android-app-reverse

对 $ARGUMENTS 执行 Android App 逆向分析。

MCP 依赖:

• frida-mcp — Frida 动态 Hook（spawn/attach/注入脚本/消息读取）
• adb-mcp — ADB 设备管理（安装/文件传输/截屏/日志/输入模拟）
• androidproxymcp — 流量捕获（HTTP/HTTPS 抓包/API 分析）

前置检查

开始分析前确认环境：

1. list_devices → 检查 ADB 是否连接到设备
2. get_device_info → 确认设备信息（型号、Android 版本、root 状态）
3. check_frida_status → 检查 frida-server 是否运行
   └── 未运行 → start_frida_server
4. proxy_status → 检查代理服务是否运行（如需抓包）

分析流程

根据目标灵活选择阶段，不必全部执行：

Stage 1: 目标识别与信息收集

1. list_packages → 查找目标 App 包名
   └── 未安装 → install_app(apk_path) 安装 APK
2. get_frontmost_application → 确认目标 App 在前台
3. pull_file → 提取 APK:
   - /data/app/<package>/base.apk → 本地分析
4. 静态分析（本地执行，非 MCP）:
   - jadx / apktool 反编译
   - 查看 AndroidManifest.xml（权限、组件、入口）
   - 识别加固壳（360、腾讯、梆梆等）
   - 定位网络请求相关类

Stage 2: 流量捕获与 API 发现

目标: 找到目标 API 请求、识别加密参数

1. 配置代理:
   - 手机 WiFi 设置代理 → 指向 android_proxy_mcp 的 IP:8288
   - 需要 HTTPS → get_cert_info 获取 CA 证书安装指引

2. 驱动 App 操作:
   - send_tap(x, y) / send_swipe(...) → 模拟用户操作触发请求
   - send_text("搜索关键词") → 输入文本
   - take_screenshot → 截屏确认当前界面

3. 分析流量:
   - traffic_list → 列出捕获的请求（按域名/状态码筛选）
   - traffic_search("sign") → 搜索包含加密参数的请求
   - traffic_get_detail(reqid) → 查看请求头、响应头
   - traffic_read_body(reqid) → 读取请求/响应体
   
4. 识别加密参数:
   - 记录加密字段名、位置（header/body/query）
   - 记录字段值的特征（长度、编码格式、是否时间相关）
   - 对比多次相同请求，观察哪些字段变化

Stage 3: SSL Pinning 绕过

如果 HTTPS 抓包失败（证书错误），需要绕过 SSL Pinning：

方案 A: Frida 脚本 Hook（推荐）
  spawn(package_name, script_file_path="ssl_bypass.js")
  
  通用 SSL Pinning 绕过脚本思路:
    - Hook TrustManager.checkServerTrusted → 置空
    - Hook OkHttp CertificatePinner.check → 绕过
    - Hook SSLContext.init → 替换为信任所有证书
    - Hook WebViewClient.onReceivedSslError → proceed
  
方案 B: LSPosed + TrustMeAlready 模块（免 Frida）
  参考 references/ssl-pinning-bypass.md

方案 C: 修改 APK（network-security-config）
  解包 → 修改 res/xml/network_security_config.xml → 重打包签名

Stage 4: 动态 Hook

目标: 拦截加密函数的输入输出，理解加密逻辑

4.1 Java 层 Hook

// spawn 或 attach 后注入 Frida 脚本

// Hook 加密方法，打印输入输出
Java.perform(function() {
    var EncryptUtil = Java.use("com.target.utils.EncryptUtil");
    
    EncryptUtil.encrypt.overload("java.lang.String").implementation = function(input) {
        console.log("[encrypt] input: " + input);
        var result = this.encrypt(input);
        console.log("[encrypt] output: " + result);
        return result;
    };
});

操作流程:

1. spawn(package_name, initial_script=上述脚本)
   或 attach(package_name, initial_script=上述脚本)
2. 操作 App 触发加密
3. get_messages(max_messages=200) → 读取 hook 输出
4. 分析输入输出关系

4.2 Native 层 Hook（.so 文件）

// Hook native 函数
Interceptor.attach(Module.findExportByName("libnative.so", "Java_com_target_NativeLib_sign"), {
    onEnter: function(args) {
        console.log("[native sign] arg0: " + args[0]);
        console.log("[native sign] arg1: " + Memory.readUtf8String(args[1]));
    },
    onLeave: function(retval) {
        console.log("[native sign] return: " + Memory.readUtf8String(retval));
    }
});

4.3 常用 Hook 目标

Stage 5: 算法还原

根据 Stage 4 的 Hook 结果，还原加密算法：

情况 A: 标准加密算法（MD5/SHA/AES/RSA/HMAC）
  → Hook 拿到 key/iv/salt 等参数
  → 直接用 Python 标准库实现
  → 验证：相同输入 → 相同输出

情况 B: 自定义算法（Java 层）
  → 反编译代码 + Hook 中间值
  → 逐步还原逻辑到 Python
  → 多组数据验证

情况 C: Native 层算法（.so 文件）
  → IDA/Ghidra 反编译 .so
  → Frida hook native 函数拿中间值
  → 还原到 Python 或直接调用 .so（ctypes/cffi）

情况 D: 第三方加固/保护
  → 先脱壳（Frida dump dex）
  → 再按 A/B/C 处理

反模式

• 不要在未 root 设备上尝试 Frida — 非 root 需要重打包 APK 注入 frida-gadget，流程完全不同。
• 不要忽略 ProGuard 混淆 — 大部分 App 的类名/方法名被混淆，需要在反编译代码中搜索特征字符串（如 "sign"、"encrypt"、"MD5"）定位目标类。
• 不要只 hook 一层 — 很多 App 的签名是多步组合（先 MD5 再 HMAC 再 Base64），需要 hook 整个调用链。
• 不要忘记时间戳 — 大部分签名包含时间因子，重放时需要更新时间戳。
• spawn vs attach — 需要在 App 启动前 hook（如 onCreate 中的初始化逻辑）用 spawn；hook 已运行 App 的实时行为用 attach。

完成标准

分析结果：
- App：$ARGUMENTS
- 目标 API：https://api.example.com/v1/feed
- 加密参数：X-Sign（位于请求头）
- 算法类型：HMAC-SHA256
- 密钥来源：固定密钥，硬编码在 so 层
- Python 实现：output/sign.py（已验证）
- 验证结果：相同输入产生相同签名，HTTP 200 + 业务数据返回

References

遇到具体场景时按需读取：