Arc 1: Learning the System

"Under the Hood" — Windows Kernel & Boot Process

Marcus Chen is complaining about his slow workstation. Time to look under the hood and understand what makes Windows tick — from the kernel up.

The NT Hybrid Kernel Architecture

Windows is built on the NT kernel, designed by Dave Cutler starting in 1988. It is called a hybrid kernel because it combines aspects of both monolithic kernels (where most OS services run in kernel mode for speed) and microkernels (where services run in user mode for stability). The result is a layered architecture where each layer depends on the one below it:


                ↑ User Applications (Ring 3) ↑

                ─────────────────────────────────────

                Environment Subsystems (Win32, POSIX)

                ─────────────────────────────────────

                Executive Services (Ring 0)

                ─────────────────────────────────────

                Kernel (ntoskrnl.exe)

                ─────────────────────────────────────

                HAL (hal.dll)

                ─────────────────────────────────────

                ↓ Hardware (CPU, RAM, Disk, NIC) ↓

The Hardware Abstraction Layer (HAL) sits at the very bottom. It translates generic kernel requests into hardware-specific instructions. This is why the same copy of Windows can run on wildly different motherboards and chipsets — the HAL handles the differences so the kernel does not have to.

Above the HAL sits the Kernel itself (ntoskrnl.exe), responsible for thread scheduling, interrupt dispatching, and multiprocessor synchronization. It is the most privileged code on the machine.

Above the kernel sit the Executive Services — the major subsystems that do the real management work. Above those sit the Environment Subsystems (Win32, formerly POSIX) that provide the API surface that applications use.

Ring 0 vs Ring 3: The Security Boundary

The CPU itself enforces a privilege boundary between kernel mode (Ring 0) and user mode (Ring 3). This is not a Windows invention — it is built into the x86/x64 processor architecture.

Ring 0 — Kernel Mode:

Full access to all hardware and memory
Can execute any CPU instruction, including privileged ones
A crash here takes down the entire system (BSOD)
Runs: ntoskrnl.exe, hal.dll, device drivers, file system drivers

Ring 3 — User Mode:

Restricted access — cannot touch hardware directly
Each process gets its own isolated virtual address space
A crash here only kills that one process
Runs: applications, services, environment subsystems (csrss.exe)

The bridge between Ring 3 and Ring 0 is the system call (syscall). When a user-mode application needs to read a file, it calls the Win32 API function ReadFile(), which calls into ntdll.dll, which executes a syscall instruction. This instruction triggers a CPU mode switch from Ring 3 to Ring 0, where the kernel takes over, performs the operation, and returns the result.

Why This Matters for Security: Anything running in Ring 0 has unrestricted power. A malicious driver loaded into kernel mode can hide processes, intercept network traffic, disable antivirus, and render itself invisible to user-mode tools. This is why driver signing and Secure Boot exist — to prevent unauthorized code from entering Ring 0.

Executive Services: The Brain of Windows

The Executive is a collection of kernel-mode components that provide core OS functionality. Each one is responsible for a specific domain. Together they form the management layer of Windows.

Component	Responsibility	Key Detail
I/O Manager	Handles all input/output requests — disk reads, network sends, printer output, USB communication. Everything goes through IRP (I/O Request Packets).	Uses a layered driver model: I/O requests pass through a stack of drivers (filter drivers, function drivers, bus drivers) before reaching hardware.
Object Manager	Manages all kernel objects — processes, threads, files, registry keys, mutexes, events. Every resource in the kernel is an "object" with a handle.	Objects live in a hierarchical namespace (visible with tools like WinObj). Handles are how user-mode code references kernel objects.
Memory Manager	Manages virtual memory, paging, working sets, and shared memory. Gives each process the illusion of a private 4 GB (32-bit) or 128 TB (64-bit) address space.	Uses demand paging: pages are loaded from disk only when accessed. The working set is the subset of pages currently in physical RAM.
Security Reference Monitor (SRM)	Checks every access request against the object's ACL (Access Control List). Determines if a process has the right to open a file, registry key, or any other object.	Runs in kernel mode so it cannot be bypassed by user-mode code. Compares the caller's access token (SIDs + privileges) against the object's DACL.
Process Manager	Creates and destroys processes and threads. Manages PIDs, handles process/thread termination, and works with the scheduler to assign CPU time to threads.	Each process has at least one thread. Scheduling is done at the thread level, not the process level. Priority ranges from 0 (idle) to 31 (real-time).
Configuration Manager	Manages the Windows Registry — the hierarchical database that stores system configuration, user preferences, software settings, and hardware info.	The Registry is stored in files called "hives" (SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT). The Configuration Manager loads them at boot and keeps them in memory.

Key Insight: When you right-click a file and choose "Properties → Security", you are looking at the object's DACL that the Security Reference Monitor checks on every access. Understanding this flow — from user request to Win32 API to syscall to SRM — is the foundation of Windows security.

The Windows Boot Process

When you press the power button, a precise sequence of events brings Windows from cold hardware to a functioning desktop. Every step is a potential attack surface, which is why Secure Boot exists to verify each component before it runs.

Boot Sequence (UEFI systems):

