Minimalistic hypervisor with memory introspection capabilities
This project has a single goal: to be as minimal as possible while providing a hypercall API for reading/writing an address space of any (protected) process. It is a standalone Microsoft Windows kernel-mode driver that can be loaded either normally or through manual mapping.
Some parts were copied from my Sphinx project, so the codebase might contain some unused defines and headers.
- Windows 10 or Windows 11 (both 64-bit, offsets may need updating)
- AMD processor with SVM and NPT support
- Ensure that you have SVM enabled in UEFI firmware options (BIOS)
- Make sure Microsoft Hyper-V is fully disabled
- Use manual mapper to load the kernel mode driver (kdmapper, KDU)
- Enjoy hypercall API (see client folder)
Common timing attacks are ineffective against this hypervisor, as it does not exit on CPUID or similar instructions typically used in such attacks. When manually mapping, code will be in unsigned memory, having all the usual vectors. However, this can be easily mitigated by adjusting the NPT to completely hide the hypervisor memory from the guest.
At the time of release, no popular anti-cheat has issues with this hypervisor running.
- Q: Will there be a version supporting Intel CPUs / Intel VT-x?
- A: No, at least not public.
- Q: Driver is returning unsuccessful status and the hypervisor is not loaded, why is that?
- A: If virtualization is truly enabled in BIOS, then make sure Hyper-V is really disabled. It might be off in Windows Features dialog, but still running due to WSL, Docker, VBS/HVCI and similar.
- Q: Hypervisor loads just fine, but the moment I try to attach to a process, the system crashes!
- A: Certain system APIs cannot be used in the VM-exit context, so the EPROCESS of the target process is found manually by iterating a linked list. Hard-coded offset is used. Make sure it is updated.
- Q: Hypervisor loads fine, everything works, but after some time the system crashes!
- A: System sleep/hibernation is not supported. Memory mapping is done only for the first 512 GB of physical memory. In theory, that should be fine, but in reality, certain drivers (most commonly overclocking tools, motherboard utilities) will attempt to access memory beyond this range. Since there is no mapping, a nested page fault will occur, causing a system crash. You can fix this by implementing an exit handler that will add memory mappings on the fly, or if you don't care about 1.4 GB of useless space, then you can map all the 512 PML4 entries in NPT at once.
- Q: Do you have anything less barebones then this?
- A: I have Sphinx project already mentioned above. It also hides its memory, supports Intel VT-x, reading of guarded pages, proper TSC offsetting, CR3 resolving (for processes with trashed directory base), etc. I have no plans to publish it at the moment.
- SimpleSvm by @tandasat