Ramblings++

I’m curious, what disassembler do you use? Maybe i’m wrong, but I get the impression that you only use OllyDBG in specific situations.

well, i must say that i am impressed that you took the time to reverse this mess of work /’calling mimic ‘work’ is an OVER-statement’\ you must have been very bored. Ive reversed the past build only to find a nasty coded bot, that compares to the china iphone fake… *peice of shit!* .. By looking at mimics source , only a few things come to mind… Ethier, the cheaply paid devs. /if u can call them that\ dont give 2 fucks bout their users and purposly lie about *fixing* mimic , OR they truely are as ignorant and un-educated as they seem to reversers like myself… In my opinion , its all of the above, they dont give a shit AND are ignorant… Id like to hear your true opinion on this subject cypher… Also ive got an idea that will destroy mimic for good…. Let me know if your interested. -kam

Hey, Cypher… I’ve been luring/reading these a while… Just wondering, with all the free time you’ve got, when should we (the public) be expecting your bot to be coded, tested, and released?

@Cypher
I think he was trying for sarcasm, but it’s hard to tell with that one.

So, regarding the jump to the middle of an instruction “obfuscation,” as sad as it is, this is pretty much the state of the art in x86 instruction-level obfuscation; this is what most VX devs still use. It’s not intended to completely prevent reversing. The only point of the jump-into-an-instruction thing is to slightly slow down a newbie reverser; because most disassemblers won’t handle this gracefully without a little nudging, it can derail the noob. Anybody with any experience reversing malware will see through it immediately, of course.

I think the Mimic devs — all epeen flexing aside — would be better to focus on defeating the WoW devs, not trying to be “uber hackers.” Make their code metamorphic (obviously, they’re halfway there since they’re looking at VX techniques) and they’ll pretty much make signature-hashing impossible. Don’t try to make the code unreversible (since that will never happen), just try to make it so that *Warden can’t hash against it*, and they’ve won the battle (until Warden is updated to use heuristic scanning in addition to the proven-broken signature scanning).

I tell you, this whole thing is shaping up to be virus writers vs. antivirus companies, all over again, except that the clock has been rolled back to about 1995 or so.

Oh, one correction. I didn’t want to imply that jump-into-instruction is state of the art in VX writing (it’s not, by a long shot). But for the express purposes of slowing down an automated disassembly, it’s about the best you can get without self-encrypting code.

@Cypherjb

I guess that makes sense. I think that if the Warden guys are at all competent it’s going to come down to plausible deniability (in other words, inter-modular calls are going to be fair game, intra-modular calls are going to be unsafe).

Has anyone explored carving a code-cave out of WoW’s .text segment? Or you could sneak a hook table into the PE header or something unused (just sort of wrap it around the loaded module lists, or something). Just something so that fn calls look like they’re “coming from” (or “going to” a location inside WoW itself). Of course, that would only work until Warden starts hashing every byte of the binary, or even just the particular function you’re hooking…

@Cypherjb

The more I think about it, the more I start to think that Lax’s technique (just counter each individual Warden module as it shows up, and kill the app if an unknown module appears). Then you don’t have to worry about “what if’s,” you can just implement code and fool Warden into saying that the code is good.

Seeing as how we have physical control of the box and access to every bit of binary/net traffic on it, that should work — in theory — even though it’s a lot of work.

er… last comment should be “Lax’s technique is a good one”

Hi, interest post. I’ll write you later about few questions!

No. There was no sarcasm involved. He showed exactly what I suspected: He can criticize the shit out of what they do… but he can actually program no better. If he can program a more secure bot, he’s not the fortitude to sell it as the programers of WowMimic do. In other words… he’s another 18 year old kid without the balls to do a damn’d thing but whine. Cry cry, as you do nothing, boy.

@amadmonk

I completely emulate Warden (on the packet level) and do exactly as you said. It really isn’t as simple as you might think. With every update (and patch), you’re required to sit down for hours and check for changes and update various modules of the emulator.

For instance, i need to update all my hashes of client files and memory offsets to return the clean values.

@Cypherjb

Bah. I was sort of thinking about that on the way home from work; how the big weakness of Warden is that it’s a single point of attack. Once they start weaving aspects of its code into other code (like the masquerading attack you mention), things get sticky.

@kynox

Hmm. How many “types of things” do you need to hash? The last I looked at the list of known checks, it was just a dozen or so offsets. I can see how you’d need to stay on top of the changes in Warden, but how often does some IAT entry change?

Actually… thinking about how I’d implement Warden, lemme guess: the key they use to hash with changes dynamically, so that with each update to Warden you have to rehash with the new key.

Bah. Nothing’s easy.

@amadmonk
Polymorphism in every cranny you can think of.

When i meant updating hashes, i meant all the client files it hashes, all the offsets it checks, etc. In a way, it’s nice having to do it because you end up easily noticing if anything new was added.

@Cypherjb
I was a longtime user of Innerspace and ISXWow. I thought when Lax stopped releasing ISXWarden, the ISXWow project all but vanished? The forums are dead, and one person updated it a month ago, but isn’t safe to use. I asked him. It is too bad really, because I really miss the functionality and universal scripting of the bots, and combat assist routines I made.

From what I can tell, Mimic, even though detectable is the closest thing out there to what I used to be able to do. I am not a programmer, so maybe I am offbase here.

Hmm. Thinking about the “on-the-wire” Warden em. You’d have to keep a man-in-the-middle encryption proxy going, I assume (so you can drop packets or send extra packets). Then you’d intercept the SMSG_WARDEN_DATA packets and send the “clean” CMSG_WARDEN_DATA packets back? Does the hash key/seed/whatever vary dynamically, or only by patch?

It does seem like a lot of work, but it also seems like most of the work is up front; once you know what to hash and what data to use to hash it, you can write a little script or something to re-hash known data (offsets, files, whatever — that was where I was going with the “how many kinds of things do you need to hash” question) when something changes.

I like your technique, a lot. It completely eliminates the need for something like binary self-encryption. It wouldn’t do anything to prevent so-called “cock blocking” (nice term, btw, Cypher) but once you’re not worried about consistency checks you can just block the cock blockers and you’re set.

Hmm… I think it’s time for me to start actively looking at those SMSG_WARDEN_DATA packets (and responses)…

Now, how would you handle the “hijacked opcode” issue… you’d have to have some at least semi-deterministic way of finding out if an opcode received led to the code path that it “should” be running. Otherwise you’d have to distinctly handle every known opcode (and that would be an insanely huge amount of work).

@amadmonk, you should have a look at http://sharesource.org/project/sniffitzt/ ,this programm can intercept and decrypt the wowtraffic and knows how to find the “key” used for encryption.
Might be useful