LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリ難読化と改ざん対策（RASP）が必要な理由

モバイルアプリはストアから配布された時点で、誰でもそのバイナリを入手できる状態になります。適切な保護措置なしにリリースされたアプリは、ツールを用いた解析に対して無防備です。

OWASP MASVS（Mobile Application Security Verification Standard）v2.0は、アプリのリバースエンジニアリング耐性について4つのRESILIENCE要件を定義しています。^*1これらは「診断」ではなく「保護実装」の基準であり、リリース前後を問わず取り組むべき工程です。

特にAPIキーや秘密鍵をアプリバイナリに埋め込んだまま公開するケースは後を絶たず、不正アクセスや情報漏洩の直接的な原因となります。ゲームアプリにおけるチート対策や、金融アプリにおける不正改造防止など、アプリの種別を問わず保護実装の重要性は高まっています。

リバースエンジニアリング・APIキー漏洩・チート——脅威の全容

アプリ保護を実装しない場合に現実的に起こりうる脅威を整理します。主な攻撃手法は大きく3類型に分けられます。

静的解析によるリバースエンジニアリング

静的解析（Static Analysis）とは、アプリを実行せずにバイナリやソースコードを逆コンパイル・逆アセンブルして内部構造を調べる手法です。Androidの.apkファイルはzipとして展開でき、dex2jarやJadxといったオープンソースツールを使うとJavaに近いコードを再現できます。

iOSのIPAファイルも同様にobjection等のフレームワークで解析が可能です。保護を施していなければ、ビジネスロジックやAPI仕様、認証フローが外部に筒抜けになります。

APIキー・シークレット抽出

ソースコード内にハードコードされたAPIキーやOAuth秘密情報は、静的解析によって即座に抽出されます。抽出されたキーは第三者による不正API呼び出しや、クラウドサービスの不正利用につながります。

MASVS-RESILIENCE-3（アンチ静的解析メカニズムの実装）は、難読化をはじめとする静的解析への対抗策を求める要件です。^*1難読化はキー抽出を完全に防ぐわけではありませんが、解析コストを大幅に引き上げる効果があります。

動的解析・チート・不正改造

動的解析（Dynamic Analysis）では、アプリを実行した状態でメモリダンプやネットワークトラフィック傍受を行います。ルート化（Androidのroot取得）やジェイルブレイク（iOSの脱獄）が施されたデバイス上では、通常アクセスできないメモリ領域を読み書きできます。

ゲームアプリでは体力・通貨の改ざん、金融アプリでは残高表示の偽装、業務アプリでは認証バイパスなどの被害につながります。MASVS-RESILIENCE-1（プラットフォームの整合性検証）はルート化・ジェイルブレイク・エミュレータといった実行環境の正当性確認を、MASVS-RESILIENCE-4（アンチ動的解析技法）はデバッガアタッチや動的計装ツールへの対抗をそれぞれ求めています。^*1

コード難読化・文字列暗号化・ルート検知——主要手法の解説

App Hardeningの中核となる技術手法を解説します。OWASP MASTGは、難読化（Obfuscation）をMAST-KNOW-0033として、RASPをMASTG-KNOW-0118として体系化しています。^*2

コード難読化（Code Obfuscation）

コード難読化とは、プログラムの動作を変えずにソースコードや中間バイトコードを読みにくい形式に変換する処理です。クラス名・メソッド名・変数名を無意味な短文字列に置換したり、制御フローを複雑化したりすることで、逆コンパイル後のコードを解読困難にします。

Androidでは標準ビルドツールに含まれるProGuard/R8が基本的な難読化を提供します。より高度な制御フロー難読化や文字列暗号化が必要な場合は、専用ツールの導入を検討することになります。iOSのSwift/Objective-Cにはビルトイン難読化ツールがないため、サードパーティツールへの依存度が高くなります。

文字列暗号化（String Encryption）

文字列暗号化は、ソースコード内のリテラル文字列（APIエンドポイントURLやキー値など）を暗号化した状態でバイナリに格納し、実行時に復号する手法です。単純なコード難読化だけでは文字列検索で機微情報が見つかるリスクが残るため、文字列暗号化は組み合わせて実施することが推奨されます。

ただし、暗号化鍵自体もバイナリ内に存在するため、攻撃者が時間をかければ解読できる点は念頭に置く必要があります。難読化と暗号化の組み合わせは解析コストを引き上げますが、単独での完全な情報隠蔽には限界があります。

ルート検知・ジェイルブレイク検知

ルート化されたAndroidデバイスや脱獄されたiOSデバイスでは、OSの制約が外れた環境でアプリが動作します。これを検知するため、SuperSUやMagiskなど既知のルート化ツール痕跡の有無、書き込み可能な/systemパーティションの検出、特定の隠蔽ファイルパスのチェックなどを実装します。

