Hack hiding

[FenixTX2]

Hey amadmonk,

I'm not sure if this is what your after and I'm not all that skilled in c++ but could you make use of the map container to map your library calls and functions calls to strings?

[amadmonk]

Hmm you know, I never even considered import/export hooking. So then as long as you're sure your replacement function sig matches the target you don't need to type the function at all. No asm overwrites...

Just did 3 mins of quick research and it looks like (given what you've told me about what Warden looks at, and extrapolating what it's likely to look at) EAT hooking of the system API's is probably the best bet.

Nice. Much cleaner. Must research. Happy to get rid of DWORD (__stdcall *)(DWORD, HANDLE, DWORD) syntax -- very happy.

[Edit: on reconsideration... nah. Import/export hooking wouldn't have solved the issue of ZwQueryVirtualMemory in my other post; I'd have had to hook three separate functions, all with different signatures (VirtualQuery, VirtualQueryEx, and ZwQueryVirtualMemory -- possibly four if NtQueryVirtualMemory has its own entry). So it's not terribly effective as a (relatively) secure anti-anti-cheat. Also it's far easier to scan for IAT/EAT entries that don't point to the right place than it is to scan for inline detours. And my real complaint was more a reflection of my C++ noobishness than any real problem with asm hooking; IAT/EAT hooking still has all of the fragility of detouring, but doesn't have all of its benefits. I'll stick with detouring and just man up and figure out the "right" way to layout my class hierarchy.]

[amadmonk]

Hey amadmonk,

I'm not sure if this is what your after and I'm not all that skilled in c++ but could you make use of the map container to map your library calls and functions calls to strings?

Yeah, that was sort of the (not yet fully formed) plan in my mind -- be able to just index ApiHooks["ZwQueryVirtualMemory"].UnHook() or something like that. Probably use an std::map, like you suggest, to make that happen.

Ideally, I could do the following with ease:

Hook/Unhook -- when I got skeert that Warden was going to scan me (I know Warden doesn't scan patches like this right now, but ... it might someday).
InvokeOriginal -- so that I don't have to worry about going into a recursive death spiral if my hook code needs to call the original, and so that other code that wants to use it can use it without fear of hitting the hook (although I guess with EAT hooking that's not a concern)
IsHooked -- obvious

And then the "manager" class could:

HookAll/UnhookAll -- just for a simple single point panic button
FindHook("APINAME") -- (maybe just an index into the map?)
??

Now that Cypher's planted the idea of EAT hooking in my mind, I'll probably go that route for the internals.

I know Cypher and others already have all of this code working and tested, but where's the fun of just copying and pasting someone else's code...? I haven't worked actively in c++ for about 3 years and a lot of what I'm doing is forcing my brain to remember how it works.

Ideally I'm going to just build a simple chunk of injected code that will be controlled by an out-of-process brain, but still I'd like it to be flexible enough that it doesn't become useless at the first patch. Now I just need to think about an XML structure to explain that "the offset I'm interested in is at deref(deref(STATIC) +0x + 0x54" (or whatever)...