UEFI Firmware → POST — CPU initializes, firmware performs Power-On Self Test. Checks RAM, storage, and peripherals. Reads boot configuration from NVRAM.
bootmgr (bootmgfw.efi) — UEFI loads the Windows Boot Manager from the EFI System Partition. It reads the BCD (Boot Configuration Data) store to determine which OS to load.
winload.efi — The Windows Loader loads the kernel (ntoskrnl.exe), the HAL (hal.dll), and boot-start drivers into memory. Verifies digital signatures on each file.
ntoskrnl.exe — The kernel initializes: Memory Manager, Object Manager, Security Reference Monitor, Process Manager, I/O Manager. Creates the System process (PID 4).
smss.exe — The Session Manager is the first user-mode process. It creates Session 0 (services) and Session 1 (user), starts csrss.exe, sets up the page file, and processes the registry's BootExecute entries.
csrss.exe — The Client/Server Runtime Subsystem manages console windows, thread creation/deletion, and is critical to the Windows subsystem. It runs in every session.
winlogon.exe — Handles the logon process. Presents the Ctrl+Alt+Del screen, loads credential providers, authenticates users (via LSASS), and loads user profiles.
explorer.exe — The Windows Shell. Once a user is authenticated, winlogon starts explorer.exe, which provides the desktop, taskbar, and Start menu. The system is ready.

Secure Boot & ELAM

Secure Boot is a UEFI firmware feature that ensures only digitally signed, trusted code can run during the boot process. Each component in the boot chain is verified before it is allowed to execute:

UEFI firmware verifies the bootloader (bootmgfw.efi) using Microsoft's certificate stored in firmware
The bootloader verifies winload.efi
winload.efi verifies ntoskrnl.exe, hal.dll, and all boot-start drivers

If any signature check fails, the boot process halts. This prevents bootkits — malware that infects the boot process to load before the OS and hide from antivirus.

ELAM (Early Launch Anti-Malware) is a mechanism that allows antivirus drivers to load before any third-party drivers. Windows Defender's ELAM driver (WdBoot.sys) loads first and classifies each subsequent boot-start driver as:

Known Good — signed and recognized, allowed to load
Known Bad — known malware, blocked from loading
Unknown — not recognized, policy determines if it loads
Known Bad but Critical — needed for boot but flagged for investigation

BYOVD Attacks (Bring Your Own Vulnerable Driver): Attackers sometimes load a legitimately signed but vulnerable driver, then exploit the vulnerability to gain kernel access. Because the driver has a valid signature, Secure Boot allows it. This is why keeping driver blocklists updated matters — Microsoft maintains a Vulnerable Driver Blocklist for this purpose.

Blue Screen of Death (BSOD)

A BSOD (Blue Screen of Death) occurs when the kernel encounters an error so severe that it cannot safely continue. Because Ring 0 code has full access to the system, a crash here risks data corruption, so Windows halts everything and displays a bug check screen.

Common bug check codes:

Bug Check Code	Name	Common Cause
`0x0000000A`	IRQL_NOT_LESS_OR_EQUAL	A driver accessed memory at a wrong IRQL (Interrupt Request Level). Often caused by faulty or incompatible drivers.
`0x0000007E`	SYSTEM_THREAD_EXCEPTION_NOT_HANDLED	A system thread generated an exception that the error handler did not catch. Typically a driver bug.
`0x00000050`	PAGE_FAULT_IN_NONPAGED_AREA	A kernel component tried to access invalid memory. Could be bad RAM, a corrupt driver, or disk corruption.
`0x000000D1`	DRIVER_IRQL_NOT_LESS_OR_EQUAL	Specifically identifies a driver that accessed paged memory at an elevated IRQL.
`0x0000007B`	INACCESSIBLE_BOOT_DEVICE	Windows cannot read the boot drive. Failed storage driver, corrupt BCD, or hardware failure.

When a BSOD occurs, Windows writes a memory dump to C:\Windows\MEMORY.DMP (full dump) or C:\Windows\Minidump\ (small dump). These can be analyzed with tools like WinDbg to pinpoint the exact driver and code line that caused the crash.

NT Kernel Architecture Diagram

Click any layer to explore what lives there, what it does, and why it matters for security.

🔄 Boot Sequence Flowchart

The chain of trust from power button to desktop. Each step verifies the next before handing off control.

UEFI Firmware

POST + hardware init

↓ Reads EFI System Partition

bootmgr (bootmgfw.efi)

Windows Boot Manager

↓ Reads BCD store

winload.efi

Windows Loader

↓ Loads kernel + HAL + boot drivers

ntoskrnl.exe

Kernel Initialization

↓ Creates System process (PID 4)

smss.exe

Session Manager

↓ Creates Session 0 + Session 1

csrss.exe

Client/Server Runtime

winlogon.exe

Logon Handler

↓ Authenticates user via LSASS

explorer.exe

Desktop Shell — You see the desktop!

X-Ray Mode: BSOD — When a Bad Driver Crashes the Kernel

Watch step by step what happens inside the kernel when a faulty driver causes a Blue Screen of Death. The diagram highlights which component is active while the terminal shows the system's perspective.

Press Play to begin X-Ray walkthrough...

Investigation Lab: Marcus Chen's Slow Workstation

Scenario: Marcus Chen, Senior Engineer, has submitted a ticket complaining that his workstation (MD-WS-ENG05) has been running slowly for the past week. Boot times are long and applications hang. Priya asks you to investigate the boot configuration, drivers, and startup items. "Look under the hood," she says. "Something is not right on that machine."

Run bcdedit to examine the boot configuration. Look for anything unusual in the boot settings.

Hint: Pay close attention to the testsigning and safeboot settings

Run driverquery /v to list all loaded drivers. Look for any unsigned or suspicious drivers.

Hint: Check the "State" and "Status" columns, and look for drivers that are not signed by Microsoft

Run msconfig to check what opens at startup. Anything unusual?

Run tasklist /svc to see which services are running in each process. Cross-reference with the drivers you found.

Run systeminfo | findstr Boot to check the last boot time. Is it recent?

Run wmic startup list brief to examine startup entries. Look for anything that should not be starting automatically.

Hint: Legitimate startup items usually run from C:\Program Files or C:\Windows. Items in unusual paths are suspicious.