Memory Access Control in Windows Memory Management

Why can't windows kernel disallow cheater programs processes to access games memory at runtime through ACL (Access Control List) or other access control methods??

Let's take an example.

Let's say we are a game publisher. We publish a game, which our customers can run under any user account (games very rarely requires to be run with elevated privileges).

A game user, alongside our game, also installs a game cheat which runs as the current user.

User starts running a game and their cheat (both running under the same user account). Now, the system won't prevent the cheat from accessing (e.g. reading and writing memory, modifying CPU context, etc.) the game process: processes inherit their privileges from the logon session, which is tied to a user account. So basically, any process can "access" any other process running on the same session (under the same user account).

Now, you might be thinking: there should be a way to tweak the game process privileges so that, even if it's running on the same user account as a rogue program (cheat), it can't be accessed from another program. But that contradicts various fundamental security principles of operating systems:

• You cannot obtain more privileges than the maximum set of privileges you were given.
  • This means that, as a non-administrative user, you can't tweak the game process ACLs to run the game as, say, Administrator or even SYSTEM.
• A user has all power over the program it is running (that is, programs that are running under their own user account).
  • Depending on their set of privileges they may or may not have power over programs running under other user accounts.

Now we decide we want to force our game users to run the game as elevated administrator (another possibility would be to install a service running as SYSTEM, then the game would be started by the service, thus the game would also be run as SYSTEM). But, thinking about it, nothing prevents the user to be running the cheat also as elevated administrator (we don't have any control on the user's machine). We are back to square one.

Enter kernel drivers. As a publisher we decide to ship our game with a kernel driver, so from the kernel side, we make the process memory unreadable and un-writable, basically preventing any access whatever the user account and privileges are (even administrator). To counteract that, the cheat engine also ships with a kernel driver [1], disrupting and undoing whatever our own kernel driver is doing.

Now we decide that we could DRM our game, preventing reverse engineering of the game and the kernel driver. But... the cheat engine now leverage virtualization features techniques which cannot be seen even from the kernel space... (virtualization controls the kernel space).

To sum up: ACLs are not part of the equation for anti-cheats on PC since, as a publisher, you can't (fortunately, for us as users) control the end-user machine. It's a never ending cat & mouse game.

[1] Even though drivers have to be signed to be loaded, you can leverage a legitimate but vulnerable signed driver to do whatever you want in kernel space. Those are called "loldrivers".