2.4. Examples of Executable Files Correction

2.4. Examples of Executable Files Correction

The examples provided here are not too difficult. They are given for the following purposes:

• To demonstrate the possibilities of the previously described tools

• To demonstrate some standard techniques for investigation and correction of executable code

• To stop tempting you with promises and jump into code disassembling

All techniques of correcting executable code are provided here for educational purposes only.

2.4.1. Example 1: Eliminating an Annoying Message

Recently I purchased a CD containing an encyclopedia in the field of history. After installing it on my computer and making sure that everything worked, I forgot about this program. A week later, I discovered that when this program was started for execution, an annoying message box appeared on the screen (Fig. 2.19).

Figure 2.19: The annoying error message that appeared when the encyclopedia was started

If the Yes button is clicked, the program would continue to operate normally. After several minutes of consideration, I decided that this happened because a couple of days ago I moved all swap files to the same partition. Because I didn't intend to recover the initial state and the program continued to operate normally, I decided to correct its executable code to remove the annoying message.

Thus, I proceeded as follows. To all appearances, this message is displayed in a standard MessageBox window. First, the presence of an icon on the left indicates such a window (in this case, it is an exclamation mark). Second, such windows usually contain two buttons — Yes and No. How do you reach this call?

Searching with OllyDbg

There are several ways of accessing the MessageBox window using the debugger. The easiest way of doing this is to set a breakpoint to the imported MessageBox name (see Section 2.3.2), and then start the program (<Ctrl>+<F8>) and wait for the interrupt. However, this time the situation is much simpler. The message appears at the initial stages of the program start-up, and this location can be easily detected by step-by-step program execution (press <F8>).

Fig. 2.20 shows the debugger window displaying the required program fragment. Note that slightly above the MessageBox function there is the GlobalMemoryStatus API call. Obviously, the execution of this function results in the error message. In this case, you do not even need to investigate how this function operates. The important issue is that the call to this function is directly followed by the code lines provided in Listing 2.5.

Figure 2.20: The OllyDbg window displaying the fragment of the call to MessageBox

Listing 2.5: Code lines directly preceding the call displaying the warning message

 00494039       813D 287A4900        CMP DWORD PTR DS:[497A28], 989680 00494043       7D 1F                JGE SHORT RHistory.00494064 

It is easy to replace the JGE SHORT 00494064 command with the JMP SHORT 00494064 command. Thus, you'll bypass the call to the MessageBox window. In this chapter I have described hiew.exe, an excellent program that can be used for correcting executable modules. However, it is also possible to correct executable modules using OllyDbg. It is a wonderful feeling to know that any task can have several solutions and that you can use any of them. I hope that you experience this feeling many times!

Searching with W32Dasm

Now, try to locate the required fragment using W32Dasm. It is possible to use the list of imported functions and, having found MessageBox by double-clicking the line of code containing this function name, to find all locations where this function is called. It is also possible to use the debugger built into W32Dasm. This method will be illustrated here.

Use the Debug | Load Process menu commands. The window will appear where it is necessary to specify the program loading parameters. Click the Load button. The debugger window will appear (Fig. 2.21). Click the AutoStep Over button and wait for the required message to appear. When the message appears, click the Terminate button. You'll find yourself in the required location of the program (disassembled code). The further steps are exactly as described earlier — start hiew.exe and introduce the required corrections.

Figure 2.21: The W32Dasm window

Searching with IDA Pro

The procedure of searching for the required program fragment in IDA Pro also is traditional. First, it is necessary to find the MessageBox name in the list of functions. Then double-click the name to go to the code fragment shown in Fig. 2.22. This is a "stub" called from the other locations within the program. Pay special attention to the ellipsis. If you right-click it and select the Jump to cross reference item in the context menu, the window will open, which would display all program addresses, from which the MessageBox function is called. Now you won't have any difficulties checking all of these function calls and finding the required location within the program.

Figure 2.22: Fragment of the disassembled program code produced by IDA Pro

