WinDBG quick start tutorial

[Nytro]

WinDBG quick start tutorial

Step by step walk-through for learning basic commands and navigation in WinDBG.

© CodeMachine Inc. | codemachine.com | @codemachineinc

Overview

This post goes over the important commands in WinDBG through a step-by-step follow-along style walkthrough to help you get a jump start into using WinDBG and getting familiar with the commonly used commands. This is required pre-course reading for the Windows Security Developer Bootcamp.

We will use WinDBG Preview which can be downloaded from the Windows Store. The version that was used to write this post is WinDBG 1.0.2007.06001. All examples used in the post are from WinDBG running on Windows 10 Version 19042 64-bit version.

Getting setup

Prior to starting the debug session, we will set up the symbol path that we want WinDBG to use by running the following command in an administrative CMD.exe. If you have the variable _NT_SYMBOL_PATH already set up, you don't have to change it, and therefore running the following command would not be necessary.

setx _NT_SYMBOL_PATH SRV*C:\symsrv*http://msdl.microsoft.com/download/symbols

Launching the target process

We are ready to start the debugger. There are a few different ways to use WinDBG to debug a process, the most common ones are attaching to a running process and launching a process from WinDBG. For this walkthrough, we will be launching the native 64-bit executable from WinDBG.

To make it easy to follow along, we will choose an application that is available in every Windows 10 system i.e. notepad.exe. The 64-bit notepad.exe is located in the c:\windows\system32 directory.

Start WinDBG from the Windows 10 Start menu. Once WinDBG has started, select File, then Launch Executable.

http://codemachine.com/articles/figures/figure_windbg_quickstart_launch.png Launch Executable

In the Launch Executable dialog box, browse to the directory c:\Windows\System32 select notepad.exe and click on Open.

http://codemachine.com/articles/figures/figure_windbg_quickstart_notepad.png Select Notepad

