android-reverse-engineering

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Android Reverse Engineering

Android 逆向工程

Decompile Android APK, XAPK, JAR, and AAR files using jadx and Fernflower/Vineflower, trace call flows through application code and libraries, and produce structured documentation of extracted APIs. Two decompiler engines are supported — jadx for broad Android coverage and Fernflower for higher-quality output on complex Java code — and can be used together for comparison.

使用 jadx 和 Fernflower/Vineflower 反编译 Android APK、XAPK、JAR 和 AAR 文件，追踪应用程序代码和库中的调用流，并生成已提取 API 的结构化文档。支持两种反编译器引擎——jadx 覆盖范围广，适合 Android 应用；Fernflower 在复杂 Java 代码上能够提供更高质量的输出——两者可以结合使用进行对比。

Prerequisites

前置条件

This skill requires Java JDK 17+ and jadx to be installed. Fernflower/Vineflower and dex2jar are optional but recommended for better decompilation quality. Run the dependency checker to verify:

bash

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

On Windows (PowerShell):

powershell

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

If anything is missing, follow the installation instructions in

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md

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

bash

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

在 Windows（PowerShell）上：

powershell

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

如果缺少任何依赖，请按照

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md

中的安装说明进行操作。

Workflow

工作流

Phase 0: Fingerprint the App (recommended before anything else)

阶段 0：应用指纹识别（建议在其他操作之前执行）

Before installing tools or decompiling, run a fast triage to determine what kind of app you are looking at. Decompiling Java is mostly useless for Flutter, React Native, Cordova/Capacitor, and Xamarin apps — the real code lives elsewhere. The fingerprint script tells you which.

bash

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

It prints, in one screen:

Mobile framework (Flutter / React Native / Cordova / Xamarin / Native Kotlin / etc.) with the file marker that triggered the verdict.
HTTP stack (Retrofit, OkHttp, Ktor, Apollo, Volley) detected via DEX string scan — works even when class names are obfuscated.
DI / serialization signals (Hilt, Dagger, Koin, kotlinx.serialization, Moshi, Gson, Jackson).
Obfuscation level estimate based on root-level short-named packages.
Notable third-party SDKs (AppsFlyer, Datadog, Sentry, Firebase, payment SDKs, support/chat SDKs, etc.).
Consolidated native libraries across the base APK and all splits — XAPK split bundles often place
```
.so
```
files in
```
config.<abi>.apk
```
, not in
```
base.apk
```
.
Recommended next step, which differs by framework (e.g. for Flutter the script suggests
```
blutter
```
/
```
strings libapp.so
```
rather than jadx).

If the fingerprint says the app is Flutter / RN / Cordova / Xamarin, stop and switch to the framework-appropriate tooling. Phases 1–5 below assume a native (Java/Kotlin) Android app.

在进行工具安装或反编译之前，先运行快速初步分析，判断目标应用属于哪一类。对于 Flutter、React Native、Cordova/Capacitor 和 Xamarin 应用，反编译 Java 基本没有用处——真正的代码位于其他地方。指纹脚本会告诉你答案。

bash

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

它会在一屏内输出：

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

如果指纹结果表明应用是 Flutter / RN / Cordova / Xamarin，请停止当前操作并切换到适合该框架的工具。以下阶段 1–5 假定目标是原生（Java/Kotlin）Android 应用。

Phase 1: Verify and Install Dependencies

阶段 1：验证并安装依赖

Before decompiling, confirm that the required tools are available — and install any that are missing.

Action: Run the dependency check script.

bash

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

On Windows (PowerShell):

powershell

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

The output contains machine-readable lines:

```
INSTALL_REQUIRED:<dep>
```
— must be installed before proceeding
```
INSTALL_OPTIONAL:<dep>
```
— recommended but not blocking

If required dependencies are missing (exit code 1), install them automatically:

bash

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

On Windows (PowerShell):

powershell

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

The install script detects the OS and package manager, then:

Installs without sudo when possible (downloads to
```
~/.local/share/
```
, symlinks in
```
~/.local/bin/
```
)
Uses sudo and the system package manager when necessary (apt, dnf, pacman)
If sudo is needed but unavailable or the user declines, it prints the exact manual command and exits with code 2 — show these instructions to the user

Windows notes: The PowerShell install script uses

winget

scoop

, or

choco

(in that order). If none are available, it downloads directly to

%USERPROFILE%\.local\share\

and adds the directory to the user's PATH. After running

install-dep.ps1

, the PATH is persisted but the current terminal session may not see it. The

check-deps.ps1

and

decompile.ps1

scripts automatically refresh PATH from the user environment, so re-running them will find newly installed tools without restarting the terminal.

For optional dependencies, ask the user if they want to install them. Vineflower and dex2jar are recommended for best results.

