Cheat detectors and responses

ACTk detectors continuously monitor your game for suspicious activity and raise callbacks you can use to react—log analytics, notify your backend, or block the player. Each detector can be configured in the editor or started from code.

Common configuration

Add detectors via GameObject > Create Other > Code Stage > Anti-Cheat Toolkit or attach them to existing objects through Component > Code Stage > Anti-Cheat Toolkit. Every detector exposes the same core options:

• Auto Start – automatically begins detection after the scene loads. Disable if you want to control the start timing from code.
• Auto Dispose – destroys the component after a detection event. Leave enabled when you only need a single detection per session.
• Keep Alive – persists through scene loads.
• Detection Event – UnityEvent invoked on detection. Hook this up to your response logic or use the scripting API.

Scripting API

Control detectors programmatically via static methods:

SpeedHackDetector.StartDetection(OnSpeedHackDetected);
// ... handle detection
SpeedHackDetector.StopDetection();

Mix-and-match editor configuration with runtime control.

Warning

Always start detectors from Start() or later lifecycle phases. Starting them in Awake() or OnEnable() can lead to race conditions when Unity initializes subsystems.

Obscured Cheating Detector

Catches tampering with obscured types by validating data and optionally presenting honeypot values while the encrypted payload stays safe.

Settings

• Honey Pot – Enables fake unencrypted fields for attackers to find. Leave enabled to detect casual cheating attempts with easily discoverable fake values, disable if you only care about obfuscation and integrity validation.

• Epsilons – Tolerance thresholds for comparing fake and real values. Increase them if you see false positives with rapidly changing numbers:

  • Double Epsilon – Max allowed difference for ObscuredDouble values
  • Float Epsilon – Max allowed difference for ObscuredFloat values
  • Vector2 Epsilon – Max allowed difference for ObscuredVector2 values
  • Vector3 Epsilon – Max allowed difference for ObscuredVector3 values
  • Quaternion Epsilon – Max allowed difference for ObscuredQuaternion values

Works hand-in-hand with the Obscured types APIs.

Speed Hack Detector

Monitors discrepancies in timings to catch process acceleration / slowdown tools.

Basic Usage

SpeedHackDetector.StartDetection(OnSpeedHackDetected);

Settings

Core Detection Settings

• Interval – Time (in seconds) between detector checks. Lower values provide faster detection but may increase false positives on slower hardware.

• Threshold – Allowed speed multiplier threshold. Default: 0.2. Do not set too low values (e.g., 0 or 0.00*) since there are timer fluctuations on different hardware.

• Max False Positives – Maximum false positives count allowed before registering speed hack. Higher values reduce false positives but delay detection.

• Cool Down – Amount of sequential successful checks before clearing internal false positives counter. Set to 0 to disable. Higher values provide more stability but slower recovery from false positives.

Advanced Settings

• Use DSP – Controls whether to use DSP Timer to catch speed hacks in sandboxed environments (like WebGL, VMs, etc.). Uses AudioSettings.dspTime under the hood, which can catch some extra speed hacks but can potentially cause false positives on some hardware due to high sensitivity. ⚠️ Warning: Use at your peril!

• Watch TimeScale – Controls whether to watch Time.timeScale for unauthorized changes. When enabled, the detector will monitor for unauthorized changes to Time.timeScale. Use SetTimeScale() method to safely change timeScale without triggering false positives. ⚠️ Warning: May cause false positives if you change timeScale directly without using the provided API.

Advanced Features

SpeedHackProofTime APIs

When SpeedHackDetector is running, you can utilize SpeedHackProofTime class to use reliable timers instead of Unity's Time.* timers, which usually suffer from speed hacks. It mirrors most Unity timer properties except the fixed timestep values.

Note

SpeedHackProofTime may not work in some cases, e.g., when there is no legal way to reach reliable timers (may happen in sandboxed processes), it will fallback to usual timers instead.

Safe TimeScale Management

Use SpeedHackDetector.SetTimeScale() instead of directly setting Time.timeScale to avoid false positives. Use AllowAnyTimeScaleFor() for third-party assets that need to change timeScale temporarily.

Configuration Guidelines

• Configure Interval, Max False Positives, and Cool Down to balance responsiveness and noise. For example: interval 1s, max false positives 5, cool down 30s.
• Consider using SpeedHackProofTime for critical timing operations that need to be cheat-proof.

Note

Reliable timers may be unavailable in sandboxed environments such as browser WebGL processes. Provide fallbacks or degrade gracefully.

For detailed examples and API reference, see SpeedHackDetector API documentation.

Time Cheating Detector

Detects changes to the system clock by comparing it to an authoritative online source.

Basic Usage

TimeCheatingDetector.StartDetection(OnTimeCheatingDetected);

Settings

Request Settings

• Request URL – Absolute URL which will return correct Date in response header to the HEAD request. Nearly any popular web server works including google.com, microsoft.com, etc.

• Request Method – Method to use for URL request. Options: Head (preferred, faster), Get (more compatible). Use Head if possible and fall back to Get if server blocks head requests.

