Body:

Before we unpack the file we will examine its protection scheme. Open LanHelper.exe. After it is loaded we are presented with a box telling us that we "are on day 1 of our 30 day trial". We then have an option to enter a registration code. Let's try it out. A box comes up asking for our name and registration code. Enter anything and press OK. A box pops up telling us that "The registration code you have entered is not correct". Notice that the box that the box that pops up looks very much like a messagebox that we covered in the previous tutorial. That is something to keep in mind when we are trying to crack the program.

Unpacking:
Unpacking is becoming a bigger part of reverse engineering. Many companies are choosing to pack or protect their programs to discourage people from reversing them. Because the packer used for this program is so popular, the method we are going to use to unpack it is not exclusive to this tutorial. In fact look for a tutorial by Ferrari on System Mechanic for more information on this method.

As a precursor to unpacking any program I usually use the hidedebugger plugin. Many packers and protectors are detecting whether or not you are debugging their program, and will quit if it detects that you are. Download the HideDebugger DLL using the selected link and place it in the same folder as Olly. Do the same for the Ollydump plugin as we will use it later.

We are going to begin by opening up LanHelper.exe in Ollydbg. You will be presented with a box about the program having an entry point outside of code. Click Okay. Another box will pop up asking if you want to analyze the code. Click Yes. You should find yourself here:

Press the Step Into button once . Now look at your registers. Understanding the registers is an integral part to learning how to reverse programs. Think of registers as 32 bit memory reserves. Information can be stored, modified, and accessed in registers. The registers are part of the processor so you can perform calculations without having to use extra memory. This is why 64 bit processors are becoming more popular. They use 64 bit registers allocatting more memory at the processor level.

