結論と決定条件

  • 機能をビジネス損失と攻撃者の ROI でまず分類し、その後 VMP、Java2C、制御フロー難読化、または名前難読化のいずれかを決定します。
  • 起動シーケンス、描画ループ、高頻度の暗号化/復号処理、言語間境界は機微性の高いパスであり、パフォーマンスおよび互換性のベースラインに代えて標準的な機能回帰テストのみに依存することはできません。
  • 保護リストはバージョン管理され、固有のリリース候補、署名 ID、ビルド設定、および回帰記録に紐付けられている必要があります。そうでない場合、異常の原因特定が不可能になります。
  • VMP はクライアント側コードの解析と流用コストを増大させますが、署名ガバナンス、プラットフォーム整合性シグナル、サーバー側認可、あるいはリスク制御を代替するものではありません。

関数リストをビジネス資産目録へ変換する

包括的カバレッジの主な問題はパフォーマンスではなく、選定基準の欠如です。コードリポジトリには、コアアルゴリズム、認証チェック、プロトコルのエンコード/デコード、UI バインディング、汎用ユーティリティ、サードパーティ適応層が混在しています。これらのコンポーネントをリバースされた際の影響は劇的に異なります。パッケージ名、クラス名、または関数のみでターゲットを選定すると、低価値なコードに保護予算を急速に消費し、重要なパスに対する安定した回帰テストリソースが残らなくなります。

実行可能なアプローチには、事業、セキュリティ、エンジニアリングの各チームが共同で資産目録を作成することが必要です。候補となる関数はそれぞれ次の 4 つの質問に答える必要があります：攻撃者がこれを理解することで何を得られるか？これを変更するとどのような被害が生じるか？ロジックをサーバー側へ移行できるか？失敗時に安全なフォールバックはあるか？明確な損失リスクがあり、オンデバイスでの実行が必須であり、テスト可能な境界を持つパスのみを技術選定に進めるべきです。

OWASP MASVS は、逆解析対策と改ざん対策を多層防御の措置として分類し、これらが堅牢なセキュリティアーキテクチャの代わりにはならないと明記しています。この境界線は、VMP の選定基準は脅威モデリングから導き出すべきであり、技術名をセキュリティ成果と直接同一視してはならないことを意味します。

候補関数の評価時に記録すべき最小限の情報
評価次元回答すべき質問高強度保護に適したシグナル格下げまたは延期が必要なシグナル
事業損失ロジックがコピー、スキップ、または変更された場合、何が失われるか？認可、権限、コアアルゴリズム、または重要プロトコルが直接バイパスされる可能性があります。UI 表示や低価値な補助機能のみに影響します。
クライアント側の必要性最終的な判断をオンデバイスに残す必要があるか？オフライン要件、レイテンシ制約、またはプラットフォーム機能がクライアント側での実行を義務付けています。高リスクの判断はサーバー側で完了可能です。
実行特性呼び出し頻度、スレッドコンテキスト、および起動段階は何か？低頻度であり、境界が明確で、孤立状態で測定可能です。メインスレッドでの起動、高頻度のループ、または無制限の実行時間。
失敗時のフォールバック保護機能の失敗時に、システムを安全に停止または切り替えられるか？明確な失敗状態とロールバック設定が存在します。失敗により起動がブロックされ、迅速に隔離できません。
検証可能性保護適用後に業務上の正しさをどう証明するか？入出力、シナリオ、および受け入れ責任者が明確に定義されています。安定したテストパスがない暗黙的な状態に依存しています。
  • 資産所有者が損失モデルを確認します。
  • エンジニアリングが呼び出し境界と依存関係を確認します。
  • QA が再現可能な受け入れパスを確認します。
  • リリースマネージャーがロールバック条件を確認します。

VMP は実行表現を変更するだけであり、セキュリティ責任の総量を変えるものではありません

名前難読化はシンボルや構造の可読性を低下させ、制御フロー難読化はパス復元の工数を増大させます。Java2C は管理コードの一部をネイティブ表現へ移行し、VMP は選択されたロジックを新しい命令セットと実行メカニズムで処理します。これらは階層化可能ですが、それぞれ異なる課題に対処し、固有の実行時コストと失敗モードを持ちます。均一な保護レベルを全関数に適用するよりも、設定可能な階層化戦略を定義する方が検証が容易です。

攻撃者は依然として入出力、呼び出しタイミング、ネットワーク挙動、および実行時状態を観測可能です。決済、権限付与、アカウント認証、または高リスクなリソースアクセスにおいては、サーバー側でアカウント権限、バージョンセット、リクエストコンテキスト、プラットフォーム整合性シグナルを検証する必要があります。クライアント側保護の役割は分析・改変・大規模な再利用のコストを増大させることであり、クライアントを絶対的に信頼できる環境に変換することではありません。

