mobile-security

モバイルセキュリティ

対象範囲

Android（APK/AAB）およびiOS（IPA）を対象に、OWASP MASVS v2.xのコントロールグループとMASTGのテストプロセスに沿って、モバイルアプリケーションのエンドツーエンドのVAPTを実施します。相互に補完する4つのティアで構成されます。

1. 静的リバースエンジニアリング — コンパイル済み成果物を対象にします。Dart AOTスナップショット、Unity IL2CPP、React Native/Hermesのバイトコード、ネイティブARM64の.so/Mach-O、smaliを解析します。デバイスを使わずに、シークレット、エンドポイント、暗号化の仕様を特定します。
2. SAST — マニフェスト／Info.plist、エクスポートされたコンポーネントとIPCの攻撃対象面、WebView、ローカルストレージ、暗号プリミティブの弱点、コード署名、自動ベースライン（MobSF/apkid/apkleaks）を調査し、その後に手動で詳細分析します。
3. 動的解析（DAST） — Frida/objectionによるインストゥルメンテーション、トラフィックの傍受、各スタックでのTLSピンニングのバイパス、Keychain/Keystoreの実行時ダンプ、IPCのプロービング、およびMAS-L2 / MASAの対象範囲におけるroot／脱獄／改ざん防止の回避を行います。
4. プライバシー — データ収集のインベントリ、トラッカー／SDKの列挙、PIIの漏えい、申告内容と実態の照合（Play Data Safety / Apple Privacy Manifest）を行います。

まずは静的ダンプを実施します（高速で、デバイスも不要です）。実行時にしか証明できないコントロール（強制されるピンニング、Keystoreに格納された鍵、rootへの反応、IPCガード）がある場合は、動的解析を正式なフェーズとして実施します。アセットをまたぐ関連付け、スコアリング、レポート作成は関連スキルが担当します。このスキルではMASVS/MASTGタグ付きの検出事項を作成し、引き継ぎます。

カバレッジの要件

カバレッジモードのエンゲージメント（pentest-engagementのモバイルモード）では、完了は文章ではなくコードによって強制されます。ゲート対象のサーフェスは2つあり、どちらも必須です。

サーフェス	ファイル	クラス
アプリバンドル	recon/inventory/mobile-surface.json	15個のMAS-* MASVSクラス
バンドルから復元したバックエンド	<apex>-api/recon/inventory/surface.json	通常のOWASP API/Webクラス

これまで重大なリスクが潜んでいたのは2行目です。逆コンパイルしたバンドルからサーバーの仕様全体を把握できます。また、そのサーフェスはブラウザーから到達できないため、アプリ開発者自身も含め、誰もが体系的にテストを見落としています。エンドポイントのインベントリを復元し、APIクラスに沿ってテストすることは、任意の追加作業ではありません。エンドポイントが1つも見つからないバンドルは、取得失敗として扱います。

クラスごとの詳細は、reference/masvs-class-map.mdを参照してください。否定的な結果を記録する前に、次の2つのルールをよく理解してください。

• proof_mode: runtimeは静的解析ではクローズできません。 ピンニングとroot検出は典型的な落とし穴です。静的解析でコントロールが機能していないことは証明できます（構築されているもののアタッチされていないCertificatePinner、DEXから参照されていないRootBeerなど）。これは肯定的な検出事項として挙げてください。一方、コントロールが有効であることは静的解析では決して証明できません。そのためにはバイパスを試みて失敗する必要があり、バイパスに失敗したことは、報告対象として正当な結果です。
• proof_mode: staticは、デバイスを使わないことを理由に先送りできません。 デバイスがなくても、マニフェスト、署名、バンドルされた依存関係、成果物内のシークレットの確認は免除されません。

使用する場面

• 対象が Android APK/AAB または iOS IPA を配布している場合。ランタイムテストの前に抽出して調査します。
• Flutter（lib/arm64-v8a/libapp.so／iOS の App.framework）、Unity（libil2cpp.so + global-metadata.dat）、または React Native + Hermes（libhermes.so + index.android.bundle）で構築されている場合。jadx だけでなく、ランタイムを考慮した逆コンパイラーが必要です。
• 標準的な Android/iOS アプリの場合。マニフェスト／IPC／ストレージ／暗号化／署名の攻撃対象領域（SAST）を調査し、ランタイムでのみ有効になる制御については動的に確認します。
• アプリが 暗号化された API エンベロープ（KEY/IV/SALT/SIGNATURE ヘッダー）を使用しており、暗号化の仕様をリバースエンジニアリングして、実稼働 API にリプレイする必要がある場合。
• TLS ピンニング／root／脱獄検知によってテストが妨げられる場合。動的に回避する（または静的に無効化する）ことで、保護されたフローを実証します。
• クライアントをダンプしたほうが見つけやすく、その後サーバー側で確認できる IDOR／マスアサインメント／ビジネスロジックの欠陥が疑われる場合。
• MASVS-PRIVACY の検査（トラッカー、過剰なデータ収集、PII 漏えい、宣言内容と実際の挙動の差異）が必要な場合。

方法論

まず reference/methodology.md を確認してください。フェーズの骨格（ACQUIRE → TRIAGE → STATIC → DYNAMIC → NETWORK → STORAGE → PLATFORM/IPC → BACKEND PIVOT → REPORT）、アプリの取得と証拠の完全性、MASVS とファイルの対応マップ、検出事項のタグ付け規則、クライアントから API へのピボットについて説明しています。ここから、以下のすべてのリファレンスに移動できます。最初に事前確認（../coordination/reference/preflight-checklist.md）を実施してください。

リファレンス

横断的な項目

