2

I have noticed many times whilst disassembling executables that often the compiler will produce jumps to other unconditional jumps, rather than simply jumping to the final destination. For example:

enter image description here

Notice instead of jmp 0x100001634 it would have written jmp 0x100001681 and skipped the two other jumps in between. Is there a particular reason for not doing so?

  • 1
    Likely due to a crappy optimizer. Noticed this on a few occasions as well. I could see a point where a conditional branch jumps to an unconditional one due to limited range, but in this case it clearly looks like compiler being stupid. – Dmitry Janushkevich Jul 24 '14 at 10:55
  • If this is a release version it's like Dmitry said. Otherwise, it could be just jump table in debug PE. – Paul Jul 24 '14 at 11:45
  • 6
    Could this code be produced by an Optimized for Size compiler setting? I.e., if these labels are used anyway, the compiler chose to replace one 6-byte long jump with 2 2-byte short ones? – usr2564301 Jul 24 '14 at 14:21
  • @Jongware: Good idea; perhaps. The code was compiled with g++, with default settings. – JamalS Jul 24 '14 at 15:20
2

In addition to what others have already mentioned with respect to Compiler Optimizations, there is another possibility. At times, malwares can perform control flow obfuscations by making use of a lot of opaque predicates (in this case, unconditional jumps).

In fact, if you perform an instruction trace using a pintool (DBI) on a malware, at times you will observe a lot of jmp instructions executed in sequence. You can observe these type of subroutines in malwares which make use of polymorphic engines. It can help deter reverse engineering as it alters the control flow while stepping through the code.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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