はじめに

概要

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 エディターメニューの説明

OZeroSDK > Security メニューには、SDK の設定と診断コマンドがまとまっています。セキュリティプリセットは上部メニューではなく 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 は ScriptableObject エセットを1つ追加し、購入後に受け取ったキーを貼り付けます。Plus キーはプロジェクト別の Variant 検証とポータルのダウンロードに使用され、Pro キーはランタイムサーバーの活性化にも使用されます。

1. 設定エセットの生成

Config Dashboard (メニュー: OZeroSDK → Security → Config Dashboard) を開き、License & Server セクションで Create OZeroLicenseConfig ボタンをクリックします。エセットが自動的に正しい Resources/ フォルダに生成されるため手動で移動する必要はありません。

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

3. ビルド & 検証

コードの変更は必要ありません。アプリが開始されると SDK が OZeroLicenseConfig エセットを自動的に読み取ります。最初の実行の後 Player ログから [OZeroLicense] activated; tier=pro caps=5 と同じ列を確認してください。Pro として設定したのに Standard モードで実行されるというログが見える場合は、エセットが Resources/ フォルダーの下にあり、名前が正確に OZeroLicenseConfig か確認してください。

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

活性化はアプリ開始の際にバックグラウンドで進行されます。サーバーの応答が遅れたり一時的に失敗してもシーンのロードを止めず、保存された活性化の情報があればその値を使用します。

ブートシーケンス

1. SDK はアプリの開始の際、ライセンスランタイムを自動初期化します。
2. Standard と Plus はランタイムサーバー呼び出しなしに引き続き進行されます。
3. Pro はバックグラウンドで軽い活性化のリクエストを送ります。
4. 活性化に成功すればテレメトリー、signed time、attestation のような Pro サーバー機能が使用可能になります。
5. 活性化の失敗、満了、タイムアウトが発生してもプレイヤーにエラーを表示せず Standard モードで継続して実行されます。

ネットワークに流れるデータ

活性化のリクエストは小さな JSON POST です。必須フィールドは licenseKey、deviceId、sdkVersion、platform です。appIdentifier、companyName、productName、webglOrigin は Unity で空でない値を提供するときにのみ追加されます。デバイスの識別子のソースは 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>"
}

サーバーは署名されたトークン、決定されたティアー、使用可能な機能のリスト、満了時刻を JSON として返します。SDK は設定された公開キーで応答の署名を確認した後のみ Pro 機能を活性化します。

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

サーバーの点検、ネットワークのタイムアウト、ライセンス満了/停止/廃棄、Bundle ID 不一致はすぐにハッキングとして判断しません。この場合、Pro 専用の機能のみ非活性化し、基本の保護機能は継続して実行します。反対にビルド不一致、ブロックされたビルド、インジェクション、デバッガーのように改ざんが明確な状況は設定された対応のポリシーに従います。

オフラインの動作

OZero はネットワーク状態と無関係にプレイヤーが常にゲームを実行できるように設計されました。正確な動作はティアーによって異なります:

Standard — 常にオフライン

Standard はサーバーの活性化やテレメトリーの転送なしでローカルの保護機能のみ実行します。ネットワークがなくてもゲームはそのまま開始され、Pro 専用の機能のみ使用されません。

Pro — TTL 内のオフライン可能

指定デバイスで /v1/activate が初めて成功した後、Pro 活性化の情報は PlayerPrefs に保存されます(デバイスのバインディングキーで暗号化 — 下記のキャッシュセキュリティを参照)。以後の実行ではネットワーク呼び出しが始まる 前に 保存された活性化の情報を読むため、プレイヤーがオフラインであっても SDK はどんなティアーでどんな Pro 機能が使用可能かわかります。

保存された Pro 活性化の情報は活性化の時点に記録された cachedAtMillis から tokenTtlSeconds の間信頼されます。デフォルト 7日(604800)です。その間ずっとオフラインの状態で時間が過ぎれば保存された情報は廃棄され、次のオンライン活性化が成功するまで SDK は Standard レベルで動作します。ディテクターは引き続き動作し、テレメトリーの送信と signed-time 検証のみオフになります。

Pro — 署名されたオフラインのブロックのポリシー

サーバーの障害の際に基本の保護で継続して実行されることと、ポータルで明示的にブロックしたビルドを許可することは異なります。Pro 活性化が成功すればサーバーは現在のブロックのポリシーを署名された形で提供し、SDK はこれを別途に保存します。

