android-reverse-engineering

Android 逆向工程

使用 jadx 和 Fernflower/Vineflower 反编译 Android APK、XAPK、JAR 和 AAR 文件，追踪应用代码和库中的调用流程，并为提取出的 API 编写结构化文档。支持两种反编译引擎——jadx 适用于广泛的 Android 场景，Fernflower 则能为复杂 Java 代码提供更高质量的输出；两者也可以搭配使用，以便进行对比。

先决条件

此技能需要安装 Java JDK 17+ 和 jadx。Fernflower/Vineflower 和 dex2jar 为可选项，但建议安装，以获得更好的反编译质量。运行依赖检查器进行验证：

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh

在 Windows 上（PowerShell）：

& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.ps1"

如果缺少任何依赖，请按照 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md 中的安装说明进行安装。

工作流

阶段 0：识别应用特征（建议优先执行）

在安装工具或反编译之前，先快速检查应用，判断它属于哪种类型。对于 Flutter、React Native、Cordova/Capacitor 和 Xamarin 应用，反编译 Java 基本没有用——真正的代码 位于其他位置。特征识别脚本会告诉你应用属于哪种类型。

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/fingerprint.sh <file.apk|file.xapk>

脚本会在一个屏幕中输出以下信息：

• 移动框架（Flutter / React Native / Cordova / Xamarin / Native Kotlin / 等），以及触发判断的文件标记。
• HTTP 技术栈（Retrofit、OkHttp、Ktor、Apollo、Volley），通过 DEX 字符串扫描进行检测——即使类名已混淆也能生效。
• DI / 序列化信号（Hilt、Dagger、Koin、kotlinx.serialization、Moshi、Gson、Jackson）。
• 基于根目录级短名称包的混淆程度估算。
• 值得关注的第三方 SDK（AppsFlyer、Datadog、Sentry、Firebase、支付 SDK、支持/聊天 SDK 等）。
• 汇总基础 APK 和所有拆分包中的原生库——XAPK 拆分包通常会将 .so 文件放在 config.<abi>.apk 中，而非 base.apk 中。
• 建议的后续步骤，会根据框架而有所不同（例如，对于 Flutter，脚本会建议使用 blutter / strings libapp.so，而不是 jadx）。

如果特征识别结果表明应用使用 Flutter / RN / Cordova / Xamarin，请停止 并改用适合该框架的工具。以下阶段 1–5 假设应用是 原生 Android 应用（Java/Kotlin）。

阶段 1：验证并安装依赖项

开始反编译前，请确认所需工具均已就绪，并安装缺少的工具。

操作：运行依赖项检查脚本。

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh

在 Windows（PowerShell）上：

& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.ps1"

输出中包含机器可读的行：

• INSTALL_REQUIRED:<dep> — 必须先安装，然后才能继续
• INSTALL_OPTIONAL:<dep> — 建议安装，但不会阻止后续操作

如果缺少必需的依赖项（退出代码为 1），请自动安装：

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/install-dep.sh <dep>

在 Windows（PowerShell）上：

& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/install-dep.ps1" <dep>

安装脚本会检测操作系统和包管理器，然后：

• 尽可能在不使用 sudo 的情况下安装（下载到 ~/.local/share/，并在 ~/.local/bin/ 中创建符号链接）
• 必要时使用 sudo 和系统包管理器（apt、dnf、pacman）
• 如果需要 sudo，但无法使用或用户拒绝，脚本会输出确切的手动命令并以代码 2 退出 — 请向用户显示这些说明

Windows 说明：PowerShell 安装脚本会按顺序使用 winget、scoop 或 choco。如果这些工具都不可用，脚本会直接下载到 %USERPROFILE%\.local\share\，并将该目录添加到用户的 PATH。运行 install-dep.ps1 后，PATH 会持久化保存，但当前终端会话可能无法识别它。check-deps.ps1 和 decompile.ps1 脚本会自动从用户环境刷新 PATH，因此重新运行这些脚本即可找到新安装的工具，无需重启终端。

对于可选依赖项，请询问用户是否要安装。推荐使用 Vineflower 和 dex2jar，以获得最佳效果。

安装完成后，重新运行 check-deps.sh，确认所有依赖项均已就绪。在所有必需依赖项都正常之前，请勿进入阶段 2。

阶段 2：反编译

使用反编译包装脚本处理目标文件。该脚本支持三种引擎：jadx、fernflower 和 both。

