1

The Problem

I'm attaching a game's process to view/edit my ammo. I've reversed a few games and understand x86 assembly; however, I'm new to the whole anti-debuggers and memory scanning bit. I have searched for resources on how to combat this issue, but still have found nothing. Whenever I attach to the game it still works, but as soon as I change a single instruction it's as if the application "scans" it and detects my change, thus causing a crash. Also, sometimes if I happen to "bypass" the detection, the anti-cheat always finds a way to kick me out.

I've read about a few functions that some programs may use, but none of them have really seemed to help.

Questions

  1. What do these games/applications use to detect this?
  2. Is there a way to avoid this detection?
Community
  • 1
iScott
  • 21
  • 1
  • 3
  • Possible duplicate of http://reverseengineering.stackexchange.com/questions/3658/what-ways-is-there-for-an-application-to-detect-that-it-has-been-modified/3661#3661 ? – Guntram Blohm Aug 09 '14 at 21:25
  • 2
    Are you sure it's the anticheat thats crashing the app, instead of you messing at the wrong place in memory? Since you didn't mention which AC is this, I'ld recommend you googling for "warden" and "punk buster" and check game hacking sites for more info on them to get a basic understanding how they work. – Dominik Antal Aug 09 '14 at 22:18

2 Answers2

2

Regarding the questions:

  1. Applications are reading code memory and computing checksums. If checksum not matches predefined value - applications act accordingly.
  2. There is no general and easy explainable way to avoid such kind of detection. The most common point of such action is patching the code that checks the checksum.

In your case I'd try to protect the changed memory from reading (by calling VirtualProtect from injected dll for example) or create breakpoint on reading memory on changed area and check the area of code where changed memory reading will occur - this will be the place where the changed code is read. You'll need either recalculate the checksum with your new changed code or nopify the code that is responsible for incorrect checksum reaction.

Please note that the checksuming code you'll need to change may be also protected in the same manner.

w s
  • 8,458
  • 1
  • 24
  • 40
1

First, there's no perfect solution. An application running on a computer is subject to all kinds of manipulation. All you can do is take a few reasonable steps to prevent most cheating and manipulation of the client by people who aren't willing to spend enough resources to figure out how to circumvent your anti-cheating measures.

A few steps you can take include:

  1. Obfuscate the binary by randomizing the linker. This way, any in-memory hacks change every time you push a new version.

  2. Embed a secret key in the client. Check for the correct key every time you connect to a client.

  3. Obfuscate memory. Have a set of randomized XOR pads for each memory structure, making it harder for an in-memory hacker to determine how to manipulate memory.

  4. Checksum. For each structure, store a checksum of all values which is periodically verified.

  5. Constraint validation. For any constrained values, double check them every time they are used for sane values, preferably on the server.

  6. Log and ban. Log any suspicious behavior and immediately ban the user. Ultimately this is your best deterrent to cheating.

Jeff-Inventor ChromeOS
  • 140
  • 4