When WinDBG launches an application, it stops at the initial breakpoint before the main entry point of the application is executed. When WinDBG launches notepad.exe the following lines will be displayed in WinDBG's command Window. This allows us to run some initial commands and set any desired breakpoints before the main entry point is called. More on this later.

Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Windows\System32\notepad.exe

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:\symsrv*https://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\symsrv*https://msdl.microsoft.com/download/symbols
Executable search path is: 
ModLoad: 00007ff6`f8830000 00007ff6`f8868000   notepad.exe
ModLoad: 00007ff9`ff090000 00007ff9`ff286000   ntdll.dll
ModLoad: 00007ff9`fd840000 00007ff9`fd8fd000   C:\WINDOWS\System32\KERNEL32.DLL
ModLoad: 00007ff9`fce20000 00007ff9`fd0e9000   C:\WINDOWS\System32\KERNELBASE.dll
ModLoad: 00007ff9`fe5a0000 00007ff9`fe5ca000   C:\WINDOWS\System32\GDI32.dll
ModLoad: 00007ff9`fcc90000 00007ff9`fccb2000   C:\WINDOWS\System32\win32u.dll
ModLoad: 00007ff9`fca90000 00007ff9`fcb99000   C:\WINDOWS\System32\gdi32full.dll
ModLoad: 00007ff9`fcbf0000 00007ff9`fcc8d000   C:\WINDOWS\System32\msvcp_win.dll
ModLoad: 00007ff9`fc910000 00007ff9`fca10000   C:\WINDOWS\System32\ucrtbase.dll
ModLoad: 00007ff9`fd6a0000 00007ff9`fd840000   C:\WINDOWS\System32\USER32.dll
ModLoad: 00007ff9`fd990000 00007ff9`fdce6000   C:\WINDOWS\System32\combase.dll
ModLoad: 00007ff9`fe7d0000 00007ff9`fe8fb000   C:\WINDOWS\System32\RPCRT4.dll
ModLoad: 00007ff9`fe030000 00007ff9`fe0de000   C:\WINDOWS\System32\shcore.dll
ModLoad: 00007ff9`fddd0000 00007ff9`fde6e000   C:\WINDOWS\System32\msvcrt.dll
ModLoad: 00007ff9`f1f70000 00007ff9`f220b000   C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.488_none_ca04af081b815d21\COMCTL32.dll
(4bc.1df4): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ff9`ff1606d0 cc              int     3

Debugger process architecture

Before we proceed any further let us quickly review the WinDBG Preview process architecture. WinDBG Preview is a UWP application that has very limited access to the system, certainly not enough to debug a process. Hence the WinDBG UI and the WinDBG debugger workhorse are in separate processes that communicate using the named pipe inter-process communication (IPC) mechanism. The WinDBG Preview UI process is DBG.X.Shell.exe which connects over a named pipe to EngHost.exe which is the process responsible for attaching or launching the process being debugged.

http://codemachine.com/articles/figures/figure_windbg_quickstart_processes.png WinDBG Process Hierarchy

The following command displays the command-line options that were passed to the debugger process (EngHost.exe). The named pipe with the name DbgX_c07674536fa94c33bdf0af63c782f816 is used by DbgX.Shell.exe to communicate with EngHost.exe.

0:000> vercommand
command line: '"C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2007.6001.0_neutral__8wekyb3d8bbwe\amd64\EngHost.exe" npipe:pipe=DbgX_c07674536fa94c33bdf0af63c782f816,password=9cd080f41b98 "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2007.6001.0_neutral__8wekyb3d8bbwe\amd64" "C:\ProgramData\Dbg"'

Performing some initial investigation

Let us obtain some basic information about the OS version and the process being debugged. The Show Target Computer Version (vertarget) command displays information about the Windows version and information debug session time.

0:000> vertarget
Windows 10 Version 19042 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Build layer:            -> 
Build layer:            -> 
Build layer:            -> 
Machine Name:
Debug session time: Sun Dec  6 00:16:24.332 2020 (UTC - 8:00)
System Uptime: 0 days 17:37:21.507
Process Uptime: 0 days 0:03:22.680
    Kernel time: 0 days 0:00:00.000
    User time: 0 days 0:00:00.000

The (vertarget) command showed that there are 4 CPUs (cores) on the system, let's find out a little bit more about the Family (F), Model (M), Stepping (S), and the speed of the CPUs/cores in the system using the (!cpuid) debugger extension command. Note that the (!) symbol before the (!cpuid) command denotes that this command is not supported natively by the debugger rather it resides in a debugger extension DLL.

0:000> !cpuid
CP  F/M/S  Manufacturer     MHz
    0  6,14,3                  2607
    1  6,14,3                  2607
    2  6,14,3                  2607
    3  6,14,3                  2607

Prior to starting WinDBG, we had set up the environment variable _NT_SYMBOL_PATH to the symbol path. WinDBG should have automatically used the symbol path set in this variable. Let us verify that using the Set Symbol Path (.sympath) command. Note that the (.) in front of the command denotes that this is a meta-command. Most such commands cause a change in the behavior of the debugger. In this specific case, the (.sympath) command could be used with the (+) option to append another path to the current symbol path.

0:000> .sympath 
Symbol search path is: SRV*C:\symsrv*https://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symsrv*https://msdl.microsoft.com/download/symbols

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:\symsrv*https://msdl.microsoft.com/download/symbols

To find the path to the symbol file (.PDB) that the debugger is using for notepad we can use the debugger extension command (!lmi). This command parses the PE headers and displays information retrieved from the PE file's Debug Directory.

0:000> !lmi notepad
Loaded Module Info: [notepad] 
            Module: notepad
    Base Address: 00007ff6f8830000
        Image Name: notepad.exe
    Machine Type: 34404 (X64)
        Time Stamp: d686c2e9 (This is a reproducible build file hash, not a true timestamp)
            Size: 38000
        CheckSum: 3e7ca
Characteristics: 22  
Debug Data Dirs: Type  Size     VA  Pointer
                CODEVIEW    24, 2b604,   2a404 RSDS - GUID: {17F6F0A8-0039-D425-B201-69009E11D822}
                Age: 1, Pdb: notepad.pdb
                    POGO   49c, 2b628,   2a428 [Data not mapped]
                REPRO    24, 2bac4,   2a8c4 Reproducible build[Data not mapped]
        Image Type: FILE     - Image read successfully from debugger.
                    C:\Windows\System32\notepad.exe
    Symbol Type: PDB      - Symbols loaded successfully from symbol server.
                    c:\symsrv\notepad.pdb\17F6F0A80039D425B20169009E11D8221\notepad.pdb
    Load Report: public symbols , not source indexed 
                    c:\symsrv\notepad.pdb\17F6F0A80039D425B20169009E11D8221\notepad.pdb

Process and Thread Status

The Process Status (|) command can be used to find the process ID and the process name being debugged.

0:000> |
.  0	id: 4bc	create	name: notepad.exe

When WinDBG is being used as a user-mode debugger, the Thread Status (~) command displays information for all threads in the current process. At this time, there is just a single thread in the notepad process and the status of the thread is shown below. This information includes the Thread ID = 0x1df4, the address of the TEB of the thread 0x000000e979a72000, the suspend count of the thread and information about freeze state of the thread.

0:000> ~
.  0  Id: 4bc.1df4 Suspend: 1 Teb: 000000e9`79a72000 Unfrozen

Module Information

To find the virtual address at which any module is loaded in memory, we can run the (List Loaded Modules) (lm) command. Running the lm command by itself will display the starting and ending address range of where each module is loaded in notepad.exe process address space. /p>