推奨される値である ApplyCachedBlockPolicies モードでは、署名されたポリシーが有効な間にプレイヤーが機内モードで実行しても、ブロックされた manifest hash、SDK のバージョン、アプリのバージョンが Build Integrity で継続して拒否されます。ポリシーは署名トークンの TTL に従うため、ポータルでブロックのルールを変えた後は1度のオンラインの活性化が必要です。

トラブルシューティング

すべてのライセンスイベントは、基本的に Unity の Debug.Log にルーティングされる OZeroSecLog を通じて記録されます (OZeroSecurityConfig で設定可能)。Player ログを [OZeroLicense] プレフィックスでフィルタリングして起動時点の決定を確認し、[OZeroTelemetry] でレポーターを確認してください。一般的な症状と解決策:

プロジェクト設定

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

最小のビルドターゲット

リリースビルドの IL2CPP と Managed Stripping

Android、iOS、standalone のリリースビルドでは、Unity が対応している場合 IL2CPP を優先してください。IL2CPP はリバースエンジニアリングを不可能にするものではありませんが、平文の managed metadata 露出を減らし、OZero の native 整合性チェックにより強いリリース基準を与えます。

Project Settings > Player > Other Settings > Scripting Backend を IL2CPP に設定してください。リリースビルドの Managed Stripping Level はまず Low または Medium にし、対象デバイスでクリーンなスモークテストを実行します。reflection、serialization、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 としてアクセスします。

Common Setting

すべてのモジュールにグローバルに適用される最上位フィールドです。

Global Threat Response

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

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

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

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

ビル드 무결성 (Build Integrity) を有効化し、Require Manifest Signature をオンにした場合、OZero は公開キーに基づく署名で整合性マニフェストが変更されていないか確認します。リリースビルドを作成する前に、Unity エディターでキーペアを必ず生成してください。

マニフェスト署名の動作方式

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

キーペアを生成する

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

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

• 個人キーファイルは Unity がビルドに含めないように Assets/ フォルダの 外部 に保存されます。絶対に Assets/ の中に移動しないでください。
• OZeroSigningKeys/ を直ちに .gitignore に追加してください。個人キーをバージョン管理にコミットすることは深刻なセキュリティリスクです。
• 個人キーを安全なオフラインの場所（暗号化された USB ドライブ、パスワードマネージャーなど）にバックアップしてください。このファイルを持つ人は誰でも有効なマニフェストを偽造できます。
• 個人キーを紛失した場合、新しいキーペアを生成する必要があります。新しい公開キーは次のビルドに自動的に含まれます。既存にリリースされたビルドはすべて新しい公開キーでマニフェストの検証に失敗するため、アップデートをデプロイする必要があります。

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

インスペクターの Manifest Signing — Editor Only の下にある Manifest Signing Private Key Path フィールドで個人キーの代替の場所を指定できます。次の2つの状況で有用です:

• CI/CD パイプライン — 個人キーを CI シークレットとして保存し、ビルド時に経路を注入すれば、ビルドマシンがキーを永続的にディスクに保管しなくても済みます。
• チーム環境 — キーを共有セキュリティサーバーやシークレットマネージャーに保管し、フィールドをマウントパスとして指定します。リリースビルドを実行するチームメンバーだけがアクセス権限を持てば十分です。

既存のキーペアの検証

ディスクの個人キーと OZeroSecurityConfig に保存された公開キーが一致するか確認するには、Validate Key Pair ボタンをクリックしてください。OZero が個人キーで小規模のテストペイロードに署名し、公開キーで検証します。一致すれば成功メッセージが表示され、一致しない場合は新しいペアを生成する必要があります。

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

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

再生成後は新しい公開キーが次のビルドに自動的に含まれます。既存にリリースされたビルドは新しい公開キーでマニフェストの検証に失敗するため、アップデートをデプロイする必要があります。

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

Generate Key Pair ボタンを押すと、公開キーが OZeroSecurityConfig に保存され、同じキーを識別する fingerprint が OZeroManifestTrustAnchor.cs にも記録されます。ランタイムにはこの2つの値が合うか確認した後、マニフェストの署名を検証します。値が互いに合わなければマニフェストを信頼しません。

現在のキーと以前のキー

OZeroManifestTrustAnchor.cs には現在使用するキーの fingerprint と、キーの回転期間にのみ一時的に許可する以前のキーの fingerprint を記録できます。普段は現在のキーのみを使用し、新しいキーに交換する時のみ以前のキースロットをしばらく満たしておきます。このようにすれば、新しいビルドをデプロイする間、既存のビルドのユーザーが突然マニフェストの検証に失敗することを減らすことができます。

キーの回転手順

