• About Me
  • Blog
  • Home

Eric Hokanson

~ E's little space in cyberspace

Eric Hokanson

Category Archives: Reverse Engineering

Reverse Engineering with OllyDbg

17 Friday Apr 2015

Posted by Eric Hokanson in Malware RE, Reverse Engineering

≈ 3 Comments

Tags

OllyDbg Tutorial, Reverse Engineering, Reverse Engineering Malware

OllyDbg is a 32-bit disassembler/debugger for Microsoft Windows binary files.  It is shareware and it is available here.  The goal today is to provide a tour of OllyDbg and how the tool can be used in reverse engineering software or malware.  We will learn many of Olly’s features while attempting to unlock a “trial” software whose trial time has expired.

Prerequisites

  • You should have a good understanding of Intel x86 assembly opcodes; not how to program but at the very least, know how to it.  You will also need the following tools:
  • OllyDbg v1.10
  • CFF Explorer.  Available here.

And if you want to follow along, I created a simple little CrackMe program that you can download from here.

A Tour of OllyDbg

The following figure shows the various components inside the OllyDbg debugger:

OllyDbg

Figure 1: OllyDbg’s Debugging EnvironmentThe following figure gives the “lay-of-the-land” inside the debugger and its various components.

The Window with the disassembly and byte-code instructions is called the CPU window, there is a window that shows the current register settings and the EFLAGs register settings, the hints pane will display useful information such as register or address values while single-stepping through the code, you can always view the memory contents of data and registers in the memory view window, and the stack window shows the current stack setup during your debugging session.  Also note that OllyDbg “speaks” Windows API and will resolve any API information, arguments, and strings in the CPU window next to the op-codes.

OllyDbg View Menu and Windows

OllyViewMenu

Figure 2: Menubar -> View

OllyDbg’s View menu will open new windows to view a process’ threads, handles it has open, its layout in memory and breakpoints.  Note that many of the view menu items have hot-key commands.  For example, the key sequence of Alt+B will open the Breakpoints window to view all of the breakpoints set in your debugging session.  You may also call up many of the view menu options by clicking on the corresponding blue buttons (L, E, M, T, etc).

OllyLogWindow

Figure 3: Log Window

Clicking on the Log (Alt+L) option will bring up the Log Window.  This window displays all debugging events such as module loads, thread creations, breakpoint hits, and errors.  If you need to do some trouble-shooting during your debugging session, the Log Window may be useful in tracking down unusual or unexpected behaviors while stepping through mal-code.  The Log window is also useful in checking to ensure any plug-ins you installed were loaded correctly.  Any plug-in loading errors can usually be attributed to placing the plug-in in a directory other than Olly’s default plug-ins directory.  Two recommended plug-ins you should get are OllyDump to dump a process’ memory and Olly Advanced to get around any anti-debugging a malware sample may throw against you.  The OllyDump plug-in will come in handy during manual unpacking and it contains two heuristics for locating the OEP (Original Entry Point).  OpenRCE (www.openrce.org) has OllyDump, Olly Advanced, and many other useful plug-ins to help hide the debugger from malware attacks or to help automate your dynamic analysis process.

OllyExecutableWindow

Figure 4: Executable Modules Window

OllyNamesWindow

Figure 5: Names Window

The Executable Modules Window shows the base virtual address, the virtual size (the size the binary takes up in memory), the Entry Point’s virtual address, the module name, file version, and file path for each module loaded in the process.  Red text means that the module was loaded dynamically.  While in this window, right-clicking on a module opens a context menu.  Choosing the “View names” (Ctrl-N) opens the Names Window.  The Names Window shows the list of imported and exported functions for a given module.  Examining a malware’s imported functions may give a general idea of the malware’s functionality.  For example, if you see functions opening an internet connection and downloading files from an URL, the sample may be a downloader.  The MSDN API documentation site (www.MSDN.microsoft.com) is a useful resource in looking up these functions to learn what they do, the parameter’s these functions take in, and what these functions return.
While in the Names window, you can right-click on any of these functions names to toggle a break point (Right-click -> “Toggle breakpoint” or press the F2 key).  This allows you to set breakpoints on API functions.  For example, many malware will use the API IsDebuggerPresent to check if they are being debugged and attempted to kill the debugger.  Setting breakpoints on these API’s will help you navigate quickly to those parts of code that have anti-debugging checks so you can defeat them.

