windows kernel debugging

.

McAfee Confidential

Kernel Debugging Demystify

Thomas ROCCIA | InfoSec [email protected]

.

McAfee Confidential2

OverviewSummary

0000 – $whoami

0001 –Why debugging Kernel?

0010 – Kerneland VS Userland

0011 –Windows Kernel Structure

0100 – Drivers

0101 – Setup a Lab with 2 VM

0110 – Rootkit Analysis

0111 – Conclusion

1000 – References

.


0000 – $whoami

• Thomas ROCCIA | @r1tch1e_

• InfoSec Researcher at Foundstone Intel Security (McAfee)

• Forensic / Incident Response

• Malware Analysis

• Penetration Testing

.


Overview

0001 – Why debugging Kernel?

0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


0001 – Why debugging Kernel?

• To better understand how works my system

• To better understand what’s happened when I got this…

• To analysis how works a driver

• To analysis a Rootkit

• Or just for play with the kernel…

.


Overview


0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

kerneland Userland

.


Userland


• Userland is the place where every user application running

• Userland usually refers to the various programs and libraries that the operating system uses to interact with the kernel

• A memory space is assigned to Userland application

• Each user space process normally runs in its own virtual memory space

• The processus in Userland can normaly not accessed to kerneland

.


Kerneland


• kerneland is a place of Operating System where Input/Output requests from Software are managed

• The Kernel is a specific software use for transmit data to processor

• The code is usually loaded into a protected area of memory, for avoid overwritten by other programs

• The kernel have full access to:– CPU– Memory– Devices

.

McAfee Confidential

• Operating System uses a protection ring

9

Protection ring


• A kernel connect the application software to the hardware

.


Windows Architecture


.


Memory distribution


• Userland memory space from0x0000 0000 to 0x7FFF FFFF• Applications process• DLL• Variables• …

• kerneland memory space from0x8000 0000 to 0xFFFF FFFF• Boot Drivers• Kernel• HAL• …

Userland

kerneland

.


Who wins?


• As we saw, kerneland has some protection to avoid access fromUserland

• But, what’s happen if user process attempt to access to kerneland?

• Normaly a crash!

• But sometimes a malicious code can gain full access to your system across vulnerabilities or with a malicious DLL…

.


Who wins?


• And now the attacker is like GOD in your system

.


Who wins?


• If we try to access to the kerneland from userland with a simply pieceof code:

.


Who wins?


• We get an error of access violation:

.


Overview


0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


Presentation


• The Windows Kernel is the composant that allow secure access fromWindows task to Hardware Abstraction Layer (HAL)

• Kernel32.dll, ntdll.dll and other dll are loaded in user-mode but this isa gateway for access to kernel

• On 32bit architecture the name of the kernel is NTOSKRNL.EXE

• The kernel is the only component to have access to the HAL:– DMA (memory)– Bus mapping– Horloge and timer– Interrupt– Privileged architecture

.


Architecture Kernel


• Windows Executive : Services de base du système d’exploitation, gestion mémoire, gestion des processus et des threads, securité, E/S, réseaux, IPC, etc.

• Kernel Windows : Fonctions bas niveau du système : gestion des exceptions et des interruptions, scheduling de threads et processus, synchronisation, etc.

• Device Driver : comprend les pilotes matèriels mais aussi les pilotesde devices virtuels (système de fichier, réseaux).

.


Processor initialisation


• When a kernel boot up, it performs basic initialization for eachprocessor.

• The PCR (Process Control Region) is a structure (one by processor) that stores critical CPU information and state

