Ramblings++

Took a look at the latest build of WoWMimic yesterday. Yet again they claim to have made improvements to their “anti-detection methods”, and yet again I see little to no evidence of that. There really is only one word to describe the current state of WoWMimic and their attempts to fix their anti-warden stuff, and that is “failure”.

They have added another layer of obfuscation since the last build I looked at, but like all their obfuscation attempts their efforts are ultimately futile and it’s a 5 minute job at most to pull away all the crap and find the relevant code. What they did was simply add another level of indirection.

Simple explanation:

They use an INT3 (breakpoint) placed on the return address of the function they wish to hook, then they handle that exception in their vectored exception handler, but rather than go straight to their hook sub like previously, they now go to a block of code which raises a second interrupt. From there they handle that second interrupt and go to the hook sub. In short, all they’ve done is add another layer of indirection which is defeated by simply following flow from the exception address of that layer rather than the first layer. A very basic trick, obviously an amateur attempt.

Their hook on NtQueryVirtualMemory is STILL INSECURE. That’s right, after all this time they still can’t get it right. Sure, they fixed the hole that they got burned by in the last wave, but there are still at least 5 holes that I can see in that hook function alone, and 3 elsewhere. Plus, that’s only with a quick look! With an in-depth check I’m positive more could be uncovered.

Obviously I’m not going to tell them what all the holes are though, that would ruin the fun. But if I have some spare time this week I will write a new WardenMimic build, and we might just play a little game…

If anyone is interested, here is their latest code:

http://cypherjb.privatepaste.com/07090Hlmku

Thanks to Kynox for disassembling some misaligned bytes for me because I didn’t have a VM up and running at the time.

So, in summary:
WoWMimic is going in circles. It’s still just as detectable as it has been since day one. Every time they attempt to ‘fix’ one hole they end up opening up several more. It’s obvious their dev team have no idea what they’re doing. You’re free to waste your money on it, but imo you’re stupid for doing so, because at the end of the day you’re simply playing russian roulette with your accounts, and hey, you don’t need to throw money away to do that, there are plenty of free hacks you can use to get banned.

Update:

Oh, I have some advice for the Mimic team.

Rather than wasting all your time attempting (and failing) to obfuscate your code, why don’t you spend some time on actually implementing your anti-warden properly. Security by obscurity is stupid, because it only takes 5-10 minutes to undo what seems to take you guys days. The people you are up against (Blizzard) are not like you, they’re not amateurs. The Warden guy may be lazy, but he’s not stupid, so the only person’s time you’re wasting is your own.

Hades now has extension loading support! The API is still in the process of being exposed to the extension interface, but that should only take another 15 minutes or so to smooth out.

This is a great step forward because it means extensions can be loaded and unloaded on the fly without having to restart the process (as was the case when it was compiled as a static lib). Furthermore, it means that the modules are independent from changes to the Hades DLL and as long as no breaking interface changes are made should work with updated DLLs without the need for a recompile (as opposed to a static lib where a recompile is obviously necessary, or rather, a relink).

Naturally, both x86 and x64 are tested and working.

One issue I had with this was with the exposure of the interface. It seem that I can’t do what D3D does and do a C-style interface exposure because my interface is just too C++ heavy for me to be able to convert it to work that way. Not that it matters though, all the information exposed via exports is already available in the SDK.

Update (29/06/09):

Scratch that issue, got it working through some minor modifications and the magic of virtual functions! (Okay not magic, but it’s still a nice workaround.)

Yes I know I said I’d be looking at the new mimic build and I still will, but recently I’ve just been busy with more interesting stuff.

I added base .NET support to Hades (thanks Grey and Kynox for the help) . I improved the LUA support. I began adding event subscription support to LUA, I began adding event subscription and callback support to .NET, I continued the implementation of some D3D helper libs I was writing, and lastly, I began working on some random WoW stuff in order to test all the aforementioned things.

It’s just a ‘PVP mode’ ESP hack designed to make PvP just that little bit more unfair. (Thanks to Kynox for the camera/w2s stuff!)

