Imagine you are working in a kind of crypter that only works with the current function deciphered, rest of the code is ciphered by symmetric encryption. When a new function is about to be called, the current function is enciphered and the following is deciphered and called.

My assumption is that a analyst can easily dump the deciphered code (real code) each time a function is called, due to is the unique time where code is leaked/deciphered. Also, an analyst could easily repatch the executable in order to extract the protection, but it would need the symmetric key, once he has it, he just has to remove the encryption/decryption blocks and decipher the code.

Question here is: How can I implement a secure system that accomplish:

  • Key management without leaking the key, or protecting it from being retrieved. (So the executable isn't patched for removing crypter's protection).
  • Avoid dumping per deciphered function. (Thus the analyst wouldn't dump the whole executable's deciphered code just dumping deciphered functions in runtime).

It would be great to read some advices. Thanks!

  • Even if you were able to keep the key "hidden" (using white-box cryptography or other means) and obfuscate the decryption algorithm well, one could still decrypt your program by calling your decryption function(s) on each encrypted function and dumping the output. I actually discussed this briefly @ youtube.com/watch?v=mWsT5M6rHWI#t=15m7s (it's about encrypted strings but the same approach could also be applied to encrypted functions). Commented Jan 28, 2016 at 15:20

1 Answer 1


There is a thing that might help you in modern crypto research, it is called white-box cryptography and relatively good Q&A article resides here .

Generally speaking if the key exists sometimes in the memory you can safely assume that sometimes it will be dumped and reused.

However you can harden the problem by using the following techniques:

  • Obfuscate the key (compute them on the fly)
  • Obfuscate the encryption/decryption algorithm
  • Use different keys for different functions
  • Re-encrypting the function back may be done with different keys
  • Use checksums for verification of encrypted code before usage
  • Use Intel SGX or similar features of other processors to avoid debugging
  • Use anti-debugging and anti-dumping techniques

Good luck.

  • Small remark: Encrypting the code by function boundaries leaks information about the code structure. You can divide your encryption blocks differently.
    – w s
    Commented Jan 28, 2016 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.