android-reverse-engineering

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

jadx と Fernflower/Vineflower を使用して Android の APK、XAPK、JAR、AAR ファイルを逆コンパイルし、アプリケーションコードやライブラリ内の呼び出しフローを追跡して、抽出した API の構造化ドキュメントを作成します。静的トリアージの結果、必要と判断された場合にのみ、ランタイム解析に進みます。逆コンパイラーエンジンは 2 種類に対応しています。幅広い Android に対応する jadx と、複雑な Java コードをより高品質に出力する Fernflower/Vineflower です。

基本原則

いきなり Frida、パケットキャプチャ、SO 解析に進まないでください。まず JADX を使って、次の点を特定します。

• 使用されているネットワークスタック
• リクエストビルダーまたはインターセプターチェーン
• 署名または暗号化が行われている箇所
• ロジックが Java で確認できるか、ネイティブコードに委譲されているか

動的解析は、静的解析で解決できない点を確認または補完する場合にのみ使用します。

IDA MCP を提案する場合

IDA MCP は .so ファイルの静的バイナリ解析（逆アセンブル、逆コンパイル、クロスリファレンス）を行います。むやみに提案しないでください。まず、次の条件を確認します。

ユーザーが次のことを依頼した場合は、IDA MCP を提案してください。

• 特定の SO の関数オフセットまたはエクスポートを見つける
• 既知のネイティブ関数を C の疑似コードに逆コンパイルする
• 文字列、シンボル、アドレスへのクロスリファレンスを追跡する
• SO が暗号化またはネットワーク関連ライブラリをインポートしているか確認する
• 難読化されていない SO（標準的なコンパイラーでコンパイルされ、関数境界を識別できるもの）を解析する

次の場合は、IDA MCP を提案しないでください。

• SO が制御フローの平坦化など、同様に強力な難読化を使用している場合。疑似コードが判読不能になります。代わりに Frida スクリプトを使用してください。
• SO 内のすべての文字列が暗号化されている場合。静的検索では何も見つかりません。実行時の復号を取得するには jni_method_trace.js を使用してください。
• ユーザーがランタイム値（キー、トークン、パラメーター、復号済みデータ）を必要としている場合。IDA で確認できるのは静的コードのみです。
• 対象の SO がまだ特定されていない場合。まず jni_method_trace.js を提案し、どの SO がそのロジックを処理しているかを特定してください。
• ユーザーが署名、暗号文、トークンを計算または生成する必要がある場合。静的解析ではなく、ランタイム実行が必要です。

提案する前の簡易チェック： SO に対して survey_binary を使用します。出力に多数の小さな関数ではなく、巨大な関数（各 10 KB 超）が少数しか表示されない場合、バイナリは難読化されています。IDA は使わず、Frida を提案してください。

前提条件

このスキルを利用するには、Java JDK 17 以降とjadxがインストールされている必要があります。Fernflower/Vineflower、dex2jar、rizinは任意ですが、逆コンパイルの品質向上とネイティブ .so の解析のために推奨されます。依存関係チェッカーを実行して確認してください。

bash skills/android-reverse-engineering/scripts/check-deps.sh

Windows の場合（PowerShell）：

& "skills/android-reverse-engineering/scripts/check-deps.ps1"

不足しているものがある場合は、skills/android-reverse-engineering/references/setup-guide.md のインストール手順に従ってください。

ワークフロー

フェーズ 1：依存関係の確認とインストール

逆コンパイルを始める前に、必要なツールが利用可能であることを確認し、不足しているツールがあればインストールします。

操作：依存関係のチェック スクリプトを実行します。

bash skills/android-reverse-engineering/scripts/check-deps.sh

Windows の場合（PowerShell）：

& "skills/android-reverse-engineering/scripts/check-deps.ps1"

出力には、機械で読み取り可能な次の行が含まれます。

• INSTALL_REQUIRED:<dep> — 続行する前にインストールする必要があります
• INSTALL_OPTIONAL:<dep> — 推奨されますが、必須ではありません

必須の依存関係が不足している場合（終了コード 1）、自動的にインストールします。

bash skills/android-reverse-engineering/scripts/install-dep.sh <dep>

Windows の場合（PowerShell）：

& "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\ へのダウンロードに切り替えます
• check-deps.ps1 と decompile.ps1 はユーザー環境から PATH を更新するため、新しくインストールしたツールは通常、ターミナルを再起動しなくても見つかります

オプションの依存関係については、インストールするかユーザーに確認してください。最良の結果を得るには Vineflower と dex2jar を推奨します。JNI または .so の調査が見込まれる場合は、Rizin を推奨します。

