Get Started

Overview

OZero Security protects Unity games by executing security logic in the Native C++ layer, which is difficult for general hacking tools to access. Core protection features operate simply by activating modules in the dashboard within the Unity Editor. No scene setup or additional code writing is required.

1 Import Package

Open the Unity Editor and import the OZero Security package. You can import it via the Unity Package Manager or by double-clicking the .unitypackage file.

When the Import Unity Package dialog appears, leave all items checked and click Import. The necessary scripts, native plugins, and editor tools will be added automatically.

Welcome window

After you import an OZero SDK package, the Welcome window opens automatically (Window > OZero Security > Welcome). It opens after every import of an OZero SDK package, even when the same version is imported again, and when a new SDK version is loaded for the first time. Importing the Built-in TMP dialog package or TMP resources does not open it.

The top of the window is one large card, STEP 1 · Run Setup. Start setup opens Check Setup, which lists what the project still needs; Auto Setup then applies it, asking before each change. Below it are two cards for after setup. Read the Manual has Online (the manual on the OZero website) and Offline (the HTML manual bundled with the package, Assets/OZeroSecurity/Documentation/HTML/index.html); Offline is disabled when the bundled manual is missing. Security Config (Open config) opens Edit > Project Settings > OZero Security, where you change the preset or individual protections once setup is done.

With the online add-on installed, the window also shows an Online Services row. Open opens Window > OZero Security > Online Services (creating the settings if needed).

With the online add-on installed, Offline opens the manual bundled with the add-on (Assets/OZeroSecurity/Online/Documentation/HTML/index.html).

Tick Don't show this window automatically again to stop it opening automatically in this project; you can still open it from the menu. It never opens in batch mode or when the OZERO_SUPPRESS_WELCOME environment variable is set, so CI and automated builds are not interrupted.

2 Open Dashboard

Once the import is complete, open the Config Dashboard from the Unity menu bar:

When the Config Dashboard opens, you can manage presets, security modules, licenses, and build integrity settings all at once on this screen. There is no need to manually locate and modify files in the Project window. The dashboard is the OZero Security page of Edit > Project Settings; you can also open it there.

Unity Editor Menu Reference

OZeroSecurity uses Window > OZero Security for setup windows and Tools > OZero Security for diagnostic or bake commands. Security presets are intentionally applied from Config & Dashboard, so you can review the resulting settings before saving.

• Window > OZero Security > Welcome: start screen
• Window > OZero Security > Config & Dashboard: security settings (opens Edit > Project Settings > OZero Security)
• Window > OZero Security > Check Setup: setup check and Auto Setup

Check Setup and Auto Setup

Open Window > OZero Security > Check Setup, or press Start setup in the Welcome window. Run it once right after importing the package and again before a release build.

Check Setup checks the project, the active build target and the security settings, and lists the items that block a build and the recommended changes. Each item has a Docs button and a fix button; fix the blocking items first.

Press Auto Setup to go through the recommended changes one step at a time. Each step shows the current and the new value; choose Apply or Skip. At the end, a summary lists what was applied, what was skipped and what is still open. Once no blocking item and no Auto Setup change is left, Check Setup shows a Setup complete box with an Open Build Settings button; build your game as usual from there.

What Auto Setup changes: turns off Development Build, switches to IL2CPP, sets Managed Stripping to Low, sets Android API 24 and ARM64, generates the DeveloperSecret, imports the TMP dialog package, generates the manifest signing key (and turns on Require Manifest Signature), and adds the Android debug SHA.

Signing key file: keep the manifest signing private key that Auto Setup creates outside the project and out of version control, and make it available on every build machine, including CI.

More: Auto Setup steps and behavior

Check Setup (Window > OZero Security > Check Setup, or Start setup in the Welcome window) checks the project, the active build target, the security settings, and platform release settings, and lists blocking issues, recommendations, and information. Each item has Docs and fix buttons, and the top of the window shows how many recommended changes Auto Setup can apply. The buttons at the top are, from the left, Auto Setup (with the number of pending changes), Re-check (runs the checks again), Manual and Security Config. Security Config opens Edit > Project Settings > OZero Security. Build-time validators still run during actual player builds.

The first time Check Setup opens after an OZero SDK package is imported, it asks whether to start Auto Setup when there are changes it can apply (Start Auto Setup / Not now). It asks again after every SDK package import, even of the same version, and never in batch mode. You can also start it later with the Auto Setup button.

Auto Setup first lists the planned steps; only the steps that the project and the active build target need are listed. Choose Start (or Cancel). For each step it shows the current value and the new value; choose Apply, Skip, or Stop. At the end, a summary lists what was applied, what was skipped, and what is still open, and Run Auto Setup Again starts it over. The possible steps are:

1. Turn off Development Build.
2. Switch the scripting backend to IL2CPP.
3. IL2CPP only: set Managed Stripping Level to Low.
4. Android: set the minimum API level to 24 and the target architecture to ARM64.
5. Generate a DeveloperSecret.
6. Import the Built-in TMP dialog package. Auto Setup installs TextMeshPro / Unity UI if needed, imports TMP Essential Resources, then imports the dialog package. A Processing screen shows the current stage and elapsed seconds until all of it finishes, then the next step starts. It continues across script reloads.
7. Generate the manifest signing key pair; the trust anchor is updated automatically. The step screen shows where the private key file is created. No result dialog appears: the private key location and fingerprint are written to the Console. If a key already exists, a dialog asks before it is overwritten. The next step turns on Require Manifest Signature.
8. Add the Android debug SHA. The result is written to the Console. If there is no debug keystore, a dialog asks whether to create one. Running these tools from their own buttons (Security Config, Keystore SHA Extractor) still shows the result dialogs.

With Fail Build on Setup Warnings on (on by default in the security settings), generating the key and requiring manifest signatures are regular steps: if you skip them, the warnings stay and the player build fails at preflight, and the step and summary screens say so. Only when that setting is off are they optional steps marked "(optional, review first)". The key step shows where the private key file is created; keep it outside the project and out of version control, and make it available on every build machine, including CI.

Steps this Editor cannot apply (for example the IL2CPP step when the Unity Editor does not have the IL2CPP module installed) are not walked through; the overview and the summary list them separately under Needs your action. Without the IL2CPP module, add it for the target platform in Unity Hub > Installs > Add modules, then run Auto Setup again. Player Settings changes cannot be reverted with Undo; the summary lists every change that was applied.

