はじめに

概要

OZero Security は、一般的なハッキングツールがアクセスしにくい Native C++ レイヤーでセキュリティロジックを実行し、Unity ゲームを保護します。Unity エディター内のダッシュボードでモジュールを有効化するだけで、コアな保護機能が動作します。シーンの設定や追加のコード作成は必要ありません。

1 パッケージのインポート

Unity エディターを開き、OZero Security パッケージをインポートします。Unity Package Manager を使用するか、.unitypackage ファイルをダブルクリックしてインポートできます。

Import Unity Package ダイアログが表示されたら、すべての項目がチェックされた状態で Import をクリックしてください。必要なスクリプト、ネイティブプラグイン、エディターツールが自動的に追加されます。

2 ダッシュボードを開く

インポートが完了したら、Unity のメニューバーから Config Dashboard を開きます:

Config Dashboard が開くと、この画面でプリセット、セキュリティモジュール、ライセンス、ビルド整合性設定を一度に管理できます。Project ウィンドウでファイルを直接探して修正する必要はありません。

Unity エディターメニューの説明

OZeroSecurity は、設定ウィンドウを Window > OZero Security、診断や bake コマンドを Tools > OZero Security に配置しています。セキュリティプリセットは Config & Dashboard から適用する設計です。保存前に変更後の設定を確認できます。

3 モジュールの有効化

ダッシュボード内でセキュリティモジュールの一覧とトグルスイッチを確認できます。使用するモジュールを有効化してください。以下は推奨される開始設定です。

セキュリティのプリセットを選択する

まずプリセットを選択した後、プロジェクトに合わせて個別のモジュールだけ調整してください。一般的なライブゲームは Standard から始めることをお勧めします。保護のレベル、パフォーマンス、誤検知の可能性のバランスが最も良いです。

ダッシュボードで使用するモジュールをオンにし、OZeroSecurityConfig アセットを保存するだけです。プレイヤーが起動すると、SDK が有効化されたモジュールを自動的に準備します。

ライセンスモデル — Standard / Pro

Standardはサーバー連携なしでローカル保護を提供します。Proはプロジェクト専用ネイティブバイナリ（Native Variant）とマニフェストのバインディングに、テレメトリー・署名付き時刻・リモートセキュリティ設定・アテステーション・サーバー検証を組み合わせます。

Proライセンスキーの登録

Standardは個別のライセンス設定なしで動作します。ProではUnityでOZeroLicenseConfigアセットを作成し、プロジェクトのキーを入力します。専用Variantのバインディングとランタイム有効化・サーバー機能に使用します。

1. 設定アセットの作成

Unity の上部メニューから Window → OZero Security → Config & Dashboard を開きます。License & Server セクションで Create OZeroLicenseConfig ボタンをクリックしてください。このボタンを使うと、OZeroLicenseConfig アセットが正しい Resources/ フォルダーに自動作成されます。フォルダーを手動で作成したり、アセットを移動したりする必要はありません。

2. Inspector フィールドを埋める

3. ビルド & 検証

追加のコードを書く必要はありません。アプリが起動すると、SDK が OZeroLicenseConfig アセットを自動的に読み込みます。初回実行後、Player ログで [OZeroLicense] activated; tier=pro caps=5 のような行を確認してください。Pro に設定したのに Standard モードと表示される場合は、まずアセットの場所と名前を確認します。アセットは Resources/ フォルダー配下にあり、名前は正確に OZeroLicenseConfig である必要があります。

オフラインの動作

要点から言うと、ネットワークが切れてもゲームとローカル保護は止まりません。Standard はもともとサーバーを使わず、Pro も同じオフラインのローカル保護を維持します。明示的に選択したサーバー機能だけが、一定期間保存済みの認証情報を使えます。

Standard — インターネットなしで起動

Standard はサーバーに許可を確認しません。アプリに含まれるローカル保護モジュールだけを実行するため、プレイヤーがオフラインでもゲームは起動します。テレメトリーや signed time など、Pro サーバーが必要な機能だけが使われません。

Pro — ローカル保護はオフライン継続、選択したサーバー機能はキャッシュを使用

任意の Pro サーバー機能を有効にした場合、オンライン時に端末とライセンスを確認します。選択したサーバー機能は、一定時間だけ一時的な切断に耐えられます。この確認は、取得済み Native Variant のビルドやローカル保護を制限しません。