After installation, re-run

check-deps.sh

to confirm everything is in place. Do not proceed to Phase 2 until all required dependencies are OK.

反编译前，确认所需工具均已可用，并安装任何缺失的依赖。

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

bash

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

在 Windows（PowerShell）上：

powershell

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

输出包含机器可读的行：

```
INSTALL_REQUIRED:<dep>
```
— 必须安装后才能继续
```
INSTALL_OPTIONAL:<dep>
```
— 推荐安装，但不会阻塞流程

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

bash

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

在 Windows（PowerShell）上：

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。

Phase 2: Decompile

阶段 2：反编译

Use the decompile wrapper script to process the target file. The script supports three engines:

jadx

fernflower

, and

both

Action: Choose the engine and run the decompile script. The script handles APK, XAPK, JAR, and AAR files.

bash

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

On Windows (PowerShell):

powershell

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

For XAPK files (ZIP bundles containing multiple APKs, used by APKPure and similar stores): the script automatically extracts the archive, identifies all APK files inside (base + split APKs), and decompiles each one into a separate subdirectory. The XAPK manifest is copied to the output for reference.

Split/bundled APK detection: Some APKs are actually bundle wrappers — the outer APK contains

base.apk

plus

split_config.*.apk

files inside its resources directory. When this happens, jadx will decompile the thin wrapper and produce very few Java files. The decompile scripts automatically detect this (≤10 Java files + inner APKs present) and re-decompile

base.apk

into an

<output>/base/

subdirectory. Config-only splits (ABI, language, density) are skipped. The main decompiled source will be in

<output>/base/sources/

Options:

```
-o <dir>
```
— Custom output directory (default:
```
<filename>-decompiled
```
)
```
--deobf
```
— Enable deobfuscation (recommended for obfuscated apps)
```
--no-res
```
— Skip resources, decompile code only (faster)
```
--engine ENGINE
```
—
```
jadx
```
(default),
```
fernflower
```
, or
```
both
```

Engine selection strategy:

Situation	Engine
First pass on any APK	`jadx` (fastest, handles resources)
JAR/AAR library analysis	`fernflower` (better Java output)
jadx output has warnings/broken code	`both` (compare and pick best per class)
Complex lambdas, generics, streams	`fernflower`
Quick overview of a large APK	`jadx --no-res`

When using

--engine both

, the outputs go into

<output>/jadx/

and

<output>/fernflower/

respectively, with a comparison summary at the end showing file counts and jadx warning counts. Review classes with jadx warnings in the Fernflower output for better code.

For APK files with Fernflower, the script automatically uses dex2jar as an intermediate step. dex2jar must be installed for this to work.

See

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md

and

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md

for the full CLI references.

使用反编译包装脚本处理目标文件。脚本支持三种引擎：

jadx

、

fernflower

和

both

。

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

bash

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

在 Windows（PowerShell）上：

powershell

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

对于 XAPK 文件（包含多个 APK 的 ZIP bundle，用于 APKPure 等商店）：脚本会自动解压归档文件，识别其中的所有 APK 文件（base + split APK），并将每个 APK 分别反编译到独立子目录中。XAPK manifest 会复制到输出目录供参考。

Split/bundled APK 检测：某些 APK 实际上是 bundle wrapper，外层 APK 的 resources 目录中包含

base.apk

和

split_config.*.apk

文件。在这种情况下，jadx 只会反编译外层薄包装并生成少量 Java 文件。反编译脚本会自动检测此情况（Java 文件数 ≤10 且存在内部 APK），并将

base.apk

重新反编译到

<output>/base/

子目录中。配置类 split（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、泛型、Streams	`fernflower`
快速概览大型 APK	`jadx --no-res`

使用

--engine both

时，输出分别位于

<output>/jadx/

和

<output>/fernflower/

中，最后还会显示一份对比摘要，其中包括文件数量和 jadx 警告数量。对于存在 jadx 警告的类，应检查 Fernflower 输出中的对应代码，以获得更佳结果。

对于使用 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

。

Phase 3: Analyze Structure

阶段 3：分析结构

Navigate the decompiled output to understand the app's architecture.

Actions:

Read AndroidManifest.xml from
```
<output>/resources/AndroidManifest.xml
```
:
- Identify the main launcher Activity
- List all Activities, Services, BroadcastReceivers, ContentProviders
- Note permissions (especially
```
INTERNET
```
  ,
```
ACCESS_NETWORK_STATE
```
  )
- Find the application class (
```
android:name
```
  on
```
<application>
```
  )
Survey the package structure under
```
<output>/sources/
```
:
- Identify the main app package and sub-packages
- Distinguish app code from third-party libraries
- Look for packages named
```
api
```
  ,
