AI + garlic 自动化逆向 Android App

发布于

neocanable: 我给 [garlic decompiler](https://github.com/neocanable/garlic) mcp-server 可以跑起来了。

## 效果
拿 Tinder 一个旧版本举例:

```
▎ Meet Fable 5, our newest model for complex, long-running work. Switch anytime with /model.

❯ 帮我分析一下 tinder.apk

..... bla bla bla

---
Tinder APK 分析报告 — v17.24.0 (build 17240054)

---
📦 基本信息

这里列出来 tinder 的基本信息

✻ Sautéed for 1m 55s

※ recap: You asked me to analyze tinder.apk. I've completed the full analysis — extracted the AndroidManifest, decompiled 98,603 Java files, built a call graph with 586K nodes and 1.49M edges, and produced a comprehensive report covering permissions, API endpoints, architecture, security, and monetization. The manifest and decompiled sources are in `/Users/neo/apks/tinder/inner_analyze/decompiled/`. Let me know what you'd like to dive deeper into. (disable recaps in /config)
```

紧接着,我要求 ai 帮我分析 tinder 的登录认证的流程,结果如下:

```
❯ 查看 feature/auth 模块的源码看看认证流程

Thought for 40s, searched for 2 patterns, read 1 file, listed 5 directories, searched memories

分析完毕,以下是 Tinder 认证( auth )模块 的完整源码分析报告:

---
Tinder 认证模块源码分析

目录结构

feature/auth/
├── captcha/ # Arkose Captcha / HCaptcha 验证
├── collect/email/ # 邮箱收集
├── consent/ # 用户同意
├── email/otp/ # 邮箱 OTP 验证
├── google/ # Google 登录
├── inboundsms/ # 运营商 SMS 验证
├── internal/ # 核心认证逻辑
│ ├── activity/ # AuthStartActivity, TermsOfServiceActivity
│ ├── authflow/ # ★ 认证流程状态机(核心)
│ ├── di/ # Hilt DI 模块
│ ├── fragment/ # LoginFragment (登录 UI )
│ ├── levers/ # 功能开关( A/B 测试)
│ ├── phoneverification/ # 手机验证子流程
│ ├── presenter/ # MVP Presenter
│ ├── usecase/ # 用例层
│ └── viewmodel/ # LoginViewModel
├── passkeys/ # Google Passkey 无密码认证
├── phone/
│ ├── number/ # 手机号输入
│ └── otp/ # 手机 OTP 验证
└── usecases/ # 暴露给外部的接口

---
1. 认证方式 (AuthType)

8 种认证方式,每种对应一个 key 字符串:

┌────────────────┬──────────────────┬───────────────────────────┐
│ 枚举 │ key │ 说明 │
├────────────────┼──────────────────┼───────────────────────────┤
│ LINE │ "line" │ LINE 第三方登录 │
├────────────────┼──────────────────┼───────────────────────────┤
│ GOOGLE │ "google" │ Google 登录 │
├────────────────┼──────────────────┼───────────────────────────┤
│ TINDER_SMS │ "sms" │ 短信验证码(主流程) │
├────────────────┼──────────────────┼───────────────────────────┤
│ PUSH │ "push" │ Push 推送认证 │
├────────────────┼──────────────────┼───────────────────────────┤
│ STACKS │ "stacks" │ Stacks 认证 │
├────────────────┼──────────────────┼───────────────────────────┤
│ EMAIL │ "email" │ 邮箱验证 │
├────────────────┼──────────────────┼───────────────────────────┤
│ CREATE_ACCOUNT │ "create_account" │ 创建新账号 │
├────────────────┼──────────────────┼───────────────────────────┤
│ LOGIN │ "login" │ 登录(通用) │
├────────────────┼──────────────────┼───────────────────────────┤
│ PASSKEY │ "passkey" │ Google Passkey 无密码认证 │
└────────────────┴──────────────────┴───────────────────────────┘

---
2. 认证流程状态机 (AuthFlowStep)

认证是一个状态机,每一步代表一个状态:

┌─────────────┐
│ Processing │ (处理中)
└──────┬──────┘

┌────────────┼────────────┐
▼ ▼ ▼
┌────────────┐ ┌──────────┐ ┌──────────┐
│InitialStep │ │NextStep │ │ConsentIs │
│Ready │ │Ready │ │Required │
└─────┬──────┘ └─────┬────┘ └──────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────┐
│ Authenticated│ │ Error │
└──────────────┘ └────┬─────┘

┌───────────┼──────────┐
▼ ▼ ▼
┌────────┐ ┌─────────┐ ┌────────┐
│ Ban │ │ Warning │ │Cancelled│
└────────┘ └─────────┘ └────────┘

认证完成后进入 AuthOutage (认证服务不可用)或 Authenticated 。

---
3. 认证 Step 栈 (AuthStepV2)

认证过程由多个 Step 按顺序推进,支持回退。Step 类型:

┌────────────────────────────────────┬─────────────────────────────┐
│ Step │ 说明 │
├────────────────────────────────────┼─────────────────────────────┤
│ CaptchaStep │ 人机验证( Arkose/HCaptcha ) │
├────────────────────────────────────┼─────────────────────────────┤
│ CollectEmail │ 收集邮箱地址 │
├────────────────────────────────────┼─────────────────────────────┤
│ EmailOtp │ 邮箱 OTP 验证码 │
├────────────────────────────────────┼─────────────────────────────┤
│ Onboarding │ 新用户引导流程 │
├────────────────────────────────────┼─────────────────────────────┤
│ Phone │ 收集手机号 │
├────────────────────────────────────┼─────────────────────────────┤
│ PhoneOtp │ 手机 OTP 验证码 │
├────────────────────────────────────┼─────────────────────────────┤
│ InboundSms │ 运营商 SMSC 自动验证 │
├────────────────────────────────────┼─────────────────────────────┤
│ IneligibleTinderUEmail │ 不符合 Tinder U 条件的邮箱 │
├────────────────────────────────────┼─────────────────────────────┤
│ AccountRecoveryAwaitEmailMagicLink │ 账户恢复等待邮件 │
├────────────────────────────────────┼─────────────────────────────┤
│ Passkey │ Passkey 验证 │
└────────────────────────────────────┴─────────────────────────────┘

Step 栈是有序列表:每次新 step 被 push 到栈顶,出错时可以 pop 回到上一个 step 。

---
4. 请求/响应模型 (AuthRequest / AuthResult)

AuthRequest ( 27 种请求):
Captcha, CollectEmail, ChallengeRecovery,
EmailForAccountRecovery, EmailMagicLinkOtp,
EmailOtp, EmailOtpResend, DismissEmailOtp,
DismissTinderUIneligibleEmail,
Facebook, Google, Line,
Phone, PhoneOtp, PhoneOtpResend,
InboundSms, Refresh, PreEmail,
ExistingPhoneOtp, ExistingPhoneOtpResend,
CreateNewAccount, DismissPasskey,
InitiatePasskey, ValidatePasskey,
InitiateAuthenticatePasskey, AuthenticatePasskey

AuthResult 类型:
- Authenticated — 认证成功
- Response — 需要下一步(携带 AuthStepV2 )
- Error — 各种错误( Ban, Warning, IOError, 限流等)

---
5. AuthFlowViewModel 核心方法

注入关键 (反混淆后推测):

┌───────────────────────────────┬────────────────────────────────────────────┐
│ 依赖 │ 用途 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ SubmitAuthRequestV2Impl │ 提交认证请求到 AGS ( Auth Gateway Service ) │
├───────────────────────────────┼────────────────────────────────────────────┤
│ SaveInitialAuthTypeImpl │ 保存初始认证方式 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ LoadInitialAuthTypeImpl │ 恢复上次认证方式 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ ClearAuthTokensImpl │ 清除 token │
├───────────────────────────────┼────────────────────────────────────────────┤
│ SaveBanImpl │ 保存封禁记录 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ FireworksAuthTracker │ 分析事件埋点 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ AuthInteractTracker │ 交互跟踪 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ PasskeyAuthFlowDiagnostics │ Passkey 诊断 │
├───────────────────────────────┼────────────────────────────────────────────┤
│ UpdatedEmailAddressRepository │ 邮箱更新仓库 │
└───────────────────────────────┴────────────────────────────────────────────┘

关键词方法:
- d0() — continueSetInitialAuthStep:设置初始认证 step
- e0() — prePasskeyData:Passkey 前置检查
- f0() — applyInitialAuthStep:应用初始 step
- g0() — checkIfAuthIsUp:健康检查
- h0() — 根据错误消息解析回退 step
- i0() — handleBan:处理封禁/错误
- j0() — handleAuthenticated:认证成功处理
- k0() — 计算下一个可用 step
- m0() / s0() — 显示错误/回退 UI
- t0() — 从 AuthType 生成 Phone Step
- u0() — 从 AuthType 生成认证请求
- v0() — 更新 step 或显示错误

---
6. 完整认证流程

AuthStartActivity
├── onCreate() → 检查 Intent 中的 ban/onboarding/challenge 状态
├── 启动 LoginFragment (登录 UI )
│ └── 用户选择登录方式( Google/SMS/Email/Passkey/LINE )
│ └── LoginFragment.Listener.e(AuthType) 回调
│ └── 调用 AuthFlowActivity

└── AuthFlowActivity ★ 认证流程 Activity
├── AuthFlowViewModel 持有 StateFlow<AuthFlowState>

├── 1) 首次进入:d0() → continueSetInitialAuthStep
│ ├── e0() 检查 Passkey 是否可用
│ ├── checkIfAuthIsUp() 健康检查
│ └── applyInitialAuthStep() 设置初始 Step

├── 2) AuthStepLauncher 根据 AuthStepV2 类型启动目标 Activity:
│ ├── CaptchaStep → Captcha Activity (Arkose/HCaptcha)
│ ├── CollectEmail → 邮箱输入 Activity
│ ├── EmailOtp → 邮箱 OTP Activity
│ ├── Phone → 手机号输入 Activity ★
│ ├── PhoneOtp → 手机 OTP Activity ★
│ ├── InboundSms → 运营商自动验证
│ ├── Passkey → Passkey 全屏 Activity
│ ├── Google → Google Sign-In
│ ├── LINE → LINE 授权
│ ├── Onboarding → 新用户引导
│ └── IneligibleTinderUEmail → Tinder U 不兼容提示

├── 3) 每个子 Activity 返回后,ViewModel 提交 AuthRequest
│ └── AGS (Auth Gateway Service) 返回 AuthResult
│ ├── Authenticated → j0() → 登录成功
│ ├── Response(NextStep) → 推入 step 栈继续
│ └── Error → i0() → 处理具体错误

└── 4) 错误处理 (i0):
├── Ban (40301, 40341) → 保存封禁 + 显示 Ban 页面
├── Warning → 显示警告
├── 各种限流 → 显示 toast + 回退
├── InvalidPhone/OTP → 显示错误 + pop step
└── IOError/Unknown → 通用错误

7. 手机验证子流程 (主要认证路径)

PhoneVerificationAuthViewModel 管理手机验证的独立流程:

PhoneNumberCollectionActivity
└── 用户输入手机号
└── SubmitNewPhoneNumberImpl → 提交到 AGS
├── GoToPhoneOtpStep → PhoneOtpActivity
│ └── 用户输入验证码
│ └── VerifyUpdatedPhoneOtpImpl → 验证
│ ├── PhoneOtpSuccess → 完成
│ └── Error → 各种错误/重试
└── 错误 → 显示错误提示

注入的分析事件跟踪器:AuthVerifySMSEvent — 标记 enterPhoneNumber / submit / enterOTP 各阶段的指标。

---
8. AuthStartActivity 入口

AuthStartActivity 是认证入口 Activity (从 LaunchActivity 跳转),它:

- 实现了 LoginTarget 接口( 16+ 方法)
- 处理 deep link 跳转:deep_link_uri, onboarding_token_extra
- 处理封禁参数:extra_ban_error_type, extra_suspension_policy, extra_appeal_token
- 处理多种启动场景:新用户引导、Challenge 、Selfie Challenge
- 登录方式选择 UI 由 LoginFragment 渲染
- 创建 LoginViewModel 管理登录状态

关键方法 (LoginTarget 接口):

┌─────────────┬──────────────────────────────────────────┐
│ 方法 │ 触发场景 │
├─────────────┼──────────────────────────────────────────┤
│ O() │ 登录成功 → 跳转 MainActivity │
├─────────────┼──────────────────────────────────────────┤
│ e(AuthType) │ 用户选择认证方式 → 启动 AuthFlowActivity │
├─────────────┼──────────────────────────────────────────┤
│ B2() / F1() │ 开启 overlay + 启动 AuthFlow │
├─────────────┼──────────────────────────────────────────┤
│ P0() / Z0() │ 封禁 → 跳转 BanActivity │
├─────────────┼──────────────────────────────────────────┤
│ T0() │ 账户恢复 │
├─────────────┼──────────────────────────────────────────┤
│ G2() │ 版本过期提示 │
├─────────────┼──────────────────────────────────────────┤
│ J2() │ Selfie 验证 │
├─────────────┼──────────────────────────────────────────┤
│ w0() │ Passkey 不可用 BottomSheet │
├─────────────┼──────────────────────────────────────────┤
│ Z1() │ Passkey 登录 │
├─────────────┼──────────────────────────────────────────┤
│ B1() │ 年龄验证 │
├─────────────┼──────────────────────────────────────────┤
│ G0() │ 邀请处理 │
└─────────────┴──────────────────────────────────────────┘

---
9. 与 AGS (Auth Gateway Service) 通信

认证请求通过 SubmitAuthRequestV2Impl 发送到 Auth Gateway Service ( api.gotinder.com 上的认证网关),这是 Tinder 后端 API 。发送的 AuthRequest 序列化后会包含:

- App-Session-Id — App 会话
- User-Session-Id — 用户会话(登录后有)
- Install-Id — 设备安装 ID
- Device/Carrier/SIM 信息 — 设备指纹
- Auth token headers — TinderAuth 拦截器注入

认证成功后,ViewModel 调用 j0() → 保存 token → 更新状态为 Authenticated → 关闭 AuthFlowActivity → 回到 AuthStartActivity → O() 启动 MainActivity 。

---

项目地址: [https://github.com/neocanable/garlic](https://github.com/neocanable/garlic) ,欢迎使用反馈。

---

原文链接:[点击查看](https://www.v2ex.com/t/1228106)

评论(8)

挺好奇的,为啥我用 Fable 做逆向一点都不好使,完全干不动活,是我使用姿势不对吗?

· 0 个赞

回复

我用 fable 的时候直接就标记切到 Opus 模型了,你是咋配置和使用的?

· 0 个赞

现在的 App 基本上都是加了固的,这工具碰到加固的包该怎么搞逆向?

· 0 个赞

回复

如果 token 够用的话,只要能把 native 层的控制流梳理清楚,我猜 AI 完全有能力把里面的虚拟机逻辑给推演出来。

· 0 个赞

回复

其实脱壳现在不算什么大问题了。普通的壳基本在 art::DexFile::OpenMemory 就能轻松抠出来,有些抽取指令的稍微费点劲但也搞定。我之前试过某大厂用 OLLVM+VMP 加固的,纯靠人去逆向简直要命,但加上一些经验指引让 AI 去跑,才三天就给扒得明明白白。要是搁平时,这种硬茬子让我搞大半年我都够呛能弄出来。

· 0 个赞

楼主,这工具支持逆向 Flutter 开发的 App 吗?

· 0 个赞

回复

了解了。现在用 Flutter 写的 App 真的越来越多了,真心希望能支持下 DartVM,这绝对是个刚需。

· 0 个赞

回复

支持是支持的,不过 Flutter 那边的 DartVM 得自己写插件去兼容,另外 native 那部分的自动化分析我也在抓紧实现中。

· 0 个赞