Reverse Engineering with OllyDbg

Abstract

The objective of writing this paper is to manifest, how to crack an executable without peeping its source code by exercising OllyDbg tool. Although, there are much of tools that can achieve the same objective but the beauty behind OllyDbg is that, it is simple to operate and freely available. We have already done much of reversing of .NET application earlier. This time, we are confronting with an application which origin is unknown altogether. In simple term, what we are implying that we don’t have the actual source code indeed. We just have only the executable version of a particular application which is in fact, a tedious task in 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 in order to remove various security restrictions imposed by vendor as well as fix the inherent bugs in the source code. A familiar type of restriction built into software is copy protection which is normally forced by software vendor in order to test the robustness of software copy protection sachem. Typically in copy protection, the user is obligatory to register first for the product before use. The vendor stipulates a time restrictions condition over the beta software in order to be license misuse and permitting the product to run only in a reduced-functionality mode until the user registers.

Executable Software

The following sample shoes a way, how to bypass or remove the copy protection sachem in order to use the product without extending the trail 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 should, which functionality should be exposed.

One type of copy protection common in trail or beta software, allows a program to run only until a certain date. In order to explain reverse engineering, we have downloaded the beta version of software from internet which is operative till 30 days. As you can see, the following trail software application is expired and not working further and showing an error message when we try to execute it.

We don’t know, in which programming language or under which platform this software is developed. So, the first task is to identify its origin. We can engage CFF explorer, which display some significant information such as this software is developed by using VC++ language as following.

So, we can easily conclude that this is a native executable and it is not executing under CLR. We can’t use ILDASM or Reflector in order to analyze its opcodes. This time, we have to elect some different approach to crack the native executable.

Dissembling with OllyDbg

When we attempt to load SoftwareExpiration.exe file, it will refuse to run because the current date is past the date on which the authorized trial expired. How can we use this software regardless of the expiration of the trail period? The following section illustrates the steps in the context of removing the copy protection restriction as;

The Roadmap

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

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

Now open the SoftwareExpiration.exe program in OllyDbg IDE from File à open menu and it will decompile that binary file. Don’t afraid with the bizarre assembly code because all the modifications are performed in the native assembly code.

Here, the red box showing, the entry point instructions of the program referred to as 00401204. The CPU main thread window displaying the software code in form of assembly instructions which are executed top to down fashion. That is why as we stated earlier, assembly programming knowledge is necessary when reversing with native executable.

Unfortunately, we don’t have the actual source code so how we inspect the assembly code. Here the error message “Sorry, this trail software has expired” might help us to get rid of this problem because by help of this error message, we can identify the actual code path that lead to occur this message.

While the error dialog box is still displayed, start debugging by pressing F9 or from Debug menu. Now, you can find the time limit code. Next press F12 in order to pause the code execution so that we could find the code that causes the error message to be displayed.

Ok. Now view the call stack by pressing the Alt+ K. Here, you can easily figure out that the trail error text is a parameter to MessageBoxA as following;

Select the USER32.MessageBoxA near the bottom of the call stack and right click and choose show call as 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 which 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 which is referenced by another line of code.

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

Select the text area code in the above figure and right click to open the shortcut menu. It allow you to easily navigate to code that refers to a selected line of code as shown;

Up till now, we have identified the actual line code that is responsible for producing the error message. Now it is time to do some modification in the binary code. The context menu in the previous figure shows that both 00401055 and 00401063 contains JA (jump above) to the PUSH 10 used for message box.

So, first select the Go to JA 00401055 from the context menu. You should now be on code at location 0x00401055. Your ultimate objective is to prevent the program from hitting the error code path. So this can be accomplished by changing the JA instruction to NOP (no operation) which actually do nothing. Right click the 0x00401055 instruction inside the CPU window and select binary where click over Fill with NOPs as following;

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

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

Now save the modifications by right clicking in the CPU windows. Clicking Copy to Executable, and then clicking All Modifications. Then hit the Copy all button in the next occur 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 following.

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

Final Note

This article demonstrates one way to challenge the strength of the copy protection measure 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 roust the protection mechanism. By doing this testing before the product become publically available, we can modify the code to make circumvent of copy protection more sophisticated before its release.