「プレミアム無料、資源無限」— 検索一つで出てくる自分のゲーム
開発したゲーム名のうしろに「MOD APK」を付けて検索したことはありますか? 有料アンロック、アプリ内課金の回避、資源無限、広告除去版が第三者のAPK配布サイトに堂々と上がっていれば、誰かがそのAPKを分解・改ざんして再配布した可能性が高いです。
MOD APKは、モバイルゲームの売上とサービス寿命に直接悪影響を及ぼす主要な脅威です。有料コンテンツが無料で出回り、IAP(アプリ内課金)検証が無力化されるだけでなく、改ざんされたクライアントはマルチプレイの公平性も著しく損ないます。さらにマルウェアが仕込まれたまま流布されれば、ゲームのセキュリティに対するユーザーの信頼低下と評判被害につながります。
本記事では、MOD APKが実際にどのような過程で作られるのか、よくある防御がなぜ回避されうるのか、そしてそれを効果的に抑制する戦略は何かを見ていきます。
MOD APKはどう作られるか — 仕組み
APKは本質的にコード・リソースが圧縮された(ZIP)アーカイブです。したがって改ざんはおおむねデコンパイル → 分析 → 修正 → 再署名 → 再配布の定型プロセスをたどります。
デコンパイル(apktool/jadx/Il2CppDumper) ──> ロジック修正(課金回避・ゴッドモード・検査の無力化) ──> リパッケージ・再署名(攻撃者の鍵) ──> 第三者へ流布
1) デコンパイルおよび解析 攻撃者はAPKを展開し、専用ツールで内部を分析します。
- Java/Kotlin・Monoのロジックは
apktoolでsmaliバイトコードを抽出するか、jadxでJava類似コードに復元します。 - Unity IL2CPPビルドは核心ロジックがネイティブの
libil2cpp.soにコンパイルされますが、型・メソッド情報を含むglobal-metadata.datが同梱されます。攻撃者はIl2CppDumper系でこのメタデータを抽出し、関数構造とオフセットをかなり復元します。
2) ロジックの修正およびパッチ 分析結果をもとに、目的に合わせてコードを改ざんします。代表的な改ざん:
- 課金検証の回避: 「購入成功」を常に返すよう分岐を修正し、有料アイテムを無料で取得。
- 資源無限・ゴッドモード: 主要ステータス値を固定するか、ダメージ計算ロジックをパッチ。
- 防御ロジックの無力化: 広告表示、ライセンス確認、署名検査関数を見つけてNOP化して回避。
smaliは命令を直接修正し、IL2CPPベースは.soを直接パッチするかglobal-metadata.datを操作します。
3) リパッケージおよび再署名 修正したファイルを再びAPK(zip)にまとめて整列(zipalign)し、攻撃者任意の鍵で再署名します。Androidはすべてのapkに署名を要求するため、改ざんアプリの実行にこの過程は必須です。このとき元の開発者の公式署名は失われ、別の署名に置き換わり、これが防御者にとって改ざんを検知する非常に重要な手がかりになります。
4) 再配布 完成した改ざんファイルは、第三者APKサイト、ブラックマーケットのコミュニティ、Telegramなどに「MOD」のラベルを付けて流布されます。
ここから2つの示唆が得られます。第一に、IL2CPPは分析の難易度を上げるが、それだけで完全な盾にはなりにくい——メタデータダンプで多くが復元されます。第二に、改ざんアプリの実行にはたいてい再署名が伴うため、元と署名が変わるという点が最も強力な改ざん検知シグナルの一つです。
よくある防御戦略とその限界
1) 署名検証(正しい方向だが、検証の場所に限界)
実行時に「現在のアプリが公式証明書で署名されているか」を確認すれば、再署名されたMODを捉えられる有効なアプローチです。しかしこのロジックがJava/smali層(マネージドコード)にあると、攻撃者は該当メソッドを見つけ、常に正常判定(true)を返すよう容易にパッチします。検証が攻撃者と同じコード層に露出していると無力化リスクが高い、という構造的限界です。
2) DEX・リソースのチェックサム(整合性検証) インストールされた主要ファイルのハッシュを実行時に比較して改ざんを検知します。原理上は強力ですが、整合性を検査するロジック自体がマネージドコードに露出すると改ざんの余地があり、基準となる元のハッシュをクライアント内部に安全に隠す方法が要になります。
3) Google Play Integrity API(サーバーベースのアテステーション) Googleが端末、アプリのインストール元、ライセンスの正当性をサーバー側で証明する強力な方式です。任意のストアやWebからインストールされたMODは正常判定を受けられないため、高い信頼性を提供します。ただしPlay配布・ネットワーク接続を前提とするため、オフラインや他ストア配布のようにネットワーク依存のない区間を単独ですべてカバーするのは困難です。
4) IL2CPPビルド(単純な難読化効果) スクリプトロジックをネイティブに変換し、コード分析の参入障壁を上げます。大きな助けにはなりますが、前述のとおりメタデータダンプでかなりの構造把握が可能なので、単独の防御手段としては不十分です。
要するに、断片的な検査は正しい方向を突いていますが、検証ロジックがマネージドコードに露出すると解析でパッチされやすく、単一シグナル(署名のみ・整合性のみ)に依存すると回避経路が生じます。
Native層で改ざんと再配布を効果的に防ぐ方法
強力な防御の原則は一貫しています — 核心の検証ロジックを攻撃者が容易に分析・修正できないNative層へ移し、多角的な検知シグナルを組み合わせること。
(1) 署名・整合性検証をNative C++層で実行 アプリの署名整合性と、インストールファイルが元と一致するかをネイティブ層で確認します。Java・smaliの検査に比べ、解析・改ざんの難易度が大きく上がります。再署名・リソースパッチされたMODは、ネイティブ検証で署名不一致・ハッシュ変更として摘発されます。
(2) ビルド改ざん・メタデータ操作の挙動を直接検知
.soパッチやglobal-metadata.dat改ざんのように、IL2CPPを狙う典型的な攻撃痕跡をシステムレベルで直接点検します。IL2CPP保護を無力化しようとするメタデータ改ざんの試み自体を、検知可能なシグナルとして活用します。
(3) 多重シグナルの結合とポリシー的対応 アプリ署名、整合性チェック、リパッケージ痕跡、実行環境(エミュレータ/root)を複合的にクロス検証し、回避経路を最小化します。検知時の後続動作(強制終了、機能制限、監視ログ送信)はゲームサービスの運用ポリシーに合わせて設定します。
OZero Securityはこれらの原則をもとに、MOD APK・ビルド改ざん検知モジュールをNative C++層に実装して提供します。クライアント側で再署名・ファイル改ざん・メタデータ操作を検知し、ライブサービス段階ではPro Add-onのテレメトリでサーバー側から異常クライアントを識別・対応します。さらにPlus Add-onのアプリ別Native Variantを適用すれば、ビルドされるプロジェクトごとにセキュリティロジックのバイナリ構造が変わり、あるゲームで分析された回避パターンが別のゲームにそのまま通用するのを防ぎます。
まとめ
- MOD APKはおおむねデコンパイル → コード/ロジック修正 → 再署名 → 再配布の定型プロセスで作られ、IL2CPP環境でもメタデータ抽出によって改ざんが起こりえます。
- ほとんどの改ざんアプリはインストールのために再署名を経るため、署名・ファイル整合性検証が最も強力な一次検知シグナルです。
- ただし、この検証ロジックがJava/C#のマネージドコードにあると、比較的容易に解析・回避される恐れがあります。
- 核心戦略はNative層の署名・整合性検証 + メタデータ改ざん検知 + 多重シグナルのクロス検証であり、Play Integrityやサーバーベースのテレメトリと連携すると防御力がさらに高まります。
検索バーに現れる「自分のゲームのMOD APK」を根絶することは、単一のセキュリティスイッチを入れるだけでは完成しません。改ざんの全過程を理解し、コードの複数の層(レイヤー)にわたって複合的なハードルを築くことが重要です。