```
network
```
  ,
```
data
```
  ,
```
repository
```
  ,
```
service
```
  ,
```
retrofit
```
  ,
```
http
```
  — these are where API calls live
Read every
BuildConfig.java
— these are almost never obfuscated and frequently leak the highest-signal constants in the entire APK (base URLs, flavor names, build type, third-party API keys, feature flags):
bash
```
find <output>/sources -name BuildConfig.java -exec grep -H '=' {} \;
```
Each Gradle module emits its own
```
BuildConfig
```
, so expect 1–N hits. Read all of them.
Identify the architecture pattern:
- MVP: look for
```
Presenter
```
  classes
- MVVM: look for
```
ViewModel
```
  classes and
```
LiveData
```
  /
```
StateFlow
```
- Clean Architecture: look for
```
domain
```
  ,
```
data
```
  ,
```
presentation
```
  packages
- This informs where to look for network calls in the next phases

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

操作：

从
```
<output>/resources/AndroidManifest.xml
```
读取 AndroidManifest.xml：
- 识别主 launcher Activity
- 列出所有 Activity、Service、BroadcastReceiver 和 ContentProvider
- 记录权限（尤其是
```
INTERNET
```
  、
```
ACCESS_NETWORK_STATE
```
  ）
- 查找 application 类（
```
<application>
```
  上的
```
android:name
```
  ）
浏览
```
<output>/sources/
```
下的包结构：
- 识别主应用包及其子包
- 区分应用代码与第三方库
- 查找名为
```
api
```
  、
```
network
```
  、
```
data
```
  、
```
repository
```
  、
```
service
```
  、
```
retrofit
```
  、
```
http
```
  的包——API 调用通常位于这些位置
读取每个
BuildConfig.java
——这些文件几乎从不被混淆，而且经常泄露整个 APK 中信噪比最高的常量（基础 URL、flavor 名称、构建类型、第三方 API 密钥、功能开关）：
bash
```
find <output>/sources -name BuildConfig.java -exec grep -H '=' {} \;
```
每个 Gradle module 都会生成自己的
```
BuildConfig
```
，因此预计会有 1–N 条匹配结果。请全部读取。
识别架构模式：
- MVP：查找
```
Presenter
```
  类
- MVVM：查找
```
ViewModel
```
  类以及
```
LiveData
```
  /
```
StateFlow
```
- Clean Architecture：查找
```
domain
```
  、
```
data
```
  、
```
presentation
```
  包
- 这将决定后续阶段应到哪里寻找网络调用

Phase 3.5: Recover Kotlin Class Names (only for obfuscated Kotlin apps)

阶段 3.5：恢复 Kotlin 类名（仅适用于混淆的 Kotlin 应用）

If Phase 0 reported moderate / high obfuscation and the app is Kotlin (Compose / kotlin_module markers detected), run the metadata recovery script before tracing call flows. R8 obfuscates JVM symbols but cannot strip Kotlin metadata strings, so original FQNs leak through

@DebugMetadata

and

@Metadata.d2

bash

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

Then use the lookup helper instead of plain grep — every hit comes annotated with the owning class's real name:

bash

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

Typical recovery on a real-world Kotlin app: ~100% of

*Repository

*ViewModel

*UseCase

*Impl

classes, ~80% of DTOs.

See

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/kotlin-name-recovery.md

for the full technique and limitations.

如果阶段 0 报告为中度或高度混淆，且应用是 Kotlin（检测到 Compose / kotlin_module 标记），请在追踪调用流之前运行元数据恢复脚本。R8 会混淆 JVM 符号，但无法剥离 Kotlin 元数据字符串，因此原始 FQN 会通过

@DebugMetadata

和

@Metadata.d2

泄露。

bash

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

然后使用查找辅助脚本，而不是直接使用 grep——每次命中都会附带所属类的真实名称：

bash

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: Trace Call Flows

阶段 4：追踪调用流

Follow execution paths from user-facing entry points down to network calls.

Actions:

Start from entry points: Read the main Activity or Application class identified in Phase 3.
Follow the initialization chain: Application.onCreate() often sets up the HTTP client, base URL, and DI framework. Read this first.
Trace user actions: From an Activity, follow:
- ```
onCreate()
```
  → view setup → click listeners
- Click handler → ViewModel/Presenter method
- ViewModel → Repository → API service interface
- API service → actual HTTP call
Map DI bindings (if Dagger/Hilt is used): Find
```
@Module
```
classes to understand which implementations are provided for which interfaces.
Handle obfuscated code: When class names are mangled, use string literals and library API calls as anchors. Retrofit annotations and URL strings are never obfuscated.

See

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md

for detailed techniques and grep commands.