OllyDbg’s Memory Map window shows the virtual address, the virtual size, the owner module, section names, memory allocation type and memory protection for each allocated region of memory in the process.

OllyMemMapWindow

Figure 6: Memory Map Window

OllyDbg’s Threads window shows the thread ID, Entry Point virtual address, the Thread Environment Block (TEB) virtual address, the last-error value, status such as, active or suspended, the priority, and the timing information for each thread in the process.

The Windows window displays the Handle, Title, Parent Window, Window ID, Window Style, and Window Class Information for each window owned by the process.

The Handles window shows the object type, reference count, access flags, and the object name for each handle owned by the process.

The SEH (Structured Exception Handler) chain window shows the Structured Exception Handler functions for the current thread.  See the figure below for the Threads, Windows, Handles, and the SEH windows.

Figure 7: The Threads, Windows, Handles, and SEH windows

Figure 7: The Threads, Windows, Handles, and SEH windows

OllyDbg has a Call Stack window that is very useful in observing the call stack for the current thread.  The Stack window shows the virtual address of stack frame for each function call, the stack contents at that virtual address, the procedure and its arguments as pushed on the stack, as well as who called the procedure.

Figure 8: The Call Stack Window

Figure 8: The Call Stack Window

And finally, the Breakpoints window shows all the user-set software breakpoints in the process.

OllyBreakPoints

Figure 9: Breakpoints Window

The window shows the virtual address of all software breakpoints currently set, the active status (always, disabled), and the disassembly instruction of the breakpoint.  You can right-click on this window to disable or delete the breakpoints that have been set.

OllyDbg Hotkeys

There are several hotkeys that you will find useful during your debugging session.  They are:

  • F7 – the Step Into command.  This key single-step traces one instruction at a time
  • F8 – the Step Over command.  This key single-step traces one instruction except for CALL instructions.  When used on a CALL, F8 sets a breakpoint after the CALL and runs the debuggee.  This is handy for stepping over C-runtime libraries, such as printf, scanf, etc.
  • F9 – Run runs the debuggee
  • F2 – Set Breakpoint sets a software breakpoint on the currently selected instruction.

Other OllyDbg Functionalities

In OllyDbg’s menu bar, the Debug menu allows you to set both hardware and software breakpoints, single step instructions, restart the debugging session, perform conditional tracing , or to set commandline arguments for the debuggee.
OllyDbg has many context menus.  You can right-click on almost anything in OllyDbg to get a context menu to examine your many debugging options.

Reversing with Olly

With our tour of Olly behind us, we are now ready to start doing some real work: reversing and cracking a “trial” piece of software.  First, it is usually a good idea to configure OllyDbg to ignore exceptions and to show loops.  In the OllyDbg menu bar, go to Options, then Debugging Options:
In the Exceptions tab, make sure your settings look like Figure 10.

Figure 10: Configure Olly to Ignore Exceptions

Figure 10: Configure Olly to Ignore Exceptions

To set the “Ignore also following custom exceptions or rages:” select the check-box and then click the add range button.  In the top dialog box type eight 0’s (00000000) and in the second type eight F’s (FFFFFFFF).

Next click on the CPU tab and make sure the boxes highlighted in Figure 11.

DebuggingOptionsLoops

Figure 11: Debugging Options to Show Loops

Meet the Debuggee

To demonstrate the power and functionalities of OllyDbg, we will use a sample that has some copy protections.  Say we downloaded a trial piece of software that expires after a certain date or after 30 days.  As you can see in Figure 12, the following “trial” software is expired and no longer working.  All we get is an error message when we attempt to execute it.

Figure 12: Software Trial has Expired

Figure 12: Software Trial has Expired

The first thing we should do is assess the software with CFF explorer to identify the development language used and some other particulars.

Figure 13: CFF Explorer

Figure 13: CFF Explorer

CFF explorer has some built-in functionalities to calculate the MD5 and SHA-1 hashes of our sample.  Dependency Walker lists the DLL’s this sample relies on, and we can see that the sample was compiled with Visual Studio C++ 8, which is Visual Studio 2013.  Since we have a native executable, tools such as ILSpy, ILDASM, and Reflector can’t be used to analyze this sample’s opcodes.  We will need to rely on OllyDbg.