インストール後、check-deps.sh を再実行して、すべての依存関係が揃っていることを確認します。必須の依存関係がすべて OK になるまで、フェーズ 2 に進まないでください。

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

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

操作：エンジンを選択し、デコンパイルスクリプトを実行します。このスクリプトは、APK、XAPK、JAR、AAR ファイルを処理します。

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

Windows（PowerShell）の場合：

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

XAPK ファイル（APKPure などのストアで使用されている、複数の APK を含む ZIP バンドル）の場合：スクリプトはアーカイブを自動的に展開し、内部のすべての APK ファイル（ベース APK と分割 APK）を識別して、それぞれを別のサブディレクトリにデコンパイルします。XAPK マニフェストは参照用に出力先へコピーされます。

分割 APK／バンドル APK のラッパーの場合：外側の APK から生成される Java ファイルが非常に少なく、そのリソース内に base.apk と split_config.*.apk ファイルが含まれている場合、デコンパイルスクリプトは外側の APK が単なる薄いラッパーであることを自動的に検出し、base.apk を <output>/base/ に再デコンパイルし、設定のみの分割 APK はスキップして、実際のソースの場所を報告します。

オプション：

• -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
Frida／JNI／unidbg／実行時のクラス名が必要	--deobf を付けずに jadx
難読化の強いコードの読みやすさだけが必要	jadx --deobf

--engine both を使うと、出力はそれぞれ <output>/jadx/ と <output>/fernflower/ に保存され、最後にファイル数と jadx の警告数を示す比較サマリーが表示されます。jadx で警告が出たクラスについては、より良いコードを得るために Fernflower の出力を確認してください。

Fernflower で APK ファイルを処理する場合、スクリプトは中間処理として dex2jar を自動的に使用します。これを使用するには dex2jar がインストールされている必要があります。

CLI の詳細については、skills/android-reverse-engineering/references/jadx-usage.md と 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. アーキテクチャのパターンを特定します：

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

フェーズ 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 文字列は難読化されません。

6. フックやエミュレーションにはランタイムで有効な名前を優先する：次の手順で Frida、JNI FindClass、unidbg、またはランタイムのクラス読み込みを扱う可能性がある場合は、まず --deobf を指定せずに jadx を実行します。--deobf が生成する読みやすいエイリアスはソースの追跡には役立ちますが、ランタイムに存在するとは限りません。

詳細な手法と grep コマンドについては、skills/android-reverse-engineering/references/call-flow-analysis.md を参照してください。

フェーズ 5：API を抽出して文書化する

すべての API エンドポイントを見つけ、構造化されたドキュメントを作成します。

アクション：API 検索スクリプトを実行して、広範囲に検索します。

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

Windows の場合（PowerShell）：

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

対象を絞った検索：

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

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

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

Windows の場合（PowerShell）：

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

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

# Only auth patterns
& "skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Auth

次に、見つかった各エンドポイントについて、周辺のソースコードを読み、次の情報を抽出します。

• HTTP メソッドとパス
• ベース URL
• パスパラメーター、クエリパラメーター、リクエストボディ
• ヘッダー（特に認証関連）
• レスポンスタイプ
• 呼び出し元（フェーズ 4 の呼び出しチェーン）

次の形式を使って、各エンドポイントを文書化します。

### `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`

ライブラリ固有の検索パターンとドキュメントテンプレート全体については、skills/android-reverse-engineering/references/api-extraction-patterns.md を参照してください。

フェーズ 6：動的解析

静的解析では不十分な場合、またはユーザーから Frida フック、パケットキャプチャ、SSL ピンニングの調査、署名の追跡などのランタイム作業を明示的に求められた場合にのみ、このフェーズを使用します。

よくある追加調査のケース：

• リクエストパラメーターが間接的に組み立てられており、静的解析では再構築が難しい
• Java コードが署名、トークン生成、暗号化のために native メソッドを呼び出している
• アプリがカスタムのネットワークスタックを使用しており、静的検索では最終的なリクエストが見つからない
• コードパスだけでなく、ランタイムの値を示す証拠が必要

推奨される順序：

1. 最終的な送信リクエストに最も近い Java のリクエストビルダー、インターセプター、コールバック、またはリクエストオブジェクトにフックを設定する
2. リクエスト URL、ヘッダー、ボディ、および署名関連の入力値と出力値を調べる
3. その後で初めて、SSL ピンニングのバイパスやネイティブ解析が必要かどうかを判断する

次を参照してください。

• skills/android-reverse-engineering/references/dynamic-analysis.md
• skills/android-reverse-engineering/references/native-analysis.md