0:000> lm
start             end                 module name
00007ff6`f8830000 00007ff6`f8868000   notepad    (pdb symbols)          c:\symsrv\notepad.pdb\17F6F0A80039D425B20169009E11D8221\notepad.pdb
00007ff9`f1f70000 00007ff9`f220b000   COMCTL32   (deferred)             
00007ff9`fc910000 00007ff9`fca10000   ucrtbase   (deferred)             
00007ff9`fca90000 00007ff9`fcb99000   gdi32full   (deferred)             
00007ff9`fcbf0000 00007ff9`fcc8d000   msvcp_win   (deferred)             
00007ff9`fcc90000 00007ff9`fccb2000   win32u     (deferred)             
00007ff9`fce20000 00007ff9`fd0e9000   KERNELBASE   (deferred)             
00007ff9`fd6a0000 00007ff9`fd840000   USER32     (deferred)          
00007ff9`fd840000 00007ff9`fd8fd000   KERNEL32   (pdb symbols)          
00007ff9`fd960000 00007ff9`fd990000   IMM32      (deferred)             
00007ff9`fd990000 00007ff9`fdce6000   combase    (deferred)  
00007ff9`fddd0000 00007ff9`fde6e000   msvcrt     (deferred)             
00007ff9`fe030000 00007ff9`fe0de000   shcore     (deferred)             
00007ff9`fe5a0000 00007ff9`fe5ca000   GDI32      (deferred)             
00007ff9`fe7d0000 00007ff9`fe8fb000   RPCRT4     (deferred)             
00007ff9`ff090000 00007ff9`ff286000   ntdll      (pdb symbols)          c:\symsrv\ntdll.pdb\1EB9FACB04C73C5DEA7160764CD333D01\ntdll.pdb

Running the (lm) command with the (m) option can be used to restrict the output to a specific module. We use this to retrieve the VA range assigned to the module notepad.exe.

0:000> lm m notepad
start             end                 module name
00007ff6`f8830000 00007ff6`f8868000   notepad    (deferred)             

To obtain version information of a module, which is stored in the resources (.rsrc) section use the (v) option of the lm command.

0:000> lm v m notepad
start             end                 module name
00007ff6`f8830000 00007ff6`f8868000   notepad    (pdb symbols)          c:\symsrv\notepad.pdb\17F6F0A80039D425B20169009E11D8221\notepad.pdb
    Loaded symbol image file: C:\Windows\System32\notepad.exe
    Image path: notepad.exe
    Image name: notepad.exe
    Image was built with /Brepro flag.
    Timestamp:        D686C2E9 (This is a reproducible build file hash, not a timestamp)
    CheckSum:         0003E7CA
    ImageSize:        00038000
    File version:     10.0.19041.488
    Product version:  10.0.19041.488
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    Information from resource tables:
        CompanyName:      Microsoft Corporation
        ProductName:      Microsoft® Windows® Operating System
        InternalName:     Notepad
        OriginalFilename: NOTEPAD.EXE
        ProductVersion:   10.0.19041.488
        FileVersion:      10.0.19041.488 (WinBuild.160101.0800)
        FileDescription:  Notepad
        LegalCopyright:   © Microsoft Corporation. All rights reserved.

In WinDBG, the name of any module is treated as an expression that evaluates to the start VA at which the module is loaded into memory. If we use the MASM expression evaluator operator (?) on the module "notepad", it displays the start VA of the module.

0:000> ? notepad
Evaluate expression: 140698708017152 = 00007ff6`f8830000

Setting an execution breakpoint

At this point, we have found a reasonable bit of information about the process being debugged. We will now set a breakpoint on the main entry point of the PE file of notepad.exe. To do so, we must find the symbol that represents the main entry point of notepad.exe. To obtain a list of all such symbols we use the Examine Symbol (x) command which accepts wildcards and therefore makes it quite convenient to obtain a list of functions that end with the word main. The parameter we are passing to the (x) command consists of - the name of the module (without the extension), the exclamation sign (!) as the separator followed by the name of the symbols (containing wildcards).

0:000> x notepad!*main
00007ff6`f883b090 notepad!wWinMain (wWinMain)

In the above output, the first column displays the address of the symbol at which the symbol resides followed by the complete name of the symbol that matched the given wildcard.

The Set Breakpoint (bp) command has the ability to set a breakpoint on either a symbol name or an address. We use it to set a breakpoint on the main entry point of notepad.exe.

0:000> bp notepad!wWinMain

Let us verify that the breakpoint is indeed set appropriately using the Breakpoint List (bl) command.

0:000> bl
    0 e 00007ff6`f883b090     0001 (0001)  0:**** notepad!wWinMain

It is noteworthy that the bp command was able to resolve the symbol notepad!wWinMain to the appropriate address i.e. 00007ff6`f883b090 and was able to set an execution breakpoint and enable it as indicated by the (e) in the output above.

Now that we have the breakpoint set, let us continue executing the process notepad.exe using the Go (g) command.

