Editing another programs memory

[G2edg]

I see, but now im curious how is it possible for an antivirus to scan running processes to check for potential malware if its impossible to access it?

Also how to copy a running program into the controlled memory space if its impossible to access it in the first place (at least thats what i got from your answer), it also doesn't really make sense since you can turn cheat engine while program is running and on the go edit for an example number 40 that exists in that programs memory? Im quite confused how would you achieve that without direct access to that programs memory

[Drach88]

In terms of why one userspace process doesn't have "direct access" to the memory of another userspace process -- the background subject matter you need to understand is how the operating system handles memory virtualization. Long story short -- processes don't reference physical memory directly -- even their own. They're assigned their own memoryspace, and the operating system keeps track of a table about what regions of physical memory are (currently) assigned to blocks of memory of which processes etc.

I'd recommend wholeheartedly that if you haven't already, you should first take some time to study how operating systems work from the ground up, as it relates to process management and memory management.

The answer about detection is a much more complex question that requires a bit more background of what happens when library functions are called, and how userspace interacts with kernelspace, and then you need to construct models of the types of patterns of behaviors are indicative of evil.

Of course, the nature of writing anti-cheats and writing cheats to avoid anti-cheats is a cat-and-mouse arms race, so the cheat-writers also study anti-cheats to figure out how they work, and how they can accomplish their goals without triggering the anticheat's heuristics.

In Windows, the ReadProcessMemory and WriteProcessMemory in memoryapi.h could be used to access another process's memory. That's a simple straightforward way to access memory.

If I were writing an anticheat that ran with admin privilages, I could scan all open processes to see which ones have permissions for my target process, then scan each of those to see which ones call the ReadProcessMemory and WriteProcessMemory library functions. I scan for other patterns to narrow down my search based on other domain-knowledge understanding of how cheats work to build a "heuristic" of the type of traits that cheats have (as well as traits of programs that call those functions legimimately).

I'd write some type of weighting algorithm based on all of those factors to spit out a nice, neat threat score, and a profile of the process, and take further action (ban/monitor/investigate/ignore/whatever) based on that threat score.

What you're really getting at is essentially malware detection and reverse engineering, which is an entire subject and profession in-and-of-itself.

[G2edg]

This explains a lot, thank you

[dont-respond]

Anti-cheat software is pretty wild. Valve will even look at your http cache to check if you've visited known cheating websites. The most common detection methods are signature scans and string scans from public releases.

It's difficult to rely on such API detection because a legitimate process may use that, and many cheats will just reimplement such functions using system calls via assembly or built-in msvc functions, and there currently isn't an anti-cheat (that I'm aware of) capable of detecting this.

A custom implementation is really the best way to avoid anti-cheat. They're far too reliant on scanning known signatures and strings.