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.
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.
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:
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.
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:
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.
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:
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.
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.
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:
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.
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:
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:
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:
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.
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.
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:
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.
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.
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.
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.
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:
Figure 1.22
Here, just replace the ZF register value as 1 to 0 and click Ok.
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:
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.
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.
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.
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.
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.
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.