フェーズ 7：ネイティブコードと署名の分析

署名または暗号処理が JNI や .so コードに委譲されている場合：

1. 逆コンパイルした Java で native 宣言を探します
2. 対応する System.loadLibrary 呼び出しを探し、対象の SO を特定します
3. SO が静的 JNI エクスポートと動的登録のどちらを使用しているかを判断します
4. 詳細なリバースエンジニアリングに取りかかる前に、ランタイムフックで関数の入力と出力を確認することを優先します
5. ユーザーがオフラインでの再現やアルゴリズムの詳細な解析を明示的に必要としている場合に限り、unidbg または追加の RE を使用します

次の点を明らかにすることに重点を置きます。

• 署名は Java とネイティブコードのどちらで生成されますか？
• 署名関数への正確な入力は何ですか？
• タイムスタンプ、Cookie、デバイス ID、リクエスト本文などの実行時の値と、どの入力が安定した定数ですか？
• アプリを呼び出してアルゴリズムを再現できますか？ それとも再実装が必要ですか？

.so 分析で推奨する CLI：

• 利用可能な場合は、まず rizin / rz-bin を使用します
• rizin を利用できない場合は、readelf、nm、objdump、strings に切り替えます

推奨する .so コマンド一式：

# Basic file identity
file libfoo.so

# ELF metadata, imports/exports, sections
rz-bin -I libfoo.so
rz-bin -s libfoo.so
rz-bin -i libfoo.so
rz-bin -E libfoo.so

# Fast string triage
rz-strings -a libfoo.so | rg 'http|https|Java_|JNI_OnLoad|RegisterNatives|encrypt|sign|ssl|socket'

# Function list and disassembly
rizin -qc "aaa; afl; q" libfoo.so
rizin -qc "aaa; pdf @ sym.JNI_OnLoad; q" libfoo.so
rizin -qc "aaa; pdr @ sym.JNI_OnLoad; q" libfoo.so

rizin を使わない場合の代替手段：

readelf -d libfoo.so
readelf -Ws libfoo.so
nm -D libfoo.so | rg 'Java_|JNI_OnLoad|RegisterNatives'
objdump -T libfoo.so
objdump -d libfoo.so > libfoo.objdump.asm
strings -a libfoo.so | rg 'http|https|Java_|JNI_OnLoad|RegisterNatives|encrypt|sign|ssl|socket'

標準の .so ワークフロー：

1. file と rz-bin -I でアーキテクチャとリンク済みライブラリを特定します
2. エクスポート／インポートを確認し、JNI_OnLoad、Java_*、暗号化 API やソケット API を探します
3. 文字列を検索し、URL、ホスト名、ログタグ、登録に関する手掛かりを探します
4. まず JNI_OnLoad を調べ、次に RegisterNatives の対象を探します
5. Java 側の呼び出し経路が判明してから、関数の詳細なリバースエンジニアリングを行います

出力

ワークフローの最後に、以下を提出します。

1. 逆コンパイル済みソース（出力ディレクトリ内）
2. アーキテクチャの概要 — アプリの構造、主要パッケージ、使用されているパターン
3. API ドキュメント — 上記の形式で、発見したすべてのエンドポイントを記載します
4. 呼び出しフローマップ — UI からネットワークまでの主要な経路（特に認証と主要機能）
5. ランタイムでの発見事項 — 該当する場合、フックポイント、観測したリクエストフィールド、およびそのポイントを選んだ理由
6. 署名の評価 — 署名が Java ベースか、ネイティブコードに依存するか、対象のリクエストに不要かを示します

参考資料

• skills/android-reverse-engineering/references/setup-guide.md — Java、jadx、Fernflower/Vineflower、dex2jar、およびオプションのツールのインストール
• skills/android-reverse-engineering/references/jadx-usage.md — jadx CLI のオプションとワークフロー
• skills/android-reverse-engineering/references/fernflower-usage.md — Fernflower/Vineflower CLI のオプション、使用する場面、APK のワークフロー
• skills/android-reverse-engineering/references/api-extraction-patterns.md — ライブラリ固有の検索パターンとドキュメントのテンプレート
• skills/android-reverse-engineering/references/call-flow-analysis.md — 逆コンパイルしたコードで呼び出しフローを追跡する手法
• skills/android-reverse-engineering/references/dynamic-analysis.md — Frida、実行時のリクエストインターセプト、SSL ピンニングのトリアージ、パケットキャプチャのワークフロー
• skills/android-reverse-engineering/references/native-analysis.md — JNI／SO の調査、ネイティブ署名の分析、unidbg を使った追加調査が必要な場合