HVCI Explained: How Hypervisor-Protected Code Integrity Killed a Cheat Category

Sometime between the Windows 11 22H2 rollout and the Vanguard TPM 2.0 mandate for League of Legends in 2024, an entire generation of signed-third-party-driver-based cheats quietly died. The proximate cause was not a splashy anti-cheat update or a signed-driver revocation wave. It was a Hyper-V feature most gamers had never heard of, silently flipped on by Windows Setup on any machine that met the hardware bar: Hypervisor-Protected Code Integrity.

HVCI is not new. Microsoft shipped it as part of Device Guard on Windows 10 in 2015, and it has been the default posture on Secured-core PCs for years. What changed is scope. Since Windows 11 22H2, on hardware that passes the compatibility check, HVCI ships enabled out of the box under the friendlier marketing name "Memory integrity" inside the Core Isolation settings pane. That single default flip broke the exploit primitive that most public cheats had been quietly reusing for a decade: load a WHQL-signed but signed third-party driver, use its arbitrary read/write to map physical memory or hijack a kernel page, and run your own code in ring 0 without ever shipping a signed driver of your own.

What HVCI actually is

HVCI is one specific enforcement mode of Virtualization-Based Security (VBS). The mechanics are worth stating precisely because most public explanations get them wrong.

When VBS is enabled, the Windows boot process launches Hyper-V first, then boots the normal NT kernel inside a virtual trust level called VTL0. A second, more privileged virtual trust level, VTL1, hosts the Secure Kernel and a handful of trustlets: LsaIso for credential guard, and the Secure Kernel Code Integrity module (skci.dll) which enforces HVCI. The NT kernel in VTL0 cannot read, write, or even query the memory of VTL1. Hyper-V enforces that separation using Extended Page Tables (EPT on Intel, RVI on AMD) that the guest NT kernel has no ability to modify.

HVCI's job inside VTL1 is narrow and boring: every time the NT kernel wants to make a physical page executable, it has to ask the Secure Kernel to sign off. The Secure Kernel walks the code integrity policy, checks the driver's Authenticode signature against the policy's allow list, cross-references the Microsoft signed third-party driver Blocklist, and only then flips the executable bit in the EPT. If the check fails, the page stays non-executable and any attempt to jump to it fires an EPT violation that Hyper-V translates into a bugcheck.

The consequence is a hard invariant that no ring-0 exploit in the compromised guest can violate: no page of physical memory is ever both writable and executable at the same time in kernel mode. The strict W^X guarantee is what dismantles most of the signed-third-party-driver toolkit, and understanding why requires walking through what those toolkits were actually doing.

The signed-third-party-driver workflow HVCI killed

For a fuller treatment of the technique itself, see our writeup on [signed-driver abuse as an anti-cheat bypass strategy](/blog/signed-driver-abuse chain-bring-your-own-vulnerable-driver). The condensed version: a cheat loader drops a legitimately WHQL-signed driver with a known vulnerability, opens its device object, and issues an IOCTL that grants a physical memory read/write primitive. Popular donors over the years included the RTCore64.sys from MSI Afterburner (CVE-2019-16098), various Intel and AMD chipset utilities, and, more recently, obscure OEM diagnostic drivers that never made it into the Microsoft blocklist quickly enough.

Once you have arbitrary physical read/write from user mode, the classic follow-up is a physical memory aliasing trick. Something like this, in pseudocode:

// Pre-HVCI kernel exploit primitive, sketch
PHYSICAL_ADDRESS pa = ResolvePAFromVA(target_kernel_va);

// Map the same physical page as WriteBack, RWX, via the donor driver's
// MmMapIoSpace-equivalent IOCTL. This creates a second virtual alias
// that bypasses the original page's PTE protections.
void* alias = DonorIoctl_MapPhysical(pa, PAGE_SIZE, MEMORY_CACHING_WRITE_BACK);

// Write shellcode into the alias.
memcpy(alias, shellcode, shellcode_len);

// The original kernel VA still points at the same physical page,
// which is executable via its original PTE. Redirect a function
// pointer to it and win.
*(void**)hijack_target = target_kernel_va;

The trick relied on two assumptions that HVCI invalidates. First, that the kernel can freely produce a second virtual alias of a physical page with different cache and protection attributes. Second, that once you have write access to a physical page backing kernel code, the CPU will happily execute what you put there.

MiShowBadMapper and the 24H2 wall