tokenTtlSeconds は保存されたサーバー機能結果の有効期間で、既定値は 604800 秒、つまり 7 日です。オフライン中に期限切れになると、テレメトリー送信や signed-time 検証などのサーバー依存機能だけが次のアクティベーション成功まで利用できなくなります。ゲーム、取得済み Native Variant、ローカルディテクターはそのまま継続し、SDK が製品ティアを Standard に暗黙的に切り替えることはありません。

Pro — ポータルでブロックしたビルドはオフラインでも止める

一時的なサーバー障害やネットワーク障害で基本保護として起動を続けることと、運営者がポータルで明示的にブロックしたビルドを許可することは別の問題です。Pro 認証が成功すると、サーバーはブロック対象のビルドハッシュ、SDK バージョン、アプリバージョンなどを署名付きリストとして返します。SDK はこのポリシーを一時的なサーバー機能状態とは別に扱います。

この動作は Config Dashboard の License & Server セクションにある OZeroLicenseConfig.offlineProPolicyMode で設定します。デバイスがサーバーに接続できないとき、ローカル Build Integrity が最後に受け取った署名済み Pro ポータルブロックポリシーをどう扱うかを決めます。

要約すると、ApplyCachedBlockPolicies は運用既定の fail-open モード、RequireFreshPolicy は fail-closed ポリシーモード、IgnoreCachedBlockPolicies はテスト用 bypass です。毎回の検証でオンラインサーバー確認を必須にしたい場合は、このオプションだけに依存せず、サーバー Integrity または Managed Verification の必須オプションも一緒に設定してください。

ライセンス問題の解決

問題が起きたら、まず Unity Player ログで [OZeroLicense] を検索してください。このログで、SDK が Standard として起動したか、Pro 認証が成功したか、失敗した場合になぜ Standard へ下がったかを確認できます。セキュリティイベント送信の問題は [OZeroTelemetry] も一緒に検索してください。

プロジェクト設定

個別のセキュリティモジュールを調整する前に、ネイティブプラグインとストアのビルド、プラットフォームの検証に影響を与える Unity Player Settings を先に確認してください。

最小のビルドターゲット

リリースビルド向けのセキュリティと容量最適化設定

最終リリースビルドを公開するときは、ビルドを強化しアプリ容量を減らすために、次の Unity 設定を推奨します。

セキュリティ強化（IL2CPP 設定）: Android、iOS など Unity が対応する環境では、ビルド方式を IL2CPP にしてください。IL2CPP はリバースエンジニアリングを完全に防ぐものではありませんが、C# コードやメタデータがそのまま露出する範囲を減らし、OZero のセキュリティチェックがより堅いリリース環境で動作する助けになります。パス: Project Settings > Player > Other Settings > Scripting Backend

容量最適化（Managed Stripping 設定）: 使用していない managed code を削除してアプリ容量を減らす機能です。最初から強く削りすぎるとアプリが実行時に失敗する可能性があるため、まずは Low または Medium から始めてください。

注意: 設定を変更した後は、シーン遷移、データ保存、Addressables、決済や広告などの外部 SDK が実機で正しく動作することを確認してから、stripping level を上げてください。

Android ProGuard / R8 の設定

OZero Security は別途の Java SDK パッケージを要求しません。ただし、Android リリースビルドで Minify、ProGuard、R8 を有効にした場合は、Unity Java ブリッジとプロジェクトで使用するカスタム Android ブリッジクラスを保持する必要があります。そうすることで、パッケージ情報、インストール元、APK 署名証明書チェック、ブートアセットロードに必要な JNI 呼び出しが難読化以降も安定して動作します。

# OZero Security - Unity Android ProGuard/R8 keep rules
-keep class com.unity3d.player.UnityPlayer { *; }
-keep class com.unity3d.player.UnityPlayerActivity { *; }
-keep class com.unity3d.player.UnityPlayerGameActivity { *; }
-keep class com.unity3d.player.UnityPlayerForActivityOrService { *; }
-keepattributes *Annotation*,InnerClasses,EnclosingMethod,Signature

# If your game adds custom Java/Kotlin bridge classes that OZero or your code
# calls through AndroidJavaClass / AndroidJavaObject, keep those classes too.
# Replace the package below with your own bridge package.
# -keep class com.yourcompany.yourgame.bridge.** { *; }

