Applied Reverse Engineering With OllyDbg

Abstract

The objective of this paper is to show how to crack an executable without seeing its source code, using the OllyDbg tool instead. Although many tools can do the same thing the beauty behind OllyDbg is that it is simple to operate and freely available. We have already done much of reversing .NET applications earlier; however, it is relatively easy to do it in the context of a .NET binary because they can be disassembled into their source code. This is not possible in the case of a C/C++ binary. They can only be disassembled into typical assembly language code that is very difficult to scrutinize. This time, we are presented with an application that whose origin is unknown altogether. In simple terms, what we are implying is that we don't have the actual source code and development environment indeed. We have only the executable version of that specific application, which when disassembled and the code is analyzed is in fact, a tedious task in the context of Reverse Engineering.

Essentials

The security researcher must have rigorous knowledge of Assembly Programming language. It is expected that their machine must be configured with the following tools.

• OllyDbg
• Assembly Programming knowledge
• CFF explorer

Patching Native Binaries When the source code is not provided, it is still possible to patch the corresponding software binaries to remove various security restrictions imposed by the vendor as well as fix the inherent bugs in the source code. A familiar type of restriction built into the software is copy protection which is normally forced by the software vendor to test the robustness of the software copy protection scheme. Typically in copy protection, the user must register first for the product before use. The vendor stipulates a time restriction for the beta software order to be license misuse and permits the product to run only in a reduced-functionality mode until the user registers. Executable Software

The following sample shows how to bypass or remove the copy protection scheme to use the product without extending the trial duration or in fact, without purchasing the full version. The copy protection mechanism often involves a process in which the software checks whether it should run and, if it should, which functionality should be exposed. One type of copy protection common in trial or beta software, allows a program to run only until a certain date. To explain reverse engineering, we have downloaded the beta version of the software from the internet which is operative for 30 days. As you can see, the following trial software application has expired and is not working further and is showing an error message when we try to execute it.

We don't know what programming language this software was developed in or which platform it was developed under. So, the first task is to identify its origin. We can engage the CFF explorer, which displays some significant information, such as that this software was developed using the VC++ compiler as in the following.

So, we can easily conclude that this is a native executable and it is not executing under the CLR. We can't use ILDASM or Reflector to analyze its opcodes. This time, we need to elect a different approach to crack the native executable. Dissembling with OllyDbg When we attempt to load the SoftwareExpiration.exe file, it will refuse to run because the current date is past the authorized trial expiration date. How to use this software regardless of the expiration of the trial period? The following section illustrates the procedure in the context of removing the copy protection restriction. The Roadmap.

The following is the roadmap.

• Load the expired program to understand what is happening behind the scenes.
• Debug this program into OllyDbg.
• Trace the code backward to identify the code path.
• Modify the binary to force all the code paths to succeed and never hit the trial expiration code path again.
• Test the modifications.

Such tasks, however, can also be accomplished by one of the powerful tools. IDA Pro however is commercialized and not available freely. OllyDbg is not as powerful as IDA Pro but useful in some scenarios. First things first, download OllyDbg from its official website and configure it properly onto your machine. It looks as in the following.

Now open the SoftwareExpiration.exe program in the OllyDbg IDE from the File Open menu and it will decompile that binary file. Don't be afraid of the bizarre assembly code because all the modifications are done in the native assembly code. Here, the red box shows, the entry point instructions of the program are referred to as 00401204. The CPU main thread window displays the software code in the form of assembly instructions that are executed from the top down. That is why as we stated earlier, assembly programming knowledge is necessary when reversing a native executable.

Unfortunately, we don't have the actual source code so how can we inspect the assembly code? Here the error message “Sorry, this trial software has expired” might help us to eliminate this problem because by using this error message, we can identify the actual code path that produces the message. While the error dialog box is still displayed, start debugging by pressing F9 or from the Debug menu. Now, you can find the time limit code. Next press F12 to pause the code execution so we can find the code that displays the error message. Okay. Now view the call stack by pressing Alt+ K. Here, you can easily determine that the trial error text is a parameter to MessageBoxA as in the following.

Select the USER32.MessageBoxA near the bottom of the call stack and right-click and choose "Show call" as in the following.

It shows the starting point in which the assembly call to MessageBoxA is selected. Notice that the greater symbol (>) next to some of the lines of code indicates another line of code jumps to that location. Directly before the call to MessageBoxA (in red color right-pane), four parameters are pushed onto the stack. Here the PUSH 10 instruction contains the > sign that is referenced by another line of code.

Select the PUSH 10 instruction located at the address 004011C0, the line of code that references the selected line is displayed in the text area below the top pane in the CPU windows as in the following.

Select the text area code in the preceding figure and right-click to open the shortcut menu. It allows you to easily navigate to the code that refers to a selected line of code as in the following.

Up until now, we have identified the actual line of code responsible for producing the error message. Now it is time to make some modifications to the binary code. The context menu in the previous figure shows that both 00401055 and 00401063 contain a JA (jump above) to the PUSH 10 used for the message box. So, first, select Go to JA 00401055 from the context menu. You should now be in the code at location 0x00401055. Your ultimate objective is to prevent the program from hitting the error code path. So this can be done by changing the JA instruction to an NOP (no-operation) that does nothing. Right-click the 0x00401055 instruction inside the CPU window and select binary where click over Fill with NOPs as in the following.

This operation fills in all the corresponding instructions for 0x00401055 with NOPs as in the following.

Go back to PUSH 10 by pressing the hyphen (~) and repeat the previous process for the instruction 0x00401063 as in the following.

Now save the modifications by right-clicking in the CPU windows. Click "Copy to Executable" and then click "All Modifications". Then hit the "Copy all" button in the next dialog box as shown below.

Right after hitting the "Copy all" button, a new window will appear named SoftwareExpiration.exe. Here, right-click in this window and choose "Save File" as in the following.

Finally, save the modified or patched binary with a new name. Now load the modified program, and you can see that no expiration error message is shown. We have successfully defeated the expiration trial period restriction.

Final Note

This article shows one way to challenge the strength of the copy protection measures using OllyDbg and identify ways to make your software more secure against unauthorized consumption. By attempting to defeat the copy protection of your application, we can learn a great deal about how robust the protection mechanism is. By doing this testing before the product becomes publically available, we can modify the code to circumvent the copy protection and make it more sophisticated before its release.