Note 

When correcting the executable code (usually, this is done to remove the protection), conditional jump commands are often encountered. Because such commands are often preceded by comparison commands (CMP), there is a common opinion that to crack a program the cracker needs to know only one Assembly command. This is not quite true. In difficult situations, the code investigator must literally "grind" the Assembly code.

2.4.2. Example 2: Removing Limitations on Program Use

The task of removing limitations of trial versions is not too difficult. At the same time, it is one of the most common. This problem can be solved using W32Dasm. For code correction, the hiew.exe program is traditionally used.

The program considered in this section, Allscreen, is a shareware program allowing you to produce snapshots of individual windows or fragments of the screen. I downloaded its shareware release quite a long time ago. This program is written in Delphi. However, as will be shown in this section, it is possible to solve the problem without even knowing, in which programming language it was written. Nevertheless, it should be pointed out that the DeDe disassembler (see Section 2.1.1), which I praised earlier, failed to determine the program structure. This is probably because an old version of compiler was used for program translation.

Thus, when you start the allscreen.exe program, the dialog shown in Fig. 2.23 appears on the screen. When you carefully study cracking and related issues, you'll discover that usually the cracker must look for the program fragment corresponding to some visual effect, such as opening or closing a window or text output.

Figure 2.23: The window that appears at start-up of the Allscreen program

When the user clicks the Accept button, there is a delay of about 6 seconds (Fig. 2.24), after which the program operates normally.

Figure 2.24: The delay window displayed by the Allscreen program

After 15 runs, the program displays the window shown in Fig 2.25, and terminates.

Figure 2.25: The message informing the user about expiration of the trial period

To remove the protection, the cracker must solve the following two problems:

• Eliminate the annoying delay

• Ensure that the program continues to operate correctly after the trial period expires

The Delay Procedure

The window shown in Fig. 2.25 is a blunder of the program's authors. The window, along with its contents, can be hidden within the resources. However, when a new record appears in that window, it is nothing but the program code. Thus, start W32Dasm and load the allscreen.exe program there. Open the string data reference (SDR) window, find the Shareware Delay string there, and double-click it. You'll find yourself in the required program location. This program fragment is shown in Listing 2.6.

Listing 2.6: Fragment of the Allscreen code required for removing the delay procedure

 * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:004420BC(C) | :00442123 33D2              xor edx, edx :00442125 8B83B0010000      mov eax, dword ptr [ebx + 000001B0] :0044212B E8541DFDFF        call 00413E84 :00442130 33D2              xor edx, edx :00442132 8B83B4010000      mov eax, dword ptr [ebx + 000001B4] :00442138 E8471DFDFF        call 00413E84 :0044213D 33D2              xor edx, edx :0044213F 8B83B8010000      mov eax, dword ptr [ebx + 000001B8] :00442145 E83A1DFDFF        call 00413E84 :0044214A BA50000000        mov edx, 00000050 :0044214F 8B83BC010000      mov eax, dword ptr [ebx + 000001BC] :00442155 E8D618FDFF        call 00413A30 * Possible StringData Ref from Code Obj ->"Shareware Delay"                             | :0044215A BAA8214400        mov edx, 004421A8 :0044215F 8B83BC010000      mov eax, dword ptr [ebx + 000001BC] :00442165 E8EE1DFDFF        call 00413F58 :0044216A 33D2              xor edx, edx :0044216C 8B83C0010000      mov eax, dword ptr [ebx + 000001C0] :00442172 E80D1DFDFF        call 00413E84 :00442177 33D2              xor edx, edx :00442179 8B83C4010000      mov eax, dword ptr [ebx + 000001C4] :0044217F E8001DFDFF        call 00413E84 :00442184 33D2              xor edx, edx :00442186 8B83C8010000      mov eax, dword ptr [ebx + 000001C8] :0044218C E8F31CFDFF        call 00413E84 :00442191 8B83CC010000      mov eax, dword ptr [ebx + 000001CC] :00442197 E8E8D4FFFF        call 0043F684 :0044219C 5B                pop ebx :0044219D C3                ret 