保護範囲の選定には保守性も考慮する必要があります。リリース毎に高頻度で変更され、高強度の処理が行われるビジネス結合コードは、ビルド差分と回帰テストの対象範囲を拡大させます。一方で、インターフェースが明確で比較的安定した高価値のコアモジュールこそが、長期的な保護単位として適しています。

異なる保護レイヤーの責務は相互に代替できません
保護レイヤー主要機能典型的なコスト引き続き必要な対策
名前および構造の難読化静的解析および一括特定的效率を低下させます。デバッグ、クラッシュ原因特定の困難化、マッピングファイルの管理。整合性チェック、サーバー側認可、重要ロジックの保護。
制御フローおよび文字列処理局所的な復元コストを増大させ、直接的な機密手がかりを減少させます。パッケージサイズ増、実行時オーバーヘッド、互換性リスク。鍵ガバナンス、ログのサニタイズ、実行時検証。
Java2C またはネイティブ変換管理コードの一部に対する分析対象面を変更します。JNI 境界、ABI 互換性、ネイティブクラッシュ。SO 依存関係、シンボル、例外処理、スレッドチェック。
VMP（仮想マシン保護）選択されたコードの実行表現と分析経路を変更します。パフォーマンス、影響範囲（ブラスト半径）、リリース候補における回帰テスト。署名、バージョニング、サーバー側ポリシー、リリースゲート。

起動チェーンおよび高頻度パスには、まず同等のベースラインが必要

アプリケーションの起動は単一のポイントではありません。Android は公式にコールドスタートを、プロセス生成、Application クラスの生成、メインスレッドの起動、Activity の生成、レイアウトのインフレート、初回描画に分解し、それぞれ TTID（Time to Initial Display）と TTFD（Time to Fully Drawn）を用いて初フレーム表示時間と完全インタラクティブ時間を観測します。保護対象コードが Application、ContentProvider、クラス初期化、または重要な最初の画面パスに存在する場合、モニタリング SDK の初期化前に障害が発生する可能性があり、標準的なオンラインログでは完全に捕捉できない場合があります。

高頻度関数のリスクは累積コストに起因します。1 回の呼び出しあたりの実行時間のわずかな増加も、レンダーループ、音声・動画処理、プロトコルループ、またはバッチデータ処理において増幅されます。合否判定は単一の平均値に依存せず、同一デバイス状態かつ同一リリース候補 ID の下で、分布、ロングテール、メインスレッド占有時間、メモリ変動、例外発生率を比較する必要があります。本記事では汎用的なオーバーヘッド数値を示しません。具体的な結果は関数構造、保護設定、デバイス、コンパイラ、および実行頻度に依存するためです。

コールドスタート、ウォームスタート、予熱済みテスト環境を混同してはなりません。少なくともインストール状態、プロセス状態、アカウントデータ、ネットワーク条件を固定し、 unprotected なベースラインと保護済みのリリース候補の双方を同一手法で測定してください。

高感度パスの検証焦点
パス感度が高い理由必須観測項目リリース条件
Application および ContentProvider初画面描画および大半のモニタリング初期化より前に発生します。プロセス生成、初期化順序、最早期の例外、TTID。新たな起動失敗がないこと。時間変動がプロジェクト予算内であること。
高頻度のメインスレッド関数累積遅延がインタラクティブ性に直接影響します。呼び出し回数、単回/総所要時間、ジャック、ANR。重要なユーザーパスの分布が許容範囲内であり、新たなロングテールが発生していないこと。
ネイティブおよび JNI 境界ABI、登録、例外、スレッド制約に関わります。ライブラリ読み込み、JNI 例外、対象 ABI、クラッシュスタック。対象マトリクスが項目ごとに合格すること。未カバー項目はフラグ付けされます。
バックグラウンドバッチ処理CPU、バッテリー、メモリのコストを増幅させる可能性があります。タスク所要時間、ピークリソース使用量、キャンセル、リトライ。システム制限またはビジネスデッドラインに違反しないこと。
  • コールドスタート時間とビジネスインタラクション時間を分別して記録する。
  • インストール条件とアカウントデータ条件を同一にする。
  • 平均値だけでなくロングテールの分布も観察する。
  • パフォーマンス予算を事後の説明ではなく、受け入れ基準に組み込む。

保護スコープを「監査可能かつロールバック準備済み」の構成として定義する。

維持可能な保護リストは単なるツール上のチェックボックスであってはならない。リリース構成と同様にバージョン管理に入れ、アセット識別子、選択理由、保護レベル、依存関係、パフォーマンス予算、担当者、およびロールバック条件を記録する必要がある。これにより、問題発生時に特定の関数がなぜ保護されたのか、どのバージョンからか、誰が承認したかを明確に答えられるようになる。