• libOZeroSecurity.so を名前変更、削除、再パッケージ化しないでください。プラグインは Assets/OZeroSDK/Plugins/Android/arm64-v8a の下に維持し、32ビットビルドを配布する場合は armeabi-v7a も一緒に維持してください。
• Build Integrity > Check Platform Native と Android SHA Keys を使用する場合は、Minify/R8 適用後の最終署名された APK または AAB で必ずテストしてください。デバッグキーストアのフィンガープリントとリリースキーストアのフィンガープリントは異なります。
• Minify をオンにした後にのみ、Android ログで JNI 照会失敗、インストール元検知失敗、APK 署名チェック結果が空と表示される場合は、まずカスタムブリッジの keep ルールを確認してください。
• ストア配布用のビルドは、IL2CPP、リリース署名、Android Sha Keys に登録された予想される Android SHA-256 フィンガープリント、そして少なくとも1台の実際のデバイスでのクリーン実行テストを基準に検証してください。

5 OZeroSecurityConfig の設定

OZeroSecurityConfig ScriptableObject アセットはパッケージのインポート時に含まれます。Project ウィンドウで選択し、すべてのセキュリティモジュールの設定を確認および調整してください。ランタイムでは OZeroSecurityConfig.Instance としてアクセスします。

共通設定

すべてのセキュリティモジュールで共有される最上位設定です。この表のデフォルト値は、コードに定義されたシリアライズ初期値を基準にしています。

Managed UI（全ライセンス）

Security Termination Notice、共通 dialog prefab、localization は Standard / Pro で利用できます。Pro では Build Integrity と Steam DRM 用の Managed Verification retry・timeout・provider 設定も表示されます。optional package の import 前に Package Manager から Unity UI と TextMeshPro を install してください。通知はすでに予約された終了を説明するだけで、終了の取消や native deadline の延長はできません。

Global Threat Response

セキュリティの脅威が確認されたときのゲームの反応を設定します。テスト中はコールバックとログを先に確認し、実際の配布ビルドではプレイヤーへの通知時間と終了ポリシーをプロジェクトの運用方法に合わせて選択してください。

連携トラブルシューティング

OZero Security を有効化した後にアプリが終了する場合、または特定の環境でだけ問題が出る場合は、まずローカル診断ファイルでどのモジュールが反応したかを確認してください。推測で設定を変えるのではなく、ファイル内の module、subCode、reason を基準に下の表を順に確認します。

アプリが繰り返し終了する場合

よく見る診断項目

よくある症状と最初の確認

ビルド整合性検証器の設定

修正されたゲームファイル、デバッガーの接続、異常な実行環境を検知するビルド整合性チェッカーを構成します。

RSA 署名キーの生成（Build Integrity Manifest）

Build Integrity は、ビルド時に生成される manifest に RSA 署名を追加できます。この manifest には、ランタイムで検証する assembly hash とファイル整合性情報が含まれます。リリースビルドでは manifest 自体が差し替えられると検証基準を信頼できないため、配布前に Window > OZero Security > Config & Dashboard の Generate Key Pair で manifest 署名キーペアを生成してください。

Manifest 署名が必要な理由

ビルド時に、OZero は 秘密キーで manifest に署名します。プレイヤービルドには秘密キーは含まれず、OZeroSecurityConfig に保存された公開キーだけが含まれます。ランタイムでは、SDK がその公開キーで manifest の署名を確認します。署名が正しければ「ビルド時に作成された manifest がそのまま維持されている」と判断し、その manifest を基準に assembly/file hash 検査を行います。署名がない、または一致しない場合は manifest が差し替えられた、または編集された可能性があるため、Build Integrity 失敗として処理します。その後の動作は Response Settings に従い、ログ、コールバック、アプリ終了などになります。

キーペアを生成する

1. Unity エディターで Window > OZero Security > Config & Dashboard を開きます。
2. インスペクターで Build Integrity セクションを展開します。
3. Require Manifest Signature チェックボックスを有効化します。
4. Generate Key Pair ボタンをクリックします。
5. OZero が Build Integrity manifest signing 用のキーペアを生成します。公開キーは OZeroSecurityConfig に保存され、個人キー はデフォルトで次のパスに保存されます:
   [ProjectRoot]/OZeroSigningKeys/manifest_private_key.pem
6. 個人キーの位置を示す確認のダイアログボックスが表示されます。OK をクリックして閉じます。

重要 — 個人キーのセキュリティ