I have provided a larger code fragment in Listing 2.6, having included several preceding lines of code. In essence, this listing shows the entire delay procedure. There is no practical sense in trying to understand the meaning of each individual CALL command, although it can be easily discovered (by conducting a small experiment) that, for example, CALL 00413E84 removes a string from the screen.

To eliminate the delay, it is enough to "exclude" this fragment from the program. The easiest way of achieving this is to insert POP EBX/RET commands into the start of this code fragment (the 00442123 address) using some hex editor (hiew.exe, for example). After starting the corrected program for execution, the delay is eliminated (see for yourself).

Removing the Limitation on the Number of Program Runs

Now consider the second problem — removing the limitation on program runs. After you carefully consider the window (see Fig. 2.25), it will be clear that this window is formed by the program. This means that you can try to find the text displayed on the screen within the program. As in the previous case, the string can be found in the SDR window. Double-click this line of code to find yourself in the required program location (Listing 2.7).

Listing 2.7: Fragment of Allscreen responsible for limiting the number of runs

 :00443326 8BC0               mov eax, eax :00443328 53                 push ebx :00443329 8BD8               mov ebx, eax :0044332B 803DEC56440001     cmp byte ptr [004456EC], 01 :00443332 7546               jne 0044337A :00443334 A124564400         mov eax, dword ptr [00445624] :00443339 E84E2CFEFF         call 00425F8C :0044333E A1D8564400         mov eax, dword ptr [004456D8] :00443343 E87816FEFF         call 004249C0 :00443348 FF05F0564400       inc dword ptr [004456F0] :0044334E C605EC56440000     mov byte ptr [004456EC], 00 :00443355 833DF05644000F     cmp dword ptr [004456F0], 0000000F :0044335C 7E1C               jle 0044337A :0044335E 6A00               push 00000000 :00443360 668B0DB0334400     mov cx, word ptr [004433B0] :00443367 B202               mov dl, 02 * Possible StringData Ref from Code Obj ->"This Software Has Been Used Over"                              | :00443369 B8BC334400         mov eax, 004433BC :0044336E E8BDAEFEFF         call 0042E230 :00443373 8BC3               mov eax, ebx :00443375 E84214FEFF         call 004247BC * Referenced by a (U)nconditional or (C)onditional Jump at Addresses: :00443332(C), :0044335C(C)                             | :0044337A 33D2              xor edx, edx :0044337C 8B83F4010000      mov eax, dword ptr [ebx + 000001F4] :00443382 E8A52DFFFF        call 0043612C :00443387 33D2              xor edx, edx :00443389 8B83F8010000      mov eax, dword ptr [ebx + 000001F8] :0044338F E8982DFFFF        call 0043612C :00443394 33D2              xor edx, edx :00443396 8B83FC010000      mov eax, dword ptr [ebx + 000001FC] :0044339C E88B2DFFFF        call 0043612C :004433A1 33D2              xor edx, edx :004433A3 8B8314020000      mov eax, dword ptr [ebx + 00000214] :004433A9 E87E2DFFFF        call 0043612C :004433AE 5B                pop ebx :004433AF C3                ret 

As in the previous case, Listing 2.7 presents the entire code fragment required to achieve the cracking goal. View several preceding lines of code, and you'll easily discover "suspicious" commands (Listing 2.8).

Listing 2.8: Commands you must correct to remove the limitation on program runs

 cmp dword ptr [004456F0], 0000000F jle 0044337A 

Recall that the program ceases to operate after 15 runs (0FH in hex representation). The easiest way of removing the limitation is to overwrite the code fragment spanning the addresses from 0044335EH to 00443375H with NOP (90H) commands. Use hiew.exe for this purpose. As a result, the program would operate without any limitations on the number of runs.

