はじめに

概要

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

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

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

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

Welcome ウィンドウ

OZero SDK パッケージを import すると、Welcome ウィンドウ(Window > OZero Security > Welcome)が自動で開きます。OZero SDK パッケージを import するたびに(同じバージョンを再 import した場合も)開き、新しい SDK バージョンが初めて読み込まれたときにも開きます。Built-in TMP ダイアログパッケージや TMP リソースの import では開きません。

ウィンドウ上部には大きな STEP 1 · Run Setup カードが 1 枚あります。Start setup を押すと Check Setup が開き、プロジェクトにまだ必要な設定が表示され、Auto Setup が変更ごとに確認を取りながら適用します。その下には、セットアップ後に使うカードが 2 枚あります。Read the Manual には Online(OZero Web サイトのマニュアル)と Offline(パッケージに同梱された HTML マニュアル、Assets/OZeroSecurity/Documentation/HTML/index.html)のボタンがあり、同梱マニュアルがない場合 Offline ボタンは無効になります。Security Config(Open config)は Edit > Project Settings > OZero Security を開き、セットアップ後にプリセットや個別の保護機能を変更できるようにします。

アドオンがインストールされたプロジェクトでは Online Services 行も表示されます。Open を押すと Window > OZero Security > Online Services ウィンドウを開きます(設定がなければ作成します)。

アドオンがインストールされている場合、Offline ボタンはアドオンに同梱されたマニュアル(Assets/OZeroSecurity/Online/Documentation/HTML/index.html)を開きます。

Don't show this window automatically again をオンにすると、このプロジェクトでは自動で開かなくなります。メニューからはいつでも開けます。batch モードの場合や OZERO_SUPPRESS_WELCOME 環境変数が設定されている場合は開かないため、CI や自動ビルドは止まりません。

2 ダッシュボードを開く

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

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

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

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

• Window > OZero Security > Welcome: スタート画面
• Window > OZero Security > Config & Dashboard: セキュリティ設定(Edit > Project Settings > OZero Security を開きます)
• Window > OZero Security > Check Setup: 設定チェックと自動設定(Auto Setup)

Check Setup と Auto Setup

Window > OZero Security > Check Setup を開くか、Welcome ウィンドウで Start setup を押してください。パッケージをインポートした直後と、リリースビルドの前に一度ずつ実行することをおすすめします。

Check Setup はプロジェクト、現在のビルドターゲット、セキュリティ設定を検査し、ビルドを止める項目と推奨項目を表示します。各項目には Docs(説明)と修正ボタンがあります。ビルドを止める項目から解決してください。

Auto Setup を押すと、推奨される変更を 1 ステップずつ表示します。各ステップで現在の値と変更後の値を確認し、Apply または Skip を選んでください。終了すると、適用した項目、スキップした項目、残っている項目が要約で表示されます。ブロックする項目と Auto Setup が適用できる変更がすべてなくなると、Setup complete ボックスと Open Build Settings ボタンが表示されます。あとは通常どおりビルドしてください。

Auto Setup が変更する項目: Development Build のオフ、IL2CPP への切り替え、Managed Stripping Low、Android API 24・ARM64、DeveloperSecret の生成、TMP ダイアログパッケージのインポート、manifest 署名キーの生成(Require Manifest Signature のオンを含む)、Android デバッグ SHA の登録。

署名キーファイル: Auto Setup が作成した manifest 署名の秘密キーファイルは、プロジェクトとバージョン管理の外に置き、CI を含むすべてのビルドマシンから使えるようにしてください。

詳しく: Auto Setup のステップと動作

Check Setup(Window > OZero Security > Check Setup、または Welcome ウィンドウの Start setup)は、プロジェクト、アクティブなビルドターゲット、セキュリティ設定、プラットフォームごとのリリース設定を点検し、ブロックする問題、推奨事項、情報を表示します。各項目には Docs と修正ボタンがあり、ウィンドウ上部に Auto Setup が適用できる推奨変更の数が表示されます。ウィンドウ上部のボタンは左から Auto Setup(適用待ちの変更数を表示)、Re-check(チェックを再実行)、Manual、Security Config です。Security Configは Edit > Project Settings > OZero Security を開きます。実際のプレイヤービルドでもビルド時の検証はそのまま実行されます。

OZero SDK パッケージを import した後に Check Setup を初めて開いたとき、Auto Setup が適用できる変更があれば、Auto Setup を開始するか確認します(Start Auto Setup / Not now)。同じバージョンを再 import した場合も import のたびに確認し、batch モードでは確認しません。後から Auto Setup ボタンで開始することもできます。

Auto Setup はまず適用するステップの一覧を表示します。プロジェクトとアクティブなビルドターゲットに必要なステップだけが表示されるので、Start(または Cancel)を選びます。ステップごとに現在の値と変更後の値を示し、Apply、Skip、Stop から選ばせます。最後の要約画面に適用した項目、スキップした項目、まだ残っている項目が表示され、Run Auto Setup Again で最初からやり直せます。表示される可能性のあるステップは次のとおりです。

1. Development Build をオフにする
2. Scripting Backend を IL2CPP に変更する
3. IL2CPP の場合のみ: Managed Stripping Level を Low に設定する
4. Android: 最小 API レベル 24、ターゲットアーキテクチャ ARM64
5. DeveloperSecret を生成する
6. Built-in TMP ダイアログパッケージを import する。必要に応じて TextMeshPro/Unity UI をインストールし、TMP Essential Resources とダイアログパッケージを順に import します。すべて終わるまで Processing 画面に進行段階と経過秒数が表示され、終わると次のステップに進みます。スクリプトの再読み込みを挟んでも続行します。
7. マニフェスト署名キーペアを生成する(トラストアンカーは自動で更新されます)。秘密鍵ファイルの作成場所はステップ画面に表示されます。結果のダイアログは表示されず、秘密鍵の場所とフィンガープリントはコンソールログに残ります。すでにキーがある場合は、上書きするか確認するダイアログが表示されます。次のステップで Require Manifest Signature をオンにします。
8. Android デバッグ SHA を追加する。結果はコンソールログに残ります。デバッグ keystore がない場合は、作成するか確認するダイアログが表示されます。 Security Config や Keystore SHA Extractor のボタンから直接実行した場合は、従来どおり結果のダイアログが表示されます。

セキュリティ設定の Fail Build on Setup Warnings がオンの場合(既定値)、キー生成と Require Manifest Signature も通常のステップです。スキップすると警告が残り、プレイヤービルドは preflight で失敗します。ステップ画面と要約画面にもその旨が表示されます。この設定がオフの場合だけ「(optional, review first)」と表示される任意のステップになります。キー生成ステップでは秘密鍵ファイルの作成場所が表示されます。秘密鍵はプロジェクトの外に置いてバージョン管理から除外し、CI を含むすべてのビルドマシンで使えるようにしてください。

このエディターで適用できないステップ(例: Unity エディターに IL2CPP モジュールがインストールされていない場合の IL2CPP ステップ)は 1 ステップずつ進めず、概要と要約画面の Needs your action に別に表示されます。IL2CPP モジュールがない場合は Unity Hub > Installs > Add modules で対象プラットフォームの IL2CPP モジュールを追加してから、Auto Setup をもう一度実行してください。Player Settings の変更は Undo で元に戻せません。適用した変更はすべて要約画面に表示されます。

