Detecting or preventing process memory injections on Windows (anti-hack)

Question

Standard hacking case. Hack injects into a started game process and writes over process memory using WriteProcessMemory call.

The situation is like this:

1. we are hosting a game server
2. clients join the server with their games, they can corrupt their games using various hacks
3. we have no chance to change game source, it is as is. However we do have a possibility to enforce our program to be run before client can join the server.

So to put this clear: we can't obfuscate game memory but we do have a possibility to run a separate program at the same time. I already tried to use a call EnumProcessModules which lists all process DLLs with no success. It seems to me that the hacks inject directly into process memory, therefore it is undetected. After doing a lot of "Google research" I came down to a few options:

1. scan for running process names, files in game directory, byte patterns of files, byte patterns of running processes... this task is very time consuming since I'd have to get samples of all available hacks and update our program every time new one comes out. All hack information needs to be stored inside the source which can make the program very big.

2. Using ReadProcessMemory to monitor the changes in well known memory offsets (hacks usually use the same offsets to achieve something). I would need to run a few hacks, monitor the behavior and get samples of hack behavior when comparing to normal run. The program would basically do the same thing hacks do but in reverse.

3. detect WriteProcessMemory call inside memory. I am not sure if this would bring some false positives from legit DLLs but idea seems interesting. How would I scan the process memory for this call? How to get the byte value of it?

This is an example of a hack call:

WriteProcessMemory(phandler,0xsomeoffset,&datatowrite,...);

The offset is actually fixed at least in low-level hacks. If we could somehow rearrange the stack or push it down somehow it could already mess up the hack to crash the game.

A few more facts:

1. new hacks are rarely published and there is a fixed number of those that are publicly available and actually work. Most of them also work in a similar way.
2. goal is to either detect the hack or confuse it from working

My question here is, what would be some good ways to achieve my goals here? Any idea that would confuse the hack or help to detect hack being injected or memory being changed is welcome.

I know there is NO WAY to have a 100% secure anti-hack system but if we catch only those who use publicly available hacks it is already 95% of hackers, we do not care about the minority of smart hackers.

Answer 1

I know you've mentioned this as inefficient and I completely agree, However surely you could run a timer of some sort and scan continuously for programs like cheat engine and tsearch :)

Here's another completely random idea: You could write a function to check a byte at an offset in your game and see if it matches the byte you want to be there, if it doesn't then you can call an event to shut the game down or to write the correct byte to that offset, Another option could be to check the bytes against bytes stored on a server and if the byte is different then the user is kicked.

Hope that gives you some ideas :)

Answer 2

Ooooohh I love questions like this.

Right, first up:

we are hosting a game server

Bam, there you go. If the client must send the state update back to the game server before this is pushed out to other clients, you have a chance to analyze the game state for changes. This means you can detect anomalous patterns. So for example, if you suddenly see a massive change of value in gold, you can then shut that user out of the game.

There's many statistical approaches you can take. Aside from the obvious "huge change" or "impossible action" you can apply more long term solutions - such as gold over time. Assuming I know about the "don't add massive amounts of gold to my character" trick I might increment gold in safe amounts over time. Great, if I always push the edge. However, that constant increase won't correlate with the equivalent gold earned in genuine consistent gameplay, so... again, detect and shut the account down.

The key here is that these are things you can do on the server side that the end user can do nothing about, even if they've manipulated the game state.

Now, onto your Win32 side questions. First up, I don't think WriteProcessMemory is a particularly valid call for any DLL to make, with the exception of debuggers (which will replace instructions in code - this is how breakpoints set by debuggers work), however, there's no way you can reliably replace this for every call on the system without writing what is effectively a rootkit - i.e. you'd affect everyone, not just yourself. So this isn't really an option.

One thing you could do - and it's no mean feat - is to periodically check your own executable memory for modification. For more, see Tamper Aware/Self Healing Code on codeproject. Basically, periodically invoke this and crash the game if you detect any modifications.

You might also consider code signing - it's not ridiculously expensive, and it does provide a built into windows way of preventing offline executable modifications.

If you store saved state locally, you might consider saving checksums and sending these to your server accounts. No, this is not bulletproof, but it adds extra complexity.

If you're going to implement any of these features, you're going to need to raise the barrier a bit and make it hard for the cracker to disable, skip or otherwise work around your protection mechanisms. Let's be clear - if someone is determined enough, you're done for, but you can at least make their lives very painful.

The top articule for anti reverse engineering on my reading list is also from code project. The guide is very thorough and should give you an excellent grounding in exactly what you can do to confuse and otherwise upset debuggers. I'll walk through one of them, which I think is fantastic:

 SetUnhandledExceptionFilter(UnhandledExcepFilter);
 __asm{xor eax, eax}
 __asm{div eax}

This is evil. Basically, as the article explains, the UnhandledExceptionHandler is called on a non-debug process as the handler of last resort; however, in this case we deliberately clear eax, then divide by zero. That'll cause a processor fault, which the OS then sends back to the executable's exception handler - only if there's a debugger attached. If there is a debugger attached, the debugger gets notified and the executable exits.

Of course, it is fairly easy for an attacker to replace div eax with one or more nop instructions or something, which means execution will just slide over, but a little self verification picks that up easily enough.

So, in conclusion then:

• My first advice would be to try to detect cheats on the server side. Here, you hold all the keys. You could even introduce these changes "dark", that is, check and see who is cheating, then analyse their states to see if it works, without cutting them off.
• Then, I'd attempt periodic self verification in several forms:
  • In memory, as much as is reliable, of the executable.
  • In memory, as much as is reliable, of critical data structures.
  • The executable on disk, too.
• Finally, I'd read that reverse engineering guide top to bottom - and see what you can apply to your executable. I realise you said you can't modify your executable, but honestly unless you do so, you're likely to be up against it. After all, a second "watcher process" can just be killed by an attacker.

Answer 3

For information on how to defeat chats to your games, I recommend the following article:

• How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It

It is an excellent overview of some of the challenges.

If you want more, you could take a look at the following book as well:

• Exploiting Online Games: Cheating Massively Distributed Systems, Greg Hoglund, Gary McGraw.

Answer 4

Would you make your own WriteProcessMemory function and link it to the game exe, and filter bogus calls? Or any other function you can intercept with some stream you can filter. Anyway, this is very advanced and you would need to provide all kernel32.dll calls or something like this. Basically you would really have to do it if you want to protect it somewhat from this, maybe some kind of filtering of the stream would help, but to find this out you would spend some time with the debugger looking for a moment when the command is decoded, so then you can fill it with zeros. SSL proxy would be good thing to have it separately as in EMAIL, so you got the message and before you deliver it, you run a scan check on it in separate process, and then deliver to mailbox on another account.