Windbg is an artifact for Windows debugging. It is an indispensable tool for viewing certain structures of the kernel, mining vulnerabilities, debugging the system kernel, and debugging drivers. However, due to the large number of windbg commands and the poor interface friendliness, it is difficult for newcomers to get started and discouraged. This article throws bricks to attract jade, starting from the basics and explaining windbg. Hope to make progress with us as newcomers!
Note: The omitted part of this article is: 1. How to load system symbols. 2. How to enable dual-machine debugging. Because of this part of the content, there are too many on the Internet. Readers can Baidu. But please note: these two parts are also very important.
0×1 program code
In order to master the debugging process of windbg as a whole. The examples in this article are written by myself. The advantage is that you can be more active and familiar with the debug commands of windbg, and view the display results of windbg more intuitively.
0×2 windbg debug entry
Open windbg, click: File->Open Executable, select the compiled exe file. Windbg will automatically give the program the next breakpoint. But we don't know if this breakpoint belongs to an area of our program. So, let's first look at where the breakpoint is broken. We enter the !address breakpoint address in the windbg command. As shown below:
The figure shows not only the "airspace" where the breakpoint is located, but also other properties of some files. Since the breakpoint at this time is no longer the airspace we need, the pseudo-register mentioned above will be used below. We enter in windbg: bp $exentry. You can also enter bp @$exentry. The role of @ is to make windbg no longer look for system symbols, thereby speeding up the execution speed. As for Bp, we can still look at the help documentation of windbg. From this, we can know that bp is the next breakpoint for the address. to stop the program. So what is $exentry? We can click on the index in Help->Content and enter: pseudo to view. $exentry is our program entry point.
Then we enter the bl command; we can view the breakpoints we have placed.
Enter the g command; g means to run the program. Run the program, and the program will stop at our program entry point, which is oep.
But this is still not what we want. This is where the role of the system symbol table comes into play. Although the system symbol table loaded by this program is automatically generated during vs2015 debug, the function of this system symbol table is the same as that of the system symbol table downloaded from Microsoft.
We enter in windbg: bp main; it's that simple. Note: This symbol table is the local symbol table used. Enter the g command; windbg will automatically break for us in the main function.
After the G command is over, here we need to pay attention: Click on the Source mode off of the windbg toolbar. When Souce mode is on, the single-step command of debug will be executed directly according to the steps of the function, rather than from the real single-step assembly command, you can try to switch different switches. The specific implementation is shown in the following figure:
0x3 key command
1) View stack content
A very important point here is: this program is to experience the process and instructions of windbg. Therefore, the display problem of the source code will not be avoided. We single-step into the first call function of the program, which can be stepped into with F8 or F11. Enter the command: kv. Or click View->Call Stack to view. At this point, we can see that the information in the stack is the same. From it, we can also see that kv is the command to display stack details. The k command is one of the most useful commands in Windows vulnerability mining and understanding the Windows execution process.
From the figure below, we can also see that after the kv command, 001218a7 is the return address of the first call function. 00000001 and 00000002 are exactly the parameters passed to f_add. In the program of CVE vulnerability number verification, it is often seen that Dashenmen checks the stack information. And what is ChildEBP information? As shown in the figure below, it can be seen from the figure: ChildEBP is the pointer address of the base address of the sub-function stack. RetAddr is the returned function address, and Args to Child is the displayed parameter.
2) Viewing of strings
Continue to F10, after running the first call function, windbg displays a 'string' character. So want to know what this character is? How to check it? We use the db command here, which is to display the memory data in the form of bytes. There is no string behind the Dd command, which is relatively monotonous, and readers can try it by themselves.
We run to the f_add function with four parameters, and kb checks the information of the stack. At this time, we find that Args to child can only display 3 parameters. What if there are multiple parameters? You can use the kp or kP command, and their results are the same, whether the knowledge wraps or not. The result is shown below:
3) Structure view
If we don't know the structure of st_m and want to see what the structure of st_m is, we can use dt st_m; we can see the following results. 3 int types, each occupying 4 bytes.
With this knowledge, we can simply debug some windows; if you don't believe me, see the following example.
0×4 Windows dual-machine debugging (actual combat)
The source of the exploited vulnerability: www.exploit-db.com belongs to SEH Buffer Overflow type.
Before execution:
After execution:
1) Find the specified process and attach
Open the wavtomp3 software. We use the .process 0 0 command to view the processes running in XP. Then after finding the specified process, pass .process /i process address. Switch to the process that is actually needed. After switching; remember to run 'g'.
2) Find a suitable breakpoint
Appropriate breakpoints are very important in many debugging, and breakpoints require accumulation of experience and skills. There is no breakpoint that can eat the whole world. This article is because of the buffer overflow of SHE. And an exception is triggered at the user layer, so here we can directly break: bp RtlpExecuteHandlerForException. You can also be more stable; put a breakpoint on the ReadFile function: bp ReadFile . But please note: Be sure to .reload the symbol table of the function under /f. Otherwise the breakpoint may not succeed. After the disconnection, it is shown in the following figure:
3) Analyze the code
After running the program; can be broken in the RtlDisPatchException part of the function. Use the r command to view registers, and use db to view memory bytes. For example, if you want to view the value of the esp register, you only need: dd esp. As shown below:
The value of dex in the figure is the length of the shellcode text. Eip has already pointed to the exception section. Esp points to the top of the stack. Viewed from the esp address from top to bottom through db esp-100 L200
0x200 units of bytes.
Step down (F10). Encounter the first call; the following figure is followed in the figure:
In the above figure, the executehandler2() function is passed 5 parameters. And the shellcode execution is call ecx in executehandler2(). We use the command to watch: The first parameter in the address of dd 0104fb24 is the address of the execution function we want. It is also the Handler callback function address of the _EXCEPTION_REGISTRATION_RECORD structure.
See the figure below: In the figure, the abnormal address is viewed through !exchain. View the content of the current exception chain through !slist $teb _EXCEPTION_REGISTRATION_RECORD. It can also be proved from the figure below that the Handler of the exception chain is a callback function.
Continue to step in (F8), we find that an exception dialog box of Messagebox is actually going to pop up here. The content is as follows:
Continue to single step, it will jmp to the content of the shellcode. Or we can use to observe through a structure. At this point in windbg, enter !teb; you can see the current value of the current teb structure. Dt _NT_TIB can also observe the internal structure of nt_tib.
By comparing the above and below figures, we can see that our shellcode: 0x909006eb and 0x004043a4 in the figure cover fs:[0], pointing to the next exception block and this callback function respectively. So there is a call ecx above, which is actually call 0x004043a4. already pointed to what we want.
The picture below; is already the code for the instruction we want to execute. The code for all three parts is the same.
4 Conclusion
This article mainly emphasizes the description of the debug operation commands of windbg. It is helpful for how to debug the windows system in the future. On the road of the safety industry, I hope that everyone can encourage each other.