• reference/methodology.md — ハブ：フェーズ、取得（adb pull / bundletool / ipatool）、MASVS/MASTG のタグ付け、バックエンドへのピボット。
• reference/privacy-testing.md — 両プラットフォームの MASVS-PRIVACY：トラッカー／SDK、PII の経路、宣言内容と実際の挙動の差異。

Android

• reference/android-static-analysis.md — SAST：MobSF/apkid/apkleaks の基本調査、マニフェストとエクスポートされたコンポーネント／IPC、ContentProvider の SQLi／パストラバーサル、PendingIntent、ディープリンク、ネイティブ WebView の RCE、ストレージと Keystore のレビュー、暗号プリミティブの弱点確認、NSC、apksigner/Janus、SBOM。
• reference/android-dynamic-analysis.md — DAST：デバイス／Magisk/Zygisk のセットアップ、frida-server の起動、objection のレシピ、Android 7 のユーザー CA 回避策を含むインターセプト、スタックを横断するピンニング回避（OkHttp/BoringSSL-Flutter/RN）、drozer IPC、ランタイムストレージ、RESILIENCE のアクティブな回避と再パッケージ／再署名。

iOS

• reference/ios-static-analysis.md — SAST：IPA の取得と FairPlay の復号（cryptid）、Mach-O/ObjC/Swift のリバースエンジニアリング、ATS、エンタイトルメント／プロビジョニング、バイナリの堅牢化、Keychain のアクセシビリティと Data Protection、URL スキーム／Universal Links、WKWebView、ペーストボード／スナップショット、MobSF/SBOM。
• reference/ios-dynamic-analysis.md — DAST：脱獄済み環境と非脱獄環境（objection patchipa / frida-gadget）のセットアップ、iOS での objection/Frida、SSL Kill Switch / SecTrust のピンニング回避、Keychain のダンプ、LAContext の生体認証回避、脱獄検知／アンチデバッグの無効化、メソッドトレース。

フレームワーク固有のリバースエンジニアリング

• reference/flutter-aot-reversing.md — blutter を使用した Flutter/Dart AOT。HTTP 暗号化エンベロープのパターン（fast_rsa OAEP-SHA256 + AES-256-CBC）と、報告すべき弱点。
• reference/scenarios/android/react-native-hermes.md — RN+Hermes：HBC バージョンの確認、hermes-dec による index.android.bundle の逆コンパイル、BuildConfig シークレットの最短経路、RN 固有の MASVS 攻撃対象領域。
• reference/scenarios/android/native-lib-host-extraction.md — Bionic→glibc フォワーダーと strcmp/memcmp インターセプターを使用した、ホスト側での Android .so の dlopen（Frida／エミュレーター不要）。 複数スキルで再利用する機能（重複させず、相互リンクで共有）
• ../reverse-engineering/reference/scenarios/static-analysis/unity-il2cpp-recipe.md — Unity の libil2cpp.so と global-metadata.dat のダンプ（Il2CppDumper／Il2CppInspector）。
• ../reverse-engineering/reference/scenarios/dynamic-analysis/frida-hooking.md — 両方の動的解析ファイルで使用する Frida フッキングの基本要素（spawn／attach、Interceptor、Stalker、Java.perform、ObjC フック）。
• ../reverse-engineering/reference/scenarios/obfuscation/packed-binaries.md — 難読化された APK／.so を対象とするパッカー／解析回避処理のアンパック。
• ../reverse-engineering/reference/scenarios/obfuscation/hash-dispatcher-chain.md — ネイティブ .so 内の多項式ハッシュを使ったディスパッチャーチェーンを Z3 で解析。
• ../api-security/reference/scenarios/rest/owasp-bola-bopla.md · ../api-security/reference/scenarios/rest/mass-assignment.md — クライアントから API へのピボットによって、クライアントから復元したエンドポイント／IDOR を調査します。

決定論的な制御配線検出ツール

• ../../tools/apk_control_wiring.py — 逆コンパイルした Android ツリーを静的に相互参照し、実際に適用されている制御と孤立した制御を区別します。RootBeer／SafetyNet／Play-Integrity が組み込まれているものの配線されていない状態（参照されているが、結果によって何も制御されない）、CertificatePinner が構築されているものの OkHttpClient にアタッチされていない状態、ハードコードされた AES／DES 鍵リテラルとその呼び出し箇所、バンドルされているものの一度も読み込まれない .so を検出します。修正に関する判定を作成する前に、静的解析フェーズで実行してください。制御の存在だけを grep する単純な再テストでは、機能していない制御を誤って「修正済み」と報告します（モバイルの再テストで繰り返し問題になる点です）。

アンチパターン

• 静的ダンプを作成する前に Frida／エミュレーターに手を伸ばすこと。静的解析を先に行うほうが速く、デバイスも不要です。ただし、動的解析を対象外として扱わないでください。ピンニングの強制、Keystore とのバインド、root への反応、IPC の到達可能性は実行時にしか確認できません。
• アクティブなバイパス試行をせずに、制御（root／ピンニング／改ざん検出）を「存在する」と報告すること。MAS-L2／MASA では、制御を突破するか、突破できないことを立証する必要があります。
• network_security_config.xml が空であることから「ピンニングなし」と結論づけたり、cryptid 1 の iOS バイナリから「シークレットなし」と結論づけたりすること。JS／ネイティブのピンニングレイヤーを確認し、まず IPA を復号してください。
• クライアント側の IDOR の調査で止めること。これはサーバー側の仮説であり、API セキュリティへのピボットを通じて確認してください。
• ライブラリが存在するというだけで CVE を報告すること。正確なバージョンと、到達可能なコードパスの両方を確認してください。