Fuck Kernel-Level Anticheat

Before I start off this blog post, I'd like to apologize to any former viewers for my site and services being gone for so long. My old website was a piece of shit and needed to go, but I couldn't get this one in a way I wanted for a while. Sorry about all that, I'll try to have actually usable stuff now. Most of my old services are back online with the rest getting worked on. Old blog posts have been wiped because they sucked anyways.

Anyways, back to your regularly scheduled nerdbabble.

Introduction

Cheating has been a problem in online gaming for about as long as anyone can remember. I think most people reading this can agree that cheating in multiplayer isn't a good thing. That said, I think the problem of intrusive anticheats is far greater than the problem of cheaters themselves. And this isn't coming from someone who's never dealt with cheaters in games. I was there at the peak of Sniper bots in Team Fortress 2 spinning around like Beyblades and killing you from across the map, I've played plenty of Black Ops 2 in lobbies with people using mod menus, and I've seen CS:GO wallhackers. I know it sucks, but kernel-level ACs are not a good solution for anything reaching normal players. The only situation I can see them being even remotely permissible is in LAN tournaments and such.

What is kernel-level anticheat?

Kernel-level anticheat, unsurprisingly, operates in the kernel space of an operating system. While this part is obvious, if you're actually reading, you likely have no clue what that means. The "kernel" of an operating system is the part that talks to your hardware (like your processor, monitors, RAM, network card, etc). On Windows, the kernel is called NT. On MacOS, it's XNU. On Linux-based systems, it's Linux. All modern operating systems that actually matter divide everything between "kernel space" and "user space". Kernel space handles the kernel and all of its jobs, while user space is where all your other software goes, like web browsers, games, messaging apps, and whatever other stuff you might be running. Maybe this graph will do a better job explaining roughly how this works if I'm not coming through right:

These two "spaces" talk to each other, but kernel space takes higher privilege than user space since it directly talks to the hardware and handles communication between the two. Back to the topic of anticheat software, this is where kernel-level ACs actually work. By operating in kernel space, the anticheat gets access to ~everything on your computer when the anticheat is running with the (marketed) goal of stopping you from cheating in game. Note that I did not say "when the game is running", I said "when the anticheat" is running. Kernel level ACs usually require that you run them from boot until when you stop playing, so if it's not running from when you boot, you have to reboot with it enabled and *then* play.

While yes, this theoretically gives the AC more power to detect cheating, this neither makes it inherently better at picking up on cheats nor does it justify granting that much access to a kernel blob you have no real reason to trust.

Shady Vendors

Running things in your kernel from often dubious sources, as I just said, gives that program (and by extension, its developers) as much access as you can possibly give to a piece of software, and of course, gets abused. The single biggest example of this I can remember happened all the way back in 2013 on ESEA. In April 2013, ESEA's anticheat client was updated to start mining Bitcoin on every install of the client, which of course was removed, discovered, and then played off as a mistake.

While yes, not all kernel ACs will try to pull some shit like this, it's something you should definitely take into consideration when you play a game using this type of AC or defending the use of them.

Security

Even if you put 100% trust in the anticheat developers that they will never include ANYTHING malicious in their AC, no program is perfect. Vulnerabilities happen in everything given enough time, no matter what gets put on the marketing page. Shit happens, and when it does, you don't want it happening in THE most privileged part of your operating system. While yes, this does go for the rest of the kernel, the first party parts of the kernel and its drivers are A) invariably held to a higher standard than something like Vanguard, Javelin, or Ricochet is, and B) are largely maintained as one, constantly getting the security updates they need. The kernel and its modules usually (with the main exception of NVIDIA's god-awful Linux drivers, which even then shouldn't introduce nearly as much of a risk) are maintained for as long as you're using that system or installation of the operating system. When a game using a kernel AC falls out of support or the developer just stops caring, what happens then? You're just fucked! If you want to keep playing your game, you'll have to keep running with potential vulnerabilities that probably would exist by then at the kernel level. Or even worse, nothing will work AT ALL because your anticheat doesn't work on the latest kernels.

For example, you might remember the CrowdStrike incident of 2024. While it may have not been an anti-cheat for some online game, it did happen due to misuse of kernel space. ONE fuck up in Falcon Sensor led to an estimated 8.5 million BSoDs, causing flights to get canceled and affecting 60% of the Fortune 500.

The Linux Problem

Of course, most (if not all) kernel-level anticheat software is Windows-only. And since it's running as part of the kernel, compatibility layers like Proton/Wine don't help. As Linux's userbase for gaming slowly grows with the help of Steam hardware and Windows repeatedly shooting itself in the foot, this presents a pretty big problem to Linux users, especially as most kernel ACs try to detect VMs and block you from playing on anything other than a bare metal Windows install. It's pretty annoying to have to set up dualboot between Windows and Linux just to play a game with your Windows-using friends.

And For What?

The biggest problem with kernel level anticheat is that on top of being invasive and breaking Linux compatibility, they aren't the silver bullet Riot, EA, Activision, etc want you to believe it is. Running in the kernel does not make the software inherently better at picking up on cheating. It simply gives the opportunity to detect kernel-level cheats (which of course, carry all the same risks listed here and then some). As the cheating-anticheating arms race continues, hardware cheats taking advantage of DMA (Direct Memory Access) are becoming increasingly prevalent, with kernel ACs able to do very little about it in comparison to software cheats.

While I'm not at all knowledgeable in cheat development, I think the best solution here is validating player actions on the server side as much as possible. I think machine learning in picking up on irregular player inputs could be very useful, and it would heavily relax the "need" to run invasive software on client machines.