@ Warden Dev

[Cypher]

=[
more hand leveling for me, i suppose.

Protip: Noone here cares.

[kynox]

So you're essentially tipping blizzard off so they catch alot of people who are botting?

Haha, **** you.

Clearly not trying to help the community, obviously doing it to get other botters out of the picture to keep your own botting monopoly?

Do you also report other botters?

Funny. Could have sworn i put "PTR" in the topic. OH! I did, you are just too retarded to read.

Did it not occur to you that if Mimic even cared about their user base that they would take this warning and step up their protection?

You are pinnacle of retarded child births.

[amadmonk]

So, an actual technical question:

Warden was hashing RVA's? Of what? IAT?

Regardless of what it is, this seems transparently, laughably thin; your RVA's might well change with a recompile.

Now that I've given up on trying to make Darawk's old ManualMap code work and have come back to the lightside of simple IAT/EAT patching in my private bot, anything that includes the term RVA pricks up my ears.

Yes, I said pricks.

[Cypher]

So, an actual technical question:

Warden was hashing RVA's? Of what? IAT?

Regardless of what it is, this seems transparently, laughably thin; your RVA's might well change with a recompile.

Now that I've given up on trying to make Darawk's old ManualMap code work and have come back to the lightside of simple IAT/EAT patching in my private bot, anything that includes the term RVA pricks up my ears.

Yes, I said pricks.

I'm considering rewriting ManualMap to work on x86 and x64, and also on the latest versions of windows (and remove all the bugs and memory leaks in the process). Where di you get stuck?

I'm doing IAT/EAT patching in my generic anti-anti-cheat library, and theres problems you'll face there too if you're writing generic code that you want to be as hard as possible to bypass (simple IAT/EAT hooks on their own are very easy to defeat).

[amadmonk]

Mm well, the semi-working code is on my work system (forgot to svn up it before I left today), but from what I remember, I was chasing down trap after trap due to things like uninitialized data sections not quite conforming to Darawk's original code (thank you .textbss!) and so on. Also lots of bugs and mem leaks, as you mention. The thing is that there are so many linker- and compiler-specific ways that PE's can be generated that even just the small subset of different kinds of DLL's I messed with was becoming a pain -- I was spending hours poring through MSDN to try to understand why particular fields were set certain ways in some instances, but not in other instances.

I finally realized that the only real benefit of manual mapping was to bypass the LoadLib call, since the other benefit (keeping it out of the PEB LDR chains) could be achieved by simply unlinking it (and zeroing some mem, and so forth). In other words: a lot of work for little gain. Interesting learning experience, if you're dying to know the gory details of PE's, but... not really worth it from a big picture perspective. IMO.

When you say IAT/EAT hooks are easy to bypass, what specifically do you mean? I know that (unless I shim in before wow.exe runs) the app can always do GetProcAddress and save an addres before I can inject. However, from what I've seen, they use the standard inter-modular call for the most part. I also know that IAT/EAT hooks are fairly easy to detect, since you can just look for an RVA that would put you outside of the module's section, and that's a clear patch (although nothing says you couldn't put a code cave INSIDE the code of the section). However, from what I understood of Warden, it's not checking that (although this RVA hashing thing has me curious) -- which makes sense since there are AFAIK a number of legitimate tools that hook the IAT.

So, can you be more specific? I know that Warden could just patch back the IAT/EAT when it runs, and that would definitely undo the hooks. Guess we should distinguish between bypassing A-A-C's and detecting/banning for them (which gets back to plausible deniability and Blizzard's willingness to possibly mass-ban thousands of antivirus users/rootkit victims/whatever).

I really don't want to have to go back to a detours-style system of hooking, since raw ASM mixed with C (or esp. C++) just makes me squidgy. I lost a precious hour of my life today figuring out and fixing the calling convention for D3D::EndScene (wtf is the calling convention called when there are no formal parameters per MSDN, but ecx is set ala thiscall, and one param (which looks like the this pointer) is pushed onto the stack? I've never seen that before :yuck I don't care if Blizz can eventually UNDO my hooks, as long as they're not going to ban for them (within reasonable probability, of course).