Green is low risk (friendly), yellow is medium risk (hostile but not an immediate thread), red is high risk (hostile and an immediate threat).

Just finished adding the very first revision of LUA support to Hades. Currently it’s just a proof of concept, as all it does is load a LUA script which calls a custom function I’ve registered to print the arguments passed to the function to the console. Getting that first bit done and working though is the biggest hurdle, so with that finished I can now move on to writing proper code for it and exposing my whole API.

Both x86 (WoW) and x64 (HL2) builds are tested and working.

Finally fixed a bug that was causing flakey x64 support in Hades (well, the ‘bug’ was actually in HL2 it seems… but I digress). It finally works without issue in both HL2 (which worked in the first build but was flakey at time), and HL2 LC (which didn’t work for the first build). Unfortunately these are the only x64 games I can find the discs for. I’m hoping to get another copy of Crysis and UT 2k4 soon (both of which I have keys for but have lost the actual DVDs) which will allow me to test x64 more extensively, as well as D3D10 (on Crysis, for both x86 and x64), and also ensure Hades doesn’t break the x64 builds of SecuROM (because I had trouble originally with the x86 version before making some of my hooks a little less agressive).

Screenshots of Hades running in x64 builds of HL2 and HL2 LC:

Recently I’ve been doing a lot of bug fixes for Hades in order to increase compatiability with a number of Valve’s games. During this time I came across a bug that fixed a LOT of issues I was having. Currently Hades hooks SetWindowLong and SetWindowLongPtr in order to prevent the game subclassing the window and inserting a custom window procedure above the one owned by Hades. The reason this needs to be done is so that I can ensure Hades always gets ‘first dibs’ on input into the game.

I noticed though that this was causing problems with a number of Valve’s games. After reading over my code for a bit I came across the bug which was obvious in hindsight yet seemed innocent enough at the time. When implementing the hook I got a little lazy, and rather than subclassing only the window handles passed in by the D3D layer, I was just hooking ALL windows that were being passed into the API. Needless to say this is NOT a good idea and can cause great instability.

Low and behold as soon as I filtered it just to rendering windows the issues went away and a handful of games ‘magically’ started working properly.

Whilst I’m much too lazy to actually debug it to the point where I can work out which window was causing issues and why, it suffices to say that it’s probably a bad idea to hook any more windows than you actually need.

Screenshots of the newly supported games:

I just managed to get Hades working in native x64 mode, which is a huge step forward. Not even InnerSpace can do that at the moment. Currently I only have one game to test it on because I can’t find half my fucking game discs >.<. I’ll be getting my hands on some more x64 games soon though, so that should be good.

The game I currenly have and am testing is Half-Life 2. Below is a screenshot of the first working build. Please disregard the profanity, Kynox was trying to troll me on IRC about not being able to get it working, and pretty much just as he said that I did infact get it working .

I had some very minor issues porting the code over, but luckily (and surprisingly) I didn’t fuck up much at all so it nearly worked “out of the box”. Only took about 30 minutes to track down and fix the issues I was having.

Pretty much the only one that was an actual issue and not just caused by a typo, wrong datatype, etc was with hooking the window subclassing APIs. Don’t forget that SetWindowLongPtrA/W resolves to SetWindowLongA/W via a #define under x86, yet is an actual API of that name under x64. If you don’t explicitly handle that then you’ll be hooking the wrong API and you won’t be able to get subclass detection and rehooking working correctly (if at all).

Honestly I’m amazed at how easy it was to get working. Makes me wonder why the rest of the tools out there are lagging so far behind.

Anyway, I guess I’ll test this for a bit longer, fix any bugs I find, then move on to getting D3D10 working and stable.

Hey, as most of the people interested in the Mimic saga already know, a new version is out.  A bunch of people have contacted me to ask if I would be posting about it, so I figured I’d post an explanation as to why I may or may not be. Kynox has done a minor coverage of the update available here.

I may or may not do a full and in-depth coverage for three reasons:

1. I think it has been proven beyond doubt now that Mimic is indeed full of shit when it comes to their anti-anti-cheat code.
2. I think they have been given enough handouts for now.
3. Working on my new project is simply much more fun.

