I would like to know what is the simplest way to produce code binaries with instruction camouflage (see this question).

The problem here is that you first have to produce a correct assembly code and then to hide it with a given method directly into the binary. Doing it by hand is quite painful, especially if you have to take care of the static jumps into the code. Right now, I am using nasm, and more precisely its preprocessor to perform the camouflage operations. But, I wonder if there are better ways to do it.

So, what tools or tricks do you use to produce such binaries ?

  • 1
    This may be OT for reveng, since this site is mostly concerned with understanding such code.
    – nneonneo
    Apr 9, 2013 at 9:30
  • 2
    @nneonneo good point.. is the creation of obfuscation and protection schemes on topic for a reverse engineering site. Or does the topic only cover understanding such schemes after they have been created? I think reverse engineers certainly have unique insights to these topics at least. Apr 9, 2013 at 9:45
  • 1
    Yeah. It's most certainly a gray zone. I am of the opinion that the direct creation of obfuscation techniques, without a view to reversing them, is OT. In this early stage, it is really important to figure out what is and what isn't on topic.
    – nneonneo
    Apr 9, 2013 at 9:47
  • 3
    I'm only using these to create crackme challenges for training my students to reverse-engineering. Marking it as OT is a bit harsh because we have to study both side of domain to pretend understand a bit what is going on, in my humble opinion.
    – perror
    Apr 9, 2013 at 9:51
  • 4
    This question is on-topic. If you disagree, reason about it here.
    – Igor Skochinsky
    Apr 10, 2013 at 9:01

1 Answer 1


In general what you do is that you make a new segment in the executable, change the entry point to your new segment. Your new segment has the decryption code for the original code and the changed entry point now means that the first code to execute when the executable is loaded is your decryption code.

Your encryption code then either maps a segment, usually at the address where the original executable segment was located, and decrypts the source segment into the mapped segment or it directly decrypts the segment in place. If your code decrypts the segment in place you need to make sure the remove any relocations from the original executable.

In all cases, except if you get to map your decrypted executable segment at its original intended address, you need to do the relocations yourself after decryption so that the executable won't crash. Personally I would implement the relocations in order to support things like ASLR. After decryption and relocation you simply call into the original entry point.

This way you do not have to create your encryption or "masking" code for a particular binary and applying it to arbitrary binaries in the future should be possible.

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.