[Open source]Just another manual PE image mapper

[DarthTon]

So I decided to make my own open source manual PE image mapper with blackjack and hookers

So far it has next features:

- x86 and x64 image support
- Mapping into any arbitrary unprotected process
- Section mapping with proper memory protection flags
- Image relocations (only 2 types supported. I haven't seen a single PE image with some other relocation types)
- Imports are resolved****
- Delayed imports can be resolved****
- Bound import is resolved as a side effect i think
- Module exports
- Loading of forwarded export images
- Api schema name redirection
- SxS redirection and isolation
- Activation context support
- Dll path resolving similar to native load order
- TLS callbacks*
- Static TLS data, sort of**
- Exception handling support (SEH and C++), need more testing though, It is quite unreliable
- Adding module to some native loader structures(for basic module api support: GetModuleHandle, GetProcAdress, etc.)***
- Security cookie initialization
- C++/CLI images can be mapped (this needs adding module to native structures)
- Image unloading
- Increase reference counter for import libraries in case of manual import mapping***

The things it can't do yet:

- Trace module dependencies during unload
- Remove module from native loader structures upon unload
- Shitload of other things I don't know about or forgot

*TLS callback are only executed for one thread with DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH reasons during image loading and unloading respectively.

**Static TLS is a mess. It is only initialized for one worker thread and can't be expanded. If another image with static TLS is loaded by native loader after manually mapped one, loader will probably increase TLS vector size, and because it can't detect already existing TLS vector of manual module (it is not yet referenced in LdrpTlsBitmap an LdrpTlsList), loader will destroy old TLS vector and create new one without preserving it's contents.Official documentation also says that you shouldn't load images with static TLS dynamically (LoadLibrary).

***This is fully implemented only for Windows 8 loader (with it's binary tree for module search). I'll add win7 and earlier versions support asap.

****Imports and all dependencies can be mapped either manually or by native loader. In case of manual mapping circular dependencies are handled properly.

Source - https://github.com/DarthTon/DarkMMap

Whole thing is compiled using VC++ november CTP (I'm too lazy to add support for more compilers...).

Although it supports most features image needs to work properly, I can't guarantee that it won't actually crash during some point of execution This is more like Proof of Concept than stable solution.

[Cypher]

Awesome! Good job. You using this for anything? Or just write it for fun?

[DarthTon]

I'm using this for my private bots. And for fun also

[Alfalfa]

What does PE stand for? I thought it was packet editing when I read the title.

[Jadd]

Awesome! Will definitely check this out.

What does PE stand for? I thought it was packet editing when I read the title.

PE stands for portable executable.

[Alfalfa]

Awesome! Will definitely check this out.


PE stands for portable executable.

Ok, thanks.

[DarthTon]

Added unlinking of image memory pages from process VAD tree (only Win7 SP1 x64 for the moment; will add other offsets later). This is mostly for fun, because of ring0, obviously.

[DarkLinux]

I was like, lame just another mmapper... but unlinking from the VAD tree Tricky shit and risky. How well does your code work? Going to take a look :}

[sitnspinlock]

Added unlinking of image memory pages from process VAD tree. This is mostly for fun, because of ring0, obviously.

i didn't look through all of VadPurge, maybe i missed it, but you need to make sure that the user pages that you unlink aren't going to be paged out, or in the case of NtMapViewOfSection; aren't paged in to begin with, prior to unlinking the VAD nodes.

because if they are (since VAD is used to resolve user level page faults) and no VAD entry exists but there is stale entries in the page directories, you will get a bugcheck.

use virtuallock() or mmprobeandlockpages() but if you use the latter of the two, register a callback for process exit. because a process terminating with locked pages is also a bugcheck.

if you already did all this and I missed it, then let me know ;p


edit - forgot to mention. virtuallock() is a user level api. it does not really lock the page frame, it just adds the pages to the working set. they can still be paged out technically but only in extreme circumstances.

anyways i'm not trying to be nit-picky, i really don't care to be honest. but I thought i'd just throw that out there in case you started running into problems. otherwise looks good, very nice and clean work

[DarthTon]

Hmm... I thought page faults were resolved completely accordingly to PTE without VAD lookup, but now I realize I was wrong (MmAccessFault indeed gets page info from VAD in case of UserMode page fault). I'll lock pages in the working set. Many thanks for noticing this