Two Check Setup errors protect OZero's native load anchor (the limits of client-side protection). OZero native plugins are not set to Load on startup: Auto Setup turns Load on startup back on for the OZero native plugins; do not turn it off. Android boot provider library is missing: Android builds with the Mono backend need this library; re-import the OZero Security package to restore Assets/OZeroSecurity/Plugins/Android/OZeroSecurityBoot.androidlib.

With the online add-on, Auto Setup can also fill in values that only you have. These steps show input fields, each with its label above it: enter the value and press Apply. The value is checked before it is saved and is never written to the Console or logs. If the check fails, the step shows why and saves nothing; enter a corrected value or press Skip.

• License Key: for Pro license key is empty and Native Variant <NNNN> needs your license key / is bound to a different license key. With a license-bound Native Variant in the project, the key is checked against that variant's license before it is saved; a key of another license is not saved.
• Server Public Key: for Pro server signing public key is not configured. Copy the signing public key (64 hex characters) from Customer Portal > Server Key; other input is rejected, and the key is stored in lowercase.
• Application Identifier: for Application identifier is not registered for Native Variant <NNNN>. The value depends on the active build target and matches Customer Portal > Platform settings. Android: Package Name; iOS: Bundle Identifier; the field starts with the current identifier. Apply also turns on Override Default Package Name / Bundle Identifier in Player Settings, because Unity ignores the identifier while it is off. Windows, macOS and Linux: enter the Company Name and Product Name registered for this platform in Customer Portal > Platform settings (shown there as Company / Product) in their own fields, which start with the current values; they are checked as company.product or com.company.product. Apply sets Player Settings Company Name and Product Name; the Product Name is also the name of the built app. WebGL is identified by the page origin (domain) registered in the portal, so nothing in the project needs to change and the step shows as unavailable. The value must be registered for your license; if it is not, the step asks you to register it in the Customer Portal and download the package again.

3 Enable Modules

You can check the list of security modules and toggle switches inside the dashboard. Enable the modules you want to use. Below is the recommended starting configuration.

Select Security Preset

First select a preset, then adjust individual modules to fit your project. For typical live games, we recommend starting with Standard. It offers the best balance of protection level, performance, and false positive risk.

More: what the presets change

The Quick Preset panel shows the preset that matches the current settings, for example Current: Standard, and marks that button in bold with *. After you change a value by hand, it shows Current: Custom and no button is marked. Standard is the recommended preset and its button reads Standard (Recommended); the preset names stay Low / Standard / Strict. A short description appears under each button and as its tooltip.

Windows system-module scanning (enableWindowsSystemModuleScan): Low OFF / Standard and Strict ON. These are security presets, not license tiers. See Injection settings for compatibility and observation rules.

Settings downloads are controlled by enableRemoteSpeedHackConfig, enableRemoteInjectionConfig, and enableRemotePhysicsConfig. A security preset turns them on only when the project's license tier (Online Services settings) is Pro; on Standard, or without license settings, presets leave every Pro-only server option off (re-apply the preset after switching the tier to Pro). They work only on Pro. The remote config options themselves do not turn on BIV server verification, install-source sync, the server whitelist or telemetry; presets change those values separately (see the preset table above).

• Low: Maintains only lightweight core checks. Relaxes platform native checks and forced termination policies so test environments aren't blocked too early.
• Standard: Turns on the core protection set, startup verification, runtime re-verification, emulator checks, and recommended IL2CPP file coverage. A configuration balancing compatibility and protection level.
• Strict: Applies the broadest coverage and treats more failures as critical violations. Apply after sufficiently testing platforms, signing, and store distribution flows.

License Model — Standard / Pro

OZero Security is provided in two tiers: Standard and Pro. Standard uses local protection features without server integration. Pro adds per-project Native Variant packages, manifest / Bundle ID binding, telemetry, signed server time, remote policies, and server verification.

이 앱은 부정 행위와 변조를 방지하기 위해 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 Settings

Security Config shows the add-on settings in two places. The Pro - License & Online Services card at the end of the Protection Modules group, which is the bottom of the page (after Steam Anti-Piracy (PC Only)), starts with License (tier and license key). With Tier Pro it also shows Server Connection, Offline & Device Policy, Security Level Enforcement (with the Security Config Hash (build allowlist) list), Telemetry, Online Verification UI and Validate License Now, and each detection module section (Build Integrity, Install Source (Android Only), Device Binding, Speed & Time Hack, Injection & Hooking, Steam Anti-Piracy (PC Only)) gets a Pro - Online block with that module's online settings. The block is disabled while the module's Activate is off.

The values are saved in ProjectSettings/OZeroLicenseSettings.asset, which you commit to version control; there is no settings asset in the Project window. The same settings are also available in a stand-alone layout: the Online Services button in Security Config and in the Welcome window opens Window > OZero Security > Online Services (creating the settings if needed), with Select Settings Asset and Validate License Now. At the top of the window, Security Config and Check Setup take you to those screens. The rest of this section describes the stand-alone layout; the field names are the same in Security Config.

Choose the tier in the License section. The License Key field is shown for both tiers. With Standard, only the License section is shown, with a note that Standard runs serverless: online services are off and nothing is sent to the OZero server; enter the License Key only when you use a package with your Native Variant, and it is checked locally. Select Pro to show the server connection and the online services.

The settings are organised like Security Config, in this order: Quick Preset, License, Server Connection, Offline & Device Policy, Security Level Enforcement (turned on with Enable in its header), the module sections Build Integrity, Install Source, Device Binding, Speed & Time Hack, Injection & Hooking and Steam Anti-Piracy, and finally Telemetry and Online Verification UI.

There is one preset for the whole SDK. The Low / Standard / Strict buttons here apply the same preset as Security Config, so either place gives the same result. Here too Standard is the recommended preset, shown as Standard (Recommended), with a description under each button. Applying a preset updates the detection modules, the online service defaults and Declared Security Level together; the license, server URL and keys are kept. The panel shows the current state, for example Current: Standard, with that button in bold and marked *, and Current: Custom with no button marked after you change an online setting by hand. The Security Level Enforcement section warns when Declared Security Level differs from the applied preset.

The module sections use the same names and order as Security Config. Each header shows the module's state in Security Config (Active / Inactive, read-only), and each section starts with one line on what the online service adds to that module. The server switch is the first row of the section:

• Build Integrity: Check Integrity With Server
• Install Source: Check Installer With Server
• Device Binding: Verify Device With Server
• Speed & Time Hack and Injection & Hooking have several server features, so they have no single switch.
• Steam Anti-Piracy: Check Steam DRM With Server

In Security Config, a module's Pro - Online block is greyed out with Activate this module to use its online settings. while the module is off. In the stand-alone layout, the section of an inactive module says that these online settings have no effect until the module is activated, and offers Open Security Config.