0:000> g
ModLoad: 00007ff9`fd960000 00007ff9`fd990000   C:\WINDOWS\System32\IMM32.DLL
Breakpoint 0 hit
notepad!wWinMain:
00007ff6`f883b090 488bc4          mov     rax,rsp

As soon as we continue execution, the function we set the breakpoint on gets called, the breakpoint triggers and WinDBG gives us back control of the process.

Hitting the breakpoint

WinDBG has stopped the execution of notepad.exe at the first instruction of the function notepad!wWinMain. Let us ascertain that by retrieving the value of all the x64 CPU registers. The values in the registers would also assist us with retrieving the parameters that were passed to this function since on x64 the first 4 parameters are passed in CPU registers. To retrieve the CPU registers we use the Registers (r) command.

0:000> r
rax=0000023771d528b6 rbx=000000000000000a rcx=00007ff6f8830000
rdx= rsi=0000000000000000 rdi=0000000000000000
rip=00007ff6f883b090 rsp=000000e9799dfd48 rbp=0000000000000000
    r8=0000023771d528b6  r9=000000000000000a r10=00000fff3f9cdb1f
r11=0002002080000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
notepad!wWinMain:
00007ff6`f883b090 488bc4          mov     rax,rsp

The above output confirms that the address in the instruction pointer (RIP) indeed points to the first instruction of the function notepad!wWinMain. The prototype of the function wWinMain is as shown below along with the CPU registers that contain the respective parameters.

int WINAPI wWinMain(
    HINSTANCE hInstance,     // rcx
    HINSTANCE hPrevInstance, // rdx
    PWSTR lpCmdLine,         // r8
    int nCmdShow );          // r9

From the output of the (r) command the value of hInstance = 0x00007ff6f8830000, hPrevInstance = 0x 0000000000000000 (NULL), lpCmdLine=0x0000023771d528b6, nCmdShow=000000000000000a (SW_SHOWDEFAULT).

Displaying stack contents

The RSP register points to the top of the stack of the current thread. For a 64-bit process, each value stored on the stack is 64-bits in size i.e. a pointer-sized value. To display the contents of memory starting at the address in the RSP register we use the (dp) variant of the Display Memory command.

Please note that the (@) sign in front of a register is required if the current expression evaluator is C++, but we use it by default just as best practice.

0:000> dp @rsp
000000e9`799dfd48  00007ff6`f8853b86 00000000`00000000
000000e9`799dfd58  00000000`00000000 00000000`00000000
000000e9`799dfd68  00000000`00000000 00000000`00000000
000000e9`799dfd78  00000000`00000000 00000000`00000000
000000e9`799dfd88  00007ff9`fd857034 00000000`00000000
000000e9`799dfd98  00000000`00000000 00000000`00000000
000000e9`799dfda8  00000000`00000000 00000000`00000000
000000e9`799dfdb8  00007ff9`ff0dd0d1 00000000`00000000

By default, the (dp) command displays 64-bit values in two columns. We can change that using the column (/c) option to the (dp) command to display the contents of memory in 4 columns, as shown below.

0:000> dp /c 4 @rsp
000000e9`799dfd48  00007ff6`f8853b86 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfd68  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfd88  00007ff9`fd857034 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfda8  00000000`00000000 00000000`00000000 00007ff9`ff0dd0d1 00000000`00000000

To display more than the default 16 values, we can use the object count (L) option followed by the number of values to display.

0:000> dp /c 4 @rsp L 20
000000e9`799dfd48  00007ff6`f8853b86 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfd68  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfd88  00007ff9`fd857034 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfda8  00000000`00000000 00000000`00000000 00007ff9`ff0dd0d1 00000000`00000000
000000e9`799dfdc8  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfde8  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
000000e9`799dfe08  00000000`00000000 000004e8`fffffb30 000004d0`fffffb30 00000000`00000019
000000e9`799dfe28  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000

And last but not the least, if we would like WinDBG to automatically attempt to map each one of the displayed values to symbols the (dps) variant of the Display Referenced Memory command can be used which in case of the stack would display all the return addresses as the map to symbols representing addresses within the functions that have been pushed on the stack by call instructions.

0:000> dps @rsp
000000e9`799dfd48  00007ff6`f8853b86 notepad!__scrt_common_main_seh+0x106
000000e9`799dfd50  00000000`00000000
000000e9`799dfd58  00000000`00000000
000000e9`799dfd60  00000000`00000000
000000e9`799dfd68  00000000`00000000
000000e9`799dfd70  00000000`00000000
000000e9`799dfd78  00000000`00000000
000000e9`799dfd80  00000000`00000000
000000e9`799dfd88  00007ff9`fd857034 KERNEL32!BaseThreadInitThunk+0x14
000000e9`799dfd90  00000000`00000000
000000e9`799dfd98  00000000`00000000
000000e9`799dfda0  00000000`00000000
000000e9`799dfda8  00000000`00000000
000000e9`799dfdb0  00000000`00000000
000000e9`799dfdb8  00007ff9`ff0dd0d1 ntdll!RtlUserThreadStart+0x21
000000e9`799dfdc0  00000000`00000000

Now that we have learned how to display the raw contents of the stack using the RSP register, let us view the stack the way it is meant to be displayed by the debuggers using the Display Stack Backtrace (k) command and its variants.

0:000> k
Child-SP          RetAddr               Call Site
000000e9`799dfd48 00007ff6`f8853b86     notepad!wWinMain
000000e9`799dfd50 00007ff9`fd857034     notepad!__scrt_common_main_seh+0x106
000000e9`799dfd90 00007ff9`ff0dd0d1     KERNEL32!BaseThreadInitThunk+0x14
000000e9`799dfdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x21

