Wrap/encrypt another executable (for licensing)

Question

I want to create a wrapper around another executable (ie - I have an executable that prints hello World, but I want the user to enter a password before the hello world executable is run). I don't want to edit the original executable's source. I also want to encrypt the original executable (hello world in this example) and do not want to write it to the drive (mem only).

To be written in C/C++/ObjC for Unix. Would love any tips and/or pointers to opensource project which does something like this :)

I have a handle on reading in and encrypting/decrypting the binary executable (easy obviously). What I'm not exactly clear on is how to get a function pointer to main in the second executable and to call it.

Thanks in advance for your pointers!

Answer 1

I don't know the complete answer to your question, but the nm command does give you the address of the main function in an executable.

Answer 2

Short answer: there's no easy way to do it (on Linux, anyway). In order to exectue a file, Linux requires that it is actually a file. Fortunately, this isn't necessarily the end of the line. If you were to set up a filesystem (writing a FUSE module seems best, as it can be integrated to your code and doesn't require root priveleges), you can get Linux to treat it as a regular file, even though it won't be written to disk. That's about as close as you'll get though without some serious hackery.

Jumping straight into the process won't work, as the code won't be in the correct portion of memory.

Answer 3

Implement your original executable as a web service, and require authorisation before returning results. If you give people the actual executable code (encrypted or protected or whatever), it can always be circumvented.

Answer 4

if you don't care that it is super secure an easy solution is just using zip's password/encryption flag

zip -e binary

if you want to be alittle more secure use gpg

gpg --output binary.gpg --symmetric binary

Answer 5

coppro: I will look into fuse - but regarding your statement about jumping into the code, couldn't I just get an offset from my code to the executable's main and run (somehow)?

greg: I agree there is always risk of circumvention (i'm willing to accept that). I agree the webservice would be more secure (as secure as the web server is :) . But I need to run on the platform. hacintosh: no good - writes the executable

I'm def. looking for a function lookup in an executable file and applying an offset. Poly: The nm helps - as that's the offset for main (thanks). Not exactly sure how it will work - could I use asm to make the main call - using the pointer to the beginning of the unecrypted binary data? (or not asm even easier)?

Answer 6

(Continuation) What i'm not sure is - when, ie, you call LoadLibrary(), what else is happening besides loading the library into memory? Can I just point to a point in memory which has loaded binary and say "go" or is there more involved (sorry - I skipped the OS fundamentals class in school)

Answer 7

(continuation after more research) coppro: Ok - seems like what you mentioned may be best - because (after looking at your link) - I recalled it could be very annoying to try to do load all the dynamic libraries referenced by the executable instead of just having the OS do it itself......

Answer 8

There is a way to do it, and there's working code for it in the UPX executable compressor source download.

Unfortunately I don't understand exactly what the code is doing, but it does do it, and it does work.

Answer 9

I've never done it under *NIX, but for Windows there are a number of things that have to be done before you can just use an asm jump to the entrypoint. For example:

• Loading the encrypted code sections into the proper places in memory;
• Loading in any dynamic link libraries referenced by the program;
• Setting the addresses of DLL functions to where they are actually loaded;
• Making sure that the executable is loaded at its preferred address, or finding and correcting the changeable addresses to account for the difference.

That's just off the top of my head, there are several other things that had to be done too. If I had to write the code to do it from scratch again, it would probably take me two or three weeks of uninterrupted effort to get a working first draft, and that's with already knowing exactly what needs to be done and where to find the information to do it. If I had to research it from scratch too, it would probably be six or seven weeks minimum. And then there's the debugging time -- something like that is never completely done, I wrote the code for it more than ten years ago now and we're still finding the occasional bug in it.

It's definitely not a project for the faint of heart, or something you can do quickly from scratch. If you have the source code for a working program that does something similar (such as the aforementioned UPX), you can probably cut that time quite a bit, but without it you're looking at a lot of work.