Windbg DEBUG command 1 (k, U, X)

K *Command to display the call stack of a given thread and other related information

~ 0 k indicates printing the call stack of Thread 0, and K indicates printing the call stack of the current thread.

Kd> ~ 0 k

1. Childebp retaddr
2. 0007 fddc 77d191be NTDLL! Kifastsystemcallret
3. 0007 fdfc 010021b0 USER32! Ntusergetmessage + 0xc
4. 0007ff1c 010125e9 calc! Winmain + 0x25f
5. 0007ffc0 7c817077 calc! Winmaincrtstartup + 0X174
6. 0007fff0 00000000 Kernel32! Baseprocessstart + 0x23
7. 0: 002> K
8. Childebp retaddr
9. 00bfffc8 7c972119 NTDLL! Dbgbreakpoint
10. 00bffff4 00000000 NTDLL! Dbguiremotebreakin + 0x2d
11. 0: 002> ~ 2 K
12. Childebp retaddr
13. 00bfffc8 7c972119 NTDLL! Dbgbreakpoint
14. 00bffff4 00000000 NTDLL! Dbguiremotebreakin + 0x2d

We noticed the stack of thread 2. This is a remote thread created by windbg to execute the dbguiremotebreakin function. It calls dbgbreakpoint internally to execute the breakpoint command to trigger the breakpoint exception and force the program to be disconnected, so the threads printed by windbg always have one more thread, so don't be surprised why there are more threads.

 

In fact, I want to find out what the childebp/retaddr respectively refers to: K First, check the stack:

Kd> K

1. Childebp retaddr
2. 0012fb1c 7c95e612 NTDLL! Dbgbreakpoint
3. 0012fc94 7c940000f NTDLL! Ldrpinitializeprocess + 0 xffa
4. 0012fd1c 7c92e437 NTDLL! _ Ldrpinalize + 0x183
5. 00000000 00000000 NTDLL! Kiuserapcdispatcher + 0x7

Then open the Disassembly window:

Ntdll! Dbgbreakpoint:

1. 7c92120e cc int 3

Currently running to this line: Use r ebp to view the following values:

Kd> r EBP

1. EBP = 0012fc94

This value is childebp before ldrpinitializeprocess. F10 debug to ret (that is, 7c92120f) in one step)

Ntdll! Dbgbreakpoint:

1. 7c92120e cc int 3
2. 7c92120f C3 RET

Run F10 to debug and return it to ldrpinitializeprocess (7c95e612 ):

7c95e60d e8fc2bfcff call NTDLL! Dbgbreakpoint (7c92120e)

1. 7c95e612 8b4368 mov eax, dword ptr [EBX + 68 h] DS: 0023: 7ffd3068 = 00000070

We found that the 7c95e612 is the return address of dbgbreakpoint, that is, the return address should be the value of the next EIP after the function exits. I used to think it was the corresponding part of the RET/leave, it turns out to be the value after RET is run.

KBDisplays the first three parameters of each function passed to stack rollback.KPDisplays all parameters passed to each function in the stack rollback. The parameter list contains the data type, name, and value of the parameter.PThe command is case sensitive.Complete symbolic information is required to use this parameter.. (In fact, I see the same result as K)KP
AndPThe parameters are the same. All parameters passed to each function in the stack rollback are displayed. HoweverP, Function parameters are displayed in the second row, rather than at the end of the row as the data. (In fact, I see the same result as K)

Kd> KB

1. Childebp retaddr ARGs to child
2. 00bfffc8 7c972119 00000005 00000004 00000001 NTDLL! Dbgbreakpoint
3. 00bffff4 00000000 00000000 00000008 201760c0 NTDLL! Dbguiremotebreakin + 0x2d
4. 0: 002> KP
5. Childebp retaddr
6. 00bfffc8 7c972119 NTDLL! Dbgbreakpoint
7. 00bffff4 00000000 NTDLL! Dbguiremotebreakin + 0x2d
8. </Span>

If the KP has a symbolic file, it will display a large line. I will paste the KP print under a debug file:

Kd> KP

1. Childebp retaddr
2. 0012f78c 7c92daea NTDLL! Kifastsystemcallret
3. 0012f790 7c932298 NTDLL! Zwrequestwaitreplyport + 0xc
4. 0012f7b0 7c872a51 NTDLL! Csrclientcallserver + 0x8c
5. 0012f8ac 7c872b98 Kernel32! Readconsoleinternal + 0x1be
6. 0012f934 7c8018b7 Kernel32! Readconsolea + 0x3b
7. 0012f98c 102c207c Kernel32! Readfile + 0x64
8. 0012fa20 102c19c9 msvcr90d! _ Read_nolock (int fh = 0, void * inputbuf = 0x10316740, unsigned int CNT = 0x1000) + 0x62c [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ read. c @ 233]
9. 0012fa70 10253e43 msvcr90d! _ Read (int fh = 0, void * Buf = 0x10316740, unsigned int CNT = 0x1000) + 0x219 [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ read. c @ 93]
10. 0012fa98 102523e8 msvcr90d! _ Filbuf (struct _ iobuf * STR = 0x103113e8) + 0x113 [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ _ filbuf. c @ 136]
11. 0012faf0 10252440 msvcr90d! GETC (struct _ iobuf * stream = 0x103113e8) + 0x208 [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ fgetc. c @ 76]
12. 0012 fafc 1025245a msvcr90d! _ Fgetchar (void) + 0x10 [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ fgetchar. c @ 37]
13. 0012fb04 0041160b msvcr90d! Getchar (void) + 0xa [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ fgetchar. c @ 47]
14. 0012fbe4 004114b2 Test2! Mycls: Hold (void) + 0x2b [D: \ project1 \ Test2 \ Test2 \ test2.cpp @ 28]
15. 0012 fcec 0041167a Test2! Foo1 (void) + 0xa2 [D: \ project1 \ Test2 \ Test2 \ test2.cpp @ 39]
16. 0012fdc0 004116ea Test2! Foo2 (void) + 0x3a [D: \ project1 \ Test2 \ Test2 \ test2.cpp @ 45]
17. 0012fe94 00411743 Test2! Foo3 (void) + 0x3a [D: \ project1 \ Test2 \ Test2 \ test2.cpp @ 51]
18. 0012ff68 00411ce8 Test2! Main (void) + 0x23 [D: \ project1 \ Test2 \ Test2 \ test2.cpp @ 56]
19. 0012ffb8 00411b2f Test2! _ Tmaincrtstartup (void) + 0x1a8 [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ crtexe. c @ 586]
20. 0012ffc0 7c817077 Test2! Maincrtstartup (void) + 0xf [F: \ dd \ vctools \ crt_bld \ self_x86 \ CRT \ SRC \ crtexe. c @ 403]
21. 0012fff0 00000000 Kernel32! Baseprocessstart + 0x23