The information displayed is the call chain from the start of this thread's execution (ntdll!RtlUserThreadStart) all the way to the current function (notepad!wWinMain) on which we set our breakpoint. Let's dig a little deeper into the displayed call stack.

Each line displayed above represents the stack frame of a single function. The frame at the bottom is the least recent frame and the frame on top is the most recent frame.

The values listed under Child-SP are the values of stack-pointer (RSP) register for the frame. This is the value of the RSP register right after the prolog of the function listed under the Call Site column has finished execution. This value in the RSP register remains static throughout the function body. Local variables and stack-based parameters to the function are accessed using this value in RSP.

The RetAddr is the return address that the current function i.e. the function listed under Call Site will return to once the function has finished execution. This address corresponds to the location displayed in the next (lower) stack frame. For example, running the List Nearest Symbols (ln) command on the RetAddr in the topmost frame maps to the function and offset listed under Call Site in the frame below the topmost frame.

0:000> ln 00007ff6`f8853b86 
(00007ff6`f8853a80)   notepad!__scrt_common_main_seh+0x106   |  (00007ff6`f8853c00)   notepad!wWinMainCRTStartup

Now that we understand how to interpret the information displayed by the (k) command, let us try some of its variants. To include the frame numbers in the stack display use the (kn) variant of the Display Stack Backtrace (k) command.

0:000> kn
    # Child-SP          RetAddr               Call Site
00 000000e9`799dfd48 00007ff6`f8853b86     notepad!wWinMain
01 000000e9`799dfd50 00007ff9`fd857034     notepad!__scrt_common_main_seh+0x106
02 000000e9`799dfd90 00007ff9`ff0dd0d1     KERNEL32!BaseThreadInitThunk+0x14
03 000000e9`799dfdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x21

To display a clean stack trace which only lists the module and function names use the (kc) variant of the Display Stack Backtrace (k) command.

0:000> kc
Call Site
notepad!wWinMain
notepad!__scrt_common_main_seh
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart

And finally, to display the verbose stack trace that includes the stack-based parameters passed to every function on the stack, use the (kv) variant of the Display Stack Backtrace (k) command. It is critical to note that as per the x64 calling convention, the first four parameters to a function are passed via CPU register and not through the stack. Therefore, the values displayed under "Args to Child" which are values on the stack do not represent the actual parameters to the function and using them as such can be quite misleading. Due to this, the (kv) command has very limited use on x64.

0:000> kv
Child-SP          RetAddr               : Args to Child                                                           : Call Site
000000e9`799dfd48 00007ff6`f8853b86     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : notepad!wWinMain
000000e9`799dfd50 00007ff9`fd857034     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : notepad!__scrt_common_main_seh+0x106
000000e9`799dfd90 00007ff9`ff0dd0d1     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
000000e9`799dfdc0 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

Displaying strings

Now we look at some WinDBG commands that can be used to display different types of strings used by applications, such as ASCII strings, wide char strings, and Unicode strings. One relatively straightforward way of finding such strings is to look for symbols in modules such as notepad.exe or NTDLL.dll that represent data values as opposed to functions and whose names are indicative of them representing strings. The list of such variable names can be found using the Examine Symbols (x) command with the (/d) option. We also add the (/a) option which will display the output in ascending order of addresses The following output has been edited for brevity.

0:000> x /a /d ntdll!*
00007ff9`ff1ac000 ntdll!RtlpSlashSlashDot = <no type information>
00007ff9`ff1ac010 ntdll!RtlpDosCONOUTDevice = <no type information>
00007ff9`ff1ac020 ntdll!RtlpDosPRNDevice = <no type information>
00007ff9`ff1ac030 ntdll!RtlpDosNULDevice = <no type information>
00007ff9`ff1ac040 ntdll!RtlpDosAUXDevice = <no type information>
. . . [REDACTED]

Using the above technique on notepad.exe we obtain the symbol notepad!_sz_ADVAPI32_dll. The presence of 'sz' in the name of the data variable implies that the memory contains a NULL-terminated ASCII string. With this assumption, we run the (da) variant of the Display Memory command.

0:000> da notepad!_sz_ADVAPI32_dll
00007ff6`f88573a0  "ADVAPI32.dll"

Again, using the same symbols listing technique listed above, we obtain the symbols ntdll!SlashSystem32SlashString. Unlike the previous case, the name is not suggestive as to the type of string this data variable represents. It may be an ASCII string, wide char string, or Unicode string. When the format of the data in memory is not known in advance, the (dc) variant of the Display Memory command can be used to display the contents of that memory in both DWORD (32-bit) format and as ASCII characters provided the characters are printable.

0:000> dc ntdll!SlashSystem32SlashString
00007ff9`ff1ac1e0  00160014 00000000 ff1b75c8 00007ff9  .........u......
00007ff9`ff1ac1f0  001a0018 00000000 ff1b6fd0 00007ff9  .........o......
00007ff9`ff1ac200  ff0d08e0 00007ff9 ff0fd2c0 00007ff9  ................
00007ff9`ff1ac210  00000000 00000000 ff114580 00007ff9  .........E......
00007ff9`ff1ac220  ff0cea30 00007ff9 ff1a1c70 00007ff9  0.......p.......
00007ff9`ff1ac230  ff0d2950 00007ff9 ff0fd2c0 00007ff9  P)..............
00007ff9`ff1ac240  ff114cf0 00007ff9 ff114580 00007ff9  .L.......E......
00007ff9`ff1ac250  ff0d4700 00007ff9 ff0fd2c0 00007ff9  .G..............

By observing the contents of the memory location and recognizing the pattern - 16-bit integer, 16-bit integer, 32-bit NULL, 64-bit address, we can assume that we have a Unicode string header in memory. To ascertain this let us display the data type for the Unicode string header using the Display Type (dt) command.

0:000> dt ntdll!_UNICODE_STRING
    +0x000 Length           : Uint2B
    +0x002 MaximumLength    : Uint2B
    +0x008 Buffer           : Ptr64 Wchar

We can clearly see that the contents of memory match the fields of the UNICODE_STIRNG structure. So we go one step further and typecast the contents of memory at the symbol ntdll!SlashSystem32SlashString (0x00007ff9`ff1ac1e0) to the UNICODE_STIRNG structure.

