C or C++: how do loaders/wrappers work?

Question

Here's an example of what I mean...

• User runs LOADER.EXE program
• LOADER.EXE downloads another EXE but keeps it all in memory without saving it to disk
• Runs the downloaded EXE just as it would if it were executed from disk, but does it straight from memory

I've seen a few applications like this, and I've never seen an example or an explanation of how it works.

Does anyone know?

Another example is having an encrypted EXE embedded in another one. It gets extracted and decrypted in memory, without ever being saved to disk before it gets executed.

I've seen that one used in some applications to prevent piracy.

Edit: As a side-note, do programs like UPX work like this? I looked at the code but it is hard to decipher for me, and I'm asking mainly out of curiosity, I don't have a need for it.

Answer 1

Well if you know where the offset to the entry point of an executable is and you know what parameters it takes then all you need to do is call the function at address "exeBase + entryPointOffset" using a function pointer.

Its worth noting that OS's, on x86 systems at least, tend to not allow you to execute memory that is marked as data. Under windows, for example, this can be changed using the "Virtual ProtectEx" function to mark the memory as executable.

In fact, back in the good old days, this was a common system to save memory. You'd have "overlays" such that you could save memory by swapping the code in and out as needed.

Answer 2

A lot of programs that do this just unzip to %TEMP% (I know I do), but the big boys essentially re-implement the OS executable loader, which has to:

• Map the executable into memory. This is not as simple as it sounds, as the .exe contains multiple 'sections', which must be loaded with page alignment (they must start at addresses that are multiples of 4K) and they each have specific requests - read only, copy on write, zero initialized, etc....
• Satisfy static imports, by updating the import table section, normally using LoadLibrary() and GetProcAddress().
• In the case of dlls (which are actually almost identical, the important difference is that they have exports as well as imports), the loader might also have to rebase the dll, if the memory address it was compiled to load at was already in use (which is quite common). This is normally impossible for exe's, though, because they do not include the relocation section which lists the places in the loaded code which need to be updated, because normally they are the first thing loaded into a process, and therefore can't be blocked by something. This means a loader has to have an unusual load address for it's own exe that won't block the loaded exe.

In summary: this is a lot of work. If you are interested, take a look at the PE format specification, which describes .exe and .dll files, and the VirtualAlloc() function.