次の 2 つの Check Setup エラーは OZero のネイティブロードアンカーを守ります(クライアント側保護の限界)。OZero native plugins are not set to Load on startup: Auto Setup が OZero ネイティブプラグインの Load on startup を再びオンにします。この設定はオフにしないでください。Android boot provider library is missing: Mono バックエンドの Android ビルドに必要なライブラリです。OZero Security パッケージを再インポートして Assets/OZeroSecurity/Plugins/Android/OZeroSecurityBoot.androidlib を復元してください。

オンラインアドオンがある場合、Auto Setup はお客様だけが知っている値も入力を受けて設定します。こうしたステップには入力欄が表示されるので、値を入力して Apply を押します。値は保存前に確認され、Console やログには記録されません。確認に失敗するとステップに理由が表示され、何も保存されません。値を直して入力し直すか、Skip を押してください。

• License Key:Pro license key is empty、Native Variant <NNNN> needs your license key、… is bound to a different license key の項目で表示されます。プロジェクトにライセンス専用の Native Variant がある場合は、保存前にその Variant のライセンスと照合し、別のライセンスのキーは保存しません。
• Server Public Key:Pro server signing public key is not configured の項目で表示されます。Customer Portal > Server Key から署名公開鍵(16 進数 64 文字)をコピーして入力してください。それ以外の形式は拒否され、小文字で保存されます。
• Application Identifier:Application identifier is not registered for Native Variant <NNNN> の項目で表示されます。入力する値はアクティブなビルドターゲットによって異なり、Customer Portal > Platform settings と同じです。Android は Package Name、iOS は Bundle Identifier を入力し、入力欄には現在の識別子があらかじめ入っています。この設定がオフだと Unity は入力した識別子を無視するため、Apply は Player Settings の Override Default Package Name / Bundle Identifier もオンにします。Windows、macOS、Linux は、Customer Portal > Platform settings でこのプラットフォームに登録した Company Name と Product Name(ポータルでは Company / Product と表示)をそれぞれの欄に入力します。両方の欄には現在の値があらかじめ入っており、company.product または com.company.product として照合されます。Apply は Player Settings の Company Name と Product Name を設定し、Product Name はビルドされたアプリの名前にもなります。WebGL はポータルに登録したページの origin(ドメイン)で識別されるため、プロジェクトで変更するものはなく、このステップは利用不可と表示されます。値はライセンスに登録済みである必要があり、登録されていない場合は Customer Portal で登録してからパッケージを再ダウンロードするよう案内されます。

3 モジュールの有効化

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

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

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

詳しく: プリセットが変更する値

Quick Preset パネルには、現在の設定に一致するプリセットが Current: Standard のように表示され、該当するボタンが太字と * で示されます。適用後に値を手動で変更すると Current: Custom と表示され、どのボタンにも印は付きません。推奨値は Standard で、ボタンには Standard (Recommended) と表示されます。プリセット名は Low / Standard / Strict のままです。各ボタンの下にプリセットの説明が表示され、ボタンのツールチップにも同じ説明が出ます。

Windows システムモジュール検査（enableWindowsSystemModuleScan）: Low OFF / Standard・Strict ON。ライセンス階層ではなくセキュリティプリセットの設定です。互換性と観測規則は Injection 設定を確認してください。

設定の取得は enableRemoteSpeedHackConfig、enableRemoteInjectionConfig、enableRemotePhysicsConfig で切り替えます。セキュリティプリセットは、プロジェクトのライセンスティア(Online Services 設定)が Pro のときだけこれらを有効にし、Standard またはライセンス設定がない場合は Pro 専用のサーバーオプションをすべて無効のままにします（ティアを Pro に変更したらプリセットを再適用してください）。これらは Pro のみで動作します。リモート設定オプション自体は BIV サーバー検証、インストール元の同期、サーバーホワイトリスト、テレメトリーを有効にしません。プリセットはこれとは別にこれらの値を変更します(上のプリセット表を参照)。

• Low: 軽い核心の検査だけ維持します。テストの環境が早すぎる段階でブロックされないよう、プラットフォームネイティブ検査と強制終了のポリシーを緩和します。
• Standard: 核心保護のセット、開始の際の検証、ランタイムの再検証、エミュレーターの検査、推奨される IL2CPP ファイルのカバレッジをオンにします。互換性と保護のレベルのバランスを合わせた構成です。
• Strict: 最も広いカバレッジを適用し、より多くの失敗を致命的な違反として処理します。プラットフォーム、署名、ストア配布フローを十分にテストした後に適用してください。

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

OZero Security は Standard と Pro の2つのティアーで提供されます。Standard はサーバー連携なしでローカル保護機能を使用します。Pro はプロジェクト別の Native Variant パッケージ、マニフェスト / Bundle ID バインディング、テレメトリー、署名付きサーバー時刻、リモートポリシー、サーバー検証を提供します。

이 앱은 부정 행위와 변조를 방지하기 위해 OZero Security SDK(오제로시큐리티 주식회사)를 사용합니다. 보안 검사는 기기 안에서 이루어지며, [Pro 서버 기능이 켜진 경우] 보안 이벤트가 발생하면 다음 정보가 OZero 서버로 전송됩니다: 앱별로 해시된 기기 식별자, 플랫폼·운영체제, 앱 버전, 탐지된 보안 이벤트의 종류와 결과, 탐지에 관련된 외부 프로그램 모듈의 파일명·서명자·해시, 접속 국가. [물리 검증을 켠 경우: 캐릭터 위치·속도·씬 이름.] [Steam 확인을 켠 경우: Steam 인증 티켓과 SteamID(해시로 저장).] 기기의 원문 식별자, IP 주소, 채팅·닉네임·결제 정보는 전송되지 않습니다. 전송된 기록은 90일 후 삭제되며, 외부 프로그램 모듈 정보는 개인·기기와 연결되지 않는 형태로 OZero의 부정 프로그램 판별 기준을 개선하는 데 사용됩니다. 자세한 내용: https://www.ozerosecurity.com/privacy.html

This app uses the OZero Security SDK (OZero Security Inc.) to prevent cheating and tampering. Security checks run on the device. [When Pro server features are enabled] the following is sent to OZero servers when a security event occurs: an app-specific hashed device identifier, platform and OS, app version, the type and result of the security event, the file name, signer and hash of third-party modules involved in the detection, and the country of connection. [Physics validation: character position, velocity and scene name.] [Steam verification: the Steam auth ticket and SteamID, stored hashed.] The raw device identifier, IP address, chat, nicknames and payment data are not sent. Records are deleted after 90 days. Module information is used, in a form not linked to any person or device, to improve OZero's cheat-program classification. Details: https://www.ozerosecurity.com/privacy.html

本アプリは不正行為と改ざんを防ぐために OZero Security SDK（OZero Security Inc.）を使用しています。セキュリティ検査は端末内で行われ、[Pro サーバー機能が有効な場合] セキュリティイベント発生時に次の情報が OZero サーバーへ送信されます：アプリごとにハッシュ化した端末識別子、プラットフォーム・OS、アプリのバージョン、検知したイベントの種類と結果、検知に関係した外部モジュールのファイル名・署名者・ハッシュ、接続国。[物理検証：キャラクターの位置・速度・シーン名。][Steam 確認：Steam 認証チケットと SteamID（ハッシュで保存）。] 端末の生の識別子、IP アドレス、チャット・ニックネーム・決済情報は送信されません。記録は 90 日後に削除され、モジュール情報は個人や端末と結び付かない形で OZero の不正プログラム判定基準の改善に使われます。詳細：https://www.ozerosecurity.com/privacy.html

