BEVAN
Resume

Kernel-level anti-cheats: a necessary devil

July 29, 2024

Cheating is an increasingly endemic problem to multiplayer video games on PCs, and as a response, we’ve seen the “Cambrian explosion” of anti-cheats designed to combat this situation.

However, a vast majority of these products are choosing to run with the highest privileges possible on your system: the kernel-level. This choice has caused a lot of scrutiny from customers over the possible ramifications of this decision on their usage of their computer: particularly, over the privacy, security and stability of their PCs.

Unfortunately, this discussion is messy, and has a lot of misinformation. This is an attempt to face this issue, from the perspective of a customer evaluating the option of installing these pieces of software.

The lay of the land

A brief primer on what “kernel-level” means:

(There are multiple levels “rings” in the middle, but we’re not going to go too in-depth here.)

There are a lot of anti-cheat tools available right now. From generic technology providers, to bespoke solutions developed by studios, this table attempts to give an outline of the more known providers:

Name Developer Kernel-level? Generic provider Examples of games using it
Vanguard Riot Games Yes No VALORANT, League of Legends
BattleEye BattleEye Yes Yes Fortnite, Escape From Tarkov
Easy Anti-Cheat Epic Games Yes Yes Fortnite, Apex Legends
RICOCHET Activision Blizzard Yes No Call of Duty Modern Warfare II (2022)
EA Anticheat Electronic Arts Yes No Battlefield 5, EA FC 24
EQU8 1047 Games Yes No 1 Splitgate
FACEIT AC FACEIT Yes Third-party Counter-Strike (FACEIT)
EMAC LAB EMAC Yes Third-party Counter-Strike (GamersClub)
Akros Akros Yes Third-party Counter-Strike (ChallengerMode)
ESPORTAL AC2 ESPORTAL Yes Third-party Counter-Strike (ESPORTAL)
XIGNCODE3 Wellbia Yes Yes Black Desert
PunkBuster PunkBuster Yes Yes Call of Duty 4: Modern Warfare, Battlefield 4
GameGuard nProtect Yes Yes Helldivers 2
Denuvo AC Denuvo Yes Yes (Formerly DOOM Eternal)
Valve Anti-Cheat (VAC) Valve Corporation No Yes Counter-Strike, generic Steam titles
Warden Activision Blizzard No No World of Warcraft
Defense Matrix Activision Blizzard No No Overwatch 2
Arbiter 343 Technologies No No Halo Infinite
TenProtect Tencent Yes No Rings of Elysium
mhyprot2 miHoYo Yes No Genshin Impact
Anti-Cheat Expert Tencent Yes (Probably) Yes League of Legends (China)
FairFight i3d (formerly Gamebloks) No (server-side only) Yes Battlefield 4
mail.ru AntiCheat Service mail.ru Yes Yes Conqueror’s Blade

The privacy impact is minimal

A major focus of the kernel-level AC debate is the idea that escalating to the kernel would allow surreptitious extraction of user data, and with the ownership of some of these companies, potentially leave you vulnerable to manipulation, harm, and other ill wills.

Strictly speaking, this is true.

But… it’s also true if you just install the game, without installing anything in the kernel.

Without a kernel-level driver, or even administrative rights, software on your computer can:

This is unfortunately the nature of modern desktop operating systems: there are no safeguards to prevent applications without administrator access from reading data accessible to non-administrators. Mobile operating systems are designed differently, to prevent one app from reading anything other than the relevant data for the application to work.

With a kernel-level driver, you gain these additional abilities,

That is not a lot gained.

If you do not trust the publisher of a game to protect the privacy of your computer, you should not install their software, full stop. Drawing the line at a kernel-level driver is arbitrary, and naïve.

However, if your beef is only about data privacy at Riot, running the game client or running Vanguard makes not one bit of difference. Data can still be retrieved from user-mode, and we’re all engineers for the same studio with the same goals, none of which are collecting your personal information. If Riot hasn’t earned your trust, do not run our software.

/dev: Vanguard x LoL

The ability for kernel-level vendors to do mass data surveillance is also neutered by the fact that they know they are under constant vigilance by opponents: cheat developers. Cheat developers are constantly evaluating the state of kernel-level ACs, and are pouncing at the bit to discredit them to consumers, because it increases the likelihood for it to be removed.

When cheat developers revealed that VAC was reading the DNS cache of systems (basically, seeing what websites your computer had visited), there was a mass outcry, forcing Gabe Newell to make a statement on reddit, clarifying the details around such a check.

