Eilam E.Reversing.Secrets of reverse engineering.2005

Breaking Protections 361

Figure 11.5 Imports and exports for Key4 (from OllyDbg).

At the moment, you’re interested in the Import entry titled USER32. MessageBoxA, because that could well be the call that generates the message box from Figure 11.2. OllyDbg lets you do several things with such an import entry, but my favorite feature, especially for a small program such as a crackme, is to just have Olly show all code references to the imported function. This provides an excellent way to find the call to the failure message box, and hopefully also to the success message box. You can select the MessageBoxA entry, click the right mouse button, and select Find References to get into the References to MessageBoxA dialog box. This dialog box is shown in Figure 11.6.

Here, you have all code references in Key4.exe to the MessageBoxA API. Notice that the last entry references the API with a JMP instruction instead of a CALL instruction. This is just the import entry for the API, and essentially all the other calls also go through this one. It is not relevant in the current discussion. You end up with four other calls that use the CALL instruction. Selecting any of the entries and pressing Enter shows you a disassembly of the code that calls the API. Here, you can also see which parameters were passed into the API, so you can quickly tell if you’ve found the right spot.

Figure 11.6 References to MessageBoxA.

Breaking Protections 363

this case, you’re not interested in ever getting to the error message at Key4.00401358, so you completely eliminate the jump from the program. You do this by typing NOP into the Assemble dialog box, with the Fill with NOPs option checked. This will make sure that Olly overwrites the entire instruction with NOPs.

Having patched the program, you can run it and see what happens. It’s important to keep in mind that the patch is only applied to the debugged program and that it’s not written back into the original executable (yet). This means that the only way to try out the patched program at the moment is by running it inside the debugger. You do that by pressing F9. As usual, you get the usual KeygenMe-3 dialog box, and you can just type random values into the two text boxes and click “OK”. Success! The program now shows the success dialog box, as shown in Figure 11.8.

This concludes your first patching lesson. The fact is that simple programs that use a single if statement to control the availability of program functionality are quite common, and this technique can be applied to many of them. The only thing that can get somewhat complicated is the process of finding these if statements. KeygenMe-3 is a really tiny program. Larger programs might not use the stock MessageBox API or might have hundreds of calls to it, which can complicate things a great deal.

One point to keep in mind is that so far you’ve only patched the program inside the debugger. This means that to enjoy your crack you must run the program in OllyDbg. At this point, you must permanently patch the program’s binary executable in order for the crack to be permanent. You do this by rightclicking the code area in the CPU window and selecting Copy to Executable, and then All Modifications in the submenu. This should create a new window that contains a new executable with the patches that you’ve done. Now all you must do is right-click that window, select Save File, and give OllyDbg a name for the new patched executable. That’s it! OllyDbg is really a nice tool for simple cracking and patching tasks. One common cracking scenario where patching becomes somewhat more complicated is when the program performs checksum verification on itself in order to make sure that it hasn’t been modified. In such cases, more work is required in order to properly patch a program, but fear not: It’s always possible.

Figure 11.7 The Assemble dialog in OllyDbg.

Breaking Protections 365

challenge, where the protected program takes the volume serial number and the username and generates a challenge, which is just a long number. The user is then given that number and is supposed to call the software vendor and ask for a valid product key that will be generated based on the supplied number. In such cases, a keygen would simply convert the challenge to the product key.

As its name implies, KeygenMe-3 was meant to be keygenned, so by patching it you were essentially cheating. Let’s rectify the situation by creating a keygen for KeygenMe-3.

Ripping Key-Generation Algorithms

Ripping algorithms from copy protection products is often an easy and effective method for creating keygen programs. The idea is quite simple: Locate the function or functions within the protected program that calculate a valid serial number, and port them into your keygen. The beauty of this approach is that you just don’t need to really understand the algorithm; you simply need to locate it and find a way to call it from your own program.

The initial task you must perform is to locate the key-generation algorithm within the crackme. There are many ways to do this, but one the rarely fails is to look for the code that reads the contents of the two edit boxes into which you’re typing the username and serial number. Assuming that KeygenMe-3’s main screen is a dialog box (and this can easily be verified by looking for one of the dialog box creation APIs in the program’s initialization code), it is likely that the program would use GetDlgItemText or that it would send the edit box a WM_GETTEXT message. Working under the assumption that it’s GetDlg ItemText you’re after, you can go back to the Names window in OllyDbg and look for references to GetDlgItemTextA or GetDlgItemTextW. As expected, you will find that the program is calling GetDlgItemTextA, and in opening the Find References to Import window, you find two calls into the API (not counting the direct JMP, which is the import address table entry).

Listing 11.1 Conversion algorithm for first input field in KeygenMe-3. (continued)

366 Chapter 11

