Applied Reverse Engineering With IDA Pro

Introduction

 
This piece of the editorial is committed to subverting the essential security restriction mechanisms of a native binary executable by employing the IDA Pro Dissembler. This paper is basically elaborating a very complex mechanism of reverse engineering among the previously demonstrated papers yet because it is a very exhausting and long process, claims proportions of patience and proficiencies in machine code instructions but it is very interesting and challenging. We have mostly focused on .NET reverse engineering so far which is relatively an easy task instead of native binary reversing because source code is straightforwardly manipulated by dissemblers. This article would surely assist the aspirants who are repeatedly seeking a step-by-step tutorial on IDA Pro reverse engineering because no such paper is perfectly crafted in a laborious fashion so far.
 
This article is showcasing the particulars of these contents:
  • Live Binary Sample Target
  • Target Analysis with IDA Pro
  • Cracking the Target
  • Alternative way of Tracing
  • Final Note
There are "n" numbers of approaches for reverse engineering and choosing the appropriate one depends on the target program, the platform on which it runs and on which it was developed, and what kind of information you're seeking to extract. Generally speaking, one of the fundamental reversing methodologies is an offline analysis that is all about taking a binary executable and using a disassembler to convert the machine code into a human-readable form. Reversing is then done by manually reading and analyzing parts of that output. Offline code analysis is a powerful approach because it provides a good outline of the program and makes it easy to search for specific functions that are of interest.
 
The disassembler is one of the most significant reverse-engineering apparatuses. Essentially, a disassembler decodes binary machine code into a readable assembly language code. The disassembler merely decodes each instruction and creates a textual representation for code. It is trivial to say, the specific instruction encoding format and the resulting textual representation are entirely platform-specific. Each platform provisions a different set of instructions and registers. Therefore a disassembler is also platform-specific (even though there are a couple of disassemblers that contain specific support for multiple platforms).
 
Essentials
  • The target file
  • IDA Pro Interactive Dissembler
  • PE signature verifier
  • Assembly Language skills
Live Binary Sample Target
 
This time, I have chosen a target binary that over Reverse Engineering is being applied and its origin is in fact, totally unknown to us. This executable basically first validates the user identity by asking for the password. If the user enters the correct information then he would be able to proceed, otherwise, it echos the wrong password message over the screen. But we have obtained this binary from some unauthentic resources. Thus we are not provided the user password token key that would probably have part of the license key. Luckily, we have only the executable, not the source code, so that we can determine the mechanism implemented behind the scenes.
 
enter password
 
Figure 1.1
 
So the only possibility remaining to carry on without buying the license code is to reverse engineer this binary file using the IDA Pro dissembler. It is indispensable to confirm whether this target binary is a standard windows PE file or belongs to some other platform because it is necessary for a binary file to have the PE file signature, otherwise IDA Pro won't dissemble it. So to do this, we can assist PE Explorer to obtain the signature information of this binary as in the following in the file Header section.
 
Binary Sample Target
 
Figure 1.2
 
The previous figure is clearly expressing that this binary has a Windows PE signature and hence can be dissembled by IDA Pro. We will elaborate on that in the next section.
 
Target Analysis with IDA Pro
 
Well, we have obtained the origin information of the target file so far using PE explorer. As we have stated earlier, reversing with IDA pro is truly a laborious task because we would need to encounter trivial machine code. We don't have the source code, rather only the binary executable. However, we first decompile or dissemble the binary using IDA Pro to comprehend what mechanics are implemented implicitly. Thus, launch the IDA Pro software and it would ask to choose the prototype of a new disassembled file as in the following:
 
IDA Pro
 
Figure 1.3
 
After configuring the disassembled prototype as a new project, the IDA prompts to open the target binary as in the following figure.
 
Target Analysis
 
Figure 1.4
 
Right after choosing the target file, IDA Pro displays a screen dialog that states that three types of a file to be reversed are PE files, DOS Executable Files, and binary files. These file types basically specify the platform on which they were developed. In our scenario, the PE file is the best fit because we have chosen a Windows 32 console application as in Figure 1.2. Apart from that, we can organize another option such as processor type, kernel, and DLL renaming as in the following:
 
