Windows Kernel Security

Windows Kernel Security

Overview

This skill covers Windows kernel internals that matter for game security research: object callbacks, process and image notifications, APC behavior, driver loading, trust enforcement, memory manager structures, and the bookkeeping anti-cheats inspect to detect hostile drivers or hidden executable code.

Treat undocumented structures, offsets, globals, and allocator internals as build-specific. Verify them against symbols and runtime observations for the exact Windows build; use research-rigor before generalizing a PoC or forensic heuristic.

Driver Attack Surface and Evidence

For event provenance, provider/callback scope and absent telemetry, use observation coverage.

Review buffer lengths, output initialization, object lifetime, cancellation, and IRQL alongside caller authorization. Signed code can still expose unsafe operations. The table is a threat-model synthesis; actual reachability requires evidence for the specific build and configuration. Microsoft driver security checklist

Distinguish VBS/HVCI capability, configuration, and running state. Memory integrity imposes executable-memory constraints; compatibility does not prove every driver interface or data operation safe. Memory integrity compatibility

Driver blocklists have incomplete coverage. Distinguish controls that prevent writing a vulnerable driver to disk from policies that block loading it, and record the active policy/version rather than assuming protection from the OS name. Microsoft driver block rules

Use Driver Verifier on a recovery-capable test system when evaluating owned drivers; preserve tested configuration and crash artifacts. It can deliberately bugcheck a system and does not establish a low false-positive anti-abuse detector. Driver Verifier

For acquisition relayed over USB or a network, use the source/transport distinction. Legitimate incident response can produce the same acquisition artifacts. Sources in this section were reviewed on 2026-09-09.

README Coverage

• Cheat > PatchGuard-related
• Cheat > Driver Signature enforcement
• Cheat > Windows Kernel Explorer
• Cheat > EFI Driver (cross-reference with game-hacking skill)
• Cheat > Vulnerable Driver
• Anti Cheat > Detection:Attach
• Anti Cheat > Detection:Hide
• Anti Cheat > Detection:Vulnerable Driver
• Anti Cheat > Detection:Spoof Stack
• Anti Cheat > Windows Ring3 Callback
• Anti Cheat > Windows Ring0 Callback
• Anti Cheat > Information System & Forensics
• Some Tricks > Windows Ring0
• Windows Security Features

Core Kernel Concepts

Important Structures

• EPROCESS / ETHREAD
• KTHREAD / KAPC / KAPC_STATE
• MMVAD / VAD tree nodes
• PEB / TEB
• DRIVER_OBJECT
• DEVICE_OBJECT
• IRP (I/O Request Packet)

Key Tables

• SSDT (System Service Descriptor Table)
• IDT (Interrupt Descriptor Table)
• GDT (Global Descriptor Table)
• PspCidTable (Process/Thread handle table)
• PiDDBCacheTable / MmUnloadedDrivers / PoolBigPageTable

User-Mode Kernel Symbol Walking

Methodology

