Use WinDbg to debug Windows Kernel Process Analysis

Use WinDbg to debug Windows Kernel Process Analysis

If you can check the operating system's internal working process, it will be a powerful capability. Some advanced malware share the kernel as a common goal, and many of the most powerful vulnerabilities are also manifested in kernel components. Therefore, using a debugger to explore this environment is a powerful tool essential to any researcher's arsenal.
The process of learning this kind of debugging is very difficult, so I have provided some examples of getting started with WinDbg debugging. We try to move from basic commands to some more advanced debugger. This article uses three examples to demonstrate WinDbg's debugging capabilities. We hope to prove the strength of this tool in this way.
0 × 01 set the kernel mode debugging environment
All the examples below will use WinDbg, which can be obtained from the Microsoft official website. This "Windows debugging tool" provides package creation and multi-purpose debugger.
When it is set to kernel debugging, you need two machines. One is used for the debugger and the other is used to run the program to be debugged. The simplest way to establish a kernel debugging environment is to use a virtual machine and a software called VirtualKD. VirtualKD allows you to debug named pipelines, which is like a serial interface, greatly accelerating the connection. It also provides a virtual machine (VM) Monitor, which is automatically started as long as you start the Virtual Machine debugger.
VirtualKD works well with VMware or VirtualBox. The installation is simple and the commands can be found on the SysProgs website. If everything goes well, your VM will be interrupted in the debugger, like this:

 
Now all the debugging environment settings have been completed. At any time, you can use the "g" command to re-Execute debugging on the virtual machine. Similarly, you can use the CTRL + BREAK shortcut in WinDbg to interrupt a running Virtual Machine.
0 × 02 set the symbol
An important aspect of debugging is the establishment of the correct symbol of the target system. The symbol allows the debugger to match the address of the compiled binary program, the name of the function or variable, the source file path, and the line number corresponding to each symbol in the source file. The importance of the symbols to be displayed can be seen in the differences between the two identical stack trace results:
No symbols set:

 
Set symbol:

 
Fortunately, Microsoft provides most of the binary common symbols. Common symbols usually include defining all functions, static and global variables. They also provide a symbol server so that the debugger can query the correct symbols in binary files. The simplest way to create a symbol is to set the "_ NT_SYMBOL_PATH" environment variable. This is an environment variable for WinDbg and other programs, such as IDA, to query the symbolic path. You can use it to connect to the Microsoft symbolic server and cache the local symbolic path: c: \ symbols. The local cache accelerates subsequent symbolic access:
Srv * c: \ symbols * http://msdl.microsoft.com/download/symbols
Once the symbolic path is set, restart WinDbg and set the new symbolic path correctly. You can type ". sympath" in WinDbg to confirm the path of the symbol it is using. At this point, you can run the ". reload-f" command, which forces the target system to download all the symbols, cache and load each module.
0 × 03 start to use some Basic Debugging commands
WinDbg is a powerful tool, but it is not especially user-friendly for those who have not debugged it. It provides a large number of available commands, and some common commands are worth looking. Here is a detailed command list. The HELP command is ". hh ". We will debug the basic functions called by the system through WinDbg. The following are all completed in Windows 7 64-bit system.
First, let's see which modules are loaded on the current target system. If your symbols are correctly set, you can execute your first WinDbg command. Run the "lm" (list module) command to view the list of currently loaded modules. You should see the module name and the loaded address information. This is a list of screenshots taken from my VMS.

 
The "NT" module in the above list is interesting. This is the name of the Windows Kernel execution module. This module is the main functional area of the Windows Kernel. It is responsible for I/O, object management, security, and process management. Run another command to go deep into the kernel and view its export function. The WinDbg command "X" (check) queries the symbols of a given module. It can be called as "module>! Symbol> "and accept wildcards. All accessible system calls start with NT. We use "x nt! The NT * File * command lists system calls related to File operations.

 
The returned value is the name of the function in the memory. Let's use "U" (disassembly) to look at one of the memory functions. The "U" command requires a memory address, which is the address of the function in the memory, and the return value is the disassembly function of the function. We can use the memory address to disassemble the NtCreateFile function. Windbg will parse the address here for us:

 
If you want to disassemble the entire function, you can use the "uf" disassembly command. Now, we can try to run a breakpoint on NtCreateFile to check some functions. The "bp" command is used to add a breakpoint. It also requires a memory address (or a valid symbol) as a parameter. Once a breakpoint is set and "g" is used to continue execution, the breakpoint will soon be disconnected:

 
In the above interrupt period, use the "K" (stack) command to display the stack call of this function. WinDbg fails to parse some symbols at the bottom. This is because we have entered the context of a user mode process without symbols loaded. We can use ". reload/user" to load these lost user pattern symbols. During kernel debugging, you must always remember when these user-mode processes are mapped to the memory. Because Windows uses virtual address space, user mode addresses only apply to the process context they are allocated. When the user process context switches, the symbol will need to re-load the user context. You can find the description of virtual addressing here ,. Once the symbol is reloaded, we can get a complete call Stack:

 
We can use "! Process-1 0 !" Query the current ing in the process (NtCreateFile is finally called in this process); the first parameter (-1) is used for the current process information, and the second parameter (0) is the data volume to be displayed. If it is set to 0, the minimum information is displayed.

 
In this case, we are called SearchIndexer. Finally, we can find the file that NtCreateFile calls the disk. To help us find this information, we need to know the parameters related to NtCreateFile. MSDN has recorded most of the System Call functions. NtCreateFile is like this:
NTSTATUS NtCreateFile (
_ Out _ PHANDLE FileHandle,
_ In _ ACCESS_MASK DesiredAccess,
_ In _ POBJECT_ATTRIBUTES ObjectAttributes,
_ Out _ PIO_STATUS_BLOCK IoStatusBlock,
_ In_opt _ PLARGE_INTEGER AllocationSize,
_ In _ ULONG FileAttributes,
_ In _ ULONG internal access,
_ In _ ULONG CreateDisposition,
_ In _ ULONG CreateOptions,
_ In _ PVOID EaBuffer,
_ In _ ULONG EaLength
);
The source is here.
In the kernel API, the file name field is the OBJECT_ATTRIBUTES struct and is passed as a pointer to NtCreateFile. In this case, it is the third parameter, so it will be passed in the R8 register. Read the documentation on the 64-bit call conventions to learn how functions are called. With this knowledge, because it is passed to our breakpoint function, the content of this structure can be displayed. The command "dt" (display type) can be displayed. We only need to give it a memory address and data type. Here, we will use "DT _ OBJECT_ATTRIBUTES @ R8", which is like an OBJECT_ATTRIBUTES structure to display the memory referenced by the R8 register.

 
Note: When they are generally structured by underscores. This is because the names of most Microsoft structures contain a leading underline, And the typedef definition has the same name with the omitted underline.
Now we are done. We can delete the breakpoint we set at the beginning. You can use "BL" (breakpoint list) and "BC" to delete breakpoints:

 
Now, through further debugging, we have mastered the necessary basic tools and technologies. Now you should be able to check the memory structure, breakpoint function, query symbols, and view the call stack. With these capabilities, you should be able to start exploring the system. When we use the above technology to continue the debugging research for the next part, we will also learn more advanced debugging skills.