2.4.3. Example 3: Cracking an Evaluation Copy

General Considerations

The next example considers how to make a fully featured program out of the 30-day evaluation copy of the Intel C++ 4.5 compiler. I'm not going to add functional capabilities missing from the evaluation version of the compiler. This example only demonstrates the principal possibility of removing the time limitation for the use of the evaluation copy.

After you install the compiler on your computer, it will be located in the ...\compiler45\bin directory. The program name is icl.exe. Start this program, and it will output the following strings to the console:

    Intel(R) C/C++ Compiler Version 4.5 00015    Copyright (C) 1985-2000 Intel Corporation. All rights reserved.    Evaluation copy.    Icl: NOTE: This is day 1 of 30 day evaluation period.    Icl: Command line error: no files specified. 

The last output line is clear because the C program name wasn't specified in the command line. If you specify the name of some C program, the compiler would be functional. However, after a month it would cease to operate and, instead of compiling your programs, would display the following string: The evaluation period has expired.

Now, start IDA Pro and try to find the strings that appear in the compiler's console output. Listing 2.9 shows what I located as a result of searching the program code.

Listing 2.9: Strings in the Intel C compiler console output, which were found in IDA Pro

 data:00419C20 aCopyrightC1985 db 'Copyright (C) 1985-2000 Intel Corporation.  All rights reser' .data:00419C20                 ; DATA XREF: sub_404574 + 31↑o .data:00419C20                 ; sub_40C974 + 21 ↑o .data:00419C20                 db 'ved.', 0Ah .data:00419C20                 db 'Evaluation copy', 0 

Note that the entire listing represents a single string. This is an important issue, especially if you assume that the Evaluation copy message isn't related to any check for the program's operability. Any attempt at locating a string like This is day, however, didn't succeed. Even if I could locate such a string, I'd most likely discover a call to some library function, such as puts or printf. Then I'd have to go one level higher to discover the strings where the limitations for the program use are checked. So, I decided to use the debugger for further analysis of the program.

Searching in the Debugger

Before starting the debugger, I found the address of the main function using IDA Pro. This address turned out to be 00402000H, so, after starting OllyDbg, I immediately set the breakpoint to that address and started program analysis from that point.

To try this, locate the main function and start step-by-step program execution (<F8>), checking the contents of the console window after each procedure call. You'll soon locate the fragment in Listing 2.10.

Listing 2.10: Tracing the console output of the evaluation copy of the Intel C compiler

 0040204A        E8 71040000         CALL  icl.004024C0 0040204F        0FB6C0              MOVZX EAX, AL 00402052        85C0                TEST  EAX, EAX 00402054        0F84 E5000000       JE    icl.0040213F 0040205A        E8 D1780000         CALL  icl.00409930 0040205F        0FB6C0              MOVZX EAX, AL 00402062        85CO                TEST  EAX, EAX 00402064        OF84 C4000000       JE    icl.0040212E 

As it turns out, the procedure with the 0040204AH address outputs the Evaluation copy string, and the procedure located at the 0040205AH address outputs the string informing the user about the 30-day evaluation period. Based on the assumption made at the end of the previous section, consider the second procedure (0040205AH), skipping the first one. An attempt at replacing the JE command with JNE doesn't produce the desired result. When running the program in step over mode, you'll find that this procedure returns one. Thus, I've made a simple assumption, namely, that only the contents of the EAX register are of any interest in this procedure. Thus, replace CALL icl.00409930 with MOV EAX, 1 (the number of bytes in both commands is equal) and save the executable module. Test it for usability. It works, and it continues to work after the 30-day trial period expires.

2.4.4. Example 4: Removing Protection

In this example, I demonstrate how crackers often achieve their goals by taking a lengthy and tedious route instead of using the easy and fast approach. This time, consider the GetPixel program intended for taking color pixels from the screen. I obtained this module with the crack (crack.exe). Because I required a demonstration example, I decided to remove the protection without any help (after all, this is an interesting and instructive occupation). Note that although this program was written in Visual Basic I didn't use this knowledge for code investigation. For all I know, Visual Basic decompilers never produce useful results.

