Get Started

Overview

OZero Security protects Unity games by running security logic in the Native C++ layer, where most hacking tools cannot reach. The SDK provides ready-to-use modules that you enable through a simple dashboard inside the Unity Editor. No manual scene setup or boilerplate code is required to get the core protection running.

1 Import the 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.

In the Import Unity Package dialog that appears, leave all items checked and click Import. All required scripts, native plugins, and editor tools will be added to your project automatically.

2 Open the Dashboard

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

A custom Editor window will open. This is the central control panel for all OZero security modules. You do not need to touch anything in the Project hierarchy — everything is managed here.

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

Inside the Dashboard, you will see a list of available security modules with toggle switches. Enable the modules you want to use. The recommended starting set is shown below.

Security Presets

Choose a preset first, then adjust individual modules only when your project needs a custom policy. For most live games, start with Standard because it balances protection, performance, and false-positive risk.

Turn on the modules you want to use in the dashboard and save the OZeroSecurityConfig asset. When the player starts, the SDK automatically prepares the enabled modules.

License Model — Standard / Plus / Pro

OZero Security ships in three tiers. Standard is fully serverless with the shared native module. Plus stays serverless but adds app-specific Native Variant packages bound by manifest and Bundle ID. Pro includes Plus and unlocks server-side capabilities such as Cloud Telemetry, Signed Time, remote policy, attestation, and per-device limits.

Registering a Plus / Pro License Key

Standard works without any separate license setup. For Plus or Pro, create the OZeroLicenseConfig asset in Unity and enter the license key issued to your project. Plus 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 the 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 in the 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.

Server Activation Flow

Pro licenses are checked automatically when the app starts. This process is designed not to block the game startup flow. If the server is slow or the network is temporarily unavailable, the SDK checks stored activation info first and continues with it when it is still usable.

Boot sequence

1. The SDK automatically initializes the license runtime when the app starts.
2. Standard and Plus do not need runtime server activation, so local protection starts immediately.
3. When optional Pro server features are configured, Pro sends a /v1/activate request in the background to check the current license and device state.
4. If activation succeeds, Pro server features such as telemetry, signed server time, and build attestation become available.
5. If server maintenance, a temporary network error, or a timeout occurs, the SDK uses stored activation info when possible. If no usable stored info exists, or if the license is expired, suspended, or revoked, only the selected Pro server features become unavailable or degraded. Acquired Native Variants and local protection continue unchanged.

Transmitted data

The activation request is a small JSON POST. The basic request includes licenseKey, deviceId, sdkVersion, and platform. When Unity can provide values, appIdentifier, companyName, productName, and webglOrigin are also sent. By default, deviceId uses Unity's device identifier, but you can replace it with an account id or your own UUID source through OZeroLicenseRuntime.DeviceIdProvider.

POST https://api.ozerosecurity.com/v1/activate
Content-Type: application/json

{
  "licenseKey":    "OZ-PRO-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX",
  "deviceId":      "<DeviceIdProvider result; default SystemInfo.deviceUniqueIdentifier>",
  "sdkVersion":    "<OZeroSdkVersion.ManagedVersion>",
  "platform":      "<android | ios | windows | macos | linux | webgl | ...>",
  "appIdentifier": "<Application.identifier>",
  "companyName":   "<Application.companyName>",
  "productName":   "<Application.productName>",
  "webglOrigin":   "<WebGL origin only>"
}

The server returns a signed token, the resolved tier, available capabilities, whether server features are enabled, the token expiry time, and the server-unreachable posture. The SDK verifies the signed token with the configured public key before accepting Pro capabilities.

Graceful degradation

Server maintenance, network timeouts, license expiry, suspension, revocation, and bundle mismatch are not treated as tamper. In those cases, only the selected Pro server features become unavailable or degraded; acquired Native Variants and local protection continue unchanged. Confirmed tamper states such as build mismatch, blocked build, injection, and debugger detection follow the configured threat-response policy.

Offline Behaviour

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 through /v1/activate while online. The SDK encrypts the result and saves it in PlayerPrefs so those selected server features can tolerate a temporary disconnection. This activation 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 stores this block list separately from the activation result.

With the recommended ApplyCachedBlockPolicies mode, a blocked build is still rejected by Build Integrity while the saved block list is valid, even if the player starts the game in airplane mode. After you change block rules in the portal, each device needs one successful online activation to receive the new rules.

Troubleshooting

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 configuring individual security modules, check the Unity Player Settings that affect native plugins, store builds, and platform validation.

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, but Android release builds that enable Minify, ProGuard, or R8 must preserve Unity's Java bridge and any custom Android bridge classes used by your project. This keeps JNI calls for package information, installer source, APK signing certificate checks, and boot asset loading stable 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, remove, or repackage libOZeroSecurity.so. Keep the plugin under Assets/OZeroSDK/Plugins/Android/arm64-v8a and, if you ship 32-bit builds, armeabi-v7a.
• When Build Integrity > Check Platform Native and Android SHA Keys are enabled, test the final signed APK or AAB after Minify/R8. Debug keystore fingerprints and release keystore fingerprints are different.
• If Android logs show JNI lookup failures, installer-source detection failures, or APK signature checks returning empty results only after Minify is enabled, review your custom bridge keep rules first.
• For store releases, build with IL2CPP, release signing, the expected Android SHA-256 fingerprint registered in Android Sha Keys, and a clean launch test on at least one real device.

5 Configure OZeroSecurityConfig

