Comment by tracker1
18 hours ago
I would think the Linux kernel could offer a "don't let anything read/write to the process I'm about to open" with a launcher then have that process also create a random/temp executable to test that the configuration is working...
Having the kernel itself, actually deny any access... The game devs run a build without debug symbols (not that debugging could work with it on), and run with it... Also, this should severely limit what that process can do in terms of communication outside itself. And maybe a launch warning from the OS... "You are about to launch a sealed application that cannot be observed, do you want to continue? Y/N"
> I would think the Linux kernel could offer a "don't let anything read/write to the process I'm about to open" with a launcher then have that process also create a random/temp executable to test that the configuration is working...
Then all a cheater has to do is run a custom kernel that has an API that responds to that request but then lets another process read/write the memory anyways.
You have to keep in mind something. The cheaters don't give a shit about what they have to do to let a cheat work. It's only the legit players that are like "I don't want anti-cheat to have kernel access". Cheaters will flash a custom BIOS to their motherboard if they have to without a second thought, while legitimate players would be absolutely horrified of the idea of needing a custom BIOS for anti-cheat, and very rightfully so.
That would only protect against userland cheats. A cheat developer would just write a kernel module to read the memory so it wouldn't be another process attempting to read it, but the kernel itself.