hyper-reV turns Hyper-V into a memory introspection platform

The guest gets hypervisor level access by borrowing Hyper-V

hyper-reV is memory introspection and reverse engineering tooling that works by leveraging Hyper-V rather than replacing it. The README lists the abilities it gives the guest, meaning the Windows operating system virtualized by Hyper-V: read and write access to guest virtual memory and guest physical memory, translation of guest virtual addresses into their corresponding guest physical addresses, SLAT code hooks, also known as EPT and NPT hooks, and the ability to hide entire pages of physical memory from the guest.

There is a usermode component that serves as a kernel debugger.

The architectural trick is that it does not need to be its own hypervisor. Because Hyper-V is already the thing sitting between the guest and the hardware, and because Hyper-V's own memory management is SLAT based, hooking Hyper-V gives access to the same page tables the hardware consults. That also means it works on systems protected by HVCI, since the project states that leveraging Hyper-V is what makes it work there.

The repository is C++ and laid out as a Visual Studio solution named hyper-reV.sln, with directories for hyperv-attachment, uefi-boot, usermode and shared code, plus images and a load-hyper-reV.bat script at the root. The licence is GPL-3.0, and the repository has no GitHub releases. The last push was on 2026-07-24.

The README covers architecture support in its own section, with Intel and AMD treated separately for code hooks, and describes an APIC section and a hypercalls section with a list and descriptions.

Replacing bootmgfw.efi is how the UEFI module gets in

The entry point is the Windows boot manager itself. The 'uefi-boot' module is described as hyper-reV's UEFI driver. A copy of bootmgfw.efi is made, and the contents of that copy are replaced with the 'uefi-boot' module so it runs at the next boot. The hyperv-attachment, the module inserted into Hyper-V, is saved on disk in the same directory as bootmgfw.efi.

Once the uefi-boot module starts, it restores the original bootmgfw.efi file and any timestamp related metadata, which the README frames as hiding that the file was tampered with. That restoration is the first step of the boot process described in the documentation.

The module then allocates a heap using UEFI boot_services!AllocatePages rather than boot_services!AllocatePool, so the memory is 4kB aligned. That heap is used for the hyperv-attachment runtime image buffer, the PML4 and PDPT for an identity map, the hyperv-attachment's own internal heap, and a deep copy of Hyper-V's SLAT CR3.

All of that memory is later hidden from the guest by pointing each page in the guest SLAT mappings to a dummy page. The original bootmgfw.efi image is then loaded through UEFI boot_services!LoadImage, a hook is applied to bootmgfw.efi!ImgpLoadPEImage, and bootmgfw.efi is started with UEFI boot_services!StartImage.

The Hyper-V launch hook is four lines of assembly and one PML4e

The critical interception happens in three steps. When winload.efi is loaded by bootmgfw.efi, the ImgpLoadPEImage hook intercepts it, and the bootmgfw.efi hooks are fully removed before a hook is applied to winload.efi!ImgpLoadPEImage. That second hook lets hyper-reV intercept the loading of hvloader.dll, and when that load is caught, a hook is applied deep inside the Hyper-V launch routine within hvloader.dll, again after removing the winload.efi hooks.

The README shows a stripped down decompilation of the routine that gets hooked, called from hvloader.dll!HvlLaunchHypervisor:

void __fastcall hv_launch(std::uint64_t hyperv_cr3, std::uint8_t* hyperv_entry_point, std::uint8_t* entry_point_gadget, std::uint64_t guest_kernel_cr3)
{
	__writecr3(guest_kernel_cr3);
	__asm { jmp entry_point_gadget }
}

The parameter meanings are given explicitly. rcx holds a CR3 from which Hyper-V copies certain PML4es, rdx is the virtual address of the relocated Hyper-V entry point, r8 is the address of a gadget which jumps to that entry point, and r9 is the guest kernel CR3, with 0x1AE000 given as the example on Windows 11 24H2.

