Junk code makes reversing a pain

Warning: I know some who follow this blog are looking for deep tech, others aren't.  If you are not a techie, this post isn't for you (sorry).

I was looking at some malware the other day and found an interesting use of adding junk code.  I've seen this a lot over the years, but this particular sample is just filled with garbage code that does nothing.  Why add junk code?  It makes the file bigger and usually bigger files mean less stealth.  But in the case of junk code, we see superfluous instructions that the processor just executes to get to the good stuff.  The original program instructions are carefully interlaced in the junk code, making it harder for the reverse engineer to understand what is going on.

In other cases, junk code never executes but it may not be obvious from static analysis that the code will not be used.  The whole point of the junk code is to complicate analysis in the hopes that you will give up before understanding the true meaning of the code.

Junk code

Now this is by far not the most exciting example of junk code insertion I've ever seen - this one doesn't even try to break the disassembler. But the sheer quantity of junk code is inserted is interesting.  The basic block we examine above has more junk instructions than real.

The first clue that we are looking at junk code are the combination of additions and subtractions to the ESP register.  Normally, we subtract from ESP to create space on the stack for local variables.  Adding to ESP is used to clear space for local variables before the function returns or to clear function arguments after the return.  But in this case, we see an add followed immediately by a subtraction - no net change to ESP at all.

The values added to EBX do definitely represent a change to the value of EBX.  These would be very interesting indeed, except that the register EBX is not used anywhere in the function.  There are many other junk code obfuscations in the program.  I'll detail some more in future posts.