Ugh. I'm tired. Spent too long working on my IAT hook mgr class. I sleep now.

[Cypher]

You can't actually just look for pointers outside the module boundary, Vista itself does IAT hooking for its Compatiability layer, you could have malware, you could be using aggressive AV software, etc.

I'm not talking about banning for hooks in my post, but bypassing them.

Holes you need to plug (with notation of the ones I've plugged in my lib so far):
1. Calling the NT API when you're only hooking the Win32 API. <-- Fixed. Always hooking all possible control paths, or at the very least, all of the lowest control paths.
2. A direct SYSCALL into the kernel. <-- Impossible to hook from usermode.
3. Enumerating the EAT manually for a module. Assuming you're only doing IAT hooks. <-- Fixed. Also hook the EAT.
4. Enumerating the IAT or EAT manually on disk. <-- Currently in the process of fixing. Hooking file reading APIs and preserving the 'hooked' RVA on disk.
5. Cached function pointers that are from before you injected. <-- Partially fixed. Currently I scan static memory in the primary module. Next on the list is all secondary modules, and all heaps in the process. Obviously impossible to catch obfuscated pointers that are cached before injection.

My library is designed for x64 as well as x86 so inline hooking is not something I want to do (because of the need for a runtime disassembler, threading issues, etc, which all do not exist when using IAT/EAT hooks).

Blizzard are never going to ban you for your hooks (assuming you stay private, because once you're public they can hash your hook and ban for it), but whats the point if its really easy to bypass without any prior knowledge of the target? (i.e. shit you'd do anyway "just to catch out the unprepared")

P.S. You can bypass LoadLibrary if you use the NT API (which is more difficult to do). That itself is obviously still hookable, but you're more likely to catch less-sophisticated monitoring attempts off-guard. In terms of undetectability by things like AC software and AV software, bypassing LoadLibrary is a huge plus (albeit very difficult to do 'correctly').

[UnknOwned]

But then again, who would care about WoWMimic?

I love their advertising:
"Kreate Confiker, Sæt Clas Tajp. In Tæxt sættin set patra...
Setting ingame, helthy potin and mana potin in slot fire and six off shift and 2, water in subtraktin slime.."

[LegacyAX]

if you unpack wow mimic (themida) you will see how poorly coded it was ... >_>

Its a wonder why it takes up 80% CPU, and the GUI is VERY unresponsive... It really bugs me when you click a button and 10 hours later the event fires...

Plus the GUI controls are overlapping.. Like wtf? Fix that shit lazy ass..

[amadmonk]

You can't actually just look for pointers outside the module boundary, Vista itself does IAT hooking for its Compatiability layer, you could have malware, you could be using aggressive AV software, etc.

Ahh, good. Plausible deniability Since I never plan to release my code, they should never be able to build up a hash for the banbat.

I'm not talking about banning for hooks in my post, but bypassing them.

Holes you need to plug (with notation of the ones I've plugged in my lib so far):
1. Calling the NT API when you're only hooking the Win32 API. <-- Fixed. Always hooking all possible control paths, or at the very least, all of the lowest control paths.

Done that. It's not too hard to trace the API and see what lower-level syscalls are being made, although there are a surprisingly huge number of vectors of attack (what if they try blind pid opens instead of a toolhelp/NtQIP attack, etc.). I mean you're never 100% confident, but given their laxness, I think I've got my butt covered. It would be cool to enumerate the possible attack/response vectors on here sometime, but then Apoc would probably call me a retard again. I'm such a sensitive boy.

2. A direct SYSCALL into the kernel. <-- Impossible to hook from usermode.

Yeah, given how little work they do right now, I really don't see this happening.

3. Enumerating the EAT manually for a module. Assuming you're only doing IAT hooks. <-- Fixed. Also hook the EAT.

Check. I hook the EAT too (although that DOES make unpatching a tiny bit more difficult. Just a tiny bit.)

4. Enumerating the IAT or EAT manually on disk. <-- Currently in the process of fixing. Hooking file reading APIs and preserving the 'hooked' RVA on disk.

Holy crap. You mean you're hooking the ReadFile API to see when they specifically try to read the block of data that would be the RVA's in question, and patching that? That's just masochistic. I mean, I am stealthing (Zw)CreateFile(Ex) since it's fairly cheap protection for a number of possible attack vectors, but actually recreating a stealthed image of the bits on disk? That's just... masochistic.

5. Cached function pointers that are from before you injected. <-- Partially fixed. Currently I scan static memory in the primary module. Next on the list is all secondary modules, and all heaps in the process. Obviously impossible to catch obfuscated pointers that are cached before injection.

Well, yeah. This is the "if they call GetProcAddress before I inject" thing I mentioned. The only real answer is a brute-force search for pointers, as you say. But (again as you say), there's not much help if they do something as simple as:

PVOID pODS = (PVOID)GetProcAddress(GetModuleHandle("kernel32.dll", "OutputDebugStringA"));
pODS = (PVOID)((DWORD)pODS + 1);

Only real fixes for that are:

1) Detours
2) Some kind of SEH-based breakpointing (possibly DR0-3 based)
3) Get in to the process first so that the only copy of ntdll/kernel32/whatever that they get is YOUR fixed-up copy. Could do this if you bypass their launcher.