There is also a social engineering side to cheating, which is to attack people’s trust in the system. If “Valve is evil - look they are tracking all of the websites you visit” is an idea that gets traction, then that is to the benefit of cheaters and cheat creators. VAC is inherently a scary looking piece of software, because it is trying to be obscure, it is going after code that is trying to attack it, and it is sneaky. For most cheat developers, social engineering might be a cheaper way to attack the system than continuing the code arms race, which means that there will be more Reddit posts trying to cast VAC in a sinister light.

Gabe Newell, Valve, VAC, and trust : r/gaming

Security

As mentioned prior, there can be security-related issues.

One potential risk is a supply chain attack. The concept is that someone could hack the vendor of an anti-cheat, and utilise that access to send out malicious software to customers. It’s hard to quantify the real risk behind this prospect. This could happen to any piece of software on your machine, including the operating system you run, or common applications you use on a day-to-day basis. As discussed earlier, being the kernel does not give you substantially higher access to a machine.

The other risk is the ability for a kernel-level driver to allow arbitrary applications to elevate themselves. This could be used by a piece of malware to elevate themselves to the kernel, and disable anti-virus solutions (which, as mentioned earlier, has already happened).

There is a responsibility for game developers to design these tools with security as a core focus, beyond what is applicable to user-mode software. Whether game developers are up to the task is going to be something we’re evaluating for a long time.

That being said, user-mode security is important, too. And game developers have had failures here for far longer.

A brief section about attacks done with user-mode game software

In 2014, a worm spread through Garry’s Mod. Known as the Cough Virus, servers would infect users, who would have their Steam name changed, spam their friends and servers with a “cough” message, and attempt to hack other servers.

In 2015, reddit user bsadams joined a Counter-Strike: Source server. The server exploited a Source engine exploit to gain remote-code execution (RCE) privileges on his computer. Using those privileges, they proceeded to steal his Steam, ESEA and CEVO accounts, stole his skins, and used his account to cheat. He only re-gained access due posting his story publicly.

In 2023, Call of Duty: Modern Warfare 2 (2009) had to be taken down because an attacker was abusing an RCE exploit in the game (one of many) to propagate a worm. The exploit was reported to Activision in 2018.

In 2024, the Apex Legends Global Series was put on hold after multiple professional players were hacked live on air with an RCE vulnerability, and forced to play with cheats (contrary to some initial hypotheses, this had nothing to do with the kernel-level anti-cheat: it was a usermode vulnerability).

In April 2021, researchers revealed that multiple RCE exploits were present in CS:GO, and remained unpatched despite having been reported to Valve months and years ago.

To me, this is the real worry when we talk about security within video games. Game developers have a litany of failures to look back on, and there are countless examples of big names being lax.

Stability

The July 2024 Crowdstrike incident shows just how wrong writing software in the kernel-level can go.

To summarise the technical aspect: Crowdstrike delivered a bad upgrade to data used by their kernel-level driver, which revealed a bug. This bug caused machines to enter into a bootloop, which it could never5 recover from without intervention. Resolving it required booting into safe mode, and manually deleting the driver update file.

Incidents like that should never happen. Users should never have to boot into safe mode.

This is not a problem if the driver does not start at boot. If a crash is caused by the user opening a piece of software, they can avoid the crash by not opening that piece of software, and the developer can put out a fix without much issue.

But some anti-cheat vendors do start at boot. The most infamous is Vanguard. Now that they have chosen to do this, they must be aware of the great responsibility placed upon them.

I have not minced words about how game developers have failed at securing their user-mode software. One only hopes that they take the stability of their kernel-level software more seriously.

An early version of Vanguard disabled vulnerable (i.e. usable to cheat, or exploit your system) device drivers. However, these device drivers powered peripherals, leading to users finding out that features such as keyboard RGB, or game monitoring, suddenly became unusable. This didn’t permanently brick any computers, but was an early warning of the risks.

(While there are some reports around Vanguard bricking computers, they mostly appear to be inaccurate: see the post-script for further commentary about this).

Where do we go from here?

As much as kernel-level anti-cheat software might not be the devil it is portrayed to be, it is an expensive, and ultimately risky piece of software for game companies to develop and maintain. And given the requirement for these solutions to be game specific, practically every game developer on the planet is now creating new software to be installed at the kernel level. Some even install multiple, and randomize which one you use.

This state of affairs is not sustainable, not by a long shot. Trust in these solutions is already low, and any vendor messing up risks permanent damage on the entire industry. Worse, developers are unlikely to want to keep pouring money forever into this state of affairs.

