proudly presents his XV. Cracking Tutorial (02.06.1999)
How to use W32Dasm as a debugger.

I.   Tools you need for my tutorial
II.  The Crack

I. Tools you need for my tutorial
   W32Dasm (get it at CrackZ page (you find a link at

II. The crack
After some request by different fellows I decided to write a tutorial about the use of W32Dasm as a debugger. To say it first. The W32Dasm debugger is far less powerful than SICE.Anyway I prefer using it. You ask why? I prefer looking at WIN95-style windows and I can load the W32Dasm debugger when I want and I terminate it when I want. To get rid of SICE you have to reboot the computer. Yes, that's all. Generally both debuggers work in the same way (as every debugger), but W32Dasm only works with the absolute general things, like changing registers and setting breakpoints on code lines. In SICE you have hundreds of possibilities.

Get relaxed, this will be a long essay. Perhaps it's better to print it out. Get a nice drink (I prefer water, the one and only drink) and some music in the background (Blind Guardian, what else :). Everything OK? Then let's go.
Sometimes I will say that this or that option is irrelevant and will not explain it further. Don't wonder about it. I am sure you can handle SICE not bad, and don't know what the instructions "IRP" and "OBJDIR" are (or at least you never used them).
Before we start let's have a look at the different options we see in the menu. "Load Process" let's you debug an EXE file you have currently disassembled. There's the first main difference between W32Dasm and SICE. In SICE you can debug everything what is currently running (even the Windows Kernel), W32Dasm allows you to debug only the disassembled exe (or dll) file.
"Attach to an active process" disassembles an active process you have chosen and then starts debugging. The other menuitems are currently irrelevant. Only "Debugger Options" might be of some interest. In fact I never changed an option. Most of the options are self explaining, if you want more information consult the helpfile.

Alright. Disassemble a program and then choose "Debug/Load Process". First a small window pops up asking if you want to start the prog with parameters. I used this option only once in my life and it failed, so I don't know if this works correctly or the problem was something different. Just push [ENTER] (or disable "Enable Command Line on Load" in the options) and go on. Now the following windows should appear:

This is the instruction window (the help file calls it the "Lower Right Hand Debugger Window", but I don't like that). In the big listbox you see which ASM instruction will be executed next (this is the highlighted line) and which will follow.
Below there are 5 checkboxes. You should always have enabled the the first, the second and the fourth one. This will make the program stop when your target window calls a API function. A window will appear showing the values that are passed to the API call and the values the API returns. (Most time this is irrelevant, but when you are in a code calculation routine that could be your success; this window is one of the things that are better in W32Dasm than in SICE). The other two checkboxes are rather irrelevant.
The "Copy "button at the right copies the contents of the listbox to the clipboard (only the part you can see). There will be more "Copy" buttons in other windows, but I will not mention them again. They always copy the contents of the text field they belong to into the clipboard.
I never use the "Goto address" button because it will only display another part of code in the listbox. It is better to use the "Goto Address" in the main window of W32Dasm. Then you can set a breakpoint on the highlighted line by pressing [F2].
Pressing "Patch code" makes a window appear where you can patch the current instruction line. Note: This patch will only be done in the RAM. When you restart the program the changes will be gone. We will have a closer look to this window later.
"Terminate" closes all debugging windows and the program that was debugged. (If an error is caused by the target program or the program terminates, the caption of the button will change to "Close", but the effect when you click it will be the same, except that the target program is not to be closed, as it is closed, yet).
When you start debugging a program it will not be executed immediately (at first the DLL that the program uses will be loaded, then the debug process stops). You have to do this manually by pressing either "Run" (this makes the program without any debugging stuff) or "Step Into" (This executes the next - in this case first -instruction. Then the debugger will stop again and wait for your next command.). "Step Over" has the same effect as "Step Into". The difference is when you come to a CALL. "Step Into" traces into the call, "Step over" quickly executes the code inside the call and then goes on with the next instruction after the call. The equivalents in SICE are F8 (Into) and F10 (Over). The "Auto Step..." buttons do the same like the "normal" "Step..." buttons. The difference is that the "Auto..." buttons don't break after executing one instruction. They repeat their function until you push "Pause"


The next window I call "Code window". In the top left corner you can see the value of the different registers. Right from that is the window that displays the status of the different flags. I never needed others than Z (ero flag) for JE/JNE and O(verflow flag) for JG/JL... Below there is the window that displays where the registers point to. You can access the different registers by clicking on the small buttons at the left. You wonder what UA1 und UA2 are? You have two spaces for adresses you can permanently have a look at. You can specify the adresses in the two different dropdownlists below of the registers list. For example: If you enter 42d0a8 as the second user address a click at UA2 will always show the contents of this address. The buttons DWord, Word, Byte and Code just choose in which way the memory is displayed. The "On" and the "Off" buttons are never used. The "Off" button switches the display of the memory off, the "On" button on.
Additional information about the address that is currently displayed is given in the text field below "Source For Data Disp 2". "Disp 1" shows information about the selected register. You know what UA1 and UA2 means, the only new is "Oper". "Oper" gives information about the current operation. For example: The very first instruction of "Startclean" is: mov eax, dword ptr fs:[00000000]. When you choose "Oper" you get the values of EAX and FS:[00000000]. The text field below (in the picture Tr0001...) and the brown square in the upper right corner give information about the current status of the program. The second textfield (even belower) gives information about the DLLs that are used. The "Modify Data" button opens another window which allows you to modify the values of registers and flags (more about that later). "Goto Current Eip" is useful when you traced through the instructions in the listbox. This button brings you back to the next instruction that is executed.
Now to the right side of the window. The "Segment Reg" displays nothing else than the starting offset of the different segments. The listbox "BPts" list all breakpoints where the button "Clear" clears them (what else ;) and the buttons "AA" and "DA" activate and deactivate them. The checkboxes in the lower right corner are nothing but the same settings you can choose with Debug/Debugger Options.


OK, this is the window where you can patch the contents of registers and the status of flags. It's easy. To change the different flags, just click on the small fields containing 0 or 1. The status will change. If you want to make the change perfect, you have to press the "Modify" button at the lower right. The registers are changed a little different. Choose your prefered data type (DWord, Word or Byte) and enter a value in the "Enter Value" field. The click on the small button of the register you want to change (eax, ebx and so on). UA1 and UA2 are the same as last time, only "Dsp2" and "Mem" are new. The "Dsp2" stands for "Display 2". The value of it is a little harder to calucate. In the second window I explained, there was a part with the text "Source for Display 2". There is additional information about the current register displayed. Let's say the active register is EBP and the value at the memory location EBP points to is 75FE24. On this memory location you will find 8 bytes, let's say 00712345. Then DSP2 displays the bytes at address 00712345. "Mem" allows you to edit any memory address even the ones that are currently not addressed by registers. You can choose the address in the "Mem Loc" text box. To make the changes permanent you have to press the "Modify" button. To make the changes undone (as long as you haven't pressed the "Modify" button) you can press the little "R" buttons on the right. "Reset All" is the same as pushing all of these "R" buttons. "NOP Instruction @ eip" just NOPs the instruction that is to be executed next. (Don't forget to press modify)


This is the "Patch Window". It lets you easily patch the instruction that should be executed next. The address is displayed in the upper left corner, the instruction right of it. Below you can enter a new instruction. The new instruction mustn't be bigger (in opcode-bytes) than the old one. I don't even know if you are allowed to use instructions that need less bytes or if the new instruction must have exactly as much bytes as the old one. If you have entered the instruction press [ENTER]. If you have entered a valid instruction your change is displayed in the "Code Patch Listing". "Apply patch" makes the patch permanent, "Clear Patch" makes the patch undone. "Remove Last Line" removes only the patch of the last line and "Close" closes this window.


That was all. Pretty theorethical, eh? I don't like this theorethical stuff , splet's make the theorethical practical. A short introduction to "Using W32Dasm as a Debugger". The target is Startclean. I won't explain anything, but the "Debugging with W32Dasm stuff".

Start the prog. Register. Enter a name and a serial. "Incorrect Code". Disassemble Startclean. Search for the string of the messagebox. Line :004027A3. Start debug session. Choose "Goto/Goto code location" and enter 4027A3. Press F2. Now a yellow square should indicate that you set a breakpoint. Press F9 to run the prog. Try to register it again. Now it should break.First option: Changing the Z-flag, so that the program will not jump to the "Beggar off". So "Modify Data". Click on the small text field that contains the value of the Z flag. It should change from 1 to 0. "Modify" to make the change permanent. "Close" and push F9 to make the program run on. Now you get "Thanx" message.
Second option. NOPing the jump. After the breakpoint breaks, "Modify Data". Check "NOP Instruction @ eip" and "Modify". Then "Close" and F9. The thanx message again.

Final Notes: I experienced that it is much harder to write a tutorial about something general. Writing about cracking a target is *much* easier and I believe the quality of this essay is far not the quality of my other essays. Anyway I hope I was able to give you a short introduction of my *favourite* debugger.

Greets/Thanx and Gratitude to: Fravia+, tKC, ED!SON, Moral Insanity, +Sandman, Eternal Bliss, DaVinci and all [hf] members

Visit Hellforge at for more tutorials and high quality cracking links.
If you want to mail me:

LaZaRuS [hf]