My library is designed for x64 as well as x86 so inline hooking is not something I want to do (because of the need for a runtime disassembler, threading issues, etc, which all do not exist when using IAT/EAT hooks).

Yeah, threading issues are a bitch. I've mostly been doing SuspendThread on "everyone but me" any time I do "anything interesting," and it's been fairly successful, but I know that's not a terribly great long-term strategy for a number of reasons.

Blizzard are never going to ban you for your hooks (assuming you stay private, because once you're public they can hash your hook and ban for it), but whats the point if its really easy to bypass without any prior knowledge of the target? (i.e. shit you'd do anyway "just to catch out the unprepared")

Yeah, I get your drift. My goal in all of this is not to create the perfect, polished haxx0r package to give to the world. In fact, about half my code is so ugly that I'd never show it anyway; it's just the state at which, at 3 in the morning, I said, "**** it, it's done and I know it doesn't have any serious bugs, ugly as it is." I just want to hack WoW to:

1) Run a successful group party bot.
2) Not be banned by using someone else's software
3) Not have to feel like a script kiddy by using someone else's software.

I was spoiled on XP by my kernel rootkit; I knew that they would never detect me unless they started installing drivers (which, again, I would be aware of well in advance, when the program crashed because I wouldn't let it out of a low-privilege jail to install the driver).

Now, in Vista/userland, everything's a zillion times harder. But I'm starting to get confident that there's no real likelihood that they're going to ban me; my code is all custom so it should have no easily identifiable signatures. I have plausible deniability on everything; ie just about all the stuff I'm doing could legitimately be done by AV software, since I'm not planning on hooking Blizzard's code at all (don't really need to for a bot; with the CTM stuff, with a ws2_32 hook on recv coupled with a packet decryptor, and with in-memory walks (read only) of the object list, I can do just about everything I'd need, and I'll put the bot intelligence out of process).

P.S. You can bypass LoadLibrary if you use the NT API (which is more difficult to do). That itself is obviously still hookable, but you're more likely to catch less-sophisticated monitoring attempts off-guard. In terms of undetectability by things like AC software and AV software, bypassing LoadLibrary is a huge plus (albeit very difficult to do 'correctly').

Yeah, I guess Blizz could manually call the Ldr/Ldrp functions, but again -- I just don't see that happening. It's too tricky to get right, and they have to balance their attempts to catch the evil haxx0rs against not having an app that crashes every time the antivirus software spins up (or whatever). From my perspective, just wanting a working, anonymous, safe bot... I'm probably safe just hashing LoadLibrary(Ex)(W) and if it "looks okay," using it to inject. Since I can play with the "kernel32/ntdll is the same everywhere" fact, I don't need to worry about my LoadLib being detected via Blizz doing their own AT hooks. The only thing that still makes me nervous about calling LoadLib is the whole DllMain REASON_THREAD_ATTACH thing (I'm sure you know the vulnerability I'm talking about). Gotta think about how to bypass that, and if it's a good cost-benefit ratio. Hopefully it won't force me back to ManualMap.