In the hook, a PML4e is inserted into the CR3 held in rcx, and that PML4e contains an identity map of host physical memory. The physical memory backing the hyperv-attachment is mapped in by the same identity map, so the attachment has a valid virtual mapping in Hyper-V's address space. The loaded image is then relocated by the virtual base of the PML4e plus the physical base address of the image, which is what allows it to execute in Hyper-V's address space once launched.

Hiding from the guest is part of the design, not an afterthought

Two mechanisms keep the guest from noticing what has been inserted into the hypervisor, and both are described in the documentation.

The first is the page hiding already mentioned. Every page in the guest SLAT mappings is pointed at a dummy page, which covers the hyperv-attachment runtime buffer, the identity map pages and the internal heap. The attachment file is deleted from disk as soon as it has been loaded into memory, so the second copy on disk in the boot directory is temporary too.

The second is subtler and the README is explicit about its limits. As described by Iraq1337 in a post the README links to, there are several copies of Hyper-V in physical memory which are not SLAT protected, so the guest can read them. Only the final Hyper-V image buffer is hidden from the guest. In the hypervisor launch hook, rdx holds the virtual address backing that final image buffer, and the README states it will be SLAT protected.

The documentation also has a section on avoiding detection, and lists a usermode application with command usages, kernel hooks, command aliases and a way to flush logs. That is a research tool with a research purpose, and the README does not dress it up as something else.

Code hooks are split by vendor because EPT and NPT differ

The second level address translation hooks are the part of the design that differs most between processor vendors, and the README separates them into an Intel subsection, an AMD subsection, and a third subsection for features common to both.

The common subsection is where the interesting mechanics live. It covers page split and merge, synchronization using NMIs, and a deep copy of the Hyper-V SLAT CR3. That last item appears twice in the documentation, once in the UEFI heap allocation list, where the deep copy of Hyper-V's SLAT CR3 is one of the things the allocated heap is used for, and again in the hook feature list.

The NMI synchronization is split further into NMIs in host state and NMIs in guest state, which is the practical problem of installing a code hook without the guest noticing a debugger was just installed.

There is a dedicated section on returning execution to Hyper-V, and a section on APIC handling, both of which the README treats as required pieces rather than optional extras.

The README also notes that there is a usermode component serving as a kernel debugger, and the top-level table of contents lists command usages and descriptions, kernel hooks, command aliases and flushing logs, so the interactive side of the project is documented as a command driven tool rather than a GUI.

Building means two targets, a load script, and boot configuration caveats

The documentation has a section on how to compile and use the project with four subsections: compilation of the 'uefi-boot' module, architecture-specific compilation, a load script, and usage with Secure Boot. A fifth subsection covers usage with TPM.

The compilation is split because the two pieces are different in kind. The uefi-boot module is the UEFI driver, and the architecture-specific part concerns the hyperv-attachment and the code hook implementations, which the README already separates into Intel and AMD paths. The repository root holds load-hyper-reV.bat, which is the load script the documentation refers to, and hyper-reV.sln ties the Visual Studio projects together. The top-level entries also include a .gitmodules file and shared/ directory.

Secure Boot and TPM get their own usage subsections, which tells you they are treated as real deployment constraints rather than edge cases. On a machine with Secure Boot enforced, a UEFI module and a kernel component both need to pass the platform's signature policy, and the README's decision to spend a subsection on it is a signal about the setup effort involved.

There is also a section listing the tested Windows versions, which is the first thing to check before loading the module onto a machine you care about. The last section of the table of contents is Credits, and the licence is GPL-3.0.

Editorial conclusion

Adopt hyper-reV if you are researching Windows internals from inside a Hyper-V guest and need physical memory access, address translation and EPT or NPT hooks that a normal kernel debugger cannot give you. Skip it if you need a stable debugging product, because the project publishes no releases and the README describes its own detection avoidance as a feature. Verify first that your Windows build matches one of the versions the README lists as tested, that you can run the UEFI module on your platform, and that your Secure Boot and TPM configuration is covered by the documented usage before loading anything.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. noahware/hyper-reV on GitHub
4. README