You queue a Premier match. You die through a wall to a man crouched in a shadow on the other side of the map who, by any reasonable account, had no vision on you, no audio cue worth tracking, and no business landing a one-tap through 40cm of digital concrete. You alt-F4, open Reddit, and the answer is what it always is: Premier is cooked, just play FACEIT.

The catch is what FACEIT asks for in return: a kernel-level driver that the next thread down will call a literal rootkit. It sits in the same broad category as Riot’s much-argued-over Vanguard driver, and uncomfortably close to the elevated-privilege ESEA client that quietly mined Bitcoin on subscribers’ GPUs. Post-CrowdStrike, people are also a lot less relaxed about software that can blue-screen millions of Windows machines at once.

So you don’t install it. You queue another Premier match. You die through another wall. Your privacy has been preserved. Your ELO has not. Valve, meanwhile, keeps treating CS cheaters as a vaguely embarrassing PR issue rather than the existential one they actually are.

To be fair, the Valve gripe is the most defensible part of that panic. The rest is more interesting than it looks.

Anti-cheat is one of the strangest arms races in consumer computing. It’s software you install specifically so it can outwit a small army of teenagers with FPGAs and a credit card.

What anti-cheat is actually doing in there

Take FACEIT AC, since it gates every serious CS lobby above matchmaking and has been sitting in your tray for years. FACEIT publicly describes its anti-cheat as three pieces: an app that has to be running during protected CS2 matches, a kernel-mode driver loaded at boot, and a server-side SDK that helps verify the client is present.

A kernel driver, running in Ring 0. Ring 0 is where the operating system kernel lives: privileged access to system memory, devices, and low-level CPU features that normal applications are not supposed to touch. Unfortunately, while Windows can be an entertaining mess, this is the part of Windows where mistakes stop being funny. A driver can register callbacks with Windows so it gets pinged when a process starts, a module loads, or a handle opens. It can scan kernel memory for byte patterns matching known cheats, compare loaded modules with their on-disk versions, and watch for the fingerprints of code injection. If you’ve ever wondered why FACEIT AC and Vanguard want to load at boot, that’s why: they want to be there before anything malicious arrives.

A user-mode app handles updates, backend communication, and telemetry, while server-side verification ties the whole thing to protected matches.

The logic is basically the antivirus model. User-mode code can be lied to by anything with kernel privileges; kernel-mode code can see more, but is dangerous to write and dangerous to deploy. So anti-cheat vendors build small, paranoid kernel components alongside server-side checks, so a cheat has to silence more than one thing at once.

Why it had to go to the kernel

The popular framing is backwards: anti-cheat didn’t go to the kernel because publishers got paranoid. It went there because the cheats went there first, and a defender at Ring 3 can’t reliably see an attacker at Ring 0. That’s a hardware-level fact about how x86 protection rings work.

Over the last decade, cheats have climbed the entire privilege ladder:

User-level memory hacks, still common, but easier to detect.

Custom kernel drivers that hide cheat processes, manipulate page tables, or patch anti-cheat callbacks.

Hypervisor-based cheats that sit underneath the OS and can show kernel anti-cheat a sanitised version of reality.

Direct Memory Access cheats, often FPGA boards plugged into PCIe or tunnelled over Thunderbolt, which read game memory from the bus without running code on the target machine.

DMA is the ugly one. From your CPU’s point of view, a well-built DMA cheat can look like any other device minding its own business. There’s no cheat process to find, no injected DLL to catch, and no suspicious thread to suspend. The anti-cheat is left fingerprinting PCIe topology, checking IOMMU settings, and looking for hardware oddities. Useful clues, sure. Not proof. The anti-cheat is a bit like airport security staring at a weird bag but ultimately waving it through.

So no, the kernel driver isn’t just paranoia. It’s where the fight had to move because the other side had been there for years. It also isn’t enough any more, which is why the industry is drifting towards server-side behavioural detection. We’ll come back to that.

Aside: why anti-cheat often doesn’t run on Linux

Steam Deck owners ran into this quickly: kernel anti-cheat isn’t just “running in the kernel”. It’s running in a specific kernel, usually the Windows one, and using Windows-specific APIs, callbacks, and driver-model conventions that have no clean Linux equivalent.

The bigger problem is trust. On Windows, anti-cheat vendors can lean on a more standardised stack: Secure Boot state, TPM availability, driver signing, and OS-reported security state. Linux, and especially the Steam Deck, is different because the user owns the machine in a much more literal way. They can disable Secure Boot, enrol their own keys, boot another distro, or run a modified kernel. That’s the point of the platform, but it’s a nightmare for anti-cheat. If a userspace client asks the kernel whether the system is trustworthy, the kernel is the thing answering. If the kernel has been modified, it can lie. You’re asking the bouncer to check his own fake ID.

Valve could build a stricter signing chain for SteamOS, but it only works if users can’t opt out, which cuts against the Deck’s pitch as an open, tinkerer-friendly PC. Porting the Windows anti-cheat model isn’t recompiling, but rather, it’s redesigning the product around assumptions Linux doesn’t make.

The upshot on Steam Deck: CS2 runs fine; Easy Anti-Cheat and BattlEye work under Proton but only with per-game opt-in from developers; FACEIT AC and Vanguard don’t run at all, which blocks competitive CS lobbies and the PC versions of Valorant, League, and TFT.