本应用使用 OZero Security SDK（OZero Security Inc.）防止作弊与篡改。安全检查在设备内进行，[启用 Pro 服务器功能时] 发生安全事件时会向 OZero 服务器发送以下信息：按应用哈希处理的设备标识符、平台与操作系统、应用版本、安全事件的类型与结果、与检测相关的第三方模块的文件名·签名者·哈希、连接国家。[物理验证：角色位置、速度与场景名。][Steam 验证：Steam 认证票据与 SteamID（以哈希保存）。] 不会发送设备原始标识符、IP 地址、聊天、昵称与支付信息。记录在 90 天后删除；模块信息以不关联个人或设备的形式用于改进 OZero 的作弊程序判定标准。详情：https://www.ozerosecurity.com/privacy.html

Online Services 設定

Security Config はアドオンの設定を 2 か所に表示します。Protection Modules グループの最後、つまりページの一番下(Steam Anti-Piracy (PC Only) の後)にある Pro - License & Online Services カードは License(ティアとライセンスキー)から始まります。Tier が Pro の場合は Server Connection、Offline & Device Policy、Security Level Enforcement(Security Config Hash (build allowlist) の一覧を含む)、Telemetry、Online Verification UI、Validate License Now も表示され、各検出モジュールのセクション(Build Integrity、Install Source (Android Only)、Device Binding、Speed & Time Hack、Injection & Hooking、Steam Anti-Piracy (PC Only))に、そのモジュールのオンライン設定をまとめた Pro - Online ブロックが追加されます。モジュールの Activate がオフの間、このブロックは無効です。

値は ProjectSettings/OZeroLicenseSettings.asset に保存され、このファイルをバージョン管理にコミットします。Project ウィンドウに設定アセットはありません。同じ設定は独立した画面でも編集できます。Security Config と Welcome ウィンドウの Online Services ボタンは Window > OZero Security > Online Services ウィンドウを開き(設定がなければ作成し)、このウィンドウには Select Settings Asset と Validate License Now ボタンがあります。ウィンドウ上部の Security Config と Check Setup ボタンでそれぞれの画面に移動できます。この節の残りは独立画面について説明しますが、項目名は Security Config でも同じです。

ティアは License セクションで選びます。License Key 欄はどちらのティアでも表示されます。Standard を選ぶと License セクションだけが表示され、Standard はサーバーなしで動作するためオンラインサービスはオフで、OZero サーバーには何も送信しないという案内が出ます。License Key は Native Variant 込みのパッケージを使う場合だけ入力し、ローカルでのみ確認されます。Pro を選ぶと、サーバー接続とオンラインサービスの設定が表示されます。

設定は Security Config と同じように構成され、順序は Quick Preset、License、Server Connection、Offline & Device Policy、Security Level Enforcement(ヘッダーの Enable でオン)、モジュールセクション Build Integrity、Install Source、Device Binding、Speed & Time Hack、Injection & Hooking、Steam Anti-Piracy、そして Telemetry、Online Verification UI です。

プリセットは SDK 全体で 1 つです。ここの Low / Standard / Strict ボタンは Security Config と同じプリセットを適用するため、どちらで適用しても結果は同じです。ここでも Standard が推奨値で Standard (Recommended) と表示され、各ボタンの下に説明が出ます。プリセットを適用すると、検知モジュール、オンラインサービスの既定値、Declared Security Level がまとめて変わり、ライセンス・サーバー URL・キーは保持されます。パネルには Current: Standard のように現在の状態が表示され、該当するボタンが太字と * で示されます。適用後にオンライン設定を手動で変更すると Current: Custom になり、どのボタンにも印は付きません。Declared Security Level が適用したプリセットと異なる場合は、Security Level Enforcement セクションに警告が出ます。

モジュールセクションは Security Config と名前・順序が同じです。ヘッダーには Security Config でのモジュールの状態(Active / Inactive、読み取り専用)が表示され、各セクションの先頭にはオンラインサービスがそのモジュールに追加する内容が 1 行で説明されます。サーバースイッチはセクションの最初の行にあります。

• Build Integrity: Check Integrity With Server
• Install Source: Check Installer With Server
• Device Binding: Verify Device With Server
• Speed & Time Hack と Injection & Hooking はサーバー機能が複数あるため、単一のスイッチはありません。
• Steam Anti-Piracy: Check Steam DRM With Server

Security Config では、モジュールがオフの間、そのモジュールの Pro - Online ブロックが Activate this module to use its online settings. の案内とともに無効表示になります。独立画面では、無効なモジュールのセクションに、モジュールを有効にするまでこのオンライン設定は効果がないという案内と Open Security Config ボタンが表示されます。

Telemetry と Online Verification UI はオンライン専用です。Telemetry は Customer Portal に送るセキュリティイベントとリモート物理設定を扱います。Online Verification UI はサーバー検証中に表示される画面(検証中、再試行、オンライン必須、タイムアウト)の動作を決めます。設定項目は UI ポリシー、再試行・オンライン必須の時間、タイムアウト時の動作、ネットワーク復帰時の自動再試行です。ダイアログのデザインと言語は Security Config > Player Notice (Managed UI) に従います。Check Integrity With Server と Check Steam DRM With Server がどちらもオフの場合は、使用されないという案内が出ます。

アドオンに個別のログスイッチはなく、ログは Security Config の Enable Debug Logs に従います。

Pro パッケージと Native Variant

Pro のお客様は Customer Portal のダウンロードから Pro 統合パッケージを受け取ります。ライセンス用に作成された 1 つの .unitypackage に、Standard SDK、オンラインアドオン、全プラットフォームの Native Variant が含まれます。カードには次の 2 つのオプションがあります。

• Native Variant 込み:このライセンスに割り当てられた専用ネイティブです。カードに割り当て番号(Variant · Native · ABI)が表示され、パッケージはライセンス(ライセンスキーと登録済みの Bundle ID / パッケージ名)にバインドされます。
• Standard variant(0000)込み:Standard SDK の共通ネイティブをそのまま使用し、ライセンスバインドはありません。

Variant を交換（ローテーション）する場合： 以前の Variant で作成した既存ビルドは引き続き動作します。新しい Variant は、交換後に新しくダウンロードしたパッケージで作成したビルドから適用されます。交換するとローテーション回数を 1 回使用し、交換後は返金を受けられません。

Native Variant 込みのパッケージを Tier Standard で使うには、Tier は Standard のまま、Security Config > Pro - License & Online Services > License に License Key だけを入力します。ビルドとプレイヤーはキーをローカルでのみ確認し、Tier Standard は OZero サーバーと通信しません。これは既定でオンの Allow Standard Build With Premium License に従います。オフの場合、Check Setup がこのオプションをオンにするか Tier を Pro にするよう案内します。

ライセンスキーなしでビルドするには、Standard variant(0000)込みのパッケージをダウンロードしてください。

