Navigating the Kernel

As an exploit developer, it is important to be able to navigate the kernel to understand its structures, vulnerabilities, and develop effective exploitation techniques.

Process Context

In the Windows operating system, the kernel and each process have their own virtual address spaces. The kernel operates within a single virtual address space that is shared among all processes. This shared kernel address space allows the kernel to provide services and manage system resources on behalf of multiple processes.

On the other hand, each process has its own individual virtual address space that is unique to that process. The virtual address spaces of different processes can overlap, meaning that different processes may have memory regions with the same virtual addresses. However, these overlapping virtual addresses actually map to different physical memory locations, ensuring memory isolation and preventing one process from accessing another process's memory directly.

When you are debugging the kernel it is important to understand that you need to debug in the desired process context.

To list all of the processes currently running we can use the !process command:

0: kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
[omitted for brevity]
PROCESS fffffa8007e8fb30
    SessionId: 0  Cid: 069c    Peb: 7fffffdb000  ParentCid: 01f8
    DirBase: 1e42e4000  ObjectTable: fffff8a00255b4e0  HandleCount: 529.
    Image: SearchIndexer.exe

We can change the process context using the .process command:

0: kd> .process fffffa8007e8fb30
Implicit process is now fffffa80`07e8fb30
WARNING: .cache forcedecodeuser is not enabled

Now when we refer to memory in user space it will be in the context of this process.

This means we can debug and observe code in the kernel and user spaces in the same debugging session.

Work in progress