Reverse Engineering with OllyDbg

17 Friday Apr 2015

Posted by Eric Hokanson in Malware RE, Reverse Engineering

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:

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

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

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.

Figure 4: Executable Modules Window

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.

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

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

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

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

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.

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

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

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

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

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 17: The Call Stack Window (Alt+K)

Figure 18: Select Show Call

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

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

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

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

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 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 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!

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

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:

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

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

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:

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.

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:

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

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:

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

Now hit run or F9. We should break:

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

you should wind up here:

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

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:

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:

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

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:

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

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:

We will just 0 out EAX:

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

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:

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.

ESET Challenge Part 2

10 Friday Jan 2014

Posted by Eric Hokanson in Malware RE

≈ 4 Comments

Tags

ESET ChallengeME 2013, Malware Analysis, Malware Reverse Engineering, Reverse Engineering, Reverse Engineering Puzzles

In part one of the ESET CrackMe 2013 challenge, we:

Did some initial triaging and string analysis in order to try and deduce what the sample may do.
We discovered that it was packed using a UPX packer.
We unpacked the sample by hand using OllyDbg and ImportRec.
Then analyzed the strings of our unpacked sample to see if we could now determine this samples potential capabilities.

Today, we are going to test our theory by actually running and debugging the EsteCrackMe3013 sample. Remember from part one, we did observe some indications of anti-debugging in our string analysis, so it is likely that we will have to try to circumvent those.

First, let’s load our unpacked CrackMe sample into IDA Pro and let it take us to the starting point of the program. A little ways down you can see a series of MOV instructions. This is a long block of move instructions, starting at 0x404679 and ending at 0x407A63:

These look like ASCII characters and if we highlight each character in IDA and hit the ‘r’ key, it will reveal the actual character:

This looks like it might be the message we see printed to the console that we see when we first run the program:

I see an asterisk, some characters, and lots and lots of spaces. I could be hitting the ‘r’ key all day, and it appears that these characters are being loaded “randomly” into random locations. Perhaps they are scrambling the start up message to make static analysis harder. If we set a break point in IDA after all these MOV instructions, then highlight on of the move instructions, right click and jump in a new hex window, we can see:

And that is exactly what all those MOV instructions are doing. Moving the “scrambled” start up message into memory. It also explains why we were seeing lots of spaces.

At the end of the MOV instructions, if scroll down, we see calls to SetConsoleCursorPositon, SetConsoleTitle, and WriteConsole. This is the part of the code that retrieves the start up message lines from memory and prints them to the screen. Once we scroll past the routines that print the start message to the console, that is where things start getting interesting:

After writing the start up message to the console, the program immediately calls a subroutine located at 0x402998. This routine checks if we hit the ‘Enter’ key to continue. Once we hit the enter key, the program calls the subroutine on the next line. At first, I thought this was a TLS callback because I saw evidence of TlsIndex, and calls to TlsGetValue. There appears to be a place for a callback function. However, after hitting CTL-E in IDA, the only starting point I saw was the program’s starting point. I did not see evidence of a TlsCallbackEntry point. I did not spend too much time investigating this subroutine, but, whether a callback is called or not, it appears that the program makes calls to non-returnable functions. These functions eventually cause the program to wend its way to a FreeLibrary call and then eventually to an ExitProcess call. My guess is, that during the normal flow of the program, we call this routine and eventually terminate the program. This subroutine, however, does not prevent us from stepping over this function during a debug session. But if we do, notice that the program loads some value from location 0x40810C, and then calls OutPutDebugString. What do you bet, EAX contains that ‘s%s%s%s%s%s%s…” string sequence we saw in our string analysis in part one?

Sure enough, that is exactly what EAX contains. So, if we step over subroutine sub_40256C, and get to location 0x407BD92, then the program knows it must be in a debugger. It attempts to leverage an old OllyDbg vulnerability that will crash Olly. We can change EAX to 0 to get past that issue, or use a newer version of Olly, or IDA’s debugger.

After surviving our first anti-debugging trick, we now see that there are calls to LoadLibrary, but we don’t know the library’s name because it is disguised at offset dword_407F18:

I suspect, the authors are trying to hide the name of the library loaded. If we highlight, and hit the ‘a’ key, IDA will resolve the above array of numbers to an ASCII string:

We do this to all the obfuscated library names, and we can begin to see clearly what is being loaded:

URLMON and WININET libraries, functions for checking for Internet connections, and to download a file from some location. We also see strings for IsDebuggerPresent and scrolling down a little further we also calls to GetTickCount, and checks to the file segment fs:18h. These are all known techniques for checking to see if the program is in a debugger. If it is, the program can simply terminate the process leaving us high and dry.

We will need to deal with these anti-debugging techniques. Before we start debugging, lets continue our static analysis and scroll down to find some other interesting things such as:

I am not sure what that is. Junk code? The hexidecimal digits look like ASCII symbols. If we highlight and press the ‘r’ key:

Interesting! A key of some sort? Scrolling further down, there are more checks for debugging and calls to GetTickCount, and jumps to ExitProcess if a debugger is detected. But eventually, we arrive to a series of code blocks that call WriteConsole. What other messages are there? Our next goal is to start the debugger, and when ever we come to a check for a debugger, change the jump value in the control flags to avoid ending the process. Lets see if we can get to these WriteConsole calls and see what these messages are.

After a couple of attempts, I finally get to the first WriteConsole call and we see the message:

Continuing, stepping through to the next WriteConsole call, we get our second message:

We continue stepping through to the third call to WriteConsole, and our third hidden message is revealed:

Looks like there is a second leg to our quest! Ok. We got pretty far today. It may be a good idea to re-run this program in our debugger, just like we did above, but this time run procmon and fakenet to see if this program did anything else behind the scenes such as write to the registry, and download any files.

This was a lot of fun and I learned some new tricks in IDA Pro that will be useful in my new position as a malware analyst and researcher. The next step is to visit the site, and get the second part of the challenge, and repeat the process. But that we will have to do another day.

A Malware Analyst’s Bookshelf

02 Thursday Jan 2014

Posted by Eric Hokanson in Computer Security, Cyber Security Research, Malware RE

≈ 2 Comments

Tags

Gary McGraw, Greg Hoglund, Malware, Malware Analysis, Malware Analysis Sources, Microsoft Windows, OllyDbg, Reverse Engineering, Static program analysis

I am often asked by those wishing to pursue a career as a malware analysit, what references are useful in learning, or the continued learning of the art and craft of malware analysis? Here is a list of resources that I find useful:

1. The Art of Computer Virus Research and Defense by Peter Szor (TAOCVRD). This is the book that introduced me to malware research. It could use some updating, but sadly, the author recently passed away. On the other hand, with the popularity of Android malware, what is old is new again. Many Android malware samples are doing what the old Windows malware used to do in the early days.

TAOCVRD covers different malware types, and the armoring, self-protection strategies they employ, the common detection techniques, and the last chapter is a useful guide in setting up your own malware analysis lab. Again, a bit outdated because many of the tools we use today were not widely available back when this book was originally published. However, many of the analysis techniques are still relevant today.

2. Practical Malware Analysis by Michael Sikorski and Andrew Honig (PMA). An introductory tour of malware analysis and reverse engineering techniques. The hands-on labs reinforce the skills covered in each chapter. Each lab has a set of “malware” like samples (download from the book’s website). Introductory chapters cover x86 assembly and the common instructions you will encounter, as well as how to use common tools, such as OllyDbg, and IDA Pro.

3. One of the most powerful tool for static analysis, that I mentioned in (2), is IDA Pro. But it has a steep learning curve. The IDA Pro Book by Chris Eagle is about the only practical users guide available. Whenever I need to learn something new in IDA, or how to write a plugin, I consult this book.

4. Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw. This book shows the common software programming errors and exploitation patterns. Usually, I will start looking for these patterns in the malware samples I am analyzing to help guide my investigations; knowing these patterns can reveal what the malware may be targeting.

5. Reversing: Secrets of Reverse Engineering by Eldad Eilam. This too is a little outdated, but it is the best introduction into the art of RE that I have found so far. It covers the common tools used, the basics of assembly and x86 architecture, basic Windows internals, and even has a chapter on reversing malware.

This list is by no means exhaustive. I am sure I am overlooking other good sources and would be happy to hear what other analysts routinely consult. I am always looking to expand my library.

Eric Hokanson

~ E's little space in cyberspace

Tag Archives: Reverse Engineering

Reverse Engineering with OllyDbg

Prerequisites

A Tour of OllyDbg

OllyDbg View Menu and Windows

OllyDbg Hotkeys

Other OllyDbg Functionalities

Reversing with Olly

Meet the Debuggee

Conclusion

Debugging

A Simple Demonstration on Reversing Software

ESET Challenge Part 2

A Malware Analyst’s Bookshelf

related articles