1464
Steam games will now need to fully disclose kernel-level anti-cheat on store pages
(www.gamingonlinux.com)
this post was submitted on 30 Oct 2024
1464 points (98.5% liked)
Games
32654 readers
2057 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
To put it very simply, the 'kernel' has significant control over your OS as it essentially runs above everything else in terms of system privileges.
It can (but not always) run at startup, so this means if you install a game with kernel-level anticheat, the moment your system turns on, the game's publisher can have software running on your system that can restrict the installation of a particular driver, stop certain software from running, or, even insidiously spy on your system's activity if they wished to. (and reverse-engineering the code to figure out if they are spying on you is a felony because of DRM-related laws)
It basically means trusting every single game publisher with kernel-level anticheat in their games to have a full view into your system, and the ability to effectively control it, without any legal recourse or transparency, all to try (and usually fail) to stop cheating in games.
And it's worth noting that trusting the game developer isn't really enough. Far too many of them have been hacked, so who's to say it's always your favorite game developer behind the wheel?
Or, even better, when you let a whole bunch of devs have acces to the kernel...
... sometimes they just accidentally fuck up and push a bad update, unintentionally.
This is how CrowdStrike managed to Y2K an absurd number of enterprise computers fairly recently.
Its also why its ... you know, generally bad practice to have your kernel just open to fucking whoever instead of having it be locked down and rigorously tested.
Funnily enough, MSFT now appears to be shifting toward offering much less direct access to its kernel to 3rd party software devs.
More importantly, if traditional anticheat has a bug, your game dies. Oh no.
If kernel level anticheat has a bug, your computer blue screens (that's specifically what the blue screen is: a bug in the kernel, not just an ordinary bug that the system can recover from). Much worse. Sure hope that bug only crashes your computer when the game is running and not just whenever, because remember a kernel-level program can be running the moment your computer boots as above poster said
Not all anti cheats run at startup. Some only run when you play a game. I think vanguard for valorant ran all the time at first and people were pissed. Meanwhile easy anti cheat runs only with a game. So it depends. It all sucks though.
That's definitely true, I probably should have been a little more clear in my response, specifying that it can run at startup, but doesn't always do so.
I'll edit my comment so nobody gets the wrong idea. Thanks for pointing that out!
It's not just trust of the game developer. I honestly believe most of them just want to put out profitable games. It's trust that a hacker won't ever learn how to sign their code in a way that causes it to be respected as part of the game's code instructions.
There was some old article about how a black hat found a vulnerability in a signed virtual driver used by Genshin Impact. So, they deployed their whole infection package together with that plain driver to computers that had never been used for video games at all; and because Microsoft chose to trust that driver, it worked.
I wish I could find an article on it, since a paraphrased summary isn't a great source. This is coming from memory.
That's not an accurate description of the exploit you describe. It sounds like the attacker bundled a signed and trusted but known vulnerable version of the module, then used a known exploit in that module to run their own unsigned, untrusted code with high privileges.
This can be resolved by marking that signature as untrusted, but that requires the user to pull an update, and we all know how much people hate updating their PC.
Thank you! Really clear and appreciate you taking the time to explain!