はじめに

概要

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

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

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

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

2 ダッシュボードを開く

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

カスタムエディターウィンドウが開きます。これがすべての OZero セキュリティモジュールを制御する中央パネルです。Project ヒエラルキーは一切操作する必要がなく、すべてここで管理します。

3 モジュールの有効化

ダッシュボード内に、トグルスイッチ付きの利用可能なセキュリティモジュール一覧が表示されます。使用したいモジュールを有効化してください。推奨の初期構成は以下のとおりです。

セキュリティプリセット

まずプリセットを選び、プロジェクト固有の方針が必要な場合だけ個別モジュールを調整してください。一般的なライブゲームでは、保護性能、実行負荷、誤検知リスクのバランスがよい Standard から始めることを推奨します。

「Auto Setup」ボタンを押す必要はありません。ダッシュボードで有効化したいモジュールをトグルし、OZeroSecurityConfig アセットを保存してください。プレイヤー起動時、SDK がゲームプレイ開始前に有効な検出器を自動で準備します。

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

OZero Security は3つのティアで提供されます。Standard は共有ネイティブモジュールを使う完全サーバーレスです。Plus はサーバーレスのまま、マニフェストと Bundle ID で紐付けたアプリ別 Native Variant パッケージを追加します。Pro は Plus を含み、Cloud Telemetry、Signed Time、リモートポリシー、attestation、デバイス数上限などのサーバー側機能を解放します。

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

Standard ティアにはセットアップが不要です。Plus または Pro では、ScriptableObject アセットを1つ追加し、購入後に受け取ったキーを貼り付けます。Plus はプロジェクト紐付けの Variant 検証とポータルダウンロードにキーを使用し、Pro はさらにランタイムのサーバーアクティベーションにも使用します。

1. Config アセットの作成

OZero Security の Config & Dashboard（メニュー: OZero Security → Security → Config & Dashboard）を開き、License & Server セクションを見つけて Create OZeroLicenseConfig をクリックします。アセットが作成され、正しい Resources/ フォルダーへ自動配置されます — 手動のドラッグ＆ドロップは不要です。

2. Inspector フィールドの入力

3. ビルドと確認

コード変更は不要です。OZeroLicenseBootstrap が [RuntimeInitializeOnLoadMethod(AfterAssembliesLoaded)] で自身を接続し、アプリ起動時にアセットを読み取ります。初回起動時に Player ログで [OZeroLicense] activated; tier=pro caps=5 のような行を確認してください。Pro 設定があるのに [OZeroLicense] Standard / serverless mode. と表示される場合は、アセットが Resources/ フォルダー配下にあり、名前が OZeroLicenseConfig（拡張子なし、リネーム接尾辞なし）であることを再確認してください。

サーバーアクティベーションフロー

アクティベーションフローはアプリ起動時にバックグラウンドで実行されます。SDK がこれによってシーン読み込みをブロックすることはありません — 6秒のタイムアウト時でもキャッシュ済み権限（または Standard フォールバック）が使われるため、プレイヤーが HTTP を待って黒画面で固まることはありません。

起動シーケンス

1. SDK は起動時にライセンスランタイムを自動初期化します。
2. Standard と Plus はランタイムサーバー呼び出しなしで続行します。
3. Pro はバックグラウンドで軽量なアクティベーション要求を送信します。
4. アクティベーションに成功すると、telemetry、signed time、attestation などの Pro サーバー機能が利用可能になります。
5. アクティベーションが失敗、期限切れ、タイムアウトしても、プレイヤーにエラーを表示せず Standard モードでゲームプレイを継続します。

通信で送られる内容

アクティベーション要求は小さな JSON POST です。必須フィールドは licenseKey、deviceId、sdkVersion、platform です。appIdentifier、companyName、productName、webglOrigin は Unity が空でない値を提供した場合のみ追加されます。デバイス ID の取得元は OZeroLicenseRuntime.DeviceIdProvider で上書きできます。

POST https://api.ozero.security/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>"
}

サーバーは、JWT 形式の signedToken（header.payload.signature、base64url、パディングなし）、解決された tier、capabilities 配列、serverFeaturesEnabled フラグ、そして（任意で）expiresAt（unix-ms）を含む JSON ボディで応答します。SDK は serverPublicKeyHex を用いて signedToken に対し電子署名検証を実行し、それを通過した場合にのみ権限を受け入れます — それ以外はすべてフェイルクローズです。

グレースフルデグラデーション