The function parameter list is displayed.

 

UCommand to display the disassembly of program code in the specified memory.

To disassemble an address, run the U command to add the address.

Kd> U 77d2929a

1. USER32! Sendmessagew:
2. 77d2929a 8bff mov EDI, EDI
3. 77d2929c 55 push EBP
4. 77d2929d 8bec mov EBP, ESP
5. 77d2929f 56 push ESI
6. 77d292a0 8b750c mov ESI, dword ptr [EBP + 0ch]
7. 77d292a3 f7c60000feff test ESI, 0fffe0000h
8. 77d292a9 0f85be800100 JNE USER32! Sendmessagew + 0x11 (77d4136d)
9. 77d292af 8b4d08 mov ECx, dword ptr [EBP + 8]

If a symbolic file exists, you can directly add the function name: kd> U USER32! Sendmessagew

1. USER32! Sendmessagew:
2. 77d2929a 8bff mov EDI, EDI
3. 77d2929c 55 push EBP
4. 77d2929d 8bec mov EBP, ESP
5. 77d2929f 56 push ESI
6. 77d292a0 8b750c mov ESI, dword ptr [EBP + 0ch]
7. 77d292a3 f7c60000feff test ESI, 0fffe0000h
8. 77d292a9 0f85be800100 JNE USER32! Sendmessagew + 0x11 (77d4136d)
9. 77d292af 8b4d08 mov ECx, dword ptr [EBP + 8]

Note that the function only supports the full name. If you write it as u USER32! Sendmessage and windbg cannot be recognized. Of course, you can press the tab to make windbg automatically match

UBIndicates that the area to be decompiled is calculated backward. IfUBAddress, The disassembly area isAddressThe ending 8 or 9 commands. If you useUBAddressLLengthIf the syntax specifies a region, the disassembly usesAddressThe content of the specified length at the end.

Kd> UB USER32! Sendmessagew

1. USER32! Sendmessageworker + 0x4ed:
2. 77d29290 5B pop EBX
3. 77d29291 C9 leave
4. 77d29292 c21400 RET 14 h
5. 77d29295 90 NOP
6. 77d29296 90 NOP
7. 77d29297 90 NOP
8. 77d29298 90 NOP
9. 77d29299 90 NOP

We can find that the last line after UB is just the beginning of U.

Similarly, if a symbolic file exists, we can use UF to disassemble the entire function:

UFCommand to display the disassembly code of the specified function in the memory.

 

XCommand to display the symbols that match the specified template in all contexts. Wildcard characters

Kd> X USER32! Send *

1. 77d53948 USER32! Sendpolicymessagea = <no type information>
2. 77d2fb6b USER32! Sendmessagetimeouta = <no type information>
3. 77d6b88f USER32! Sendopenstatusnotify = <no type information>
4. 77d6b49e USER32! Sendimemessageexa = <no type information>
5. 77d2d64f USER32! Sendpolicymessagew = <no type information>
6. 77d2cdaa USER32! Sendmessagetimeoutw = <no type information>
7. 77d65b26 USER32! Sendhelpmessage = <no type information>
8. 77d6b823 USER32! Sendmessagetoui = <no type information>
9. 77d6b48d USER32! Sendimemessageexw = <no type information>
10. 77d2cd08 USER32! Sendmessagetimeoutworker = <no type information>
11. 77d203fc USER32! Sendregistermessagetoclass = <no type information>
12. 77d3c2e7 USER32! Senddlgitemmessagea = <no type information>
13. 77d2d6db USER32! Sendmessagecallbackw = <no type information>
14. 77d6b129 USER32! Sendmessagecallbacka = <no type information>
15. 77d273cc USER32! Senddlgitemmessagew = <no type information>
16. 77d61930 USER32! Sendwinhelpmessage = <no type information>
17. 77d291b3 USER32! Sendmessageworker = <no type information>
18. 77d2929a USER32! Sendmessagew = <no type information>
19. 77d2f3c2 USER32! Sendmessagea = <no type information> </span>

Therefore, this can be used to locate functions,

Here we will introduce the string wildcard syntax

An asterisk (*) Indicates zero or multiple characters. In the previous example,

A question mark (?) Represents any single character, as shown in the following example:

Kd> X USER32! Sendmessage?

1. 77d2929a USER32! Sendmessagew = <no type information>
2. 77d2f3c2 USER32! Sendmessagea = <no type information> </span>

One well number (#) Matches zero or multiple first characters. For example,Lo # PMatch "LP", "Lop", "loop", "looop", etc.

A plus sign (+) Matches one or more first characters.

If you want to use#,?,[,],*,+Character, must be preceded by a backslash (\).