Reversing, grasping the big picture

So no reversing section but still a reversing post. My personal opinion is that reversing is part of a forensic research in some way or an other…you could state that reversing is like a very specific forensic investigator. Most people asociate reversing with copyright infringements and bypassing security measures to access forbidden goodies(game cheats for example). Reversing can also be used for legal purposes just to name a few:

• perform a blackbox audit on an executable
• perform a investigation on a piece of malware
• help develop a quick patch until the official one is released
• learn and understand compiler optimization

I love reversing, I also hate reversing. Yet I keep practicing it and trying to learn. Why ? Because it really is a beautifull way to learn new things and to relax(this depends on the person reversing of course).

So why do I love it? Because of all the purposes I already named and because it’s like a tiny( or big depending on the target you are reversing) puzzle. Why do I hate it then? Because I always got lost. For some reason I have always tried to understand every single line of assembly line I saw in the debugger/disassembler. Most of you can tell right away that, that is the WRONG approach. So the other day a collegue of mine succeeded in changing my thinking and I finally don’t want to understand every single line of assembly(I still do actually but I can finally wait till it actually makes sense to do so) that scrolls down my screen.

So I’d like to pass this information on because it really was a eye opener for me even if I had read it a thousand times in tutorials…I kept ignoring it until it actually worked for me.

So what made me open my eyes?

GIVE FUNCTIONS AND VARIABLES MEANINGFULL NAMES!

Now that’s easy isn’t it? I felt very very very dumb for not sticking with the above sentence in past reversing assignments. Also graphical representations of the program flow are a big help. An example of a graph (created with immunity debugger) is as follow:

Function Graph

Now that’s a LOT easier then scribbling down notes on a piece of paper(or your favorite digital notes) about where the loop ends or starts. Now let’s view the difference between…not naming functions and naming functions.

No re-naming done

Now with re-naming done

re-naming done

Now that’s a lot easier to read isn’t it? instead of having to memorize/write all the function hex values to know if it’s the same function beeing called or a new one. When the function call are close to each other it’s easy to see, just imagine the same function beeing called from like 100 different places.

The part I liked most about this approach was the “drilling down” effect. You just recognize big chunks of code in the target application which you are reversing…but you do NOT start analyzing the code yet. You just try to understand what a function MIGHT do and what it’s arguments COULD be.

The result of this, is that in a relative short time you have a pretty clear picture off the stuff that is going on…of course you won’t have everything correct the first time. This means that you can SKIP the useless chunks of assembly code on which I usually wasted a lot of time. I mean if you are looking for a algorithm which uses loops(in general, excluding recursive functions and compiler optimalizations like loop unrolling) to let’s say generate random names. It’s a lot easier to identify it because it’s beeing called a lot from other places in the target application and because the code actually contains a loop. In a graph the loop would be pretty obvious.

This does NOT mean you can now skip understanding the assembly and just focus on the big picture. If you eventually want to understand a algorithm or a specifc action you WILL have to study the assembly lines, the difference this time beeing that you (hopefully) spent your time on the correct assembly lines.

Man I gotta love sleeping…cause I’m heading for my bed now.