はじめに

概要

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 / Plus / Pro

OZero Security は Standard、Plus、Pro の3つのティアーで提供されます。Standard はサーバーの連携なしでローカルの保護機能を使用します。Plus はプロジェクト別の Native Variant パッケージとマニフェスト / Bundle ID バインディングを追加します。Pro は Plus の構成を含み、テレメトリー、署名されたサーバー時間、リモートポリシー、サーバー検証、デバイスの限度などの運用機能を提供します。

Plus / Pro ライセンスキーの登録

Standard は追加のライセンス設定なしで使用できます。Plus または Pro を使う場合は、Unity で OZeroLicenseConfig アセットを作成し、プロジェクトに発行されたライセンスキーを入力します。Plus キーは、ポータルからプロジェクト専用 Native Variant パッケージをダウンロードし、ビルド時にそのパッケージが現在のプロジェクト用か確認するために使われます。Pro キーはさらに、実行時のサーバー有効化と Pro 専用サーバー機能にも使われます。

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 である必要があります。

サーバーの活性化のフロー

Pro ライセンスはアプリ開始時に SDK が自動で確認します。この処理はゲーム開始を止めないように設計されています。サーバー応答が遅い場合やネットワークが一時的に切れた場合は、まず保存済みの有効化情報を確認し、使用できる情報があればその状態で続行します。

ブートシーケンス

1. SDK はアプリ開始時にライセンスランタイムを自動で初期化します。
2. Standard と Plus はランタイムサーバー有効化が不要なため、すぐにローカル保護機能を実行します。
3. 任意の Pro サーバー機能を設定した場合、バックグラウンドで /v1/activate リクエストを送り、現在のライセンスとデバイス状態を確認します。
4. 有効化に成功すると、テレメトリ、署名済みサーバー時刻(signed time)、ビルド検証(attestation) などの Pro サーバー機能を使用できます。
5. サーバーメンテナンス、一時的なネットワークエラー、タイムアウトが発生した場合、SDK は可能であれば保存済みの有効化情報を使います。使用できる保存情報がない場合、またはライセンスが期限切れ、停止、失効している場合は、選択した Pro サーバー機能だけが利用不可または制限状態になります。取得済みの Native Variant とローカル保護はそのまま継続します。

送信される情報

有効化リクエストは小さな JSON POST です。基本リクエストには licenseKey、deviceId、sdkVersion、platform が含まれます。Unity が値を提供できる場合は、appIdentifier、companyName、productName、webglOrigin も一緒に送信されます。deviceId は既定で Unity のデバイス識別子を使いますが、必要に応じて OZeroLicenseRuntime.DeviceIdProvider でゲームアカウント ID や独自 UUID に変更できます。

POST https://api.ozerosecurity.com/v1/activate
Content-Type: application/json

{
  "licenseKey":    "OZ-PRO-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX",
  "deviceId":      "<DeviceIdProvider result; default SystemInfo.deviceUniqueIdentifier>",
  "sdkVersion":    "<OZeroSdkVersion.ManagedVersion>",
  "platform":      "<android | ios | windows | macos | linux | webgl | ...>",
  "appIdentifier": "<Application.identifier>",
  "companyName":   "<Application.companyName>",
  "productName":   "<Application.productName>",
  "webglOrigin":   "<WebGL origin only>"
}

サーバーは署名済みトークン、決定されたティア、使用可能な機能一覧、サーバー機能の有効状態、トークンの有効期限、サーバー到達不能時のポリシーを返します。SDK は設定された公開鍵で署名済みトークンを検証してから Pro 機能を信頼します。

サーバーの機能を使用できない場合

サーバーメンテナンス、ネットワークタイムアウト、ライセンスの期限切れ/停止/失効、Bundle ID 不一致は、すぐに改ざんとは判断しません。この場合は選択した Pro サーバー機能だけが利用不可または制限状態になり、取得済みの Native Variant とローカル保護はそのまま継続します。一方、ビルド不一致、ブロックされたビルド、インジェクション、デバッガーのように改ざんが明確な状態は、設定された対応ポリシーに従います。

オフラインの動作

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

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

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

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

任意の Pro サーバー機能を有効にした場合、オンラインで /v1/activate を使って端末とライセンスを確認します。SDK は結果を暗号化して PlayerPrefs に保存し、選択したサーバー機能が一時的な切断に耐えられるようにします。このアクティベーションは、取得済み Native Variant のビルドやローカル保護を制限しません。

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

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

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

推奨値の ApplyCachedBlockPolicies を使うと、保存済みのブロックリストが有効な間は、プレイヤーが機内モードで起動してもブロック対象のビルドは Build Integrity で拒否されます。ポータルでブロックルールを変更した後は、各端末が一度オンライン認証に成功して新しいルールを受け取る必要があります。

トラブルシューティング

問題が起きたら、まず 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 としてアクセスします。

共通設定

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

検証用 UI 管理

Pro Only 機能です。Build Integrity と Steam DRM などで使用するオンライン再検証、ネットワーク再試行、ブロック/終了案内ダイアログを設定します。optional OZero TMP dialog package をインポートする前に、Package Manager から Unity UI と TextMeshPro をインストールしてください。Unity 6 では TextMeshPro は Unity UI 2.x に含まれます。TextMeshPro を使わないプロジェクトでは Custom UI / Callback Only を使用してください。

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 で確認します。リリースビルドでは、非 Android プラットフォームは約 6 秒、Android は起動猶予後に約 10 秒の heartbeat deadline を使用します。その間に heartbeat が届かない場合、アプリが停止したと判断され、設定された応答ポリシーに従って終了することがあります。

大きなシーンのロード、同期的なアセット解凍、シェーダー 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 設定

想定外のネイティブモジュール読み込み、実行可能な private memory、inline hook、remote thread 型の注入、危険な外部プロセス handle、WebGL ランタイム改ざんシグナルを検出します。

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 レファレンスですべてのクラス、メソッド、設定オプションを詳しく確認してみてください。