• 個人キーファイルは Unity がビルドに含めないように Assets/ フォルダの 外部 に保存されます。絶対に Assets/ の中に移動しないでください。
• OZeroSigningKeys/ はバージョン管理から除外してください。Git では .gitignore、SVN では svn:ignore に追加します。個人キーをリポジトリへコミットすることは重大なセキュリティリスクです。
• 個人キーは安全な場所にバックアップしてください。このファイルを持つ人は、そのプロジェクトの有効な Build Integrity manifest を作成できます。
• 個人キーを紛失した場合、既にリリース済みのビルドはそのまま動作します。ただし、次のアップデートビルドでは旧キーで新しい manifest に署名できません。新しいキーペアを生成し、integrity manifest を再生成して clean build で配布してください。公開キー、fingerprint、manifest、signature が一致していない場合、Build Integrity 検証に失敗することがあります。

ユーザー指定の個人キーのパス（CI/CD & チーム環境）

Manifest Signing Private Key Path は、Generate Key Pair が新しいキーを生成する場所を選ぶ設定ではありません。ビルドと検証ツールが読み込む PEM 秘密キーの場所を指定する設定です。Generate Key Pair はプロジェクトの既定パスにキーを作成し、そのパスを Config に記録します。CI/CD やチームビルドでは、同じ PEM を安全な場所に復元してから、このフィールドでそのパスを指定してください。

• CI/CD パイプライン — PEM を CI Secret に保存し、Unity ビルドの直前に復元します。ビルドランナーが秘密キーを常にディスクへ保持する必要はありません。
• チーム環境 — リリースビルド担当者やビルドランナーだけがアクセスできるセキュアなマウントパス、またはシークレットマネージャーを使用します。すべてのリリースビルドマシンは同じ PEM を使用する必要があります。

既存のキーペアの検証

ディスク上の秘密キーと OZeroSecurityConfig に保存された公開キーが一致しているか確認するには、Validate Key Pair をクリックしてください。OZero は PEM から公開キーを再計算し、Config の公開キーと比較します。一致しない場合は、対応する秘密キーを復元するか新しいキーペアを生成し、その後 clean build を作成してください。

キーペアを再生成すべき場合

• 個人キーを紛失または流出した場合。
• Validate Key Pair で不一致を報告する場合（キーが同期されていない場合）。
• 予定されたセキュリティポリシーの一環として意図的にキーを交換する場合。

再生成後も、既にリリース済みのビルドは自分のビルドに含まれるキーと manifest でそのまま動作します。次のアップデートビルドでは、新しい公開キー、fingerprint、manifest、signature が1つのセットとして一致している必要があります。integrity manifest を再生成し、clean build で配布してください。

デュアルフィンガープリントのキー回転

Generate Key Pair ボタンを押すと、公開キーが OZeroSecurityConfig に保存され、同じキーを識別する fingerprint が Assets/OZeroSDK/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs にも記録されます。ランタイムでは、まず asset 内の公開キーが信頼済み fingerprint と一致するか確認してから、署名済み manifest を受け入れます。

現在のキーと以前のキー

ExpectedPublicKeyFingerprintHex は現在のビルドで使うキーの fingerprint です。PreviousPublicKeyFingerprintHex はキー回転期間だけ使う補助スロットです。この機能は manifest の再生成を置き換えるものではなく、サーバー側のキー管理機能でもありません。OZeroSecurityConfig の公開キー、fingerprint、manifest、signature は、同じキーを基準に1つのセットとして一致している必要があります。

安全なキー回転手順

1. 現在の fingerprint をバックアップします。 Assets/OZeroSDK/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs を開き、ExpectedPublicKeyFingerprintHex の値を一時メモにコピーします。
2. 以前のキースロットに登録します。 同じファイルの PreviousPublicKeyFingerprintHex に1段階でコピーした値を貼り付けて保存します。
3. 新しいキーペアを生成します。 Window > OZero Security > Config & Dashboard を開き、Build Integrity セクションで Generate Key Pair をクリックします。新しい公開キーと Expected fingerprint が自動的に更新されます。2番目の手順で入れた Previous の値は維持してください。
4. integrity manifest を再生成し、clean build を作成します。 新しい manifest と signature は、新しい秘密キーを基準に生成される必要があります。
5. アップデート移行期間を設けます。 既存リリースビルドは、自分のビルドに含まれるキーと manifest で引き続き動作します。Previous スロットは、新しいビルドの配布中にロールバックや成果物の混在が起きた場合の安全策です。ライブゲームでは通常 1〜4 週間程度を目安にします。
6. 以前のキースロットを空にします。 古いビルドの使用量が十分に低くなった後、PreviousPublicKeyFingerprintHex = "" に戻し、もう一度リリースすると回転が完了します。