Telemetry and Online Verification UI are online-only. Telemetry covers the security events sent to the Customer Portal and the remote physics config. Online Verification UI sets how the screens shown during server verification behave (checking, retry, online required and timeout): the UI policy, the retry and online-required times, the timeout action, and automatic retry when the network comes back. Dialog design and language follow Security Config > Player Notice (Managed UI). While both Check Integrity With Server and Check Steam DRM With Server are off, the section notes that it is not used.

The add-on has no separate log switch: its logs follow Enable Debug Logs in Security Config.

Pro Packages and Native Variant

Pro customers download the Pro unified package from the Customer Portal downloads: one .unitypackage made for the license, with the Standard SDK, the online add-on and the Native Variant for every platform. The card offers two options:

• With your Native Variant: the private native libraries assigned to this license. The card shows the assigned number (Variant · Native · ABI), and the package is bound to your license: the license key and the Bundle IDs / package names registered for it.
• With the Standard variant (0000): the Standard SDK's public native libraries as shipped, with no license binding.

When you rotate the Variant: builds you already made with the previous Variant keep working. The new Variant applies from builds made with the package you download after the rotation. A rotation counts against your rotation quota, and refunds are not available after a rotation.

To use a package with your Native Variant on Tier Standard, keep Tier on Standard and only enter the License Key in Security Config > Pro - License & Online Services > License. The build and the player check the key locally, and Tier Standard sends nothing to the OZero server. This relies on Allow Standard Build With Premium License, which is on by default; if it is off, Check Setup asks you to turn it on or to set Tier to Pro.

To build without a license key, download the package with the Standard variant (0000).

If you bought the SDK on the Unity Asset Store, install the SDK from the Asset Store and download only the Pro extension package from the Customer Portal: the online add-on and your assigned Native Variant, made for the SDK version you choose on the card. The SDK itself is not included.

Native Variant items in Check Setup

When the package contains a Native Variant, Check Setup reports whether the project matches it before you build. A player build stops with the same reason.

Game Server Integration: Device ID and User UUID

Pro lets your game server work with the IDs OZero uses. Read the OZero device ID to store it with the player's account, and link your own user UUID (account ID) so that you can find the devices a user played on and block the user in the Customer Portal.

Reading the device ID

Read OZeroLicenseRuntime.CurrentDeviceId. With the default settings it is the same value the Customer Portal and telemetry show. Do not replace DeviceIdProvider to link accounts: that changes the device ID the server knows. Use the user UUID API below instead; it keeps the device ID.

Linking your user UUID

• After the player signs in, call OZeroLicenseRuntime.SetExternalUserId(uuid). It returns false and ignores the value when it is empty after trimming spaces, longer than 128 characters, or contains control characters.
• On sign-out, call OZeroLicenseRuntime.ClearExternalUserId(). HasExternalUserId tells whether a user is linked.
• The UUID is hashed on the device with SHA-256 and a per-license salt. Only the hash is sent with telemetry, physics events and device policy checks, and only the hash is stored on the server. The original UUID never leaves the device and is not written to disk.
• You can call it before activation finishes. The SDK keeps the UUID in memory and starts sending the hash after activation.

Blocking a user

In the Customer Portal, a block rule for a user has one of two actions:

• Callback only: the game receives a policy action (Module = "user_policy", PolicyId = rule ID, Reason = the operator's reason) once per session and decides what to do. The session is not ended.
• Terminate: the game first receives a policy action (Module = "user_policy", ActionId = "user_blocked", Reason = "terminate"). The SDK then shows the same termination notice as a device policy block (OZ-SEC-0E) and ends the session.

To tell a user block from a device block, read OZeroLicenseRuntime.LastServerBlockCode: "USER_BLOCKED" for a user, "DEVICE_BLOCKED" for a device. The check runs about 5 seconds after SetExternalUserId, even when the device policy heartbeat is off, and at most once every 30 seconds. If the network fails, the session is not ended; the next check decides.

Customer Portal: User UUID page

Open Operations > User UUID in the Customer Portal (Pro). The page has three tabs:

• Find user: enter the UUID your game passed to SetExternalUserId. The browser hashes it before sending, so the raw value never reaches the server. The result shows the devices the user played on (first and last seen, event count), recent events (telemetry, physics events, policy blocks) and the block status, with buttons to create, edit or lift a block rule. Find by device takes a device ID (CurrentDeviceId) and shows how many users are linked and the first 8 characters of each user key. Raw UUIDs cannot be shown; search by UUID to confirm a user.
• Block rules: lists the rules (In effect or All). New rule takes the user's UUID, the action (Callback only or Terminate), a reason that is also sent to the game callback, and an expiry: Never (default, until lifted), 7, 30 or 90 days, or a chosen date. Saving a rule for a user who already has one updates it. Each rule shows where it was made: Portal, Server API or Operator.
• Settings: shows the license's salt, the formula, the UUID normalization rule, the current counts, and C#, Node.js and Python examples for computing the same hash (h1) on your server. Your server uses this h1 with the server API. The game client does not need the salt; the SDK receives it at activation.

Reissue salt (Settings tab) breaks existing links: user links and block rules made with the old salt no longer match your users, and existing rules stay under their old keys. The game gets the new salt at its next activation, and your server must recompute h1 with it.

Saving or lifting a block rule and reissuing the salt are recorded in Operation history under the User UUID category.

The Customer Portal is a single-page app. If a screen looks outdated or broken after an update, reload the page.

The same examples as the Settings tab. Check your implementation with the test vector in the API reference (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()

Example: sign-in, sign-out and the policy callback

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);
    }
}

Privacy and store disclosures

• Use a pseudonymous account ID as the UUID, not an email address or a phone number.
• iOS: the add-on's privacy manifest already declares User ID, so no extra entry is needed.
• Google Play: declare User IDs in the Data safety form when you link user UUIDs.

Security Config Hash Allowlist

Every build seals its security settings (OZeroSecurityConfig, including the online add-on settings) and computes a SHA-256 hash of them. When you approve the hashes of the builds you ship, the server's security level check accepts only those builds, so a tampered build with weakened settings cannot pass by declaring a high security level.

• Compatibility mode (no approved hash): only the declared security level is compared; every build passes the hash check.
• Enforced mode (one or more approved hashes): a build whose hash is not approved is rejected. With Fail On Security Level Reject on, the game ends; otherwise it is downgraded to Standard.

Pro only. It works only when Security Config > Pro - License & Online Services > Security Level Enforcement is turned on (Enable in its header, enableSecurityLevelCheck). When it is off, the build does not send its hash and the allowlist has no effect; the section then shows a single warning instead of the hash list.