That being said, if I get bored I might take a look at the changes, but all I will be doing is documenting them, and pointing out whether it as a whole is still detectable. I will no longer be handing them free anti-warden ideas, they’re on their own now.

Bored, so I figured I’d post screenies of something I’m currently working on. It’s a generic game-hacking framework (similar to InnerSpace). It’s pretty much just for myself and very close friends for use on whatever game I feel like hacking at the time. I’m hoping to get a really awesome system in place by the time Blizzard release their next MMO. Which so far seems like it will be a while off, which is “good”, because as soon as that comes out I wanna tear it a new arsehole right from the get-go.

Work only really started this week, so progress is slow so far as most of the work is being done designing efficient and easy to use APIs. I’d rather spend a month or so getting the backbone right, then throw lots of features onto something shaky and have to go rewrite it and do 10x the work fixing up the dependencies later on.

Anyway, so far it supports D3D9 games, using both DirectInput and standard message based input. The only game I have that I currently can’t get it working on is HAWX. It renders but I can’t get input hooking in it working properly (though, that being said, InnerSpace doesn’t even render in HAWX, let alone get input, so I’m happy that I’m already +1 in that regard ).

The feature list I’m currently looking at implementing is:

• DLL injector supporting both CreateProcess (as suspended) and on-the-fly injection methods. Both x86 and x64. (Done.)
• CreateProcess injection style support for STEAM games. (x86 Done. x64 needs minor fixes due to STEAM being x86 and the x86 DLL not being able to boostrap the x64 injection code. Easy fix, I’m just lazy.)
• Injection “chaining”, so if you want to use CreateProcess style injection on a program that requries it be launched through a boostrapper — e.g. STEAM, Eve, etc — then the DLL will hook CreateProcess and automatically ‘chain’ injection until it hits the process you request. (Done.)
• D3D9 support. (Currently in RC)
• GUI system. (Currently in Alpha. Using CEGUI.)
• Generic event-based API for rendering, input, etc. (Currently in Alpha.)
• D3D10 support. (Currently in Alpha)
• D3D11 support. (Waiting on W7 and a D3D11 game to come out )
• x64 support. (Currently in Alpha)
• .NET support.
• Scripting for the command-line (LUA).
• Generic Anti-Anti-Cheat. (Currently in Beta. Tested and working against VAC2 and Warden.)
• Lots of generic helper APIs that can be applied to any game (pattern scanning, memory modification, code hooking, etc).

Before anyone gets the wrong idea though. This is a private project designed solely for my personal use. I am not interested in releasing this publicly, and as such very minimal (if any) code will be provided. The main reason I’m posting about this is because I instead wish to document any problems I come across while developing it, and how I solved them, in the hope that others may find the information useful, or even have a better way to solve the same problem.

Screenshots from the games I’ve tested so far:

Another WoWMimic build was released recently. I’ve reversed it yet again to bring you the gory details.

They’ve beefed up (by their standards) the obfuscation on this one. I put “by their standards” because they’re morons, and by the standards of any real reverser ‘beefed up’ is hardly the right term. It seems they’ve learned two new ‘tricks’, one they use once, another they use constantly. Both are very lame and very obvious and easy to undo though.

The first is this:

15DEBE67 | 5B            | POP     EBX                         | ; Pop address of current line into EBX

15DEBE68 | 81EB 471A4000 | SUB     EBX, 401A47                 | ; Subtract 401A47 from EBX (15DEBE67) (Final: 159EA420)

15DEBE6E | 8B83 F1194000 | MOV     EAX, DWORD PTR [EBX+4019F1] | ; Move 7CCAE98C into EAX

15DEBE74 | 35 8CE9CA7C   | XOR     EAX, 7CCAE98C               | ; Xor EAX (7CCAE98C) with 7CCAE98C. (Final: 0)

15DEBE79 | 8D8B C81A4000 | LEA     ECX, DWORD PTR [EBX+401AC8] | ; Move EBX (159EA420) + 401AC8 into ECX (Final: 15DEBEE8)