1. 現在の fingerprint をバックアップします。 Assets/OZeroSDK/Scripts/Security/BuildIntegirity/OZeroManifestTrustAnchor.cs を開いて ExpectedPublicKeyFingerprintHex の値をコピーしておきます。
2. 以前のキースロットに登録します。 同じファイルの PreviousPublicKeyFingerprintHex に1段階でコピーした値を貼り付けて保存します。
3. 新しいキーペアを生成します。 OZeroSecurityConfig インスペクターで Generate Key Pair をクリックし、再生成の確認ウィンドウで進行します。新しい公開キーと新しい fingerprint が自動的に更新されます。
4. 新しいリリースビルドをデプロイします。 新しいマニフェストは新しい個人キーで署名されます。
5. アップデートの切り替え期間を置きます。 既存のビルドと新しいビルドが一緒に使われる期間には以前のキーも許可する必要があります。ライブゲームでは通常1〜4週間程度を基準に設定します。
6. 以前のキースロットを空にします。 古いビルドの使用量が十分に低くなった後、PreviousPublicKeyFingerprintHex = "" に戻し、もう一度リリースすると回転が完了します。

なぜ以前のキースロットが必要なのか

ライブサービスでは、すべてのユーザーが同時に新しいバージョンに移行するわけではありません。以前のキースロットをしばらく維持すれば、既存のビルドと新しいビルドが一緒にある間、マニフェストの検証の失敗を減らすことができます。十分な切り替え期間が過ぎた後、以前のキースロットを空ければよいです。

トラブルシュート

ほとんどのキー関連のエラーは、個人キー、OZeroSecurityConfig の公開キー、OZeroManifestTrustAnchor の fingerprint が互いに合わないときに発生します。以下の項目を順に確認してください。

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

ExpectedPublicKeyFingerprintHex が空いている可能性があります。解決: Unity エディターで Generate Key Pair を1回実行した後、クリーンビルドしてください。値がすでに満たされているのにも関わらず失敗する場合は、以前のビルドの生成物が残っている可能性があるため、ビルドのフォルダーを空にして再度ビルドしてください。

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

OZeroSecurityConfig.Integrity.ManifestSigningPublicKey が空のときに発生します。解決: インスペクターで OZeroSecurityConfig を開き、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 の公開キーとコードに記録された fingerprint が合わないときに発生します。解決: Unity エディターで Tools → OZero → Validate Manifest Signing Keys を実行してください。ツールが不一致を報告する場合、Generate Key Pair で新しいキーペアを発行して再度ビルドしてください。配布されたビルドでこのメッセージが表示される場合、APK または実行ファイルが再パッケージされたかも確認する必要があります。

症状 4 — 回転の後、古いビルドのユーザーがマニフェストの検証に失敗する

新しいキーを配布する前に、以前の fingerprint を PreviousPublicKeyFingerprintHex に登録しなかった可能性が高いです。解決: 以前の fingerprint を Previous スロットに入れたホットフィックスビルドをデプロイし、十分な切り替え期間が過ぎた後に Previous スロットを空にしてください。

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

CI マシンに OZeroSigningKeys/manifest_private_key.pem がないときに発生します。解決: 個人キーを CI Secret に保管し、Unity のビルド直前に同じパスに復元してください。または OZeroSecurityConfig の Manifest Signing Private Key Path に CI でアクセスできるセキュリティパスを指定してください。すべてのリリースビルドのマシンは同じ個人キーを使用する必要があります。

インストール元の設定

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

Steam Anti-Piracy の設定

Steam に配布される PC ビルドで Steam の実行の経路、App ID、権限の状態、リリースの設定を確認します。Standard はローカルの検証であり、Steam サーバーを通じたより強い所有権の検証は Pro のサーバー 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 をネイティブプラットフォームのタイマーおよびオプションで信頼できるウェブ時間ソースと比較して、タイムスケール操作（スピードハック）を検出します。

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

Speed & Time Hack モジュールが有効な状態で Time.timeScale を直接変更すると、外部の時間操作に似たシグナルとして扱われる可能性があります。一時停止、スローモーション、カットシーン速度制御、早送り、デバッグ速度調整など、ゲーム側が意図して速度を変える場合は OZeroTime.timeScale を使用してください。

OZeroTime.timeScale は要求値を OZero detector に渡し、detector の想定 game-time scale を更新してから Unity time scale を安全に適用します。これにより SDK は、正当なゲームプレイ上の速度変更と疑わしいランタイム改ざんを区別できます。

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 設定

アセンブリインジェクション、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 のようなツールではメモリをスキャンしても見つけることができません。型の名前を変更するだけで、残りのコードはそのまま動作します。

サンプルコード

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 レファレンスに文書化されています。

次のステップ

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