portable executable
 
Figure 1.5
 
Finally, click OK. Don't bother ahead because IDA Pro prompts a couple of alert messages and opens 2 dialog windows. On the whole, much of the internal processing is done before opening a target file.
 
As you can grasp in the Red box in the following Figure 1.6, we have a function window that is enumerating all the methods and routines used in this executable. The graph windows create the control execution in the flowchart format stated in the Red box. It provides a draggable and moveable dashed rectangle box that can let us reach anywhere in the code execution.
 
In the Blue box, it shows the decompiled code in assembly code format, and most importantly, we can access any segment of code such as entry point, contained text string, binary pattern, and marked position by just dragging the pointer in the first Red box.
 
decompile source code
 
Figure 1.6
 
The important point to note here is that the Debugger Menu would only be visible if the target file has the correct PE signature, otherwise, it remains invisible. That is why it is better to identify the first signs of the target file using PE explore. We shall accomplish the task of logic tracing by debugging the decompiled file. We however choose the appropriate debugger. In our case, we select Local Win32 debugger as in the following:
 
local win32
 
Figure 1.7
 
After ensuring the mandatory configuration, it is time to correlate with the actual mechanism using the arrow shown in the following Figure 1.8. It basically requires some hit and miss to determine the actual execution code path by dragging the pointer. The alert string message shown in Figure 1.1 assists us to determine the execution path. In fact, this target file shows numerous execution paths and some of them are useful in the context of reversing and the remaining is useless. So, the code flow that shows the alert message “Enter the password” is very significant from the reversing point of view because this is the key-value or entry point by which we can trace the essential code.
 
essential code
 
Figure 1.8
 
After moving the pointer to a specific location, we can find the actual mechanism logic flow as in the following. It is typically showing the control flow when we enter the wrong password value.
 
mechanism logic flow
 
Figure 1.9
 
The logic path flow is shown in the previous figure usually does not fit in the work area window. For this purpose, we can move the dashed rectangle in the graph overview by dragging it to reach a specific segment as in the following:
 
graph overview
 
Figure 1.10
 
After moving the pointer to an appropriate location, we have found the decompiled code in an assembly language format. Here, we can easily assume that this program prompts the user to enter the password by the scanf method shown in the Red box. Then this value is compared to a predefined string value (the password) using the strcmp method. The test eax register is holding the value 0 or 1 that would come based on the string comparison. Finally, the jnz instructs the compiler to directly jump to the false segment branching that is at location 411444.
 
location 411444
 
Figure 1.11
 
If the eax register contains the value 0 then the condition would be true and the code execution is directed to the box highlighted by the Cyan color and if it has the value 1 then the control flow diverts towards the false condition block as in the following:
 
condition block
 
Figure 1.12
 
If the user enters the correct password, the following assembly code segment would be executed in which first the “congratulation” message would be displayed along with the actual password information as in the following:
 
assembly code segment
 
Figure 1.13
 
As we have stated earlier, the code flow instruction is huge in quantity, so we need to move the dashed rectangle from time to time in order to reach the specific code block. This time move to false condition block as in the following:
 
drag the outlined box
 
Figure 1.14
 
If the eax register doesn't the contain value 0, then the execution is diverted towards the following figure block where the “Wrong Password! Try again” message will be print on the screen.
 
Wrong Password
 
Figure 1.15
 
Finally, no matter what value the eax register holds, the compiler always executes the following assembly instruction where the getch method is encountered every time as in the following.
 
getch method
 
Figure 1.16
 
So, we have successfully disassembled the target assembly code to correlate the actual mechanism running behind the scenes. We have come to the conclusion that the eax register value is the key hack. If its value is 0 then we have entered into a true condition code block otherwise we have entered into a false condition block.
 
Cracking (Reversing) the Target
 
So, the eax register value would be the key interest for the reverser to subvert the password mechanism, if we change that value manually during debugging then we can reach the true condition block even if we enter the wrong password information.
 
