|< Day Day Up >|
As a software reverse engineer, you are only as good as your tools. Before diving into practical examples later in the chapter, we first review some of the classic Windows RCE tools. Some you can learn in a day, while others may take years to master.
2.2.1 Hex Editors
To edit binaries in hexadecimal (or opcode patching ), you need a good hex editor. One of the best is Ultra Edit, by Ian Meade (http://www.ultraedit.com/), shown in Figure 2-1.
Figure 2-1. For opcode patching, we recommend UltraEdit, an advanced Windows hex editor
A disassembler attempts to dissect a binary executable into human-readable assembly language. The disassembler software reads the raw byte stream output from the processor and parses it into groups of instructions. These instructions are then translated into assembly language instructions. The disassembler makes a best guess at the assembly language code, often with variable results. Nevertheless, it is the most essential tool for a software cracker.
A popular disassembler, and one that is the tool of choice for many expert reverse engineers , is IDA Pro. IDA (http://www.datarescue.com) is a multiprocessor, multioperating-system, interactive disassembler. It has won numerous accolades, not the least being chosen as the official disassembler of the +HCU in 1997.
IDA treats an executable file as a structured object that has been created from a database representing the source code. In other words, it attempts to re-create viable source code (as opposed to W32DASM, which only displays the code it thinks is important).
One of the most powerful features of IDA is the use of FLIRT signatures. FLIRT stands for Fast Library Identification and Recognition Technology. This means that IDA uses a proprietary algorithm to attempt to recognize compiler-specific library functions.
Mastering IDA takes considerable time and effort. The company admits in the user 's manual that IDA is difficult to understand. However, once you have mastered IDA, you'll probably prefer it to the combination of W32DASM + SoftICE (discussed next ). This section walks you through a few basic IDA configuration and manipulation steps.
A configuration file controls IDA's preferences. Search your Program Files directory for the IDA folder and use a text editor to open Ida.cfg (the configuration file). The configuration file is read two times. The first pass is performed as soon as IDA is loaded, while the second pass is performed when IDA determines the processor type. All processor-specific tuning is located in the second part of the config file.
IDA allows you to choose the default processor at program startup. As you can see in Example 2-1, the developers have created support for an extensive range of processor types. Here, you can view the processors that IDA supports. For example, if you mostly crack PocketPC (Windows CE) applications, you will probably be using the ARM processor. Otherwise, the default is setting is " metapc " (x86).
Example 2-1. Processor-specific parameters in IDA Pro
/* Extension Processor */ "com" : "8086" // IDA will try the specified "exe" : "metapc" // extensions if no extension is "dll" : "metapc" // given. "drv" : "metapc" "sys" : "metapc" "bin" : "metapc" "ovl" : "metapc" "ovr" : "metapc" "ov?" : "metapc" "nlm" : "metapc" "lan" : "metapc" "dsk" : "metapc" "obj" : "metapc" "prc" : "68000" // PalmPilot programs "axf" : "arm710a" "h68" : "68000" // MC68000 for *.H68 files "i51" : "8051" // i8051 for *.I51 files "sav" : "pdp11" // PDP-11 for *.SAV files "rom" : "z80" // Z80 for *.ROM files "cla*": "java" "s19": "6811" "o": "metapc"
IDA allows you to tune several options for disassembly. For example, you can determine whether you want to automatically analyze 90h NOPs. The configuration for this is shown in Example 2-2.
Example 2-2. IDA options for disassembly
#ifdef __PC_ _ // INTEL 80x86 PROCESSORS USE_FPP = YES // Floating Point Processor // instructions are enabled // IBM PC specific analyzer options PC_ANALYSE_PUSH = YES // Convert immediate operand // of "push" to offset // // In sequence // // push seg // push num // // IDA will try to //convert <num> to offset. // PC_ANALYSE_NOP = NO // Convert db 90h after // "jmp" to "nop" // Now it is better to turn // off this option // because the final pass // of the analysis will // convert 90h to nops // more intelligently. // // Sequence // // jmp short label // db 90h // // will be converted to // // jmp short label // nop
Now, it's time to fire up IDA. Run the program and open the target binary that you happen to be using. Figure 2-2 shows IDA's startup window.
Figure 2-2. IDA startup window
On most Windows files you will use the Portable Exectuable (PE) format (discussed later in this chapter), so select this option. Select your processor type if you have not already configured the default in your config file. Make sure both "Analysis" options are checked. Under Options, make sure the "Load resources" and "Make imports segment" boxes are checked. Also make sure "Rename DLL entries" and "Manual load" are unchecked.
When you are ready, press OK and watch IDA work its magic.
In order to view strings in IDA, select View Open Subviews Strings (Figure 2-3). You will also see the other subview options. The keyboard shortcut for strings is Shift-F12. Take some time to explore this sample disassembly and to get used to moving around in IDA.
Figure 2-3. Viewing strings in IDA
+Fravia calls SoftICE (http://www.numega.com) the "Alpha and the Omega" of debuggers. However, what many modern reverse engineers are too young to remember (unless your hair is as grey as that of the authors) is that the forefather of SoftICE itself, known as ICE-86, was actually a hardware-based in-circuit emulator from Intel, designed to debug their seminal 8086 processor. A full description of this hardware can be found in the classic 8086 Family User's Manual published by Intel in 1979.
SoftICE allows you to single-step through program code and to edit memory, registers, variables and flags on the fly as the program executes. The following function keys let you step through code and edit memory in SoftICE:
Once you have SoftICE installed, your system will boot WINICE.EXE along with Windows. SoftICE is integrated with the Windows operating system itself, at Ring 0, which is what makes it so powerful. SoftICE is configured by editing the WINICE.DAT file. Remove the semicolons in WINICE.DAT to uncomment the particular features that you need. For example, if you are editing WINICE.DAT to include 32-bit calls (recommended), uncomment the following lines:
gdi32.dll kernel32.dll user32.dll
SoftICE is a complex application. In fact, it comes with a large, two-volume user's manual just to help get you started with the basics of its use. However, the most difficult part of using SoftICE is remembering the command shortcuts. If you are performing RCE with SoftICE, you will need a reference list that you can keep handy while you are cracking. Even the official user's manual for SoftICE doesn't list these critical breakpoints. For this reason, we have included a basic list of useful SoftICE commands and breakpoints in the Appendix. We also recommend that you read through the SoftICE user's manual at least once before working the examples at the end of this chapter.
2.2.4 System Monitors
The wizards at SysInternals (http://www.sysinternals.com) have developed two powerful, real-time system monitors: regmon and filemon . The programs are freely available for personal use, with source code, from their web site. With these two programs, you can see which hidden registry and file calls your target binary is making. The programs are easy to master.
To use filemon, first install and run the program. You'll soon see a flood of data scrolling down the filemon window, which will rapidly overwhelm you. Our goal here is to focus on one application that we want to monitor; i.e., NOTEPAD.exe (Figure 2-4).
Figure 2-4. filemon gathers all system file accesses by default
Immediately after starting the target application, enter Ctrl-E to pause the data capture. Then scroll up until you find the .exe name , and hit Ctrl-L to enter it into the filter window (Figure 2-5).
Figure 2-5. Using the filemon filter
Next, hit Ctrl-X to clear the display and then Ctrl-E to toggle capture on again. You will see that you have a pure capture that is focused on file access by one executable only ”in this case, NOTEPAD.exe (Figure 2-6).
Figure 2-6. Filtered capture of NOTEPAD.exe system file calls
For regmon, the process is nearly identical (Figure 2-7). By using regmon, you can focus on a suspected Trojan, for example, to see the hidden registry calls that it utilizes.
Figure 2-7. Using regmon to trace hidden registry calls
Many commercial software programs are compressed with commercial "packers" (e.g., AsPack from http://www.aspack.com) in order to save space or to frustrate disassemblers. Unfortunately, you will not be able to disassemble a binary if it is packed. Fortunately, there are tools to unpack a packed binary. This section reviews the tools and methods used for unpacking a compressed application so that you may proceed to reverse engineer it.
220.127.116.11 The PE file format
IThe native file format of Windows is the Portable Executable (PE). "Portable" means that all Windows platforms and processors recognize the program. In order to understand the process of unpacking a compressed application, it is first necessary to understand the structure of the Win32 PE file format (Figure 2-8). This format has remained relatively constant over the years, even with newer 64-bit Windows platforms.
Figure 2-8. A simplified representation of the PE file format
The programmer's assembler or compiler creates the PE sections automatically. The purpose of the DOS MZ header is so that if you happen to run DOS (Disk Operating System), DOS can recognize the program. In contrast, the DOS stub is simply a built-in executable provided to display an error message (e.g., "This program cannot be run in MS-DOS mode") in case the operating system does not recognize DOS.
We are most interested in the third section, the PE header , a structure that contains several fields used by the PE loader . When you execute the program on an operating system that can process the PE file format, the PE loader uses the DOS MZ header to find the starting offset of the PE header, thus skipping the DOS stub.
The data in a PE file is grouped into blocks called sections . These sections are organized based on common attributes, rather than on a logical basis. Thus, a section can contain both code and data, as long as they have the same attributes.
Following the PE header is an array of structures known as the section table . A structure holds section-specific data such as attribute, file offset, and virtual offset.
During program execution, the PE header maps each section into memory based on the information stored in the sections. It also assigns attributes to each section in memory based on information in the section table. After mapping the PE file into memory, the PE loader imports data from an array known as the import table .
For educational purposes, at some point you may want to learn how to manually unpack an unknown binary. However, the RCE scene has developed useful tools to help you save time by addressing many commercial packers (make sure to get permission from all relevant software manufacturers before reverse engineering their code). In addition, there are tools to help unpack even unknown compression schemes. ProcDump, written by G-RoM, Lorian, and Stone, is a powerful tool to help with unpacking. Figure 2-9 shows the startup screen, which lists open tasks and modules. Simply press Unpack to start the unpacking wizard.
Figure 2-9. Using ProcDump to unpack a compressed program
After starting ProcDump, you'll see a split-screen GUI. The top contains a list of processes running under Windows; the bottom of the GUI lists all modules attached to a certain process. On the right side of this screen, you'll see the following six buttons :
To unpack an application, start by clicking the Unpack button. Then, choose the name of the commercial or other packing program that protects the program. Next, an Open Dialog will pop up. Choose the executable you want to unpack and click Open.
ProcDump will load the executable in memory. When this is done, hit OK, and the program will unpack automatically.
2.2.6 Personal Firewalls
A personal firewall is a useful addition to the reverse engineer's arsenal. Personal firewalls are software applications that run on end-user machines to filter data passing through the TCP/IP stack. For example, if there is a hidden backdoor installed on your system, a good personal firewall can alert you to normally hidden communication. Similarly, a personal firewall can uncover commercial spyware when it attempts to "phone home." Please note that you still might be fooled, as some products use port redirection/tunneling or even methods as simple as embedding the signal in an allowed SMTP message. An example of a personal firewall is Zone Alarm, from http://www.zonelabs.com.
2.2.7 Install Managers
Install managers are programs that monitor unknown binaries as they install on your system. There are many commercial install managers, like In Control 5 (Figure 2-10).
Figure 2-10. In Control 5 install manager
One way that install managers work is by comparing a "snapshot" of your drive files, startup files, and registry keys before and after installation (Figure 2-11).
Figure 2-11. In Control 5 is comparing registry keys to find what was installed
As you can see, install managers are valuable for detecting hidden system changes during installation. In particular, they are useful to track spyware and Trojan changes to your system so that you can develop disinfection steps by hand. Simply start the uninstall manager, browse to the program you want to install, and then use the uninstall manager to launch the installer.
|< Day Day Up >|