With 32 bit registers you have General Registers: EAX EBX ECX EDX. These are the most used by program calculations. You also have Index and Pointer Registers: ESI EDI EBP EIP ESP. These have a variety of functions most involve pointing to addresses that the program will use. The register we will use to unpack this program is ESP. ESP contains the top address of the stack (You will remember we covered the stack in tutorial #2). For more information on registers and their uses:

http://www.mujweb.cz/www/komsbomb/article/x86reg.htm - basic information on registers
http://www.swansontec.com/sregisters.html - Information on how registers are used and what for.

Now take a look at the registers and then take a look at the stack window.
You'll notice that the values of the registers have been pushed onto the Stack. This is the result of the PUSHAD function at the beginning of the program. PUSHAD pushes the values of the registers onto the stack in their respective order. You'll notice EAX went on first, then ECX, etc... This unique function is used when the program wants to modify these registers but leave no trace of their modification behind. Their initial values are saved and then restored later. This is a perfect function for a packer. It can run the STUB, unpack the program and then restore the registers as if the STUB never existed. What we want to do is find out where the registers are restored because then we will know where the OEP of our program is.

The function that POP's the register values from the stack is appropriately called POPAD. This will pop the values off of the stack and back into the registers. We know the order that the registers were PUSHed, which means we know what order they will be POPed. EDI was last and will be the first register removed from the stack.We also know EDI's location on the stack because our register ESP points to the top of the stack. (Your register values may be different than mine but the information still applies).

Right click on the ESP register and choose Follow In Dump. You will see in the dump window, at the bottom of Olly, that you are at location 0012FFA4 (AKA the top of the stack). Highlight the first four Bytes and Right-Click. Select Breakpoint, then "Hardware, On Access", and Dword. What we are doing is setting a breakpoint so that Olly will stop when the first four bytes (EDI) are accessed. The reason we choose Dword is becausewe highlighted 4 bytes: 2 Bytes are a Word and 2 Words are a Dword (DoubleWord)
Okay we are all set to stop when EDI is POPed. Press the RUN button. Assuming you did everything correctly you should stop on the instruction JNZ SHORT LanHelpe.005533BA. Scroll up a bit and you will see directly above the JNZ is our POPAD function.

Now we are not at the OEP just yet. Our packer just needs to leave the decryption routine. Press the Step Into button 2 times and we will see how ASPack jumps to the OEP without actually jumping. You will see that the program PUSHed a location onto the stack and then immediately follows it up with a RETN. The location pushed is our OEP and the program then executes the RETN thinking that the location on the stack is the location of the function that originally called it.

Press Step Into one more time to execute the RETN and we are at the OEP. It looks wierd because the analysis of the program was done before the file was unpacked. Right click in the code window and select Analysis and then Analyse Code (or just press CTRL+A).

Our program is now unpacked into memory and we are sitting at the entry point. We are now able to dump the unpacked file from memory. Select the Plugins drop down list at the top of the Ollydbg window. Choose Ollydump and then Dump Debugged Process. You will be presented with the following box:

Look at the button "Get EIP as OEP" We do not need to press this in this tutorial. However for future reference; The EIP register (or instruction pointer) can also be called "program counter." It contains the offset of the next instruction to be executed. Pressing this button sets the OEP of the dump equal to the address stored in EIP. In this case they are both the same. We need to remember to write our OEP down. We will use the OEP address to rebuild our imports.

Now before continuing make sure that Rebuild Imports is UNchecked. Press Dump and then choose a name for your dumped executable. I chose LanDump.exe. Press the Save button and you can close Ollydbg. We now have a unpacked version of our executable. The only problem is: It won't run.

In the Introduction I gave you a brief overview of the Import Address Table (IAT). When a program is dumped from memory the IAT is not dumped along with it. We have to rebuild it ourselves and then attach it to our already dumped file. Sometimes this can be a very time consuming process because some protectors like to mess up the IAT in efforts to stop unpacking. However, this time we will find our IAT intact.

Rebuilding the IAT:
What we are going to do is use ImportReconstructor (ImpREC) and take the IAT from the original exe and attach it to our dumped file. Begin by running the original LanHelper.exe. Once LanHelper has started, open up ImportREC.exe and from the drop down menu choose the LanHelper process.

ImportREC needs to know where to look for the IAT. Without knowing where the OEP is, ImpREC looks at the entry point of the STUB and cannot find an IAT. Remember writing down the OEP when you dumped the program? This is where we will use it.

Enter the OEP in the bottom box labeled OEP. Then press "IAT AutoSearch". ImpREC will pop up saying it found what it thinks to be an IAT. Press Okay. Now Press the "Get Imports" button and wait for the Imported functions list to populate.

If the packer had messed up some of our functions, at the end of the lines you would see valid:NO. Press "Show Invalid" just to be safe. Okay nothing happened. We know that all our functions are valid. (I will cover fixing invalid functions at another time. If you are interested: Look for tutorials on AsProtect and/or rebuilding IAT's)

Press the "Fix Dump" Button and choose our LanDump.exe file. (ImpREC will save the newly modified file as FileName_.exe) Press Open and wait until the Log window of ImpREC says that LanDump_.exe was saved successfully. You can now close ImpREC and LanHelper. Okay let's open up LanDump_.exe and test it out. It Runs! You have successfully fixed the IAT and now have a working unpacked version! The only problem is: It's still not registered.

Patching the Registration Function:
Now that we have an unpacked executable we can figure out how to register it. To do this we are going to use the Attach feature of Olly. The reason we are going to attach to the process is One: because you will learn how to debug processes that are already running and Two: The dumped exe throws an exception in Olly and the program enters an endless loop that cannot be terminated outside of restarting the computer. (If anyone has more knowledge as to why this happens please email me *address at bottom*) So begin by running LanDump_.exe. Then run Ollydbg and open the File Menu, choose Attach. Find the LanDump_.exe process in the list of processes running and press Attach.

Once you attach you will find yourself in module ntdll. You know this because the titlebar of Ollydbg displays what module you are currently in. We need to get ourselves back in the main process and then continure running the program. Select the View drop down list. And then select Executable Modules. A list of all the executable modules for this program is displayed. At the top you will see LanDump_. Select that line and then Right-Click. From the menu choose Follow Entry. This will put you back into the main thread.

Press RUN to continue running the program. (If you get an error about suspended threads: Close Ollydbg. Then restart LanDump_.exe and Ollydbg. You only get one chance to attach with Ollydbg before having to close it and open it back up)

Now we are attached to the process and can go about reversing it's protection scheme. Remember the error message that came up when we entered an incorrect serial? It looked very much like a messagebox. So we are going to start by setting a breakpoint on every call to a message box.

Right-Click and choose Search For, and then choose All Intermodular Calls.You now have a list of all the calls made by the program to other modules. Press the Destination bar at the top to sort alphabetically by destination. Scroll down until you find a bunch of calls to User32.MessageBoxA. Select one of the calls and Right-Click. Choose Set Breakpoint on Every Call to MessageBoxA.

Now go to LanDump_.exe and enter your name with any serial and press Okay. Olly will pop up and you should have broken on CALL <JMP.&user32.MessageBoxA>. Scroll the code window up a little bit and then press CTRL+A. This will analyze the code again giving us more information of what the program is doing.
In the image you can see I circled an >. The > represents an entry point for this function. If we locate the code that jumped to this entry point we may find where the program compares our serial. Olly makes finding the jump to this function very easy. Highlight the LEA ECX,DWORD PTR SS:[EBP-10] line that has the > in front of it and then Right-Click. From the menu select Go-To and at the bottom of the menu select go to JE from 004DB6CE. This is the location of the JE that took us to this messagebox code.

By selecting Go-To JE from 004DB6CE we find ourselves directly below a TEST AL,AL. This checks to see if AL = 1. If AL does not equal 1 then it will jump to the messagebox telling us we entered an incorrect registration code. We could patch the jump but that will not help us if the registration is checked on startup. (Which in this case it is. You can try patching it and then restarting the program to verify for yourself.) What we want to do is patch the routine that checks the serial. What happens is our name and serial are passed to a function. I will call it CheckSerial(). The function checks our serial code and then sets AL equal to 1 or 0 depending on whether the serial is correct or not. Many times a developer will use the same function in different areas of the program. He call the CheckSerial() function on startup, and to verify the registration code when it is entered, even see if you are trying to access a disabled feature. If we patch the function to always set AL=1 then we do not have to search through the program trying to change every JE to JNE.

Looking directly above the TEST AL, AL we can see the CheckSerial() function. Highlight the line and set a breakpoint on it by pressing F2. We are going to break on this function and then trace into it to find out where the value for AL is set. Press RUN and go back to LanDump_.exe.

Go ahead and try entering your name and any serial in LanDump_.exe again. Press Okay and we will find ourselves at our breakpoint in Olly at CALL LanDump.004C4BFC. Press the Step Into button and we will be inside the registration scheme of LanHelper. Rather then step through all this code looking for where the value for AL is determined. We are going to jump right to the end because we know that setting AL equal to 1 or 0 is one of the last things the function will do before returning. Press the Execute Till Return button . This will run the code until it reaches a RETN. You should end up at the following place in code.
But looking at the stack we see that the RETN we are on will only move us down to 004C511A. That happens to be exactly where we want to go. At that location we can see that AL is being set equal to [EBP-9]. We can find out what EBP-9 is by Right-Clicking on EBP in the registers window and then choosing Follow in Dump. Count back 9 bytes from where you start in the dump and you will end up at 0012EE73 which contains 00.

To fix this program we are going to change the line so that AL always equals 1. Now select MOV AL,BYTE PTR SS:[EBP-9] and press Spacebar to edit it. In the window that pops up change MOV AL,BYTE PTR SS:[EBP-9] to MOV AL,1. Make sure Fill With NOP's is checked and press Assemble. Close the editing box and press RUN. If you have not removed your MessageBoxA breakpoints you will break on a call to a messagebox. By looking at the stack we can see that it is thanking us for registering LanHelper. Success! But will it work when we restart the program?

To make sure our program works when we restart it we need to save our changes to a new executable. Right-Click in the code window and choose Copy to Executable then All Modifications. A box will pop up asking if you want to copy the selected modification to the executable file; choose Copy All. A new window will open up with our modified program in it. Right-Click in the window and choose Save File. Pick a name for your file (I choose LanFixed.exe) and press Save. You can now close Olly.

Time to test it. Open up your newly saved file and... It works! No nag screen. Choose Help and then About from the menu and you will see that the program is now registered to your name.


Creating a Patch:
The final thing we are going to cover is how to create a patch for a packed file. This is useful because it is much easier to send a patch out rather than a large modified executable. Once again I am going to use Diablos2oo2 Universal Patcher, or DUP. We used this patcher before to create an offset patch but this time we are going to use it to create a patch based on virtual offsets. A nice thing about this patcher is the fact that it supports packed files.

Begin by opening up DUP. You start in the Patcher Settings. Enter LanHelper in the Application Name. Click the browse button next to the Target Filename box and browse to LanHelper.exe. The other boxes are optional, under Release Info you may want to give a little description on how to use the patch. You can customize the About Box and the Icon and add your own skin and other options, by pressing the Options button.

Once you have filled in the boxes, choose the Offset Patch tab at the top. First check the box that says Virtual Address Mode this allows us to patch the executable based on the offsets of the program when it is loaded into memory. For the original file choose our unpacked LanDump_.exe and for the Patched File choose LanFixed.exe. Press the Compare button and it will fill our list with the modified bytes. Now we need to give the patcher the information of our original packed executable. Press the Get It... button under Target File: Filesize + CRC32. Choose LanHelper.exe and then Open. Once dUP has the target file information press Create Patch and choose a name for your patch.

You are done! Backup LanHelper.exe and run the patch. Now run the patched LanHelper and it will show you as registered! To test registering it again, delete the values from the sn and user keys under HKEY_LOCAL_MACHINE\SOFTWARE\LanHelper. You have successfully unpacked a packed executable and have patched a registration scheme at the deepest level. You can now take whet you used here and apply it to other targets.

UPDATED FOR 1.41:

Dumping:
1. Follow the same steps under Dumping except you will break on a JMP after the POPAD.
2. Follow that JMP to get to the OEP.
3. Fix the IAT in the same way as above, using your newly discovered OEP.

Patching:
1. Load newly dumped executable in Olly
2. You are going to encounter a few exceptions. So in Olly's Debugging Options check Ignore memory access violations in Kernel32, and INT 3 breaks. Also, check the Ignore Custom Exceptions box. In the custom exceptions add the range (00000005 to <Same as Above>) and the range (C0000005 (Access Violation) to <Same as Above>).
3. If play around with the executable for awhile you will notice that setting a Breakpoint on MessageBox in the intermodular calls does not work.
-Instead-
4. Use the command bar plugin and type "BP MessageBoxA" without the quotes.
5. Try and register the program: type in any name and serial and press Okay. You will break on MessageboxA in the user32 module.
6. Look at the top line of the stack to see where the Call to messageboxA came from. In my case it was 4D5C1C.
7. Right click in Olly and choose Go-To->Expression. Type in 4D5C1C, or whatever address your call occured at, and press Okay. You will be at the call to messageboxa
8. Scrolling up in Olly's you will see code that is very similar to the code that calls the messagebox in version 1.40. However it is missing that nice little > that tells us what called this code.
-No Problem-
9. Remember w32dasm? Hope so! Leave Olly open, but also open up your dumped executable in w32dasm. Wait for it to analyze the file.
10. When you have the executable loaded into w32dasm. Choose GoTo at the top and choose Code Location on the drop down menu. Type in 4D5C1C, or whatever your call location was, and press Okay
11. You will see that you are at the call to messageboxA, scroll up a little until you see
Referenced by a (U)nconditional or (C)onditional Jump at Address:
4D571E(C) <-**This number may be different**
12. That address is where the Jump to the messagebox is made. Write it down and close out w32dasm.
13. Back in olly right-click and choose Go-to->Expression. Type in the address you just found and press Okay. You will find yourself just below a CALL and TEST. Just as in version 1.40.
14. Fixing the call and patching the program is just the same as in 1.40.