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.

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.

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.

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.

Simply turn on the modules you want to use in the dashboard and save the OZeroSecurityConfig asset. The SDK will automatically prepare the activated modules when the player starts.

License Model — Standard / Pro

Standard provides local protection without server integration. Pro combines project-specific native binaries (Native Variants) and manifest binding with telemetry, signed server time, remote security settings, attestation, and server verification.

Registering a Pro License Key

Standard works without separate license setup. For Pro, create the OZeroLicenseConfig asset in Unity and enter the project license key. It binds the dedicated Native Variant and enables runtime activation and server features.

1. Create Config Asset

Open Window → OZero Security → Config & Dashboard. In the License & Server section, click Create OZeroLicenseConfig. The button creates the asset in the correct Resources/ folder, so you do not need to create folders or move the asset manually.

2. Fill Inspector Fields

3. Build & Verify

You do not need to add extra code. When the app starts, the SDK automatically reads the OZeroLicenseConfig asset. 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 the asset location and name first. The asset must be under a Resources/ folder and must be named exactly OZeroLicenseConfig.

Offline Behavior

The short version: losing the network does not stop the game or local protection. Standard does not use the server at all. Pro keeps the same offline local protection, while explicitly selected server features can use saved activation information for a limited time.

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.

tokenTtlSeconds is the lifetime of that saved server-feature result. The default is 604800 seconds, or 7 days. After it expires offline, only server-dependent features such as telemetry upload and signed-time verification stay unavailable until the next successful activation. The game, acquired Native Variant, and local detectors continue unchanged; the SDK does not silently switch the product tier to Standard.

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 in OZeroLicenseConfig.offlineProPolicyMode from the License & Server section of the Config Dashboard. 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 security and size settings for release builds

When you publish the final release build, OZero recommends the following Unity settings to strengthen the build and reduce app size.

Security hardening (IL2CPP): On Android, iOS, and other Unity-supported targets, set the scripting backend to IL2CPP. IL2CPP does not make reverse engineering impossible, but it reduces direct C# metadata exposure and helps OZero security checks run on a stronger release baseline. Path: Project Settings > Player > Other Settings > Scripting Backend

Size optimization (Managed Stripping): Managed Stripping removes unused managed code to reduce app size. If too much code is stripped at once, the app may fail at runtime, so start with Low or Medium.

Important: After changing these settings, test scene transitions, save/load behavior, Addressables, and external SDKs such as payments or ads on a real device before increasing the stripping level.

Android ProGuard / R8 Settings

OZero Security does not require a separate Java SDK package. However, if Minify, ProGuard, or R8 is enabled in an Android release build, you must preserve the Unity Java bridge and custom Android bridge classes used in your project. This ensures that JNI calls required for package information, install source, APK signature certificate checking, and boot asset loading operate stably even after obfuscation.

# 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/OZeroSDK/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.
• If you see JNI lookup failures, install source detection failures, or empty APK signature check results in the Android log only after turning on Minify, check your custom bridge keep rules first.
• Validate store deployment builds based on IL2CPP, release signing, the expected Android SHA-256 fingerprints registered in Android Sha Keys, and clean execution tests on at least one actual device.

5 OZeroSecurityConfig Settings

The OZeroSecurityConfig ScriptableObject asset is included when the package is imported. Select it in the Project window to review and adjust all security module settings. It can be accessed at runtime via OZeroSecurityConfig.Instance.

Common Settings

Top-level settings shared by all security modules. Defaults in this table use the serialized values defined in code.

Managed UI (All licenses)

Security Termination Notice, the shared dialog prefab, and localization are available in Standard / 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.

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.

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 OZeroSecurityConfig 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 in the Inspector.
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 OZeroSecurityConfig, and the private key is saved to this default path:
   [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 OZeroSecurityConfig, click Validate Key Pair. OZero derives the public key from the PEM and compares it with the config. 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 OZeroSecurityConfig, and a fingerprint for that key is recorded in Assets/OZeroSDK/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs. At runtime, the SDK first checks that the public key in the asset 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 OZeroSecurityConfig, 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/OZeroSDK/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 OZeroSecurityConfig, 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 OZeroSecurityConfig.Integrity.ManifestSigningPublicKey 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 OZeroSecurityConfig 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 Settings

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

Steam Anti-Piracy 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.

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.

Reset Token support flow

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 OZeroDeviceBindingDetector.Instance?.ClearStoredFingerprint(token.Trim()).
5. After the SDK accepts the token, restart the app or run the protected startup flow again. The current device fingerprint will be registered again.

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.

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.

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.

Pro: allow or block observed modules from the portal

With enableServerWhitelist on, a Pro build downloads one signed decision list at start-up and again at every serverWhitelistRefreshInterval. The list merges the decisions your team makes in the customer portal (Injection → Detection status → Observed modules) with OZero's own verdicts drawn from data across all customers.

• 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, meaning tools like Cheat Engine 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