操作：选择引擎并运行反编译脚本。该脚本支持处理 APK、XAPK、JAR 和 AAR 文件。

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/decompile.sh [OPTIONS] <file>

在 Windows（PowerShell）上：

& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/decompile.ps1" [OPTIONS] <file>

对于 XAPK 文件（包含多个 APK 的 ZIP 包，由 APKPure 等应用商店使用）：脚本会自动解压归档文件，识别其中的所有 APK 文件（基础 APK 和拆分 APK），并将每个文件反编译到单独的子目录中。XAPK 清单会复制到输出目录以供参考。

拆分／捆绑 APK 检测：有些 APK 实际上是捆绑包包装器——外层 APK 的资源目录中包含 base.apk 和 split_config.*.apk 文件。发生这种情况时，jadx 会反编译这个精简的包装器，生成的 Java 文件很少。反编译脚本会自动检测这种情况（Java 文件不超过 10 个，且存在内部 APK），并将 base.apk 重新反编译到 <output>/base/ 子目录中。仅包含配置的拆分包（ABI、语言、密度）会跳过。主要反编译源码位于 <output>/base/sources/。

选项：

• -o <dir> — 自定义输出目录（默认：<filename>-decompiled）
• --deobf — 启用反混淆（对混淆过的应用推荐使用）
• --no-res — 跳过资源，仅反编译代码（更快）
• --engine ENGINE — jadx（默认）、fernflower 或 both

引擎选择策略：

情况	引擎
首次处理任意 APK	jadx（最快，能处理资源）
分析 JAR/AAR 库	fernflower（生成更好的 Java 代码）
jadx 输出包含警告／代码损坏	both（进行比较，并为每个类选择最佳结果）
复杂的 lambda、泛型、流	fernflower
快速概览大型 APK	jadx --no-res

使用 --engine both 时，输出会分别放入 <output>/jadx/ 和 <output>/fernflower/，并在末尾提供比较摘要，显示文件数量和 jadx 警告数量。若要获得更好的代码，请查看 Fernflower 输出中对应 jadx 警告的类。

对于使用 Fernflower 处理的 APK 文件，脚本会自动使用 dex2jar 作为中间步骤。要使用此功能，必须安装 dex2jar。

完整的 CLI 参考请参阅 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md 和 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md。

阶段 3：分析结构

浏览反编译输出，了解应用的架构。

操作：

1. 读取 <output>/resources/AndroidManifest.xml：

   • 找出主启动 Activity
   • 列出所有 Activity、Service、BroadcastReceiver、ContentProvider
   • 记下权限（尤其是 INTERNET、ACCESS_NETWORK_STATE）
   • 找出应用类（<application> 上的 android:name）

2. 查看 <output>/sources/ 下的包结构：

   • 找出主应用包及其子包
   • 区分应用代码和第三方库
   • 查找名为 api、network、data、repository、service、retrofit、http 的包——API 调用通常位于这些包中

3. 读取每个 BuildConfig.java——这些文件几乎从不经过混淆，而且经常暴露整个 APK 中最有价值的常量（基础 URL、flavor 名称、构建类型、第三方 API 密钥、功能标志）：

   find <output>/sources -name BuildConfig.java -exec grep -H '=' {} \;
   

   每个 Gradle 模块都会生成自己的 BuildConfig，因此预计会有 1 到 N 个结果。请全部读取。

4. 识别架构模式：

   • MVP：查找 Presenter 类
   • MVVM：查找 ViewModel 类和 LiveData／StateFlow
   • Clean Architecture：查找 domain、data、presentation 包
   • 这有助于确定后续阶段中网络调用的位置

Phase 3.5：恢复 Kotlin 类名（仅适用于经过混淆的 Kotlin 应用）

如果 Phase 0 报告混淆程度为中等 / 高，并且应用使用 Kotlin （检测到 Compose / kotlin_module 标记），请在跟踪调用流程之前运行元数据恢复 脚本。R8 会混淆 JVM 符号，但无法移除 Kotlin 元数据字符串，因此原始 FQN 会泄露在 @DebugMetadata 和 @Metadata.d2 中。

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/recover-kotlin-names.sh \
    <output>/sources <output>/mapping

然后使用查找辅助工具，而不是直接运行 grep——每条匹配结果都会附上 所属类的真实名称：

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/lookup-name.sh \
    <output>/mapping --grep '"/api/' <output>/sources

