LaZaRuS
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
III. BTW
I. Tools you need for my tutorial
W32Dasm (get it at CrackZ page (you find a link at
http://come.to/hellforge))
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 http://come.to/hellforge
for more tutorials and high quality cracking links.
If you want to mail me: lazarus666@gnwmail.com
LaZaRuS [hf]