[Question] Defeating DMA, with anti hack system present

[Smellfeit]

My (nooby) question: Is there a way to "defeat" Dynamic Memory Allocation of a game(find ptr & offsets), without using breakpoints and obvious ASCII names in IDA Pro?

The game i want to read memory from has a pretty awful anti hack system that I cannot defeat, and the game will shut down immediately when IDA Pro is run at the same time as the game(same for Olly Dbg etc.).

And I cannot find any useful Ascii strings in IDA Pro, because game code is originally korean(and names nonsense). I have korean language support, but IDA Pro doesn't recognize this(or the names are like that with support).

And yes, I have searched the forums.. :happysad:

Edit:

So, debuging is blocked.

I've tried to find a solution myself (ofc.), but so far the only options I've come up with are:

1. Get/make bypass (I have no experience with bypasses so i think this will be too hard).

2. Scan interesting (dynamically allocated) chunks in memory when game is running with an undetected memory scanner, find useful structures. Then later implement a memory scanner into bot, and make user type in enough info to be certain that you can find the structure in memory the next time memory is dynamically allocated(usually just 2 things are need to find larger structure, like name and current hp- with a fixed offset that i have observed when looking at interesting chunks).

Using 2.(with C#) now, but I'd love to get my hands/eyes on that ptr :brittish:.

(shameless repost of a two week old unanswered thread that I made in the programming section, because I could really use those twocents)

Answers>Questions>Flaming. HAND

[Cypher]

Lol what??

[r00tman]

How about renaming the windows/processes ?

[caytchen]

You know, the thing about IDA is, it is mostly a tool for static analysis. Means it doesn't require you to run the program. It does bring a semi decent support for various debuggers, though, should it be necessary.

[Cypher]

Okay, upon rereading this I've been able to decipher some more ofi t, lol.

Have you tried changing the string type in IDA to Unicode? The reason the strings may not be coming up is that they're Unicode when you've got it set to ASCII.

Also, what do you mean debugging is blocked? Are you able to attach WinDbg or w/e and use it? Or does the game kick you?

[bind]

What game shield variant is the game using? There's several ways to defeat these "anti-hack" shields.

There's no such thing as "Debugging is blocked", you just don't understand how to defeat the mechanic in place preventing you from otherwise successfully debugging the application. In my 20+ years as a developer I've yet to come across an application that's impossible to debug.

Also, "The game i want to read memory from has a pretty awful anti hack system that I cannot defeat", if it's so awful why are you having difficulties?

Some of the more common anti-hack shields do very simple checks for process memory read / writes and hash checks against the executable and dependencies to make sure they haven't been altered upon load. while it's not practical to attach a layer to the game that constantly scans these alterations / queries, they are often quite easy to get around. Some of them only scan for these alterations "On load", bypassing these routines is trivial most of the time. In a case where you are dealing with Hackshield or Gameguard, they do proactive scanning but have still been defeated. I personally can't think of one of these anti-hack shields that hasn't been defeated, do some research on the target, it will pay off.

A lot of "anti-hack" mechanics implemented in games use the IsDebuggerPresent API and based on that throw a routine to disconnect the client, exit the game, etc. If you don't know what's actually causing the client to disconnect or exit, try step tracing through the executable, prevent it from hitting that call. All of this is stupidly easy to do and if you need in depth information on debugging, pay tuts4you.com a visit.

Try loading the application in Olly and before running the application, search for "All intermodular calls" and look for the IsDebuggerPresent call. This is the most common way of finding debuggers but not the ONLY method used for detecting debuggers. For additional information on these methods, visit the following post: http://www.symantec.com/connect/arti...ebug-reference

In addition to that link if you search Google for "Anti Debugging Routines", you'll find several "White paper" information on various routines commonly used to thwart debugging.

Also do you know if the game itself is the issue or perhaps a dependency? Not always are these anti-hack routines built into the executable, they are often in a .dll, again step tracing through the application will allow you to find where the culprit segment of code is located. I'd also suggest using Dependency walker.

Have you tried using Olly with one of the "Stealth" plug-ins? it does several things to hide the presence of the debugger. IE: renaming the window, process name...

I personally use the Defixed and the SnD editions of Olly you can find them both on tuts4you.com or on Google, it has several of those stealth plug-ins installed out of the box.

If you're lazy which judging from your post you are (no offense), the names of the plug-ins are: "Hide Olly", "Olly Invisible", "Hide Debugger", or my personal favorite which has all-in-one options is "Olly Advanced"

Your best bet is to do some more research on the application itself, regardless if the strings are in Korean or not, that won't prevent you from step tracing through the application and gaining valuable information on how the client works. It's just in some circumstances with a game, a bit time consuming.

In my personal opinion, as a developer who dabbles in the reverse engineering community, it's crucial to understand how packers, obfuscation, crypto, anti-debugging routines, work. By educating yourself on those topics, and fundamentally understanding how applications work from the core level, you'll find yourself better able to handle these circumstances you'll quite often come across in the field. Understanding debugging is crucial as a developer. Also if you're not currently savvy on the subject, learning ASM will also vastly assist you in the reverse engineering community as it comes hand in hand with debugging compiled code.

Now that you've been spoon fed a bit, happy debugging

[Smellfeit]

How about renaming the windows/processes ?

The anti hack system detects it still, in my experience.

You know, the thing about IDA is, it is mostly a tool for static analysis. Means it doesn't require you to run the program. It does bring a semi decent support for various debuggers, though, should it be necessary.

Yeah, I can do static analysis (with some strings now, see reply below).

Okay, upon rereading this I've been able to decipher some more ofi t, lol.

Have you tried changing the string type in IDA to Unicode? The reason the strings may not be coming up is that they're Unicode when you've got it set to ASCII.

Also, what do you mean debugging is blocked? Are you able to attach WinDbg or w/e and use it? Or does the game kick you?

Thanks for reading it twice, lol. I checked Unicode previously, but did it again just to be sure. Seems like I did something wrong last time, because now it worked- and I get to feel like an idiot.

What game shield variant is the game using? There's several ways to defeat these "anti-hack" shields.

Hackshield Pro: HackShield - Hacking Prevention Solutions For Online Games

There's no such thing as "Debugging is blocked", you just don't understand how to defeat the mechanic in place preventing you from otherwise successfully debugging the application. In my 20+ years as a developer I've yet to come across an application that's impossible to debug.

I dont' know if it was intended this way, but this was pretty motivating.

Also, "The game i want to read memory from has a pretty awful anti hack system that I cannot defeat", if it's so awful why are you having difficulties?

[ sarcasm ]I'm sorry for not having English as my first language [ /sarcasm ]

Some of the more common anti-hack shields do very simple checks for process memory read / writes and hash checks against the executable and dependencies to make sure they haven't been altered upon load. while it's not practical to attach a layer to the game that constantly scans these alterations / queries, they are often quite easy to get around. Some of them only scan for these alterations "On load", bypassing these routines is trivial most of the time. In a case where you are dealing with Hackshield or Gameguard, they do proactive scanning but have still been defeated.

Hackshield Pro is (partially?) incorporated into the game, and does a kernel hook to monitor/block certain fuctions(like sendkeys etc.), so in the long run I want to learn how to bypass stuff like this. One of the simplest solutions may be a VM..

I personally can't think of one of these anti-hack shields that hasn't been defeated, do some research on the target, it will pay off.

A lot of "anti-hack" mechanics implemented in games use the IsDebuggerPresent API and based on that throw a routine to disconnect the client, exit the game, etc. If you don't know what's actually causing the client to disconnect or exit, try step tracing through the executable, prevent it from hitting that call. All of this is stupidly easy to do and if you need in depth information on debugging, pay tuts4you.com a visit.

I will use link, thanks. As is now, the game is run via. a activeX+flash based weblauncher that send a MD5 Hash, that contains password, something related to time(cant start game if one waits too long after loging in @ webpage), maybe something else, and probably salt. So in order to debug, I'll atleast need to circumvent IsDebuggerPresent API and the like + game check if game is run via. launcher(that terminates game if not).

Try loading the application in Olly and before running the application, search for "All intermodular calls" and look for the IsDebuggerPresent call. This is the most common way of finding debuggers but not the ONLY method used for detecting debuggers. For additional information on these methods, visit the following post: Windows Anti-Debug Reference | Symantec Connect

In addition to that link if you search Google for "Anti Debugging Routines", you'll find several "White paper" information on various routines commonly used to thwart debugging.

I will try this when I can find the time. The symantec link was pretty informative, thanks.

Also do you know if the game itself is the issue or perhaps a dependency? Not always are these anti-hack routines built into the executable, they are often in a .dll, again step tracing through the application will allow you to find where the culprit segment of code is located. I'd also suggest using Dependency walker.

I assume that it's .dll based since gamefolder contains /HShield with many .dlls (V3Hunt.dll for instance).

Have you tried using Olly with one of the "Stealth" plug-ins? it does several things to hide the presence of the debugger. IE: renaming the window, process name...

I personally use the Defixed and the SnD editions of Olly you can find them both on tuts4you.com or on Google, it has several of those stealth plug-ins installed out of the box.

I'll try this, although similar attempts made by me have failed .

If you're lazy which judging from your post you are (no offense), the names of the plug-ins are: "Hide Olly", "Olly Invisible", "Hide Debugger", or my personal favorite which has all-in-one options is "Olly Advanced"

I am indeed lazy, maximum output for minimum input.

Your best bet is to do some more research on the application itself, regardless if the strings are in Korean or not, that won't prevent you from step tracing through the application and gaining valuable information on how the client works. It's just in some circumstances with a game, a bit time consuming.


In my personal opinion, as a developer who dabbles in the reverse engineering community, it's crucial to understand how packers, obfuscation, crypto, anti-debugging routines, work. By educating yourself on those topics, and fundamentally understanding how applications work from the core level, you'll find yourself better able to handle these circumstances you'll quite often come across in the field. Understanding debugging is crucial as a developer. Also if you're not currently savvy on the subject, learning ASM will also vastly assist you in the reverse engineering community as it comes hand in hand with debugging compiled code.

Now that you've been spoon fed a bit, happy debugging

Will do..

On a side note: I provided minimal info to get a general answer, so this could be of some use to others searching forum(and not just for a specific anti hack)- which seems to have yielded results . Thanks and +Rep to you Bind! Also thanks to you others.

Warning, incoming flame below