Finding a build's hash

• The build log prints [OZero] Security config digest for this <Target> build: <64 hex>.
• While Security Level Enforcement is on, the Security Level Enforcement section of the Pro - License & Online Services card at the bottom of Security Config shows the last 5 builds in Security Config Hash (build allowlist): target, time (UTC), hash and a Copy button. The same section in Window > OZero Security > Online Services shows the same list.
• The record file Library/OZeroSecurity/BuildConfigDigests.json keeps the last 20 builds.
• A player sends exactly this hash: the digest in the build log and in the Pro card (or the Online Services window) is the value the server receives.
• Building the same settings on another machine gives the same hash.
• Editor Play Mode sends a hash computed from the config asset, not a build hash. It can appear under Hashes the server received in the portal; do not approve it.

Approving hashes in the Customer Portal

Open Policy Settings > Security Config Hashes (Pro).

• The top shows the policy mode (Enforced or Compatibility) and the number of approved, active hashes.
• Approved hashes: Revoke removes one. Revoking the last one returns the license to compatibility mode.
• Hashes the server received: hashes sent by builds with Security Level Enforcement on (no device IDs are stored; sightings are counted at most once an hour). Press Approve on your release build's hash.
• Register a hash: enter the hash from the build log or the Pro card, a label and an expiry (Never, 30 days, 90 days or 1 year).
• The first approval asks you to confirm that builds whose hash is not approved will be rejected. Approve every build you currently ship before you turn it on.

Approvals and revocations are recorded in Operation history. To register hashes from CI, see Security config hashes (CI) in the API reference.

Registering a Pro License Key

Standard works without any separate license setup. For Pro, enter the license key issued to your project in the Online Services settings, which are saved in ProjectSettings/OZeroLicenseSettings.asset. Pro uses this key to download the project-specific Native Variant package from the portal and to confirm during build that the package belongs to the current project. Pro also uses the key for runtime activation and Pro-only server features.

1. Create Config Asset

The online add-on creates the license settings in ProjectSettings/OZeroLicenseSettings.asset automatically once the Editor is idle after import (not while an old OZeroLicenseConfig asset is still under Assets/). Enter the license in the Pro - License & Online Services card at the bottom of Security Config: choose the tier in License and enter the license key (with Standard, only when you use a Native Variant package); the server URL and keys are in Server Connection. Online Services in Security Config or in the Welcome window opens Window > OZero Security > Online Services with the same settings and creates them if they are missing. Commit ProjectSettings/OZeroLicenseSettings.asset to version control.

2. Fill Inspector Fields

3. Confirm Check Integrity With Server

Before you build, check that Security Config > Build Integrity > Pro - Online > Check Integrity With Server has the value you want. The Standard and Strict presets turn it on and Low turns it off; new Online settings start with the Standard values (on). Turning it on adds the server build verdict and re-checks while the game runs, and with Standard the game needs to be online at startup. The portal's device and Variant blocks apply whether or not it is on. With the default Built-In verification UI, the TMP dialog package is required; Auto Setup imports it. If the game must run offline, see Offline Behavior.

4. Build & Verify

You do not need to add extra code. When the app starts, the SDK automatically reads the license settings that the build packed into the player as an encrypted resource. On the first run, check the Player log for a line such as [OZeroLicense] activated; tier=pro caps=5. If you configured Pro but the log says Standard mode, check first that ProjectSettings/OZeroLicenseSettings.asset exists and was saved before the build, and that Check Setup reports no Old OZeroLicenseConfig asset found.

Offline Behavior

Standard runs without a server. Pro can reuse saved activation information while offline, unless the license policy requires a new online confirmation at startup.

Standard — starts without internet

Standard does not ask any server for permission. It runs the local protection modules bundled in the app, so the game starts even when the player is offline. Only Pro server features such as telemetry and signed time are unavailable.

Pro — local protection stays offline; selected server features use cache

When optional Pro server features are enabled, the device and license are confirmed while online. Selected server features can tolerate a temporary disconnection for a limited time. This check does not gate builds made with an acquired Native Variant or local protection.

Games that must run offline: the Standard and Strict presets turn on Check Integrity With Server, so the game needs a connection for server verification. To run offline, apply the Low preset or turn off Security Config > Build Integrity > Pro - Online > Check Integrity With Server. In that case the server build verdict and in-game re-checks are not performed.

Saved Pro activation information stays valid until the server-signed activation token expires. The OZero server sets that expiry when it issues the token, currently 7 days after a successful activation; the SDK cannot extend it. After it expires, another successful activation is needed before Pro server features return. The acquired Native Variant and local detection settings are unchanged. This validity period is separate from the Local clock policy described below.

Pro — choose how the device clock is used

Open Customer Portal > License > Local clock to choose whether saved Pro activation information may be reused at an offline start. Online activation uses server time, so an incorrect device date or time does not by itself reduce an online Pro session.

Pro — portal-blocked builds stay blocked offline

A temporary server or network problem is different from a build that an operator intentionally blocked in the portal. When Pro activation succeeds, the server also sends a signed block list, such as blocked build hashes, SDK versions, and app versions. The SDK keeps this policy separate from the temporary server-feature state.

Configure this behavior with Offline Pro Policy Mode in the Offline & Device Policy section of the Pro - License & Online Services card in Security Config (also in the Online Services window; OZeroLicenseConfig.offlineProPolicyMode). The option controls how local Build Integrity handles the last signed Pro portal block policy when the device cannot reach the server.

In short, ApplyCachedBlockPolicies is a fail-open operating default, RequireFreshPolicy is a fail-closed policy mode, and IgnoreCachedBlockPolicies is a test bypass. If every validation must require online server confirmation, also configure the server Integrity or Managed Verification requirements instead of relying on this option alone.

License Issues

If something looks wrong, first search the Unity Player log for [OZeroLicense]. This tells you whether the SDK started as Standard, whether Pro activation succeeded, and why it downgraded to Standard when activation failed. For security-event upload issues, also search for [OZeroTelemetry].

Project Settings

Before adjusting individual security modules, first check the Unity Player Settings that affect native plugins, store builds, and platform verification.

Minimum Build Targets

Recommended release build settings

We recommend these settings for release builds.

• Set Scripting Backend to IL2CPP (Project Settings > Player > Other Settings).
• Set Managed Stripping Level to Low. With the Mono backend, keep it Disabled.
• After changing these settings, test scene changes, save and load, and external SDKs such as payments and ads on a real device.

Limits of client-side protection

