I agree. I have given up on Mimic peroid.
I agree. I have given up on Mimic peroid.
but but.....they have the BEST CHINESE GAME HACKER!
First, OOP scanning is 100% stealthable (but not 100% unblockable) from user mode (which is why a lot of the most paranoid folks stay OOP, despite how much more of a pain it is). It's a cat-and-mouse game, but until WoW goes kernel (or begins exploiting some of the privilege escalation loopholes in Windows), there are ways to 100% "jail" WoW from looking at other processes. E-peens aside, it is possible to completely block a process from accessing meaningful/useful info in another process' address space. Kernel drivers (on older Windows) can do this. Wine (on Linux) can do this. Heck, unless you use a privilege escalation hack, it's possible to almost completely stealth an OOP process in user mode just by running WoW as a restricted account (stealthing windows is harder due to Windows' insecure desktop design, but even there some common-sense precautions can help).
In-process is much trickier. Again, if you can get into the kernel you can (for the most part) "win" the arms race between developer and RE, but once you're in-process there are many, many more loopholes to close (as even the relatively simple module cloaker shows: forgetting to zero an init structure hint leaves you open).
Ultimately, it's not useful to talk about 100%'s -- nothing is 100% undetectable (I guarantee you), nor is any detection technology 100% reliable (again, I guarantee you). I don't really know this whole WoW Mimic kerfluffle, but if they were bragging about 100% stealth -- yeah, that's like waving a red flag before a bull.
There are what is called "class breaks" on an entire class of security methods that would render them theoretically useless. For instance, going kernel is a class break on using ZwQueryVirtualMemory, since it can be detoured in-kernel without any modifications to the user space at all. In effect that particular technique -- ZwQueryVirtualMemory -- becomes useless (of course this introduces OTHER detection techniques, such as scanning for kernel hooks, but that's not the point -- often those anti-anti-anti-RE methods are unreliable or prohibitively expensive/buggy/false-positive prone). The mem encryptor code I'm working on is a class break for a code-hashing attack by Warden, if my encryption is good (for instance, if I use a one-time pad as big as the code space, it is unbreakable even in theory). It leaves open other attack vectors (hashing on the call gate, for instance, or behavioral techniques such as looking for hidden memory blocks, etc.), but the actual hashing of code would have a crypto-secure class break. In other words, Warden could never use that particular anti-reversing method again (but -- and this is important -- ONLY that particular method; they could still hash common detours since the detours wouldn't be encrypted, or as I mentioned, they could hash the call gate).
A lot of what's going on in the "war" between RE's and Warden dev's very much parallels the arms race that's led to the increasing sophistication of computer virii; my idea of self-encryption is just stealing a proven technique from virus writers, and my idea of making the call gate metamorphic is another such virus technique. The reason I picked them is because they are proven class-breaks against signature scanning. Implementing them (correctly) would require Warden to work more towards heuristic and behavioral detection (which is much, much more complicated, as AV vendors have discovered, and which, frankly I doubt Blizzard is either capable or willing to do). Once code signature detection is class-broken, Warden's entire method of signature scanning will only ever catch script kiddies who don't know about the self-encrypting/decrypting PE techniques. (Note that there will still be an arms race on the metamorphic call gate).
So what this long-winded rant is getting towards is: security is not simple, whether you're implementing it, or breaking it. Ultimately, Warden will lose, since ultimately physical control of the machine will win the day (just running an ICE that does what you want would permanently class-break almost all of Warden, but almost nobody has this kind of equipment). But many people wil fall by the ban-bat in the meantime, since this is an arms race, and at certain times either "side" will (temporarily) have superiority. Bottom line is, if you can't take the heat -- the possibility of being detected at ANY time -- you shouldn't be in the sandbox. And people who don't understand security and OS internals well -- as Cypher demonstrated the Mimic folks DIDN'T -- shouldn't even be playing in the sand; they're likely to be early victims.
I do have one minor quibble with the prevailing sentiment, however. If botting is itself morally objectionable, then why would anyone be on a public forum devoted to helping folks write bots? I mean that's like saying "drugs are evil, but I'm going to manufacture and distribute information on manufacturing bathtub LSD." Teensy bit of a conflict there.
Me, I don't think bots are in any way immoral (or I wouldn't be on the forum). I just think they're against Blizz's rules (different thing entirely), and know that I always risk detection when I run my little penny-ante bots. But then again, I'm not stupid enough to a) distribute my bot publicly and b) then claim it's "completely undetectable." That's just dumb...
Last edited by amadmonk; 05-20-2009 at 03:57 PM.
Aamen.
In my country we have and old proverb. "Made the law, made the hole" - Well translations never are as cool as orginals, but still have the same point. Each time someone develops an anti cheat, you can develop an anti anti cheat... and so on. As amadmonk sed lets hope that by having direct controll of the machine, RCEs should have an advantage over DEVs
(Note: not full machine control unless your are on linux + wine thou)
"I'm not going to expose my methods for time bending, as i don't want to do get nerfed!"-Kynox
Today is awesome. I'm loving the fact that all the Mimic idiots have to eat their own words.
So it's updated and detected? daaaaaaaaaamn
@amadmonk:
Isn't kernel-mode programming a little bit dead since patchguard came to be? They fixed the bug where you could overwrite the paging files, or at least that's what I read. Are there other ways? Or can you still load w/e you want if you disable driver signing, and I'm just misunderstanding what it does. Does it just check if you're using ssdt hooks or detouring ntdll funcs?
Last edited by lanman92; 05-20-2009 at 10:33 PM.
Disabling signing doesn't disable KPP. Also, KPP does a lot more than just look for SSDT hooks. Also, NTDLL is a usermode component.
EasyHook has a KPP bypass, but all the public bypasses always get patched, so don't rely on them.
EasyHook - The reinvention of Windows API Hooking - Home
You sound like you have a few private ones :P I might just install a VM with WinXP 32-bit and see if I can get some fireworks, though. Either that or...wine...
They have it down decently last time I checked. They just have issues with DInput. You can't use the mouse to turn if you're in vmware using DX. I used glider in my VM and it worked pretty well actually. Forgot the pass to that VM... rofl. Have you worked with Wine at all? I'd hate to make my own tools, but that might actually be pretty cool.