15DEBE7F | 8D0401        | LEA     EAX, DWORD PTR [ECX+EAX]    | ; Move ECX (15DEBEE8) + EAX (0) into EAX (Final: 15DEBEE8)

15DEBE82 | FFE0          | JMP     NEAR EAX                    | ; Jump NEAR to EAX (15DEBEE8). Another obfuscation attempt.

They have attempted to hide the jump address with some VERY basic math. Sorry guys, but you’re gonna have to do better than that.

Second trick:

; MimicVectoredHandler

15DEBE06 | 55            | PUSH    EBP       | ; Standard stack frame setup

15DEBE07 | 8BEC          | MOV     EBP, ESP  | ; Standard stack frame setup

15DEBE09 | 81C4 00FFFFFF | ADD     ESP, -100 | ; Sub ESP 100. Room for local variables

15DEBE0F | EB 50         | JMP     15DEBE61  | ; Jump over garbage and into an instruction. Obfuscation attempt.

; Original - Nice try… Not!

15DEBE60 | 2A60 E8 | SUB     AH, BYTE PTR [EAX-18] | ; Jump lands one byte into this instruction.

15DEBE63 | 0000    | ADD     BYTE PTR [EAX], AL    | ; Just reassemble the bytes to fix it.

15DEBE65 | 0000    | ADD     BYTE PTR [EAX], AL    | ; See below for one I prepared earlier!

; Fixed - Wow.. that was hard…

15DEBE61 | 60          | PUSHAD           | ; Preserve registers

15DEBE62 | EB 00000000 | CALL    15DCBE67 | ; Call next line

They’re attempting to confuse disassemblers by jumping into what seems to be the middle of an instruction. What they don’t seem to realize is that there are two very easy ways to undo this. One is to realign your disassembler for that chunk if it has that functionality. The other is to just dump out the bytes, assemble them externally (in OllyDbg or another tool that can assemble bytes into mnemonics), and just read from there.  Thanks to Nessox and Apoc for doing that for me because Olly was being a whore on my PC.  To put it simply, its no barrier to any reverser with half a brain.

Both obfuscation ‘techniques’ (if you can call them that) just reek of the work of an amateur. I still think they’re waiting for “one of china’s best hackers” to turn up for work.

As for actual changes to the implementation, there isn’t much, they seem to have wasted the last week or so on obfuscation which took them 1000x longer to write than it took me to reverse. Nevertheless, there is one notable change, which is to their ZwQueryVirtualMemory hook.

They no longer null out pMemoryBasicInformation->BaseAddress, but they have started nulling out pMemoryBasicInformation->RegionSize. The reason for this is both obvious and hilarious.

The previous build of WardenMimic (new one coming once I get some free time) worked by enumerating all regions of memory to look for the one that has been hidden. It is identified by detecting the unique return values which would never be returned in normal circumstances. Whilst the change breaks WardenMimic, it does so for all the wrong reasons. Not only do they obviously have no idea how a NtQueryVirtualMemory hook is actually supposed to work, they’ve fucked up and left another gaping hole AGAIN. That’s right, the hook is STILL detectable by Warden because the morons obviously don’t understand the first thing about Windows internals and virtual memory.

The rest of the APIs (GetCursorPos, SetCursorPos, NtGetContextThread) remain unhooked for the time being. (GetCursorPos and SetCursorPos still have the bug that was left there from the previous build.)

So, in summary, the changes are as followed:

• Had another crack at obfuscating their anti-detection code and failed hard.
• Attempted to fix their NtQueryVirtualMemory hook. Whilst they broke WardenMimic they fucked up their hook AGAIN and so Mimic is STILL DETECTABLE.

It’s pretty funny it took them this long just to push out such a simple new build. Really says something about either the quality of the developers or the quality of the customer service department. (Regardless though, the fail obfuscation attempts definitely say something about the developers. — In case you’re slow, its says they’re incompetent.)

Full code (with documentation) is available again. Anything marked as “Fixed” has been realigned so most of the obfuscation will not be apparent unless you reverse it yourself.

WoWMimic v50 Anti-Detection Code.