In this encounter, our leading objective is to collapse the jump statement (jnz) execution so that the calling of the method loc_411444 won't happen. To do so, run this application in debugging mode. However, place a breakpoint at the eax instruction using F2. The instruction would be submerged in the Red box as in the following:
 
Cracking the Target
 
Figure 1.17
 
Then run this executable by Start-Process (F9) from the debugger. Then again, a couple of windows appear and disappear as usual.
 
debugger
 
Figure 1.18
 
Then the target starts to execute in command prompt mode because it is a console application. Here, it asks the user to enter the password as in its functionality but unfortunately, we don't have the password. So, just enter any value as a password and press Enter.
 
Wrong Password enter
 
Figure 1.19
 
The moment you press Enter after entering the bogus password value as the test, the execution is transferred to the IDA View-A and we will reach the instruction where we placed the breakpoint earlier. Then we need to move ahead manually by pressing step into (F7) and we step forward to the jump instruction. Here, you notice that the Green arrow (in the Red box) started blinking that is pointing out that the execution is about to transfer to the B31444 method block. If we didn't do anything, the wrong password message is displayed as usual.
 
B31444 method
 
Figure 1.20
 
The execution is transferred to the B31444 (false condition) block because the eax register has the value 1. The transmission to the false condition block is done due to the ZF value of 0. If this value would have 1 then the true condition block would execute.
 
eax register
 
Figure 1.21
 
However, if we modify the value of ZF to 1, then we could control the code path execution to the true condition block. In order to change this value, right-click over the value and select Modify the value as in the following:
 
modify value
 
Figure 1.22
 
Here, just replace the ZF register value as 1 to 0 and click Ok.
 
ZF register value
 
Figure 1.23
 
The moment the ZF register value is changed to 1, you would notice that the execution flow is instantly changed to the true condition block by repeatedly blinking the red arrow in the box as in the following:
 
execution flow
 
Figure 1.24
 
Now, go to the debugger menu and press Run until the return option ends the execution after reaching the end of Code. Bingo! The target binary is showing the congratulation message even if the wrong password value was entered. In addition to that, this program shows the original password value as Ajay.
 
congratulation message
 
Figure 1.25
 
So, we have successfully subverted the password security mechanism just by diverting the binary code flow execution. But forget the common misconception; we have reverse engineered this target file, not the patched actually. The password restriction still exists because we have not modified the corresponding bytes so far.
 
An alternate way of Tracing
 
Identification of the program entry point is always complex in IDA Pro because it shows raw assembly code. We have applied such a process by moving the arrow as in Figure 1.8. But in fact, this is a very cumbersome task. There is another way that eases the task of identifying such entry points.
 
A program displays some string to carry on the execution ahead or to assist the user to control the execution. Just consider the following figure, it asks the user to enter the password by prompting the “Please enter the password” string.
 
Alternate way of Tracing
 
Figure 1.26
 
This string could be beneficial in terms of finding the entry points. So go to the text in the Search menu and enter this string in the box that finds such entries in the assembly code as in the following.
 
search down
 
Figure 1.27
 
Alternatively, the string window displays all the built-in string values of the target program. Just double-click over the “Please enter the password” string, which redirects us to its assembly code.
 
string window
 
Figure 1.28
 
Here, we didn't find the code execution in flowchart format, instead of in the actual assembly code. So we have reached the location where the string is located. Place the breakpoint here by F2 as earlier. Therefore follow the operation or procedure as done earlier from Figure 1.18.
 
performed earlier
 
Figure 1.29
 
Final Note
 
This rare piece of artifact illustrated the process of disassembling as well as reverse engineering tactics over a native binary using IDA Pro disassemble. We saw the importance of the register value of binary code to correlate with the actual program implementation and what role they can play in reversing the process. We have subverted the password mechanism just by modifying the value of the ZF register that is connected to the eax register. The tutorial that applied to the binary target is dedicated to reversing the logic flows only, not patching the byte code associated with the mechanism. There is no permanent change that happens in memory-related bytes, if we run this target again without IDA Pro, the password mechanism is still there and it is not bypassed yet. We will discuss that in detail byte patching in the next article.