Step 1: Attempt To Register the Program

Fig. 2.26 shows the registration window of the GetPixel program. According to the intention of the program's author, this window must be used for user registration. The Name and Registration Code fields are intended for supplying the user name and registration code. When the user clicks the OK button, the program checks the supplied name and password. When I supplied an arbitrary name and an arbitrary password, the program displayed an error message. Well, I didn't expect it to behave differently.

Figure 2.26: The GetPixel registration window

After this first failed attempt, I tried to make the program register my name and the password. Using logic, I started this small investigation by searching for strings containing Registration.

Open the famous IDA Pro disassembler and load the program there. In the strings window, I located three strings containing this word: Register Successfully!, Registration, and Register Fail!. It seems that I chose a correct approach. Start with the first phrase. Double-click this string, and you'll find yourself in the required location of the disassembler window (Listing 2.11).

Listing 2.11: The fragment of disassembled code containing the Register Successfully! string

 .text:00409720          aRegisterSucces:  ; DATA XREF: .text:00417ECE↓o .text:00409720          unicode 0, <Register Successfully!>, 0 

Follow the cross-reference, and you'll find the fragment in Listing 2.12.

Listing 2.12: The code fragment, to which the cross-reference (Listing 2.11) points

 .text:00417EC5     lea      edx, [ebp - 134h] .text:00417ECB     lea      ecx, [ebp - 34h] .text:00417ECE     mov      dword ptr [ebp - 12Ch], offset aRegisterSucces ; "Register Successfully!" .text:00417ED8     mov      dword ptr [ebp - 134h], 8 .text:00417EE2     call     ds:__vbaVarDup 

It is difficult to determine what the __vbaVarDup function represents; however, it appears much like a message about successful registration. Now, study the program code located near these strings in more detail. Slightly above the code provided in Listing 2.12, I discovered the fragment shown in Listing 2.13.

Listing 2.13: The "suspicious" code located slightly above the fragment shown in Listing 2.12

 .text:00417E76     push     ecx .text:00417E77     push     edx .text:00417E78     push     4 .text:00417E7A     call     edi ; __vbaFreeVarList .text:00417E7C     add      esp, 20h .text:00417E7F     cmp      [ebp - 1A8h], bx .text:00417E86     jz       loc_4181A4 

This looks suspicious. Find out what is located at the loc_4181A4 address. Jump to that address, and you'll discover the fragment in Listing 2.14.

Listing 2.14: Code fragment located at the loc_4181A4 address of the GetPixel program

 .text:00418268     mov     dword ptr [ebp - 12Ch], offset aRegisterFailed ; "Register Failed!" .text:00418272     mov     dword ptr [ebp - 13Ch], offset aPleaseVisit ; "Please visit" .text:0041827C     mov     dword ptr [ebp - 14Ch], offset aHttpWww_aimoo_ ; "http://www.aimoo.com/getpixel" .text:00418286     mov     dword ptr [ebp - 15Ch], offset aToGetYourRegis ; "to get your register code" .text:00418290     call    ebx ; __vbaVarCat 

This is a message about failed registration that invites the user to visit the developer's site. Thus, this indicates that the chosen way is the correct one. Start hiew32.exe and find the .text:00417E86 address there. Overwrite 6 bytes with NOP instructions. Then exit and start the program. When the program starts, repeat the registration attempt by supplying any arbitrarily chosen name and password. You'll receive the message that you are now a registered user. Does this mean that the problem has been solved and you can rejoice? No!

Step 2: Remove the Nag Screen

Soon you'll discover that the problem is far from solved. If you didn't quit the program after "successful" registration, the registration window would display that the registration was carried out successfully. However, after restarting the program, the registration window would again state that this copy wasn't a registered one. Furthermore, after restart, the window shown in Fig. 2.27 would start to appear with a certain level of probability. If this window appears and the user clicks the Yes button, the program tries to connect to the developer's site; otherwise, it continues normal operation.