A Mono build can be decompiled and edited with common tools, so a modified build can skip client-side checks. IL2CPP makes such edits much more expensive, but it is not complete protection either. The real countermeasures are server verification and making your game code depend on OZero APIs such as Secure Variables.

For games where a bypass would cause real damage, we recommend:

• Keep key game values (currency, score, stats) in Secure Variables (OZeroSV). Removing or disabling the SDK then breaks the game, which makes a bypass more expensive.
• Turn on server integrity verification (OZeroManaged or CustomerGameServer) and check the OZA token or the managed session on your game server. A modified client cannot obtain a valid server signature.

macOS: Developer ID signing and notarization

A macOS build from Unity is ad-hoc signed, so with Build Integrity on it closes about 10 seconds after launch. To distribute it, sign it with a Developer ID Application certificate. With automatic signing turned on, OZero signs the build when it finishes.

Turn on automatic signing (recommended)

1. Open Window > OZero Security > macOS Distribution Signing and turn on Sign macOS builds. When the build target is macOS, Open signing settings in Check Setup opens it too.
2. In Certificate, pick your Developer ID Application certificate. If the keychain holds only one, leave Automatic.
3. To notarize during the build, turn on Notarize and enter the Notary keychain profile name you created once with xcrun notarytool store-credentials.
4. Click Save. From then on every macOS build is signed when it finishes; when the Console shows macOS distribution signing complete, the app is ready to distribute.

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: code signing and integrity re-bake

If you do not code-sign your Windows or Linux builds yourself, skip the steps below. If you sign the executable or native modules after the build, re-bake the OZero integrity files after signing; otherwise the game closes at startup with an integrity error (0x0A).

1. Build as usual, then sign the executable and your own DLLs or .so files. The OZero DLLs are already signed, so you do not need to sign them again. A release build needs a certificate the OS trusts; a self-signed test certificate does not pass.
2. Re-bake the integrity files against the signed output with the command below, or use Tools > OZero Security > Re-bake Integrity After Code Signing (Windows or Linux player)... in the Editor.
3. Package and ship the output. The integrity files live under <Game>_Data/StreamingAssets and are not signed. If you use server verification, register the manifest hash printed by the re-bake.

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 Settings

# 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.** { *; }

• Do not rename, delete, or repackage libOZeroSecurity.so. Keep the plugin under Assets/OZeroSecurity/Plugins/Android/arm64-v8a, and if you distribute 32-bit builds, keep armeabi-v7a as well.
• If you are using Build Integrity > Check Platform Native and Android SHA Keys, make sure to test with the final signed APK or AAB after applying Minify/R8. Debug keystore fingerprints and release keystore fingerprints are different.

5 Security Settings (OZeroSecurityConfig)

The security settings are created with the Standard preset when the package is imported. Edit them in Edit > Project Settings > OZero Security; Window > OZero Security > Config & Dashboard opens the same page. Shared values are saved in ProjectSettings/OZeroSecuritySettings.asset, which you commit to version control; it holds no secrets. DeveloperSecret and the manifest signing private key path are per-user values saved in UserSettings/OZeroSecuritySecrets.json, which stays out of version control. Read the settings with OZeroSecurityConfig.Instance at runtime and in editor scripts; to change them from a script, see Custom build scripts. The page is ordered Quick Preset, Project & Advanced (Common Settings, Editor Play Mode), Detection Response (Global Threat Response, Player Notice (Managed UI)), then Protection Modules. Every section starts collapsed; click its title to expand it. The Security Termination Notice policy is in Player Notice (Managed UI) under Detection Response.

Common Settings

Top-level settings shared by all security modules. Defaults in this table use the serialized values defined in code. In Security Config they are under Common Settings in the Project & Advanced group, split into Keys & Storage, Build Checks (Preflight) and Logs & Diagnostics.

Player Notice (Managed UI) (All licenses)

Security Termination Notice, the shared dialog prefab, and localization are available in Standard and Pro. Pro additionally exposes Managed Verification retry, timeout, and provider settings. Before importing the optional package, use Package Manager to install Unity UI and TextMeshPro. The notice describes an already-armed fatal response; it cannot cancel exit or extend the native deadline.

Global Threat Response

Determine how the game will respond when a security threat is confirmed. During testing, check callbacks and logs first, and in actual deployment builds, choose the notification time for players and the termination policy according to your project's operation method.

Integration Troubleshooting

If the app closes after enabling OZero Security, or only fails in a specific environment, first use the local diagnostic file to identify which module reacted. Instead of guessing, follow the tables below using the module, subCode, and reason values from the file.

When the app keeps closing

Fields you will usually see

Common symptoms and first checks

Build Integrity Validator Settings

Configure the build integrity checker to detect modified game files, debugger attachments, and abnormal execution environments.

Platform notes (portal blocks): Android builds do not produce a manifest hash, so build-hash blocks do not apply there; only version blocks do. WebGL does not check the signed block list locally. Version blocks compare the SDK version and the app version against the same list and do not distinguish platforms, so a blocked version applies to every platform.

With CustomerGameServer, your game server checks each token with POST /v1/validate and a server API key. The API reference guide Game Server Integration with the Server API Key walks through the whole flow with examples.

Generate RSA Signing Keys (Build Integrity Manifest)

Build Integrity can add an RSA signature to the manifest generated at build time. The manifest contains the assembly hashes and file integrity information that the SDK will verify at runtime. In release builds, the SDK must also know that this manifest itself has not been replaced, so create the manifest signing key pair from Window > OZero Security > Config & Dashboard before shipping. Since SDK 1.2.0 the aggregate hash (oz_ahash) always includes the player startup files, with every preset: RuntimeInitializeOnLoads.json, ScriptingAssemblies.json, globalgamemanagers and globalgamemanagers.assets on Windows, macOS and Linux (Mono and IL2CPP), and RuntimeInitializeOnLoads.json and ScriptingAssemblies.json on Android, in addition to the native libraries and global-metadata.dat. When Compression Method is LZ4 or LZ4HC, a desktop player packs globalgamemanagers, the scenes and the assets into data.unity3d; that file is then hashed instead, whenever it exists. Even for a large file, SHA-256 costs about one second per GB at startup.

Why manifest signing matters

At build time, OZero signs the manifest with the private key. The private key is not included in the player build; only the public key stored in the security settings is included. At runtime, the SDK uses that public key to check whether the manifest is still the one created during the build. If the signature is valid, the SDK uses that manifest as the trusted baseline for assembly and file hash checks. If the signature is missing or does not match, the manifest may have been replaced or edited, so Build Integrity treats it as a failure and follows your Response Settings.

Generate a key pair