Unity Asset Store で SDK を購入した場合は、SDK を Asset Store からインストールし、Customer Portal からは Pro 拡張パッケージだけをダウンロードします。カードで選んだ SDK バージョン用のオンラインアドオンと割り当て済み Native Variant が含まれ、SDK 本体は含まれません。

Check Setup の Native Variant 項目

パッケージに Native Variant が含まれている場合、Check Setup がビルド前にプロジェクトが一致しているかを表示します。プレイヤービルドも同じ理由で停止します。

ゲームサーバー連携: デバイス ID とユーザー UUID

Pro では、ゲームサーバーが OZero の使う ID と連携できます。OZero のデバイス ID を読み取ってプレイヤーのアカウントと一緒に保存し、ゲームのユーザー UUID(アカウント ID)を紐付けると、Customer Portal でそのユーザーが使ったデバイスを調べたり、ユーザーをブロックしたりできます。

デバイス ID の読み取り

OZeroLicenseRuntime.CurrentDeviceId を読み取ってください。既定の設定では Customer Portal とテレメトリに表示される値と同じです。アカウントを紐付けるために DeviceIdProvider を置き換えないでください。サーバーが把握しているデバイス ID が変わってしまいます。代わりに下のユーザー UUID API を使えば、デバイス ID はそのまま保たれます。

ユーザー UUID の紐付け

• プレイヤーがサインインした後に OZeroLicenseRuntime.SetExternalUserId(uuid) を呼び出します。前後の空白を除いて空の場合、128 文字を超える場合、制御文字を含む場合は false を返し、値は無視されます。
• サインアウト時に OZeroLicenseRuntime.ClearExternalUserId() を呼び出します。HasExternalUserId でユーザーが紐付いているかを確認できます。
• UUID はデバイス内でライセンスごとの salt と SHA-256 でハッシュ化されます。テレメトリ、物理イベント、デバイスポリシー確認にはハッシュだけを送り、サーバーにもハッシュだけを保存します。元の UUID がデバイスの外に出ることはなく、ディスクにも書き込まれません。
• 有効化が終わる前に呼び出しても構いません。SDK は UUID をメモリに保持し、有効化後にハッシュの送信を始めます。

ユーザーのブロック

Customer Portal のユーザーブロックルールには、次の 2 つの動作のどちらかを設定します。

• コールバックのみ:ゲームは policy action(Module = "user_policy"、PolicyId = ルール ID、Reason = 運用者の理由)をセッションごとに 1 回受け取り、対応を決めます。セッションは終了しません。
• 強制終了:ゲームはまず policy action(Module = "user_policy"、ActionId = "user_blocked"、Reason = "terminate")を受け取ります。その後 SDK がデバイスポリシーブロックと同じ終了案内(OZ-SEC-0E)を表示し、セッションを終了します。

ユーザーブロックとデバイスブロックは OZeroLicenseRuntime.LastServerBlockCode で区別します。ユーザーは "USER_BLOCKED"、デバイスは "DEVICE_BLOCKED" です。判定は SetExternalUserId の呼び出し後およそ 5 秒以内に実行され(デバイスポリシー heartbeat がオフでも実行)、最短間隔は 30 秒です。ネットワークに失敗した場合はセッションを終了せず、次の確認で判定します。

Customer Portal: ユーザー UUID ページ

Customer Portal で 運用情報 > ユーザー UUID を開きます(Pro)。ページには 3 つのタブがあります。

• ユーザー検索:ゲームが SetExternalUserId に渡した UUID を入力します。ブラウザーが送信前にハッシュ化するため、元の値はサーバーに届きません。結果には、そのユーザーが使ったデバイス(初回・最終観測、イベント数)、最近のイベント(テレメトリ、物理イベント、ポリシーブロック)、ブロック状態と、ブロックルールの作成・編集・解除ボタンが表示されます。デバイスで検索では、デバイス ID(CurrentDeviceId)に紐付いたユーザー数と各ユーザーキーの先頭 8 文字を表示します。元の UUID は表示できないため、ユーザーを確認するには UUID で検索してください。
• ブロックルール:ルールの一覧(適用中またはすべて)を表示します。新しいルールでは、ユーザーの UUID、動作(コールバックのみまたは強制終了)、ゲームのコールバックにも渡される理由、期限(期限なし(既定、解除するまで)、7・30・90 日、日付を指定)を設定します。すでにルールがあるユーザーに保存すると、そのルールが更新されます。各ルールには作成元(ポータル、サーバー API、運用者)が表示されます。
• 設定:ライセンスの salt、計算式、UUID の正規化ルール、現在の紐付け数、お客様のサーバーで同じハッシュ(h1)を計算する C#・Node.js・Python の例を表示します。お客様のサーバーはこの h1 でサーバー API を呼び出します。ゲームクライアントに salt は不要です(SDK が有効化時に受け取ります)。

salt を再発行(設定タブ)すると既存の紐付けが切れます。以前の salt で作られたユーザーの紐付けとブロックルールはユーザーと一致しなくなり、既存のルールは古いキーのまま残ります。ゲームは次の有効化で新しい salt を受け取り、お客様のサーバーも新しい salt で h1 を計算し直す必要があります。

ブロックルールの保存・解除と salt の再発行は、操作履歴のユーザー UUIDカテゴリーに記録されます。

Customer Portal はシングルページアプリです。更新後に画面が古いままだったり表示がおかしかったりする場合は、ページを再読み込みしてください。

設定タブと同じ例です。API リファレンス(OZeroLicenseRuntime)のテストベクターで実装を確認してください。

// C#
using System.Security.Cryptography;
using System.Text;

static string ExtUserHash(string salt, string uuid)
{
    var id = uuid.Trim(' ', '\t', '\n', '\v', '\f', '\r');
    var bytes = SHA256.HashData(Encoding.UTF8.GetBytes("OZERO-EXTUID-V1|" + salt + "|" + id));
    return Convert.ToHexString(bytes).ToLowerInvariant();
}

// Node.js
const crypto = require("crypto");

function extUserHash(salt, uuid) {
  const id = uuid.replace(/^[ \t\n\v\f\r]+|[ \t\n\v\f\r]+$/g, "");
  return crypto.createHash("sha256").update("OZERO-EXTUID-V1|" + salt + "|" + id, "utf8").digest("hex");
}

# Python
import hashlib

def ext_user_hash(salt: str, uuid: str) -> str:
    uid = uuid.strip(" \t\n\v\f\r")
    return hashlib.sha256(f"OZERO-EXTUID-V1|{salt}|{uid}".encode("utf-8")).hexdigest()

例: サインイン、サインアウト、policy コールバック

using OZeroSDK.Security;
using OZeroSDK.Security.License;
using UnityEngine;

public sealed class OZeroAccountLink : MonoBehaviour
{
    private void OnEnable()
        => OZeroSecurityManager.Instance.RegisterUserPolicyActionCallback(OnPolicyAction);

    private void OnDisable()
        => OZeroSecurityManager.Instance.UnregisterUserPolicyActionCallback(OnPolicyAction);