在实际 Kotlin 应用中，通常可恢复约 100% 的 *Repository / *ViewModel / *UseCase / *Impl 类，以及约 80% 的 DTO。

完整技术方案及其局限性请参阅 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/kotlin-name-recovery.md。

Phase 4：跟踪调用流程

从面向用户的入口点沿执行路径向下追踪，直至网络调用。

操作：

1. 从入口点开始：阅读 Phase 3 中识别出的主 Activity 或 Application 类。

2. 跟踪初始化链：Application.onCreate() 通常会设置 HTTP 客户端、基础 URL 和 DI 框架。先阅读这里。

3. 跟踪用户操作：从 Activity 开始，依次追踪：

   • onCreate() → 视图设置 → 点击监听器
   • 点击处理程序 → ViewModel/Presenter 方法
   • ViewModel → Repository → API 服务接口
   • API 服务 → 实际 HTTP 调用

4. 梳理 DI 绑定（如果使用了 Dagger/Hilt）：查找 @Module 类，了解哪些实现会提供给哪些接口。

5. 处理混淆代码：类名被混淆时，使用字符串字面量和库 API 调用作为定位线索。Retrofit 注解和 URL 字符串不会被混淆。

详细技术和 grep 命令请参阅 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md。

Phase 5：提取并记录 API

找出所有 API 端点并生成结构化文档。

操作：运行 API 搜索脚本，进行全面扫描。

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/

在 Windows 上（PowerShell）：

& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/

定向搜索：

# Only Retrofit
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --retrofit

# Only hardcoded URLs
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --urls

# Only auth patterns
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --auth

在 Windows 上（PowerShell）：

# Only Retrofit
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Retrofit

# Only hardcoded URLs
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Urls

# Only auth patterns
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -AuthPatterns

将端点分为两个层级进行记录——对于有 100+ 个路径的应用，逐一深入分析每个端点成本过高，而且大多数端点并不值得这样做。务必生成 Tier 1；仅对重要端点扩展到 Tier 2。

Tier 1 — 扁平清单（始终生成）

用一个表格涵盖发现的每个端点。尽量每个端点占一行；如果无法确定某列的值，请填写 ?。

主机	方法	路径	Auth	源文件
api.example.com	GET	/v1/users/profile	Bearer	com/example/api/UserApi.java
api.example.com	POST	/v1/auth/login	none	com/example/api/AuthApi.java

这张表可让人一屏了解“后端是什么样的”，即使是大型应用，从 --paths 输出生成也只需约 5 分钟。

Tier 2 — 单个端点详情（仅适用于高价值端点）

仅对确实需要详细说明的少数端点使用详细格式：

• 完整的身份验证流程（登录、刷新、登出、OTP/SMS、匿名、注册）
• 支付 / 结账 / 创建订单端点
• 用户明确询问的内容
• 扫描过程中发现的异常内容（自定义签名、未记录的标头等）

### `METHOD /path`

- **Source**: `com.example.api.ApiService` (ApiService.java:42)
- **Base URL**: `https://api.example.com/v1`
- **Path params**: `id` (String)
- **Query params**: `page` (int), `limit` (int)
- **Headers**: `Authorization: Bearer <token>`
- **Request body**: `{ "email": "string", "password": "string" }`
- **Response**: `ApiResponse<User>`
- **Called from**: `LoginActivity → LoginViewModel → UserRepository → ApiService`

通常，除非用户明确要求更多内容，否则 Tier 2 条目不要超过约 10 个端点——Tier 1 加上对身份验证和 1-2 个关键流程的 Tier 2 深入分析，正是大多数使用者真正需要的内容。

库专属搜索模式及完整文档模板请参阅 ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md。

输出

在工作流结束时，交付：

1. 反编译后的源代码，位于输出目录中
2. 架构摘要——应用结构、主要包和所用模式
3. API 文档——以以上格式列出所有发现的端点
4. 调用流程图——从 UI 到网络的关键路径（尤其是身份验证和主要功能）

参考资料

• ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md — 安装 Java、jadx、Fernflower/Vineflower、dex2jar 和可选工具
• ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md — jadx CLI 选项和工作流
• ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md — Fernflower/Vineflower CLI 选项、适用场景和 APK 工作流
• ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md — 特定库的搜索模式和文档模板
• ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md — 在反编译代码中追踪调用流程的技巧