1. In the Unity Editor, open Window > OZero Security > Config & Dashboard.
2. Expand the Build Integrity section on the page.
3. Enable the Require Manifest Signature checkbox.
4. Click the Generate Key Pair button.
5. OZero generates a key pair for Build Integrity manifest signing. The public key is stored in the security settings (Project Settings), and the private key is saved to this default path (the path itself is a per-user value in User Settings):
   [ProjectRoot]/OZeroSigningKeys/manifest_private_key.pem
6. A confirmation dialog showing the private key location appears. Click OK to close it.

Important — Private Key Security

• The private key file is stored outside the Assets/ folder to prevent Unity from including it in builds. Never move it into Assets/.
• Exclude OZeroSigningKeys/ from version control with .gitignore or svn:ignore. Committing the private key is a critical security risk.
• Back up the private key to a secure location. Anyone with this file can create a valid Build Integrity manifest for your project.
• If you lose the private key, already released builds continue to work. However, the next update can no longer sign a new manifest with the old key. Generate a new key pair, regenerate the integrity manifest, and ship a clean build. The public key, fingerprint, manifest, and signature must match, or Build Integrity verification can fail.

Custom Private Key Path (CI/CD & Team Environments)

The Manifest Signing Private Key Path field does not choose where Generate Key Pair creates a new key. It tells the build and validation tools where to read the PEM private key. Generate Key Pair creates the key at the project default path, then records that path in the config. For CI/CD or team builds, restore the same PEM to a secure path first, then point this field at that path.

• CI/CD Pipelines — Store the PEM in a CI secret and restore it right before the Unity build. The runner does not need to keep the key on disk permanently.
• Team Environments — Use a secure mount path or secrets manager that only release builders can access. Every release build machine must use the same PEM.

Validate an existing key pair

To check whether the private key on disk matches the public key stored in the security settings, click Validate Key Pair. OZero derives the public key from the PEM and compares it with the settings. If they do not match, restore the matching private key or generate a new key pair, then rebuild cleanly.

When to regenerate a key pair

• If the private key is lost or compromised.
• If Validate Key Pair reports a mismatch (keys are not synchronized).
• When deliberately rotating keys as part of a scheduled security policy.

After regeneration, already released builds continue to work with their own embedded key and manifest. The next update build must use the new public key, fingerprint, manifest, and signature as one matching set. Regenerate the integrity manifest and ship a clean build.

Dual Fingerprint Key Rotation

When you click Generate Key Pair, the public key is saved in the security settings, and a fingerprint for that key is recorded in Assets/OZeroSecurity/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs. At runtime, the SDK first checks that the public key in the settings still matches the trusted fingerprint before it accepts a signed manifest.

Current Key and Previous Key

ExpectedPublicKeyFingerprintHex is the fingerprint for the key used by the current build. PreviousPublicKeyFingerprintHex is an optional transition slot. It does not replace manifest regeneration, and it is not a server-side key manager. The public key in the security settings, the fingerprint, the manifest, and the signature still need to be generated as one matching set.

Safe Rotation Procedure

1. Back up the current fingerprint. Open Assets/OZeroSecurity/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs and copy the ExpectedPublicKeyFingerprintHex value into a temporary note.
2. Register into the previous key slot. In the same file, paste the value copied in step 1 into PreviousPublicKeyFingerprintHex and save.
3. Generate a new key pair. Open Window > OZero Security > Config & Dashboard, then click Generate Key Pair in Build Integrity. The new public key and Expected fingerprint are updated automatically. Keep the Previous value from step 2.
4. Regenerate the integrity manifest and make a clean build. The new manifest and signature must be produced with the new private key.
5. Keep a transition period. Existing released builds keep using their own embedded key and manifest. The Previous slot is a safety net for rollback or mixed-artifact cases while the new build rolls out. Choose the window based on your update speed, commonly 1-4 weeks.
6. Clear the previous key slot. Once the usage of the old build has dropped sufficiently, revert to PreviousPublicKeyFingerprintHex = "" and release once more to complete the rotation.

What the Previous slot does

Old shipped builds do not need the new key to keep working. They already carry their own public key, fingerprint, manifest, and signature. The Previous slot is useful for the new release line during a controlled key rotation window. Keep it only as long as you need the transition, then clear it in a later release.

Troubleshooting

Start with the simple checks first: run Generate Key Pair if no key exists, run Validate Key Pair if a key exists, then regenerate the integrity manifest and make a clean build. Most issues come from one of these four items being out of sync: private key PEM, public key in the security settings, fingerprint in OZeroManifestTrustAnchor, or the generated manifest/signature files.

Symptom 1 — Release build terminates immediately after launch

ExpectedPublicKeyFingerprintHex may be empty. Release builds fail closed when the fingerprint is missing. Fix: run Generate Key Pair, wait for Unity to recompile, then make a clean build. If the value is already filled, run Validate Key Pair and rebuild from an empty output folder.

Symptom 2 — Build halts just before starting with "no manifest signing public key is configured"

Occurs when Project Settings > OZero Security > Build Integrity > Manifest Signing Public Key is empty. Fix: Open Window > OZero Security > Config & Dashboard, click Generate Key Pair in the Build Integrity section, and rebuild.

Symptom 3 — Runtime log: "Manifest signing public key does NOT match the pinned trust anchor fingerprint — APK appears to have been repacked with attacker-controlled keys"

Occurs when the public key in the security settings does not match the fingerprint recorded in OZeroManifestTrustAnchor. This often happens after restoring only part of a key pair or manually editing generated files. Fix: run Validate Key Pair. If it reports a mismatch, restore the matching PEM or generate a new key pair, regenerate the integrity manifest, and make a clean build. If this appears only in a distributed build, also check whether the APK or executable was repackaged.

Symptom 4 — The new build fails manifest verification after key rotation

One part of the rotated set is probably stale: public key, fingerprint, manifest, or signature. Fix: keep the old fingerprint in PreviousPublicKeyFingerprintHex only if you need a transition window, then run Validate Key Pair, regenerate the integrity manifest, clear the old build output, and build again.

Symptom 5 — Local build succeeds but CI build signs with a wrong key or says "private key not found"

CI does not automatically have the local OZeroSigningKeys/manifest_private_key.pem file. Fix: store the PEM as a CI secret and restore it before the Unity build, either to the default path or to the custom path configured in Manifest Signing Private Key Path. Make sure every release runner uses the same PEM, then run Validate Key Pair once in the release environment.

Install Source (Android Only) Settings

Restrict the game to run only if installed from approved stores or paths. Useful for preventing sideloading or repackaged APKs.

