Hv2 - AMD-V (SVM) Type-2 Hypervisor Research Project

Hv2 is a Windows kernel-mode Type-2 hypervisor built as a research project for studying x86-64 architecture, AMD Secure Virtual Machine (SVM), nested paging, and live operating-system virtualization. The project explores how a running Windows system can be transitioned into a hardware-virtualized guest context while preserving normal kernel execution.

This repository is intended for educational and defensive research use in controlled lab environments. It focuses on virtualization mechanics, CPU state reconstruction, memory translation, and kernel debugging rather than production deployment.

---

Technical Highlights

• Live system virtualization: Captures the active processor state and initializes a Virtual Machine Control Block (VMCB) so the running kernel can continue execution as a guest.
• Multicore launch coordination: Uses a two-phase initialization strategy with processor affinity and DPCs to bring all logical processors into the virtualized context consistently.
• VMCB state reconstruction: Rebuilds guest segment, control-register, descriptor-table, and MSR state from the live system.
• Windows kernel implementation: Runs as a kernel driver and exercises low-level Windows internals including IRQL constraints, system threads, DPC dispatch, and driver unload cleanup.
• Nested Page Tables (NPT/SLAT): Implements second-level address translation, physical memory identity mapping, large-page splitting, and page-level permission control.
• VMEXIT handling: Provides dispatch logic for selected intercepts including MSR access, SVM instructions, nested page faults, debug exceptions, and test hypercalls.

---

Project Structure

The codebase separates hardware-facing assembly and architecture definitions from higher-level virtualization logic.

Component	Responsibility
SVM/Asm/Launch.asm	Low-level SVM launch path, register preservation, and initial VMRUN transition.
SVM/Asm/Entrypoint.asm	VMEXIT entry path and host/guest context transition handling.
SVM/Svm.cpp	Hardware capability checks, per-core setup, and multicore initialization flow.
SVM/Vmcb.cpp	VMCB initialization and live CPU state reconstruction.
SVM/Handlers/	C++ VMEXIT dispatch logic for intercepted events.
SVM/Npt.cpp / SVM/Npt.h	NPT identity map, page splitting, and page-level translation controls.
HypercallTest/	Small user-mode test harness for validating VMMCALL/hypercall behavior.

---

Implementation Notes

1. Virtualization Lifecycle

Type-2 hypervisors must virtualize an already-running system instead of booting a guest from a known initial state. Hv2 handles this by splitting initialization into two phases:

• Phase 1 - Per-core preparation: The initialization thread is pinned to each logical processor to configure SVM state and register the host save area.
• Phase 2 - Concurrent launch: DPCs are queued across processors so all cores enter the virtualized context in a coordinated window, reducing the chance of inconsistent CPU state between cores.

This design is meant to avoid common failure modes in multicore kernel virtualization, including watchdog timeouts and processors observing different execution environments.

2. CPU State Reconstruction

Because the guest is the currently running Windows kernel, Hv2 reconstructs the VMCB save-state area from live processor state:

• Segment decoding: A fill_segment helper parses GDT descriptors and reconstructs base addresses, limits, selectors, and SVM attribute fields.
• Descriptor tables: The current GDT and IDT are captured so guest interrupt and exception delivery continue through the expected Windows paths.
• System-call MSRs: LSTAR, STAR, and SFMASK are mirrored into the guest state so SYSCALL behavior remains consistent after virtualization.
• Control state: Control registers and EFER are initialized to match the pre-virtualization execution environment while enabling SVM operation in the host context.

3. Nested Page Tables

AMD-V nested paging adds a second translation layer from Guest Physical Address (GPA) to System Physical Address (SPA). Hv2 uses this mechanism to study hypervisor-controlled memory translation and page-level permissions.

Identity map construction: During NPT initialization, Hv2 queries MmGetPhysicalMemoryRanges and builds a GPA-to-SPA identity map using 1 GB pages where possible. The resulting PML4 physical address is written to VMCB.N_CR3, and nested paging is enabled through VMCB.NP_ENABLE.

Page splitting: Fine-grained page permissions require 4 KB mappings. Hv2 supports splitting larger NPT mappings on demand:

1. npt_split_huge_page replaces a 1 GB mapping with a page directory of 512 2 MB entries.
2. npt_split_large_page replaces a 2 MB mapping with a page table of 512 4 KB entries.

Cache attributes are preserved across splits to avoid mismatches with the system's physical memory type configuration.

Permission-based page views: For research into execution-time instrumentation, Hv2 can maintain alternate NPT mappings for a single guest page and switch permissions in response to nested page faults and debug exceptions. This demonstrates how a hypervisor can distinguish instruction fetches from ordinary data reads/writes using hardware-enforced translation permissions.

4. Intercept Consistency

Hv2 includes selected intercept handling to keep guest-visible behavior coherent while the processor is running under SVM:

• MSR handling: Intercepts selected MSR reads/writes where guest-visible state must differ from host SVM control state.
• SVM instruction handling: Intercepts SVM-specific instructions and injects architecturally appropriate exceptions for guest execution.
• Nested page faults: Handles NPT permission faults and updates translations before resuming guest execution.
• Debug exceptions: Uses single-step handling where temporary permission changes must be restored immediately after an instrumented instruction executes.

The goal is architectural correctness: the guest should continue running with behavior that is internally consistent with the virtualized execution environment.

---

Development & Debugging

Kernel-mode virtualization work requires a dedicated debugging setup. The project was developed and tested in nested virtualization environments with kernel debugging enabled.

• WinDbg kernel debugging: Used to diagnose bug checks, hangs, VMEXIT paths, and early launch failures.
• VMware nested AMD-V/RVI: Used for rapid iteration inside an isolated virtual machine.
• Serial logging: Captures low-level state around launch, VMEXIT, and teardown paths where normal debugging tools may be unavailable.
• Test signing: Required for loading the development driver in a lab Windows environment.

---

Anti-Cheat Detection Research & Responsible Disclosure

Hv2 is currently being used as a research platform to explore the detection surface of hypervisor-based memory introspection tools, with the intent of responsibly disclosing findings to anti-cheat vendors (EAC, Vanguard) and publishing a public writeup on vmmcall.org.

The goal is to document which detection vectors are closeable in software, which are irreducible without hardware-level mitigations, and what anti-cheat vendors should implement to address this class of threat.

Hardening Research — Priority Queue

The following techniques are being explored in order, each documented as a detection vector and its countermeasure:

• 1. DKOM — Module list hiding: Remove Hv2's LDR_DATA_TABLE_ENTRY from PsLoadedModuleList after load. Demonstrates that kernel module enumeration is not a reliable detection method. Countermeasure: cross-referencing physical memory ranges against known modules.

• 2. MSR bitmap audit: Verify empirically whether FS_BASE/GS_BASE MSR intercepts fire on Windows 11 with CR4.FSGSBASE enabled. Remove unnecessary intercepts to minimize VMEXIT frequency and residual timing noise.

• 3. RDTSC normalization: Intercept RDTSC/RDTSCP and subtract per-vCPU accumulated VMEXIT overhead from the returned counter. Demonstrates that software timing-based detection is closeable. Countermeasure: server-side attestation.

• 4. Physical memory fingerprint (document as irreducible): Contiguous physically-backed allocations (VMCB, scratch pages, host save areas) are visible via physical memory enumeration with no module attribution. Documents a detection vector that survives all other mitigations.

• 5. NPT hook timing side-channel (document as irreducible): The execute-vs-read path divergence in the page-flip mechanism has a fundamental timing side-channel that cannot be closed in software. Key finding for the disclosure report.

• 6. Hardware mitigation recommendations: TPM measured boot (SVM-enabled state changes PCR values, verifiable by game server), Secure Boot policy enforcement blocking third-party hypervisors. The only architectural answer to this class of tool.

Future Research (flagged)

• Hypervisor-assisted NPT-protected manual mapper: Physical-level DLL injection with zero API signature and zero scanner visibility via NPT page flip on injected pages. Novel technique flagged for a future standalone disclosure.

---

Roadmap & Future Research

• Independent host paging: Add a private VMM page table hierarchy to better isolate host-mode hypervisor memory from guest-controlled mappings.
• Nested Page Tables: Implement hardware-backed second-level address translation with identity mapping and page-split support.
• Permission-based NPT instrumentation: Demonstrate page-level permission transitions using NPF and single-step handling.
• Cross-process memory introspection: Hypercall API for arbitrary read/write across process address spaces with zero kernel API calls at GIF=0.
• Structured test suite: Expand the user-mode hypercall tests and add repeatable validation for launch, teardown, and NPT translation behavior.
• Documentation diagrams: Add diagrams for the launch sequence, VMCB state layout, and NPT split flow.

---

Credits & References

• AMD64 Architecture Programmer's Manual, Volume 2: Primary reference for SVM, VMCB layout, intercepts, and VMEXIT codes.
• SimpleSvm by Satoshi Tanda: Reference for SVM initialization concepts and the transition into hardware-virtualized execution.
• Memhv by Samuel Tulach: Reference for consistency issues around guest-visible virtualization state and MSR handling.

---

Building & Deployment

1. Requirements: Visual Studio, Windows Driver Kit (WDK), and MASM.
2. Configuration: Build for x64 in Debug or Release.
3. Testing: Requires TESTSIGNING to be enabled on the target machine.

sc create Hv2 type= kernel binPath= "C:\Path\To\Hv2.sys"
sc start Hv2

This project is for controlled educational research into low-level system architecture, Windows kernel development, and AMD-V virtualization.