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?

4
  • 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. Commented Jul 24, 2014 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
    Commented Jul 24, 2014 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?
    – Jongware
    Commented Jul 24, 2014 at 14:21
  • @Jongware: Good idea; perhaps. The code was compiled with g++, with default settings.
    – JamalS
    Commented Jul 24, 2014 at 15:20

1 Answer 1

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.

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.