windows-kernel-security git:20260909.90b22a8A

Immutable. This exact content is served forever at /api/v1/blob/c54f2422e281f9d4.

---
name: windows-kernel-security
description: Analyze Windows driver trust boundaries and kernel evidence for game-security research. Use for IOCTL authorization, callbacks and IRQL, driver provenance, DSE/PatchGuard, VBS/HVCI, build-specific internals, and crash or memory forensics; select repository resources for symbol comparison, ETW metadata, driver-unit coverage and offline dumps. Distinguish documented contracts, observed host state and inferred internals; report privilege prerequisites, mitigation scope, missing coverage and benign alternatives.
---

# 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`](../research-rigor/SKILL.md) before
generalizing a PoC or forensic heuristic.

## Driver Attack Surface and Evidence

For event provenance, provider/callback scope and absent telemetry, use
[observation coverage](../anti-cheat/references/input-provenance-and-measurement.md).

| Threat class | Necessary capability or boundary | Evidence and defensive focus |
|---|---|---|
| Dangerous privileged interface | A caller can reach sensitive driver operations | Device ACLs, per-operation authorization, constrained functionality |
| Vulnerable signed-driver abuse | An affected driver is loaded or loadable and its interface reachable | Exact hash/version, provenance, loaded inventory, applicable policy |
| Driver-mediated acquisition | A host kernel acquisition component and usable interface | Driver/service identity, acquisition process, interface access, timeline |
| Kernel code/data tampering | Ability to modify the affected protected state | Trusted comparison evidence, ownership, protection and integrity events |

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](https://learn.microsoft.com/en-us/windows-hardware/drivers/driversecurity/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](https://learn.microsoft.com/en-us/windows-hardware/drivers/driversecurity/implement-hvci-compatible-code)

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](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-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](https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/driver-verifier)

For acquisition relayed over USB or a network, use the
[source/transport distinction](../dma-attack/references/acquisition-and-transport.md).
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
```cpp
PsSetCreateProcessNotifyRoutine
PsSetCreateProcessNotifyRoutineEx
PsSetCreateProcessNotifyRoutineEx2
```

### Thread Callbacks
```cpp
PsSetCreateThreadNotifyRoutine
PsSetCreateThreadNotifyRoutineEx
```

### Image Load Callbacks
```cpp
PsSetLoadImageNotifyRoutine
PsSetLoadImageNotifyRoutineEx
```

### Object Callbacks
```cpp
ObRegisterCallbacks
// OB_OPERATION_HANDLE_CREATE
// OB_OPERATION_HANDLE_DUPLICATE
```

### APC / Execution Context
```cpp
KeInitializeApc
KeInsertQueueApc
KeStackAttachProcess
RtlWalkFrameChain
```

### Registry Callbacks
```cpp
CmRegisterCallback
CmRegisterCallbackEx
```

### Minifilter Callbacks
```cpp
FltRegisterFilter
// IRP_MJ_CREATE, IRP_MJ_READ, etc.
```

## Driver Development

### Basic Structure
```cpp
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](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/public-and-private-symbols)

### 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](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exallocatepool2),
[ExAllocatePool3](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-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](https://www.microsoft.com/en-us/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/)

## 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](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-poolmon-to-find-a-kernel-mode-memory-leak)

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
```cpp
MmMapIoSpace
MmCopyMemory
\\Device\\PhysicalMemory
```

### Virtual Memory
```cpp
ZwReadVirtualMemory
ZwWriteVirtualMemory
KeStackAttachProcess
MmCopyVirtualMemory
```

### MDL Operations
```cpp
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](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html)

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](../dma-attack/SKILL.md). 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](https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/hypervisor-platform)

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](https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/funcs/whvrunvirtualprocessor),
[exit contexts](https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/funcs/whvexitcontextdatatypes),
[capabilities](https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/funcs/whvgetcapability).

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](https://www.microsoft.com/en-us/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/)

### Conditions for a Supported Protection Claim

| Review question | Evidence required |
|---|---|
| What is covered? | Exact protected memory, active mappings, access class and lifecycle; names such as callback list or ETW structure are not enough |
| Who owns the policy? | Hypervisor/security-component provenance and the authority allowed to change mappings or configuration |
| Was an access observed? | Available fault/exit context, collection coverage and correlation with the relevant mapping and execution context |
| Was the operation prevented? | Enforced decision and resulting state; a reported exit alone does not establish denial or continuing integrity |
| What remains outside scope? | Unprotected aliases or state, permitted update paths, device DMA, firmware and independent event or service failures |

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](references/repository-resources.md) on demand. Use the shared [repository navigation](../overview/references/repository-navigation.md) 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](../../../wiki/overviews/windows-kernel.md). 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](../../../wiki/index.md) for topical synthesis and
cross-project connections. [Wiki schema](../../../wiki/AGENTS.md) describes its
structure. Generated wiki pages are discovery aids; follow their original
citations before adopting technical claims.

Raw catalog: [wiki/index.md](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/index.md).
For this domain, read [wiki/overviews/windows-kernel.md](../../../wiki/overviews/windows-kernel.md).
Raw URL: [windows-kernel overview](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/overviews/windows-kernel.md).

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](../../../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](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/README.md).

### 2. Repository Descriptions

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

```text
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](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/bkaradzic/bgfx/description_en.txt).
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:

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

Example: [bgfx archive](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/bkaradzic/bgfx.txt).
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](../overview/references/repository-navigation.md) adds the optional read-only indexer,
case-ambiguity handling and maintenance details; it supplements this Data Source
section rather than replacing it.