Open the CrackMeDemo.exe program in OllyDbg.  In the menu bar, select File then open to navigate to the location of CrackMeDemo.exe.

Figure 14: Opening CrackMeDemo in Olly

Figure 14: Opening CrackMeDemo in Olly

Olly will disassemble the binary file and it will look something like Figure 15.  After disassembly, Olly will take us to the entry point, which for this sample is at virtual address 0x40129E.  At this point, the question we are now faced with is where to begin?  We could scroll through this sample’s opcodes and look for the error message we encountered but that could be tedious if there are thousands of lines of code.  Instead, we will use the power of the debugger to help us locate the error message.

By hitting F9 to run the debugger, we should encounter the error message as seen in Figure 16.  Now we will attempt to find the time limit checking code.  Next press F12 to pause the debugging execution.  Note the yellow “Paused” message in the debuggee status.  With the execution paused, we now can search for the code that causes the error message.

Figure 15: CrackMeDemo at Entry Point

Figure 15: CrackMeDemo at Entry Point

One way to look for our error message is to examine the current call stack since the error message is currently displayed at this point.  To view the call stack, press Alt+K.  From this vantage point you can easily see that the error message string is a parameter of the MessageBoxA function call (see Figure 17).
Select the USER32.MessageBoxA near the bottom of the call stack.  Then right-click and choose “Show Call” (see Figure 18).  This will take us to the starting point in the CrackMeDemo’s software where the call to USER32.MessageBoxA is made (Figure 19 ).

Figure 16: Running the debuggee

Figure 16: Running the debuggee

Figure 17: The Call Stack Window (Alt+K)

Figure 17: The Call Stack Window (Alt+K)

Figure 18: Show Call

Figure 18: Select Show Call

Figure 19: The Start of MessageBoxA call in debuggee

Figure 19: The Start of MessageBoxA call in debuggee

Notice at the line highlighted in Figure 19 the “>” symbol.  This “>” symbol indicates that other parts of code jumps to this location.  Notice in the API information section in Figure 19 shows the MessageBoxA call and its parameter’s just above it.  The parameters start with the PUSH 10 instruction at 0x401042.  Since we are at the PUSH 10 instruction (indicated by the grey line), we can examine the Hints pane to see the parts of code that references this call:

Figure 20: The Hints pane shows two places that jump to this error message box

Figure 20: The Hints pane shows two places that jump to this error message box

Select the text area of the hints pane and right-click to open a context menu.  It allows you to easily navigate to the code where those jumps are made:

Figure 21: Context menu of hints pane

Figure 21: Context menu of hints pane

We see two jumps, a JNZ from 0x401060 and a JE from 0x401064.  Now we can modify those parts of the code.  Select the JNZ from 0x401060 from the context menu.  This will take you to the jump command at 0x401060.  In order to prevent the program from hitting this error code path, we can change the jump instruction to a NOP (no operation) instruction.  Right click on the instruction at location 0x401060 inside the CPU window and select “Binary” and then click on the “Fill with NOPs” as shown in Figure 22.

Figure 22: Binary patching with NOPs

Figure 22: Binary patching with NOPs

The operation overwrites the JNZ instruction with NOPs, thus eliminating that code path (or jump) to the error message.  Next go back to the PUSH 10 instruction of the MessageBoxA by pressing the minus sign key (-) and repeat the process for the JE from 0x401064.

Figure 23: the JNZ instructio is filed with NOPs

Figure 23: the JNZ instructio is filed with NOPs

Once your two jumps to the error message are patched with NOPs, save the modifications by right-clicking in the CPU window, click on “Copy to Executable”, and then select “All Modifications.  Hit the “Copy all” button in the resulting dialog box as shown in Figure 24 and Figure 25.

Figure 24: Copy to Executable -> All modification

Figure 24: Copy to Executable -> All modification

Figure 25: Resulting Dialog Box after Figure 24

Figure 25: Resulting Dialog Box after Figure 24

After selecting the “Copy all” button, a new window appears as in Figure 26.  Right click on this file window and choose “Save File” as in Figure 27.

Figure 26: The CrackMeDemo file window

Figure 26: The CrackMeDemo file window

Figure 27: Saving our changes

Figure 27: Saving our changes

I renamed our fixed CrackMeDemo software and saved it to the desk top.  Double clicking on our new, patched binary should result in:

Figure 28: Success!

Figure 28: Success!

Conclusion

Today we learned our way around OllyDbg and used that information to debug, reverse, and defeat an expiration lock of a “trial” piece of software.

About me: I teach Reverse Engineering and Reverse Engineering of malware at Sandia National Laboratories in Albuquerque, New Mexico.  I also consult with several University Computer Science Departments on how to develop a reverse engineering course.  If you liked this post, feel free to share it with others who may be interested in learning the art of reverse engineering.

 

 

Quote

Debugging

08 Thursday May 2014

Posted by Eric Hokanson in Programming, Reverse Engineering, Software Development

≈ Leave a comment

Tags

Brian Kernighan, Debugging, programming, Reverse Engineering

Debugging is twice as hard as writing the code in the first place.  Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Brian Kernighan

A Simple Demonstration on Reversing Software

03 Saturday May 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

Screen Shot 2014-05-03 at 1.47.38 PM

In our scenario, we have a piece of software that is asking for a passphrase or key to unlock it.  Since we don’t 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 Pro’s disassembler and debugger: we don’t 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:

Screen Shot 2014-05-03 at 1.59.26 PM

Select the “New” button and then open your crackMe binary:

Screen Shot 2014-05-03 at 2.00.00 PM

 

Then click Ok on the “Load New File” Window:

Screen Shot 2014-05-03 at 2.00.19 PM

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:

Screen Shot 2014-05-03 at 2.04.46 PM

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 IDA’s debugger.  In the menu bar, select Debugger, then at the dialog box, select the Local Win32 debugger.

Screen Shot 2014-05-03 at 2.23.53 PM

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

Screen Shot 2014-05-03 at 2.29.38 PM

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 anti-debugging 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:

Screen Shot 2014-05-03 at 2.46.55 PM

It looks like this comparison routine is comparing the user’s command line input to the hard-coded string “ericroolz”.

Screen Shot 2014-05-03 at 2.50.41 PM

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 IDA’s debugger to step to this crucial decision point:

Screen Shot 2014-05-03 at 3.05.53 PM

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):

Screen Shot 2014-05-03 at 3.11.53 PM

Now hit run or F9.  We should break:

Screen Shot 2014-05-03 at 3.14.58 PM

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):

Screen Shot 2014-05-03 at 3.17.37 PM

you should wind up here:

Screen Shot 2014-05-03 at 3.18.44 PM

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

Screen Shot 2014-05-03 at 3.21.13 PM

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:

Screen Shot 2014-05-03 at 3.23.21 PM,

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 IDA’s 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:

Screen Shot 2014-05-03 at 3.29.51 PM

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

Screen Shot 2014-05-03 at 3.05.53 PM

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:

Screen Shot 2014-05-03 at 3.33.24 PM

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):

Screen Shot 2014-05-03 at 3.35.16 PM

Screen Shot 2014-05-03 at 3.38.04 PM

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 don’t 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 won’t 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:

Screen Shot 2014-05-03 at 3.47.57 PM

We will just 0 out EAX:

Screen Shot 2014-05-03 at 3.49.04 PM

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

Screen Shot 2014-05-03 at 3.51.04 PM

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:

Screen Shot 2014-05-03 at 3.54.49 PM

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.

 

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • May 2016
  • May 2015
  • April 2015
  • March 2015
  • September 2014
  • August 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013

Categories

  • Alan Turing
  • Algorithms
  • Apollo 17
  • C Programming
  • Christmas
  • Computer Programming
  • Computer Science
  • Computer Security
  • Current Events
  • Cyber Security Research
  • Education
  • Freedom of choice
  • Freewill
  • Hacking
  • Holidaze
  • Learning
  • Malware RE
  • Math
  • NASA
  • Pen-testing
  • Philosophy
  • Pi Day
  • procrastination
  • Programming
  • Python
  • Quine programs
  • Quotes
  • Random Stuff
  • Research
  • Reverse Engineering
  • Shopping
  • Smithsonian National Air and Space Museum
  • Software Development
  • Star Wars
  • Success
  • Uncategorized

Meta

  • Register
  • Log in

Blog at WordPress.com.

  • Follow Following
    • Eric Hokanson
    • Join 44 other followers
    • Already have a WordPress.com account? Log in now.
    • Eric Hokanson
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...