0:000> dt ntdll!_UNICODE_STRING 00007ff9`ff1ac1e0
    "\SYSTEM32\"
    +0x000 Length           : 0x14
    +0x002 MaximumLength    : 0x16
    +0x008 Buffer           : 0x00007ff9`ff1b75c8  "\SYSTEM32\"

Now that we have confirmed that ntdll!SlashSystem32SlashString contains a Unicode string header, let us go ahead and display the string with the (dS) variant of the Display String commands.

0:000> dS ntdll!SlashSystem32SlashString
00007ff9`ff1b75c8  "\SYSTEM32\"

Instead of using the address of the UNICODE_STRING structure itself, we can also use the address in the Buffer field of the UNICODE_STRING structure (i.e. 0x00007ff9`ff1b75c8) to display the string. To do this we use the (du) variant of the Display Memory command. Please note that the wide char string must be NULL-terminated.

0:000> du 0x00007ff9`ff1b75c8
00007ff9`ff1b75c8  "\SYSTEM32\"

Displaying Memory Contents

Now that we know that the memory at the symbol notepad!_sz_ADVAPI32_dll contains an ASCII string, let us display the same memory in various other formats such as 8-bit byte (db), 16-bit word (dw), 32-bit double-word (dd) and 64-bit quad-word (dq). Please note that only the (db) command displayed the output in ASCII as well as hexadecimal numbers.

Display as bytes (char).

0:000> db notepad!_sz_ADVAPI32_dll
00007ff6`f88573a0  41 44 56 41 50 49 33 32-2e 64 6c 6c 00 00 00 00  ADVAPI32.dll....
00007ff6`f88573b0  22 05 93 19 01 00 00 00-a8 c9 02 00 00 00 00 00  "...............
00007ff6`f88573c0  00 00 00 00 01 00 00 00-b0 c9 02 00 20 00 00 00  ............ ...
00007ff6`f88573d0  00 00 00 00 05 00 00 00-00 00 00 00 00 00 00 00  ................
00007ff6`f88573e0  61 00 70 00 69 00 2d 00-6d 00 73 00 2d 00 77 00  a.p.i.-.m.s.-.w.
00007ff6`f88573f0  69 00 6e 00 2d 00 63 00-6f 00 72 00 65 00 2d 00  i.n.-.c.o.r.e.-.
00007ff6`f8857400  73 00 79 00 6e 00 63 00-68 00 2d 00 6c 00 31 00  s.y.n.c.h.-.l.1.
00007ff6`f8857410  2d 00 32 00 2d 00 30 00-2e 00 64 00 6c 00 6c 00  -.2.-.0...d.l.l.

Display as words (short).