Steam Anti-Piracy (PC Only) Settings

Checks Steam execution paths, App IDs, authorization states, and release settings for PC builds distributed via Steam. Standard is local verification, while stronger ownership verification via the Steam server is provided by Pro's server Steam Attestation.

Steamworks SDK folder and automatic library copy

Select the Steamworks SDK folder (the sdk folder or its parent) in Project Settings > OZero Security > Steam Anti-Piracy (PC Only) > SDK Folder, or in the Steam setup fields of Check Setup. When you build, OZero copies the Steam API library for the target platform into the build output, so you do not copy it by hand:

Before the build starts, OZero checks the library's file format and architecture and the supported Steamworks versions (SteamApps v008–v009, SteamUtils v009–v010, SteamUser v022–v023). If they do not match, the build stops. The copy happens before the integrity manifest is written, so the Steam library is covered by the integrity check as well. When a macOS build is signed, Valve's signature on libsteam_api.dylib is kept (macOS signing).

Other PCs and CI: the selected folder is saved only in this PC's Editor preferences, not in the project files. On another PC or a CI machine, select the folder again or set the environment variable OZERO_STEAMWORKS_SDK to the SDK folder path. Without either, the build fails with a message that explains this.

Desktop only: Steam Anti-Piracy runs only in Windows, macOS and Linux players. If you build for Android, iOS or WebGL with it turned on, the build continues with a warning: that app does not run the Steam check and does not include the Steam library. Check Setup shows the Info item Steam Anti-Piracy is skipped for this build target.

With Steamworks.NET or another wrapper: if a wrapper plugin put a different steam_api library in the build output, OZero replaces it with the library from the selected SDK and logs a warning in the build log. Select as the SDK Folder the same Steamworks SDK version the wrapper was built for.

Steam enforcement level

A Steam violation terminates the game when Detection Action is Callback or Block and Response > Force Quit On Detection is on. This enforcement level is sealed into the boot metadata at build time, and the native code carries out the termination itself. If the sealed value in the build output does not match the security config, the build preflight fails; rebuild in that case.

With Observe or Off, Force Quit On Detection off, forceSteamAntiPiracyObserveOnly on, requireSteamApiInit off, or the Low preset, a violation is only recorded and the game keeps running. These configurations are allowed, but Check Setup shows a warning in its Steam enforcement item and the build logs a warning to the console. When the configuration terminates, the same item reads "terminates on detection".

With the online add-on, when Check Steam DRM With Server lets the server decide Steam ownership, the server decision flow applies instead of native termination, and local Steam violations are recorded as observations.

Device Binding Settings

Stores a fingerprint for the first trusted device and compares later launches against it. This helps detect when the same account or protected save data is moved to a different device.

How to use it in operations

In Pro, Device Binding becomes an operations tool. The server can remember which device fingerprints belong to a license, block devices that repeatedly show risk, and help support legitimate device changes without disabling the whole license.

Resetting a binding from your game

When a player legitimately moves to a new device, your game can clear the stored fingerprint with RequestReset. In player builds the SDK asks the authorizer you register with OZeroDeviceBindingDetector.SetResetAuthorizer and resets only when it returns true. After the reset the SDK binds the current device again in the same session, so no restart is needed.

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;

In player builds, a reset with neither an authorizer nor a valid server Reset Token is refused and logged as an error. In the Editor the reset always proceeds. RequestReset and the authorizer run synchronously on the calling thread. ClearStoredFingerprint(token) keeps working: with a Pro license and server settings (server URL and license key), a non-empty token is verified as a server Reset Token in the background, so the reset happens after the call returns; await ClearStoredFingerprintAsync(token) on the main thread when you need the result (flow below). Otherwise your authorizer decides and receives the token in request.AuthorizationToken.

Support guide for Standard games

Standard has no OZero server, so the portal Reset Token is not available. Connect your own support check to the reset authorizer (SetResetAuthorizer) instead. Pick one of the approaches below. Whichever you use, return true from the authorizer only after the check has passed, as the warning above says.

A. Your game has its own server or account system (recommended)

1. Support issues a one-time support code for the player's account in your back office.
2. The player enters the code in the game.
3. The game verifies the code with your server first, asynchronously.
4. If it passes, the game calls RequestReset, and the authorizer only checks whether that verification just passed.

Allowing a reset after the player signs in again (platform re-authentication) follows the same structure. The authorizer runs synchronously, so finish the asynchronous check before calling 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. Offline game without a server: signed codes

1. The game shows a request code, for example a short encoding of a random single-use value and your own save or player ID.
2. Support returns a response code signed with a private key that only your studio holds.
3. The game verifies the response with the public key built into it, and the authorizer allows the reset only when the signature is valid. Discard the single-use value afterwards so the same response cannot be reused.

// 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. Clearing app data or reinstalling

The binding record lives in the app's local storage (PlayerPrefs). After the player clears the app data or reinstalls the app, the next launch registers the device as new. Local saves can be lost too, so give this answer only for games with server or cloud saves.

D. Fewer support requests

With hardwareChangeTolerance at 1 or higher (the Standard preset uses 1; Strict uses 0), a single changed identifier, for example after an OS update or a privacy setting change, is not blocked; the SDK registers the device again.

Pro: use a portal Reset Token with ClearStoredFingerprintAsync(token). See the Reset Token support flow below.

Reset Token support flow (Pro)

1. Confirm the player account and why the device reset is needed through your normal support process.
2. Open Customer Portal → Device Binding, find the target device, and issue a Reset Token.
3. Send the token only through an authenticated support channel. Do not leave it in public chat, screenshots, or long-lived tickets.
4. Your game or support UI should pass the token to await OZeroDeviceBindingDetector.Instance.ClearStoredFingerprintAsync(token.Trim()) on the main thread and check the returned bool. ClearStoredFingerprint(token.Trim()) also works, but the server check runs in the background and the reset happens after the call returns.
5. After the SDK accepts the token, it binds the current device again in the same session. No restart is needed.

Speed & Time Hack Settings

Compares Unity time, native reference clocks, background timers, and web/Pro server time to detect attempts to speed up or slow down gameplay and to catch device-clock changes. On WebGL the native clock comparison is not available: the startup log says so, and browser clock tampering (Date.now / performance.now) is detected by the WebGL runtime checks of Injection & Hooking instead.

Use OZeroTime.timeScale instead of Time.timeScale

When the Speed & Time Hack protection module is enabled, project code must not directly modify Unity's built-in Time.timeScale. If code bypasses OZero and writes to it directly, the OZero detector may treat the change as suspicious runtime time manipulation and run the configured response policy.