Previous スロットが行うこと

既にリリースされた旧ビルドは、新しいキーを知らなくても動作し続けます。旧ビルドには当時の公開キー、fingerprint、manifest、signature が一緒に含まれているためです。Previous スロットは、新しいリリースラインで管理されたキー回転期間だけ使う安全策です。移行期間が終わったら、後続リリースで空にしておくことを推奨します。

トラブルシュート

問題が起きたら、まず簡単な順序で確認してください。キーがない場合は Generate Key Pair を実行し、キーがある場合は Validate Key Pair を実行します。その後、integrity manifest を再生成して clean build を作成します。ほとんどの問題は、秘密キー PEM、OZeroSecurityConfig の公開キー、OZeroManifestTrustAnchor の fingerprint、生成済みの manifest/signature ファイルのどれかが一致していないときに発生します。

症状 1 — リリースビルドが実行直後に終了する

ExpectedPublicKeyFingerprintHex が空である可能性があります。リリースビルドは fingerprint がない場合、安全のためすぐ失敗します。解決: Generate Key Pair を実行し、Unity の再コンパイルが終わったあと clean build を作成してください。値がすでに入っている場合は Validate Key Pair を実行し、ビルド出力フォルダーを空にしてから再ビルドしてください。

症状 2 — ビルドの開始直前に "no manifest signing public key is configured" でビルドが中断される

OZeroSecurityConfig.Integrity.ManifestSigningPublicKey が空のときに発生します。解決: Window > OZero Security > Config & Dashboard を開き、Build Integrity セクションの Generate Key Pair をクリックしてから再度ビルドしてください。

症状 3 — ランタイムのログ: "Manifest signing public key does NOT match the pinned trust anchor fingerprint — APK appears to have been repacked with attacker-controlled keys"

OZeroSecurityConfig の公開キーと OZeroManifestTrustAnchor に記録された fingerprint が一致しないときに発生します。キーペアの一部だけを復元した場合や、生成されたファイルを手動で編集した場合によく発生します。解決: Validate Key Pair を実行してください。不一致が報告された場合は、対応する PEM を復元するか新しいキーペアを生成し、integrity manifest を再生成して clean build を作成してください。配布済みビルドでのみこのメッセージが表示される場合は、APK または実行ファイルが再パッケージされていないかも確認してください。

症状 4 — キー回転後、新しいビルドで manifest 検証に失敗する

回転したキーセットの一部が古い値のままになっている可能性があります。公開キー、fingerprint、manifest、signature が同じキーを基準に一致しているか確認してください。解決: 移行期間が必要な場合だけ以前の fingerprint を PreviousPublicKeyFingerprintHex に維持し、Validate Key Pair 実行、integrity manifest 再生成、ビルド出力フォルダーの整理、clean build の順に再ビルドしてください。

症状 5 — ローカルのビルドは成功するが、CI のビルドが "private key not found" または誤ったキーで署名される

CI にはローカル PC の OZeroSigningKeys/manifest_private_key.pem が自動では存在しません。解決: PEM を CI Secret に保管し、Unity ビルドの直前に既定パス、または Manifest Signing Private Key Path に指定したパスへ復元してください。すべてのリリースランナーが同じ PEM を使用する必要があり、リリース環境でも一度 Validate Key Pair を実行して確認することを推奨します。

インストール元の設定

ゲームが承認されたストアまたは経路からインストールされた場合にのみ実行されるように制限します。サイドロードや再パッケージされた APK の防止に役立ちます。

Steam Anti-Piracy の設定

Steam に配布される PC ビルドで Steam の実行の経路、App ID、権限の状態、リリースの設定を確認します。Standard はローカルの検証であり、Steam サーバーを通じたより強い所有権の検証は Pro のサーバー Steam Attestation で提供します。

デバイスバインディング設定

最初に信頼した端末の識別情報を保存し、以降の起動時に同じ端末かどうかを比較します。同じアカウントや保護されたセーブデータが別の端末へ移されたかを確認するために使います。

運用での使い方

Pro では Device Binding を運用ツールとして使えます。サーバーがライセンスごとの端末フィンガープリントを記録するため、繰り返しリスクが出る端末をブロックし、安易なライセンス共有を減らし、正当な端末変更はライセンス全体を止めずにサポートできます。

