Cheats run on the cheater's machine, not on the other players' machines. Of course the cheater would always click accept because it's not an accident that the cheat is running on their machine.

It's not the cheat that has to be accepted, it is the game. The option prevents the cheats (or any other program) from being able to examine the game's memory.

You would need to get rid of kernel level drivers for that to work. Which right now would completely disable any security software. But if it's ever done yeah this wouldn't be such a bad idea to isolate apps. However any security API would still have to allow read only access, which would be enough for most cheats, and by design blocking this type of access should never be possible since antivirus/EDR will need this.

Because the user controls their own machine, so they can open a hex editor and turn your option off.

Well I assume there are ways to prevent that (or make it extremely difficult at least)? E.g. look at denuvo, nobody has been able to "open a hex editor" and disable denuvo.

Denuvo isn't just a flag on a process. It's no more relevant to your suggestion than encryption would be to a suggestion that audio files have an option to prevent them being copied.

Picking an analogy that is actually how DRM worked is fitting.

>Denuvo isn't just a flag on a process

Nor would be PC's solution. That's why they added it, making it relevant.

> nobody has been able to "open a hex editor" and disable denuvo.

In fact, three people have been able to do so, that's why denuvo games do get cracked.

Not the recent denuvo versions, and not in the past ~1 year.

That's not even the point though, I am not saying it is literally impossible to circumvent this, but as long as it is hard enough that it is not financially reasonable for the cheat makers, that's good enough.

But now we've gone from "why do we need anti-cheat programs at all?" to "why do we need anti-cheat programs? Just make anti-cheat programs".

Denuvo has been disabled many times; however, the amount of work required to modify all the generated injection points is tedious—it's a LOT of work. It seems that fewer and fewer people are willing to spend weeks or months of their lives cracking a single game.

Anti-cheat systems, on the other hand, are entirely different. If you only need to modify one variable in the game, it's much easier because, in most cases, that variable is frequently used. This means you can't add too much overhead to its use, and after all, it's just one variable.

Indeed. Anti-cheat is interesting, because it's a case where you "want" to be able to "prove" that you don't have control over your own machine. Or rather other players want a sufficient level of assurance that you're not running certain kinds of software.

It's like DRM; on some level, the user is using computer how he is supposed to use it - interacting with memory and processor and the programs.

Of course nowadays DRMs are sort of baked-in, so I guess anti-cheats could be too?

Usually cheat programs are employed by the user. So they would of course click accept .

It's not the cheat that has to be accepted, it is the game. The option prevents the cheats (or any other program) from being able to examine the game's memory.

It could if the hardware allowed such separation, but the x86 platform doesn't do anything close to that and allows reading memory of other processes in so many different ways in both userspace and kernel. Not to forget hardware being able to read memory via DMA that many use now.

- Have a thin hypervisor kernel

- Have the user-facing OS be a VM managed by that hypervisor

- Have the game process run under a second sibling VM

The hypervisor can then mediate hardware access and guarantee nothing from VM A can access VM B nor the other way around.

IIRC WSL2 enables such a mode, both the Windows OS the user sees and the Linux VM run under Hyper-V as siblings VMs.

And Xbox One and up do EXACTLY the above: each game runs in its dedicated VM (I presume that's what "trivially" enables Quick Switch/Resume via pausing/shapshotting the VM) and apps run in another.

Tangent: I somewhat wish MS would allow WSL2 on Xbox.

Without hardware support, once the attacker gets to the hypervisor, you can't trust the hypervisor, or the "guarantees" that such tainted hypervisor provides to be upheld.

You need hardware support for confidential computing (for example, AMD SEV) to be able to trust that the hypervisor can't just read/write all over the VM RAM.

Sure, security comes in layers. A trusted platform boot chain can validate the hypervisor much easily than a whole hard disk, and existing x86 instructions can do the rest. The attack surface is also quite a lot smaller. It's already miles better than unfettered access from the very same OS and anticheats being privacy-invasive rootkits.

Hardware support for confidential computing is cherry on the cake, but in this scenario the user is not trying to defend themselves against an attacker, the game is, from the user a.k.a the cheater.

Malware will be the first software using that option.

That's why I said the user has to explicitly accept that.

Who do you think downloads and runs malware? Users.

By the same argument we should prevents the users from running any program at all because it might be malware.

That is indeed what many people want! Look at people defending "app stores" as being for the users' own good, and sometimes everyone else's.

No, but we shouldn't treat user's freedom as an anti-virus mechanism. Pretending that user acceptance will help in preventing malwares is extremely naive.

In addition to the technical details mentioned there is also the "social" part: Having Anticheat lets the company show they are doing "something" against cheating and keeps law abiding players from installing cheats.

> Can't the operating systems simply have an option when creating a process that prevents all operations looking at the memory of the process

Already the case for userspace programs, due to virtual memory

> those programs have to use OS facilities to mess with the game anyway.

Cheats today essentially are like drivers, they do not run as userspace programs. Hence, they can do literally anything on your computer. In terms of privileges, driver code runs at a level as privileged as the operating system. Hence the need for programs that run at the level of the OS kernel to catch the cheats.

> Already the case for userspace programs, due to virtual memory

Userspace programs can read other userspace programs memory, it's part of the standard win32 api[0].

> Cheats today essentially are like drivers, they do not run as userspace programs. Hence, they can do literally anything on your computer. In terms of privileges, driver code runs at a level as privileged as the operating system. Hence the need for programs that run at the level of the OS kernel to catch the cheats.

Some cheats nowadays do this, but they do this because of anti cheat programs. If there were no anti-cheat programs, they wouldn't have to do this.

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

> The handle must have PROCESS_VM_READ access to the process.

While the process still stays in user space, that's significantly different than "just being a user space program"

What stops a process from running OpenProcess with PROCESS_VM_READ on another process run by the same user in the same logon session?

If I wanted to write malware the first step to doing so would be turn on the “make me immune to any anti virus or endpoint detection software”

If you want to know why the OS doesn’t enforce this - https://slashdot.org/story/432238 you roll into HN’s other favourite topic of “why can’t I run the X of my choice on my OS?”

you don't need to read memory to cheat

What you're describing sounds like sandboxing, which Wikipedia vaguely suggests is an existing anti-cheat technique:

https://en.wikipedia.org/wiki/Cheating_in_online_games#Sandb...

Unfortunately injection based cheating is not the most prevalent form of cheating within titles that do a great job at preventing it such as overwatch. Screen bots are used often outside of any monitored process through hdmi streams and such. They can use game features, sprites, and colors to make aim and trigger bots that seem pretty natural. Additionally the most prevalant and annoying cheaters are the ones that trick games into believing keyboard and mouse is a controller which combines sticky aim features of controller input with the precision of mouse and keyboard controls. On consoles this is a dominant persistent cheat that a larger percentage of gamers use as opposed to the small percentage that inject code.

You would need hardware support to do this effectively. Telling a piece of software “no one is looking at your memory” as the OS doesn’t take into account rootkits and hypervisors.

For software related cheats maybe, but keep in mind that keyboard, screen and mouse being processed by an entirely separate computer is also very viable.