OZeroSecurityConfig.TimeScaleTamperExemptions is an exception list for scripts that still need direct Time.timeScale access. Keep this list as small as possible.

Use exemptions only for verified third-party plugins or legacy adapter scripts where direct Time.timeScale access cannot be avoided because of the existing structure.

All other project gameplay code should use OZeroTime.timeScale without exception. Use it for pause, slow motion, cutscene speed control, fast-forward, and any other intentional game-speed changes.

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;

Prevent unintended Watchdog termination during long loading

OZero's native Watchdog checks that Unity's main thread is still running by receiving periodic heartbeat updates. In release builds the heartbeat deadline is about 10 seconds on every platform (after the start-up grace). When the deadline passes, the Watchdog first looks at what the main thread is doing: a thread that is blocked and consuming no CPU (a long synchronous load, a log flush, disk I/O, a virtual machine pausing the thread) is treated as a stall and only logged, while a game that keeps running without sending heartbeats is treated as tampering and terminated according to the configured response policy. A process that stays stalled for more than five minutes is closed as hung.

This can happen during legitimate work such as large scene loading, synchronous asset decompression, shader warmup, or Addressables preparation when the main thread is intentionally blocked for several seconds.

Wrap that trusted loading boundary with OZeroWatchdog.BeginLoadingGrace(maxGraceMs). The grace starts when loading begins and ends immediately when the scope is disposed or End() is called, so you do not need to know the exact loading time in advance.

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);
}

Physics Hack Detector

Injection Detector Settings

Detects programs that get inside the running game: injected native modules, executable private memory, inline hooks, remote-thread style injection, high-risk process handles, and WebGL runtime tampering. Normal overlays and capture tools enter the game the same way, so the detector identifies every module by file hash and signer and lets you decide per module.

An unfamiliar system module does not immediately close the game. It is recorded for review; repeated sightings or a missing embedded signature alone do not trigger a block. Existing allow rules still apply, as do explicit blocks matched by file hash. Configure this option in Unity's Injection settings; it cannot be changed remotely from the Pro portal. Other platforms are unaffected.

How the detector identifies a module

Every few seconds the detector walks the complete list of modules loaded in the game process and compares it with the set it saw at start-up. A new module is identified by its file hash and, on Windows and macOS, by the fingerprint of the certificate that signed it. Rules look at the module itself, never at the folder it was installed from, so a normal program is not flagged because of its install path.

Each check returns one of three answers per detection family: detected, scanned clean, or not due yet. Only real samples move the counters; a check that did not run never resets a previous detection, and a check that could not run at all is reported as a scanner health problem rather than a clean result.

What happens after a confirmed detection. With Force Quit On Detection on (the Standard and Strict presets), a confirmed injected module closes the game after the callback grace period, even if your OZeroSecurityReceiver or callback only logs it; on Windows the native module watchdog closes it directly. To handle injection only in your own code, turn Force Quit On Detection off (the Low preset) and react in your Receiver.

Pro builds. An unsigned module injected into a Pro build also makes the license server reject the next online check (about every 4 minutes). That rejection is a Build Integrity failure and always closes the game, whatever Force Quit On Detection or your callback does. Allow the module from the portal if it is legitimate.

Pro: allow or block observed modules from the portal

With enableServerWhitelist enabled, a Pro build downloads a signed list combining your project's portal decisions with OZero's global decisions. It downloads at startup, polls at the configured interval, and automatically renews approval and rejection lists before they expire.

• The list is bound to your license and signed with the license server key (Ed25519). The SDK verifies it with the same public key it already trusts for activation.
• A verified list is kept on the device and applied on offline starts. A list that fails verification is never accepted, and detection itself is never switched off.
• A device that never connected uses only the baseline trusted list shipped in the build. When a later refresh finds the server, the list is fetched and cached.
• When OZero blocked a module that your project allowed, the portal setting When OZero's verdict and your project's verdict differ decides which one wins (default: OZero). A module your project blocked is always blocked.
• ABI 21 SDKs also report the code-signing subject of Windows and macOS modules (for example Discord Inc.), so the portal can show a company name next to the certificate fingerprint. iOS and Android modules carry no readable signer.
• A module the detector has seen but not yet acted on is sent to the portal's Observed modules list with the source label Seen before any decision, so you can allow or block it before any player is affected. A module whose code-signing certificate chain validated on the device is shown with trusted signature; such modules are never closed automatically by the identity rule — they wait for your decision.

Scanner unavailable (abort code 0x15)

If the native scanner itself cannot run — the configuration could not be applied, native scans keep failing, or the managed and native halves disagree on the contract — the SDK reports ModulationType.InjectionScannerUnavailable (value 10, abort code 0x15, message key injection_scanner_unavailable) and closes the game even when ForceQuitOnDetection is off. This is not an attack detection: a scanner that is silently broken would leave the game unprotected. Show players a support code such as OZ-SEC-15 and keep the abort code in your logs.

PlayerPrefs Encryption

For new keys that need protection, store values with OZeroSafePlayerPrefs instead of Unity PlayerPrefs. The common Get/Set, HasKey, Delete, and Save names are familiar, but encrypted data is not compatible with existing plain PlayerPrefs data.

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", "");

Save File Encryption

To encrypt save files, use OZeroSV_File instead of File.ReadAllText / File.WriteAllText. Files are automatically encrypted on write and decrypted on read. It also checks for tampering upon loading.

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 In-Game Variable Protection (Secure Types)

Secure Types replace regular C# variable types with encrypted types. Values are stored in the Native C++ heap, so memory scanners and memory editors cannot find them even if they scan the memory. Just change the type name, and the rest of the code will work exactly the same.

Example code

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;
}

Supported types

7 Security Event Handling (Optional)

By default, OZero either terminates the app or logs the event according to the configured response policy when a threat is detected. If you need to directly display a warning screen, send a custom server log, or perform save processing right before termination, you can register a callback. The callback passes the OZeroSecurityEvent containing the modulation type, abort code, message key, detailed message, and whether termination is pending.

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.
        }
    }
}

The complete lists for OZeroSecurityEvent, ModulationType, and OZeroAbortCode are documented in the API Reference.

Portal policy callback

Customer Portal policies can be operated in stages. Observe only records evidence, Callback sends a server-issued policy action to the game, and Device Block blocks the selected device on later server verification. Use Callback when you want the game to show a warning, limit matchmaking, request re-login, or route the player to support before using a stronger device block.

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.
        }
    }
}

Next Steps

The core OZero protection features are now running. Please check the API Reference for detailed information on all classes, methods, and configuration options.

Troubleshooting Reference

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.

Resolution Workflow