- Load local ntoskrnl image (typically C:\Windows\System32\ntoskrnl.exe)
- Use dbghelp + symbol server path (srv*cache*https://msdl.microsoft.com/download/symbols)
  to resolve exported symbol RVAs and type information
- Build structure-aware field lookup:
  - Query field offset directly (e.g., _EPROCESS.Token)
  - Enumerate all members of a target struct (_TOKEN, _EPROCESS, etc.)
  - Search a field name across all known structs (useful when parent type is unknown)
- Keep symbol path configurable for offline/private symbol repositories

Why It Matters in Game Security

- Reduces hardcoded-offset fragility across Windows builds
- Helps map kernel object layouts used by anti-cheat and drivers
- Supports rapid adaptation when anti-cheat-relevant fields shift
  (EPROCESS, ETHREAD, token/handle/security-related members)

Gadget Scanning Workflow

- Map executable sections of ntoskrnl image in user mode
- Scan for short control-flow gadgets (e.g., pop rcx ; ret, jmp rax)
- Use as a research primitive for:
  - ROP chain feasibility analysis
  - Kernel exploit mitigation evaluation
  - Anti-cheat hardening review against gadget-dependent attack paths

Security Features

PatchGuard (Kernel Patch Protection)

- Protects critical kernel structures
- Periodic verification checks
- BSOD on tampering detection
- Multiple trigger mechanisms

Driver Signature Enforcement (DSE)

- Requires signed drivers
- CI.dll verification
- Test signing mode
- WHQL certification

Virtualization-Based Security (VBS)

Architecture:
- Uses the Windows hypervisor to create an isolated execution environment
- Splits the system into Virtual Trust Levels (VTLs)
  - VTL0: Normal world — standard Windows kernel and user-mode processes
  - VTL1: Secure world — Secure Kernel, security policy enforcement
- VTL1 is designed to remain isolated from a compromised VTL0, assuming the
  hypervisor, secure kernel, hardware, and configuration path remain trustworthy
- Three main buckets:
  - Memory-protection features (HVCI)
  - Virtual Trust Levels (VTL0/VTL1 separation)
  - VBS enclaves (isolated execution for selected workloads)

Hypervisor-Enforced Code Integrity (HVCI)

- Also known as Memory Integrity
- Ensures only trusted, validated code executes in kernel mode
- Combines Windows hypervisor + Secure Kernel (VTL1) for enforcement
- Key mechanism: W→X transition restriction
  - Enforced code pages are not intended to be writable from VTL0
  - Executability is granted only after the configured code-integrity checks
- Enforcement pipeline:
  - Code integrity policy defines what is trusted
  - Hypervisor memory enforcement via second-stage address translation (EPT/SLAT)
  - Once a kernel page is validated, strict execution rules are enforced
- Driver compatibility requirements: drivers must be HVCI-compatible

Secure Boot

- UEFI-based boot verification
- Boot loader chain validation
- Kernel signature checks
- DBX (forbidden signatures)
- Foundation for attestation and DMA-hardening assumptions

Kernel Callbacks

Process Callbacks

PsSetCreateProcessNotifyRoutine
PsSetCreateProcessNotifyRoutineEx
PsSetCreateProcessNotifyRoutineEx2

Thread Callbacks

PsSetCreateThreadNotifyRoutine
PsSetCreateThreadNotifyRoutineEx

Image Load Callbacks

PsSetLoadImageNotifyRoutine
PsSetLoadImageNotifyRoutineEx

Object Callbacks

ObRegisterCallbacks
// OB_OPERATION_HANDLE_CREATE
// OB_OPERATION_HANDLE_DUPLICATE

APC / Execution Context

KeInitializeApc
KeInsertQueueApc
KeStackAttachProcess
RtlWalkFrameChain

Registry Callbacks

CmRegisterCallback
CmRegisterCallbackEx

Minifilter Callbacks

FltRegisterFilter
// IRP_MJ_CREATE, IRP_MJ_READ, etc.

Driver Development

Basic Structure

NTSTATUS DriverEntry(
    PDRIVER_OBJECT DriverObject,
    PUNICODE_STRING RegistryPath
) {
    DriverObject->DriverUnload = DriverUnload;
    DriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchCreate;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchIoctl;
    // Create device, symbolic link...
    return STATUS_SUCCESS;
}

Communication Methods

• IOCTL (DeviceIoControl)
• Direct I/O
• Buffered I/O
• Shared memory

Vulnerable Driver Exploitation

Common Vulnerability Types

• Arbitrary read/write primitives
• IOCTL handler vulnerabilities
• Pool overflow
• Use-after-free

Notable Vulnerable Drivers

- gdrv.sys (Gigabyte)
- iqvw64e.sys (Intel)
- MsIo64.sys
- Mhyprot2.sys (Genshin Impact)
- dbutil_2_3.sys (Dell)
- RTCore64.sys (MSI)
- Capcom.sys

Exploitation Steps

1. Load vulnerable signed driver
2. Trigger vulnerability
3. Achieve kernel read/write
4. Disable DSE or load unsigned driver
5. Execute arbitrary kernel code

PatchGuard Bypass Techniques

Timing-Based

• Predict PG timer
• Modify between checks

Context Manipulation

• Exception handling
• DPC manipulation
• Thread context tampering

Hypervisor-Based

• EPT manipulation
• Memory virtualization
• Intercept PG checks

Kernel Hooking

ETW (Event Tracing for Windows)

- InfinityHook technique
- HalPrivateDispatchTable
- System call tracing

ETW Internals

Provider / Consumer Model

Architecture:
- Providers: kernel or user-mode components that emit events
  - Manifest-based providers (registered via wevtutil)
  - TraceLogging providers (self-describing, no manifest)
  - MOF providers (legacy WMI-based)
- Consumers: tools that subscribe to and process events
  - Real-time consumers (ETW sessions)
  - Log file consumers (.etl files)
- Controllers: manage sessions (xperf, tracelog, logman)

Key kernel providers:
  Microsoft-Windows-Kernel-Process (process/thread lifecycle)
  Microsoft-Windows-Kernel-File (file I/O)
  Microsoft-Windows-Kernel-Audit-API-Calls (security-sensitive APIs)

ThreatIntel ETW Provider

- Microsoft-Windows-Threat-Intelligence
- Available to PPL (Protected Process Light) and above
- Events: NtReadVirtualMemory, NtWriteVirtualMemory, NtMapViewOfSection on protected processes
- Used by EDR and anti-cheat for detecting memory access to protected processes
- Attackers target: patch EtwThreatIntProvRegHandle or EtwpEventWriteFull

Common ETW Bypass Patterns

- Patch EtwEventWrite in ntdll.dll (user-mode ETW silencing)
- Patch nt!EtwpEventWriteFull in kernel (kernel-mode ETW silencing)
- A debugger-related thread setting does not establish ETW invisibility;
  undocumented cross-subsystem effects need build/provider-specific evidence
- Remove provider registration by walking EtwRegistration list
- EPT-based protection can defend ETW structures from tampering

Kernel Pool Architecture and Allocation Contracts

Treat allocator internals as hypotheses tied to an exact kernel binary, architecture, configuration and matching symbols. Internal structure offsets, size thresholds, encoded headers, cache depths and allocation-routing diagrams are not a stable Windows driver interface. A symbol name without sufficient type information does not establish a layout; public and private symbol content differ. Microsoft symbol scope

Architecture Questions for a Review

Separate the public allocation request from its observed allocator path. Record pool flags, requested size, lifetime, calling/access IRQL and any special-pool or verifier configuration. If a dump or source study identifies size-class, variable-size, segment-backed or large-allocation paths, report only the path supported for that artifact. Do not infer the introduction date or every later layout from the availability of a public API.

For corruption analysis, preserve the useful threat classes: out-of-bounds access, use after free, double free, uninitialized disclosure and metadata damage. Each requires evidence of the faulty access or lifetime boundary. A crash, unusual allocation pattern or integrity-check failure alone does not establish deliberate exploitation, a specific corruption mechanism or successful privilege escalation. Do not turn historical metadata-decoding formulas into a current parser contract.

Public Pool API Boundaries

• ExAllocatePool2 and ExAllocatePool3 document Windows 10 version 2004 as their minimum supported client. The latter adds extended parameters; match the particular parameter contract to the target WDK and OS.
• Pool2 zero-initializes by default unless POOL_FLAG_UNINITIALIZED is used. Allocation initialization does not cover later buffer reuse or incomplete construction of a larger object. Review information disclosure and output initialization before removing explicit clearing.
• Review failure handling, quota semantics and pool/access IRQL together. At DISPATCH_LEVEL, Pool2 requires nonpaged allocation; memory accessed there must remain nonpaged even if it was allocated at a lower IRQL.
• Earlier Windows targets require the documented down-level allocation APIs and their initialization requirements. Do not assume Pool2 automatically falls back to allocation plus clearing on an older kernel.

ExAllocatePool2, ExAllocatePool3.

KDP and Protected Data

Microsoft's 2020 KDP architecture article describes static data protection and dynamic secure-pool allocations using VBS/SLAT. It is historical implementation context, not evidence that a present machine protects every pool allocation or that an arbitrary Pool3 allocation is secure. Establish the applicable API, successful protection state, exact region and lifecycle, and the trustworthiness of the hypervisor and policy path. Content protection does not by itself prove that every reference to that content, caller or update operation is authorized. Microsoft KDP architecture

Pool Allocation & Forensics

Attribution and Coverage

Pool tags are caller-supplied labels used by debugging and tracking tools; PoolMon groups memory use by tag. They are leads for attribution, not cryptographic driver identities. A rare tag, a shared tag or a lookup in pooltag.txt cannot by itself establish which signed binary allocated a buffer, that a hidden driver is present, or that the allocation is malicious. PoolMon scope

If a report invokes PiDDBCacheTable, MmUnloadedDrivers, PoolBigPageTable or similar internal names, require an exact-build definition, collection method, retention/coverage limits and supporting artifacts. Do not assume a universal field layout, complete driver history or a one-to-one relationship between a pool allocation and a driver object. Missing or malformed data can reflect image incompleteness, stale symbols, reuse, collection effects or corruption.

Review Evidence

For an existing authorized image, record its provenance/hash, acquisition time, OS/architecture, symbol identity, parser version and unavailable regions. Keep allocation facts, ownership hypotheses and security conclusions separate. Correlate available allocation stacks, loaded-module provenance, driver/service records and independent telemetry. Explain benign alternatives before assigning intent to executable memory, unrecognized tags or unusual allocation counts.

A negative scan describes the selected parser, metadata path and retained snapshot; it is not proof that all allocations or prior driver activity were observed. A bugcheck code is a starting point for its parameters, stack and surrounding state, not a unique allocator-path or attack signature.

Sources for these pool-contract and evidence corrections reviewed: 2026-09-09.

SSDT Hooking (Legacy)

- Modify service table entries
- Requires PG bypass
- High detection risk

IRP Hooking

- Hook driver dispatch routines
- Less monitored than SSDT
- Per-driver targeting

Memory Manipulation

Physical Memory Access

MmMapIoSpace
MmCopyMemory
\\Device\\PhysicalMemory

Virtual Memory

ZwReadVirtualMemory
ZwWriteVirtualMemory
KeStackAttachProcess
MmCopyVirtualMemory

MDL Operations

IoAllocateMdl
MmProbeAndLockPages
MmMapLockedPagesSpecifyCache

Research Tools

Analysis

• WinDbg / WinDbg Preview
• Process Hacker / System Informer
• OpenArk
• WinArk

Utilities

• KDU (Kernel Driver Utility)
• OSR Driver Loader
• DriverView

Monitoring

• Process Monitor
• API Monitor
• ETW consumers

EFI/Boot-Time Threats

EFI Driver Cross-Reference

The README's > EFI Driver subcategory (under Cheat) contains 30+ projects:
- EFI bootkit frameworks: UEFI DXE drivers that persist across boots
- Boot-time memory mappers: inject code before Windows kernel initializes
- ExitBootServices hooks: intercept Windows boot handoff
- EFI runtime service abuse: GetVariable/SetVariable for kernel ↔ EFI comm

See also: game-hacking skill for EFI cheat workflows

Boot-Time Access

- EFI runtime services persist after ExitBootServices
- DXE (Driver Execution Environment) phase: full hardware access
- Pre-kernel execution: no DSE, no PatchGuard, no HVCI enforcement
- Secure Boot is the primary mitigation (firmware signature verification)

Memory Access

- GetVariable/SetVariable: pass data between EFI and OS runtime
- Runtime memory mapping via EFI memory map
- Physical memory access before Windows memory manager initializes
- ACPI table injection for persistent low-level modifications

Hypervisor Development

Hypervisor Types

Type 1 (bare-metal):
- Runs directly on hardware
- Examples: VMware ESXi, Microsoft Hyper-V, Xen
- Used for VBS, production security enforcement

Type 2 (hosted):
- Runs on top of a host operating system
- Examples: Oracle VirtualBox, VMware Workstation
- Common for research, development, and testing

Hardware Virtualization Platforms

Intel VT-x:
- Introduced 2005, widely supported on modern Intel CPUs
- Foundation for VMCS, EPT, VM exits

AMD-V (SVM):
- AMD's counterpart to VT-x, also introduced 2005
- VMCB structure, NPT (Nested Page Tables)

ARM Virtualization Extensions:
- EL2 (hypervisor mode) and stage-2 memory translation
- Used on ARM platforms for mobile and embedded security

Intel VT-x Core Concepts

VMCS (Virtual Machine Control Structure)

Central data structure for Intel VT-x:
- Describes guest state, host state, and virtualization controls
- Tells the processor:
  - What state to restore on VM entry
  - What state to save on VM exit
  - Which events transfer control back to the hypervisor

Guest/Host State Areas:
- Control registers (CR0, CR3, CR4)
- Segment registers (CS, SS, DS, ES, FS, GS)
- Debug registers (DR7 — hardware breakpoints)
- Descriptor-table registers (GDTR, IDTR)
- Key fields:
  - CR3: root of guest page tables, central to virtual memory
  - GDTR/IDTR: Global/Interrupt Descriptor Tables
  - CS/SS: code and stack segments
  - DR7: hardware breakpoint control

Control Fields:
- Pin-based controls
- Primary processor-based controls
- Secondary processor-based controls
- Events that cause VM exits:
  - CPUID interception
  - INVLPG interception
  - Control-register access
  - EPT violations
  - MSR access

EPT (Extended Page Tables)

EPT is Intel's second-stage translation for guest-physical to host-physical addresses; guest page tables separately translate guest virtual addresses. Review the processor capabilities and active virtualization controls before assuming a paging depth, page size or particular handling of a denied access. A four-level diagram describes one configuration, not every implementation. Intel system-programming manuals

Second-stage permissions constrain CPU access to the configured guest mappings. They do not themselves identify the responsible module or decide whether an operation is legitimate. Device-originated access needs its own IOMMU and device policy analysis; use DMA analysis. A guest virtual address or module name must be correlated with the observed mapping and execution context before making an attribution claim.

VM Exits & VMCALL

VM Exits:
- Occur when configured events happen in the guest
- Triggers: CPUID, CR access, I/O instructions, EPT violations, MSR access
- On exit: processor saves guest state (per VMCS), restores host state,
  records exit reason for hypervisor handler

VMCALL:
- Guest intentionally transfers control to hypervisor
- Similar in concept to a system call (guest → hypervisor)
- Used for guest-hypervisor communication interfaces

Nested Virtualization

- Running a hypervisor inside a VM managed by another hypervisor
- Useful for research, testing, and development
- Adds complexity: multiple layers participate in the same virtualization flow
- Relevant for testing hypervisor-based defense under VMware/Hyper-V

AMD-V (SVM)

• VMCB (Virtual Machine Control Block) structure
• NPT (Nested Page Tables) — AMD's SLAT equivalent
• SVM operations (VMRUN, VMSAVE, VMLOAD)

Review Use Cases

Use virtualization evidence to examine guest isolation, authorized introspection and integrity policy. Treat unauthorized concealment or tampering as threat categories with explicit access prerequisites and observation limits; the presence of virtualization is also normal for development and platform security.

Windows Hypervisor Platform (WHP) API

WHP exposes user-mode APIs to manage guest partitions, virtual processors and guest-physical mappings using the Windows hypervisor. It does not grant a tool arbitrary control over the running host kernel. Record the host/guest boundary, Windows build, architecture, SDK, feature state and actual capabilities. WHP API contract

The current WHvRunVirtualProcessor contract lists Windows 10 version 1803 for x64 and Windows 11 version 24H2 build 26100.3915 for Arm64. Its successful return and exit context describe a stop in guest execution, not complete tracing of every instruction or a deterministic replay. Capabilities and available exit contexts are architecture- and configuration-dependent; there is no generic syscall exit reason in the documented enumeration. Correlate the actual reason and context with the analysis question. Run contract, exit contexts, capabilities.

Preserve unmodeled device, scheduler, timing and concurrency effects in a result. A CPU feature name or enabled optional feature alone does not prove that a given analysis tool, nested environment or third-party hypervisor combination is supported. Use product/build-specific evidence for compatibility; do not impose a universal coexistence or conflict rule.

Hypervisor-Based Defense

Enforcement Boundary

A trusted hypervisor can enforce a separate guest-memory protection boundary. Windows VBS/KDP is one concrete architecture; other platforms' isolated execution environments require their own contracts and must not be equated with EPT hooks. Protecting selected data also differs from validating kernel code, authenticating an administrative request or preserving a detector's end-to-end coverage. Microsoft KDP architecture

Conditions for a Supported Protection Claim

For a vulnerable-driver threat, first establish the affected driver's presence, reachable interface and required privilege. A claim that attempted kernel data tampering was blocked additionally requires the protection evidence above. Do not infer that every driver-mediated write would fault or that every callback remains intact merely because a hypervisor is installed.

A CPU fault gives machine context; identifying a trustworthy principal and handling an allowed update are separate policy problems. Report detection, prevention, post-event integrity and recovery as different outcomes. Guest-kernel compromise does not automatically defeat an independently enforced boundary, but that claim assumes the hypervisor, hardware and configuration path remain trustworthy. Preserve those assumptions and any missing coverage explicitly.

Sources for these virtualization-boundary corrections reviewed: 2026-09-09.

Resource Organization

The README contains categorized links for:

• PatchGuard research and bypasses
• DSE bypass techniques
• Vulnerable driver exploits
• Kernel callback enumeration
• ETW/PMI/NMI handlers
• Intel PT integration

Repository Navigation

For project selection, load repository resource selection on demand. Use the shared repository navigation for local discovery layers, filename case, missing snapshots and currentness. Generated descriptions and wiki pages are discovery aids, not independent evidence.

For topic discovery, see the compiled windows-kernel overview. Verify its technical claims against primary sources and the actual target context.

Data Source

Use the following repository sources directly when applying this skill. Prefer available local files for discovery and scoped historical inspection; use the raw URLs when the collection is not installed locally. These entrypoint details are retained here so source lookup does not depend on loading another skill.

0. Compiled Wiki

Start with wiki/index.md for topical synthesis and cross-project connections. Wiki schema describes its structure. Generated wiki pages are discovery aids; follow their original citations before adopting technical claims.

Raw catalog: wiki/index.md. For this domain, read wiki/overviews/windows-kernel.md. Raw URL: windows-kernel overview.

A direct project question can start with its README entry or description below; reading the entire wiki is unnecessary.

1. Project Overview and Resource Index

README.md contains the collection's actual categories, subcategories, project URLs and short descriptions. Find the relevant category and retain the original URL, including any specific file or revision suffix.

Raw index: README.md.

2. Repository Descriptions

For a concise project summary, look for the actual local path:

description/{owner}/{repo}/description_en.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt

Example: bgfx description. Extract owner/repository from the original GitHub project URL, omitting a .git suffix. Resolve existing path casing before constructing a local/raw path. Descriptions are generated summaries, not independent verification. If absent or inaccessible, use the README entry, relevant archive or original project.

3. Repository Source Archives

For deeper inspection of an available captured source tree, locate:

archive/{owner}/{repo}.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt

Example: bgfx archive. Prefer inspecting the relevant portion of an existing archive over re-cloning merely to inspect the same captured material. Archives may exclude files, use fallback extraction or contain truncation; they are not guaranteed complete checkouts. Record any upstream revision evidence and included-file limits. If missing or insufficient, follow the README's original upstream URL.

Choose and Verify the Source

For a specific project, locate its README identity, use a description or wiki page for orientation when helpful, then inspect the relevant archive/source artifact for the question. For current compatibility or exact implementation, verify the matching upstream documentation, release or immutable source revision. Keep the collection revision and capture/generation dates separate from the upstream version. Multiple generated layers from one source are not independent corroboration, and missing archive content does not establish upstream absence.

The per-domain resource guide above helps choose useful artifacts. Shared repository navigation adds the optional read-only indexer, case-ambiguity handling and maintenance details; it supplements this Data Source section rather than replacing it.