Why Anti-Cheat needs kernel drivers
Recently I saw another reddit post re-spark the discussion of kernel drivers in Anti-Cheat. Ever since this controversy started I've noticed many people misunderstand the technology which has led to fear-mongering. I will try to clear up some of these misunderstandings around Anti-Cheat and kernel drivers in general.
What are kernel drivers?📎
A kernel driver is a program that lives in the operating system's kernel. This is the part of the operating system that directly interfaces with your system's hardware. The rest of the operating system runs on top of the kernel, the so-called userland. Processes in the userpace are managed by the kernel and use the kernel to interface with the rest of the operating system.
Sometimes a program requires direct access to the kernel to function. In this case, this program can ship with a kernel driver to extend the interface between userland and kernel space. For instance Wireshark uses the npcap driver on Windows to capture network traffic.
These kernel drivers are programs with a
.sys extension on Windows. And many third-party software uses them without you realizing it.
Other examples of software that often require a kernel driver to work:
- Virtualization (VMWare, VirtualBox)
- Graphics drivers (Nvidia, AMD)
- Generic device drivers (Printers, Razer Synapse)
- VPN (OpenVPN, Wireguard)
- DRM software (Widevine)
You likely have much more third-party code running in your kernel than you realize. Utilizing kernel drivers is very common, especially on Windows, and Windows does not notify you when they are installed or loaded. You cannot even watch Netflix without having Widevine or similar DRM software running in the kernel.
Why does Anti-Cheat use them?📎
Ever since the existence of Anti-Cheat, cheaters and Anti-Cheat have been in a sort of cat-and-mouse game. Cheaters try to find new ways for their cheats to go undetected, and Anti-Cheat tries to keep up. And the seriousness of it all should not be underestimated, developing and selling cheats has turned into a 100 million dollar market.
When Riot rolled out Vanguard they made a very nice blogpost detailing their choices for utilizing a kernel driver. They do a good job of explaining it, but I'll try my own explanation.
How do cheats work?📎
Let's first explain the kind of methods cheaters use. Software you might be familiar with like CheatEngine works by reading a program's memory and altering it. Other methods are manipulating the (outbound) network traffic for a game, injecting custom code into the game or faking external device input.
How does Anti-Cheat work?📎
Anti-Cheat ensures that the game isn't being messed with. Game input is real, memory is not altered, linked libraries are normal and there are no fishy processes. It communicates with the kernel for this. To quote the developers of Vanguard:
We (in user-mode) have to ask the kitchen (Microsoft Windows) what’s been added to our beef goulash (League of Legends).
This is built on an inherent trust of the kernel. If someone were to run their own code in the kernel, they could hook on the system calls used by the Anti-Cheat and tamper with the output.
I myself have experimented with bypassing an Anti-Cheat by hiding certain files from the game. I did so by linking the game with a library of my own, which overwrites methods in the C standard library.1 The presence of a library like this can easily be detected. However, if I were to utilize a kernel module instead, which hooked into these calls on the kernel level, it would be virtually undetectable from userland.
Fighting the battle in kernel space📎
So cheaters have started to use kernel space to stay ahead. A quote by Paul Chamberlain, a security engineer who worked for Riot and Epic Games:2
by 2015 or so, pretty much all the sophisticated, organized cheat-selling organizations were using kernel drivers.
This forced Anti-Cheat software to keep up by moving to the kernel as well. The kernel drivers are used to ensure that the output of the system calls to the kernel aren't being tampered with, so that the Anti-Cheat can do its job, detect cheats.
So for a couple of years now, the biggest two Anti-Cheats, Easy Anti-Cheat and BattleEye have started utilizing kernel drivers. Without them, these Anti-Cheats would be useless.
Loading code into the kernel📎
Users actually aren't allowed to load their own kernel drivers. This is because Windows will only load drivers which are signed by Microsoft. However there exists signed drivers with vulnerabilities allowing users to execute their own code within kernel space. These are called
vulnerable drivers. There is one quite popular,
capcom.sys which I suspect many cheaters are using. More about this driver later.
So these vulnerabilities allow users to execute code in the kernel and even load unsigned drivers.
This is an interesting project that allows you to use various vulnerable drivers to alter memory: https://git.back.engineering/_xeroxz/vdm. It includes a long list of potentially vulnerable drivers. It currently utilizes
gdrv.sys, which is a vulnearble driver by gigabyte.
When did this controversy start?📎
The oldest mention I've found of people complaining about kernel drivers in Anti-Cheat were in an article from 2016. However the first time I saw it was when the game Valorant was released with its new Anti-Cheat Vanguard, which is still very controversial to this day. This happened in 2020.
And I think the controversy can be traced back to one particular video, which initially sparked the discussion in the Linux community. And in this video by Muta (a person I despise in general) he claims that the new Anti-Cheat driver is akin to malware, seemingly oblivious to the fact that the other Anti-Cheats he mentions also contain a kernel driver.
To his credit, he does show part of the initial blogpost by Riot. And I believe if people would take the time to read a 5-minute blogpost instead of watching a 12-minute there would be a lot less misinformation out there. But that's too much to ask, especially in the (reddit) Linux community.
However, the video is a big source of misinformation as the author clearly doesn't have a good understanding of modern cheat and Anti-Cheat methods or kernel drivers in general.
Loading at boot📎
One part that makes Vanguard so controversial is that it is loaded at boot. There is a good reason for this and the lead Vanguard developer did a good job explaining it.
This is good for stopping cheaters because a common way to bypass anti-cheat systems is to load cheats before the anti-cheat system starts and either modify system components to contain the cheat or to have the cheat tamper with the anti-cheat system as it loads. Running the driver at system startup time makes this significantly more difficult.
Here is an example of a project which loads a custom driver in a way that goes undetected: https://github.com/armvirus/SinMapper. It uses the previously mentioned vmd. However, this most likely won't work with Vanguard.
Why are people worried?📎
Most users seem worried about their privacy. Comparing Vanguard to
Chinese Spyware because the company has been bought by Tencent. People are also worried the kernel driver will act as a backdoor, which when exploited could give remote attackers access to your computer.
Although these are valid reasons to distrust third-party software in general, it doesn't apply well to kernel drivers. Because kernel drivers are typically made for a single job (in this case detect tampering) and do not communicate with any remote servers. Writing kernel drivers for Windows is very hard and they're of little use for the purpose of collecting data.
What are the security implications?📎
So what would happen if the Anti-Cheat kernel driver were to be exploited? Well, we don't have to theorize about it as it has happened before. Twice actually.
Capcom.sys driver I mentioned before was actually used for Anti-Cheat in Street Fighter V.3 However the initial release of the driver in 2016 came with a vulnerability. This vulerability has since been very popular with cheaters/hackers to load unsigned drivers into the kernel with. Amazingly ironic right? When I talked about the first time I had seen mention of people being upset with kernel drivers in games, I was talking about this fiasco.
This driver has been used extensively to run code in kernel space.
In 2020 the Anti-Cheat for Genshin Impact,
mhyprot2.sys was found to have a vulnerability. It has gone a bit under the radar for the public, but various libraries have been made to exploit it. The researcher who found it is an Anti-Cheat developer himself and does not oppose the use of kernel drivers in Anti-Cheat. He has found many more vulnerable drivers and has also researched Vanguard. 4
Both these exploits allow an unprivileged user to execute code in kernel space. The biggest security factor here is that it could allow malware to elevate its privileges to administrator. However stills require direct access to your computer and an exploit specifically made for said driver.
The fact that these drivers allow malware to access the kernel is not relevant, because a process running with administrator privileges can load vulnerable kernel drivers anyway and use that to run code in the kernel. Besides malware really doesn't need elevated privileges for most purposes, and it especially has no need for kernel privileges.5
Capcom and mhyprot2 are just two examples of vulnerable drivers specifically originating from Anti-Cheat, according to Microsofts own blocklist there exists at least 1048 vulnerable drivers for Windows.
Even if the presence of an existing vulnerable driver would be required to enter kernel space, a hacker is not going to write malware that relies on a kernel driver from a specific Anti-Cheat. Imagine a virus that could only elevate its privileges if the user happened to start playing Genshin Impact.
So in conclusion, these kernel drivers could potentially allow someone with direct access to your computer, to gain access to kernel space. Which they could do anyway using administrator privileges, which if they haven't yet they could easily get anyway because privilege escalation on Windows is trivial.
Microsoft's fight against vulnerable drivers📎
Since there are so many signed kernel drivers with vulnerabilities, ever since Windows 11 Microsoft has started to enforce a blocklist containing many drivers popularized for kernel-hacking. It currently seems to contain 1048 drivers.
This could potentially make it harder for cheaters to get their code running in kernel space. Two drivers I've found to be used often,
capcom.sys are both included.
VAC is Valve's Anti-Cheat software, which does not use a kernel driver (and also doesn't really work). Back in 2018 someone working at Valve revealed one of their projects, VACNet, at a Game Developer Conference. It was a very interesting presentation, and I recommend you give it or this summary a watch if you are interested in seeing what a company has to deal with in terms of cheaters.
Valve developed a machine learning algorithm called VACNet which aims to detect cheaters on the server side. This means that it only uses the player's mouse and keyboard input to detect cheating. To train such a network they created a system called Overwatch where experienced CS:GO players could watch a recorded game and state if they think the player is cheating.
Server-Side Anti-Cheat sounds glorious in theory, detecting cheaters without needing to trust any software running on the client. However, the difficulty is in training and tuning such an algorithm. Valve had to rely on using experienced players as volunteers to help create training data for the model. Valve also had to rely on volunteers to convict players because an AI model could never convict players with a 100% certainty. And although VACNet is very good at discovering blatant cheaters, it has trouble even detecting players who cheat more subtly (like wallhacks). Additionally, a Server-Side Anti-Cheat model would most likely have to be specifically trained for each game that it will be applied to.
Although I hope to see server sided Anti-Cheat become the standard in the future, it still requires much more research and development.
A new method of cheating that would completely circumvent modern anti-cheat would be to use machine learning to identify targets on the screen, and then move the mouse to that target. Either by physically moving the mouse using a robot, or by using an external device that can emulate mouse input.
Here is a good example of this.
Obviously, this method is fundamentally limited in what it can do. And the current models are also too slow and lack training. But its power to bypass a Client-Side Anti-Cheat is interesting nonetheless.
Kernel drivers are extremely common on Windows, and their place in Anti-Cheat makes sense and is necessary with the current state of cheats. Although they could potentially be compromised this does not create a significant security risk.
A quote by the researcher who found the vulnerability in mhyprot2.sys:
To clarify: I personally do not think these are ”Rootkit” since I am one of the anti-cheat developer who knows what he is doing. It is necessary to have system-level privilege to prevent from cheating. but in other hand, it is clear it also necessary to protect user’s privacy aswell.↩
Although some advanced malware could potentially use the kernel to hide itself. ↩