The kernel-driver panic: fair and unfair

When FACEIT moved into the kernel, and again when Vanguard arrived, the public response was predictable: they’re putting a rootkit on my computer; they can spy on everything; this is the end of privacy. For the record, you’re not imagining it. A 2024 ACM paper examining four kernel-level anti-cheat systems concluded that two of them, including FACEIT AC and Vanguard, exhibited rootkit-like behaviour.

Some of that fear is aimed at the wrong target.

“They can read my files, spy on my browser, and see my passwords.” A normal user-mode app running under your Windows account can already access a lot of your user data: many files in your profile, clipboard contents, screenshots, window titles, and input APIs. It doesn’t need Ring 0 to be creepy. It needs Ring 0 for things you, the user, can’t normally do, like reading kernel memory, hiding processes, blocking handles, and watching other privileged code.

If FACEIT or Riot wanted your tax return, the launcher could already have a go. The kernel driver doesn’t unlock magical new spying powers. It unlocks powers that matter for anti-cheat.

“The driver runs at boot, so it’s always watching me.” Always-on drivers are annoying, and asking players to trust one is a big ask. Both FACEIT and Vanguard let you disable the driver from the tray, but you’ll need to reboot before playing again. Still, “always running” isn’t the same as “always uploading”. If the concern is privacy, the non-kernel client was already enough to be creepy. If the concern is performance, persistence, or trust, then yes, that’s a fair complaint.

The nastier risks are more boring, which is usually how security works.

A vulnerable driver can be catastrophic. A bug in a user-mode app is a bad app bug. A bug in a kernel driver is suddenly Windows’ problem, and by extension your problem, and by extension your evening’s problem. If an attacker can talk to that driver and trigger memory corruption, they may get a path straight to Ring 0.

This isn’t theoretical. In 2022, Trend Micro reported ransomware operators abusing mhyprot2.sys, an anti-cheat driver from Genshin Impact, in a “bring your own vulnerable driver” attack. The attackers didn’t need to compromise miHoYo. They brought a legitimately signed, vulnerable driver to machines that had never installed Genshin, used its kernel privileges to kill antivirus, then encrypted the system.

Companies can abuse that foothold. CS players learnt this before Vanguard discourse existed. In 2013, ESEA was caught quietly running a Bitcoin miner inside its client, using the access players had granted it for cheat detection. Around $3,600 was mined from subscribers’ GPUs before anyone noticed; some users reported overheating hardware. ESEA later agreed to a $1 million settlement, though most of that was suspended provided it stayed out of trouble.

That doesn’t make every anti-cheat vendor ESEA. It means the question “could a company use this privileged foothold for something deeply uncool?” has already been answered: yes.

One bad update can ruin a lot of days. July 2024 supplied the demonstration. CrowdStrike pushed a faulty Falcon content update, and Microsoft estimated that roughly 8.5 million Windows machines were affected. Airports stopped, hospitals fell over, and IT departments everywhere aged approximately six years.

CrowdStrike isn’t anti-cheat, but the pattern is adjacent: privileged software pulling vendor-controlled detection content or config updates. FACEIT AC, Vanguard, EAC, and BattlEye all pull new detection data from servers run by humans. That’s the real argument against kernel anti-cheat: not that Tencent is reading your texts, but that a driver bug or bad update can turn a game-security tool into a system-security problem.

Why VACnet might help

Every purely client-side approach is losing ground: DMA and hypervisor cheats can already hide from kernel anti-cheat, and each step deeper increases the blast radius of the next bad driver or bad update for diminishing returns.

Valve’s bet is simpler: stop scanning the player’s computer and start scanning the player’s behaviour. If your telemetry comes back looking like a haunted spreadsheet with a Deagle, the server doesn’t need to know which cheat you bought.

That’s VACnet: Valve’s deep-learning anti-cheat system trained on Counter-Strike gameplay telemetry, historically used to feed suspicious cases into Overwatch review. Valve has publicly discussed aim and view-angle-style behavioural analysis, and in CS2, VAC Live can cancel a match when VAC detects a cheater — though how much of that flow comes from VACnet versus traditional VAC or manual review isn’t public.

If Valve gets it right, the appeal is obvious. VACnet doesn’t care whether the cheat is a DMA card, a hypervisor, a kernel driver, or some external box taped under the desk. If the resulting behaviour looks inhuman across enough data, the server can still flag it. And because it runs on Valve’s side rather than yours, there’s no boot driver, no local attack surface, and no CrowdStrike-shaped risk for players.

The other benefit is speed. Cheap cheat ecosystems struggle if users are banned in their first ranked match, which is why mid-match VAC Live bans matter so much. The risk, obviously, is false positives. A behavioural model that bans an unusually sharp player isn’t a technical footnote; it’s a trust crisis. Nobody wants to be the guy explaining to support that no, honestly, sometimes he just does flick like that. Valve’s caution here — feeding VACnet into Overwatch review before trusting it for automated mid-match bans — is the only way this approach survives.

Still, VACnet feels like the biggest anti-cheat shift since publishers moved into the kernel. The long-term answer to client-side cheats may be to stop fighting them on the client.