Reset Token サポート手順

1. 端末リセットが必要な理由とプレイヤーアカウントを、通常のサポート手順で先に確認します。
2. Customer Portal → Device Binding で対象端末を選び、Reset Token を発行します。
3. トークンは認証済みのサポートチャネルでのみ渡してください。公開チャット、スクリーンショット、長く残るチケットに残さないでください。
4. ゲームまたはサポート用 UI から、トークンを OZeroDeviceBindingDetector.Instance?.ClearStoredFingerprint(token.Trim()) に渡します。
5. SDK がトークンを受け入れた後、アプリを再起動するか保護初期化フローをもう一度実行すると、現在の端末フィンガープリントが再登録されます。

Speed & Time Hack 設定

Unity 時刻、ネイティブ基準時計、バックグラウンドタイマー、Web/Pro サーバー時刻を比較し、ゲーム速度を速く/遅くする操作や端末時計の変更を検出します。

Time.timeScale ではなく OZeroTime.timeScale を使用する

Speed & Time Hack 保護モジュールが有効な状態では、プロジェクトコードから Unity 標準の Time.timeScale を直接変更しないでください。OZero を経由せず直接変更すると、OZero detector は外部チートツールによる疑わしいランタイム時間操作として扱い、設定された応答ポリシーを実行する可能性があります。

OZeroSecurityConfig.TimeScaleTamperExemptions は、直接 Time.timeScale へアクセスする必要があるスクリプトを登録する例外リストです。このリストは最小限にしてください。

構造上、直接 Time.timeScale にアクセスせざるを得ない検証済みの外部プラグインや legacy adapter script にのみ限定して割り当ててください。

それ以外のすべてのゲームロジックでは、例外なく OZeroTime.timeScale を優先してください。一時停止、スローモーション、カットシーン速度制御、倍速再生など、ゲーム内で意図的に速度を変更する場合は必ず OZeroTime.timeScale を使用してください。

using OZeroSDK.Security;

// Correct: the detector knows this is an intentional game-side change.
OZeroTime.timeScale = 0.5f;

// Avoid: this bypasses OZero's expected time-scale tracking.
Time.timeScale = 0.5f;

長時間ロード中の意図しない Watchdog 終了を防ぐ

OZero のネイティブ Watchdog は、Unity のメインスレッドが動き続けているかを定期的な heartbeat で確認します。リリースビルドの heartbeat 期限はすべてのプラットフォームで約 10 秒です(起動時の猶予の後)。期限を超えると Watchdog はまずメインスレッドが何をしているかを見ます。スレッドがブロックされ CPU を使っていない状態(長い同期ロード、ログのフラッシュ、ディスク I/O、仮想マシンによる一時停止)はストールとして記録のみ行い、ゲームが動き続けているのに heartbeat だけが来ない場合は改ざんとみなして設定された対応ポリシーに従って終了します。5 分以上停止したプロセスは応答なしとして終了します。

大きなシーンのロード、同期的なアセット解凍、シェーダー warmup、Addressables の準備など、メインスレッドを数秒以上意図的にブロックする正当な処理でも、この状況は発生する可能性があります。

このような信頼できるロード境界は OZeroWatchdog.BeginLoadingGrace(maxGraceMs) で囲んでください。ロード開始時に grace が始まり、scope が dispose されるか End() が呼ばれた瞬間に終了するため、正確なロード時間を事前に知る必要はありません。

using OZeroSDK.Security;
using UnityEngine.SceneManagement;

public void LoadLargeScene()
{
    using (OZeroWatchdog.BeginLoadingGrace(60000))
    {
        SceneManager.LoadScene("Battle", LoadSceneMode.Single);
        // Grace ends as soon as the using scope exits.
    }
}

public void WarmUpLargeAssets()
{
    OZeroWatchdog.RunWithLoadingGrace(() =>
    {
        BuildLargeRuntimeCache();
    }, 60000);
}

物理ハック検出器

Injection Detector 設定

実行中のゲーム内部に入り込むプログラムを検知します。注入されたネイティブモジュール、実行可能なプライベートメモリ、インラインフック、リモートスレッド型の注入、高リスクのプロセスハンドル、WebGL ランタイム改ざんが対象です。正規のオーバーレイやキャプチャツールも同じ経路でゲームに入るため、検知器はすべてのモジュールをファイルハッシュと署名者で識別し、モジュールごとに判断できるようにします。

検知器がモジュールを識別する方法