0:000> dw notepad!_sz_ADVAPI32_dll
00007ff6`f88573a0  4441 4156 4950 3233 642e 6c6c 0000 0000
00007ff6`f88573b0  0522 1993 0001 0000 c9a8 0002 0000 0000
00007ff6`f88573c0  0000 0000 0001 0000 c9b0 0002 0020 0000
00007ff6`f88573d0  0000 0000 0005 0000 0000 0000 0000 0000
00007ff6`f88573e0  0061 0070 0069 002d 006d 0073 002d 0077
00007ff6`f88573f0  0069 006e 002d 0063 006f 0072 0065 002d
00007ff6`f8857400  0073 0079 006e 0063 0068 002d 006c 0031
00007ff6`f8857410  002d 0032 002d 0030 002e 0064 006c 006c

Display as double-words (long).

0:000> dd notepad!_sz_ADVAPI32_dll
00007ff6`f88573a0  41564441 32334950 6c6c642e 00000000 
00007ff6`f88573b0  19930522 00000001 0002c9a8 00000000 
00007ff6`f88573c0  00000000 00000001 0002c9b0 00000020 
00007ff6`f88573d0  00000000 00000005 00000000 00000000 
00007ff6`f88573e0  00700061 002d0069 0073006d 0077002d 
00007ff6`f88573f0  006e0069 0063002d 0072006f 002d0065 
00007ff6`f8857400  00790073 0063006e 002d0068 0031006c 
00007ff6`f8857410  0032002d 0030002d 0064002e 006c006c 

Display as quad-words (__int64).

0:000> dq notepad!_sz_ADVAPI32_dll
00007ff6`f88573a0  32334950`41564441  00000000`6c6c642e
00007ff6`f88573b0  00000001`19930522  00000000`0002c9a8
00007ff6`f88573c0  00000001`00000000  00000020`0002c9b0
00007ff6`f88573d0  00000005`00000000  00000000`00000000
00007ff6`f88573e0  002d0069`00700061  0077002d`0073006d
00007ff6`f88573f0  0063002d`006e0069  002d0065`0072006f
00007ff6`f8857400  0063006e`00790073  0031006c`002d0068
00007ff6`f8857410  0030002d`0032002d  006c006c`0064002e

Navigating in assembler

Although there are better reverse engineering tools than WinDBG such as Ghidra, WinDBG does provide the ability to navigate through assembler functions. The most glaring feature missing in WinDBG is the ability to perform cross-referencing.

To unassemble the instructions starting at the current instruction pointer (RIP) we use the Unassemble (u) command and the RIP register as the address parameter. The (u) command uses a linear scan algorithm to disassemble the opcodes for the next 8 instructions.

0:000> u @rip
notepad!wWinMain:
00007ff6`f883b090 488bc4          mov     rax,rsp
00007ff6`f883b093 48895808        mov     qword ptr [rax+8],rbx
00007ff6`f883b097 48897010        mov     qword ptr [rax+10h],rsi
00007ff6`f883b09b 48897818        mov     qword ptr [rax+18h],rdi
00007ff6`f883b09f 4c896020        mov     qword ptr [rax+20h],r12
00007ff6`f883b0a3 55              push    rbp
00007ff6`f883b0a4 4156            push    r14
00007ff6`f883b0a6 4157            push    r15

To unassemble the instructions backward we use the (ub) variant of the Unassemble command and again specify the RIP register as the address parameter to disassemble 8 instructions prior to the address in the RIP register. The following listing shows a series of INT 3 instructions before the start of the function notepad!wWinMain. These INT 3 instructions were added by the compiler to ensure that notepad!wWinMain starts at a 16 (0x10) byte boundary and provides a small code cave that can be potentially used for inline hooking.

0:000> ub @rip
notepad!IsElevated+0x80:
00007ff6`f883b088 cc              int     3
00007ff6`f883b089 cc              int     3
00007ff6`f883b08a cc              int     3
00007ff6`f883b08b cc              int     3
00007ff6`f883b08c cc              int     3
00007ff6`f883b08d cc              int     3
00007ff6`f883b08e cc              int     3
00007ff6`f883b08f cc              int     3

To disassemble more than 8 instructions we can specify an address range consisting of an address (RIP) and object count (L) followed by the number of instructions to display.