サーバーメンテナンス、ネットワークタイムアウト、ライセンス期限切れ、停止、失効、バンドル不一致は改ざんとして扱われません。これらは Pro 専用機能を Standard/サーバーレスモードへ下げ、プレイヤーのセッションは維持されます。ビルド不一致、ブロック済みビルド、インジェクション、デバッガー検知といった確定した改ざん状態は、設定された脅威応答ポリシーに従います。

オフライン動作

OZero は、ネットワーク状態に関わらずプレイヤーが常にゲームを起動できるよう設計されています。正確な挙動はティアによって異なります:

Standard — 常にオフライン

サーバーへは一切接続しません。9つの検出器モジュールはすべて劣化なく動作します。ライセンスランタイムは IsServerless = true と HasEntitlement = false を設定します。OZeroTelemetryReporter はアタッチされますが、すべてのイベントで何もしません。

Pro — TTL 内はオフライン可

あるデバイスで最初の /v1/activate が成功すると、権限が PlayerPrefs にキャッシュされます（デバイス紐付けキーで暗号化 — 下記のキャッシュセキュリティ参照）。以降の起動ではネットワーク呼び出しが始まる前にキャッシュが同期的に読み込まれるため、プレイヤーがオフラインでも SDK はどのティアか、どの機能が解放されているかを把握できます。

キャッシュ済み権限は、アクティベーション時に書き込まれた cachedAtMillis スタンプから tokenTtlSeconds の間信頼されます。既定は7日（604800）です。ずっとオフラインだったデバイスで TTL が切れると、キャッシュは破棄され、SDK は次回のアクティベーション成功まで Standard 相当の機能に劣化します。検出器は動作を続け、テレメトリ送信と署名時刻検証のみがオフになります。

Pro — 署名済みオフライン遮断ポリシー

Graceful degradation は、ライセンス、ネットワーク、サーバー可用性の問題に対する動作です。ポータルで明示的に遮断したビルドがオフラインで許可される、という意味ではありません。Pro アクティベーションが成功すると、サーバーは現在のポータル遮断ポリシーをアクティベーショントークンに署名して含め、SDK はそのポリシーを entitlement とは別にキャッシュします。

推奨の ApplyCachedBlockPolicies モードでは、署名済みポリシーが有効な間、プレイヤーが機内モードで起動しても、遮断された manifest hash、SDK バージョン、アプリバージョンは Build Integrity によって拒否されます。ポリシーは署名トークンの TTL に従うため、ポータルで遮断ルールを変更した後は一度オンラインでアクティベーションしてください。

トラブルシュート

すべてのライセンスイベントは OZeroSecLog を通じて記録され、既定では Unity の Debug.Log にルーティングされます（OZeroSecurityConfig で設定可能）。Player ログを [OZeroLicense] プレフィックスで絞り込むと起動時の判断が、[OZeroTelemetry] でレポーターの動作が確認できます。よくある症状と対処:

プロジェクト設定

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

最小ビルドターゲット

Android ProGuard / R8 設定

OZero Security は別途の Java SDK パッケージを必要としません。ただし Minify、ProGuard、R8 を有効化した Android リリースビルドでは、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 ウィンドウで選択して、すべてのセキュリティモジュール設定を確認・調整できます。Config はシングルトンで、ランタイムでは OZeroSecurityConfig.Instance でアクセスします。

一般設定

これらの最上位フィールドは、すべてのモジュールに共通で適用されます。

応答設定

いずれかのセキュリティモジュールが検知イベントを発生させたときの動作を制御します。

ビルド整合性設定

改変されたゲームファイル、デバッガーの接続、不審な実行環境を検知するビルド整合性検証器を設定します。

RSA 署名キーの生成（ビルド整合性）

Build Integrity を有効にし、Require Manifest Signature をオンにした場合、OZero は公開鍵署名（非対称署名）を用いて、整合性マニフェストが差し替えや改ざんを受けていないことを保証します。リリースビルドを作成する前に、Unity エディター内でキーペアを生成する必要があります。

マニフェスト署名の仕組み

ビルド時に OZero は秘密鍵でアセンブリマニフェストに署名し、その署名をビルドに埋め込みます。ランタイムでは、OZeroSecurityConfig に保存された公開鍵でその署名を検証します。署名が一致しない場合 — つまりマニフェストまたはバイナリが改変された場合 — ゲームはそれを改ざんとみなし、Response Settings に従って対応します。

キーペアの生成

1. Unity エディターで、Project ウィンドウの OZeroSecurityConfig を選択します。
2. Inspector で Build Integrity セクションを展開します。
3. Require Manifest Signature チェックボックスを有効にします。
4. Generate Key Pair ボタンをクリックします。
5. OZero が公開鍵署名のキーペアを生成します。公開鍵は OZeroSecurityConfig に直接書き込まれます（Assets に保存）。秘密鍵は次の場所に保存されます:
   [ProjectRoot]/OZeroSigningKeys/manifest_private_key.pem
