ManualMap - A manual mapper for x86 modules

[Cromon]

Hey everybody!

I have started writing a manual mapper for x86 modules into x86 processes (into any arbitrary process) two or three days ago. So far i got the basic functionality working:
- Imports are resolved
- Exports are loaded and can be queried
- Sections are correctly protected and initialized
- Entry point is called in the process

So a call looks like that:

	ManualMap::IManualMapper* mapper = ManualMap::IManualMapper::CreateMapper(GetCurrentProcess());
	ManualMap::IMappedModule* pModule = nullptr;
	HRESULT hResult = mapper->LoadDll(L"MapDll.dll", ManualMap::IManualMapper::ManualMapAllDependencies | ManualMap::IManualMapper::CreateExportTable, &pModule);
	BOOL success = pModule->executeEntryPoint<BOOL>();

As the flags indicate you can either let the mapper load all dependent modules again (or newly) manually into the current address space or via LoadLibrary (if not set) and if the export table for GetFunctionAddress should be created inside the IMappedModule.

Internally the mapped module is compatible within any function that wants a HMODULE at least until Windows 7, i guess they didnt change it in win8, so its also valid there.

Before i can release it i need to do at least two more important things:
- Relocations. So far the DLL is loaded at the desired base address like if it has the flag set indicating that there are no relocations. That means the next dll manually mapped which has the same desired base address it fails because there is already one loaded.
- One of my thunks seems to **** up the stack balance which causes the returning of the call from the entry point to indicate an invalid ESP value across function calls.

Im aware that this thread so far might be pretty useless as there is no download/source code available, but i just wanted to post a preview and soon there will be some source code!

Greetings
Cromon

[Apoc]

Sawce or gtfo

[Cromon]

relocations work, stack failures are resolved and SafeSEH is on a good path.

Was about to release the code today but seriously after such a post i must say i am very disappointed and i guess ill let it be... I know neither you or anyone else would ever say "oh noe" and im already looking forward to one more of your amazing postings.

[Bananenbrot]

Be aware that if you don't share it for this community, you would at least share it for all the rest of the internet...
To be honest, I'm not quite interested in manual mapping (yet?), but I know that you must have had tons of work with this. Many people would profit from it, in case it's highly reusable code as I'm used from >=Elite users in this section.
So if you don't want to do it for anyone in this section, it is the right or most appropriate place to let the internet know whatsoever.

[Master674]

What Bananenbrot said. I don't think there is a proper working, open source manual mapper anywhere on the whole internet.

Would greatly appreciate your work =)

[DarkLinux]

Cypher has an open source mapper... Anyways it is really hard to do it correctly. I have found around 5 to 6 examples and non really did a good job. So even for you to profit it must be open source. I know I would love to help out and use it

[Cypher]

https://code.google.com/p/hadesmem/s.../ManualMap.hpp

https://code.google.com/p/hadesmem/s.../ManualMap.cpp

There you go. Works on both x86 and x64.