0:000> ub @rip L10
notepad!IsElevated+0x65:
00007ff6`f883b06d 85c0            test    eax,eax
00007ff6`f883b06f 0f455c2448      cmovne  ebx,dword ptr [rsp+48h]
00007ff6`f883b074 48ff150dba0100  call    qword ptr [notepad!_imp_CloseHandle (00007ff6`f8856a88)]
00007ff6`f883b07b 0f1f440000      nop     dword ptr [rax+rax]
00007ff6`f883b080 8bc3            mov     eax,ebx
00007ff6`f883b082 4883c430        add     rsp,30h
00007ff6`f883b086 5b              pop     rbx
00007ff6`f883b087 c3              ret
00007ff6`f883b088 cc              int     3
00007ff6`f883b089 cc              int     3
00007ff6`f883b08a cc              int     3
00007ff6`f883b08b cc              int     3
00007ff6`f883b08c cc              int     3
00007ff6`f883b08d cc              int     3
00007ff6`f883b08e cc              int     3
00007ff6`f883b08f cc              int     3

Both the (u) and the (ub) variants use a linear sweep algorithm to disassemble a function and as such are not aware of function boundaries or basic blocks within functions. The Unassemble Function (uf) command on the other hand uses a recursive algorithm that evaluates every basic block within a function to find other basic blocks. The following output has been edited for brevity.

0:000> uf @rip 
notepad!wWinMain:
00007ff6`f883b090 488bc4          mov     rax,rsp
00007ff6`f883b093 48895808        mov     qword ptr [rax+8],rbx
00007ff6`f883b097 48897010        mov     qword ptr [rax+10h],rsi
00007ff6`f883b09b 48897818        mov     qword ptr [rax+18h],rdi
00007ff6`f883b09f 4c896020        mov     qword ptr [rax+20h],r12
00007ff6`f883b0a3 55              push    rbp
00007ff6`f883b0a4 4156            push    r14
00007ff6`f883b0a6 4157            push    r15
00007ff6`f883b0a8 488d68a1        lea     rbp,[rax-5Fh]
00007ff6`f883b0ac 4881ec90000000  sub     rsp,90h
. . . 
[REDACTED]
. . .
00007ff6`f883b427 8b451f          mov     eax,dword ptr [rbp+1Fh]
00007ff6`f883b42a 4c8d9c2490000000 lea     r11,[rsp+90h]
00007ff6`f883b432 498b5b20        mov     rbx,qword ptr [r11+20h]
00007ff6`f883b436 498b7328        mov     rsi,qword ptr [r11+28h]
00007ff6`f883b43a 498b7b30        mov     rdi,qword ptr [r11+30h]
00007ff6`f883b43e 4d8b6338        mov     r12,qword ptr [r11+38h]
00007ff6`f883b442 498be3          mov     rsp,r11
00007ff6`f883b445 415f            pop     r15
00007ff6`f883b447 415e            pop     r14
00007ff6`f883b449 5d              pop     rbp
00007ff6`f883b44a c3              ret

If all we are interested in are the calls a function is making as opposed to the actual disassembly the (/c) flag to the (uf) command can list those. The following output has been edited for brevity.

0:000> uf /c @rip 
notepad!wWinMain (00007ff6`f883b090)
    notepad!wWinMain+0x41 (00007ff6`f883b0d1):
    call to notepad!wil::details::FeatureImpl. . . (00007ff6`f883cf44)
    notepad!wWinMain+0x92 (00007ff6`f883b122):
    call to notepad!wil_details_FeatureReporting_ReportUsageToService (00007ff6`f883e014)

[REDACTED]

    notepad!wWinMain+0x35e (00007ff6`f883b3ee):
    call to KERNEL32!FreeLibraryStub (00007ff9`fd85c7d0)
    notepad!wWinMain+0x36a (00007ff6`f883b3fa):
    call to combase!CoUninitialize (00007ff9`fd9b28d0) 
    notepad!wWinMain+0x38b (00007ff6`f883b41b):
    call to notepad!_imp_load_EventUnregister (00007ff6`f88538db)

Continuing Execution

Now that we are done with the walkthrough let WinBDG continue executing the process notepad.exe using the Go (g) command, once again.

0:000> g

List of commands

To recap here are the list commands we have learned about in this tutorial.

vercommand	Show Debugger Command Line
vertarget	Show Target Computer Version
!cpuid	Displays information about the processors on the system
.sympath	Set Symbol Path
!lmi	Displays detailed information about a module
|	Process Status
~	Thread Status
lm	List Loaded Modules
?	Evaluate Expression
x	Examine Symbols
bp	Set Breakpoint
bl	Breakpoint Enable
g	Go
r	Registers
dp	Display Memory - Pointer-sized values
dps	Display Referenced Memory - Display known symbols
k	Display Stack Backtrace
ln	List Nearest Symbols
da	Display Memory - ASCII characters
dc	Display Memory - Double-word values and ASCII characters
dt	Display Type
dS	Display String - UNICODE_STRING structure
du	Display Memory - Wide char characters
db	Display Memory - ASCII characters
dw	Display Memory - Word values
dd	Display Memory - Double-word values
dq	Display Memory - Quad-word values
u	Unassemble
ub	Unassemble backward
uf	Unassemble Function

Finishing up

This brings us to the conclusion of this tutorial of executing the most common commands in WinDBG on a user-mode process. We have learned how to set up symbols, launch a process from WinDBG, obtain basic information about the target process, threads and modules, set breakpoints, display stacks, display memory contents, display stack traces and navigate through function assembler listings. Most of these commands we have learned here would also work when WinDBG is used as a kernel debugger.

 

Sursa: http://codemachine.com/articles/windbg_quickstart.html