6. 確認ダイアログに秘密鍵の保存場所が表示されます。OK をクリックして閉じます。

⚠ 重要 — 秘密鍵の安全管理

• 秘密鍵ファイルは Assets/ フォルダーの外側に保存され、Unity がビルドに含めないようになっています。Assets/ 内に移動しないでください。
• OZeroSigningKeys/ をすぐに .gitignore に追加してください。秘密鍵をバージョン管理にコミットすることは重大なセキュリティリスクです。
• 秘密鍵を安全なオフラインの場所（暗号化 USB ドライブ、パスワードマネージャーなど）にバックアップしてください。このファイルを持つ者は、あなたのゲーム向けに正当なマニフェストを偽造できます。
• 秘密鍵を失った場合、新しいキーペアを生成する必要があります。新しい公開鍵は次のビルドに埋め込まれます。古い署名を持つ既出荷ビルドはすべてマニフェスト検証に失敗するため、差し替えが必要になります。

カスタム秘密鍵パス（CI/CD・チーム）

Manifest Signing Private Key Path フィールド（Inspector の Manifest Signing — Editor Only 配下に表示）で、秘密鍵の別の保存場所を指定できます。次の2つの場面で有用です:

• CI/CD パイプライン — 秘密鍵を CI シークレットとして保存し、ビルド時にそのパスを注入することで、ビルドマシンが鍵を永続的にディスク上へ持つ必要がなくなります。
• チーム環境 — 鍵を共有の安全なサーバーやシークレットマネージャーに保管し、マウントしたパスをフィールドに指定します。リリースビルドを実行するメンバーだけがアクセスできれば十分です。

既存キーペアの検証

ディスク上の秘密鍵が OZeroSecurityConfig に保存された公開鍵とまだ一致しているか不明な場合は、Validate Key Pair ボタンをクリックしてください。OZero が小さなテストペイロードに秘密鍵で署名し、公開鍵で検証します。一致すれば成功通知が表示されます。一致しない場合は、新しいペアを生成する必要があります。

キーペアを再生成すべきタイミング

• 秘密鍵を紛失または漏洩した。
• Validate Key Pair が不一致を報告した（鍵が同期していない）。
• 計画的なセキュリティポリシーの一環として意図的にキーをローテーションする。

再生成後、新しい公開鍵は次のビルドに自動で埋め込まれます。既出荷ビルドは新しい公開鍵ではマニフェスト検証に失敗するため、アップデートを配信する必要があります。

デュアル指紋によるキーローテーション（無停止）

Generate Key Pair ボタンは、公開鍵を同時に2か所へ保存します: OZeroSecurityConfig（Assets 内の ScriptableObject）の中、そして Assets/OZeroSDK/Scripts/Security/BuildIntegirity/OZeroManifestTrustAnchor.cs 内の SHA-256 フィンガープリント定数としてです。ランタイムでは SDK がまず、アセット内の公開鍵がアセンブリにピン留めされた指紋と一致するかを確認します — 一致しない場合、RSA 署名のチェック前にマニフェストが拒否されます。これにより、アセットと .sig ファイルの両方を攻撃者所有のキーに差し替える再パッカー攻撃を防ぎます。

2つの指紋スロット

OZeroManifestTrustAnchor.cs の中には2つの const スロットがあります: ExpectedPublicKeyFingerprintHex（現行の本番指紋）と PreviousPublicKeyFingerprintHex（任意の2つ目の指紋。定常状態では空）です。Matches() 検証器は、ライブの SPKI ハッシュがいずれかの値と等しければ true を返し、定数時間 XOR 比較を使用します。このデュアルスロット方式が、ホームページの「無停止キーローテーション」機能の基盤です。新しくビルドした SDK は、限定された猶予期間の間、新しいキー（Expected）と古いキー（Previous）の両方を信頼できるため、新リリースを配信する間も古い出荷ビルドは自分の古いマニフェストを検証し続けられます。

ローテーション手順（手動だが5分で完了）

