Listen to this Post
Introduction
Modern security research and advanced debugging increasingly rely on virtualization. A Type-2 hypervisor, or “hosted hypervisor,” is virtualization software installed on top of an existing operating system. The “Type2-AMD-HV” project, developed by Tyler Davis, is an open-source example implementing a Type-2 hypervisor specifically for AMD processors, leveraging the AMD Secure Virtual Machine (SVM) technology to put the running OS “underneath itself as the guest”.
Learning Objectives
– Understand the fundamental architecture and security implications of Type-2 vs. Type-1 hypervisors.
– Analyze the “Bring Your Own Vulnerable Driver” (BYOVD) technique used to load kernel drivers.
– Learn basic hypervisor setup and driver loading through command-line examples.
You Should Know
1. Decoding the Hypervisor: Type-2 vs. Type-1
The core of the project lies in its Type-2 classification. Unlike a Type-1 (Bare-Metal) hypervisor like Microsoft Hyper-V or VMware ESXi, which runs directly on the hardware, a Type-2 hypervisor operates on top of a host operating system. This design choice introduces a critical performance and security trade-off. The host OS layer increases overhead, impacting speed, but it also simplifies development and deployment.
Why This Matters for Security: This setup creates a dual-layer attack surface. A compromise of the host OS could theoretically lead to the hypervisor, and subsequently all guest VMs, being compromised. The reliance on a manual mapper or BYOVD technique—essentially a signed but vulnerable driver—is a significant vector. The “Type2-AMD-HV” project explicitly mentions that you must “bring your own driver loader (manual mapper / BYOVD),” which is a known method to bypass Windows Driver Signature Enforcement (DSE) and load arbitrary code into kernel memory.
Step‑by‑Step Guide: Driver Loading Using BYOVD
The following steps outline the theoretical process used in research environments. ⚠️ This is for educational purposes only in isolated test environments.
1. Obtain a Vulnerable Driver: Acquire a signed but vulnerable driver (e.g., `iqvw64e.sys`, `RTCore64.sys`).
2. Set Up Research Environment: Use a fully updated Windows 10/11 VM with Secure Boot and HVCI enabled to test against modern defenses.
3. Deploy Exploit Tool: Use a tool like `kdmapper` or custom script to interact with the vulnerable driver.
4. Map Payload Driver: The tool sends an IOCTL to the vulnerable driver, writing your unsigned payload driver into kernel memory.
5. Execute: Trigger the execution of your payload, gaining kernel-level execution. The expected output would be a confirmation of the driver being mapped.
Example Commands:
Clone the KDMapper repository git clone https://github.com/TheCruZ/kdmapper cd kdmapper Compile using Visual Studio x64 command prompt msbuild kdmapper.sln /p:Configuration=Release /p:Platform=x64 Execute mapping (example) kdmapper.exe iqvw64e.sys my_payload_driver.sys
This process bypasses Driver Signature Enforcement without rebooting.
2. The Hypervisor Control Block (VMCB) and Execution
The “VMRUN” loop referenced in the post is the heart of the AMD SVM technology. When the hypervisor is loaded, it initializes the Virtual Machine Control Block (VMCB). This data structure tells the processor where the guest state is stored and where to jump when a VM exit occurs. The VMRUN instruction then passes control to the hypervisor which executes the guest OS. A small amount of MASM (Microsoft Macro Assembler) is required for the VMRUN loop and IDT entry stubs, which handle the low-level context switching at the CPU level.
Step‑by‑Step Guide: VMCB Initialization
1. Allocate Memory: Reserve a region of non-paged pool memory for the VMCB.
2. Set Control Bits: Configure the VMCB controls (e.g., intercepts for I/O, MSR accesses, CPUID instructions).
3. Load Guest State: Copy the current CPU registers (CR3, RIP, RSP) into the VMCB as the initial guest state.
4. VMRUN: Call the `vmrun` instruction, passing the physical address of the VMCB to enter VMX root operation.
3. The Historical Context: The “Blue Pill” Rootkit
This research builds on concepts introduced by the infamous “Blue Pill” rootkit. Blue Pill was a proof-of-concept that demonstrated how a running operating system could be “trapped” and virtualized beneath a tiny hypervisor without the user’s knowledge. Originally designed for AMD’s Pacifica (SVM) technology, it showcased the potential for stealthy malware that resides below the OS kernel. The Type2-AMD-HV project is a modern, direct implementation of this concept, written in C and MASM. This historical lineage is crucial for security professionals to understand the evolution of software-based virtualization attacks.
– Detection: Blue Pill can be detected using timing-based attacks and hardware features like the `INVLPGA` instruction.
– Mitigation: Modern defenses like Hypervisor-Protected Code Integrity (HVCI) and Virtualization-Based Security (VBS) make it significantly harder for such rootkits to load and operate undetected.
4. Basic Hypervisor Tutorial for AMD Processors
For those looking to learn from a more structured perspective, projects like `SimpleSvm` by Satoshi Tanda provide a minimalistic educational hypervisor. It is written to provide small, explanatory code for using SVM with Nested Page Tables (NPT) from a Windows driver. NPT is AMD’s implementation of Second Level Address Translation (SLAT), which allows the hypervisor to control memory access permissions for the guest, a technique used for stealth hooks and memory introspection.
Step‑by‑Step Guide: Building an Educational Hypervisor
1. Review AMD Manuals: Download the AMD64 Architecture Programmer’s Manuals Volumes 2 and 3.
2. Install WDK: Set up Visual Studio with the Windows Driver Kit (WDK) for kernel-mode development.
3. Build SimpleSvm: Clone the repository and open the solution in Visual Studio.
4. Deploy with Driver Loader: Use a kernel driver loader (like `OSR Driver Loader`) to start the driver.
5. Debug: Attach a kernel debugger (WinDbg) to observe VM exits and monitor hypervisor activity.
5. Manual Mappers and Kernel Signing Bypasses
The “manual mapper” or “reflective driver loading” is a technique used to load drivers directly from memory without touching the disk, effectively bypassing standard OS integrity checks. This is accomplished by abusing an arbitrary read/write primitive obtained from a vulnerable signed driver, then manually fixing up the payload’s dependencies (IAT, base relocations) in kernel memory. This is a common technique in both game cheat development and advanced persistent threat (APT) tooling due to its overlap with kernel anti-cheat evasion.
What Undercode Say:
– Key Takeaway 1: The “Type2-AMD-HV” project is a working demonstration of how research from over a decade ago (Blue Pill) is still applicable and being actively implemented on modern Windows systems.
– Key Takeaway 2: The requirement to “bring your own vulnerable driver” shifts the focus from hypervisor development to the wider problem of the BYOVD attack surface, which is a persistent enterprise security risk.
Analysis: The post correctly identifies a high-skill area (hypervisor development) and links it to a practical, low-skill entry vector (BYOVD). Many EDR solutions are blind to activities that occur in the hypervisor layer, making this an effective but highly complex evasion tactic. The reliance on MASM and the WDK means the developer is assumed to have deep knowledge of x86/AMD64 assembly, kernel internals, and Windows driver architecture. This is not a “script kiddie” tool. The most valuable insight is the open admission that the loader is external, indicating the author is more focused on the hypervisor’s VMRUN logic than on delivery mechanisms.
Prediction:
– -1 (Negative): Projects like these will accelerate the commoditization of hypervisor-based rootkits, making once-exotic Blue Pill attacks more accessible to a broader range of threat actors.
– -1 (Negative): Microsoft will intensify its efforts to block vulnerable drivers via the HVCI blocklist and WHQL requirements, shrinking the usable BYOVD pool but not eliminating it entirely.
– +1 (Positive): Open-source educational hypervisors are invaluable for defensive research, helping blue teams build detection mechanisms for virtualization-based malware.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
[Join Undercode Academy for Verified Certifications](https://undercode.co.uk/certifications/)
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[[email protected]](mailto:[email protected])
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: [Aleborges Cybersecurity](https://www.linkedin.com/posts/aleborges_cybersecurity-hypervisor-programming-share-7468335394128945152-TZ35/) – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
[💬 Whatsapp](https://undercode.help/whatsapp) | [💬 Telegram](https://t.me/UndercodeCommunity)
📢 Follow UndercodeTesting & Stay Tuned:
[𝕏 formerly Twitter 🐦](https://x.com/undercodeupdate) | [@ Threads](https://www.threads.net/@undercodetesting) | [🔗 Linkedin](https://www.linkedin.com/company/undercodetesting/) | [🦋BlueSky](https://bsky.app/profile/undercode.bsky.social)