    // Call after your sign-in succeeds.
    public void OnSignedIn(string accountUuid)
    {
        if (!OZeroLicenseRuntime.SetExternalUserId(accountUuid))
            Debug.LogWarning("OZero: user id rejected (empty, too long, or control characters).");

        // Optional: keep the OZero device id with the account on your server.
        string deviceId = OZeroLicenseRuntime.CurrentDeviceId;
        MyGameServer.ReportDevice(accountUuid, deviceId);
    }

    // Call on sign-out.
    public void OnSignedOut() => OZeroLicenseRuntime.ClearExternalUserId();

    private void OnPolicyAction(OZeroPolicyActionEvent evt)
    {
        if (evt.Module != "user_policy")
            return;

        if (evt.ActionId == "user_blocked")
        {
            // Terminate rule: the SDK shows the termination notice and ends the session next.
            MyGame.SaveQuickly();
            return;
        }

        // Callback-only rule: the game decides what to do.
        Debug.LogWarning($"User block rule {evt.PolicyId}: {evt.Reason}");
        MyGame.RestrictAccount(evt.Reason);
    }
}

プライバシーとストアへの申告

• UUID にはメールアドレスや電話番号ではなく、仮名のアカウント ID を使ってください。
• iOS:アドオンのプライバシーマニフェストがすでに User ID を申告しているため、追加の項目は不要です。
• Google Play:ユーザー UUID を紐付ける場合は、データセーフティのフォームで User IDs を申告してください。

セキュリティ設定ハッシュの許可リスト

ビルドごとにセキュリティ設定(OZeroSecurityConfig、オンラインアドオンの設定を含む)を封印し、その SHA-256 ハッシュを計算します。配布するビルドのハッシュを承認すると、サーバーのセキュリティレベル確認はそのビルドだけを通過させます。そのため、設定を弱めた改ざんビルドが高いセキュリティレベルを宣言しても通過できません。

• 互換モード(承認済みハッシュ 0 個):宣言したセキュリティレベルだけを比較し、すべてのビルドがハッシュ確認を通過します。
• 適用モード(承認済みハッシュ 1 個以上):ハッシュが承認されていないビルドは拒否されます。Fail On Security Level Reject がオンならゲームが終了し、オフなら Standard に降格します。

Pro 専用です。Security Config > Pro - License & Online Services > Security Level Enforcement がオン(ヘッダーの Enable、enableSecurityLevelCheck)のときだけ動作します。オフの場合、ビルドはハッシュを送らないため許可リストは効果がなく、このセクションにはハッシュ一覧の代わりに警告が 1 つだけ表示されます。

ビルドのハッシュを確認する

• ビルドログに [OZero] Security config digest for this <Target> build: <64 hex> という行が出力されます。
• Security Level Enforcement がオンの場合、Security Config 一番下の Pro - License & Online Services カードの Security Level Enforcement セクション内の Security Config Hash (build allowlist) に、最近のビルド 5 件(ターゲット、時刻(UTC)、ハッシュ、Copy ボタン)が表示されます。Window > OZero Security > Online Services ウィンドウの同じセクションにも同じ一覧があります。
• 記録ファイル Library/OZeroSecurity/BuildConfigDigests.json に最近 20 件が保存されます。
• プレイヤーが送信するハッシュは、ビルドログと Pro カード(または Online Services ウィンドウ)に表示されるダイジェストと同じです。
• 同じ設定を別のマシンでビルドしても、ハッシュは同じです。
• エディター Play Mode はビルドのハッシュではなく、設定アセットから計算したハッシュを送信します。ポータルのサーバーが受信したハッシュに表示されることがありますが、承認しないでください。

Customer Portal でハッシュを承認する

ポリシー設定 > セキュリティ設定ハッシュを開きます(Pro)。

• 上部にポリシーモード(適用または互換)と有効な承認済みハッシュの数が表示されます。
• 承認済みハッシュ:解除で外します。最後のハッシュを解除すると、ライセンスは互換モードに戻ります。
• サーバーが受信したハッシュ:Security Level Enforcement がオンのビルドが送ったハッシュです(デバイス ID は保存せず、観測回数は最大 1 時間に 1 回数えます)。リリースビルドのハッシュで承認を押してください。
• ハッシュを直接登録:ビルドログまたは Pro カードのハッシュ、ラベル、期限(なし、30 日、90 日、1 年)を入力します。
• 最初の承認では、「承認されていないビルドは拒否される」ことの確認があります。有効にする前に、現在配布中のビルドをすべて承認してください。

承認と解除は操作履歴に記録されます。CI からハッシュを登録するには、API リファレンスのセキュリティ設定ハッシュ(CI)を参照してください。

Pro ライセンスキーの登録

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

1. 設定アセットの作成

オンラインアドオンは、import 後にエディターがアイドル状態になるとライセンス設定を ProjectSettings/OZeroLicenseSettings.asset に自動で作成します(古い OZeroLicenseConfig アセットが Assets/ の下に残っている間は作成しません)。ライセンスは Security Config 一番下の Pro - License & Online Services カードで入力します。License でティアを選び、ライセンスキーを入力します(Standard では Native Variant パッケージを使う場合だけ)。サーバー URL と鍵は Server Connection にあります。Security Config または Welcome ウィンドウの Online Services を押すと、同じ設定を持つ Window > OZero Security > Online Services ウィンドウが開き、設定がない場合は作成されます。ProjectSettings/OZeroLicenseSettings.asset はバージョン管理にコミットしてください。

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

3. Check Integrity With Server を確認

ビルドする前に Security Config > Build Integrity > Pro - Online > Check Integrity With Server が意図した値か確認してください。Standard・Strict プリセットはオン、Low プリセットはオフにし、新しく作成した Online 設定は Standard の値(オン)で始まります。オンにするとサーバーによるビルド判定と実行中の再確認が加わり、Standard では起動時にオンラインが必要です。ポータルの端末・Variant のブロックはこの値に関係なく適用されます。既定の Built-In 確認 UI を使う場合は TMP dialog パッケージが必要で、Auto Setup がインポートします。オフラインで実行する必要がある場合はオフラインの動作を参照してください。

4. ビルド & 検証

追加のコードを書く必要はありません。アプリが起動すると、SDK がビルド時に暗号化リソースとしてプレイヤーに含めたライセンス設定を自動的に読み込みます。初回実行後、Player ログで [OZeroLicense] activated; tier=pro caps=5 のような行を確認してください。Pro に設定したのに Standard モードと表示される場合は、まず ProjectSettings/OZeroLicenseSettings.asset が存在し、ビルド前に保存されているか、Check Setup に Old OZeroLicenseConfig asset found が出ていないかを確認してください。

オフラインの動作

Standard はサーバーなしで動作します。Pro は保存済みのアクティベーション情報を使ってオフラインで起動できますが、ライセンスポリシーで起動時のオンライン確認を必須にした場合はサーバー接続が必要です。

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

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

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

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

オフラインで実行する必要があるゲーム: Standard・Strict プリセットは Check Integrity With Server をオンにするため、サーバー検証のためにオンライン接続が必要です。オフラインで実行するには Low プリセットを適用するか、Security Config > Build Integrity > Pro - Online > Check Integrity With Server をオフにしてください。この場合、サーバーによるビルド判定と実行中の再確認は行われません。

