HVCI and VBS are acronyms that are often heard in the anti-cheat community, but what are they really?
HVCI: Hypervisor-Enforced Code Integrity
Let's start with HVCI, or Hypervisor Protected Code Integrity, its a protection for the Windows kernel that prevents unsigned code from being executed on it.
How it works
Basically by preventing read, write, and execute (RWX) sections from being generated in the kernel.
This means that an attacker cannot write malicious code (mostly shellcode) in these sections.
In addition, if attackers cannot force data pages (which are writable) to transform them into code pages, these pages containing malicious shellcode will never be executed.
Virtualization support
How is this achieved?
HVCI utilizes existing virtualization capabilities provided by the CPU and Hyper-V hypervisor.
To truly understand the power of HVCI, we must first understand some of the virtualization technologies that enable HVCI to achieve its goals.
Hyper-V Technology: Microsoft's Hypervisor
Hyper-V, as mentioned in the title, is Microsoft's hypervisor.
But what is a hypervisor?
A hypervisor is software that creates and runs virtual machines by separating the operating system and hardware resources.
Types of hypervisors
There are two types of hypervisors that can be used for virtualization: type 1 and type 2.
Type 1
A type 1 hypervisor, also known as the original or dedicated server (bare metal) hypervisor, runs directly on the host hardware to manage guest operating systems.
It functions as a host OS and programs the resources of the virtual machines directly on the hardware.
This type of hypervisor is typically used in enterprise data centers or other server-based environments.
Examples include KVM, Microsoft Hyper-V, and VMware vSphere.
KVM was incorporated into the Linux® kernel in 2007, so if you are using a modern version of Linux, you already have access to it.
Type 2
A type 2 hypervisor is also known as a hosted hypervisor and runs on a conventional operating system as a layer of software or an application.
It works by extracting guest operating systems from the host operating system.
The virtual machine's resources are programmed into a host operating system, which then runs on the hardware system.
These hypervisors are ideal for individual users who want to run multiple operating systems on a personal computer.
VMware Workstation and Oracle VirtualBox are examples.
When a virtual machine is created, system resources are allocated to create a secondary partition for the virtual machine.
This includes its own physical address space, virtual processors, virtual hard disk, etc.
When creating a secondary partition, a boundary is created between the root partition and the secondary partitions, where the secondary partition is placed in its own address space and isolated.
This means that a virtual machine cannot “touch” other virtual machines or the host, as virtual machines are isolated in their own address space.
Among the technologies that help maintain isolation between virtual machines is SLAT, or Second Layer Address Translation.
SLAT is what actually allows each virtual machine (VM) to operate within its own address space from the hypervisor's perspective.
In Intel's case, this technology is known as Extended Page Tables (EPT).
Essentially, SLAT (EPT) gives the hypervisor the ability to create an additional memory translation, allowing it to decide how memory is allocated and managed for each VM.
When a virtual machine needs to access physical memory (after having previously translated its own internal virtual memory), with EPT enabled, the hypervisor instructs the CPU to “intercept” that request.
The CPU is responsible for translating the memory address that the virtual machine is trying to use into the actual physical memory of the host computer.
The virtual machine does not know the actual layout of the host system's physical memory, nor can it see the actual memory pages.
From its point of view, it works with memory just like any normal computer, translating virtual addresses to physical ones.
However, in the background, SLAT performs an additional translation: it takes that “physical” address that the VM believes it is using and converts it to the actual physical address of the host.
With SLAT (Second Layer Address Translation) enabled, a physical address inside a VM (like 0x1000) is treated as a Guest Physical Address (GPA).
The CPU then translates this GPA into a System Physical Address (SPA) (the actual physical memory on the host machine).
This translation is handled by Extended Page Tables (EPT), whose base structure is the EPT PML4, similar to normal paging but used for mapping GPAs to SPAs instead of virtual to physical addresses.
The EPTP (Extended Page Table Pointer), stored in each virtual CPU’s VMCS (Virtual Machine Control Structure), points to these tables and guides the CPU in the translation process.
Each entry in the EPT is an EPTE (Extended Page Table Entry).
EPTEs are like normal PTEs but describe only physical memory, not virtual memory.
Because of this, physical memory always takes precedence — if a page is writable in the virtual view but read-only in the physical one, any attempt to execute and/or write to the page will result in an access violation.
In essence, the hypervisor has the supreme view of memory, controlling how all memory pages are defined and accessed.
Summary
- Each VM is isolated in its own address space.
- The host’s real physical memory is abstracted from the VM.
- Physical memory permissions override virtual ones.
- EPTEs give the hypervisor final control.
These principles form the foundation of HVCI (Hypervisor-Enforced Code Integrity), which operates under Virtualization-Based Security (VBS) — a core security feature in modern Windows systems.
VBS: Virtualization-Based Security
With virtualization-based security enabled, the Windows operating system runs in a kind of “virtual machine.”
Although Windows is not placed on a secondary partition, which means it does not have a VHD (virtual hard disk), the hypervisor, upon startup, uses all of the principles and technologies mentioned above to isolate the “standard” Windows kernel (i.e., what the end user interacts with) in its own region, similar to how a virtual machine is isolated.
This isolation manifests itself through Virtual Trust Levels (VTLs).
There are currently two virtual trust levels: VTL 1, which hosts the “secure kernel,” and VTL 0, which hosts the “normal kernel,” the latter being the one with which end users interact.
Both VTLs are located in the root partition.
These two VTLs can be thought of as “isolated virtual machines.”
Virtual Trust Levels (VTLs)
Virtual Trust Levels (VTLs) work much like virtual machines — they isolate environments from each other.
In Windows, VTL 1 (the secure kernel) is a more privileged and protected environment than VTL 0 (the normal kernel) where users and regular processes run.
The purpose of VTLs is to establish a stronger security boundary.
If an attacker exploits the kernel in VTL 0, their access is confined there — they can’t reach VTL 1.
Previously, compromising the Windows kernel meant total system control; now, VTL 1 remains isolated and protected, even if VTL 0 is compromised.
It’s important to note that VTL 0 and VTL 1 are separate entities, not nested within each other.
VBS (Virtualization-Based Security) doesn’t create real virtual machines; rather, it uses the same virtualization technologies to isolate these trust levels.
VTL 1 can influence VTL 0 — for example, configuring how HVCI (Hypervisor-Enforced Code Integrity) operates — but it does so through the hypervisor, using a mechanism called a hypercall.
In short
- VTL 0: normal Windows kernel and user processes.
- VTL 1: secure, isolated environment with higher privilege.
- Hypervisor: sits beneath both and mediates their interaction.
Thus, VTL 1 ≠ the hypervisor, and VTL 0 doesn’t run inside VTL 1 — they are distinct layers working together to enforce stronger system integrity and isolation.
HVCI + VBS Together
HVCI does not work in isolation: it relies on the protections and isolation mechanisms provided by VBS (Virtualization-Based Security).
VBS creates different Virtual Trust Levels (VTLs) within the system root, and within that context, HVCI is responsible for verifying the integrity of the code that attempts to run in the kernel.
This means that only signed and validated code can be executed, while any attempt to inject or modify kernel memory will be blocked by the hypervisor.
At a technical level, the hypervisor intercepts protected memory operations, applying rules based on EPT (Extended Page Tables).
Thanks to this, the kernel can no longer be modified directly by malicious processes, even if they manage to obtain ring 0 privileges.
From a security standpoint—and in contexts such as anti-cheat or forensic analysis—this represents a significant change:
the attack surface on the kernel is drastically reduced, making it difficult to execute unsigned drivers, inject code in kernel mode, or bypass integrity protections.
Summary
- VBS isolates environments (VTLs) and establishes a secure context.
- HVCI validates and protects the code that runs within the kernel.
Together, they create an architecture where even compromising the kernel does not guarantee total control of the system.
Conclusion
The combination of HVCI and VBS is one of the pillars of modern security in Windows.
These technologies leverage virtualization to establish firm boundaries between critical system components, preventing unauthorized code from running at privileged levels.
In offensive security, malware, or anti-cheat contexts, understanding how these mechanisms work is essential to understanding why certain traditional techniques (injections, direct hooks, or unsigned drivers) no longer work on modern systems with HVCI and VBS enabled.
In essence, HVCI and VBS move kernel protection to a deeper layer — the hypervisor — making attacking or modifying the system require much more than simple administrative privileges.