Live data from Hacker News

Kernel anti-cheat is an overreach

nooneshappy.com

81–90 of 119 posts

Re: Kernel anti-cheat is an overreach

#81
post #27

Earlier quoted context omitted.

Almost all trainers from time immemorial operate in the kernel space because they require direct access to memory addresses. The whole cheats paradigm started with altering values stored at specific addresses. Alter the right value and the player character gets infinite ammo or lives or whatnot, and it went from there. Modern day cheats embed more sophisticated logic that ultimately boils down to altering locations i…

> The whole cheats paradigm You are limited in envisioning a game where the client device is being trusted for ground truth about the game. In client-server models, it is possible to limit trust such that many cheat modes and methods are impossible. Furthermore is the “remote GPU streaming” model like Stadia, which nearly obsoletes conventional techno-cheating, and likewise obsoletes kernel-mode anti-cheat.

User input is always sourced at the client device. There is no other source of truth, therefore any hacks that manipulate input will not be detected server-side. Additionally, using only the server state gives a distinct advantage to the better/faster connection. This was true in Quake 2, but games have become a great deal more sophisticated since then.

Re: Kernel anti-cheat is an overreach

#82
post #2

> So I would rather share a match with the occasional cheater than run un-auditable ring-0 software on the same machine I use for anything private. Yeah except that’s not the options here. Even with ring-0 there are lots of cheaters. Without it the game would be completely infested with them.

I would still rather have that than let some game run in ring 0 TBH.

Nobody is forcing you to play a game with kernel anti-cheat.

I want to play the game, not deal with mass cheating. Unless the people against kernel-level anti cheat can provide an alternative with similar level of protection, there isn’t anything to discuss as far as I’m concerned.

Re: Kernel anti-cheat is an overreach

#83

This article reminds me of Chesterton Fence - the author is complaining about something, without ever experiencing why it exists.

I used to host pretty popular servers for several games (mostly the PvP survival kind), built a community around them, and developed custom admin software. It's hard to say I haven't experienced this first-hand, I fully understand the reasons for this to exist. Yet I 100% agree with the author, this went way too far long ago. This will NOT stop until the personal computers are forcibly locked into a fully attested hardware chain, for everyone not just gamers. The control over your personal computer will be eventually taken from you even if you never played a game in your entire life. And then cheats will simply move outside the machine entirely. No entertainment is worth it.

Starting from a certain point, the solution for cheating is better game design, more human involvement, and community building, not adding more restraints which will be circumvented in any case.

Re: Kernel anti-cheat is an overreach

#84
post #80

Earlier quoted context omitted.

Are you playing games on a different user? If not a user space program can already access all your files and memory of running processes.

yama? ptrace scope? namespaces? selinux? apparmor? of course depends also on system defaults, but then why I cannot dump ssh-agent process from same user? oh maybe that's also the reason why the move to the kernel level in general? or that's not necessary with different privileges and they could stay on user space without taking over kernel? (insert here philosoraptor meme pls) again having low leve drivers from exte…

Talking about Windows here as we're discussing kernel anti cheat.

>again having low leve drivers from external corps

What do you think drivers are then?

Re: Kernel anti-cheat is an overreach

#85

This article reminds me of Chesterton Fence - the author is complaining about something, without ever experiencing why it exists.

I must admit I immediately questioned the credibility of the article when the author admitted they "aren't a gamer" and then started making allusions to vague political threads. Not to say these criticisms aren't valid, but they're a weird jumping off point The reality is none of the companies want to do these things. Every step in this process locks out some subset of customers. And that's not including the ones who…

>The reality is none of the companies want to do these things. (...) They're an unfortunate response to (...)

This reasoning can be used to justify pretty arbitrary behavior, don't you think? Intent is irrelevant for malice, incentives are enough.

Re: Kernel anti-cheat is an overreach

#86
post #27

Earlier quoted context omitted.

Almost all trainers from time immemorial operate in the kernel space because they require direct access to memory addresses. The whole cheats paradigm started with altering values stored at specific addresses. Alter the right value and the player character gets infinite ammo or lives or whatnot, and it went from there. Modern day cheats embed more sophisticated logic that ultimately boils down to altering locations i…

Windows has no security between processes reading and writing each other's memory as long as they are from the same user. You doing need kernel level access to do it.

That hasn't been true since Windows 98/ME. Windows uses virtual addressing plus ASLR and DEP for process isolation/protection. See here:

https://learn.microsoft.com/en-us/windows-hardware/drivers/g...

Re: Kernel anti-cheat is an overreach

#87
post #86

Earlier quoted context omitted.

Windows has no security between processes reading and writing each other's memory as long as they are from the same user. You doing need kernel level access to do it.

That hasn't been true since Windows 98/ME. Windows uses virtual addressing plus ASLR and DEP for process isolation/protection. See here: https://learn.microsoft.com/en-us/windows-hardware/drivers/g...

You can use system APIs to get the memory space of another application in Windows as long as their run by the same user.

However iirc processes can opt out of this so only administrators can.

Re: Kernel anti-cheat is an overreach

#88
post #86

Earlier quoted context omitted.

Windows has no security between processes reading and writing each other's memory as long as they are from the same user. You doing need kernel level access to do it.

That hasn't been true since Windows 98/ME. Windows uses virtual addressing plus ASLR and DEP for process isolation/protection. See here: https://learn.microsoft.com/en-us/windows-hardware/drivers/g...

ReadProcessMemory and WriteProcessMemory are APIs Windows exposes for using other processes memory. Even if a process changes the default DACL to block it, admin level access can bypass it.

https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

Re: Kernel anti-cheat is an overreach

#89
post #27

Earlier quoted context omitted.

Almost all trainers from time immemorial operate in the kernel space because they require direct access to memory addresses. The whole cheats paradigm started with altering values stored at specific addresses. Alter the right value and the player character gets infinite ammo or lives or whatnot, and it went from there. Modern day cheats embed more sophisticated logic that ultimately boils down to altering locations i…

Windows has no security between processes reading and writing each other's memory as long as they are from the same user. You doing need kernel level access to do it.

don't need

Re: Kernel anti-cheat is an overreach

#90
post #33

I’m actually surprised how a lot of commenters here are defending kernel-level anticheat.

Have you played games with a ton of cheaters? It's infuriating, and I'm glad that kernel-level anti-cheat makes it such that you can have an enjoyable gaming experience. Now, I no longer play competitive shooters due to my age, but this was a huge issue back in the day.

Yes. I'm an avid Dota 2 player. I used to play the remastered CoD MWs too, and had a Counter-Strike phase as well.

Cheaters using external tools in Dota are rare. Smurfs are a much bigger problem than scripters/maphackers.

In my experience, MW and CS aren't that bad. I see a cheater only about once in 20 games.

I also play online chess. No kernel level anticheat is going to help you there.

Post reply on HN