In this blog series, I will try to set some base knowledge for Windows system debugging & exploitation and present how to setup an environment for remote kernel debugging. This environment will be useful for learning Windows internals and indispensable for our future posts about its exploitation. About Windows internals, I really recommend the training from Pavel Yosifovich on Pluralsight that will expand your familiarity with the system if you are new to the topic.
Windows exploitation is certainly not an easy subject to learn since there are not many Windows challenges available. When you look at current CTFs for example, you will find only a few basic/introductory write-ups covering Windows protections and memory allocations, but I will try to write about the subject in future posts.
This series will be part of my studies too, so hopefully, this will help everyone in the same situation!
For this environment, you will need a debugger, a couple of VMs and curiosity!
WinDBG is a debugger developed by Microsoft and we will need it for debugging user and kernel space. There are other options, but WinDBG is definitely the best tool for our endeavor, so let’s get it started!
We will also need two VMs for our lab. One will be utilized as the debugger machine and the other will act as a target system. In this case, we will proceed with a Windows 10 x64 for debugging -- this is chosen because of WinDBG Preview availability on the OS. As a target we will use Windows 7 x64, since it has fewer protections than Windows 10 and will make our life easier while we are studying. By the way, it is possible to enable a local kernel debugging but this doesn't allow the researcher to debug “live” like breakpoint functions on drivers, etc.
You will need to enable the debugging mode on this Windows machine, as it is not enabled by default. You can use an elevated prompt command (cmd.exe) and the “bcdedit” utility for this. In our case, we will configure our target machine to use a serial connection for debugging as follows:
C:\Windows\system32>bcdedit /dbgsettings serial debugport:1 baudrate:115200
The operation completed successfully.
C:\Windows\system32>bcdedit /debug on
The operation completed successfully.
If we were working with both Windows 10, we could enable the debug option with network settings. However, Windows 7 does not have this option, so we will use the serial connection.
Now that we've setup the debugger to use a serial connection we now need to add and configure a serial port for each machine. In my case, I am using the VMWare Workstation but this configuration can replicated on any VM vendor as VirtualBox. On Windows 7, you set “The end is the server.”:
Figure 1 - Virtual Machine settings from Windows 7
On Windows 10, you set the “The end is the client.”:
After the target machine is set with debug mode and both machines with a serial connection configured, we can now proceed with setting up WinDBG.
Open the WinDBG Preview, Go to "Attach to kernel", select "COM" and use this configuration below:
Figure 3 - WinDBG Preview COM Configuration on the Debugger Machine
This is tricky, this port name is not related to the name we gave to our port connection on the VMWare settings. This is actually the port on the device manager. Basically, if you did not have any port before this new one, you should only have one serial port, so you will use “com1”, however, if any other was there already, you will use “com2”, “com3”, etc.
After the OK, you will connect to the target machine:
Microsoft (R) Windows Debugger Version 10.0.19494.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\com1
Waiting to reconnect...
Connected to Windows 7 7601 x64 target at (Fri Oct 18 10:50:26.300 2019 (UTC - 3:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (1 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02a01000 PsLoadedModuleList = 0xfffff800`02c46e90
Debug session time: Fri Oct 18 10:38:56.797 2019 (UTC - 3:00)
System Uptime: 0 days 0:04:03.716
Break instruction exception - code 80000003 (first chance)
*******************************************************
You are seeing this message because you pressed either
CTRL+C (if you run console kernel debugger) or,
CTRL+BREAK (if you run GUI kernel debugger),
on your debugger machine's keyboard.
THIS IS NOT A BUG OR A SYSTEM CRASH
If you did not intend to break into the debugger, press the "g" key, then press the "Enter" key now. This message might immediately reappear. If it does, press "g" and "Enter" again.
*******************************************************
nt!RtlpBreakWithStatusInstruction+0x1:
fffff800`02a79491 c3 ret
And we are good to go!
As you should note, there is a configuration regarding “Symbols”. Symbols are basically the name given to the functions on user API and kernel files. This is extremely helpful. If you don’t have the symbols for NTDLL.dll for example, you see a function being called as ntdll!7fff’73049342 (random address) and that does not give any extra information about what is being executed. However, if you have the symbols you will see what the function name is, for example: ntdll!RtlUserThreadStart. That can save some time helping identify what is actually happening in our code.
Microsoft provides a public repository for most if not all Windows versions. Vendors can also provide the PDB files for their applications as well, which is a really nice initiative. It is necessary to configure the server on the debugger and then the symbol files will be downloaded to your local computer. On WinDBG Preview, go to the Menu, Settings and set the Symbol path as “SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols”. This will make sure that all symbols downloaded go to the local path “C:\SymCache”.
Figure 4 - WinDBG Symbol Path
Now we have the environment setup for our tests. In the next part, I’ll write about WinDBG functionalities to get familiar with debugging on Windows systems. I will then move on with some internals, application and kernel exploitation. If you have any doubts or comments, let me know! Hopefully, by the end of this series, you will have a new tool in your security arsenal.