モバイルアプリのシールディングバイパスをテストするための最適なツール
手動テスト向けのApktool、JADX、Ghidra、Frida、Objection、LLDBを、OstorlabによるAndroid・iOSのモバイルシールディングおよびRASPの自動評価と比較します。
エグゼクティブサマリー（TL;DR）
モバイルアプリのシールディングがバイパスされ得るかをテストするには、段階ごとに異なるツールが必要です。Apktoolは再パッケージ化のテストのためにAndroidパッケージをデコード、変更、再ビルドします。JADXとGhidraは保護ロジックの特定に役立ちます。Frida、Objection、LLDBは実行時にシールディングとRASPの制御に揺さぶりをかけます。そしてOstorlabはAndroidとiOSにわたる評価を自動化します。
シールディングは攻撃を検知しても、アプリを保護できないことがあります。Ostorlabによる5つの銀行アプリの評価では、あるアプリはroot化された端末上で動作していることを検知したにもかかわらず、そのままログイン画面へと進みました。保護は存在していました。問題は、その対応のほうにあったのです。
したがって、テストはroot検知、アンチデバッグ、証明書ピンニングが存在することを確認するだけでは不十分です。チームは、これらの保護に揺さぶりをかけたときにアプリがどう対応するか、そしてその対応をバイパスできるかどうかを観察する必要があります。
本ガイドでは、各ツールで何を検証できるか、必要となる専門知識、そしてその能力がどこで限界に達するかを説明します。手動のワークフローと自動評価のどちらを選ぶかを検討しているモバイルセキュリティのテスターやAppSecチームを対象としています。
本ガイドについて：本ガイドは、比較対象に含まれているOstorlabが公開しています。公式ドキュメント、オープンソースのリポジトリ、OWASPのガイダンス、公開されている技術研究に基づいています。
モバイルアプリのシールディングとRASPのテストとは
モバイルアプリのシールディングとは、解析、改変、実行時の干渉をより困難にするために、AndroidまたはiOSアプリケーションに追加される一連の保護のことです。コードの難読化、改ざん防止、整合性チェック、アンチデバッグ、アンチ計装、rootまたはジェイルブレイクの検知、証明書ピンニングなどが含まれます。
RASP（実行時アプリケーション自己保護）は、より具体的には、アプリの実行中にアプリを監視する保護を指します。RASPは疑わしい状態を検知すると、警告を表示したり、操作を制限したり、アプリを終了したりすることがあります。したがってRASPは、より広範なモバイルアプリのシールディング層の一部です。
シールディングとRASPのバイパステストは、これらの制御が想定した攻撃条件を検知するかどうか、そしてその対応を無力化または回避できるかどうかを確認するものです。保護が存在する、あるいはアラートを出すというだけでは、その保護が有効であることは実証されません。テストでは、保護が防ぐはずだった挙動をアプリが依然として許してしまうかどうかも確かめる必要があります。
モバイルアプリのシールディングテストツール一覧
以下のツールは無料かつオープンソースですが、評価全体を一つでカバーできるツールはありません。アプリの改変や保護ロジックの特定から、実行時の制御への揺さぶり、結果の検証まで、それぞれがプロセスの特定の部分を担います。
| ツール | 使う場面 | モバイルの対象範囲 | 必要な作業 | 主な制約 |
|---|---|---|---|---|
| Apktool | 再パッケージ化、署名、改ざん防止のテスト用に、改変したAPKを準備する | Android APK | マニフェスト、リソース、Smaliを調べ、管理された変更を加え、APKを再ビルドして再署名する | Androidのみ。再ビルドや署名の失敗を、アプリのシールディングによる対応と切り分ける必要がある |
| JADX | AndroidのDEXコード内で保護チェックを見つけ、その呼び出し元をたどる | AndroidのDEXバイトコード | 逆コンパイルされたコードを読み、実行時にテストすべき判定を特定する | 逆コンパイルが不完全な場合がある。ネイティブコードには別の解析ツールが必要 |
| Ghidra | ネイティブの保護ロジックをたどり、フックやパッチの適用箇所を特定する | Androidのネイティブライブラリ、iOSバイナリ | 逆アセンブル結果を解釈し、逆コンパイルされた関数を確認する | パックまたは暗号化されたコードは、解析の前に実行時の抽出が必要な場合がある |
| Frida | 独自のフックを書き、実行時にシールディングとRASPのチェックを観察または変更する | AndroidおよびiOS | プロセスへのアクセスを確立し、関数を特定し、スクリプトを調整する | スクリプトが実行される前にアンチ計装がFridaをブロックすることがある |
| Objection | 一般的なroot、ジェイルブレイク、証明書ピンニングのチェックに対して既存のバイパスルーチンを試す | AndroidおよびiOS | Fridaのアクセスを確立し、ルーチンを選択し、対応を検証する | Fridaに依存する。独自の保護には個別に調整したフックが必要な場合がある |
| LLDB | ネイティブの実行を一時停止し、チェックを追跡したり、変化する状態を調べたりする | AndroidおよびiOSのネイティブコード | デバッガーのアクセスを確立し、実行、メモリ、レジスタを解釈する | OSの権限や署名の制限により、シールディングとは無関係にアタッチできないことがある |
オープンソースツールはシールディングバイパステストにどう組み込まれるか
オープンソースによるシールディングのテストは、一つのスキャナーに頼るのではなく、複数のツールを組み合わせて行います。ApktoolはAndroidパッケージの調査、改変、再ビルドを支援します。JADXとGhidraは、テスターが保護ロジックを特定し理解するのに役立ちます。Frida、Objection、LLDBは実行時に使われ、それらの保護に揺さぶりをかけて結果を観察します。
このプロセスは必ずしも直線的ではありません。実行時のテストで何かが判明し、テスターがさらなる解析のためにコードへ戻ることもあります。
Apktool：改ざんテストのためのAndroidアプリの再ビルド
Apktoolは、Androidのアプリケーションパッケージを、マニフェスト、リソース、Smaliコードを含むプロジェクトのような構造にデコードします。変更を加えた後に、パッケージを再ビルドすることもできます。
評価における役割
Apktoolは、シールディングの評価でAPKを改変して再パッケージ化する必要がある場合に役立ちます。テスターは、マニフェスト、リソース、Smaliコードに管理された変更を加え、パッケージを再ビルドしてから、整合性、署名、改ざん防止の保護が改変されたアプリを検知するかどうかを確認できます。
この役割はJADXとは異なります。JADXは解析のためにDEXコードを読みやすいJava風のコードとして表示するのに対し、Apktoolは編集と再ビルドが可能なパッケージ構造を保持します。OWASPは、Apktoolをバイナリのマニフェストのデコード、リソースの抽出、DEXファイルのSmaliへの逆アセンブル、そしてその結果の再パッケージ化を行う手段として説明しています。（OWASPのApktoolガイドを参照）
テスターに求められること
テスターは何を変更するかを決め、該当するマニフェスト、リソース、Smaliファイルを編集し、APKを再ビルドして、インストール前に署名する必要があります。結果には、失敗がどの段階で起きたか、つまりデコード、再ビルド、署名、インストールの最中か、それともアプリの起動後かを記録すべきです。
制約
ApktoolはAndroidパッケージに限られ、それ自体で実行時の保護をテストするものではありません。生成されるのは署名されていないAPKであるため、署名は別の手順になります。再ビルドしたアプリがインストールや起動に失敗しても、シールディングが改変を検知したことが自動的に実証されるわけではありません。原因は、不正なビルド、署名の問題、パッケージの非互換性である可能性もあります。また、Apktoolのドキュメントには、OEMが改変したビルドツールで作成された一部のAPKはデコードや再ビルドができないと記載されています。Apktool FAQ
何を変更するかを決める前に、より上位のAndroidの保護ロジックをたどることが目的であれば、JADXのほうが読みやすいビューを提供します。
JADX：Androidの保護ロジックの調査
JADXは、AndroidのDEXバイトコードを読みやすいJava風のコードに変換します。テスターはアプリを実行することなく、APK内を検索し、メソッド間を移動し、参照をたどることができます。
評価における役割
JADXは、rootチェック、アンチデバッグのロジック、整合性チェック、そしてアプリがどう対応するかを決めるコードの特定に役立ちます。
対応は、元のチェックとは別の場所で処理されている場合があります。あるメソッドがrootを検知し、別のメソッドが警告を表示するか、アプリを終了するか、機能を制限するかを決めるといった具合です。それらの参照をたどることで、テスターはFridaやデバッガーを使って実行時に調査すべき判断ポイントを特定できます。
テスターに求められること
JADXを使うには、Android開発とリバースエンジニアリングに精通している必要があります。クラス名や制御フローが難読化されている場合は特にそうです。
逆コンパイルされた出力は、アプリの元のソースコードではなく、バイトコードを解釈したものです。JADXはクラスやメソッドの名前を変更したりインライン化したりすることがあるため、インターフェースに表示される識別子が実行時に遭遇するものと一致しない場合があります。疑わしい出力は、基になるSmaliコードや制御フローグラフと照合すべきです。JADXのトラブルシューティングガイダンス
制約
JADXはAndroidの解析ツールであり、完全なバイパスソリューションではありません。そのSmaliデバッガーには、デバッグ可能なアプリ、またはroot化された端末やエミュレーターが必要です。ネイティブライブラリに含まれる保護ロジック、起動時まで暗号化されている保護ロジック、実行時に生成される保護ロジックにも、別のツールが必要です。
該当するロジックがAndroidのバイトコードからネイティブライブラリへと移る場合は、Ghidraで調査を続けられます。
Ghidra：ネイティブの保護コードの解析
Ghidraは、Androidの.soライブラリやiOSの実行ファイルとフレームワークを含む、コンパイル済みのネイティブコードを解析します。
評価における役割
Ghidraの逆アセンブラー、逆コンパイラー、文字列検索、関数グラフは、ネイティブの保護コードがどのように動作するかをテスターが再構築するのに役立ちます。Androidでは、JADXがネイティブライブラリへの呼び出しに行き着いたもののその内部で何が起きているかを示せない場合に、解析を引き継ぐことができます。
関数名が削除されていても、文字列、定数、関数間の参照から、保護チェックと思われる箇所、その判定の分岐、結果としてのアプリの対応が明らかになることがあります。OWASPのGhidraガイドでは、バイナリをレビューする際にこれらのビューをどう組み合わせて使うかが説明されています。
テスターに求められること
Ghidraには、JADXよりも高度なネイティブのリバースエンジニアリングのスキルが求められます。テスターは、関数シグネチャを修正し、逆コンパイルの出力をアセンブリと比較し、値がレジスタやメモリをどう移動するかを理解する必要があるかもしれません。
通常の目的は、実行時テストのためにチェックや判断ポイントと思われる箇所を特定することです。Ghidraでそれを見つけても、バイパスできることが実証されるわけではありません。
制約
パックまたは暗号化されたコードは、アプリが実行されるまで隠れたままの場合があります。Ghidraのデバッガーは実行中のプロセスをインポートしたバイナリに対応付け、実行時のメモリを調べることができますが、テスターはまずデバッグのアクセス権を取得し、該当するコードを特定する必要があります。
バイパスの疑いがある箇所はすべて、アプリの実行中に再現する必要があります。評価のこの部分には、一般的にFridaが使われます。
Frida：独自の実行時計装
Fridaは、AndroidおよびiOSのプロセスにJavaScriptを注入します。テスターは関数呼び出しを傍受し、その入力と出力を調べ、実行中のアプリの挙動を変更できます。
評価における役割
Fridaは、保護チェックとそれに対応するコードに揺さぶりをかけるために使われます。最初の検知が引き続き機能している場合でも、保護の挙動を変更できるかどうかをテストできます。
OWASPのAndroid UnCrackable L1の例では、アプリはrootを検知し、終了する前に警告を表示します。Fridaのフックが、アプリを終了させる役割を持つ関数を変更します。rootチェックは引き続き実行されますが、アプリはもはや想定された対応を実行しません。
テスターに求められること
テスターは該当する関数を特定し、JavaScriptのフックを書くか調整し、狙った挙動が実際に変わったことを検証する必要があります。独自の保護では、チェックと対応がどうつながっているかを理解するために、追加のリバースエンジニアリングが必要になる場合があります。
テスト環境も重要です。Androidのテストでは一般的にroot化された端末が使われますが、Frida Gadgetを再パッケージ化したアプリに組み込むこともできます。iOSでは、ジェイルブレイクした端末のほうが広範なアクセスを得られますが、ジェイルブレイクしていない端末でのテストはデバッグ可能なアプリに限られます。
制約
シールディングやRASPは、意図したテストが始まる前にFridaを検知またはブロックすることがあります。Ostorlabによる5つの銀行アプリの評価では、あるアプリは、Fridaスクリプトが最初のログメッセージを出力する前に、注入の最中に終了しました。このような場合、機能する計装セッションを確立すること自体が、調査の別の一部になります。
一般的なバイパス手法については、既存のFridaのルーチンをすぐに使えるコマンドにまとめたObjectionが、より手早い出発点となります。
Objection：すぐに使えるバイパス機能
ObjectionはFridaの上で動作し、一般的なモバイルテストの手法を対話型のコンソールにまとめています。
評価における役割
Objectionには、既知のrootおよびジェイルブレイクのチェックのバイパスを試みる、一般的な証明書ピンニングの実装を無効化する、ロードされたクラスを調べる、メソッド呼び出しを監視する、といったコマンドが含まれています。これにより、テスターは独自のFridaスクリプトを書く前に、確立された手法を試すことができます。
起動時に実行されるチェックには、アプリが完全に起動する前に到達する必要がある場合があります。Objectionは早期計装をサポートしており、アプリの処理が再開される際にコマンドや独自のFridaスクリプトを読み込むことができます。
テスターに求められること
テスターは、各コマンドが何を変更したか、そして評価対象の保護に実際に到達したかどうかを確認する必要があります。コマンドが正常に完了しても、それが示すのはルーチンが実行されたということだけです。保護がバイパスされたことを立証するものではありません。
Objectionは、AndroidアプリにFrida Gadgetをパッチとして適用することもできます。これはAPKを再ビルドして再署名するため、テスターは、結果として生じた失敗がバイパスの試行によるものか、整合性チェックや署名チェックによるものかを判断する必要があります。
制約
Objectionが最も効果を発揮するのは、既存のルーチンがアプリで使われている保護に合致する場合です。独自の保護ロジックがある場合や、アプリが基盤となるFridaセッションをブロックする場合には、有用性が下がります。
そのような場合、テスターには通常、コード解析と個別に調整したFridaスクリプトが必要になります。調査でネイティブの実行を1命令ずつ追う必要がある場合は、LLDBがより低レベルのビューを提供します。
LLDB：デバッガーによる保護チェックの調査
LLDBを使うと、テスターはネイティブコードを一時停止し、命令単位で進め、レジスタ、メモリ、戻り値を調べることができます。XcodeのデフォルトのデバッガーであるとともにAndroidのネイティブデバッグにも使われています。
評価における役割
テスターは、保護チェックと思われる箇所にブレークポイントを設定し、それが返す値を観察し、アプリがどう対応するかを追うことができます。LLDBは、管理されたテストの中でプロセスの状態を変更することもできます。
そのウォッチポイントは、保護の結果がどこに格納されているかはわかっているものの、どの関数がそれを更新するのかがまだわからない場合に役立ちます。
テスターに求められること
リリースビルドには、有用なシンボルがほとんど含まれていないことがよくあります。テスターは、アドレスやその他の調査結果をGhidraから持ち込み、バイナリがメモリにどうマッピングされているかを考慮する必要があるかもしれません。そのためには、アセンブリ、呼び出し規約、レジスタ、ネイティブのプログラムフローの理解が必要です。OWASPのiOSデバッグガイダンスでは、リリースビルドにおけるこれらの制約が取り上げられています。
端末へのアクセスも、LLDBが到達できる範囲に影響します。root化されていないAndroid端末では、Android Studioはデバッグ可能なプロセスにしかアタッチできません。LLDBが扱うのはネイティブ層であり、JavaやKotlinのコードではありません。iOSでは、リリース版のアプリには、適切な端末と、再署名されたビルドまたはその他の方法でデバッグ可能にしたビルドが必要になる場合があります。
制約
LLDBのアタッチに失敗しても、シールディングがデバッガーを阻止したとは限りません。オペレーティングシステムの権限、署名の要件、アプリのエンタイトルメントによって、保護に到達する前にアタッチが妨げられることがあります。
テスターは、こうしたセットアップ上の失敗を、アプリ自体がデバッグを明確に検知またはブロックしているケースと切り分ける必要があります。他の実行時ツールと同様に、デバッガーの接続に成功するのは始まりにすぎません。最終的なエビデンスは、テスト中に対象の保護がどう振る舞ったかを示すものでなければなりません。
Ostorlab：モバイルアプリのシールディングテストの自動化
OstorlabのMobile Shielding Scanは、保護の発見、バイパスの試行、検証を、AndroidとiOSを対象とした一つの評価にまとめます。テスト環境を管理し、AIエージェントを使って、保護に揺さぶりをかけたときにアプリがどう対応するかを調査します。
Ostorlabが自動化すること
評価のワークフローは、4つの段階で構成されます。
- 保護を特定する。スキャンは、root・ジェイルブレイク検知、整合性チェック、アンチデバッグ、アンチ計装、証明書ピンニング、コードや文字列の難読化についてアプリケーションを調べます。
- 保護されたワークフローに到達する。実機上でアプリを実行し、画面をたどって保護が作動するポイントに到達します。これは、チェックがログイン後や機密性の高い機能を開いたときにのみ実行される場合に重要になります。
- バイパスを試み、対応を追う。保護の種類に応じて、試行には実行時の計装、再パッケージ化、再署名、root化の痕跡の隠蔽、保護ロジックの改変などが含まれます。エージェントはインターフェースとログを調べ、警告、クラッシュ、ブロックされたリクエストなどの対応をもとに、さらなる調査を進めます。
- 起きたことを記録する。検出結果では、攻撃の試行中に持ちこたえた保護と、欠落していた、無効だった、またはバイパスされた保護とを区別します。成功したバイパスには、裏付けとなるエビデンスと再現手順が含まれます。
用意するもの：APK、AAB、IPA、またはGoogle Play、App Store、TestFlightから選択したアプリケーション。Mobile Shielding Scanのプロファイルを選んだ後、OstorlabのCybermodelsを選択するか、サポートされているAIプロバイダーのキーを持ち込みます。Cybermodelsでは、調査の労力レベルを複数の中から選べます。スキャンが認証後の画面や該当するワークフローに到達できるよう、テスト用の認証情報やナビゲーションの指示を提供することもできます。スキャン設定ガイド
検出結果はどのようなものか
結果ダッシュボードは、検証済みの個々のチェックとあわせて、堅牢化の概要、カテゴリごとの評価、カバレッジの情報を提供します。バイパスを調査するAppSecチームにとって有用な詳細は、特定の保護がどう振る舞ったかを説明するエビデンスです。
その一例が、Ostorlabが公開した5つの銀行アプリの評価です。証明書ピンニングを調査するため、スキャンはアプリ自身の証明書チェッカーを2回実行しました。どちらの実行でも同じ証明書、チェッカーのインスタンス、設定済みのピンを使用し、一方の実行ではバイパス用のフックを無効にし、もう一方では有効にしました。
| 観察項目 | フック無効 | フック有効 |
|---|---|---|
| 両方のピンの比較 | falseを返した |
trueを返した |
| 証明書チェッカーの判定 | 証明書を拒否し、例外を送出した | 例外なしで証明書を受け入れた |
この管理された変更は、そのテストで実行した証明書チェッカーがバイパスされたことを示しています。エビデンスは、チェック処理を直接呼び出したことから得られたものです。拒否されていたのと同じ入力が、フックが有効なときには受け入れられたのです。
これにより、チームは調査すべき具体的な失敗と、修正後に再確認すべき具体的な条件を手にできます。つまり、同じバイパスを試みたときに、チェッカーが引き続きその証明書を拒否するかどうかです。
制約
Ostorlabは商用プラットフォームであるため、有償での利用が必要であり、主に反復可能な評価を実施するセキュリティチームやエンジニアリングチームを対象としています。その代わりに、手動のワークフローではチームが自ら構築・維持しなければならないテスト環境、バイパスの試行、エビデンスの収集を管理します。
アプリのシールディングバイパスをテストするための適切なアプローチの選び方
適切なアプローチは、チームが保護を見つける必要があるのか、アプリの実行中にそれに揺さぶりをかける必要があるのか、それともより広範な評価を自動化する必要があるのかによって決まります。
- パッケージの改変とコード解析には：Android APKのデコード、改変、再ビルドにはApktoolを、AndroidのDEXコードの調査にはJADXを、AndroidやiOSのネイティブバイナリの調査にはGhidraを使います。これらのツールは再パッケージ化のテストを支援し、保護チェックの特定に役立ちますが、それだけで実行時のバイパスを実証するものではありません。
- 実行時のテストには：Objectionは一般的な保護に対するすぐに使えるルーチンを提供し、Fridaは独自のフックを通じてテスターにより細かな制御を与えます。LLDBは、ネイティブの実行を一時停止し、保護の判定を命令単位で追う必要がある調査で役立ちます。JADXやGhidraから得た知見が、これらの実行時テストの焦点をどこに置くべきかの指針となることがよくあります。
- 自動テストには：Ostorlabは、保護の発見、バイパスの試行、エビデンスの収集を一つの自動化されたワークフローにまとめます。専門家が特定の検出結果をさらに深く調査する必要がある場合には、引き続き手動ツールを併用できます。保護されたAndroidまたはiOSアプリを評価するには、Mobile Shielding Scanをご覧ください。
よくある質問
root検知、ジェイルブレイク検知、証明書ピンニングがバイパスの試行に耐えるかどうかをテストできるツールは何か
Objectionには、一般的なroot、ジェイルブレイク、証明書ピンニングのチェック向けのルーチンが含まれています。それらのルーチンがアプリの実装に合わない場合は、Fridaを使って個別に調整したフックを作成できます。Ostorlab Mobile Shielding Scanは、AndroidとiOSでこれらの保護領域にわたるテストを自動化します。いずれの場合も、結果にはビルド、端末の状態、到達したワークフロー、観察された挙動を明記すべきです。
オープンソースツールで完全なモバイルシールディングの評価を行えるか
チームに必要なアクセス権とリバースエンジニアリングの専門知識があれば、手動のワークフロー全体を支えることはできます。テスターは、ApktoolでAndroidパッケージを改変・再ビルドし、JADXやGhidraで保護を理解し、その後Frida、Objection、LLDBでそれに揺さぶりをかけて結果を検証できます。この比較の中で、すべての段階を自動で実行する単一のオープンソースツールはないため、チームがツールをつなぎ合わせ、エビデンスを文書化する必要があります。
シールディング機能を検出すれば、それがバイパスの試行に耐えることを実証できるか
いいえ。root検知、アンチデバッグ、証明書ピンニングのコードが見つかることは、保護が存在することを示すにすぎません。その有効性は、制御に揺さぶりをかけ、アプリの対応を観察し、制限された挙動に依然として到達できるかどうかを確認することで確立されます。
シールディングのバイパスが成功したことを示すエビデンスとは何か
最も強力なエビデンスは、管理された変更を保護された判定に結びつけるものです。たとえば、同じチェッカーと入力を、バイパスを無効にした状態と有効にした状態で実行し、2つの結果を比較します。フックが読み込まれた、あるいは計装セッションが実行中であるというだけでは、意図した保護がバイパスされたことは実証されません。