To me (and I must stress: I am not within the anti-cheating space), we are doomed to have one, or a mix of the possible futures:

The third option seems likeliest, with an outside chance of it happening alongside option 4. Kernel-level anti-cheat providers are already enforcing similar requirements for usage of their software, and it makes sense that Microsoft will step it to streamline this process. For users, from a “reduce the amount of crap on the system” perspective, this is the best hope.

Hopefully one day soon, the platforms our games run on will offer developers the security features required to prevent cheating without necessitating extracurricular software.

/dev: Vanguard x LoL

There is already some optimism here: Microsoft have begun conversations with security partners (who are the biggest hindrance to removing user code from the kernel) about moving code out of the kernel, and along with security features like VBS Enclaves, present a pathway out.

It is a sad state of things where developers must invest so much effort into providing a playable multiplayer experience. But we cannot do much but live with the state of things, as they are.

Further reading

Post-script

What about Linux and Mac?

As sad as it is, the userbase is not significantly high enough for companies to invest into these platforms (yes, this is a chicken and egg problem). It is likely the cost for developing on Windows alone is exorbitantly high. The lay of the land will continue until developers have sufficient reason to change what they’re doing.

The other problem is the inherent difficulty of protecting Linux.

It’s the same thing when we’re talking about why we can’t support Linux. The distributions have become bespoke and so freely customizable, we have no real viable way to attest to the security of its kernel. The whole operating system itself could be the cheat. (2/4)

Phillip Koskinas, head of Riot Vanguard

The reports around Vanguard bricking computers appear to inaccurate, as of writing

Riot have denied them, and the symptoms do not appear consistent with a kernel-level driver failure (as we have so aptly seen with Crowdstrike).

What appears to have happened is the following:

To call this Riot’s fault is a bit much, and takes away agency from the people using the computer. Riot did not automatically turn them on.

Riot are allowed to require those features.

This may have been a lapse in user communication, and Riot should attempt to document this in a clearer fashion to avoid users falling into this trap.

There is a potential issue with Vanguard improperly interfering with WiFi drivers, based on user reporting. While this does not brick computers, it does prevent normal operating.

Let’s bring back server communities of old

A common retort is that we should abandon modern matchmaking solutions, and instead rely upon people to operate servers, who can then manually ban cheaters.

While I agree that all modern titles should offer options for users to host their own servers, I do not believe this to be a viable defence strategy.

For one, server admins (and other players) are not fantastic judges of whether people are cheating. Take this 2009 clip of 3kliksphilip being banned from a CSS server for… well, to be blunt, incredibly mediocre gameplay by modern standards. This is during the heyday of community servers, so I do not find it convincing that things would be better today.

Quite frankly, I was that server admin at points. So, from experience, I understand how problematic making decisions on players is. Unless the cheater is obvious, leaving judgements to other humans leads to problems.

High-level cheaters present an even more impossible challenge. When you know how to disguise your cheating effectively, or limit your cheating to information only, you become extremely difficult to ban.

Sue them all to death?

Game developers do occasionally take legal action against cheat developers. Could they scale this up to fight them?

Alas, this is hardly sustainable. For one, lawsuits are expensive, and it is unclear whether game developers will ever recoup the money. They’re slow, meaning competitors will have ample time to step in, and users plenty of opportunity to transition.

The biggest problem, like with ransomware operators, is that many operate outside of areas where game developers can enact legal action. It’s basically worthless to try and fight anyone based out of Russia.

Hardware cheats make this all moot, no?

Cheats have escalated to the point where they are components, installable into your computer, that read the memory of your computer to get you your cheats. But both FACEIT, and Vanguard claim the ability to detect them. So, already, hardware cheats are not impervious to anti-cheat providers.

But critically: forcing cheats to run within this environment increases the barrier for users to cheat. You need to purchase a hardware component, and tamper with your PC to install it. This raises the costs, and the effort required, and forces users away from this.

Server-side measures

A logical solution to reduce the efficacy of information cheats is to reduce the amount of information sent to game clients. For instance, you only need to send the location of an enemy player right as you are about to see him.

The reality is that this is a rather old idea, and has been implemented by many games: see Riot’s article for their VALORANT implementation. CS:GO implemented this same idea in 2015, although a cursory glance seems to reveal that this stopped working with the release of CS2. Examples of the community anti-cheat SMAC implementing it can be seen as far back as 2012 (although SMAC’s implementation/FACEIT’s config of SMAC was too aggressive, leading to pop-in scenarios when peeking corners).

Does it work? Yes? Does it solve the problem entirely? No, dear god, no.

