文章目录
- 1. 为什么爬虫逆向要懂 AOSP
- 2. AOSP 分层架构速览
- 2.1 与风控最相关的层级
- 3. 系统属性（System Properties）——对抗的主战场
- 3.1 属性从哪来
- 3.2 对抗思路（合规前提下仅用于自有设备测试）
- 4. 底层对抗架构：检测端 vs 采集端
- 4.1 总体架构
- 4.2 检测栈（由浅入深）
- 4.3 采集端选型
- 5. AOSP 关键模块与爬虫逆向映射
- 5.1 `Build` 类与指纹
- 5.2 Android ID
- 5.3 WebView 与 H5 爬虫
- 5.4 证书 Pinning 与 Native 网络栈
- 6. 实战案例
- 案例 1：模拟器被「一键识别」
- 案例 2：Frida 附加后 Native 检测崩溃
- 案例 3：Build 指纹与基带版本不一致
- 案例 4：1688 / 电商类 MTOP 签名与 Cookie 绑定（协议逆向）
- 案例 5：Play Integrity 阻断
- 7. 定制 AOSP 采集环境搭建（简版流程）
- 8. 架构设计建议：生产级移动采集
- 9. 常见误区
- 10. 总结与参考文档
- 参考与延伸阅读
面向爬虫工程师、逆向与安全研究人员。本文从AOSP（Android Open Source Project）源码视角，梳理 Android 原生系统的分层结构，解释 App 风控检测的落点，并给出可落地的对抗思路与实战案例。
1. 为什么爬虫逆向要懂 AOSP
移动端数据采集早已不是「抓包 + 重放 Cookie」这么简单。电商、金融、本地生活类 App 的风控链路通常覆盖：
- 环境层：是否 Root、是否模拟器、是否 Hook 框架（Frida / Xposed / LSPosed）
- 设备层：IMEI、Android ID、OAID、MAC、传感器、Build 指纹
- 网络层：TLS 指纹、证书 Pinning、MTOP/H5 签名、设备 Token
- 行为层：点击轨迹、滑动曲线、页面停留、人机验证
这些检测点的共同特点是：大量逻辑最终落在 Native 层或 Framework 层，读取的是系统属性与 HAL 返回值。如果不理解 AOSP 各层如何组织、属性从哪来、谁能改，对抗就只能停留在「改几个 Java 字段」的表层，极易被二次校验击穿。
AOSP 的价值在于：它定义了Android 的「真相来源」（Source of Truth）—
