[C#] [SRC] Hide a DLL by unlinking it from PEB

[ddebug]

I believe this is one of the first of its kind in C#. I searched for examples of doing this in .NET but returned 0 results.

I credit Pnluck at OpenRCE for posting the "C++" way of doing this, and MSDN and Pinvoke for the API prototypes and definitions.

Without further ado, attached is the source to hide a module by name in C#. After applying it, you should notice that the specified library is no longer shown as loaded in the process environment block (PEB) of your target.

This makes calls to GetModuleHandle() return NULL for your DLL.

Before application:


After application:


Notice as "Loader.dll" disappears from the module list in Process Explorer.

This can be used to help prevent detection by anti-cheats that "walk" the module list and search for injected libraries. Do note: this is not 100% full proof by Warden. This gives you an "added" layer of security, but, this is by no means a defeat to Warden. Using this in conjunction with some API hooks, should make it very difficult to detect a loaded module in a process.

This does require you to be in process. This is not for "external" programs. However, you can implement an external way of doing this fairly easily (ReadProcessMemory/WriteProcessMemory).

To use, simply call:

Stealth.Hide("library_name")

e.g.

Stealth.Hide("kernel32.dll");

Cheers.
Stealth - Hide a DLL (ddebug).zip

[_Mike]

So basically you took a C function and marked it as unsafe and put it in a .cs file?
But joking aside; Nice work. The only real problem I see with it is that you're feeding all the clueless copy'n'paste bottom feeders that hang out here

[ddebug]

So basically you took a C function and marked it as unsafe and put it in a .cs file?
But joking aside; Nice work. The only real problem I see with it is that you're feeding all the clueless copy'n'paste bottom feeders that hang out here

Btw, try pressing ctrl-h in process explorer

Ctrl+H doesn't show me anything of interest in Process Explorer. I don't see my DLL in there.

VMMap on the other hand:


Nothing that a good old NtQueryVirtualMemory hook won't solve (as recommended by Cypher).

[_Mike]

Ctrl+H doesn't show me anything of interest in Process Explorer. I don't see my DLL in there.

Yeah, that was a miss on my part and I edited it out. It was a file handle I was opening that I mistook as the dll being mapped by the dll loader. (Note to self: Don't post on forums when to tired to think)
My point was that the dll is visible as a memory mapped file though, which you obviously already knew

[Apoc]

A very much required note; make sure you specify the struct layout on the structs.

Also keep in mind that IntPtr can represent a 32 or 64 bit number, depending on platform.

[ddebug]

A very much required note; make sure you specify the struct layout on the structs.

Also keep in mind that IntPtr can represent a 32 or 64 bit number, depending on platform.

The PEB 64-bit structure is significantly different anyway that I don't think this would matter. This code shouldn't work without new structs for x64.

However, most games and software this would be useful for are 32-bit. Hence why it was designed for 32-bit processes. On x64, WoW64 should emulate the x86 environment fine, no?

[Apoc]

The PEB 64-bit structure is different anyway. This code wouldn't work without new structs for x64.

However, most games and software this would be useful for are 32-bit. Hence why it was designed for 32-bit processes. On x64, WoW64 should emulate the x86 environment fine, no?

In short; yes.

[_Mike]

The PEB 64-bit structure is significantly different anyway that I don't think this would matter.

The 64 bit structure is exactly the same except that pointers are 8 bytes instead of 4.
peb32: http://pastebin.com/KFvWZdyr
peb64: http://pastebin.com/EAhuWLwA

[ddebug]

The 64 bit structure is exactly the same except that pointers are 8 bytes instead of 4.
peb32: http://pastebin.com/KFvWZdyr
peb64: http://pastebin.com/EAhuWLwA

Interesting!

I was briefly looking at PEB Structure (Windows)

I saw that the 64-bit reserved blocks were significantly larger than their 32-bit counterparts (which is normal). Just looking at the reserved bytes didn't appear to me that pointers were the only thing that made the PEB structure "larger". I thought there was more data associated with other fields.

Thanks for pointing that out. I'm running 32-bit so I really have no way of testing.

[Cypher]

One thing to note, is that even if you hook NtQueryVirtualMemory Warden can bypass it. That's how LuaNinja was detected, there was nothing 'wrong' with my anti-detection code per-se, they embedded code inside the client to load NTDLL from disk (not from memory), and read the 'real' code from there. Effectively doing a manual syscall. If you want to defeat that you'd also have to hook the NT file APIs. That's a real pain in the ass though.

Unfortunately, this code won't really help in either public OR private bots/hacks. Private bots/hacks don't need to hide their module, and public bots can't rely on it without going to extreme measures.

If you want to hide your module in a public bot/hack you're probably going to have to write/use a manual mapper.

[_Mike]

I just had a thought.. (shocking, I know)
If you were to hook NtQueryVirtualMemory in the 64-bit ntdll (only for 64-bit system obviously) it wouldn't matter if they manually loaded the 32-bit version as it's only a wrapper for the 64-bit one.
I guess warden could use the same method to load ntdll64, but it seems like an awful lot of work just for that.

[Cypher]

I just had a thought.. (shocking, I know)
If you were to hook NtQueryVirtualMemory in the 64-bit ntdll (only for 64-bit system obviously) it wouldn't matter if they manually loaded the 32-bit version as it's only a wrapper for the 64-bit one.
I guess warden could use the same method to load ntdll64, but it seems like an awful lot of work just for that.

From memory the thunking process is actually fairly simple to emulate, so tbh I don't think it would be very difficult for them to just call the 64-bit version 'manually'.

[_Mike]

From memory the thunking process is actually fairly simple to emulate

It is, but then they'd have to maintain 2 warden versions; One for 32bit OSes and one for 64. I'm just basing my assumptions on how long it has taken them to detect some public hacks/bots in the past. But it's true that nothing is completely undetectable.

[Cypher]

It is, but then they'd have to maintain 2 warden versions; One for 32bit OSes and one for 64. I'm just basing my assumptions on how long it has taken them to detect some public hacks/bots in the past. But it's true that nothing is completely undetectable.

The thing is though, you can't really use that as a reliable metric.

Some stuff (like previous Lua hacks with no real protection) gets added to Warden in days. Whilst other shit which is equally easy to detect (read: some bots, like Mimic) either gets added after months and months, or in some cases not at all.

The way they do things is really strange, and there doesn't really seem to be a 'pattern 'to it.

Also, they wouldn't have to maintain two separate versions. They already do OS version checks (or at least they used to) to implement certain low level features, and the data retrieved includes the architecture (again, this is from memory, and I'm not sure if they still do it). All they'd have to do is add a little bit of code during the initialization of Warden to change their VQ pointer to a wrapper which is different depending on the architecture.

[SHADOW1992]

Thanks....that was really very interesting!