保存済みの Pro アクティベーション情報は、サーバーが署名したアクティベーショントークンの有効期限まで有効です。有効期限は OZero サーバーがトークン発行時に決め（現在はアクティベーション成功から 7 日）、SDK 側で延長することはできません。この期間を過ぎると、再びアクティベーションに成功するまで Pro サーバー機能は利用できません。適用済みの Native Variant とローカル検知設定は変わりません。この有効期間は、以下のローカル時刻ポリシーとは別に適用されます。

Pro — 端末時刻の使用方法を選ぶ

Customer Portal > License > Local clock で、保存済みの Pro アクティベーション情報をオフライン起動に使用できるか設定します。オンラインアクティベーションにはサーバー時刻が使われるため、端末の日時がずれているだけでオンラインの Pro 機能が制限されることはありません。

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

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

この動作は Security Config の Pro - License & Online Services カードにある Offline & Device Policy セクションの Offline Pro Policy Mode(OZeroLicenseConfig.offlineProPolicyMode、Online Services ウィンドウにもあります)で設定します。デバイスがサーバーに接続できないとき、ローカル 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 を先に確認してください。

最小のビルドターゲット

リリースビルドの推奨設定

リリースビルドには次の設定を推奨します。

• Scripting Backend を IL2CPP に設定してください(Project Settings > Player > Other Settings)。
• Managed Stripping Level は Low にしてください。Mono バックエンドの場合は Disabled のままにしてください。
• 設定を変更した後は、シーン遷移、セーブ/ロード、決済・広告などの外部 SDK を実機でテストしてください。

クライアント側保護の限界

Mono ビルドは一般的なツールで逆コンパイル・改変できるため、改変されたビルドはクライアント側の検査を飛ばせます。IL2CPP は改変のコストを大きく高めますが、完全な防止ではありません。本当の対策は、サーバー検証と、ゲームコードを Secure Variables などの OZero API に依存させることです。

回避による被害が大きいゲームには、次の構成を推奨します。

• 重要なゲーム値(通貨、スコア、能力値)は Secure Variables(OZeroSV) で管理してください。SDK を削除・無効化するとゲームの進行が壊れるため、回避のコストが高まります。
• サーバー整合性検証(OZeroManaged または CustomerGameServer)を有効にし、ゲームサーバーで OZA トークンまたは managed session を確認してください。改変されたクライアントは有効なサーバー署名を受け取れません。

macOS: Developer ID 署名と公証

Unity が作成した macOS ビルドは ad-hoc 署名のため、Build Integrity がオンだと起動から約 10 秒後に終了します。配布するには Developer ID Application 証明書で署名する必要があります。自動署名をオンにしておくと、ビルドの終了時に OZero が署名します。

自動署名をオンにする(推奨)

1. Window > OZero Security > macOS Distribution Signing を開き、Sign macOS builds をオンにしてください。ビルドターゲットが macOS なら、Check Setup の Open signing settings からも開けます。
2. Certificate で Developer ID Application 証明書を選んでください。キーチェーンに 1 つしかなければ Automatic のままで構いません。
3. ビルド中に公証も行う場合は Notarize をオンにし、xcrun notarytool store-credentials で一度作成した Notary keychain profile の名前を入力してください。
4. Save をクリックしてください。以降、macOS ビルドが終わるたびに自動で署名され、Console に macOS distribution signing complete と表示されたらそのまま配布できます。

bash "/path/to/YourProject/Assets/OZeroSecurity/Tools/macOS/OZeroMacSign.sh" \
  --app "/path/to/YourGame.app" \
  --project "/path/to/YourProject" \
  --notary-profile "YourNotaryProfile"

OZERO_MACOS_SIGNED_APP_PATH="/path/to/YourGame.app" \
  "/path/to/Unity.app/Contents/MacOS/Unity" -batchmode -nographics -quit \
  -projectPath "/path/to/YourProject" \
  -executeMethod OZeroSDK.Security.Editor.OZeroMacOSPostSignIntegrityRebaker.RebakeAfterNestedSigning \
  -logFile rebake.log

Windows / Linux: コード署名と整合性ファイルの再生成

Windows や Linux のビルドに自分でコード署名をしない場合、以下の手順は読み飛ばしてください。ビルド後に実行ファイルやネイティブモジュールに署名した場合は、署名の後で OZero の整合性ファイルを再生成する必要があります。そうしないと起動時に整合性エラー(0x0A)で終了します。

1. 通常どおりビルドしてから、実行ファイルと自社で作成した DLL・.so に署名してください。OZero の DLL はすでに署名済みのため、再署名は不要です。リリースビルドには OS が信頼する証明書が必要で、自己署名のテスト証明書では通りません。
2. 下のコマンドで、署名済みの出力に合わせて整合性ファイルを再生成してください。エディターでは Tools > OZero Security > Re-bake Integrity After Code Signing (Windows or Linux player)... も使えます。
3. そのままパッケージ化して配布してください。整合性ファイルは <Game>_Data/StreamingAssets の下にあり、署名の対象ではありません。サーバー検証を使う場合は、再生成が出力した manifest ハッシュを登録してください。

set OZERO_SIGNED_PLAYER_PATH=C:\dist\YourGame.exe
"C:\Program Files\Unity\Hub\Editor\<version>\Editor\Unity.exe" -batchmode -nographics -quit ^
  -projectPath "C:\path\to\YourProject" ^
  -executeMethod OZeroSDK.Security.Editor.OZeroStandalonePostSignIntegrityRebaker.RebakeAfterSigning ^
  -logFile rebake.log

Android ProGuard / R8 の設定

# 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/OZeroSecurity/Plugins/Android/arm64-v8a の下に維持し、32ビットビルドを配布する場合は armeabi-v7a も一緒に維持してください。
• Build Integrity > Check Platform Native と Android SHA Keys を使用する場合は、Minify/R8 適用後の最終署名された APK または AAB で必ずテストしてください。デバッグキーストアのフィンガープリントとリリースキーストアのフィンガープリントは異なります。

5 セキュリティ設定 (OZeroSecurityConfig)

セキュリティ設定は、パッケージを import すると Standard プリセットで作成されます。Edit > Project Settings > OZero Security で編集し、Window > OZero Security > Config & Dashboard も同じページを開きます。共有の値は ProjectSettings/OZeroSecuritySettings.asset に保存され、秘密値を含まないためバージョン管理にコミットします。DeveloperSecret とマニフェスト署名用秘密鍵のパスはユーザーごとの値で UserSettings/OZeroSecuritySecrets.json に保存され、バージョン管理には含めません。ランタイムとエディタースクリプトでは OZeroSecurityConfig.Instance で読み取り、スクリプトから値を変更する場合は独自のビルドスクリプトを参照してください。ページは Quick Preset、Project & Advanced(Common Settings、Editor Play Mode)、Detection Response(Global Threat Response、Player Notice (Managed UI))、Protection Modules の順です。すべてのセクションは折りたたまれた状態で始まるため、タイトルをクリックして展開してから設定してください。Security Termination Notice のポリシーは Detection Response の Player Notice (Managed UI) にあります。

共通設定

すべてのセキュリティモジュールで共有される最上位設定です。この表のデフォルト値は、コードに定義されたシリアライズ初期値を基準にしています。Security Config では Project & Advanced グループの Common Settings にあり、Keys & Storage、Build Checks (Preflight)、Logs & Diagnostics に分かれています。

