5 replies to this topic

[RobotGymnast]

My friend is working on a hack protection DLL for a specific game, which has been hacked into oblivion (especially in private servers).

I've been looking into essentially the opposite: creating a variety of hacks compiled together from all the other hack methods that have been attempted on the game, so that he once he can block those completely, the hack protection can be sold to servers without hack protection.

Now, I've been looking into a variety of methods. What I have are:

• Packet editing
  
• Changing flags when a memory location is reached
  
• Code segment editing/code injection
  
• Data segment modification
  
• API hooks
  
• Resource/file modification

First of all, information on how any of these can be done would be useful. Next, prevention/detection methods would be greatly appreciated. Some have already been blocked, by

• File checksums
  
• Code segment checksums
  
• Packet/file encryption (already built into the game)
  
• Return address checking ([ESP or EBP+4] is the function return address)

Preferably, we'd like to be able to block OpenProcess opening the process, as well as preventing thread creation (although, because the DLL itself creates threads, this will be difficult).

Help as to the aforementioned hack methods, or preventions thereof, would be helpful.

Thank you.

[dargueta]

1) Packet spoofing - Requires you to either use a library (don't ask me which one, I don't know, I just know they exist) or make your own API for low-level writing to the network card. That way you can circumvent the network drivers that'll form the packets correctly.

2) Changing flags when a memory location is reached - Going to be difficult...I thought that was a kernel-level thing. As far as I know you'd need to set your own interrupt vector and mess with CR0 (or maybe CR1), something most operating systems will block. If it doesn't then that's a huge security hole in the system.

3) Code segment editing/code injection: There are typically OS-level blocks against this. You'll probably need to run with elevated privileges or find a way to disable DEP.
Writing Self-Modifying Code for Windows

4) Data segment modification - Use pointers? :) Your DLL will be part of the application's address space, so you can modify the data anyway.

5) API hooks - Depends on what API and what OS. On Windows, some can be hooked with application-level hooking functions; others must be hooked at the driver level. You could also try modifying addresses in the import address table at runtime to point to your own functions.
CodeProject: API Hooking Revealed
API Spying Techniques for Windows 9x/NT/2000
Techniques of Hooking Windows API Functions (Claims to work on NT 4.0-based systems & higher, so that'll include XP, maybe not Vista.)

6) Resource/file modification: Resource modification isn't that difficult, just annoying as hell.
MSDN - Using Resources
MSDN - Adding, Deleting, and Replacing Resources

[RobotGymnast]

Thanks. Kernel-level control seems to be required (and would be good experienced anyway). Unfortunately, my friend doesn't want to go through the work of writing a kernel-level defence system ><.

However, editing the code segment is actually quite easy; there's a function to disable the code segment protection (it seems to be there to protect the programmer, not the system).

[dargueta]

Yeah...though I think anyone who's writing a ring 1 or 2 device driver to beat a game needs to find a new hobby. There's an API to disable code seg protection? Do tell...I may find that useful.

[RobotGymnast]

Cheat Engine's genius because it uses one driver for ALL games.. it's really amazing.
Yeah, he's one person, and writing a driver for a hack protection program is a bit over his head (not being graduated from high school).

Yeah, when I was talking about data segment modification, I only needed to know protection; writing is rather simple =P.

Apparently; my friend's been using it to patch code segment memory. It's the VirtualProtect function. His usage is:

...
VirtualProtect(_Dst, patchSize, PAGE_EXECUTE_READWRITE, &ulOldProtect);
FlushInstructionCache(currentProcess, _Dst, patchSize);
memcpy_s(_Dst, patchSize, _Src, patchSize);
VirtualProtect(_Dst, patchSize, ulOldProtect, &ulOldProtect);
...

Also see the VirtualProtect function at MSDN

[dargueta]

I've seen VirtualProtect(), but never FlushInstructionCache(). That's a new one to me. Thanks for the code!

As far as protecting the data segment, if you don't care about performance, you could use VirtualProtect() to make the segment unreadable and then unlock/lock it as necessary. Other than that, I can't think of a way to prevent drivers and loaded DLLs from accessing your data.

Edited by dargueta, 14 August 2009 - 05:57 PM.
Typo