• Timeout Seconds – Online time request timeout in seconds. Request will be automatically aborted if server doesn't respond in specified time.

Detection Settings

• Interval – Time (in minutes) between detector checks. Set to 0 to disable automatic time checks and use manual ForceCheck methods.

• Real Cheat Threshold – Threshold for detecting real time cheats (in minutes). If the difference between local and online time exceeds this value, it's considered a real cheat.

• Wrong Time Threshold – Threshold for detecting wrong time (in minutes). If the difference between local and online time exceeds this value but is less than real cheat threshold, it's considered wrong time.

• Ignore Set Correct Time – When enabled, ignores cases where time changes to be in sync with online correct time. Wrong time threshold is still taken into account. Helps reduce false positives when users correct their system time.

Advanced Features

Manual Time Checks

Use ForceCheckAwaitable() and GetOnlineTimeAwaitable() for on-demand validation.

For older Unity versions (pre-2023.1), use ForceCheckEnumerator() or ForceCheckTask() instead.

Custom Server Configuration

Configure custom time servers and thresholds using RequestUrl property or StartDetection() overloads.

Error Handling

Handle different CheckResult and ErrorKind values in your callback to manage network issues and detection results.

Configuration Guidelines

• Use Head request method for better performance, fall back to Get if server blocks head requests
• Set appropriate thresholds based on your game's requirements (e.g., 5 minutes for wrong time, 30 minutes for real cheat)
• Enable Ignore Set Correct Time to reduce false positives when users correct their system time
• Provide fallbacks for offline scenarios or network issues
• Consider using manual checks for critical moments (e.g., before important transactions)

Warning

The detector requires Internet connection and appropriate 'android.permission.INTERNET' permission on Android. It automatically switches to the current domain on WebGL to avoid CORS limitations.

For detailed examples and API reference, see TimeCheatingDetector API documentation.

WallHack Detector

Combats three classes of wall hacks—walking through geometry, seeing through surfaces, and firing through walls.

Basic Usage

WallHackDetector.StartDetection(OnWallHackDetected);

Settings

Detection Modules

• Rigidbody – Check for "walk through the walls" cheats made via Rigidbody hacks. Disable to save resources if not using Rigidbody for characters.

• Character Controller – Check for "walk through the walls" cheats made via Character Controller hacks. Disable to save resources if not using Character Controllers.

• Wireframe – Check for "see through the walls" cheats made via shader or driver hacks (wireframe, color alpha, etc.). Uses specific shader under the hood. Disable to save resources if you don't care about such cheats.

• Raycast – Check for "shoot through the walls" cheats made via Raycast hacks. Disable to save resources if you don't care about such cheats.

Timing Settings

• Wireframe Delay – Delay between Wireframe module checks (1-60 seconds).

• Raycast Delay – Delay between Raycast module checks (1-60 seconds).

Detection Settings

• Spawn Position – World coordinates of the service container. Should be unreachable for your game objects to avoid collisions and false positives. Will have different active objects within 3x3x3 cube during gameplay.

• Max False Positives – Maximum false positives in a row for each detection module before registering a wall hack.

Advanced Features

Module Configuration

Configure specific detection modules based on your game's needs using the detector's properties (CheckRigidbody, CheckController, CheckWireframe, CheckRaycast).

Spawn Position Setup

Configure the service container position using SpawnPosition property to avoid conflicts with your game objects.

Custom Detection Parameters

Start detection with custom parameters using StartDetection() overloads that accept spawn position and max false positives.

Configuration Guidelines

• Place spawn position in an unreachable area (e.g., far coordinates like 1000, 1000, 1000)
• Enable only needed modules to optimize performance (disable unused detection types)
• Adjust delays based on your game's requirements (shorter delays = more detection, higher performance cost)
• Set appropriate max false positives to balance sensitivity and false positive reduction
• Test thoroughly as the detector creates service objects in your scene

Caution

The detector creates service objects within a 3x3x3 cube at the spawn position. Make sure this area is completely empty and unreachable by your game objects to avoid false positives.

Debug Symbol

• ACTK_WALLHACK_DEBUG – Enables detailed debug logging to keep service renderers visible and provides additional detection details

Wireframe module shader setup

The Wireframe module uses Hidden/ACTk/WallHackTexture shader under the hood. This shader must be included in your build to exist at runtime. You'll see an error in logs at runtime if the shader is missing, and you'll be prompted in the Editor to include it when you run WallHackDetector without the shader.

You can easily add or remove the shader via the ACTk Settings window. Press the "Auto include" button to automatically add the Hidden/ACTk/WallHackTexture shader to the Always Included Shaders list.

Alternatively, you may press the "Include manually" button to open Graphics Settings for your project and add the shader to the Always Included Shaders list manually.

To manually add the shader to the Always Included Shaders list at the Graphics Settings:

1. Expand Always Included Shaders
2. Add one more element to the list
3. Click on the bulb next to the new element
4. Search for "wallhack" in the opened window and select the WallHackTexture with double-click

That's it for the wireframe module setup.

WallHack Detector and IL2CPP builds