• Inside the PCR there is another data structure called PRCB (ProcessRegion Control Block. This structure contains information about processors (CPU type, model, speed…)

– Kd> dt nt!_KPCR / !pcr

– Kd> dt nt!_KPRCB / !prcb

.


System Calls


• The System Calls is used for interact with the hardware

• A system call is typically a function in the kernel that users request for services I/O

• It’s implemented in the kernel because only high-privilege code canmanage such resources

• System calls uses a service dispatcher for access to the kernelfunction

• In x86 for call the service dispatcher we use the SYSENTER instruction for access to the kernel mode and SYSEXIT for return to the user mode

.


System Calls – Service Dispatcher – SSDT


.


System Calls – Service Dispatcher


• Windows stores the System Call intotwo data structure

• KeServiceDescriptorTable: containsnative syscall table.

• KeServiceDescriptorTableShadow: contains same data in addition to the syscall table for GUI threads.

– dps nt!KeServiceDescriptorTable

– dps nt!KiServiceTable

.


Faults, Traps and Interrupts


• When a device requires the processor’s attention, it causes an interrupt that forces the processor to pause what it is doing and handle the device request.

• There is an Interrupt Descriptor Table (IDT) wich store eachinformation on the interrupt handler.

– Kd> dt nt!_KIDTENTRY

– Kd> !idt

.


Faults, Traps and Interrupts


.


Interrupt Request Level


• The Windows Kernel uses an abstract concept called InterruptRequest Level (IRQL).• Kd> !irql

• Interrupt can be devided into two general categories: • Software: They are triggered by conditions in the running code • Hardware: They are triggered by devices connected to CPU

• There is different level of priorities:• PASSIVE LEVEL (0): This is the lowest IRQL in the system. All the user-

mode code and most kernel code executes at this IRQL• APC LEVEL (1): This is the IRQL at which APC (Asynchronous Procedure

Calls)• DISPATCH LEVEL (2): This is the highest IRQL. Thread dispatcher and

DPC (Deferred Procedure Calls)

.


Interrupt Request Level


.


Processes and Threads


• A thread is defined by two kernel data structures:• ETHREAD: Structure contains information about thread

⎻ Kd> dt nt!_ETHREAD• KTHREAD: Structure contains scheduling information for the thread dispatcher

⎻ Kd> dt nt!_KTHREAD

• An ETHREAD contains a KTHREAD

• A process contains at least one thread and is defined by two kernel data:• EPROCESS: Stores basic information about process (PID, list of threads, security

token…)– Kd> dt nt!_EPROCESS

• KPROCESS: Stores scheduling information about the process– Kd> dt nt!_KPROCESS

• An EPROCESS contains a KPROCESS

.


Execution Context


• Every running thread has an execution context

• An execution context contains the adresse space, security tokens and other properties of the running thread.

• In the kernel three execution context can be defined:– Thread context: context of specific thread

– System context: Context of thread executing in the system process

– Arbitrary context: Context of whatever thread was running before the schedulertook over

.


Overview

0100 – Drivers

0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


What is a driver?

0100 – Drivers

• A driver is a software running in kernel-mode (sometimes in user-mode), use for communicate with hardware or devices.

• There are many different type of driver in kernel-mode the following are the most interesting:

– Legacy software driver: Software that runs in ring0 and interacts with the kernel through interfaces.

– Legacy filter driver: Driver that attach to an existing driver and modify its input.

– File system minifilter driver: Drivers that interact with the file system to intercept file I/O requests

.


Driver Entry Points

0100 – Drivers

• The DriverEntry() function is the first call in a driver load:

• This function load the structure DRIVER_OBJECT in a kernel memory space where the driver is a loaded

• To get information about a driver:– Kd> !drvobj <NameOfDriver>

• Windows communicates with drivers by sending IRP (Input Request Packet

NTSTATUS DriverEntry (PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath

);

.


Overview


0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


Environment


• This lab is setting up on Mac OS Host with Vmware Fusion

• You need to have 2 virtual machines with Windows:

1. Target (Kernel Debugging): Windows XP SP3

2. Debugger: Windows 7 with Windbg installed

.


Target Windows XP


• For activate the Kernel debugging mode we need to modify the Boot.ini file.

• Thi file is used for load the system in a specific mode or not• C:\boot.ini• Add the following line:

.


Target Windows XP


• In a terminal go to the VM file and edit the VMX file

• Scroll to the end of the file and add the following lines:

serial0.present = "TRUE"serial0.pipe.endPoint = ”server”serial0.fileType = "pipe"serial0.yieldOnMsrRead = "TRUE"serial0.startConnected = "TRUE"serial0.fileName = "/Users/tomroc/serial0"

.


WinDBG Windows 7


• In a terminal go to the VM file and edit the VMX file

• Scroll to the end of the file and add the following lines:

serial0.present = "TRUE"serial0.pipe.endPoint = ”client”serial0.fileType = "pipe"serial0.yieldOnMsrRead = "TRUE"serial0.startConnected = "TRUE"serial0.fileName = "/Users/tomroc/serial0"

.


WinDBG configuration


• Before start your WinDBG machine you need to boot your Target Machine (WinXP), for create the serial0 server

• Then boot on your WinDBG machine

• Download the symbols for XP from Microsoft website https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx

• Download WindDBG from Microsoft website http://msdn.microsoft.com/en-US/windows/desktop/bg162891

• Install it!

.


WinDBG Symbol configuration


• Run WinDBG as Administrator

• In WinDBG click File >> Symbols File Path and enter: srv*c:\symbols*http://msdl.microsoft.com/download/symbols

.


Starting Kernel Debugging


• In Windbg click File >> Kernel Debug

• Click in the “COM” tab and verify the information (com1 for us)

.


Starting Kernel Debugging


• Restarting your target Windows XP

• Choose Debugger enabled

.


Overview

0110 – Rootkit analysis

0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


What is a Rootkit?


• Rootkit is a malware that modify internal functionalities of the OS to hide their existence.

• These modification can hide files, processes or other resources from running program.

• There is many way for attackers to create a rootkit (Driver rootkit, Hooking rootkit, DKOM rootkit…)

• The most used is the SSDT hooking

.


SSDT hooking


• As we saw the System Service Dispatch Table (SSDT) is a table of pointers for various Nt functions, that are callable from user-mode

• A malicious application can replace pointers in the SSDT with pointers to its own code

• All pointers in the SSDT should point to code within ntoskrnl, if any pointer is pointing outside of ntoskrnl it is likely hooked

.


SSDT hooking


SYSENTERUser-mode

Kernel-modeKiSystemService()

SSDT ntoskrnl.exeServiceTable

Native SSDT

CounterTableServiceLimitArgumentsTable

WinFunction()

Native functions table

WinFunction()RootkitFunction()WinFunction()

User-mode Program

.


Practical Case


1. Short analysis of IAT and code in IDA

2. Use malware analysis tools

3. Run the sample and monitor

4. Find the driver

5. Check the SSDT

6. Identify the hooked function

7. Analyze the hooked function

.


Overview

0111 – Conclusion

0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


What I learned here?

0111 – Conclusion

• Difference between Userland and Kerneland

• Basic concept of Kernel Windows

• Basic concept of Driver Windows

• How to use Windbg

• How to setup kernel debugging with Fusion

• How works a Rootkit (SSDT hooking style) and how to analyse

.


Overview

1000 – Reference

0000 – $whoami




0100 – Drivers



0111 – Conclusion

1000 – References

.


1000 – Reference

• https://msdn.microsoft.com

• http://undocumented.ntinternals.net

• https://technet.microsoft.com/fr-fr/sysinternals/bb545021.aspx

• Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation

• Windows Internals, Part 1 & 2

• Practical Malware Analysis

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff558823(v=vs.85).aspx

• Hacking Exposed: Malware & Rootkits Secrets & Solutions

.


[email protected] you!

.

McAfee Confidential

windows kernel debugging

Technology