Figure 2.27: The nag screen

After carefully looking at the contents of the directory, where the program was installed, I discovered the clickme.reg file containing the script for writing a correct user name and password into the registry (provided that the user knows the correct user name and password). Open the registry, and you'll discover that the user name and the password you specified when attempting to register the program were written into the location specified by the clickme.reg script. Apparently, the program compares this user name and password to some reference value at start-up. You do not know these values (and, rushing somewhat ahead, you'll never know them). After that, the program specifies that this is an unregistered copy (see Fig. 2.26). In addition, it occasionally displays the nag screen (see Fig. 2.27).

It is necessary to remove the nag screen. Open the strings window in IDA and search for the How do you feel me? string. Having located it, consider the code section that contains a reference to this string. This code fragment is provided in Listing 2.15.

Listing 2.15: The GetPixel code fragment that contains a reference to "How do you feel me?"

 .text:0040B217   push    eax .text:0040B218   mov     dword ptr [ebp - 0D0h], offset aHowDoYouFeelMe                                           ; "How do you feel me?" .text:0040B222   mov     dword ptr [ebp - 0E0h], offset aIWantToBeConfi                                           ; "I want to be confirmed :-)" .text:0040B22C   call    esi              ; __vbaVarCat .text:0040B22E   lea     ecx, [ebp - 0E8h] .text:0040B234   push    eax .text:0040B235   lea     edx, [ebp - 98h] .text:0040B23B   push    ecx .text:0040B23C   push    edx .text:0040B23D   call    esi ; __vbaVarCat .text:0040B23F   push    eax .text:0040B240   call    ds:rtcMsgBox 

It is obvious that the call rtcMsgBox command is the call to the MessageBox function. This function is unneeded, so you can overwrite it with NOP instructions. However, don't rush forward without taking all required actions. The MessageBox function must provide the user with a choice, and it is assumed that the user chooses No. Scroll the listing down and locate the required code fragment (Listing 2.16).

Listing 2.16: The GetPixel fragment for the Yes/No choice when the nag screen is displayed

 .text:0040B2B6   call    ds:__vbaVarTstEq .text:0040B2BC   test    ax, ax .text:0040B2BF   jz      short loc_40B305 .text:0040B2C1   mov     esi, ds:__vbaStrToAnsi .text:0040B2C7   push    1 .text:0040B2C9   lea     edx, [ebp - 60h] .text:0040B2CC   push    offset aC     ; "C:\\" .text:0040B2D1   push    edx .text:0040B2D2   call    esi           ; __vbaStrToAnsi .text:0040B2D4   push    eax .text:0040B2D5   push    0 .text:0040B2D7   lea     eax, [ebp - 5Ch] .text:0040B2DA   push    offset aHttpWww_aimoo_                                        ; "http://www...aimoo.com/getpixel" .text:0040B2DF   push    eax .text:0040B2E0   call    esi           ; __vbaStrToAnsi .text:0040B2E2   ush     eax .text:0040B2E3   push    0 .text:0040B2E5   push    0 .text:0040B2E7   call    sub_407CB0 .text:0040B2EC   call    ds:__vbaSetSystemError 

If the condition requiring the contents of the EAX register to be zero has not been observed, the program attempts to connect to the author's site. To avoid this action, it is necessary to replace JZ with JMP SHORT. That's all!

Start hiew32.exe and modify the two previously-mentioned fragments (see Listing 2.15, overwrite the MessageBox function with NOP instructions, and replace JZ with JMP SHORT in Listing 2.16). Do not forget that it is necessary to overwrite both the function call and the PUSH instruction preceding it. As a result, the nag screen won't appear.

Step 3: Complete the Registration