The broader topic of writing a generic user-mode rootkit is interesting, but... not something I have the time/energy to spend on right now (and besides, looks like you have it well in hand).

I still wish I could figure out a way to do my old SSDT kernel hooks, though. Would make all of this SOOOO much easier. I actually had my custom Wineserver working to stealth some NtXXX calls, but that would mean moving my gaming system over to Linux, which (in 64 bits) is still a cluster**** of epic proportions, sadly (can you say, every time you play flash in Firefox, your entire system's sound service crashes? I knew you could!)

[Cypher]

Just a tip. You don't need to use SuspendThread if you're doing IAT/EAT hooks. Threading issues only exist when doing code-based hooks.

[amadmonk]

Oh right. DWORD swaps are atomic, aren't they?

Doh. I guess I was just thinking about the unintended consequences of switching to/from a hooked api mid-function call. But I guess if I write my hooks right/carefully/non-retardedly, that shouldn't be so much of an issue.

[Cypher]

Oh right. DWORD swaps are atomic, aren't they?

Doh. I guess I was just thinking about the unintended consequences of switching to/from a hooked api mid-function call. But I guess if I write my hooks right/carefully/non-retardedly, that shouldn't be so much of an issue.

1. Yes.

2. Why would it matter? Changing the IAT pointer will never cause mid-call corruption because there are only two possible states, and both are valid:
1. Original API
2. New API

Both will succeed.

Threading issues only occur in inline hooks because you're patching code, and the CPU might decide to run half-way through your patching function, patch 3 bytes, and come back to 2 later. During that time a function might be executing the function you're in the middle of patching, and BANG, invalid instruction.

Again, function pointer hooks do not suffer from that because there is no 'inbetween'.

The only case you need to worry about is unloading your module and ensuring that no code is currently executing in any of your hooks. If you never want to unload your module on the fly though (which is the probably case if you're considering manually mapping it, or at the very least cloaking it), then you can just ignore the issue.

[amadmonk]

Yeah, I've decided to punt on unload since there's no real reason for it. If I'm detected, my signatures won't match, and half the goal is to not be detected. And from my memory, dynamic unloads are a major bitch from hell to make work properly because of the threading/synch issues. It's not enough just to FreeLibraryAndExitThread... Of course, with a manual map, freeing the library is as simple as deallocating your memory, but still.

One advantage of not needing to unload is that I can trash a lot of my DLL-specific structures post-load (I make sure to inject into a suspended process only). So I don't care if I overwrite my PE header, etc. Just zero it and become a smaller target...

As to the IAT hooked synch issues, I was thinking about API's that have a predefined call pattern. For instance, VirtualQuery is almost designed to be called in an ascending walk, but if your last call gave (hooked state) and your next call does (real state), I don't really know what would happen. Admittedly, that's a sort of contrived case, since well-designed API's should be stateless for threading/reentrancy reasons.

[Cypher]

I generally try to not make assumptions about how things are called, because usually you end up getting burned by someone doing stupid shit.

If you throw away unloads though the sync issues pretty much go away.

Also, you can overwrite your PE header, unlink, etc and still support unloading. Just do what I do in my module cloaker and back up all the data before you zero it. Then restore it before FreeLibrary.

[amadmonk]

Nah... I don't want dynamic unload. I figure if I need to get my DLL out of process, I'll just kill the process. Et voila. If Blizzard ever wonders why my WoW client goes down 5 times an hour, I can always play dumb and say "I dunno, my computer is buggy..." and install a virus before they send the FBI forensics team out to... but, I digress.

What I REALLY want is an encrypted PE that self-decrypts itself on calls, and recrypts on exit. Wouldn't have to be complex encryption, even just xor-ing with a post-link generated random seed would be fine. That would make signature-based detection almost impossible. Of course, they could hash your decryptor/encryptor code, but that might be small enough to run through a simple mutation engine. I've been brainstorming ideas on how to roll my own lately (also my other thread about metamorphic toolkits is related to this same idea of making code pretty much unhashable).

Interesting how many parallels there are between anti-anti-cheats and virus writing. Thank goodness we only use our powers for good.