[cherryteastain]

> 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.

[doix]

> 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...

[themoonisachees]

> 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"

[Hikikomori]

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