Now it remains to complete the final step, which consists of making the program to believe that the registry contains the correct registration data. Apparently, it would be logical to assume that there must be some procedure that checks the password for correctness.

I should admit that at this stage it took me about an hour to locate this procedure. I used both a disassembler and a debugger (OllyDbg). I had to guess how to access that procedure. Now I'm going to explain you how I did this.

First, it is necessary to note the names of the registry entries that have to be filled in the course of registration. These are the License and RegUser fields. The License field must contain the password. Now search for this string.

The string can be easily found. It occurs in two locations. This is an encouraging indication, because there are two calls to the password: at program start-up and from the registration window. Look at the disassembled program code, and you'll discover that in the first case the rtcGetSetting function is used and in the second case the rtcSaveSetting function is used. Everything is clear now. The first function reads the password, and the second function writes it. Information about both functions can be found in the Microsoft Developer Network (MSDN). The first function deserves the most attention.

Go to the required program fragment, scroll the listing down, and try to understand the program logic. When scrolling down, trace only those procedures that are not supplied as part of some library. One such procedure, most likely, will be the one that checks the password and user name for correctness.

First, the code fragment in Listing 2.17 attracted my attention.

Listing 2.17: A candidate for the role of the password-checking procedure

 .text:0040AE00       lea    edx, [ebp - 78h] .text:0040AE03       push   edx .text:0040AE04       call   sub_415160 

What value is placed into the EDX register? Start the debugger and set a breakpoint to the 40AE03 address. Then look, at which location in the stack the EDX register points. It turns out to be the name read from the system registry. There is no password here. Consequently, this procedure is not the one you are looking for. It is necessary to continue the search. In the course of this search, another procedure should attract your attention (Listing 2.18).

Listing 2.18: Another candidate for the role of the password-checking procedure

 .text:0040AE5C     lea    edx, [ebp - 88h] .text:0040AE62     lea    eax, [ebp - 78h] .text:0040AE65     push   edx .text:0040AE66     push   eax .text:0040AE67     call   sub_416070 

Use the debugger to find out that EDX points to the string made up of the user name and the password (as it turns out, they were combined somewhere). Execute this procedure under the debugger, and it will return the value of zero in the EAX register. Note that 0 in most programming languages corresponds to FALSE. Well, it seems that the time has come for a small experiment.

Start hiew32.exe, and replace the fragment shown in Listing 2.19 with the MOV EAX, 1 command, overwriting all other bytes of the procedure (Listing 2.18) with 90H values.

Listing 2.19: The code fragment that must be replaced with the MOV EAX, 1 command

 .text:0040AE65     push   edx .text:0040AE66     push   eax .text:0040AE67     call   sub_416070 

Start the program, open the registration window, and try to register again. This time you'll succeed.

Step 4: Use an Unexpected Solution

Now it is time to point out that there is much easier way of achieving the correct result. Probably, you have already guessed what I mean. It is necessary to access the 00416070H address, which is the address where the password-checking procedure starts, and insert two commands at its beginning: MOV EAX, 1/RETN 8. Nothing else will be needed. All three steps described earlier will become unnecessary. It was tempting to demonstrate for you an easy and ready-to-use solution. However, several considerations prevented me from doing this:

• In practice, most problems are not solved in the easiest way. An easy and elegant solution is usually found later, when the desired result has already been achieved. Thus, learning on the basis of elegant solution is not the correct approach.

• The approach to solving the problem chosen by the investigator doesn't matter. What matters is that the task has finally been solved.

A question may come to your mind. In the solution that I demonstrated here, I acted on the basis of information obtained from the script found in the working directory of the program. On the basis of this script, I discovered where the user name and password are written in the course of program registration. What would I do if there were no script? There is no problem here. If this were the case, it would be possible to use some registry monitor tracing all attempts at accessing the registry. If you have no registry monitors at your disposal, it is possible to resort to direct analysis of the disassembled code. For example, functions such as rtcSaveSetting and rtcGetSetting are the first candidates for such an analysis.