構成変更は小ロットで進めること。最も価値が高く境界が明確なパスを数個選んで PoC を構築し、その後グループごとに拡大する。各拡大時には新しいリリース候補 ID と回帰テスト記録を生成し、同一ファイル名で旧アーティファクトを上書きしてはならない。

以下の YAML はデータ構造の公開かつ安全な例であり、Yudun 内部の構成フォーマットに対応せず、実在するクラス名、関数名、または製品実装も含まない。

  • すべての選択にはビジネス上の正当性がある。
  • 構成変更は特定のリリース候補に紐付けられる。
  • 高リスクパスには独立した回帰テストスイートを用意する。
  • ロールバックは旧構成の推測に依存しない。
保護スコープリストの公開安全例
asset: premium-entitlement-decision
owner: commerce-team
client_required: true
threats:
  - unauthorized-logic-reuse
  - local-branch-tampering
execution:
  phase: post-login
  frequency: low
  main_thread: false
protection:
  tier: high
  rollback_group: entitlement-v1
acceptance:
  - output-parity
  - latency-budget
  - target-os-matrix
  - signed-candidate-identity

受け入れは同一のリリース候補およびリリースチェーンに必須で紐付けられること

ビルド成功はツールチェーンがアーティファクトを生成できたことのみを示し、インストール成功は現在のパッケージが当前のデバイス上でインストール条件を満たしたことのみを示す。最終的な受け入れには、署名ID、現行版からのアップグレード、コールドスタート、重要ビジネスパス、例外回復、対象システム、対象 ABI の検証も含める必要がある。静的解析、パフォーマンス測定、および互換性回帰テストはすべて同一のファイルID を指さなければならない。

保護前のベースラインと各保護済みリリース候補について、ファイルダイジェスト、パッケージ名、バージョン、署名証明書ダイジェスト、ビルドソース、保護設定バージョン、チャネル処理順序を記録することを推奨します。再ビルド、再署名、またはチャネル変更が行われた場合は新しい候補 ID が生成されるため、影響を受ける検証ステップを再度実行する必要があります。

リリースの判断においては、検証済み範囲、未実施範囲、失敗範囲という 3 つの結論を明確に記載しなければなりません。デバイス、システム、またはビジネスデータが存在しない領域は「未カバー」とマークし、他バージョンや他デバイスの成功結果を流用するのではなく、カナリアリリースを制限してください。

PoC からリリースまでの最小ゲート
ゲート証拠容認できない代替手段失敗時のアクション
候補 IDダイジェスト、バージョン、署名、設定、およびビルドソース。同一ファイル名または口頭での確認のみ。伝播を停止し、成果物を修正し直す。
機能的一貫性主要な入出力経路と例外経路の比較。ホーム画面の開示または単一のデモ実行のみ。範囲を狭め、最早期の相違点を特定する。
パフォーマンス予算同一条件下における起動時間およびクリティカルパスの分布。異なるデバイスから得られた単一の平均値のみ。高頻度経路をロールバックするか、ティアを調整する。
互換性マトリクス対象システム、ABI、デバイスタイプ、およびサードパーティ経路。エミュレータのみ、または単一の新しいシステムバージョンのみ。未カバーとしてフラグを立て、リリースを制限する。
リリース完了アップグレード、署名、チャネル、監視、およびロールバック訓練。再署名後にパッケージが異なっていること。影響を受けたゲートを再実行する。

VMP 範囲を直接拡大すべきではない事例

チームが主要資産を明確に定義できていない、安定したリリース候補がない、対象システムマトリクスを満たしていない、あるいは保護前のベースラインさえ存在しない場合、範囲をさらに拡大しても帰属不可能な変数が増えるだけです。正しい対応は、カバレッジを高めて検証の隙間を隠蔽することではなく、資産定義とテスト条件を完遂することです。

リフレクション、シリアライゼーション、動的クラスロード、ホットフィックス、プラグインフレームワーク、JNI 登録、サードパーティ製自己検証、および起動段階の SDK は、名前、コードレイアウト、ロード順序、または例外動作に対して暗黙的な依存関係を持つ可能性があります。これらは保護を一律に禁止するものではありませんが、別途リスト化し、実際のビジネスエントリーポイントで検証する必要があります。

サーバー側で処理可能な高リスクの判断は、最終的な認可をサーバー側で行うことを優先してください。クライアント側の VMP は必要なローカル計算や判断材料を保護できますが、ランタイム環境が永続的に信頼できることを保証するものではなく、有効なクライアント認証情報の悪用を単独で防止することもできません。