The OZeroSecurityConfig ScriptableObject asset is included when you import the package. Select it in the Project window to inspect and adjust all security module settings. The config is a singleton — access it at runtime via OZeroSecurityConfig.Instance.

General Settings

These top-level fields apply globally across all modules.

Managed Verification UI Management

Pro only. Configure the online revalidation, network retry, and block/exit dialogs used by Build Integrity and Steam DRM. Install Unity UI and TextMeshPro from Package Manager before importing the optional OZero TMP dialog package. On Unity 6, TextMeshPro is included in Unity UI 2.x. Projects that do not use TextMeshPro should use Custom UI / Callback Only.

Global Threat Response

Controls what happens when any security module fires a detection event.

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 Settings

Configures the build integrity validator that detects modified game files, debugger attachment, and suspicious runtime 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.

Generating the key pair

1. In the Unity Editor, select OZeroSecurityConfig in the Project window.
2. In the Inspector, expand the Build Integrity section.
3. Enable the Require Manifest Signature checkbox.
4. Click the Generate Key Pair button.
5. OZero generates an public-key signature key pair. The public key is written directly into OZeroSecurityConfig (stored in your Assets). The private key is saved to:
   [ProjectRoot]/OZeroSigningKeys/manifest_private_key.pem
6. A confirmation dialog shows the private key location. Click OK to dismiss it.

Critical — private key safety

• The private key file is stored outside the Assets/ folder so Unity does not include it in builds. Never move it inside 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 & teams)

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.

Validating an existing key pair

If you are unsure whether the private key on disk still 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 re-generate the key pair

• Private key is lost or compromised.
• Validate Key Pair reports a mismatch (keys are out of sync).
• Deliberately rotating keys as part of a scheduled security policy.

After re-generating, 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

The Generate Key Pair button stores the public key in OZeroSecurityConfig and records a fingerprint for that key in Assets/OZeroSDK/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs. At runtime the SDK checks that the public key in the asset still matches the trusted fingerprint before it accepts a signed manifest.

Two fingerprint slots

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. Note the current fingerprint. Open Assets/OZeroSDK/Scripts/Security/BuildIntegrity/OZeroManifestTrustAnchor.cs and copy the value of ExpectedPublicKeyFingerprintHex into your clipboard or a temporary note.
2. Move it into the previous slot. In the same file, paste the value into PreviousPublicKeyFingerprintHex (which is normally ""). Save.
3. Generate the new key pair. Open Window > OZero Security > Config & Dashboard and 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 slot. Once telemetry confirms the old build is at 0%, set PreviousPublicKeyFingerprintHex = "" and ship one more SDK release. Rotation complete.

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 aborts immediately on launch with reason code 0x0E (TRUST_ANCHOR_MISSING)

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 with "no manifest signing public key is configured" before compilation starts

The PreBuild validator (callbackOrder 51) caught that OZeroSecurityConfig.Integrity.ManifestSigningPublicKey is empty. Fix: open OZeroSecurityConfig in the Inspector → expand Build Integrity → click Generate Key Pair, then rebuild. Note: this check is skipped on Android / iOS (OS-level signing) and on IL2CPP Standalone (no per-DLL files to sign), so a missing key only blocks Mono Standalone targets.

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"

The public key in OZeroSecurityConfig does not match the fingerprint in OZeroManifestTrustAnchor. This usually happens after restoring only part of a key pair or editing generated files manually. 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 build 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 builds work, but CI builds fail with "private key not found" or sign with the wrong key

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

Restricts the game to only run when installed from authorized stores or sources. Useful for preventing sideloaded or repackaged APKs.

Steam Anti-Piracy Settings

Checks Steam launch path, App ID, entitlement state, and release hygiene for PC builds distributed through Steam. Standard performs local validation; stronger ownership verification through Steam server evidence is provided by Pro 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, select 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

Detects time-scale manipulation (speed hacks) by comparing Unity Time.realtimeSinceStartup against native platform timers and optionally a trusted web time source.

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 whether Unity's main thread is still alive by receiving periodic heartbeat updates. In release builds, non-Android platforms use about a 6-second heartbeat deadline, and Android uses about a 10-second deadline after startup grace. If no heartbeat arrives within that window, the app may be treated as stalled and terminated according to the configured response policy.

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 & Hooking Settings

Detects suspicious native modules, executable private memory, inline hooks, remote-thread style injection, high-risk process handles, and WebGL runtime tampering signals.

Encrypt PlayerPrefs

To protect values normally stored in Unity's PlayerPrefs, use OZeroSafePlayerPrefs for new protected keys. The common Get/Set, HasKey, Delete, and Save methods use familiar names, 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", "");

Encrypt Save Files

To encrypt save files, use OZeroSV_File instead of File.ReadAllText / File.WriteAllText. The file is automatically encrypted on write and decrypted on read. Tampering is detected on load.

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 Protect In-Game Variables (Secure Types)

Secure Types replace ordinary C# variable types with encrypted equivalents. Values are stored in the Native C++ heap so tools like Cheat Engine cannot find them by scanning memory. The replacement is a simple name swap — all operators and implicit conversions work the same way.

Example

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 Handle Security Events (Optional)

By default, OZero force-quits the application when it detects a threat (if Force Quit On Detection is enabled). If you prefer to handle threats yourself — for example, to show a warning screen, log the event to your server, or apply in-game penalties — you can register a callback.

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 full list of ModulationType values is 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

You now have the core OZero protection running. Explore the full API Reference to learn about every class, method, and configuration option in detail.