HyperDbg: a Windows debugger that runs below the operating system

Why a debugger that virtualizes the running system

HyperDbg does not attach to a process the way a conventional debugger does. The README states that it runs on top of the operating system by virtualizing an already running system using Intel VT-x and Extended Page Tables, and it combines that with Intel Processor Trace to get tracing and virtual machine introspection capabilities. The practical upshot is that the debugger sits below the code it observes, which is where most of its unusual features come from.

That positioning explains both what the project can do and what it costs you. Because observation happens through the page table rather than through a debug register or an API call, the number of things you can watch at once is not capped by the four debug registers a CPU exposes, and the README says so directly: the monitoring facilities are not limited by the number of available debug registers or by size constraints. Execution tracking also crosses privilege levels, following transitions from user mode into the kernel through system calls, heaven's gate, faults, exceptions and interrupts, then out to drivers and back.

The repository is written in C and licensed GPL-3.0. The topics list tells you the intended audience precisely: anti-debug, anti-virtualization, malware-analysis, reverse-engineering, game-security, ept and virtual-machine-introspection. Nobody installs this to step through a Python script.

EPT hidden hooks and memory monitoring without debug registers

The core capability is a set of EPT-based hidden hooks. In the README's framing, HyperDbg can emulate hardware data breakpoints to monitor reads, writes and executions over specific address ranges while staying transparent to both the operating system and the target application. Because the emulation happens in the page table, the hooks do not consume debug registers and are not bound by the register file's size.

Alongside that sit system call hooking, control flow tracing through hardware tracing features, and monitoring of I/O. The I/O coverage is split into memory-mapped I/O and port-mapped I/O, with separate command references for each, which is the kind of detail that matters when you are reverse engineering a driver that talks to hardware. On top of these sit a large collection of additional events built for reverse engineering and malware analysis, and the README points to a full feature list rather than trying to enumerate them.

The README is honest about the limits of the stealth claim. HyperDbg uses no debugging APIs to debug the operating system or an application, so classic anti-debugging checks will not spot it, and a specialized module watches for attempts to detect a hypervisor or debugger and then reports or mitigates those attempts. The README also says complete transparency cannot be guaranteed in all scenarios. That is the sentence to remember before betting an anti-cheat engagement on it.

Building from source with a recursive clone

Compiled binaries are published on the releases page, and the README points there first. If you would rather build it, the clone has to be recursive, because the repository carries submodules:

git clone --recursive https://github.com/HyperDbg/HyperDbg.git

Dropping that flag is the most common way to end up with a tree that does not build, and the README calls the flag out explicitly rather than leaving it to a build failure. The repository tree shows the layout you are dealing with: `hyperdbg/` for the debugger itself, `hwdbg/` for the hardware debugging side, `utils/` for shared helpers, `examples/` split into kernel and user directories, and `doxyfile` at the root, which is why there is a Doxygen site in the badge row alongside the main documentation.

Actual environment setup is not in the README. It sends you to the Build and Install page on docs.hyperdbg.org to configure the environment, then to a Quick Start page, then to a FAQ page. That is the right division of labour for a project of this complexity, but it does mean the README alone is not enough to get a working debugger, and you should budget time for the documented prerequisites before you evaluate the tool.

A script engine that keeps gaining data types

HyperDbg has its own scripting language rather than only interactive commands, and the release notes show it being extended type by type. Version 0.23, published 2026-08-02, added floating point support to the script engine and added a `ucpuid` command. Version 0.22, published 2026-07-20, added a `dl` command for traversing linked lists by virtual address and a `!dl` variant for physical addresses.

That pattern of paired commands is consistent across the project and worth understanding. Commands without a prefix operate in user mode, and the same command with a leading `!` operates in kernel mode, which is why 0.24 added both `dw` and `!dw` for reading two byte word values, and both `da` and `!da`. Once you know that convention, the command reference becomes predictable, and it explains how HyperDbg can track execution across privilege levels with the same vocabulary in both.

The scripting side matters for automation. Both the kernel-mode debugging examples and the script engine examples are called out in every release note as the recommended way to get started, and a scriptable debugger is what you want for fuzzing or for re-running the same trace against a new build. Version 0.24, published 2026-09-22, is the most recent release, and the last push on the repository was on the same day.

Linux support, a hardware debugging track, and research output

The README describes HyperDbg as a debugger for Windows, with Linux support under development. Release 0.24 moved that from intention to fact for one part: all of HyperDbg's kernel modules now compile on Linux. That is a compile guarantee, not a parity guarantee, and the README has not yet relabelled the project, so treat Linux as work in progress rather than a supported platform you can plan around.

The `hwdbg/` directory and the hardware debugging material point at a second front on the project: debugging the machine itself, including firmware level problems where there is no operating system to attach to yet. For a project whose stated purpose includes advanced system analysis, that is not a side feature. The examples directory, split into `kernel/` and `user/`, follows the same user mode and kernel mode split that the command prefixes use.

HyperDbg also publishes academic work, with a research subdomain linked in the README badges and a FOSDEM 2026 schedule entry for a talk on invisible hypervisors and debugging with HyperDbg. Community support runs through Telegram, Discord and Matrix, and the README asks for a star on releases rather than a specific maintainer. None of that tells you whether the tool fits your problem, but it does tell you the project has an academic and conference presence rather than being a weekend experiment.

Where HyperDbg sits against a conventional debugger

The README itself frames the trade-off in two numbered advantages: full system and OS control through the hypervisor layer, and detection resistance because no standard OS debugging API is used. Against that it states the cost plainly, that HyperDbg is harder to set up and use and requires deeper low-level system knowledge than traditional debuggers.

The honest comparison is therefore with WinDbg and with kernel debuggers generally, not with GDB. WinDbg gives you a symbol-aware, familiar experience and mature crash analysis. HyperDbg gives you EPT hooks that do not consume debug registers, monitoring across address ranges rather than at fixed watchpoints, and an anti-debug stance, at the cost of a vocabulary you have to learn and a build that is not a single package install.

What the README does not settle is quantitative. There is no throughput figure, no overhead measurement, and no guidance on how many EPT hooks you can hold before performance degrades, because the answer depends on your CPU, your page table layout and your target. Those pages are on docs.hyperdbg.org, and the command reference there is the thing to read before committing, since the feature list is large and moving with every release.

Editorial conclusion

HyperDbg is the right instrument when the target detects debuggers, when the bug lives in kernel mode or a driver, or when you need to watch a range of memory without spending hardware debug registers on it. It is the wrong instrument for application debugging on a normal machine, because the README is explicit that it is harder to set up and use than a traditional debugger and needs deeper low-level knowledge. Two things to verify before relying on it: which of the three recent releases you are on, since the command set is still gaining verbs release by release, and whether your CPU and firmware expose the virtualization features EPT monitoring depends on, which the repository documents rather than the README. Start from the Quick Start page and the script engine examples, because the command vocabulary is large enough that the examples teach it faster than the reference.

Frequently asked questions

Official sources

1. HyperDbg/HyperDbg on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases