Android 反向工程与 HTTP API 自动化提取技能插件
该项目作为 Claude Code 的技能插件，自动化反编译 Android 包并抽取 Retrofit/OkHttp 等 HTTP API，适用于安全审计、互操作性分析与应急响应场景。
GitHub SimoneAvogadro/android-reverse-engineering-skill 更新 2026-04-17 分支 main 星标 2.2K 分叉 250
Android 逆向 API 抽取 静态反编译 安全审计

💡 深度解析

7
项目解决了哪些具体问题，核心价值是什么？

核心分析

项目定位：该项目的核心价值在于把静态反编译的分散信息（Java/Kotlin 反编译结果、Manifest、资源）自动化解析为结构化的 HTTP API 列表与调用链，从而在没有源码的情况下快速定位、文档化和重现应用的网络交互。

技术特点

  • 多引擎反编译：通过 jadx 与 Fernflower/Vineflower 并列使用，减轻单一引擎在处理混淆或复杂生成代码时的局限。
  • 规则化抽取：脚本能够识别 Retrofit 注解、OkHttp 调用、硬编码 URL 以及常见认证头和令牌模式。
  • 调用链追踪：静态追踪从 Activity/Fragment 经 ViewModel/Repository 到 HTTP 调用点，便于理解触发条件与上下文。
  • 脚本化流程：包含依赖检查、反编译、API 抽取脚本（如 decompile.sh、find-api-calls.sh），保证可重复性。

实用建议

  1. 作为第一步情报收集工具：在没有源码时优先运行以快速得到候选端点和认证线索。
  2. 并行引擎对比：同时使用 --engine both 或分别运行两种反编译器以提高恢复率。
  3. 与动态验证结合：把静态抽取的结果作为动态抓包或 Frida 验证的输入，补足静态盲点。

重要提示：此工具侧重静态分析，对运行时拼接、反射、原生 (.so) 或加密后动态解密的端点可能无法完整识别；在缺失 mapping 的混淆代码中，调用链可读性会显著下降。

总结：若目标是从二进制快速提取并文档化网络 API 并建立可复现的分析流程，该项目提供了高价值的自动化起点，能显著节省手工检索与组合信息的时间。

90.0%
在什么场景下静态 API 抽取会失败或严重不完整？应该如何补救？

核心分析

问题核心：哪些情况会导致静态 API 抽取失败或严重不完整？如何补救以获得可靠的接口信息？

技术分析

  • 常见失败场景：
    1. 运行时拼接/加密：URL、路径或认证 token 在运行时解密或拼接，静态扫描无法还原完整字符串；
    2. 反射与动态代理：调用目标被反射隐藏，静态解析无法分辨真实调用点；
    3. 原生网络逻辑：通信在 .so 中实现（或通过 JNI 进入原生层），静态 Java/Kotlin 视角看不到细节；
    4. 动态加载/模块化：部分功能在运行时下载/加载，静态包中没有完整代码；
    5. 严重混淆且无 mapping：方法/类名不可读，断裂调用链的语义。

补救建议

  1. 动态验证为必需：使用 mitmproxy、Burp 或 Frida 在受控环境中抓包与 hook 验证静态抽取结果；对使用 pinning 的应用可采用 hook 或模拟证书安装（在合法授权下）。
  2. 恢复符号信息：如可能，获取 ProGuard/R8 mapping 文件或使用模式化识别（参数/常量匹配）恢复含义。
  3. 混合分析流程：先静态抽取候选，再动态触发这些路径以确认端点与认证流程，记录可复现步骤与证据链。
  4. 原生层分析：对怀疑在 .so 中的逻辑，使用逆向/符号分析或在运行时监控网络调用（如 TCP/UDP 层抓包）。

注意事项：动态干预可能改变运行状态或违反应用条款/法律，务必在授权和受控环境下进行。

总结：静态抽取是高效的信息收集手段，但在遇到运行时构造、反射或原生实现时必须结合动态分析与符号恢复才能得到完整且可验证的结果。

88.0%
如何把该工具整合到事件响应或接口重实现的工作流中？推荐的实际步骤和输出格式是什么？

核心分析

问题核心：如何把该工具嵌入到事件响应或 API 重实现流程，以保证速度、可复现性与交付物质量？

技术分析

  • 工具天生适配阶段化工作流：项目自带 check-deps.sh、decompile.sh、find-api-calls.sh 等脚本，便于把静态分析阶段自动化并嵌入更大的响应流程。
  • 推荐输出类型：结构化 JSON（用于机器处理）、CSV（快速审阅）、以及 Markdown 报告（可读的书面交付物）。输出应包含每个端点的：URL/路径、库识别（Retrofit/OkHttp）、来源文件/行号片段、调用链上下文、认证线索、置信度标签与验证建议。

推荐实际步骤

  1. 环境与依赖检查：运行 check-deps.sh 并安装缺失工具（install-dep.sh）。
  2. 并行反编译：decompile.sh app.apk --engine both --deobf，将两套输出保存到各自目录。
  3. 静态抽取：find-api-calls.sh output/sources/ --retrofit --urls，生成结构化 JSON/CSV 列表。
  4. 优先级分配：基于置信度、是否含认证或敏感域名分配验证优先级。
  5. 动态验证：在隔离环境中用 mitmproxy/Frida 自动化脚本验证高优先级端点并捕获请求/响应样本。
  6. 产出交付物：综合报告（Markdown + JSON 附件），包含复现步骤、证据片段、建议的响应动作或重实现说明。

注意事项：事件响应中应严格控制环境与授权；动态验证可能需要设备配置或证书调整，需记录并保留证据链。

总结：把该工具作为静态初筛并输出结构化候选列表，配合自动化动态验证与标准化文档输出，可以为事件响应与 API 重实现提供可复现、审计友好的工作流。

88.0%
调用链追踪能到什么程度？静态追踪的可行性与局限是什么？

核心分析

问题核心：工具声称能从 UI 层追踪到 HTTP 调用。静态追踪能做到什么，在哪些情况下会失败？

技术分析

  • 高可行情景：当应用采用标准架构（Activity/Fragment → ViewModel/Repository → 网络层）并使用显式库（Retrofit、OkHttp）时，静态规则能：
  • 识别 Retrofit 接口与注解（@GET, @POST 等）；
  • 定位 OkHttp 的构建/执行点；
  • 沿调用栈静态分析参数与返回传递，构建从 UI 到网络的路径图。
  • 主要局限：
  • 反射与动态代理：反射调用的目标方法在编译时不可见，静态规则无法解析最终调用目标；
  • 运行时字符串拼接/加密：URL 或头部若在运行时解密/拼接，静态抽取会产生假阴性；
  • 原生代码与动态加载：通过 .so 或 dex 动态加载发起的通信无法被常规静态流程捕获；
  • 混淆缺失 mapping：方法/类语义丢失，降低调用链可读性与可信度。

实用建议

  1. 先用静态提纲定位候选点：将输出作为动态测试（mitmproxy / Frida）的输入目录化。
  2. 标记不确定性：对通过反射或字符串拼接疑似生成的端点在文档中打上置信度标签并优先验证。
  3. 获取 mapping 或结合符号恢复：如可能，获取 ProGuard/R8 mapping 文件以提升链路可读性。

注意事项：静态追踪并非最终证据；在法律或应急场景中应以动态抓包或可复现测试作为补证。

总结：静态调用链追踪在多数常规 Android 架构中非常有用，但其盲点需要通过动态方法补齐以保证完整性与准确性。

87.0%
该工具的学习曲线和典型使用痛点是什么？有哪些最佳实践可以降低使用门槛？

核心分析

问题核心：使用门槛有多高？常见痛点是什么？如何有效上手并减少错误？

技术分析

  • 学习曲线来源：需要掌握 Android 应用结构、反编译产物（Java/Kotlin）解读、命令行操作以及相关工具（JDK 17+, jadx, 可选 vineflower/dex2jar）。
  • 典型痛点：
  • 环境依赖与版本不匹配导致反编译失败；
  • 混淆（无 mapping）导致方法/类不可读；
  • 静态规则产生假阳性/假阴性，尤其是动态拼接/反射场景；
  • 误把静态结果当作最终证据，未做动态验证。
  • 工具已有缓解措施：提供 check-deps.sh / install-dep.sh 脚本与示例命令（decompile.sh, find-api-calls.sh）以自动化安装与固定流程。

实用建议（最佳实践）

  1. 先运行依赖检查：用 check-deps.sh 确保环境满足 JDK 17+、jadx 等需求。
  2. 分阶段工作流：
  3. decompile.sh（或 --engine both）获取不同引擎输出；
  4. find-api-calls.sh --retrofit/--urls 抽取候选列表；
  5. 用 mitmproxy/Frida 验证高价值端点。
  6. 并行对比结果：把两套反编译结果比对以寻找更完整的上下文与更少的断点。
  7. 记录不确定性：对于通过反射或拼接猜测出的端点加置信度标注并优先验证。

注意事项：熟练使用仍需逆向基础；若分析法律敏感或受限，请确保有相应授权。

总结：虽然有中等偏高的学习曲线，但脚本化工具、分阶段流程与结合动态验证的实践可以显著降低上手难度并提高分析质量。

86.0%
遇到已被 ProGuard/R8 混淆但没有 mapping 文件时，如何提升结果可读性和调用链重构？

核心分析

