Windbg Study Notes (1)

Windbg Study Notes (1) -- Learn windbg

I. Preface
I have been learning windbg for several days. Although I am not familiar with the technology, I am still getting started with windbg, I think windbg is really much more difficult than ollydbg (I don't know if I am used to ollydbg), so I want to take some notes, so I can take a review after I forget it, it also provides some help to the windbg brothers. The article is a bit wordy. Beginners should be able to read it soon, and the old bird will be able to float...

Ii. windbg Introduction
Windbg is a free and powerful debugging tool released by Microsoft. Since it is a debugging tool released by Microsoft, it is of course very powerful in debugging Microsoft products. However, although it is powerful, it may be very difficult to operate. Sometimes, we may not know many special windbg functions, let alone use them. I am a beginner of windbg. At the beginning, I thought windbg was really difficult to get started. But now I have read a lot of information, even though I have been enlightened. Most of the time, we are used to using ollydbg or SoftICE (I have never used SoftICE), so we can also start with what we are familiar with and learn about windbg.

The following is some information in the http://bbs.dbgtech.net/, We can deepen our understanding of windbg. (I didn't mean to infringe the copyright of the original author. I just wanted to sort out the materials for your convenience. If any, please forgive me)

Kernel debugging:


User debugging:



Although windbg is indeed difficult to debug without source code, it is truly unique in kernel debugging. Like everyone else, I may be familiar with ollydbg, so I will try to write notes in the "ollydbg getting started series" Mode written by ccdebuger Daniel.

Iii. installation and configuration of windbg

Windbg is included in wdk and can be downloaded independently.
Official: http://www.microsoft.com/whdc/devtoo...g/default.mspx
English version of: http://bbs.pediy.com/showthread.php ?... Ghlight = windbg

The downloaded windbg installation program is similar to the installation process of the general program. Token.

The startup interface is similar to the following:


At this point, no other Windows may be found. However, as long as you click the corresponding window button (the area circled in red box), the corresponding window appears in the work area.

Windbg has several windows and functions are similar to those of ollydbg. The window name and usage are as follows:

Name hotkey usage
Command ATL + 1 input command, display command results and debug information output
Watch Alt + 2 observe the global variables, local variables, and register information of the command
Locals Alt + 3 automatically displays all local variables of the current function
Registers ATL + 4 observe and modify register values
Memory Alt + 5 observe and modify memory data
Call Stack Alt + 6 function call sequence recorded in stack
Disassembly Alt + 7 Disassembly
Scratch pad Alt + 8 whiteboard, which can be used for debugging notes, etc.
Processes and threads Alt + 9 displays a list Of all debugging targets, including processes and threads.
Command browser Alt + n run and browse commands
After the window is displayed, you can arrange the window. By dragging the window or right-clicking the window title and selecting the dock and always floating, you can place the window in the most suitable position for our work.


I don't know if it's my own problem. I was trying to arrange the window in a similar way as the ollydbg interface, but I couldn't do anything about it, finally, I selected two most commonly used Windows (Disassembly and command) and placed them up and down. Like:


If you have any tips for window placement, please let us know ....

Iv. symbol and source code path settings

As mentioned earlier, windbg is a powerful source code debugging tool. If we have the source code of the program, we can generate its symbol file. When using windbg for debugging, because windbg itself does not automatically recognize the symbol file, we need to set it.
You can open the file symbol file path and file source file path in the menu to open the corresponding dialog box and set it.




You can directly enter a directory in the Source Path editing box, or click the Browse button to select a directory. Multiple directories are separated by semicolons.

Some people may have questions. What is a symbolic file? Why do we not need to set the symbol file when using ollydbg?
In fact, I was very confused when I came into contact with it. I even thought that windbg could only debug files with source code. But later, through the experiment, we gradually learned.

In my understanding, a symbol is used to identify a function, variable, or tag of a program. For example, by loading a target file with source code and program symbols, you can easily use BP winmain (the main function of the program I used to test) and BP function name (a function in the program ).

What if there is no source code? So I had to use Microsoft's public symbol library. The so-called public symbol library can be understood as windbg's recognition of some Microsoft system functions (such as messageboxa), just like ollydbg's ability to recognize messageboxa. Although windbg can identify these system functions, it is not obvious (it will be exposed later ).

To set a public symbol file, you only need to enter the path in the edit box of the Set symbol file. The general input format is:
SRV * G: \ symbols * http://msdl.microsoft.com/download/symbols
It means to download the symbol from the address http://msdl.microsoft.com/download/symbolsto g:#symbols (the directory you set to save the symbol ). After setting, you can use the. Reload command windbg to reload the new symbol file. For detailed usage, refer to the windbg help document.

5. Workspace

A workspace is a tool used by windbg to save the current work environment. For example, you can save the current work window layout and symbol path settings. You do not need to reset the settings when loading the file again.

For example, if the current workspace does not load any debugging file, it is the default Windows open environment. All settings here, including window layout. Symbol source code path settings can be saved as needed. Windbg provides multiple storage methods, including

Save workspace --- save directly (save to the default file)
Save workspace as --- save as (save to the file specified by the user)
--------------------------------------------------------------------------
The files mentioned in the above two methods are not real files, but the items that windbg stores in the registry.
Registry location: HKEY_CURRENT_USER \ Software \ Microsoft \ windbg \ workspaces
This key generally contains four sub-keys: User, kernel, dump, and explicit, the first three subkeys are used to save user-mode debugging, kernel-mode debugging, and debugging dump files. The default save path of the system is saved in the SAVE workspace mode, while explicit is used to record the namespace saved using the Save workspace as method. Sometimes you may find that there is no subkey, because your windbg has not debugged files using this method.
For example, my registry HKEY_CURRENT_USER \ Software \ Microsoft \ windbg \ workspaces contains these items:

It indicates that my windbg has not been debugging the dump file.

Expand the user subkey to see:

As you can see, I have passed 3 programs in the user State, and their names are crackme3.exe1_crackme32.exeand adsfsf.exe, and they are saved in the SAVE workspace mode.

Some may ask, sometimes, after I debug the program, I do not select Save workspace, but close windbg directly and automatically save the workspace. This is because your windbg uses the "always save" method.
You can open the menu ---- view ---- options to open the Setting Dialog Box:

In the figure, the red box is circled as a prompt when the workspace is closed.
Select always ask. When the workspace is closed, the user is always asked whether to save it;
Select always save to automatically save the workspace when it is disabled;
Select never save and never save.

In addition, windbg provides another storage method [Save workspace to file], which is similar to the preceding two methods, but saves the workspace to the disk as a file, you can use a USB flash drive or other methods to port the workspace environment to other machines.

When the default storage method is used to open a workspace, windbg automatically opens the target file and the corresponding workspace file.

In addition, after the debugging target is loaded, the workspace is changed and saved, and the default startup environment of windbg is not changed. Only the workspace corresponding to the debugging target is changed to save the file, the original startup environment will be affected only when the windbg has not loaded any debugging targets.


Vi. Common Operations and commands
F9: Set the breakpoint. You only need to press the F9 key at the cursor position (in gray), and then press the F9 key again to delete the breakpoint. (Equivalent to F2 in ollydbg)

F10: step by step. Every time you press this key to execute an instruction in the Disassembly window, the call and other subprograms do not enter the code. (Equivalent to F8 in ollydbg)

F8 or F11: one step. Similar to a single step-by-step (F10) function, the difference is that when a call or another subprogram is entered, it first stays on the first instruction of the subprogram. (Equivalent to F7 in ollydbg)

F7: run to the selected location. The function is to directly run to the position where the cursor is located and pause. (Equivalent to F4 in ollydbg)

Shift + F11: run to the jump function.

F5: Run. Press this key. If no breakpoint is set, the program to be debugged will start running directly. (Equivalent to F9 in ollydbg)

Windbg does not have the [execute to user code] function similar to ollydbg. However, you can use a plug-in written in dumb, or you can press SHIFT + F11 multiple times until you jump to the user code.

Note: If a line in the Disassembly window is blue, it is not necessarily the current execution address. In the windbg Disassembly window, the number of lines of code displayed each time is fixed. You can use the previous and next buttons in the upper right corner of the window or the mouse wheel to view the front and back code, the blue color is displayed in the middle of each display. To return to the currently executed command, click Edit> go to current instruction in the menu.