Beyond that, most game developers have already elected not to trust the client for information, which prevents clients from saying “I have infinite health”, and the server going “OK, that seems legitimate”. Of course, in peer-to-peer titles where a user is the server, you can bypass that by forcibly making yourself the host, and then you are the server validating this information - hence why, after a period of P2P titles, games have reverted to servers hosted by the developer.

AI anti-cheat?

In the spirit of moving things away from the client, some technology providers are exploring using artificial intelligence to automatically detect cheats from user behaviour.

Valve are the most famous example, deploying a solution called “VACNet” to detect suspicious behaviour, and sending them to the manual review service “Overwatch”, for players to judge.

Whether or not this is working is difficult to tell. For one, after the launch of CS2, Valve appears to have temporarily disabled the solution when it was accidentally banning players for spinning their mouse too fast. It appears to have been brought back online since.

It also does not ban informational cheats (i.e. wallhacks, ESPs, radar hacks).

Riot seem skeptical of the efficacy of AI anti-cheats for detecting aimbots.

And even solely for aimbots, recall just isn’t that great. The best models can only identify around 30-50% of cheats on server-sided player input alone, and this is not sufficient for a free competitive game with literally no barriers to reentry. Worse, aimbot developers have already started offering “humanization” features to prevent player reports, and while they’re still mostly goofy pseudo-random noise generators, at some point, a particularly enterprising young cheater will spend the weekend training a model to “move the mouse like it’s a real boy.”

/dev: Vanguard x LoL

AI behaviour grouping?

Valve also have another ace up their sleeves. Using AI, they attempt to rank Steam accounts by the likelihood of them cheating. Data points such as their interactions on Steam, behaviour within the game, and whether they are running CS2 in “Trusted Mode”, inform an AI classifier to group you. You are then only matchmaked with players within the same group.

Within CS:GO, I would rate this system as having worked for me. Within CS2, the system was not working for me, or my trust ranking unexpectedly dropped (very little transparency to the user on this).

Critically, it’s difficult to evaluate the system, because it will be different for each user. How will the experience be for a new, but legitimate user? There won’t be many data points for them, so will it automatically put them in the low trust tier, forcing them to play with cheaters? At least one user has reported this as an issue.

Wait, how many third-party anti-cheats exist for CS?

As you may have seen in the table, there are at least 4 different providers for external anti-cheats for Counter-Strike. Easy Anti-Cheat used to provide esport services for Counter-Strike too.

ESL had an anti-cheat, but shut it down in 2021. For all intents and purposes, the anti-cheat was dead in 2015, when ESL acquired ESEA, who had a more renowned anti-cheat. ESEA’s anti-cheat would too be subsumed when ESL merged with FACEIT.

CEVO, a now defunct competitor to ESEA/FACEIT, had their own anti-cheat.

To put it simply, the community has universally decided that the default anti-cheat solution provided with Counter-Strike is not sufficient enough for high-level gameplay (and especially tournament gameplay), and as such has created an entire ecosystem of competitors to try and defend the game.

The most damning confirmation of the above claim is that qualifiers for Valve events have to be ran with a proprietary, third-party anti-cheat. A cause of controversy during the qualifiers for the PGL Copenhagen Major 2024 was that the third-party AC, Akros, was not good enough. The vendor, for their part, responded in a now deleted Twitter post, claiming cheating is out of control.

Game developers would love to not make kernel-level anti cheats

A general point: making kernel-level anti-cheats is an absolutely insane proposition for a company to take on, without there being the need to do so.

I do not see why a company would willingly take this on, without feeling that their products are genuinely at risk without a capable anti-cheat.

Footnotes

  1. Used to be a generic technology provider, but was acquired by 1047 Games for exclusive use in first-party titles. ↩︎

  2. During the writing of this piece, ESPORTAL declared bankruptcy. ↩︎

  3. Banks (at least within the UK) are typically wise to these sorts of attacks: session times are extremely short, and transactions likely require confirmation on your phone, with some form of verification. Some UK challenger banks don’t even provide websites. The end result is that stealing your bank session, while bad, is not catastrophic. ↩︎

  4. Caveat: more and more websites require confirmation for card purchases, on a second-factor. ↩︎

  5. Never is not strictly true: it was reported that roughly 15 reboots of a computer could resolve the issue. Each reboot would download a little bit more of the update to solve the issue (I think). ↩︎

  6. There are no active exploits for the latest version of game consoles, and the few hardware exploits, such as XIM, are expensive, and a far smaller attack surface to detect. ↩︎

security video games