検知器は数秒ごとにゲームプロセスに読み込まれた全モジュールを走査し、起動時の一覧と比較します。新しいモジュールはファイルハッシュで、Windows・macOS では署名証明書の指紋でも識別します。規則はモジュール自体だけを見てインストールフォルダー名は見ないため、正規のプログラムがインストールパスのせいで誤検知されることはありません。

チェックは検知ファミリーごとに検知、走査済み正常、まだ時期でないの 3 つのいずれかで答えます。実際のサンプルだけがカウンターを動かし、実行されなかったチェックは以前の検知を消さず、まったく実行できなかったチェックは正常ではなくスキャナーの健全性問題として報告されます。

Pro: ポータルから検出モジュールを許可 / ブロック

enableServerWhitelist を有効にすると、Pro ビルドは起動時と serverWhitelistRefreshInterval ごとに署名付きの判定リストを 1 つダウンロードします。このリストは、顧客ポータル(インジェクション → 検知状況 → 検出モジュール)でチームが下した判定と、OZero が全顧客データから下した判定を統合したものです。

• リストはライセンスにバインドされ、ライセンスサーバー鍵(Ed25519)で署名されます。SDK はアクティベーションで既に信頼している同じ公開鍵で検証します。
• 検証済みのリストは端末に保持され、オフライン起動でも適用されます。検証に失敗したリストは受け入れられず、検知自体が無効になることはありません。
• 一度も接続していない端末はビルド同梱のベースライン信頼リストだけを使います。その後の更新でサーバーに届けばリストを取得してキャッシュします。
• OZero がブロックしたモジュールを自プロジェクトが許可した場合、ポータルのOZero と自プロジェクトの判定が異なるとき設定がどちらに従うかを決めます(既定: OZero)。自プロジェクトがブロックしたモジュールは常にブロックされます。
• ABI 21 の SDK は Windows・macOS モジュールのコード署名主体(例: Discord Inc.)も報告するため、ポータルは証明書の指紋の横に会社名を表示できます。iOS・Android のモジュールには読み取れる署名者がありません。
• 検知器が確認したがまだ対処していないモジュールは、ポータルの 観測されたモジュール 一覧にソース 終了前の候補 として載ります。プレイヤーが影響を受ける前に許可か遮断を決められます。端末でコード署名の証明書チェーンが検証されたモジュールは 信頼された署名 と表示され、identity 規則が自動的に終了することはなく、判定を待ちます。

スキャナー利用不可 (abort code 0x15)

ネイティブスキャナー自体が動作できない場合(設定の適用失敗、繰り返されるネイティブスキャンエラー、managed/native の契約不一致)、SDK は ModulationType.InjectionScannerUnavailable(値 10、abort code 0x15、message key injection_scanner_unavailable)を報告し、ForceQuitOnDetection が無効でもゲームを終了します。攻撃の検知ではなく、静かに壊れたスキャナーがゲームを無防備にするのを防ぐための動作です。プレイヤーには OZ-SEC-15 のようなサポートコードを表示し、ログには abort code を残してください。

PlayerPrefs 暗号化

保護が必要な新しい key は、Unity の PlayerPrefs ではなく OZeroSafePlayerPrefs に保存してください。よく使う Get/Set、HasKey、Delete、Save 形式はなじみのある名前で提供されますが、暗号化されたデータは既存の plain PlayerPrefs データとは互換性がありません。

using OZeroSDK.Security;

// Save a value
OZeroSafePlayerPrefs.SetInt("score", 4200);
OZeroSafePlayerPrefs.SetFloat("volume", 0.8f);
OZeroSafePlayerPrefs.SetString("username", "Hero");

// Read a value
int    score    = OZeroSafePlayerPrefs.GetInt("score", 0);
float  volume   = OZeroSafePlayerPrefs.GetFloat("volume", 1.0f);
string username = OZeroSafePlayerPrefs.GetString("username", "");

セーブファイルの暗号化

セーブファイルを暗号化するには、File.ReadAllText / File.WriteAllText の代わりに OZeroSV_File を使用してください。ファイルは書き込み時に自動的に暗号化され、読み込み時に復号されます。ロード時に改ざんの有無も検査します。

using OZeroSDK.Security;

string path = Application.persistentDataPath + "/save.json";

// Write encrypted file
OZeroSV_File.WriteAllText(path, jsonString);

// Read and decrypt file
string json = OZeroSV_File.ReadAllText(path);

