为什么要知道 App 接了哪家风控
逆向一个 App 的协议，第一步不是找签名算法，而是确认它接了哪家风控 SDK——不同厂商的采集策略、检测点、对抗难度差异巨大，打法完全不同。识别方法很简单，jadx 搜包名：
- 数美：
com.ishumei/smid参数 - 顶象：
com.dingxiang/dx前缀 /constId参数 - 同盾：
cn.tongdun/blackbox参数
三家对比
数美（Shumei）
- 核心产物：
smid（设备 ID），接口里常见smid、smDeviceId参数 - 采集特点：设备硬件信息全，传感器、电池等行为字段多
- 检测强度：模拟器/root 检测中等，Frida 检测有但不激进
- 对抗要点：smid 生成 hook
SmAntiFraud类的获取方法可直接拿；设备环境要成套伪装
顶象（DingXiang）
- 核心产物：
constId（设备 ID）+ 验证码服务 - 采集特点：偏重环境检测（hook 框架、调试器、注入特征扫得细）
- 检测强度：Frida/Xposed 检测三家最激进，有 inline hook 检测
- 对抗要点：先过它的反 hook 检测（改 frida-server 名/端口，或用更隐蔽的注入），再谈数据采集
同盾（TongDun）
- 核心产物：
blackbox（加密的设备信息串），接口里一个 blackbox 参数打包所有 - 采集特点：采集字段最多（包括安装列表、通讯录权限状态等敏感项），加密最重
- 检测强度：检测全面但反应温和（倾向静默标记而非闪退）
- 对抗要点：blackbox 的加密在 SO 层且有自保护，别逆算法——Frida hook 生成函数的返回，或真机采集后池化
通用的对抗框架
无论哪家，对抗框架是一样的：
第一步：摸清采集清单。hook 系统 API（getprop、文件读取、传感器枚举），跑一次 App 记录 SDK 读了什么（方法见"设备指纹原理"篇）。
第二步：分清"本地生成"与"服务端校验"。设备 ID 本地生成后还要服务端认可——本地伪造的 ID 如果格式/校验位不对，服务端直接打回。所以优先"真机采集真 ID 池化"，其次才是"本地伪造"。
第三步：环境一致性。三家都做一致性校验：Android ID 和 IMEI 的机型匹配、传感器清单和机型匹配、系统版本和安全补丁日期匹配。散装伪造必死，成套克隆才活。
精髓：三个实战认知
- 风控 SDK 的反应方式决定对抗策略。闪退型（顶象部分版本）要彻底绕过检测点；静默标记型（同盾）更危险——你以为绕过了，账号已被打上高风险标签。验证标准永远是对比"干净设备"和"你的环境"的请求结果差异
- SDK 版本比厂商更重要。同一家 SDK，2023 版和 2026 版的检测能力天差地别。逆向时先确认 SDK 版本（jadx 里看 SDK 包内的版本常量），查该版本的已知对抗方案
- 别把风控 SDK 和业务签名混为一谈。业务签名（sign 参数）是 App 自己的逻辑，风控参数（smid/blackbox）是 SDK 的产物——两条线独立逆向，先拿签名让协议跑通，再处理风控参数提高通过率
总结
- 先认厂商再定打法：数美看 smid、顶象防检测、同盾拆 blackbox
- 通用框架：摸采集清单 → 真机 ID 池化 → 环境成套克隆
- 静默标记型风控最危险，验证标准是结果对比
- 业务签名和风控参数两条线，分开逆向
交流微信：run1255