Execute data as code?

Question

My client asked me to write an custom encrypted executable to prevent easy cracking of the licensing system. Now, I understand that this is a false sense of security, but despite this he insisted on it.

So, I dug up my knowledge of portable executables and came up with this idea:

• Encrypt the executable
• Stick this to the end of a loader executable along with it's size
• The loader decrypts the data
• It copies the code to a page allocated with VirtualAlloc that has executable permissions
• It finds the entry point of the application
• Jumps there and we are all set.

I have a problem with the jumping there part. How can I do that? If I were to set a function pointer to it, what would be the signature? The signature of the loaded executable's main() function? Or do I need to resort to assembly?

I understand that it might be needed to correct absolute addresses after loading the code. How do I check if I need to, and how do I actually perform this?

Edit: Working on windows and compiling with GCC. I can switch the Microsoft compiler if necessary.

Edit2: To clarify: I KNOW it's mostly pointless. I believe that stands for any kind of DRM. It's up to my client to decide, and he still wants it despite me warning him about this.

Thanks in advance.

Answer 1

Unfortunately, jumping to the entry point of your code is the least of your worries. A Portable Executable (PE) file (which is the file format used for EXE and DLL files on Windows) is not something you can just load into a single memory block and then run. Your custom PE loader would have to take care of the following jobs:

• Load the various code and data sections in the PE file into separate memory blocks.

• Resolve dependencies from the import table to load DLLs that your EXE depends on.

• Perform relocations.

Getting all of the details right would probably be a pretty involved job. I would suggest that you look for a tool you can buy that does this kind of EXE encryption.

Edit: A quick Google suggests you might want to take a look at the following:

• EXECryptor (proprietary)

• RLPack (proprietary)

• UPX (GPL) This one only does compression as far as I understand, but you could Use The Source to add encryption (if the GPL is compatible with your needs).

There are bound to be more tools like these -- this is just the result of a quick search.

Another edit:

MSDN magazine carried an article by Matt Pietrek called "An In-Depth Look into the Win32 Portable Executable File Format" (Part 1, Part 2). It contains a lot of information on the PE file format that should be useful to you. One interesting bit of information: Recent versions of the Microsoft linker appear to leave out base relocations for EXEs by default. You'll probably want to instruct the linker to put these back in because it's likely that your wrapper EXE is already loaded at your payload EXE's preferred load address. Alternatively, you could try and give your wrapper EXE an exotic preferred load address where it hopefully won't interfere with the payload EXE.

I've also found a page that discusses a rudimentary PE file compressor. It doesn't appear to be fully general though and would probably require some additional work before you can use it.

Answer 2

As others have mentioned, simply loading the entire EXE up into a data section and linking it at runtime is a difficult task; however, here's another option.

Take your input EXE; find its code and initialized data (including constant) sections. Rename these sections and convert them all to read-write initialized data sections; encrypt the contents. Now add a new code segment containing your decryption stub, and change the entry point there. This stub should decrypt the segments in-place, then change their protection to whatever is appropriate for their type, and jump to the original entry point.

This avoids having to implement all the functions of a full PE loader, as the imports tables are not encrypted, and thus the normal windows loader will take care of them for you.

It should be noted, of course, that this kind of naive approach will not survive a concerted attack for any time at all - an attacker can simply dump the process's memory to get the original, decrypted code. To avoid this one would likely need to encrypt and decrypt code on a continual basis, at which point PE handling is the least of your concerns.