MASVS-RESILIENCE-1（プラットフォーム整合性）の観点で行うエミュレータ検知では、Build.FINGERPRINTやハードウェア固有プロパティを参照して仮想環境上の実行を識別します。^*1MASVS-RESILIENCE-4（アンチ動的解析）に対応するデバッガ検知では、isDebuggerConnectedやptraceの利用有無を確認します。

整合性検証（Integrity Verification）

整合性検証は、アプリのバイナリやリソースが改ざんされていないかをチェックする機能です。MASVS-RESILIENCE-2（アンチ改ざんメカニズムの実装）が、アプリ本体・リソース・実行時コードの改変を検知する仕組みを求めており、公式ストアからの配布経路の正当性確認はMASVS-RESILIENCE-1（プラットフォーム整合性）が担います。^*1

Androidでは署名検証APIを用いてAPKの署名が正規のものかを確認でき、非公式ルートで配布された改ざんAPKを検出できます。iOSではAppleの署名チェーンがある程度これを担いますが、脱獄環境では署名検証が無効化されることがあるため、アプリ側での追加チェックが有効です。

RASP（実行時自己保護）の仕組みと導入効果

RASP（Runtime Application Self-Protection）とは、アプリの実行環境を実行中にリアルタイム監視し、脅威を検知した際にアプリ自身が防御アクションをとる技術です。^*2

静的解析・改ざん検知・ルート検知がアプリ起動前後のチェックであるのに対し、RASPはセッション継続中も継続的に監視を行う点が特徴です。OWASP MASTGはRASPシグナルの実装をMASTG-BEST-0029として定義しています。^*2

RASPが検知・対処できる脅威

RASPが監視する対象は多岐にわたります。実行中のメモリ改ざん（チートツールによるゲーム内パラメータ変更など）、フッキングフレームワーク（FridaやXposedなど）による関数フック、SSLピンニング（公開鍵固定）の迂回試行、デバッガのアタッチが代表的な脅威です。

これらを検知した際のRASPの対処アクションとしては、セッション終了・機能制限・サーバへの通知・アプリクラッシュなどが挙げられます。どの脅威レベルでどのアクションを取るかは設計段階で定義することが重要です。

RASPと静的保護の使い分け

難読化や整合性検証は主にアプリ配布前の静的なバイナリ保護であり、一度施すと変更しにくいトレードオフがあります。一方RASPは実行時の動的保護であり、新たな攻撃手法への対応をアップデートで追加しやすい利点があります。

実装上の注意点として、RASPのシグナル収集ロジック自体が難読化されていないと、攻撃者にRASP検知コードを特定・無効化されるリスクがあります。このため、RASPと難読化は相互補完的に組み合わせることが現実的な設計です。

RASPの実装形態

RASPはSDK形式でアプリに組み込む方式と、専用ツールのビルドパイプライン統合方式の2つが主流です。SDK方式は既存コードへの侵襲が少なく、CI/CDパイプラインに統合しやすい特徴があります。ビルドパイプライン統合方式は開発者がRASPロジックを直接記述する必要がなく、バイナリへ後処理として適用できます。

iOS・Android別の実装ポイントとツール類型

iOS/Androidではプラットフォームの仕様差異から、保護手法の実装方法と工数が異なります。両プラットフォームの特性を踏まえた実装計画が重要です。

Android（Kotlin/Java）の実装ポイント

Androidのビルドシステムには、AGP（Android Gradle Plugin）に標準で含まれるR8（ProGuardの後継）があります。R8はコード縮小・最適化・難読化を同時に処理し、リリースビルドでは既定で有効化されます。ただし標準設定のみでは名前難読化にとどまり、文字列暗号化や制御フロー難読化は別途設定・追加ツールが必要です。

より高度な保護が必要なケースでは、制御フロー難読化・文字列暗号化・RASP機能を統合した専用ツール（DexGuard等の類型）の採用が選択肢になります。ルート検知はRootBeerなどのオープンソースライブラリから始め、自社要件に応じてカスタマイズする方法もあります。

iOS（Swift/Objective-C）の実装ポイント

iOSはAppleのビルドツールチェーンにネイティブ難読化機能が含まれないため、Androidよりもサードパーティ依存が高くなります。Swiftバイナリはビルド設定によりシンボル情報の削減は可能ですが、制御フロー難読化や文字列暗号化はビルト後処理ツール（iXGuard等の類型）を用いる設計になります。

ジェイルブレイク検知はApple自体が保証する機能ではなく、開発者がランタイムチェックを自前実装するか、専用ライブラリを組み込む形になります。脱獄検知ライブラリは検知回避ツールとの「いたちごっこ」が続いており、メンテナンスコストを見込んだ計画が必要です。

