1

I recently asked a question about privileges required in Windows to read any user-mode program's memory contents. I learned from documentation linked in some of the comments:

Apparently PROCESS_VM_READ is required but documentation doesn't seem to explain under which conditions such a trait is attributed to a process. Apparently, ACLs are involved:

When you call the OpenProcess function, the system checks the requested access rights against the DACL in the process's security descriptor. When you call the GetCurrentProcess function, the system returns a pseudohandle with the maximum access that the DACL allows to the caller

But another user asks about "C++: reading memory of another process" and receives an answer linking this github repo:

https://github.com/T-vK/Memory-Hacking-Class

Now I am just learning C++ as a beginner now, so I can look through this code but I can't say I understand it, so I apologize if the answer is obvious.

I'm guessing from what I've learned so far this code only works against processes which allow PROCESS_VM_READ access. But if that's true, I don't understand why every game executable wouldn't just stop cheats by denying that access. There must be something to this picture that I'm missing.

Ðаn
  • 10,934
  • 11
  • 59
  • 95
J.Todd
  • 707
  • 1
  • 12
  • 34
  • "I don't understand why every game executable wouldn't just stop cheats by denying that access" There are lots of other techniques besides `ReadProcessMemory`. – Ben Voigt Sep 01 '21 at 21:24
  • @BenVoigt I don't suspect game hackers are burning expensive windows exploits on these products. – J.Todd Sep 01 '21 at 21:59
  • The program itself can’t deny read access, that’s based on the user. If there was a flag in the header, say, a hacker would just patch that. – 500 - Internal Server Error Sep 01 '21 at 22:26
  • @500-InternalServerError Ah ok, that's not how I understood the documentation. User choice, not process choice. – J.Todd Sep 01 '21 at 23:10
  • @J.Todd: There is no "choice" at this level, there are only instructions being executed. What you may have missed, and I think InternalServerError was trying to say, was that the DACL determines the level of access for a security principal, and processes are not security principals, users are. So when you secure a process security descriptor, you block access to all processes of a particular user at once, you can't cherry-pick and say "this anti-cheat can read process memory remotely, that cheat engine can't" unless those processes are running under separate login tokens of separate accounts. – Ben Voigt Sep 02 '21 at 16:42
  • Furthermore "The owner of an object has the privilege of being able to manipulate the object’s DACL regardless of any other settings in the security descriptor." So if the computer operator is running the anti-cheat in the same user account as the game, it can just remove the protection. Process security only protects against other user accounts. – Ben Voigt Sep 02 '21 at 16:45
  • @J.Todd: We're not talking about zero-day exploits here, we're talking about well-known techniques for code injection. For example, add an entry to `AppInit_DLLs` and you don't have to read process memory remotely, you read it from inside the game process itself. – Ben Voigt Sep 02 '21 at 16:47

0 Answers0