A Simple Demonstration on

Reversing Software

03

SaturdayMAY 2014

POSTED BY ERIC HOKANSON IN HACKING, REVERSE ENGINEERING

2 COMMENTS

Tags
How to crack softeare,how to use IDA Pro,Reverse Engineering,Softeware RE

In this post, we will learn how to use the demo version of IDA Pro to disassemble, debug,
and crack a simple crackMe software. You may download a copy of crackMe here. Simply
unzip, load into IDA Pro, and follow along.
After unzipping the target binary and running it

In our scenario, we have a piece of software that is asking for a passphrase or key to unlock
it. Since we dont know the correct passcode, the software exits with a wrong password
message.

All is not lost. This is the power of reverse engineering and using tools such as

IDA Pros disassembler and debugger: we dont need the source code to learn how the
software works. With just a debugger and a disassembler, we can often extract keys and
learn a lot about the our target software.
After installing your IDA demo. Double-click to the IDA demo icon and you should see a
window like below:

Select the New button and then open your crackMe binary:

Then click Ok on the Load New File Window:

IDA will ask if you want to switch to proximity view now, simply click the No button. You
should see a window similar to the screenshot below:

At the very top is the navigation band. It gives a layout of the binary as loaded in the
virtual address space of memory. The dark blue bands refer to code or functions written
inside the binary. The light blue bands refer to functions that come from a library (e.g. the
C run time library), and the pink area refers to Windows APIs that are loaded by Dynamic
Link Libraries (DLLs).
The boxes on the left side contain a function window and a graph overview window. Both
can be used to quickly navigate to areas of code that might be interesting to investigate.
The middle window contains a call graph of the entire binary. You can change from this call
graph view to a flat source code view by hitting the space bar. The space bar will toggle
back and forth between call graph view and flat view.
Before examining the source code, let us first set up IDAs debugger. In the menu bar,
select Debugger, then at the dialog box, select the Local Win32 debugger.

Once the debugger is set, the green debugging arrow should be activated.

Before we begin debugging, lets navigate around the code to find some interesting
landmarks. Right at the start, we can see a call being made to a Windows API,
IsDebuggerPresent. According to the Microsoft Developers Network documentation, this
function determines if the calling process, i.e. crackMe, is being debugged by a user-mode
debugger. It sets EAX to 1 if the calling process is being debugged. It sets EAX to 0 if the
calling process is not being debugged. If we were to start the IDA debugger (green arrow
button or hit F9 key), crackMe simply exits. So we will have to deal with this common antidebugging technique.
Scrolling down a little ways, we see what looks to be a command prompt asking for the
passphrase and then some sort of comparison routine. Note the hard-coded string that is
moved into the ECX register:

It looks like this comparison routine is comparing the users command line input to the
hard-coded string ericroolz.

Just by static examination, we managed to extract the passphrase. We can test that by
running crackMe from the command line and typing in ericroolz and we should get the
Correct password message. That is one way to defeat this example. But suppose we did
not see the passphrase, perhaps it was obfuscated or encrypted, or buried in thousands of
thousands of lines of code. All is not lost, we can use IDAs debugger to step to this crucial
decision point:

Then we can manipulate the results of EAX or the JNZ command to always take the path to
the correct password message. But first, we are going to have to deal with the
IsDebuggerPresent check at the start of this code. First, lets set a break point at the very
start of the program, like in the screenshot below (hit the F2 key and you will see a red
band indicating the break point is set):

Now hit run or F9. We should break:

While we are at this break, hit the G key and type kernel32_IsDebuggerPresent in the
resulting dialog box. It is important to have the kernel32 and the underscore along with the
IsDebuggerPresent):

you should wind up here:

Next, set a break point (F2) at the retn instruction at address 7C8130B0:

Right-click on that break point and select Edit Breakpoint. In the resulting dialogbox, you
want to set the condition of EAX=0 and unselect the Break (under Actions) check box. Next
click OK:

,
We are setting the break point in such a way that we are not suspending the program when
we hit the break point, but simply setting the return value (stored in EAX) from
IsDebuggerPresent to always be 0, that is, regardless of the fact that we are running
crackMe in IDAs debugger, the condition will always return false and we will fool the
program into continuing with our debug session.
Next, hit the G key again and type in eip in the box. This will take us back to our current
break point, that is, to where the current instruction pointer is pointing to:

Next, we are going to want to navigate to that crucial decision point we saw earlier during
our static analysis:

So let us go to loc_401067 and set a break point there. We can use the G key and type in
the address to take us there:

Now after hitting F9 again, the debugger runs to this break point we just set. Open the
resulting command window and enter any passphrase you want (I typed in whatever then
hit the enter key):

After typing any phassphrase, we hit the breakpoint. Note the value in the EAX register. It
is a 1. The TEST EAX, EAX instruction is checking whether EAX is 0 or not. Since it is 1, the
JNZ command will jump us to the incorrect password message. We dont want that. We
can do one of two things:

1. We can change the value of EAX by highlighting the EAX register, right clicking and
choosing the Zero value. This will change EAX to 0 and we will take the path to the
correct password message.
2. We could step past the TEST EAX, EAX instruction and pause on the JNZ instruction. If
EAX was 0, the TEST instruction would set the zero flag (ZF = 1) but since what I typed in
wont match ericroolz either, the zero flag will not be set (ZF=0). We can simply change
the zero flag by right clicking on the ZF value and choosing Increment value. This will
increment the ZF to 1 from 0, thus causing the JNZ instruction to take the correct password
message.
I will demonstrate method number 1. You may re-run this example and try method 2 if you
wish. Right-clicking on the EAX value:

We will just 0 out EAX:

Note that the EAX value changed to 0 and if we single step past the TEST instruction:

You should see the red arrow pointing to the correct password message blinking. That
signifies that we will take that path after setting EAX to 0. If we continue to run the
debugger (F9) we should see that even though we clearly entered the wrong key, we still
were able to unlock our program:

Now that we know the crucial decision point, we could use an editor such as OllyDbg and
change the JNZ instruction to something that will always jump to the correct message
location no matter what passphrase is typed in.
Although, this example was rather simple, it does illustrate the power of using a
disassembler and a debugger. Even though we do not possess the source code, that did not
prevent us from learning how our target binary worked. Once we understood how our
binary worked, we were able to manipulate it into unlocking itself.