ツール類型の整理

保護ツールはその機能範囲から3類型に分類できます。第一はビルトインツール（ProGuard/R8）で、Android標準環境で利用でき導入コストが低い反面、機能範囲は限定的です。第二は専門難読化ツール（DexGuard・iXGuard等の商用ツール類型）で、制御フロー難読化・文字列暗号化・RASP機能を統合した製品群です。第三はオープンソースRASPライブラリで、コスト優先の場合に選択されますが、メンテナンスを自社で担う必要があります。

特定製品の選定はプロジェクトのOS構成・セキュリティ要件・予算・保守体制に依存するため、PoC（概念実証）を経て判断することが一般的な進め方です。

自社実装が難しい場合の外注の進め方

App Hardeningの実装には、モバイルセキュリティの専門知識・ビルドパイプラインの熟知・継続的なアップデート対応が求められます。自社のモバイル開発チームのリソースや知識が不足している場合、外注という選択肢が合理的な判断です。

外注前に整理すべき要件

外注依頼の前に、自社で以下を整理することで発注の質が上がります。まず対象アプリのOS・バージョン・ビルド環境を把握します。次に脅威モデル（どの攻撃手法への耐性が優先か）を明確にします。OWASP MASVS v2.0のRESILIENCE要件を参照すると、要件の過不足を整理しやすくなります。^*1

また、現行のCI/CDパイプライン構成をドキュメント化しておくと、ベンダー側の工数見積もりが精度が上がります。対応後の保守・アップデート（OSメジャーバージョンアップへの追随など）も含めて発注範囲に含めるかを事前に決めておくことが重要です。

ベンダー選定の視点

外注先を選ぶ際は、モバイルセキュリティの実装実績（診断実績と保護実装実績は異なります）・対応可能なプラットフォーム（iOS/Android両対応か）・使用ツールへの精通度・保守契約の有無を確認することが有効です。

また、実装後の検証方法についても確認することをお勧めします。保護措置の有効性を担保するには、OWASP MASTGの検証手順に基づいたテスト（ペネトレーションテストやバイナリ解析）を組み合わせることが現実的です。^*2

外注の進め方：4つのステップ

外注を進める際の一般的な流れを整理します。まず第1ステップとして、現状のアプリのセキュリティ状態を把握するための簡易調査（現状ヒアリング・要件整理）を実施します。第2ステップでは、MASVS-RESILIENCEの各要件に対する対応方針の合意と技術設計を行います。

第3ステップは実装とテストで、難読化設定・検知ロジック・RASPの組み込み、および動作検証を実施します。第4ステップは保守体制の確立で、OSアップデートへの追随・検知ロジックの更新・インシデント対応フローの整備を含みます。定期的な見直しを仕組みとして組み込むことで、保護水準を維持できます。

外注範囲の切り分けとしては、難読化設定のみを依頼するケースから、設計・実装・テスト・保守を一括委託するケースまで幅広く存在します。自社の技術的関与度と予算に応じて、適切な委託範囲を設定してください。

まとめ：アプリ保護実装の3つの判断軸

モバイルアプリの難読化・改ざん対策・RASPは、リリース後のアプリを脅威から守る「保護実装」の工程です。OWASP MASVS v2.0のRESILIENCE要件は、この分野の国際標準として広く参照されています。^*1

アプリ保護の実装方針を判断する際は、以下3つの軸で検討することをお勧めします。

第1の軸は「脅威の優先度」です。自社アプリがどのような攻撃を受けやすいか（静的解析・動的解析・チート・APIキー抽出）を整理し、優先対応すべき脅威を特定します。第2の軸は「自社実装可能な範囲」です。標準ツール（R8など）で対応できる部分と、専門ツールや外部知見が必要な部分を切り分けます。

第3の軸は「保守継続性」です。OSメジャーアップデートや新たな攻撃手法への追随を含め、実装後の保守体制を確保できるかを確認します。外注を活用する場合はこの保守継続性の観点を含めた発注設計が、長期的な保護水準の維持につながります。

1. OWASP, “OWASP Mobile Application Security Verification Standard (MASVS) v2.0”, MASVS-RESILIENCE 要件群（MASVS-RESILIENCE-1〜4）, https://mas.owasp.org/MASVS/（2026年6月確認）
2. OWASP, “OWASP Mobile Application Security Testing Guide (MASTG)”, MASTG-KNOW-0033（Obfuscation）・MASTG-KNOW-0118（RASP）・MASTG-BEST-0029（RASP Signal Implementation）, https://mas.owasp.org/MASTG/（2026年6月確認）

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

Tweet