从面向用户的入口点一路跟踪到网络调用。

操作：

从入口点开始：读取阶段 3 中识别出的主 Activity 或 Application 类。
跟踪初始化链：Application.onCreate() 通常会初始化 HTTP client、base URL 和 DI 框架。请先阅读此部分。
追踪用户操作：从 Activity 开始，依次跟踪：
- ```
onCreate()
```
  → 视图初始化 → 点击监听器
- 点击处理器 → ViewModel/Presenter 方法
- ViewModel → Repository → API service 接口
- API service → 实际 HTTP 调用
映射 DI 绑定（如果使用 Dagger/Hilt）：查找
```
@Module
```
类，以了解哪些接口由哪些实现提供。
处理混淆代码：当类名被修改时，请使用字符串字面量和库 API 调用作为定位锚点。Retrofit 注解和 URL 字符串不会被混淆。

有关详细技术和 grep 命令，请参阅

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md

。

Phase 5: Extract and Document APIs

阶段 5：提取并记录 API

Find all API endpoints and produce structured documentation.

Action: Run the API search script for a broad sweep.

bash

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

On Windows (PowerShell):

powershell

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

Targeted searches:

bash

undefined

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

操作：运行 API 搜索脚本进行广泛扫描。

bash

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

在 Windows（PowerShell）上：

powershell

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

定向搜索：

bash

undefined

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


On Windows (PowerShell):
```powershell

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


在 Windows（PowerShell）上：
```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/ -Auth


Document the endpoints in **two tiers** — going deep on every endpoint is
prohibitively expensive on apps with 100+ paths, and most of them do not
warrant it. Always produce Tier 1; expand Tier 2 only for the endpoints
that matter.

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


以两个层级记录端点——对于包含 100 多个路径的应用，逐个深入分析每个端点的成本高得难以接受，而且大多数端点都不值得深入。始终生成 Tier 1；仅对重要端点扩展 Tier 2。

Tier 1 — flat inventory (always)

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

A single table covering every discovered endpoint. Aim for one line each; if you cannot determine a column, write

Host	Method	Path	Auth	Source file
`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`

This table answers "what does the backend look like" in one screen and takes ~5 minutes to produce from the

--paths

output even on a large app.

使用单个表格覆盖所有发现的端点。尽量每行记录一个端点；如果无法确定某列的内容，请填写

。

主机	方法	路径	认证	源文件
`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`

该表格可以在一屏内回答“后端整体是什么样”，即使对于大型应用，也只需约 5 分钟便可根据

--paths

输出生成。

Tier 2 — per-endpoint detail (only for high-value endpoints)

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

Reserve the detailed format for the few endpoints that actually need it:

the entire authentication flow (login, refresh, logout, OTP/SMS, anonymous, registration)
payment / checkout / order-creation endpoints
anything the user explicitly asked about
anything that looked unusual during the scan (custom signing, undocumented headers, etc.)

markdown

undefined

仅将详细格式用于少数真正需要它的端点：

完整的身份验证流程（登录、刷新、登出、OTP/短信、匿名访问、注册）
支付 / 结账 / 创建订单端点
用户明确要求分析的端点
扫描过程中看起来不寻常的内容（自定义签名、未记录的 header 等）

markdown

undefined

METHOD /path

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


As a default, do not produce Tier 2 entries for more than ~10 endpoints
unless the user explicitly asks for more — Tier 1 plus a Tier 2 deep dive
on auth + 1-2 key flows is what most consumers of this work actually want.

See `${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md` for library-specific search patterns and the full documentation template.

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


默认情况下，除非用户明确要求，否则不要为超过约 10 个端点生成 Tier 2 条目——对于大多数使用者而言，Tier 1，加上对身份验证和 1–2 个关键流程的 Tier 2 深入分析，已经能够满足需求。

有关各类库的搜索模式和完整文档模板，请参阅 `${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md`。

Output

输出

At the end of the workflow, deliver:

Decompiled source in the output directory
Architecture summary — app structure, main packages, pattern used
API documentation — all discovered endpoints in the format above
Call flow map — key paths from UI to network (especially authentication and main features)

在工作流结束时，交付：

输出目录中的反编译源代码
架构摘要——应用结构、主要包、所用模式
API 文档——按上述格式记录所有发现的端点
调用流映射——从 UI 到网络的关键路径（尤其是身份验证和主要功能）

References

参考资料

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md

— Installing Java, jadx, Fernflower/Vineflower, dex2jar, and optional tools

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md

— jadx CLI options and workflows

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md

— Fernflower/Vineflower CLI options, when to use, APK workflow

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md

— Library-specific search patterns and documentation template

${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md

— Techniques for tracing call flows in decompiled code

${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

— 在反编译代码中追踪调用流的技术