Eilam E.Reversing.Secrets of reverse engineering.2005

Breaking Protections 371

Figure 11.10 Defender.EXE launched without any command-line options.

Defender takes a username and a 16-digit hexadecimal serial number. Just to see what happens, let’s try feeding it some bogus values. Figure 11.11 shows how Defender respond to John Doe as a username and 1234567890ABCDEF as the serial number.

Well, no real drama here—Defender simply reports that we have a bad serial number. One good reason to always go through this step when cracking is so that you at least know what the failure message looks like. You should be able to find this message somewhere in the executable.

Let’s load Defender.EXE into OllyDbg and take a first look at it. The first thing you should do is look at the Executable Modules window to see which DLLs are statically linked to Defender. Figure 11.12 shows the Executable Modules window for Defender.

Figure 11.11 Defender.EXE launched with John Doe as the username and 1234567890ABCDEF as the serial number.

372 Chapter 11

Figure 11.12 Executable modules statically linked with Defender (from OllyDbg).

Figure 11.13 Imports and Exports for Defender.EXE (from OllyDbg).

Very short list indeed—only NTDLL.DLL and KERNEL32.DLL. Remember that our GUI crackme, KeygenMe-3 had a much longer list, but then again Defender is a console-mode application. Let’s proceed to the Names window to determine which APIs are called by Defender. Figure 11.13 shows the Names window for Defender.EXE.

Very strange indeed. It would seem that the only API called by

Defender.EXE is IsDebuggerPresent from KERNEL32.DLL. It doesn’t take much reasoning to figure out that this is unlikely to be true. The program must be able to somehow communicate with the operating system, beyond just calling IsDebuggerPresent. For example, how would the program print out messages to the console window without calling into the operating system? That’s just not possible. Let’s run the program through DUMPBIN and see what it has to say about Defender’s imports. Listing 11.4 shows DUMPBIN’s output when it is launched with the /IMPORTS option.

Microsoft (R) COFF/PE Dumper Version 7.10.3077

Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file defender.exe

Listing 11.4 Output from DUMPBIN when run on Defender.EXE with the /IMPORTS option.

Breaking Protections 373

File Type: EXECUTABLE IMAGE

Section contains the following imports:

KERNEL32.dll

22F IsDebuggerPresent

Summary

1000 .data

4000 .h3mf85n

1000 .h477w81

1000 .rdata

Listing 11.4 (continued)

Not much news here. DUMPBIN is also claiming the Defender.EXE is only calling IsDebuggerPresent. One slightly interesting thing however is the Summary section, where DUMPBIN lists the module’s sections. It would appear that Defender doesn’t have a .text section (which is usually where the code is placed in PE executables). Instead it has two strange sections:

.h3mf85n and .h477w81. This doesn’t mean that the program doesn’t have any code, it simply means that the code is most likely tucked in one of those oddly named sections.

At this point it would be wise to run DUMPBIN with the /HEADERS option to get a better idea of how Defender is built (see Listing 11.5).

Microsoft (R) COFF/PE Dumper Version 7.10.3077

Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file defender.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES

14C machine (x86)

Listing 11.5 Output from DUMPBIN when run on Defender.EXE with the /HEADERS option. (continued)

376 Chapter 11

Summary

1000 .data

4000 .h3mf85n

1000 .h477w81

1000 .rdata

Listing 11.5 (continued)

The /HEADERS options provides you with a lot more details on the program. For example, it is easy to see that section #1, .h3mf85n, is the code section. It is specified as Code, and the program’s entry point resides in it (the entry point is at 404232 and .h3mf85n starts at 401000 and ends at 4042FF, so the entry point is clearly inside this section). The other oddly named section, .h477w81 appears to be a small data section, probably containing some variables. It’s also worth mentioning that the subsystem flag equal 3. This identifies a Windows CUI (console user interface) program, and Windows will automatically create a console window for this program as soon as it is started.

All of those oddly named sections indicate that the program is possible packed in some way. Packers have a way of creating special sections that contain the packed code or the unpacking code. It is a good idea to run the program in PEiD to see if it is packed with a known packer. PEiD is a program that can identify popular executable signatures and show whether an executable has been packed by one of the popular executable packers or copy protection products. PEiD can be downloaded from http://peid.has.it/. Figure 11.14 shows PEiD’s output when it is fed with Defender.EXE.

Unfortunately, PEiD reports “Nothing found,” so you can safely assume that Defender is either not packed or that it is packed with an unknown packer. Let’s proceed to start disassembling the program and figuring out where that “Sorry . . . Bad key, try again.” message is coming from.

380 Chapter 11

Listing 11.6 shows Defender’s entry point function. A quick scan of the function reveals one important property—the entry point is not a common runtime library initialization routine. Even if you’ve never seen a runtime library initialization routine before, you can be pretty sure that it doesn’t end with a call to IsDebuggerPresent. While we’re on that call, look at how EAX is being XORed against itself as soon as it returns—its return value is being ignored! A quick look in http://msdn.microsoft.com shows us that IsDebugger Present should return a Boolean specifying whether a debugger is present or not. XORing EAX right after this API returns means that the call is meaningless.

Anyway, let’s go back to the top of Listing 11.6 and learn something about Defender, starting with a call to 402EA8. Let’s take a look at what it does.

The preceding routine starts out with an interesting sequence that loads a value from fs:30h. Generally in NT-based operating systems the fs register is used for accessing thread local information. For any given thread, fs:0 points to the local TEB (Thread Environment Block) data structure, which contains a plethora of thread-private information required by the system during runtime. In this case, the function is accessing offset +30. Luckily, you have detailed symbolic information in Windows from which you can obtain information on what offset +30 is in the TEB. You can do that by loading symbols for NTDLL in WinDbg and using the DT command (for more information on WinDbg and the DT command go to the Microsoft Debugging Tools Web page at www.microsoft.com/whdc/devtools/debugging/default.mspx).

The structure listing for the TEB is quite long, so I’ll just list the first part of it, up to offset +30, which is the one being accessed by the program.