Windows 11 24H2 shipped an additional layer that closes even the residual variants of the aliasing trick. The kernel's memory manager now includes an internal function called MiShowBadMapper (visible in public symbol PDBs) that fires when any component tries to map a WriteBack, cache-coherent alias of a physical page that already backs kernel executable code. The check triggers whether the caller came from a legitimate MmMapIoSpaceEx call or through a driver-side alias trick. Under HVCI, the Secure Kernel enforces the invariant; without HVCI, the NT kernel itself throws a bugcheck.

The combined effect on the client side of an exploit chain is that the traditional MmMapIoSpace ROP into WriteBack pages, which was still working on stripped-down Windows 10 LTSC 2019 boxes as late as 2023, dies immediately on a stock Windows 11 24H2 install with HVCI on. Cheat developers who had been squeezing another year out of physical memory tricks discovered this the hard way in the first half of 2024, when the 24H2 preview builds started rolling into Windows Insider rings.

Checking whether HVCI is actually on

Not every Windows 11 install has HVCI enabled. Machines that upgraded in place from Windows 10 typically do not get it flipped on automatically, and any system that reports even one incompatible driver during setup will boot with Memory integrity off. Users who want to know the ground truth should not trust the Settings UI, which sometimes lies after a driver install. The authoritative check is:

# Full HVCI / VBS status dump
Get-ComputerInfo | Select-Object `
    DeviceGuardSmartStatus, `
    DeviceGuardCodeIntegrityPolicyEnforcementStatus, `
    DeviceGuardUserModeCodeIntegrityPolicyEnforcementStatus, `
    DeviceGuardSecurityServicesConfigured, `
    DeviceGuardSecurityServicesRunning, `
    DeviceGuardRequiredSecurityProperties, `
    DeviceGuardAvailableSecurityProperties

# HVCI is active when:
#   DeviceGuardSecurityServicesRunning contains "HypervisorEnforcedCodeIntegrity"
#   DeviceGuardCodeIntegrityPolicyEnforcementStatus == 2 (Enforced)

The two values in DeviceGuardSecurityServicesRunning that matter are 1 (CredentialGuard) and 2 (HypervisorEnforcedCodeIntegrity). Anything less than an integer 2 present in that array means HVCI is not actively enforcing, regardless of what the Core Isolation toggle says. The reference for the enum values, along with the full policy schema, lives in Microsoft's HVCI enablement guide.

For the underlying registry-level configuration, the relevant keys are under DeviceGuard and its Scenarios subkey. The state is stored here:

; HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
;   EnableVirtualizationBasedSecurity  = 1 (enable VBS at boot)
;   RequirePlatformSecurityFeatures    = 1 (Secure Boot) or 3 (SB + DMA prot)
;   Locked                             = 1 (UEFI lock; survives Settings toggle)
;   HVCIMATRequired                    = 0 or 1 (MBEC requirement)

; HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
;   Enabled                            = 1 (turn HVCI on)
;   Locked                             = 1 (UEFI-locked, cannot be disabled
;                                          without a signed policy update)

A locked deployment is the interesting case for anti-cheat vendors. When Enabled is 1 and Locked is 1 and the platform stored the setting in UEFI variables, no amount of registry hacking, safe-mode booting, or bcdedit /set hypervisorlaunchtype off will turn HVCI off. The user has to physically clear the UEFI VBS variable through firmware setup, which most enterprise-managed devices simply do not allow.

What still works under HVCI

HVCI is not a complete elimination of ring-0 code execution. It restricts what can execute, not whether kernel code can be added at all. Three categories still load cleanly:

1. Drivers with a valid WHQL Microsoft signature that are not on the current Microsoft signed third-party driver Blocklist.
2. Drivers with an Attestation Signature obtained through the Windows Hardware Dev Center portal, targeting Windows 10 version 1607 or later. See our own writeup on Windows kernel driver signing in 2026 for how this pipeline works end to end.
3. Drivers signed by a policy-approved certificate under a custom WDAC Code Integrity policy, in enterprise deployments that ship one.

That first category is important because it is how every serious anti-cheat vendor and every serious kernel-mode utility still operates today. EasyAntiCheat, BattlEye, Vanguard, FaceIt, and the KyTech driver all fall into category one. They ship WHQL-signed binaries through the standard Partner Center pipeline, keep them off the vulnerable-driver blocklist by not shipping exploitable IOCTLs, and load without incident on machines where every public signed-driver-abuse chain now bugchecks on load.

The performance cost

HVCI has real overhead. Every EPT walk carries an extra permission check, and every kernel mode page-protection change round-trips into VTL1. Microsoft's own numbers, published in the same HVCI enablement guide cited above, put the impact at "less than five percent" on general workloads. Independent measurements from PC gaming outlets in 2022 and 2023 converged on roughly 1 to 5 percent frame time regression in CPU-bound titles, and effectively zero cost in GPU-bound scenarios.

The overhead is not evenly distributed. Titles that make heavy syscall-per-frame patterns, particularly older DirectX 11 renderers with lots of kernel entries in their present path, sit at the top end of the range. Modern DX12 and Vulkan titles that batch their kernel work sit near the floor. Competitive shooters running at 240 to 500 FPS, where a one-percent regression is a measurable ms shift, are the loudest complainers, which is why "should I turn Memory integrity off for gaming" is one of the most-asked questions on r/pcgaming. The correct answer for anyone playing games with a modern anti-cheat is no.

Why cheat developers hate this

The signed-third-party-driver workflow was the last cheap kernel-code-execution primitive available to public cheat developers. Its death has three downstream effects on the market.

First, the barrier to entry to shipping a real kernel cheat is now the cost and paper trail of obtaining an EV code signing certificate, submitting a driver through Partner Center for attestation signing, and keeping that signature usable across updates. Publicly-listed EV certificates get burned by the anti-cheat vendors within days of being spotted in the wild. That pushes real kernel cheats into the domain of vendors willing to burn a $500 to $1500 certificate per revocation, which most free and low-cost cheats simply cannot sustain.

Second, everything that used to sit in kernel mode has to move back to user mode. That means techniques that were dead a decade ago (usermode DLL injection, DirectX hooks, memory scanners running as a normal process) come back into vogue, and every serious anti-cheat has hardened against those since 2017. The result is that the low end of the cheat market has visibly worsened in quality since 2023, and the vendors making noise about detection issues are almost always the ones who never rebuilt for the HVCI world.

Third, the "hardware ID" concept has become both more relevant and more contested. With kernel-side spoofing more expensive to deliver, HWID stability has become one of the few remaining vectors both defenders and attackers care about. KyTech's own HWID spoofer, currently in Apex-only beta, sits in exactly this space: WHQL-signed, HVCI-compatible, no third-party-driver dependency, no reliance on any driver that a two-year-old blocklist update might have killed.

The Microsoft signed third-party driver Blocklist

The blocklist is worth its own paragraph because it is the mechanism by which HVCI stays useful over time. Microsoft ships the list as a WDAC policy called SiPolicy.p7b, publishes the current entries in the Microsoft signed third-party driver Blocklist reference, and pushes updates through the standard Windows Update pipeline roughly twice a year, with out-of-band updates when a particularly egregious donor driver enters wide use. The current list, as of the most recent public update in the 24H2 servicing branch, contains over 400 entries covering every publicly-known signed-driver-abuse candidate that has surfaced on the RE side of the community.

Under HVCI, the blocklist is enforced by the Secure Kernel and cannot be disabled by any code running in VTL0, including a kernel debugger attached to the guest. Without HVCI, the same policy loads but is enforced by the NT kernel itself, which means anyone who can already run ring-0 code can disable it. That distinction is why HVCI without the vulnerable-driver blocklist is a strictly weaker configuration than HVCI with it enabled.

How KyTech handles this

KyTech was founded in 2025 by two engineers with kernel-mode backgrounds, and every product we ship has been designed to load and run cleanly under HVCI from day one. The KyTech kernel driver is a proper WHQL-signed binary submitted through the standard Partner Center pipeline. It does not ship exploitable IOCTLs, it does not expose an arbitrary-memory primitive to user mode, and it does not depend on any donor driver that the Microsoft signed third-party driver Blocklist could kill overnight. Users can see the current product line and pricing for our supported titles: Apex Legends, CS2, Overwatch 2, Black Ops 7, Forza Horizon 6, and Roblox.

The HWID spoofer, currently in Apex-only beta, is built to the same standard. Our supported titles keep working through Windows 11 24H2 updates and quarterly VBS blocklist pushes because the stack does not depend on third-party signed drivers we did not author. When a Windows Insider ring surfaces a new HVCI enforcement wrinkle, our internal test rigs pick it up before it reaches the release channel, and our driver is updated to stay clean. KyTech Apex is where this architecture lives in production, and it is why the flagship loads without incident on any HVCI-enforced install we test against. That is the durable engineering posture the current Windows 11 threat model demands, and it is what our users are actually paying for.