Home/ Questions/Q 994065
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T06:31:25+00:00

My client asked me to write an custom encrypted executable to prevent easy cracking

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0