1. 現在の指紋を控える。 Assets/OZeroSDK/Scripts/Security/BuildIntegirity/OZeroManifestTrustAnchor.cs を開き、ExpectedPublicKeyFingerprintHex の値をクリップボード（またはメモ用ファイル）にコピーします。
2. previous スロットに移す。 同じファイルで、その値を PreviousPublicKeyFingerprintHex（通常は ""）に貼り付けます。保存します。
3. 新しいキーペアを生成する。 OZeroSecurityConfig の Inspector で Generate Key Pair をクリックします。ダイアログが、これにより以前にベイクしたマニフェストが無効になる旨を警告するので Regenerate をクリックします。新しい秘密鍵が PEM ファイルに書き込まれ、新しい公開鍵がアセットの値を置き換え、新しい SHA-256 指紋が ExpectedPublicKeyFingerprintHex に自動注入されます。手順2の PreviousPublicKeyFingerprintHex はそのまま残ります。
4. 新しい SDK リリースをビルドして配信する — 通常のパッチ/ストアチャネル経由で。このビルドの新しいマニフェストは新しい秘密鍵で署名されます。
5. フリートの切り替わりを待つ。 猶予期間の間、新しいビルドは両方のキーを信頼し、古いビルド（Expected として古い指紋のみをピン留め）は自分の古いマニフェストを検証し続けます。どちらの経路も壊れません。一般的な期間: ライブゲームで1〜4週間。
6. previous スロットをクリアする。 テレメトリで古いビルドが0%になったことを確認したら、PreviousPublicKeyFingerprintHex = "" に設定し、もう1度 SDK リリースを配信します。ローテーション完了です。

「強制アップデート不要」が成り立つ理由

古い出荷バイナリには、すでに古いキーで署名された古いマニフェストと、Expected スロットとして古い指紋の埋め込みコピーが含まれています — 動作を続けるのに新しいキーを知る必要はありません。新しいビルドが Previous スロットを必要とするのは、プレイヤーが期間中に強制再インストールや旧バージョンへのロールバックを行った場合に、キャッシュされた古いマニフェストが引き続き検証できるようにするためだけです。古いビルドが現場から消えたら、次のリリースで Previous をクリアできます。

トラブルシュート

以下の5つの症状はすべて同じ防御スタックに由来します — ビルド時の PreBuild バリデーター（OZeroBuildPreflightValidator）、起動時のアンカーガード（OZeroManifestTrustAnchor.ValidateConfigurationOrFail）、ランタイム検証器（OZeroBuildIntegrityValidator.VerifyManifestSignature）です。いずれの場合も対処は、3つの成果物（秘密鍵 PEM、OZeroSecurityConfig 内の公開鍵、OZeroManifestTrustAnchor 内の指紋）を再び同期させることです。

症状1 — リリースビルドが起動直後に reason code 0x0E（TRUST_ANCHOR_MISSING）で即座に abort する

ExpectedPublicKeyFingerprintHex が空文字列です。Editor および Development ビルドは警告付きで許容しますが、リリースビルドは信頼されないマニフェストを受け入れる前に起動時にフェイルファストします。対処: エディターで Generate Key Pair を1度実行してください — 指紋が const に自動注入されます。const がすでに埋まっているのにビルドが abort する場合は、アセンブリハッシュブロブ（oz_ahash.bin）が古い可能性があります — クリーンな状態から再ビルドしてください。

症状2 — コンパイル開始前に「no manifest signing public key is configured」でビルドが停止する

PreBuild バリデーター（callbackOrder 51）が OZeroSecurityConfig.Integrity.ManifestSigningPublicKey が空であることを検出しました。対処: Inspector で OZeroSecurityConfig を開き → Build Integrity を展開 → Generate Key Pair をクリックして再ビルドします。注: このチェックは Android / iOS（OS レベル署名）と IL2CPP Standalone（署名対象の個別 DLL ファイルがない）ではスキップされるため、キー欠落が止めるのは Mono Standalone ターゲットのみです。

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

OZeroSecurityConfig の公開鍵文字列のハッシュが、ExpectedPublicKeyFingerprintHex にも PreviousPublicKeyFingerprintHex にも一致しません。正当にビルドされたバイナリでは、手動編集で2つの成果物が同期しなくなった後に起こります。対処: エディターで Tools → OZero → Validate Manifest Signing Keys を実行してください — キーペアが整合していればツールが const を自動で書き直します。不一致を報告する場合は Generate Key Pair でペアを再生成してください。改ざんされたバイナリでは、このメッセージは意図したフェイルクローズ信号です — APK / .exe が再パッケージされていないか調査してください。

症状4 — ローテーション後、OLD の出荷ビルドのプレイヤーがマニフェスト検証に失敗し始める

ローテーション手順の手順2を忘れています。新しい SDK リリースが PreviousPublicKeyFingerprintHex = "" で出荷されたため、古いビルドをキャッシュ済みで強制再起動したプレイヤーは新しいキーで署名されたマニフェスト（古いビルドが信頼しない）に遭遇します — あるいはさらに悪いことに、強制再インストールで新しくキャッシュされた古いマニフェストが取得され、PEM がローテーション済みのため古いビルドの trust anchor で検証できません。対処: PreviousPublicKeyFingerprintHex に古い指紋を設定したホットフィックス SDK リリースを配信してください。次のマニフェスト取得は、いずれのキーでも検証されます。

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