最終的なスコープは、単一の会議で下された恒久的な結論ではありません。ビジネスロジック、コンパイルチェーン、SDK、対象システムの変化に伴い、資産価値、実行頻度、互換性の境界を再評価する必要があります。

  • スコープを拡大する前に、ベースラインを確立してください。
  • ロールバック計画なしに blast radius（影響範囲）を拡大しないでください。
  • 暗黙的な依存関係を持つパスについては、個別のグループを作成してください。
  • サーバーで管理可能な判断を、クライアントのみに委ねないでください。

証拠と適用可能性の境界

このセクションでは、文書化されたプラットフォームの事実、技術的な判断、および未検証の製品主張に一般化できない制限を分けて説明します。

条文判決事実または工学的根拠適用制限
VMP は脅威に基づく多層防御として機能させるべきであり、セキュリティアーキテクチャそのものの代用としてはいけません。OWASP MASVS-RESILIENCE では、難読化、改ざん防止、静的・動的解析対策をレジリエンス向上のためのコントロールとして挙げていますが、セキュリティは依然として検証可能な設計、暗号技術、およびサーバー側での検証に依存することを強調しています。本標準はコントロール目標を定義するものであり、特定の製品や設定がそれらを達成したことを証明するものではありません。
起動パスには、独立したパフォーマンスベースラインが必要です。Android では公式に起動をコールド、ウォーム、ホットの各状態に分類し、TTID と TTFD を用いて初フレーム表示時間と完全インタラクティブ時間を区別します。公式の指標定義だけで、特定のプロジェクトにおける実際のリリース候補や対象デバイスでの計測を代替することはできません。
署名とアップグレードの継続性は、それぞれ独立して承認される必要があります。Android のドキュメントでは、すべての APK に署名が必要であり、プラットフォームはこの署名アイデンティティを用いて、インストール済みアプリへの更新が同じ鍵保有者からのものであるかを判定すると明記されています。署名の一貫性はリリースアイデンティティチェーンの一部のみを証明するものであり、ビジネスロジックが悪用されていないことを証明するものではありません。
プラットフォーム整合性シグナルをサーバー側のポリシーに組み込むべきです。Play Integrity はアプリ、デバイス、アカウント、環境に関する評決を返却するため、バックエンドはリスクグレーディングに基づいて対応できます。シグナルは配信環境によっては利用できないか制限される場合があり、単一の評決を絶対的な信頼として扱うことはできません。
関数、デバイス、構成から切り離された汎用的なパフォーマンスオーバーヘッドの数値は存在しません。VMP のコストは実行頻度、スレッド数、コード構造、保護実装、コンパイラ、およびデバイスに依存するため、結論は同一条件下での制御された比較を通じて導き出す必要があります。これはエンジニアリング上の判断であり、Yudun や他製品に関する実証的なパフォーマンス主張ではありません。

エンジニアリングに関する質問

カバレッジを高めれば、必ずリバースエンジニアリングのコストも上昇するのでしょうか？

カバレッジの拡大は一部の箇所の分析労力を増やす一方で、パフォーマンス、互換性、回帰テストのコストも増大させます。攻撃者の ROI に真に影響するのは、高価値なパスが効果的に保護されているか、そして署名、完全性チェック、サーバー側ポリシーが閉じたループを形成しているかどうかです。

起動時の関数は VMP の適用が絶対に禁止されていますか？

絶対禁止ではありません。ただし、起動段階での障害はブラスト半径（影響範囲）が大きく、監視機構がまだ初期化されていない可能性があります。コールドスタートのベースライン、明確な予算、対象システムマトリクス、迅速なロールバック計画が前提条件となります。

ある関数が高価値かどうかをどのように判断すればよいですか？

その関数をリバースまたは改変することで、認可の迂回、アルゴリズムの複製、プロトコルの悪用、あるいは直接的なビジネス損失を引き起こせるかを評価してください。同時に、そのロジックがオンデバイスで維持される必須要件であり、独立して回帰テスト可能であることを確認する必要があります。

現在のリリース候補がない状態で、最終的な適用範囲を確定できますか？

資産の格付けや PoC リストの作成は可能ですが、パフォーマンス、互換性、あるいは最終的な保護効果について事前に確約することはできません。最終的な範囲は、実際のリリース候補を用いた比較結果によって確定させる必要があります。

VMP 導入後でも、サーバー側のリスク制御は依然として必要ですか？

はい。クライアント側の保護は解析と改変のコストを高めますが、アカウントの認可、取引、権限付与、ハイリスクリソースへのアクセスについては、バージョン、アカウント、リスクシグナルを統合したサーバー側で最終判断を行う必要があります。

独自のアプリでこれをテストしてみませんか?

Yudun PoC と互換性評価のために、リリース候補、ターゲット システム、重要なビジネス パスを提出します。

続けて: VMP 保護とは何か、およびその範囲を選択する方法

アプリ強化テストをリクエストするプロジェクトの詳細を送信する