面对陌生 App 的标准作战流程
新手逆向陌生 App 最容易犯的错是"上来就怼签名算法"——逆了三天算法，发现还要设备指纹；搞定指纹，发现还有行为风控。正确的流程是先侦察全貌，再决定主攻方向。这套流程我跑了几十个项目，稳定可靠。
第一阶段：侦察（半天，不动手逆）
1. 抓包看全貌
挂上抓包工具（Charles/mitmproxy），把 App 的核心业务流程走一遍（登录、列表、详情、提交），回答三个问题：
- 接口是 HTTP 还是私有协议？（决定分析工具）
- 有没有签名参数？（sign/token/encrypt 字样）
- 响应是明文还是密文？
2. 静态看结构
jadx 打开 APK（先不深入），看三样东西：
- 加没加固（入口 Application 是不是壳的）
- 接了哪家风控 SDK（搜 ishumei/dingxiang/tongdun/SecurityGuard）
- 网络层用的什么（OkHttp/Cronet/自研）
3. 评估防护等级
根据侦察结果分级：
| 等级 | 特征 | 预估工作量 |
|---|---|---|
| 轻 | 无签名或签名在 JS/Java 层 | 小时级 |
| 中 | 签名在 SO 无加固 + 风控 SDK | 1-3 天 |
| 重 | 加固 + SO 签名 + 行为风控 | 周级 |
第二阶段：突破签名（核心战役）
按侦察结果选路径：
签名在 Java 层：jadx 读逻辑 → Python 复现 → 对拍验证
签名在 SO 层（无加固）：
- jnitrace 跑一遍，拿签名函数的输入输出（黑盒分析）
- 判断算法类型（标准算法搜常量，自定义看结构）
- 决策：简单算法手搓还原，复杂算法 Frida RPC 直调
签名在 SO 层（有加固）：先脱壳（FRIDA-DEXDump），再走上面的流程。VMP 级防护直接 Frida RPC，不犹豫。
第三阶段：处理风控参数
签名通了之后处理风控层：
- 设备指纹参数（smid/blackbox/umid）：hook 生成函数拿真机值，池化管理
- 行为验证码（滑块/点选）：先控速避免触发，必须处理时上识别方案
- 环境检测（root/模拟器）：Frida 反检测或换干净环境
第四阶段：工程化
协议跑通后变成稳定服务：
- 签名服务化（Frida RPC 或本地算法）
- 账号池/设备池/IP 池三池配套
- 监控告警（签名失效率、风控触发率）
精髓：流程背后的三个原则
- 侦察先行，永远别在信息不足时开工。半天侦察省三天弯路——知道防护全貌后，主攻方向是显而易见的
- 每步验证，小步快跑。签名对了用公开接口验证，风控过了用小号验证——每个里程碑都有明确的"通过标准"，不带着隐患往下走
- 成本意识贯穿始终。每个决策点都问：还原 vs 直调、自建 vs 打码、协议 vs 自动化——选成本最低的达标路径，不选技术上最爽的路径
常见翻车点速查
- 抓不到包 → QUIC（封 UDP 443）或 Pinning（Frida 绕过）
- 签名算对但 403 → 缺设备指纹参数或 cookie 体系没走全
- 单机通批量挂 → IP/账号/设备三池没配套
- 跑一周突然全挂 → App 更新换了算法/密钥，建立版本监控
总结
- 四阶段流程：侦察 → 破签名 → 处理风控 → 工程化
- 侦察半天定方向，防护分级定工作量
- 每步有验证标准，不带隐患前进
- 成本意识：达标路径里最便宜的，不是技术上最爽的
交流微信：run1255