android-reverse-engineering

Android リバースエンジニアリング

jadx と Fernflower/Vineflower を使用して Android の APK、XAPK、JAR、AAR ファイルを逆コンパイルし、アプリケーションのコードやライブラリ内の呼び出しフローを追跡して、抽出した API の構造化ドキュメントを作成します。2 つの逆コンパイルエンジンに対応しています。幅広い Android アプリを扱える jadx と、複雑な Java コードをより高品質に出力する Fernflower を、比較のために併用することもできます。

前提条件

このスキルを使用するには、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>

次の情報が 1 画面に表示されます。

• モバイルフレームワーク（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 とすべての分割 APK を対象に統合したネイティブライブラリの一覧。XAPK の分割バンドルでは、.so ファイルが base.apk ではなく config.<abi>.apk に含まれることがよくあります。
• フレームワークに応じて異なる推奨される次の手順（たとえば Flutter の場合、スクリプトは jadx ではなく blutter / strings libapp.so を提案します）。

フィンガープリントで Flutter / RN / Cordova / Xamarin と判定された場合は、作業を中断し、フレームワークに適したツールに切り替えてください。以下のフェーズ 1～5 は、ネイティブ（Java/Kotlin）の Android アプリを対象としています。

フェーズ 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>

インストールスクリプトは OS とパッケージマネージャーを検出して、次の処理を行います。

• 可能な場合は 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 を再実行します。必須の依存関係がすべて OK になるまで、フェーズ 2 に進まないでください。

フェーズ 2：逆コンパイル

逆コンパイル用ラッパースクリプトを使用して、対象ファイルを処理します。スクリプトは jadx、fernflower、both の 3 つのエンジンに対応しています。

操作：エンジンを選択し、逆コンパイルスクリプトを実行します。スクリプトは 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 ファイル（APKPure などのストアで使用される、複数の APK を含む ZIP バンドル）の場合：スクリプトはアーカイブを自動的に展開し、内部のすべての APK ファイル（ベース APK と分割 APK）を特定して、それぞれを個別のサブディレクトリに逆コンパイルします。参照用に、XAPK のマニフェストも出力先にコピーされます。

分割 APK／バンドル APK の検出：一部の APK は実際にはバンドルラッパーです。外側の APK のリソースディレクトリ内に base.apk と split_config.*.apk ファイルが含まれています。この場合、jadx は薄いラッパーを逆コンパイルするため、Java ファイルがごくわずかしか生成されません。逆コンパイルスクリプトはこれを自動検出し（Java ファイルが 10 個以下で、内部 APK が存在する場合）、base.apk を <output>/base/ サブディレクトリに再度逆コンパイルします。設定のみの分割 APK（ABI、言語、密度）はスキップされます。メインの逆コンパイル済みソースは <output>/base/sources/ にあります。

オプション：

• -o <dir> — 出力ディレクトリを指定します（デフォルト：<filename>-decompiled）
• --deobf — 難読化解除を有効にします（難読化されたアプリで推奨）
• --no-res — リソースをスキップし、コードのみを逆コンパイルします（高速）
• --engine ENGINE — jadx（デフォルト）、fernflower、または both

エンジンの選択方法：

状況	エンジン
任意の APK の初回解析	jadx（最速で、リソースも処理します）
JAR／AAR ライブラリの解析	fernflower（より良い Java 出力）
jadx の出力に警告やコードの破損がある	both（比較し、クラスごとに最適なものを選択します）
複雑なラムダ式、ジェネリクス、ストリーム	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 を参照してください。

フェーズ 3：構造を分析する

逆コンパイルした出力を確認し、アプリのアーキテクチャを把握します。

操作：

1. <output>/resources/AndroidManifest.xml の 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、フレーバー名、ビルドタイプ、サードパーティ API キー、機能フラグ）が頻繁に含まれています：

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

   Gradle の各モジュールは独自の BuildConfig を出力するため、1～N 件見つかることが予想されます。すべて読みます。

4. アーキテクチャのパターンを特定します：

   • MVP：Presenter クラスを探します
   • MVVM：ViewModel クラスと LiveData／StateFlow を探します
   • クリーンアーキテクチャ：domain、data、presentation パッケージを探します
   • これにより、次のフェーズでネットワーク呼び出しを調べる場所がわかります

フェーズ 3.5：Kotlin のクラス名を復元する（難読化された Kotlin アプリのみ）

フェーズ 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 アプリで一般的に復元できる割合は、*Repository / *ViewModel / *UseCase / *Impl クラスが約 100％、DTO が約 80％です。

手法と制限事項の詳細については、${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/kotlin-name-recovery.md を参照してください。

フェーズ 4：呼び出しフローを追跡する

ユーザー向けのエントリーポイントからネットワーク呼び出しまで、実行パスをたどります。

作業：

1. エントリーポイントから開始する：フェーズ 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 を参照してください。

フェーズ 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

エンドポイントは2 段階で文書化します。100 個以上のパスがあるアプリでは、すべてのエンドポイントを詳細に調べるのは 非常にコストがかかり、そのほとんどに詳細な調査は必要ありません。必ず Tier 1 を作成し、Tier 2 は 重要なエンドポイントに限って追加します。

Tier 1 — 一覧（必須）

発見したすべてのエンドポイントを網羅する単一の表です。各エンドポイントを 1 行にまとめます。 列の値を特定できない場合は、? と記載します。

ホスト	メソッド	パス	認証	ソースファイル
api.example.com	GET	/v1/users/profile	Bearer	com/example/api/UserApi.java
api.example.com	POST	/v1/auth/login	なし	com/example/api/AuthApi.java

この表があれば、バックエンドの全体像を 1 画面で把握でき、大規模なアプリでも --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 — 逆コンパイルしたコードでコールフローを追跡する手法