CI マシンには OZeroSigningKeys/manifest_private_key.pem がディスク上に存在しません。.gitignore によって正しく除外されているためです。対処: PEM を CI シークレット（GitHub Actions Secret、GitLab Variable、Jenkins Credentials など）として保存し、Unity ビルドステップの前にパイプラインがワークスペースの OZeroSigningKeys/manifest_private_key.pem へ書き出すようにしてください。あるいは OZeroSecurityConfig の Manifest Signing Private Key Path を CI ランナーがマウントできるパス（例: シークレットマネージャーのマウント）に設定します。すべての CI ランナーが同じ PEM を使うようにしてください — 異なる PEM は、公開鍵が一致していても異なる署名を生成します。

インストール元設定

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

Steam Anti-Piracy設定

Steamで配布するPCビルドについて、Steam起動経路、App ID、権限状態、リリース設定を確認します。Standardはローカル検証であり、Steamサーバー証拠によるより強い所有権検証はProのServer Steam Attestationで提供します。

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

ハードウェア指紋を使ってゲームアカウントを最初のデバイスに紐付けます。別のハードウェアへのアカウント移行を検知します。

商用運用での目的

デバイスバインディングはProの運用レイヤーとして特に有効です。ライセンスをサーバー登録済みのハードウェア指紋に紐付けることで、リスクのあるデバイスの隔離、カジュアルなライセンス共有の抑制、正当なデバイス変更のサポートを、ライセンス全体を停止せずに行えます。

Reset Tokenサポートフロー

1. 通常のサポート手順でプレイヤーアカウントとリセット理由を確認します。
2. Customer Portal → Device Bindingを開き、対象デバイスを見つけてReset Tokenを発行します。
3. トークンは認証済みのサポートチャネルでのみ送信します。長期間残る公開チャットやスクリーンショットには保存しないでください。
4. ゲームまたはサポートUIはトークンを OZeroDeviceBindingDetector.Instance?.ClearStoredFingerprint(token.Trim()) に渡します。
5. SDKがトークンを消費した後、アプリを再起動するか保護された起動フローに再度入ると、現在のハードウェア指紋が再登録されます。

スピードハック設定

Unity の Time.realtimeSinceStartup を、ネイティブプラットフォームのタイマーや、任意で信頼できるウェブ時間ソースと比較して、タイムスケール操作（スピードハック）を検知します。

Physics Hack Detector

インジェクション設定

アセンブリインジェクション、DLL ハイジャック、IL2CPP パッチなどの不正なコードインジェクションを検知します。

PlayerPrefs の暗号化

Unity の PlayerPrefs に保存されるデータ（設定、ユーザー環境設定など）を保護するには、PlayerPrefs を OZeroSafePlayerPrefs に置き換えてください。API は同一です。

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 のようなツールでメモリをスキャンしても見つけられません。置き換えは型名を変えるだけで、15 種類の型に対応しており、一般的な数値型すべて、bool、string、Vector2、Vector3、バイト配列をカバーします。すべての演算子と暗黙的変換も同じように動作します。

対応する型

サンプルコード

// ── Before: plain C# variable ──────────────────────────────
using UnityEngine;

public class PlayerStats : MonoBehaviour
{
    public int   gold  = 0;
    public float speed = 5.0f;
    public int   hp    = 100;
}

// ── After: OZero Secure Types (only the type name changes) ──
using UnityEngine;
using OZeroSDK.Security;

public class PlayerStats : MonoBehaviour
{
    public OZeroSV_Int   gold  = 0;
    public OZeroSV_Float speed = 5.0f;
    public OZeroSV_Int   hp    = 100;

    // All arithmetic works exactly as before — no code changes needed
    void TakeDamage(int dmg) => hp -= dmg;
    void AddGold(int amount) => gold += amount;
}

7 セキュリティイベントの処理（任意）

デフォルトでは、OZero は設定された応答ポリシーに従ってアプリを終了するかログのみを残します。独自の警告画面、サーバーログ送信、終了前の保存処理が必要な場合はコールバックを登録できます。コールバックは OZeroSecurityEvent として、変調タイプ、abort code、メッセージキー、詳細メッセージ、終了予定かどうかを渡します。

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 Reference に記載されています。

次のステップ

これでコアの OZero 保護が動作しています。各クラス、メソッド、設定オプションの詳細は、API リファレンス全体をご覧ください。