Why do video games use kernel-mode anti-cheats?

I've seen this argument pop up so many times it's astonishing. I believe there is an irrational fear of kernel-mode components because people do not possess a sufficient education level in information security, information technology, or computer science. After I've made so many posts memeing people who express concern over kernel-mode components I've decided I'll actually write something about it. If you're a person who distrusts kernel mode anti-cheat software I suggest you read this. If you're a person who does not understand how they work but you're curious how they work (and why) I also suggest reading this.

Before we go down this rabbit hole, which I will try to make as succinct as possible, I want to assert that each anti-cheat kernel-mode component operates differently. By this I mean the techniques I describe below will operate fundamentally similarly across other anti-cheat vendors, but each may introduce additional layers of complexity, remove layers of complexity, or implement their own proprietary research to combat cheaters. In essence, what I am describing is the generic blueprint in how they operate but each may be tailored different for their industry, their game, ... whatever. I also expect anti-cheat, or cheat researchers to critique this paper due to not emphasizing certain techniques they may believe are more important to illustrate than others or debating whether or not something is truly behavioral analysis based rather an entirely new category in itself (you'll see that later). Meh.

I'll also be providing links to web articles or Wikipedia pages for the curious who want to go deeper and feel psychological pain.

User mode vs Kernel mode

On the Windows operating system (and every other operating system, but for this article we're going to focus exclusively on Windows), the operating system is divided into 2 "modes". These two modes are user mode and kernel mode.

User mode is the part of the computer operating system you can physically see and interact with (although, if you're curious, this also expands into what is known as "The Windows Shell") as well as programmatically interact with it through an API. In other words, user mode is the place where you do shit.

Kernel mode is the part of the computer you cannot interact with (or rather, at least not easily), and is responsible for managing the user mode part of the computer. Kernel mode acts almost like a manager, it allows the "user mode" to safely interact with the computer hardware (keyboard, mouse) as well as lower-level hardware such as the hard drive, memory, and processor itself. It is also responsible for creating the user mode "space". Every action taken in user mode must be approved of and performed through kernel space. An action as simple as moving the mouse or pressing a key on your keyboard must pass through kernel mode.

These two modes exist for a very important reason which requires some historical context. Back in the day, which means MS-DOS-era, the operating system sort of jammed everything into memory together. There was no segregation between "user mode" and "kernel mode". Back in the day users could do an oopsie doopsie and corrupt the software which allowed the computer to communicate with the hardware. This inevitably resulted in Microsoft introducing boundaries and segregating "user" space and "kernel" space whereas some software could access computer hardware and some software could not access hardware. In order for software to access hardware it would instead need to be performed by a middle-man known as a Device Driver or simple known as a "driver"

Hence, whenever you're installing or updating "drivers" on your computer you're installing or updating the software which operates in kernel space which allows your user mode software the ability to access hardware and actually do things.

What can enter kernel space?

Fast forwarding 30 years or more to the modern era, as in ... this very moment I'm writing this and you're reading this, kernel mode has evolved dramatically and has introduced hard boundaries segregating user mode and kernel mode. It's also introduced additional layers of protection to prevent bad actors from entering kernel mode when they shouldn't have access. These additional layers are Driver Signature Enforcement, Kernel-mode Code Integrity and/or Kernel Patch Protection (Patchguard), and Microsoft Vulnerable Driver Block list

Basically, Microsoft won't let any program enter kernel mode. Any software that wants to enter kernel mode needs to be reviewed and approved of by Microsoft. When it is approved it is issued an official "certificate". Additionally, Microsoft has introduced enhanced techniques to prevent drivers (kernel mode software) from altering or modifying other kernel mode software. Finally, Microsoft has an on-going "block list". This "block list" is basically drivers they have approved historically, but now they're deemed unsafe hence they're not longer allowed to enter kernel space.

You can view the certificate and certificate "owner" by right clicking on a driver (.sys file), clicking "Properties", clicking "Digital Signature", and then clicking "Details". The attached image is from a random driver on my computer.

Inevitably you're probably thinking, "is there a way to enter kernel space without a signature?". Yes, that is a technique frequently used by malicious software (malware) and video game cheat makers. But discussing offensive techniques for anti-cheat evasion go beyond the scope of this paper.

Why are anti-cheats in kernel mode?

There are certain things kernel mode components can do that user mode components cannot do. For example, user mode components cannot be notified of the "creation" of another process.

A common technique employed by kernel-mode anti-cheat software is the usage of PsSetCreateProcessNotifyRoutine (or it's variants Ex and Ex2). In the simplest of terms, it is possible for a kernel mode component to begin receiving notifications when a process is set to be created. This is extremely valuable to anti-cheat software because they can use this to prevent users from running video game cheating software. This method of receiving notifications when a process is being created is nothing new. This is the exact same technique employed by anti-malware and End Point Detection Response software.

The way anti-cheat software examines and determines if a program is being used to cheat is "proprietary" in nature. By this I mean there is no "golden standard", rather anti-cheat vendors will search for solutions and implement them in ways they believe are best. However, from a high-level overview, they all follow a similar formula.

Once a kernel-mode anti-cheat software is running it will begin receiving notifications when a user runs a program. The kernel-mode anti-cheat will then examine the program you're trying to run. The manner in which it examines the software is essentially "the secret sauce" for each anti-cheat vendor (and anti-malware software!), but it boils down to "static analysis engines", and "behavioral analysis engines".

The static analysis portion of the anti-cheat software will programmatically inspect the program and look for sequences of bytes, or byte patterns, which are often found in video game cheating software. In other words, from an extremely high-level overview, it is equivalent to you (the person reading this) pressing CTRL+F and looking for keywords in a web article. Likewise, anti-cheat software will search for known patterns in the program attempting to be ran by the user. If the anti-cheat software identifies a known-bad byte sequence (like you found the keyword you looked for on a website), the person attempting to run the program will immediately be flagged as cheating.

The behavioral analysis portion is far more complex and yet another "secret sauce" scenario. In essence, the anti-cheat software will "examine" operations occurring on the machine to determine if the user is cheating. This is not just one singular technique, rather a bunch of different techniques which may, or may not, be introduced into the anti-cheat software which fall under the "behavioral analysis" category. In my opinion, reviewing every single potential behavioral analysis technique would be profoundly time consuming and would inflate this web article to about x15 it's size. However, for those who are curious want to go down this rabbit hole, here are some things I recommend researching:

I am probably missing some other behavioral analysis techniques (or adjacent categories) as well. Anti-cheat techniques are broad and robust. Each anti-cheat is different. An anti-cheat for Battlefield will be remarkably different for an anti-cheat for Roblox because the underlying technologies which drive those games are different.

Addressing concerns about anti-cheat invasiveness

Many people who are unfamiliar with security software almost immediately believe kernel mode access is required for bad actors can exfiltrate sensitive data off of your computer, modify other kernel-mode components, or do other nefarious acts. However, this is not true.

While it is possible for a signed kernel-mode component to be malicious, is it exceptionally rare. It is easier for bad actors to write malware which operates in user-mode and do the malicious actions from there. 99.9% of malware discovered targeting users, large companies, and governments, is user-mode malware. The golden age of rootkits is dead due to the implementation of Patchguard (and Driver Signature Enforcement) which makes it extremely difficult for other kernel-mode components to modify other kernel-mode components. Of course, for the sake of argument, there is almost always a way "around" a security feature. However, Microsoft seems to take these actions quite seriously and is quick to patch any potential Patchguard bypass technique.

Threat Actors, specifically people who aim to steal your sensitive data, will rely on file masquerading and various other techniques to coerce a user to detonate malicious software on their machine. A user-mode binary (.exe, .dll, .vbs, .js, .py, etc.) needs very little privileges to access sensitive data on your machine. In fact, in some scenarios, you don't even need a binary and a Threat Actor can simply live off the land by abusing existing programs on your computer. This entire conversation however is something I've sort of discussed before under "Can "adult" websites actually "infect" your computer?

"I still don't like it. I still don't trust it. I don't like them."

If you've read this far and you still have concerns, such as LowLevelTweets who believes kernel-mode components should reserved for ... things other than video games ..., then that essentially boils down to opinion and perspectives on security models.

This article was written and designed to combat misinformation regarding the safety of kernel-mode components (e.g. oH mY gOd tHeyRe RooTkitZ) and the misconception these can effectively be used for espionage ... against gamers. In summary, kernel-mode components must be approved by Microsoft, are unable to modify other kernel-mode components, is way over-kill for "spying" on people, and kernel-mode malware is almost non-existent due to security improvements Microsoft has made separating the user-mode and kernel-mode boundary.

If any more questions pop-up in the future I may expand on this article.

-smelly

PreviousMMKCMM Loader

Last updated