Before attempting to rip the conversion algorithm from the preceding code, let’s also take a look at the function at Key4.00401388, which is apparently a part of the algorithm.

Listing 11.2 Conversion algorithm for second input field in KeygenMe-3.

From looking at the code, it is evident that there are two code areas that appear to contain the key-generation algorithm. The first is the Key4.0040130B section in Listing 11.1, and the second is the entire function from Listing 11.2. The part from Listing 11.1 generates the value in ESI, and the function from Listing 11.2 returns a value into EAX. The two values are compared and must be equal for the program to report success (this is the comparison that we patched earlier).

Let’s start by determining the input data required by the snippet at Key4.0040130B. This code starts out with ECX containing the length of the first input string (the one from the top text box), with the address to that string (40303F), and with the unknown, hard-coded address 40351F. The first thing to notice is that the sequence doesn’t actually go over each character in the string. Instead, it takes the first four characters and treats them as a single double-word. In order to move this code into your own keygen, you have to figure out what is stored in 40351F. First of all, you can see that the address is always added to EAX before it is referenced. In the initial iteration EAX equals 1, so the actual address that is accessed is 403520. In the following iterations EAX is set to 4, so you’re now looking at 403524. From dumping 403520 in OllyDbg, you can see that this address contains the following data:

00403520 25 40 24 65 72 77 72 23 %@$erwr#

368 Chapter 11

Notice that the line that accesses this address is only using a single byte, and not whole DWORDs, so in reality the program is only accessing the first (which is 0x25) and the fourth byte (which is 0x65).

In looking at the first algorithm from Listing 11.1, it is quite obvious that this is some kind of key-generation algorithm that converts a username into a 32bit number (that ends up in ESI). What about the second algorithm from Listing 11.2? A quick observation shows that the code doesn’t have any complex processing. All it does is go over each digit in the serial number, subtract it from 0x30 (which happens to be the digit ‘0’ in ASCII), and repeatedly multiply the result by 10 until ECX gets to zero. This multiplication happens in an inner loop for each digit in the source string. The number of multiplications is determined by the digit’s position in the source string.

Stepping through this code in the debugger will show what experienced reversers can detect by just looking at this function. It converts the string that was passed in the parameter to a binary DWORD. This is equivalent to the atoi function from the C runtime library, but it appears to be a private implementation (atoi is somewhat more complicated, and while OllyDbg is capable of identifying library functions if it is given a library to work with, it didn’t seem to find anything in KeygenMe-3).

So, it seems that the first algorithm (from Listing 11.1) converts the username into a 32-bit DWORD using a special algorithm, and that the second algorithm simply converts digits from the lower text box. The lower text box should contain the number produced by the first algorithm. In light of this, it would seem that all you need to do is just rip the first algorithm into the keygen program and have it generate a serial number for us. Let’s try that out.

Listing 11.3 shows the ported routine I created for the keygen program. It is essentially a C function (compiled using the Microsoft C/C++ compiler), with an inline assembler sequence that was copied from the OllyDbg disassembler. The instructions written in lowercase were all manually added, as was the name LoopStart.

ULONG ComputeSerial(LPSTR pszString)

{

DWORD dwLen = lstrlen(pszString); _asm

{

mov ecx, [dwLen] mov edx, 0x25 mov eax, 1

LoopStart:

MOV EBX, DWORD PTR [pszString] mov ebx, dword ptr [ebx]

//MOVSX EDX, BYTE PTR DS:[EAX+40351F]

Listing 11.3 Ported conversion algorithm for first input field from KeygenMe-3.

Breaking Protections 369

SUB EBX, EDX

IMUL EBX, EDX

MOV ESI, EBX

SUB EBX, EAX

ADD EBX, 0x4353543

ADD ESI, EBX

XOR ESI, EDX

MOV EAX, 4 mov edx, 0x65 DEC ECX

JNZ LoopStart mov eax, ESI

}

}

Listing 11.3 (continued)

I inserted this function into a tiny console mode application I created that takes the username as an input and shows ComputeSerial’s return value in decimal. All it does is call ComputeSerial and display its return value in decimal. Here’s the entry point for my keygen program.

int _tmain(int argc, _TCHAR* argv[])

{

printf (“Welcome to the KeygenMe-3 keygen!\n”); printf (“User name is: %s\n”, argv[1]);

printf (“Serial number is: %u\n”, ComputeSerial(argv[1])); return 0;

}

It would appear that typing any name into the top text box (this should be the same name passed to ComputeSerial) and then typing ComputeSerial’s return value into the second text box in KeygenMe-3 should satisfy the program. Let’s try that out. You can pass “John Doe” as a parameter for our keygen, and record the generated serial number. Figure 11.9 shows the output screen from our keygen.

Figure 11.9 The KeygenMe-3 KeyGen in action.