Nullcon New Delhi 2012 and DefCon 21 Presentations:

NullCon 2012:
http://www.youtube.com/watch?v=Vyi8b3VOw9M

DefCon 21:
https://www.youtube.com/watch?v=ENL9FF0JMA8

Windows 8 Kernel Debugging

Starting with Windows Vista, Microsoft changed the Windows Boot Manager, thereby changing the way we debug the Windows Kernel. Now, there is a new tool called bcdedit.exe which can be used to modify the boot configuration of a Windows installation.

The goal is to set up kernel debugging via virtual serial port, on a Windows 8 guest VM running on a Windows 8 host via the built in Hyper-V that comes with Windows 8. The pipe name will be “debug” in this example. The first step is to enable the COM port of the guest VM in the VM’s settings:

Next, enable kernel debugging on the guest VM by running the following commands from an elevated command prompt on the guest:

bcdedit /debug on

bcdedit /dbgsettings serial debugport:1 baudrate:115200

The next step is to prepare the host for debugging the guest VM. The host had the Windows 8 SDK, WDK, Visual Studio 2012, and the Visual Studio 2012 coinstaller installed, in that order. There are 2 ways to debug kernels in guest VMs from a Windows 8 host. The first is to use Visual Studio 2012 (new method), and the second is to Windbg (old method). Visual Studio 2012 now has integrated kernel debugging support using the same debugging engine as Windbg. Once the host machine has everything installed, the steps to debug using Visual Studio 2012, are as follows:

1. Run Visual Studio 2012 as Administrator
2. Under the Tools->Attach to Process window, select "Windows Kernel Mode Debugger" for Transport.
3. Click "Find" next to "Qualifier"
4. In the "Configure Computers" window use the following settings:
   Transport=Serial
   Port=\\.\pipe\debug
   Baud=115200

 

To use the old Windbg method:

1. Run Windbg as Admin on the host
2. Hit ctrl+k to connect to the serial port exposed by the VM
3. Use the following settings

  

 

 Further Reading:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542279(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/ff545440(v=vs.85).aspx

Single Step Debugging Explained

Single Step debugging of machine instructions is a technique often used during vulnerability research and exploit development to debug a program at an atomic level. At this level of granularity, one can see the individual assembly instructions as they are being executed by the CPU chip, and the states of the registers and memory as each instruction is executed.

Single step debugging is supported in part by the operating system and in part by the CPU. On Intel's x86 architecture, the EFLAGS register's bit 8 is the TF(Trap Flag) bit. If this bit is set before an assembly instruction is executed, the CPU raises an exception (Interrupt 1) after the execution of the assembly instruction is completed. Once the CPU raises the exception, the following events happen in order(see Windows Internals 5th Edition, Chapter 3):

1. The TF bit is cleared. This is why the 3rd least significant digit of "efl" register as displayed in windbg is always an even digit when single stepping. The CPU clears the TF bit before calling the exception handler, which is invoked much before the debugger ever gets it.
2. The kernel looks up entry number 1 in the system's IDT(Interrupt Descriptor Table).
3. If a debugger is attached, it is alerted about the single step exception.
4. If no debugger is attached or the exception is not handled by the debugger, the Operating System's Exception Handling mechanism is invoked.
5. If the Exception Handling mechanism still does not handle the exception, the debugger is given a second chance to handle the exception.
6. If no debugger is available, the process is killed.

The following test program manually sets the TF bit in the EFLAGS register:

#include <stdio.h>

void main()

{

    while(1)

    {

        printf("inside loop\n");

        __asm{

            pushfd

            pop eax

            or eax, 0x00000100 //set TF bit in EFLAGS

            push eax

            popfd

        }

    }

}

This program was run with and without a debugger(windbg) attached. When run with a debugger attached, there were no breakpoints set, but single step exceptions were set to be handled, as seen by the following:

0:000> sx

…

sse - Single step exception - break

…

When the test program was run with the debugger attached, a single step exception was caught by windbg:

(bf4.d98): Single step exception - code 80000004 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

This proves that setting the TF flag from within a program will cause an exception that an attached debugger can catch for single stepping. In this case, the exception mentioned in step 3 above is handled by the debugger.

The next experiment was to run the program again, but without a debugger attached. Below is the result:

step 6 was reached, and the process was killed due to the unhandled exception(no debugger to handle it)

 As is clear, single step debugging is supported in part by hardware, and in part by software.

Sources:

Windows Internals 5th Edition, Chapter 3

Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C