Supported:
- ApiSetSchema redirection (Very important on Windows 7+, if you don't support this you should definitely look into it - ApiSetSchema)
- TLS Callbacks (currently only called on module load, still need to work out the best way to detect thread creation/termination and process creation/termination and call them then)
- Relocations (should handle all relocation types you're likely to see in the wild)
- Imports (resolves imports, including handling cyclic dependencies such as manually mapping module A, which imports from module B, which in turn imports from module A)
- Sections (correct mapping, protection, etc)
- Calling Exports (for init or whatever)
- Path resolution similar to (but not quite matching) that of the Windows loader
- Recursively manually mapping dependencies automatically

Unsupported:
- Implicit TLS (Haven't looked into this yet)
- Delay Loaded Imports
- Implicit mapping of modules referenced by forwarders in the EAT
- Bound imports (afaik all I need to do is just ignore them and use the unbound imports, but whatever, haven't looked at it yet)
- Redirection of module related APIs for mapped modules (GetModuleHandle, GetModuleFileName, etc)
- Bumping load count of dependent DLLs
- SxS isolation/redirection and manifest redirection in the path resolution
- SEH/C++EH (This is one of my high priority items. I have some basic code to get it working but it needs cleaning up and a rewrite to make it less OS-dependent. Props to MaiN for putting a lot of work into this particular item - not yet integrated, but should be for v2)

I probably forgot a whole bunch of items on both lists, but it's been ages since I touched it...

Anyway, most of the 'unsupported' items I wish to resolve as part of HadesMem v2.0.0 (currently under development in /trunk), but I'm still in the phase of rewriting the underlying framework and enhancing the API. Once all the lower level pieces are in place I'll do what need to be done to bring the mapper up to scratch then start fixing the above items, but it could be months (or more) before that happens, so if you need something to hack on for now I suggest using v1.0.0. If you know what you're doing you should be able to quickly tailor it to your specific project/needs.

EDIT:

Btw, to the OP, SafeSEH is a LOT harder to support properly than you probably realize and requires a couple of nasty hacks (feel free to PM me if you think you've found another solution, I'd love to hear about it, but if you tried to take the same path I did initially then you won't be able to properly support stack unwinding). Props again to MaiN for putting a whole lot of work into that side of things and figuring out a solution (which hasn't been integrated yet, due to reasons explained above).

EDIT2:

I gotta agree with Apoc. Lets see some sauce. I've been waiting for someone else to come along who wants to take a crack at a mapper, it's a fun problem and it could certainly use more than one person working on it.

[sitnspinlock]

as far as safeseh goes there aren't too many noninvasive/nonlazy ways to go about it like for instance forcing RtlIsValidHandler to return true.

one of many that comes to mind however is the nx_compat flag. of course that would require changing the flag in the pe header or writing a process loader to get to it before LdrpInitializeProcess does, but i imagine that's not really viable because the idea would be to have your manual mapper be used in a way where the user can choose any target process/game of their liking and go from there.

anyways, since your seh handler(s) wouldn't reside in memory that is part of a image mapped file, the exception dispatcher will let it fly anyway because LdrpInitializeProcess will have set the ExecutDispatchEnable flag because the image is not nx compatible.

that is one of many many ways but probably as said, not very viable.

another one i can think of is changing the va of the safe handlers table in the load configuration data area to your own custom table.

[Apoc]

relocations work, stack failures are resolved and SafeSEH is on a good path.

Was about to release the code today but seriously after such a post i must say i am very disappointed and i guess ill let it be... I know neither you or anyone else would ever say "oh noe" and im already looking forward to one more of your amazing postings.

I'm not sure you've noticed, but this section of the forums is very lax, and we usually try not to be too serious. If you don't get the humor, then I apologize. I wasn't belittling you or anything like that. Not many people around here are willing to put in the work, or research to figure out manual mapping. (I know Cypher is one of the few crazy enough to go balls to the wall with it)

PS; you should have been able to tell by the blatantly obvious misspelling in my post that it was meant as a joke. Then again, you may not be all that familiar with me in this section

[Cypher]

as far as safeseh goes there aren't too many noninvasive/nonlazy ways to go about it like for instance forcing RtlIsValidHandler to return true.

one of many that comes to mind however is the nx_compat flag. of course that would require changing the flag in the pe header or writing a process loader to get to it before LdrpInitializeProcess does, but i imagine that's not really viable because the idea would be to have your manual mapper be used in a way where the user can choose any target process/game of their liking and go from there.

anyways, since your seh handler(s) wouldn't reside in memory that is part of a image mapped file, the exception dispatcher will let it fly anyway because LdrpInitializeProcess will have set the ExecutDispatchEnable flag because the image is not nx compatible.

that is one of many many ways but probably as said, not very viable.

another one i can think of is changing the va of the safe handlers table in the load configuration data area to your own custom table.

You can't change a processes DEP policy at runtime unfortunately, I've tried (NtSetInformationProcess with ProcessExecuteFlags infoclass and ImageDispatchEnable set to 1), so changing the NxCompat isn't really a very good generic solution (as you pointed out).

As for the safe handlers table, I haven't double checked, but I'm pretty sure that the table lookup only happens AFTER it has been confirmed that the address lies within a MEM_IMAGE mapped region, so you may still need to work around those checks somehow (EDIT: Or even if it happens before, it's still confirmed afterwards... I forget exactly which way it goes, but a quick look indicates that the table lookup may happen before a mapping check. Yet to confirm either way though.).

For example, here is the pseudocode from the Blackhat 2008 paper 'How to Impress Girls with Browser Memory Protection Bypasses':

BOOL RtlIsValidHandler(handler) { 
    if (handler is in an image) { 
        if (image has the IMAGE_DLLCHARACTERISTICS_NO_SEH flag set) 
            return FALSE; 
 
        if (image has a SafeSEH table) 
            if (handler found in the table) 
                return TRUE; 
            else 
                return FALSE; 
 
        if (image is a .NET assembly with the ILonly flag set) 
            return FALSE; 
 
        // fall through 
    } 
 
    if (handler is on a non-executable page) { 
        if (ExecuteDispatchEnable bit set in the process flags) 
            return TRUE; 
        else 
            raise ACCESS_VIOLATION; // enforce DEP even if we have no hardware NX 
    } 
 
    if (handler is not in an image) { 
        if (ImageDispatchEnable bit set in the process flags) 
            return TRUE; 
        else 
            return FALSE;           // don't allow handlers outside of images 
    } 
 
    // everything else is allowed 
 
    return TRUE; 
}

Also, I believe that C++EH is harder to support than 'raw' SEH because MSVCRT also performs its own extra safety checks when doing exception dispatch/unwinding. Again though, this is all from my very hazy memory so I'm not 100% sure. Maybe MaiN has a better memory than me?

Nevertheless, I'd like to take another crack at it once I finish the other parts of my library which the mapper depends on.

Anyway, @Cromon.... Can we see some sauce?

[Cypher]

[DarkLinux]

O god Cypher is back to his old ways....

[~Unknown~]

O god Cypher is back to his old ways....

haha I miss those days. I haven't seen him around with his text pics making fun of people since I joined this forum. Gives me some nostalgia amiright? xD

[Cypher]

[DarkLinux]

Yes! He is back! I normally dont laugh when looking over new posts. But every now and again I see old threads with funny pic and it reminds me of the old day. You got in a lot of shit back then XD Posting random pics in threads... Oh well... this made my day I lol'ed in rl