问题核心：没有 ProGuard/R8 mapping 文件时，如何提升反编译输出的可读性并重建有用的调用链？

技术分析

  • 不可避免的限制：缺失 mapping 意味着原始类与方法名被永久替换，无法完全恢复到原始语义。直接名字恢复不可行，但可采用多种启发式和补救措施来重建上下文。
  • 可行技术手段：
    1. 多引擎并列对比：jadx 与 Fernflower 在不同代码路径上可能恢复不同的局部可读性，比较两者有助于找出更清晰的实现片段；
    2. 字符串与常量线索：URL、注解、Resource 字符串、log 文本等常量可用于给混淆符号贴标签；
    3. 签名与参数类型推断：通过方法签名、参数与返回类型推断方法责任，例如带 Call<> 或 Response<> 的方法很可能是网络接口；
    4. 运行时映射：在受控环境下运行并收集栈信息、日志或使用 Frida 打点，将运行时名称映射回混淆符号；
    5. 模式化识别：基于已知库（Retrofit/OkHttp）写识别规则以自动标注接口/调用点。

实用建议

  1. 并行反编译并合并线索：先用 --engine both，把两套输出合并成一个带置信度的候选表。
  2. 优先找常量与注解位置：硬编码 URL、注解（Retrofit 注解）与 Manifest 中的组件名通常没有被混淆，是恢复语义的重要锚点。
  3. 结合动态运行时证据：使用抓包或打点把运行时行为与静态符号关联起来。
  4. 文档化不确定性：对每个推断出的调用链记录证据来源与置信度，以便审计与复现。

注意事项：在没有 mapping 的情况下，任何符号重命名/语义恢复都带有不确定性，应以动态验证作为最终确认。

总结：虽然无法完美恢复原始符号，通过多引擎对比、常量/注解线索、签名推断和运行时映射，可以显著提升可读性并重建有用的调用链，建议将这些方法系统化为标准流程。

86.0%
为什么选择 `jadx` 与 `Fernflower/Vineflower`，项目架构有哪些优势？

核心分析

问题核心：为什么用 jadx 与 Fernflower/Vineflower，以及项目架构带来哪些实际优势？

技术分析

  • 引擎互补性：jadx 直接解析 DEX，通常对 Kotlin、Android lambda、资源引用等保持较好语义；Fernflower/Vineflower（在 dex2jar 转换后的 JAR 上）往往输出更接近可读的 Java 源码，特别是在 Java 代码路径上可读性更高。并列比较可利用两者输出互补优点，减轻单一引擎失败时的风险。
  • 模块化架构：项目按 plugins/skills/commands/references/scripts 分层，方便替换反编译器、扩展识别规则或集成额外分析阶段（如 AST 分析或符号恢复）。
  • 脚本化工作流：decompile.sh、find-api-calls.sh 等脚本保证步骤可重复、易于自动化并可嵌入 CI/流水线。

实用建议

  1. 默认并行运行：对复杂或混淆的 APK 首先运行 --engine both，比较输出以找出更完整的语义恢复。
  2. 在需要时使用 dex2jar：如果目标对 Java 源码可读性敏感，先用 dex2jar 转换再用 Fernflower 反编译。
  3. 定制规则与后处理：根据常见库（Retrofit/OkHttp）写附加匹配规则以减少误报。

注意事项：依赖外部反编译工具的版本兼容性与本地环境（JDK 17+）配置会直接影响结果；确保 check-deps.sh 通过并定期更新工具链。

总结：多引擎 + 模块化 + 脚本化的架构提高了反编译的恢复率与可维护性，使该工具在面对多样化 APK 时更稳健且易扩展。

85.0%

✨ 核心亮点

  • 支持 jadx/Fernflower 双引擎对比
  • 自动抽取 Retrofit/OkHttp 与硬编码 URL
  • 包含完整安装与一键脚本化工作流
  • 依赖外部工具与运行环境配置
  • 未经授权的逆向存在法律合规风险

🔧 工程化

  • 可反编译 APK/XAPK/JAR/AAR 并提取 HTTP API 端点
  • 沿调用链追踪从 Activity 到 HTTP 的调用流
  • 提供查找 API 调用与多引擎对比的自动化脚本

⚠️ 风险

  • 仓库元信息不完整，显示无贡献者与无发布记录
  • 对复杂混淆代码的结果可能需要人工校验
  • 未授权逆向可能违反法律，使用者需自行承担合规责任
  • 依赖 JDK17、jadx、dex2jar 等外部组件，集成成本存在

👥 适合谁？

  • 安全研究员、应用渗透测试与移动安全审计人员
  • 逆向工程师、恶意软件分析师与应急响应团队
  • 需要从二进制恢复 API 或做互操作性分析的开发者