Today I would like to spread awareness and clear up some misconceptions about kernel level anti-cheat software. This is a topic that has been the subject of much debate and misinformation, and I hope to provide some clarity on the matter.
Before you continue reading, I want you to really understand the weight your opinion has on this topic. If you are against kernel level anti-cheat, you are directly advocating for cheaters to have a much easier time creating cheats and ruining games. You are advocating for the bad guys to have the upper hand over the good guys. The question is, are you okay with that?
Reading the entire article will unlock a joke at the end, so if you want to get the joke, make sure to read through the whole thing!
Key Criticisms
Let's break down the main criticisms that are often thrown at kernel level anti-cheat solutions. Understanding these concerns is crucial to dismantling the fear and stigma surrounding kernel level anti-cheat.
Propaganda - courtesy of PirateSoftware
Security Risk
One of the most common criticisms is that kernel level drivers run at a higher privilege level than users themselves. The most argued point is that if the anti-cheat developers accidentally introduce a vulnerability into their kernel driver, it could potentially be exploited by others to gain unauthorized access to the system.
Counter Argument
There is already a huge amount of vulnerable, exploitable, signed kernel drivers in the wild. The reality is that the risk of a vulnerability being introduced by an anti-cheat developer is negligible, considering that there are already countless options for malicious actors to choose from if they want to gain kernel access. As long as a process has admin access, they can load any signed kernel driver they want, and there are already many vulnerable ones out there that they can choose from.
Furthermore, the developers who work on anti-cheat kernel drivers more than likely already have deep knowledge of kernel internals and security practices, making it extremely unlikely that they would introduce a vulnerability that could be exploited in this way. There is a better chance a kernel driver developed for a hardware peripheral (like a mouse) would have a vulnerability that could be exploited than there is for an anti-cheat kernel driver, yet we don't see people freaking out about installing a mouse driver.
What about Genshin Impact mhyprot2.sys? If you don't know, the Genshin Impact anti-cheat kernel driver was exploitable, and loaded by ransomware to gain kernel access. This does not discredit the original point that there are 100s of other vulnerable kernel drivers that could have been used to gain kernel access in its place. How did this happen? The game was under growing pressure to defend their image from cheaters, and decided to attempt to make their own kernel driver despite lacking expertise. Other anti-cheat solutions like Riot and Epic Games have dedicated security teams comprised of experts to ensure this will not happen.
Invasive / Privacy
Because the anti-cheat has kernel level access, it has the potential to access and monitor a lot of information on the user's system. Couldn't they potentially use this access to spy on users, collect sensitive information, or even install malware without the user's knowledge or consent?
Counter Argument
Let me ask you a question, what information are you actually concerned about? Your passwords, your browsing history, your personal files? If your answer follows that line of thinking, then you should be equally concerned about every user level program running on your system. User level processes have the ability to access all of that information as well. So what exactly do you think a kernel level anti-cheat is going to be able to access that a user level program wouldn't be able to?
On the other hand, if your argument is anti-virus evasion, then you should appreciate the amount of knowledge and work it takes to make an anti-cheat kernel driver. If a fraction of that work was put into making user level malware, it would be undetectable from almost all anti-virus software.
The reality is that all kernel drivers have to be signed by a certificate authority, and (usually) sent to Microsoft for verification before they can be loaded. This process adds an additional layer of security and accountability. On top of this, cheat developers reverse engineer anti-cheat kernel drivers consistently to find bypasses. So if there was any malicious intent in the code, it would be found very quickly and widely publicized, leading to huge backlash against the company and likely put them out of business: alongside legal action against the company and the individuals responsible.
Instability
Another common criticism is that kernel level anti-cheat software can cause system crashes or other stability issues. If a crash happens in the kernel, it can lead to a blue screen of death (BSOD), as there is no higher privilege level to catch and handle the error gracefully. This can be a major inconvenience for users, especially if it happens frequently or without warning.
Counter Argument
Since kernel anti-cheat developers are almost certainly already deeply knowledgeable about the Windows kernel, they are less likely to introduce bugs that could cause instability compared to other kernel driver developers. Additionally, kernel anti-cheat software is typically designed to be as stable and reliable as possible, as any crashes or instability issues would reflect poorly on the company and could lead to a loss of players. While it's true that kernel level software has the potential to cause system crashes if not implemented correctly, reputable anti-cheat developers take great care to ensure that their software is stable and does not cause undue harm to players' systems.
But Lewis, I have blue screened from anti-cheat before! - If this is the worst case scenario, are you truly happy to strip away a huge amount of power from the defenders, and in turn happily hand that power to cheaters? I personally do not think that a rare crash is a good enough reason to provide cheaters with higher access than the defenders. If you are, then I don't think you genuinely care for the games you love being ruined by cheaters, because that's the reality of what you are advocating for.
What Can't User Level Anti-Cheat Do?
This is the most important question to ask when discussing kernel level anti-cheat. If user level anti-cheat can do everything that kernel level anti-cheat can do, then there is no reason to use kernel level anti-cheat. However, that is simply not the case.
Here are some key limitations of user level anti-cheat that kernel level anti-cheat can solve.
Prevent Memory Access
User level processes cannot prevent other processes from accessing their memory, making the skill level required for cheat development lower. With kernel access, anti-cheat software can implement measures to prevent unauthorized access to the game's memory - even from kernel cheats.
Detect Kernel Cheats Reading Memory
Kernel cheats can read the memory of the game without the user level anti-cheat knowing, let alone being able to do anything about it. This means that cheat developers can create cheats that are undetectable by user level anti-cheat, as they can simply read the game's memory directly from the kernel.
Detect Hardware ID Spoofing
Many anti-cheat solutions rely on hardware IDs to identify and ban cheaters. However, with kernel access, cheat developers can spoof their hardware IDs to bypass these bans by intercepting the kernel routines that retrieve hardware information and returning fake data, and simply overwriting the values in memory that the user level anti-cheat relies on. This means that even if a cheater is banned based on their hardware ID, they can easily bypass the ban and continue cheating without any consequences.
Detect Kernel Hooks
Windows provides functions to user level which eventually calls into the kernel, known as syscalls. With kernel access, cheaters can intercept (hook) kernel routines that back these syscalls. For example, if a user level anti-cheat relies on the CreateToolhelp32Snapshot function to check if a cheat thread is running, a kernel cheat could hook the kernel function which backs the user level call. This allows the cheat to always return a modified version of the original data with their thread stripped out, making it appear as if no cheat is present. This idea can be applied across the board to any function the user level anti-cheat relies on, allowing kernel cheats to effectively blind user level anti-cheat from being able to detect them at all.
What About Server-Side Anti-Cheats?
I hold the personal opinion that they are currently ineffective against cheaters who are determined to cheat, as well as not being a viable replacement for client-side anti-cheat solutions. Server-side anti-cheat can be effective at detecting and preventing certain types of cheating, such as obvious aimbots or players moving at impossible speeds. But on the other hand, I do not believe these kinds of cheaters were ever the main problem to begin with. The main problem is the cheaters who try to look as legitimate as possible to avoid detection by using humanized aimbots and not looking through walls. These kinds of cheaters can be very difficult to detect with server-side anti-cheat, as they can mimic genuinely skilled players while compromising fair play.
What about artificial intelligence? AI has made huge leaps in recent years and has shown to be very effective at detecting patterns and anomalies. That said, I do not believe that AI will be able to currently detect these kinds of cheaters without a very high rate of false positives, which would lead to a lot of innocent players being banned. We have seen this with Counter-Strike 2's new VAC Live, which falsely issued penalties to pro players and streamers, as well as to players who set their mouse DPI higher to spin for fun. Another key point to consider is that AI is not evidence. If an AI detects a cheater, a lot of the time it cannot provide a clear deeper explanation for why it believes the player is cheating, which can lead to a lot of confusion and frustration for players who are banned without understanding why. In my opinion, no player should be banned without clear evidence.
Conclusion
I personally believe that kernel level anti-cheat is a necessary tool in the fight against cheaters. While there are valid concerns about security, privacy, and stability, none of them hold enough weight to justify empowering cheaters. It's important to remember that the game of cat and mouse between cheat developers and anti-cheat developers is an ongoing battle, and both sides are constantly evolving their techniques. By giving a greater power to the mouse, we are essentially crippling the cat. If we want to give the cat a fighting chance, we need to equip it with the tools it needs to catch the mouse, even if those tools come with some risks.