Player Notice (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 を基準に下の表を順に確認します。

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

よく見る診断項目

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

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

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

プラットフォーム別の注意 (ポータルのブロック): Android ビルドは manifest hash を作成しないため、ビルドハッシュのブロックは適用されず、バージョンのブロックのみ適用されます。WebGL は署名済みブロックリストをローカルで検査しません。バージョンのブロックは SDK バージョンとアプリのバージョンを同じリストで比較し、プラットフォームを区別しないため、ブロックしたバージョンはすべてのプラットフォームに適用されます。

CustomerGameServer では、ゲームサーバーがサーバー API キーで POST /v1/validate を呼び出してトークンを確認します。全体の流れと例は API リファレンスのサーバー API キーでゲームサーバーと連携するを参照してください。

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

Build Integrity は、ビルド時に生成される manifest に RSA 署名を追加できます。この manifest には、ランタイムで検証する assembly hash とファイル整合性情報が含まれます。リリースビルドでは manifest 自体が差し替えられると検証基準を信頼できないため、配布前に Window > OZero Security > Config & Dashboard の Generate Key Pair で manifest 署名キーペアを生成してください。SDK 1.2.0 以降、集約ハッシュ(oz_ahash)にはすべてのプリセットでプレイヤーの起動ファイルが常に含まれます。Windows・macOS・Linux(Mono・IL2CPP)は RuntimeInitializeOnLoads.json、ScriptingAssemblies.json、globalgamemanagers、globalgamemanagers.assets、Android はネイティブライブラリと global-metadata.dat に加えて RuntimeInitializeOnLoads.json、ScriptingAssemblies.json です。デスクトップで Compression Method が LZ4/LZ4HC の場合、globalgamemanagers・シーン・アセットは data.unity3d 1 ファイルにまとめられ、そのときは個別ファイルの代わりにこのファイルが存在すれば常にハッシュされます。ファイルが大きくても、SHA-256 の計算は起動時に 1 GB あたり 1 秒前後です。

Manifest 署名が必要な理由

ビルド時に、OZero は 秘密キーで manifest に署名します。プレイヤービルドには秘密キーは含まれず、セキュリティ設定に保存された公開キーだけが含まれます。ランタイムでは、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 用のキーペアを生成します。公開キーはセキュリティ設定(Project Settings)に保存され、個人キー はデフォルトで次のパスに保存されます(このパス自体は User Settings にユーザーごとに保存されます):
   [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 を使用する必要があります。

既存のキーペアの検証

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

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

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

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

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

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

現在のキーと以前のキー

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

安全なキー回転手順

1. 現在の fingerprint をバックアップします。 Assets/OZeroSecurity/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、セキュリティ設定の公開キー、OZeroManifestTrustAnchor の fingerprint、生成済みの manifest/signature ファイルのどれかが一致していないときに発生します。

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

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

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

Project Settings > OZero Security > Build Integrity > Manifest Signing Public Key が空のときに発生します。解決: 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"

セキュリティ設定の公開キーと 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 を実行して確認することを推奨します。

Install Source (Android Only) の設定

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

Steam Anti-Piracy (PC Only) の設定

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

Steamworks SDK フォルダーとライブラリの自動コピー

Project Settings > OZero Security > Steam Anti-Piracy (PC Only) > SDK Folder(または Check Setup の Steam 設定欄)で Steamworks SDK フォルダー(sdk フォルダーまたはその親フォルダー)を選んでください。ビルド時に OZero が対象プラットフォーム用の Steam API ライブラリをビルド出力へ自動でコピーするため、手動でコピーする必要はありません。

ビルド開始前に OZero がライブラリのファイル形式・アーキテクチャと対応する Steamworks バージョン(SteamApps v008–v009, SteamUtils v009–v010, SteamUser v022–v023)を検査し、一致しない場合はビルドが止まります。コピーは整合性 manifest の作成前に行われるため、Steam ライブラリも整合性検査の対象になります。macOS ビルドに署名するとき、libsteam_api.dylib の Valve 署名はそのまま保持されます(macOS の署名)。

他の PC と CI: 選んだフォルダーはその PC の Editor 設定にだけ保存され、プロジェクトファイルには残りません。他の PC や CI では、フォルダーを選び直すか、環境変数 OZERO_STEAMWORKS_SDK に SDK フォルダーのパスを設定してください。どちらもない場合、ビルドは案内メッセージとともに失敗します。

デスクトップ専用: Steam Anti-Piracy は Windows、macOS、Linux のプレイヤーでのみ動作します。オンのまま Android、iOS、WebGL をビルドしても、ビルドは警告を残して続行され、そのアプリでは Steam 検査が実行されず、Steam ライブラリも含まれません。このとき Check Setup には Info 項目 Steam Anti-Piracy is skipped for this build target が表示されます。

Steamworks.NET などのラッパーと併用する場合: ラッパープラグインがビルド出力に入れた steam_api ライブラリが選択した SDK のものと異なる場合、OZero は SDK のライブラリに置き換え、ビルドログに警告を残します。ラッパーのビルドに使われたのと同じ Steamworks SDK バージョンを SDK Folder に指定してください。

Steam 保護の執行レベル

Steam の違反がゲーム終了につながるのは、Detection Action が Callback または Block で、Response > Force Quit On Detection がオンのときです。この執行レベルはビルド時に boot メタデータへ封印され、終了はネイティブコードが直接実行します。ビルド出力の封印値がセキュリティ設定と異なる場合はビルドの preflight が失敗するため、再ビルドしてください。

Observe・Off の場合、Force Quit On Detection がオフの場合、forceSteamAntiPiracyObserveOnly がオンの場合、requireSteamApiInit がオフの場合、または Low プリセットの場合、違反は記録のみでゲームは終了しません。このような構成も許可されますが、Check Setup の Steam enforcement 項目に警告が表示され、ビルド時にもコンソールへ警告が出ます。終了が起きる構成では、同じ項目に「terminates on detection」と表示されます。

オンラインアドオンで Check Steam DRM With Server によりサーバーが Steam の所有を判定する構成では、ネイティブの終了ではなくサーバー判定の流れに従い、ローカルの Steam 違反は観察として記録されます。

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

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

運用での使い方

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

ゲームからバインディングを解除する

プレイヤーが正当に端末を変更した場合、ゲームから RequestReset で保存済みの指紋を消去できます。プレイヤービルドでは OZeroDeviceBindingDetector.SetResetAuthorizer で登録した認可コールバックに問い合わせ、コールバックが true を返したときだけ解除します。解除後は同じセッションで現在の端末をすぐに再登録するため、再起動は不要です。

using OZeroSDK.Security;

// Register once at startup.
OZeroDeviceBindingDetector.SetResetAuthorizer(request =>
{
    // Approve only after your own check succeeds, for example a recent
    // account re-authentication or a support code your server verified.
    return MyAccountService.HasVerifiedResetFor(request.Reason);
});

// Later, from your account recovery or support screen:
bool cleared = OZeroDeviceBindingDetector.Instance?.RequestReset("ticket-1234") ?? false;

プレイヤービルドでは、認可コールバックも有効なサーバー Reset Token もない場合、解除を拒否してエラーログを残します。エディターでは常に解除されます。RequestReset と認可コールバックは呼び出したスレッドで同期的に実行されます。ClearStoredFingerprint(token) も引き続き動作します。Pro ライセンスとサーバー設定(サーバー URL、ライセンスキー)がある場合、空でないトークンはバックグラウンドでサーバー Reset Token として検証されるため、解除は呼び出しが戻った後に行われます。結果が必要な場合は、メインスレッドで ClearStoredFingerprintAsync(token) を await してください(下の手順)。それ以外の場合は認可コールバックが判断し、トークンは request.AuthorizationToken で渡されます。

Standard ゲームのサポート対応ガイド

Standard には OZero サーバーがないため、ポータルの Reset Token は使えません。代わりに、ゲームのサポート確認手順を認可コールバック(SetResetAuthorizer)に直接つないでください。次のいずれかの方法を選び、どの方法でも上の警告のとおり、確認が通った後にだけコールバックで true を返してください。

A. ゲーム独自のサーバー(アカウントシステム)がある場合 — 推奨

1. サポート担当がバックオフィスでプレイヤーのアカウントに 1 回限りのサポートコードを発行します。
2. プレイヤーがゲーム画面でコードを入力します。
3. ゲームが自社サーバーでコードを先に非同期で検証します。
4. 通過したらゲームが RequestReset を呼び、コールバックは直前の検証が通ったかどうかだけを確認します。

プレイヤーの再ログイン(プラットフォームの再認証)で解除を許可する方法も同じ構造です。認可コールバックは同期的に実行されるため、非同期の検証を先に終えてから RequestReset を呼んでください。

bool _supportCodeVerified;

void Start()
{
    // The authorizer runs synchronously: it only reports whether the check just passed.
    OZeroDeviceBindingDetector.SetResetAuthorizer(_ => _supportCodeVerified);
}

async void OnSubmitSupportCode(string code)
{
    // Verify the one-time code issued by your support team on your own backend.
    _supportCodeVerified = await MyBackend.VerifyResetCodeAsync(accountId, code);
    try
    {
        bool cleared = OZeroDeviceBindingDetector.Instance.RequestReset("cs-support");
        ShowResetResult(cleared);
    }
    finally
    {
        _supportCodeVerified = false;
    }
}

B. サーバーのないオフラインゲーム — 署名コード方式

1. ゲームが要求コードを表示します。例えば、1 回限りの乱数とゲーム独自のセーブ・プレイヤー ID を短くエンコードした値です。
2. サポート担当が、開発元だけが持つ秘密鍵で署名した応答コードを返します。
3. ゲームは組み込みの公開鍵で応答を検証し、署名が有効なときだけコールバックが解除を許可します。同じ応答を再利用できないよう、使った乱数は破棄してください。

// Pseudocode. Game: build a request code that the player sends to support.
nonce        = RandomBytes(8)          // keep until the reset is done, then discard
requestCode  = ShortEncode(nonce + yourSaveOrPlayerId)

// Support tool on your side. The private key never ships with the game.
responseCode = Sign(studioPrivateKey, requestCode)          // Ed25519 or ECDSA

// Game: verify with the public key built into the game, then reset.
OZeroDeviceBindingDetector.SetResetAuthorizer(_ => _signedCodeVerified)
_signedCodeVerified = Verify(embeddedPublicKey, requestCode, responseCode)
OZeroDeviceBindingDetector.Instance.RequestReset("cs-offline")
_signedCodeVerified = false
Discard(nonce)

C. アプリデータの削除または再インストール

バインディングの記録はアプリのローカルストレージ(PlayerPrefs)にあります。プレイヤーがアプリデータを削除するかアプリを再インストールすると、次回起動時に新しい端末として登録されます。ローカルのセーブも消える可能性があるため、サーバーやクラウドのセーブがあるゲームでのみサポートの回答として使ってください。

D. 問い合わせを減らす

hardwareChangeTolerance を 1 以上にすると(Standard プリセットは 1、Strict は 0)、OS のアップデートやプライバシー設定の変更で識別値が 1 つ変わってもブロックせず、端末を再登録します。

Pro: ポータルの Reset Token と ClearStoredFingerprintAsync(token) を使ってください。下の Reset Token サポート手順 を参照してください。

Reset Token サポート手順(Pro)

1. 端末リセットが必要な理由とプレイヤーアカウントを、通常のサポート手順で先に確認します。
2. Customer Portal → Device Binding で対象端末を選び、Reset Token を発行します。
3. トークンは認証済みのサポートチャネルでのみ渡してください。公開チャット、スクリーンショット、長く残るチケットに残さないでください。
4. ゲームやサポート UI は、メインスレッドで await OZeroDeviceBindingDetector.Instance.ClearStoredFingerprintAsync(token.Trim()) にトークンを渡し、戻り値の bool を確認してください。ClearStoredFingerprint(token.Trim()) も動作しますが、サーバー検査がバックグラウンドで行われるため、解除は呼び出しが戻った後に行われます。
5. SDK がトークンを受け入れると、同じセッションで現在の端末をすぐに再登録します。再起動は不要です。

Speed & Time Hack 設定

Unity 時刻、ネイティブ基準時計、バックグラウンドタイマー、Web/Pro サーバー時刻を比較し、ゲーム速度を速く/遅くする操作や端末時計の変更を検出します。WebGL ではネイティブの時計比較を使えません。起動ログにその旨が表示され、ブラウザーの時計改ざん(Date.now / performance.now)は Injection & Hooking の WebGL ランタイム検査が代わりに検出します。

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 ランタイム改ざんが対象です。正規のオーバーレイやキャプチャツールも同じ経路でゲームに入るため、検知器はすべてのモジュールをファイルハッシュと署名者で識別し、モジュールごとに判断できるようにします。

見慣れないシステムモジュールが見つかっても、すぐにゲームを終了することはありません。まず確認対象として記録し、繰り返し検出されたことやファイルに署名がないことだけを理由にブロックしません。既存の許可ルールは維持され、ハッシュで明示的に拒否したモジュールにはブロック方針が適用されます。このオプションは Unity の Injection 設定で変更できます。Pro ポータルからのリモート変更には対応していません。他のプラットフォームには影響しません。

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

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

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

確定検知後の動作。Force Quit On Detection がオン(Standard・Strict プリセットの既定値)の場合、確定した注入モジュールはコールバック猶予時間の後にゲームを終了します。OZeroSecurityReceiver やコールバックでログを残すだけでも同じで、Windows ではネイティブのモジュール監視が直接終了します。インジェクションをゲーム側のコードだけで扱う場合は Force Quit On Detection をオフ(Low プリセット)にして Receiver で対応してください。

Pro ビルド。Pro ビルドに署名のないモジュールが注入されると、ライセンスサーバーが次のオンライン確認(約 4 分ごと)を拒否します。この拒否は Build Integrity の失敗として扱われ、Force Quit On Detection やコールバックに関係なく必ずゲームを終了します。正当なモジュールであればポータルで許可してください。

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

enableServerWhitelist を有効にすると、Pro ビルドはプロジェクトのポータル判定と 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++ ヒープに保存されるため、メモリスキャナーやメモリエディターではメモリをスキャンしても見つけることができません。型の名前を変更するだけで、残りのコードはそのまま動作します。

サンプルコード

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.

解決手順