4 インゲーム変数の保護（Secure Types）

Secure Types は、通常の C# 変数型を暗号化された型に置き換えます。値が Native C++ ヒープに保存されるため、Cheat Engine のようなツールではメモリをスキャンしても見つけることができません。型の名前を変更するだけで、残りのコードはそのまま動作します。

サンプルコード

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using OZeroSDK.Security;

public class PlayerStats : MonoBehaviour
{
    [SerializeField] OZeroSV_Int Gold = 5000;
    [SerializeField] OZeroSV_Float Speed = 3.5f;
    [SerializeField] OZeroSV_Int HP = 1000;
}

サポートタイプ

7 セキュリティイベント処理（選択）

基本的に OZero は脅威を検知すると、設定された対応ポリシーに従ってアプリを終了するかログのみを残します。直接警告画面を表示したり、独自のサーバーログを送信したり、終了直前に保存処理をしなければならない場合はコールバックを登録できます。コールバックは OZeroSecurityEvent を通じて変調タイプ、中断コード、メッセージキー、詳細メッセージ、終了予定の可否を一緒に伝達します。

using UnityEngine;
using OZeroSDK.Security;

public class SecurityHandler : MonoBehaviour
{
    void OnEnable()
    {
        // RegisterUserCallback runs on the user chain only.
        // The built-in default handler runs independently and cannot be silenced.
        OZeroSecurityManager.Instance.RegisterUserCallback(OnThreatDetected);
    }

    void OnDisable()
    {
        OZeroSecurityManager.Instance.UnregisterUserCallback(OnThreatDetected);
    }

    void OnThreatDetected(OZeroSecurityEvent evt)
    {
        // evt contains Type, AbortCode, AbortCodeHex, MessageKey, Message, and WillAbort.
        Debug.LogWarning(
            $"OZero threat: {evt.Type} {evt.AbortCodeHex} {evt.Message}");

        switch (evt.Type)
        {
            case ModulationType.SpeedHack:
                // e.g. kick the player, show warning, report to server
                break;

            case ModulationType.BuildIntegrity:
                // evt.WillAbort is usually true for fatal build integrity violations.
                break;

            case ModulationType.Injection:
                break;
        }

        if (evt.WillAbort)
        {
            // Last chance to flush your own analytics or save state.
        }
    }
}

OZeroSecurityEvent、ModulationType、OZeroAbortCode の全体リストは API レファレンスに文書化されています。

ポータルポリシーコールバック

Customer Portal のポリシーは段階的に運用できます。Observe は証拠のみを記録し、Callback はサーバー発行の policy action をゲームへ配信し、Device Block は以降のサーバー検証で対象デバイスをブロックします。より強いデバイスブロックを使う前に、ゲーム側で警告表示、マッチメイキング制限、再ログイン要求、サポート案内を処理したい場合は Callback を使用してください。

using UnityEngine;
using OZeroSDK.Security;

public class PolicyActionHandler : MonoBehaviour
{
    void OnEnable()
    {
        OZeroSecurityManager.Instance.RegisterUserPolicyActionCallback(OnPolicyAction);
    }

    void OnDisable()
    {
        OZeroSecurityManager.Instance.UnregisterUserPolicyActionCallback(OnPolicyAction);
    }

    void OnPolicyAction(OZeroPolicyActionEvent evt)
    {
        Debug.LogWarning(
            $"Policy callback: {evt.Module}, score={evt.Score}, reason={evt.Reason}");

        if (evt.Score >= 80)
        {
            // Show your own UI, limit sensitive actions, or ask the player to reconnect.
        }
    }
}

次のステップ

これで OZero の核心の保護機能が実行中です。API レファレンスですべてのクラス、メソッド、設定オプションを詳しく確認してみてください。

トラブルシューティングリファレンス

Use this section when an OZero dialog appears, a security log is reported, or the app closes for a security reason. Start with the code shown on screen or in the log, then follow the first checks below.

Support Codes

Support codes are short labels shown in OZero dialogs and logs. When a player sends this code to support, the development or QA team can quickly identify which broad area to check. OZ-SEC-* means a security event was reported, and OZ-MV-* means an online or managed verification state needs attention.

Abort Codes

Abort codes are stable categories used in logs, callbacks, and OZ-SEC-* support codes. They tell the development team which protection area responded without exposing detailed evidence to the player.

For API fields and callback examples, see OZeroAbortCode & Event Messages.

解決手順