driver-vuln-research: Kernel Driver Vulns & BYOVD Arsenal

// created 2026-07-14

driver-vuln-research is my notes-and-tools pack for BYOVD (Bring Your Own Vulnerable Driver) work: legitimate, still-signed drivers whose IOCTLs expose physical memory, MSR, or PortIO. It holds a capability matrix, reproducible chains, and a Rust extractor pipeline. Purpose is explicit: independent security research and education, not a ready-made pack for abusing live systems.

Why it exists

On modern Windows, usermode cannot simply touch physical memory. BYOVD loads (or reuses already-running) known-vulnerable signed drivers and uses their vendor “debug doors” to read physical pages, patch EPROCESS, clear PPL, then scan keys or escalate from usermode. The surface is large, docs are scattered, and offsets/CVE IDs drift — so I pulled what I could reproduce into one arsenal.

Binaries in the repo are public, signed images (SIVX64, AsIO3, ASTRA64, LnvMSRIO, ArgusMonitor, ThrottleStop-related paths, etc.) with SHA256 checks. There is no custom rootkit.sys.

Capability tiers (short)

Tiers follow what a driver can actually do:

Tier 0: full phys R/W + MSR, preferred after live validation. LnvMSRIO (phys + MSR; EAC-observed samples) and CorsairLLAccess64 (WHQL; load path exists with HVCI/memory integrity on) sit here.
Tier 1: full physical windows — Portwell (many IOCTLs), SIVX64 (modes), IOMap64 (sliding window), Dell WDT-related, etc.
Tier 2: specialized — SparkIO mostly read-only; AsIO3 often already loaded at boot on ASUS boxes, enabling zero-extra-load paths via public CVEs; MSI WinIo-style large maps live here too.

The matrix also marks WHQL / HVCI / EAC as measured or untested. See CAPABILITY_MATRIX.md in the repo for the full table.

Main research chains

Chain A — stealth extraction (primary)
Load LnvMSRIO → walk KPCR to EPROCESS → single-byte PPL clear → usermode ReadProcessMemory + AES key-schedule validation over the heap. IOCTL counts and timings are logged per stage (load ~0.5s, locate ~0.3s, PPL near-instant, heap scan ~2–5s).

Chain B — HVCI-hardened hosts
CorsairLLAccess64: MSR → KPCR, physical read of the EPROCESS chain, physical write for token-related ops — aimed at SYSTEM semantics with memory integrity still on (see current verification notes in-repo).

Chain C — zero extra load
If AsIO3/Asusgio is already running, stack public CVE chains (TOCTOU-class issues and later permission/allowlist bugs documented in the tree). Smaller footprint, more sensitive to SKU and patch level.

BSoD risk is called out: correct offsets ≈ zero; wrong offsets or MMIO holes are FATAL. Physical ranges are validated before read/write.

Extractor (Rust)

extractor/ is ~3k LOC with zero external crates: SCM service lifecycle, PhysicalMemoryDriver trait, LnvMSRIO backend, EPROCESS walk + PPL bypass, AES-128 expand/validate, heap page scanner. Examples cover Superfetch checks, offset verification, and full AES scans.

cd extractor && cargo build --release
cargo run --example test_offsets   # admin; safe-ish verification
cargo test                         # 10/10 at last check

Verify offsets before any full chain. Do not physical-write against the wrong kernel build.

Docs and boundaries

The repo has the capability matrix, ops manuals, WHQL+HVCI candidate lists, E2E pipeline design, adversarial review notes, and more. This post is orientation only. For live reproduction, trust the GitHub docs and your host’s patch state.

Again: this studies known-vulnerable, legitimately signed drivers. Unauthorized damage, cheats, or theft is outside the project’s intent — on you if you go there.