The cat and mouse game between cheat devs and anti-cheat devs is quite interesting. I saw a nice video [1] a year ago about the state of the art in cheat development, which at that point was having a PCIe device that can issue DMA requests to read the RAM at any time and stream the data to a second PC to analyse. Vanguard did end up banning those people eventually, since it can see what devices you have plugged in. I can't help but wonder if the next level would be some kind of shim on the physical RAM sticks; or maybe custom UEFI firmware.

Ultimately the OS should be providing a service that can verify a program is running in a secure environment and hasn't been tampered with. That's something that's useful for things far beyond games. I kind of hope the cheaters win this war for now, to create the incentive for building a better, proper, standardized, cross-platform solution.

[1] https://www.youtube.com/watch?v=kzVYgg9nQis

▲

jeroenhd 5 days ago | parent | next [-]

> Vanguard did end up banning those people eventually, since it can see what devices you have plugged in.

Only because the makers of those DMA cards do a bad job hiding themselves. They either use vague, recognisable names, or don't act like the devices they're spoofing.

The moment a cheat developer manages to reprogram an actual SSD (especially a common model), hardware detection like that becomes near impossible.

	▲	davikr 4 days ago \| parent [-]
		Riot just shipped a new kind of DMA protection, using IOMMU, and they tout that that cheating method is now 6 feet deep.

▲

tracker1 5 days ago | parent | prev [-]

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"

	▲	Sohcahtoa82 5 days ago \| parent \| next [-]
		> 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.
	▲	positr0n 5 days ago \| parent \| prev [-]
		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.