WinDbg Getting Started

Note: The ellipsis section of this article is: 1. How to load system symbols. 2. How to turn on the dual-machine debugging. These two parts are very important.

0x1 Program code

In order to master the WinDbg of the whole debugging process. The examples in this paper are written by ourselves. The advantage is that you can more proactively familiarize yourself with WinDbg's debug commands and see the results of WinDbg more intuitively.

0x2 WinDbg Commissioning Entry

Open WinDbg, click: File->open executable, check the compiled EXE file. WinDbg will automatically give the program the next breakpoint. But we don't know if this breakpoint belongs to the area of our program. So, let's take a look at where the breakpoint is broken. We enter the!address breakpoint address in the WinDbg command. As shown in the following:

The diagram shows not only the "airspace area" where the breakpoint is located, but also some other properties of the file. Since the breakpoint at this point is no longer the airspace we need, we will use the pseudo register mentioned above. We entered in the WinDbg: BP $exentry. You can also enter the BP @ $exentry. The function of @ is to let WinDbg no longer look for system symbols, which speeds up execution. BP, we can still look at WinDbg's help documentation. From this, we can know that BP is giving the address the next breakpoint. So that the program breaks down. What is that $exentry? We can click on the index in Help->content, enter: Pseudo view. $exentry is the entry point for our program.

After we enter the BL command, we can see the breakpoint below.

Enter the G command; G is the meaning of running the program. Run the program, the program will stop at the entry point of our program, that is, Oep.

But that's still not what we want. The function of the system symbol table is shown. Although the system symbol table loaded by this program is automatically generated by vs2015debug, the system symbol table is the same as the system symbol table downloaded from Microsoft.

We enter in WinDbg: BP main; it's that simple. Note: This symbol table is used by the local symbol table. Enter the G command; WinDbg will automatically break us into the main function.

After the G command is over, here we need to note: Click on the WinDbg toolbar source mode off. When Souce mode is on, the debug single-step command executes directly according to the steps of the function, rather than the actual single-step assembly command, which allows you to try switching between different switches. The concrete execution is as follows:

0x3 Key Commands

1) Stack content view

It is important here: This program is to understand the WinDbg process and instructions. Therefore, the source code display problem is not avoided. We step into the first call function of the program and can step into it with F8 or F11. Input command: KV. or click View->call stack to view it. At this point, we can see that the information in the stack is the same. From there, we can also see that KV is the command that displays the stack details. The k command in Windows Vulnerability Mining is one of the most useful commands for Windows to understand during execution.

From here, we can also see the KV command, 001218a7 is exactly the return address of the first call function. 00000001 and 00000002 are the arguments passed to the f_add. In the CVE Vulnerability number verification program, you often see the great God Gate view stack information is so. And what is CHILDEBP information? As shown, see in the figure: CHILDEBP is the pointer address of the base of the child function stack originally. RetAddr is the function address returned, and the Args to child is the parameter that is displayed.

2) Viewing of strings

Continue F10, after running the first call function, WinDbg displays a ' string ' character. So you want to know what this character is? How to view it? We use the DB command here to display the memory data in the form of byte. The DD command has no strings behind it, and is more monotonous, and the reader can try it himself.

We run to four parameters of the F_add function, KB view stack information, at this time, found that the args to the child can only display 3 parameters, if there are multiple parameters to do? The KP or KP commands can be used, and their results are the same, and knowledge is wrapped or not. The results are as follows:

3) Structure view

If we do not know the structure of st_m, want to see what the structure of st_m, you can use the DT st_m, you can see the following results. 3 int types, each occupying 4 bytes.

With this knowledge, we can simply do some debugging of Windows, do not believe, look at the following example.

0x4 Windows Dual-machine debugging (actual combat)

Exploit Source: Www.exploit-db.com belongs to the Seh Buffer overflow type.

Before execution:

After execution:

1) Look for the specified process and additional

Open Wavtomp3 this software. We use the. Process 0 0 command to view the processes running in XP. Then locate the specified process and pass the. process/i process address. Switch to the actual required process. After switching, remember the ' G ' run.

2) Find the right breakpoint

Proper breakpoints are important in many debugs, and breakpoints require experience accumulation and technical accumulation. Not a trick to eat the world's breakpoints. This article is because she has a buffer overflow. And it triggers an exception at the user level, so here we can go straight down: BP rtlpexecutehandlerforexception. It is also possible to stabilize a point; give the ReadFile function a breakpoint: BP ReadFile. But please note: be sure to. reload/f The symbol table for the function. Otherwise the breakpoint is not necessarily successful. The following is shown below:

3) Analysis Code

After running the program, it can be broken in the rtldispatchexception part function. Through the R command, view registers and view memory bytes through DB. For example, to see the value of the ESP register, you only need: DD esp. As shown in the following:

The value of Dex 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 DB esp-100 L200 view from the ESP this address from the top down

The byte of the 0x200 unit.

Step down (F10). The first call is encountered, as shown in the figure:

, the Executehandler2 () function passes 5 parameters. And Shellcode executes the call ECX in Executehandler2 (). We use the command to watch: The first parameter in the DD 0104FB24 address is the address of the execution function we want. is also the handler callback function address of the _EXCEPTION_REGISTRATION_RECORD structure.

See: The address of the exception is viewed through!exchain in the figure. The contents of the current exception chain are viewed through!slist $teb _exception_registration_record. It can also be proved that the handler of the anomaly chain is a callback function.

Continue stepping into (F8), we found here to actually pop up a MessageBox exception dialog box. The contents are as follows:

Continue with one step, and you'll have jmp to shellcode content. Or we can use a structure to observe. At this point in WinDbg, enter!teb; you can see the current value of the current TEB structure. The internal structure of Nt_tib can also be observed by Dt _nt_tib.

By contrast, we can see that our shellcode:0x909006eb and 0x004043a4 are covered with fs:[0], pointing to the next exception block and the callback function of this time respectively. So there is a call ecx, which is actually call 0X004043A4. Has pointed to what we want.

The following is the code for the instruction we want to execute. Three parts of the code are the same.

4) Concluding remarks

The main emphasis of this paper is to WinDbg the debug Operation command to explain. Helpful for how to debug your Windows system in the future. In the safety industry on the road, I hope everyone share.

WinDbg Getting Started