How anti-cheat detection actually works — and what a provider can genuinely do about it

Every cheat provider on the internet claims to be undetected. Most of them cannot tell you what that means, which is a reasonable proxy for whether it is true.

This is an honest explanation of the four detection layers modern anti-cheat uses, what each one can and cannot catch, and — importantly — which of them no provider can promise to defeat.

Layer 1: Signature scanning

The oldest and simplest technique. The anti-cheat maintains a database of byte patterns known to belong to cheat software, and scans process memory for them.

What it catches: publicly distributed cheats, and any provider who ships the same binary to every customer.

What defeats it: per-user build signing with randomised code layout. Every splatvik loader download is compiled with a different instruction ordering and different constant encoding, so there is no stable byte pattern to add to a database. A signature derived from one customer's build matches nobody else's.

This layer is genuinely solvable, and any provider who gets caught by it is not doing the work.

Layer 2: Module and handle enumeration

The anti-cheat walks the list of loaded modules in the game process and the list of open handles to it. An injected DLL appears in the module list. A cheat process with an open handle to the game appears in the handle list.

What it catches: anything using standard DLL injection or a naive external reader.

What defeats it: manual mapping — allocating memory and writing the executable image yourself rather than asking Windows to load it, so no module entry is ever created. For handle access, the read path goes through a driver rather than an open user-mode handle.

Also solvable, and again a provider caught by this layer is not doing the work.

Layer 3: Kernel callbacks and integrity checks

This is where it gets serious. Both EAC and BattlEye load a kernel driver. From kernel mode they can:

• Register process and thread creation callbacks to see everything that starts
• Register image load callbacks to see every driver that loads
• Periodically hash the game's own code sections and compare against a known-good copy
• Walk kernel structures looking for hooks and unlinked objects
• Detect the presence of a debugger or a hypervisor

What it catches: any cheat that patches game code, hooks the render chain in an obvious way, or loads a driver that does not look legitimate.

What defeats it, partially: never writing to game memory at all. splatvik reads. The only output is an input event, produced through the same path a mouse produces one. There is nothing patched to detect.

Driver load is the harder problem. It is why Secure Boot has to be off — Windows will not load an unsigned driver otherwise — and it is why our driver's presence is minimised in time rather than resident.

I want to be precise here: this layer is mitigated, not defeated. A sufficiently determined kernel scan can find things. What we control is how much surface there is to find and how long it exists.

Layer 4: Server-side behavioural telemetry

The layer nobody talks about honestly.

The game server receives your inputs and your position, hundreds of times a second, for every match you play. That is a very rich dataset. Modern anti-cheat systems run statistical analysis over it looking for:

• Aim snap velocity distributions that do not match human motor control
• Reaction times below human physiological limits (roughly 150ms)
• Accuracy that stays flat as target angular velocity increases (humans get worse; aimbots do not)
• Pre-aiming through geometry — turning towards a target before line of sight exists
• Consistency that is too high across a long sample

What it catches: everything, eventually, if you play badly enough.

What defeats it: nothing technical. Not signature randomisation, not manual mapping, not a kernel driver. There is no software solution to a system that is analysing what you actually did.

The only defence is configuration and behaviour, which is why every one of our product guides spends as much time on FOV limits and smoothing curves as on feature lists. It is not filler. A 30-degree FOV with 1.0 smoothing produces an aim trace that no amount of technical hardening will hide.

What "undetected" actually means

It means: as of right now, running this build does not trigger detection.

It does not mean: this build will never be detected. Anti-cheat vendors ship new heuristics on their own schedule and do not announce them. Anyone claiming permanent safety is selling something.

What a serious provider owes you instead is:

1. Honest current status, visible before you pay.
2. A fast response when that status changes.
3. A hard block so you cannot run a build during a risk window.
4. Compensation for the downtime.

Our status page is written directly from our development channel — when a developer posts a status change in Discord, the site updates within seconds. There is no marketing layer between what we know and what you see. When status flips to Updating, the loader stops injecting whether you like it or not, and your subscription is credited for every day of downtime automatically.

That is the whole model, and it is why we built the Discord integration rather than editing a status page by hand.

The realistic risk assessment

Being honest about the numbers, in rough order of how people actually get banned:

1. Behavioural reports leading to manual review — by a wide margin the most common.
2. Server-side telemetry flags — increasingly common, and configuration-dependent.
3. Running a build during an update window — which is why the loader blocks it.
4. Kernel-level detection of the cheat itself — the rarest, and the one we spend the most effort on.

Note that three of those four are substantially within your control. Configure conservatively, do not run stale builds, and do not play like a highlight reel.

What we do on our side

• Per-user build signing with randomised code layout
• Manual mapping — no module footprint
• Read-only memory access; no game code is ever patched
• Input-level aim application rather than memory writes
• Time-minimised driver residency
• Automated detection monitoring across a test fleet
• Status pushed from the dev channel to the site in real time
• Hard injection block during any non-undetected status

What you do on your side

• Keep FOV under 10 degrees
• Keep smoothing above 4
• Leave visibility checks on
• Turn variance up on anything that automates a timing input
• Do not stream aura-based ESP
• Do not be the most obviously good player in every lobby

Do both halves and the risk is genuinely low. Do only ours and it is not.

Want to see the system in practice? The status page shows live detection state for every build, and the changelog shows every update we have shipped.