Does anyone know some cool technique to execute an pe file that is only present in memory? I might be able to read the EIP and then run a CreateThread on that...has anyone ever tried? Any other ways to do so (except for writing the memory map to file)? What about the MS Executeable Loader? Can I run it somehow?

Dominik
Posted on 2004-12-05 14:59:35 by Dom
Dom,

You have the problem that an EXE expects to be loaded at 400000h where when you load an exe file into a memory mapped address, it will be at the wrong location to run by itself. A DLL handles the problem by a section that has relocation data but you are going to have to know a lot about the details of a PE file and the OS loader to get this to work.

I have seen it done but its not for the faint of heart.

Regards,

hutch at movsd dot com
Posted on 2004-12-05 21:24:35 by hutch--
I think Qweerty coded something like that. Try emailing him or something.
Posted on 2004-12-06 00:04:02 by roticv
It's not that big a problem. You can link your loader-program to another base address, and/or you can include relocations in the modules you want to load - that takes care of the base address problems.

Loading the the file to memory is easy. You VirtualAlloc a chunk of peheader.SizeOfImage bytes, at peheader.BaseAddress. If this fails, the memory region isn't available. Then you have to check whether the image contains relocations - if they are stripped, fail. If not stripped, do the VirtualAlloc again, but with a NULL baseaddress, and set a flag that you need to handle relocations.

Then loop through the PE sections. Seek the file to section.RawOffset, read section.RawSize to memchunk + section.VirtualAddress.

If you "image needs to be relocated" flag is set, process relocations. The format is a bit funky, but not too bad - have a look at the PECOFF specification from microsoft.

Handle imports. This isn't too bad either. I would advise you to stick with LoadLibrary and GetProcAddress rather than coding your own, at least to start with. Unless you put some effort to it, your version of GetProcAddress will be slower than the one in windows, and will fail on NT (binary search of exports, forwarded exports, etc.).

This should be enough for most standard PE files - but fancy stuff like TLS and such aren't handled. Also, the PE file cannot use it's own resource items, to do that you probably have to look for and hook all it's imports to resource-related API functions and code some sneaky replacements.
Posted on 2004-12-06 06:41:54 by f0dder
I would advise you to stick with LoadLibrary and GetProcAddress rather than coding your own, at least to start with. Unless you put some effort to it, your version of GetProcAddress will be slower than the one in windows, and will fail on NT (binary search of exports, forwarded exports, etc.).


yeah, forwarded exports are a REAL pain :/. However, there is a problem with using GetProcAddress under 9x, for some stupid reason, it will randomly return a kernel "thunk" to the _actual_ address of the api function, and not the actual address. i thought this only applied to ordinals, but apparently not. i ran into some problems with that when i was messing with 9x. read some pietrek i guess.
Posted on 2004-12-06 20:53:15 by Drocon
Why is the thunking a problem? You should still be able to call the address returned by GPA, right?
Posted on 2004-12-07 08:24:01 by f0dder
Possibly function MapAndLoad from imagehlp.dll can be used for your purposes. There are some quite interesting articles about that stuff in MSDN (Matt Pietrek).
Posted on 2004-12-07 09:22:43 by japheth
There is another technique that you can use which is to hook the underlying file operations (NtOpenFile, NtCreateSection, NtMapViewOfFile, etc) used by NTDLL when mapping a and loading a dynamic library. By hooking these routines you can emulate their operations against a region of memory rather than allowing them to operate against a file on disk. The basic concept to this approach is to use a unique file name that your hook routine will recognize as symbolizing the memory region that you wish to map as a library from memory. Once NtOpenFile is called with this unique file name you can return a unique file handle that will then be passed to NtCreateSection/NtOpenSection. Once this happens your hook routine can compare the passed in file handle with your unique file handle to see if it should perform emulation and return a unique section handle. Finally, NtMapViewOfSection will be called with your unique section handle. At this point all you need do is set the out pointer BaseAddress to the address in memory that you have already mapped the PE file at and return STATUS_IMAGE_NOT_AT_BASE. This will cause NTDLL to process relocations, handle bound imports and do everything that would typically be done when loading a DLL from disk.

The above described technique is meant for use with DLL files, but can also work for executable files that are compiled with relocations (/FIXED:NO). It can also work for executable files that do not have relocations in scenarios where you can ensure that the address at which you mapped the executable in memory is the same as the load address that it expected to be mapped at (obviously). I'm unsure if this is helpful for the specific condition under which you wish to execute an image file only from memory but may at least be of some help.

If you are curious about reading more about this approach you can reference http://www.hick.org/code/skape/papers/remote-library-injection.pdf
Posted on 2004-12-07 10:17:36 by nohaven