IL2CPP builds enable aggressive code stripping that can remove helper components the WallHack Detector relies on. Open Tools > Code Stage > Anti-Cheat Toolkit > Settings, locate the WallHack Detector section, and press Enable automatic link.xml generation so the required components are kept in your IL2CPP builds automatically.

Tip

• Wall hack cheats mostly target desktop first-person games. Disable unused modules to keep resource usage in check on other platforms.
• The detector registers its service objects on the Ignore Raycast layer and keeps renderers disabled so they stay invisible during gameplay.
• Spawn the service cube in an empty space away from level geometry and physics objects because the detector instantiates and moves helpers while it runs.

For detailed examples and API reference, see WallHackDetector API documentation.

Injection Detector

Protects Mono builds by monitoring loaded assemblies and comparing them to an expected whitelist.

Basic Usage

InjectionDetector.StartDetection(OnInjectionDetected);

Settings

• Injection Detection Support – Must be enabled in ACTk Settings to add mono injection detection support to builds. Has no effect for IL2CPP or unsupported platforms.

• Custom Whitelist – Fill any external assemblies which are not included into the project to the user-defined whitelist to make Injection Detector aware of them.

Platform Compatibility

• Supported Platforms: Standalone and Android builds only
• IL2CPP: Not available on IL2CPP-only platforms (Mono injections are not possible in IL2CPP)
• WebGL: Not supported due to platform limitations

Note

Detection Scope: This detector only detects managed assembly injections (Mono/.NET assemblies). Native (unmanaged) code injections are still possible and not covered by this detector. Native injections operate at a lower level (binary/DLL injections) and require additional protection mechanisms like native code obfuscation or anti-tampering solutions.

Advanced Features

Platform Support Check

Always check platform compatibility before starting detection using InjectionDetector.IsSupported.

Detailed Detection Callback

Use the detailed callback to get information about the injected assembly. The callback provides the name of the injected assembly for analysis.

Whitelist management

The Injection Detector automatically adds assemblies that ship with your project to the whitelist during build. When you load assemblies from external sources or generate them at runtime, register them manually to prevent false positives.

Why the whitelist is needed:

• External libraries: Third-party DLLs loaded from outside the project
• Runtime-generated assemblies: Assemblies created dynamically at runtime
• Plugin systems: Assemblies loaded by plugin architectures
• Modding support: User-created assemblies loaded by mod systems

Use the whitelist editor to keep those assemblies on the safe list.

1. Open Tools > Code Stage > Anti-Cheat Toolkit > Injection Detector Whitelist Editor or press Edit Whitelist in the settings window.
2. Add assemblies with Add Assembly, Add Assemblies from folder, or Add Assembly manually depending on how you distribute plugins.
3. Remove entries with the - button or clear the list to rebuild it from scratch.

The whitelist is stored in ProjectSettings/ACTkSettings.asset, so share that file with your team to keep settings in sync.

Note

Enable ACTK_INJECTION_DEBUG when you need the detector to print the full name of a suspicious assembly and add it to the whitelist manually.

Configuration Guidelines

• Enable injection detection in ACTk Settings before building
• Add external assemblies to the whitelist to prevent false positives
• Test on target platforms before releasing (Standalone and Android only)
• Check platform support before starting detection to avoid runtime errors

Tip

This detector is disabled in the Editor by default due to specific assemblies causing false positives. Use ACTK_INJECTION_DEBUG symbol to force it in the Editor for testing.

Debug Symbols

The following conditional compilation symbols are available for debugging and development:

• ACTK_INJECTION_DEBUG – Enables basic debug logging and forces detection in the Editor for testing
• ACTK_INJECTION_DEBUG_VERBOSE – Provides additional detailed debug information for troubleshooting
• ACTK_INJECTION_DEBUG_PARANOID – Enables the most comprehensive debug logging for in-depth analysis

For detailed examples and API reference, see InjectionDetector API documentation.

Debug and Development

ACTk provides several conditional compilation symbols to aid in debugging and development. Enable these symbols in ACTk Settings (Tools > Code Stage > Anti-Cheat Toolkit > Settings).

Note

All debug symbols work only in development builds and the Editor.

Global Debug Symbols

ACTK_DETECTION_BACKLOGS

Enables detailed detection logging for all detectors. This symbol:

• Prints detection details to the console even when detectors are not running
• Helps identify false positives and troubleshoot detection issues
• Provides comprehensive logging including detection thresholds, counters, and timing information

Detector-Specific Debug Symbols

Individual detectors have their own debug symbols documented in their respective sections.

Handling detections

• Detectors stop themselves after firing when Auto Dispose is enabled. If you prefer continuous monitoring, disable Auto Dispose and restart the detector manually.
• Centralize cheat handling in a dedicated manager that can mute in-game input, display UI, and report analytics events.
• Combine detector output with CodeHashGenerator results and backend heuristics to minimize false positives before banning players.

Example implementations

• Basic detector usage: See DetectorsExamples.cs in Examples/API Examples/Scripts/Runtime/UsageExamples/
• DOTS integration: See AntiCheatHost.cs in Examples/DOTS ECS Examples/Scripts/MonoBehaviors/