Monday, November 23, 2009

WinNinja Module Hiding Code

Project:
WinNinja

Description:
Unlinking modules from the PEB is fairly common practice, however something which lots of people are unaware of is that this is only half of what you need to do to hide your module.

When the Windows PE loader maps a module into a process it uses a file mapping. The actual file mapping handle and other info is stored in the kernel, and cannot be hidden in the same way that the module loader data can be.

This opens a huge gaping hole that allows anyone to find your module in memory, even when it's unlinked.

This is done via calling NtQueryVirtualMemory with the MemorySectionName parameter on every memory region. This API will return the full path (kernel-style) to your module.

Furthermore, the fact that you can enumerate all memory regions in order to find potential module bases is in itself a weakness, as the attacker could perform hashing attacks (much like Warden does currently).

If you don't believe me, unlink your module from the PEB, download the VMMap tool from Sysinternals, and run it on the process your module is injected into. It will be able to retrieve the full path to your module, along with it's memory region.

So, in order to hide an injected DLL effectively from an anti-cheat system, you will have to hook NtQueryVirtualMemory, there is no way around of it (in usermode).

One problem is that NtQueryVirtualMemory allows inspection of the memory in an arbitrary process, so it's impossible to hide your DLL from an external process unless you do one of two things:

  • Hook the external process too
  • Manually map your module
Thankfully, the main reason you'd want to hide a module is to evade anti-cheat software, and in this case, we always know the process we need to hook, and we're not worried about some arbitrary process (like for example, VMMap).

Attached is an example implementation of such a hook.

Notes:
  • There are multiple known holes in it, and the documentation indicating where they are has been removed (I don't want to take away all the challenge, that would be no fun).
  • It is incomplete, in the sense that I've pulled it from part of a larger library of mine. You will need to provide the relevant structures, enumerations, functions, etc on your own. 
  • I'm using a C++0x compiler, if you're still working with C++03 or C++98 you will need to modify the code a big to get it to compile, however this is only a 30 second job.
  • Think of this more as a "pseudocode" example than a real implementation that you can just drop into your cheat.
Anyway, if you're not a moron this should provide a quick and dirty starting point for you.

As always, comments and constructive criticisms are appreciated. Also, if you notice any of the holes and want to help out the other readers you're free to post them in the comments. I just didn't want to post them myself because I thought it would be more fun to see how many you guys can find.

This may not appear anywhere else without permission, but may be linked to.

Releases:

2 comments:

spot said...

Could you please also release your detour class? I'm finding it hard to structure it properly. You seem to be using a seperate instance per hook, my idea was to let every class have its own detour engine. Could you please enlighten me? :)

Cypher said...

It's not really ready for release yet.

I will consider it though.

Post a Comment