# DRAKVUF: agentless black-box binary analysis from outside the guest > DRAKVUF is a virtualization based analysis system that traces the execution of an arbitrary binary, including a whole operating system, by reading the machine from the hypervisor rather than by installing anything inside it, and it does that on Intel hardware with VT-x and EPT. It suits a malware analyst or a researcher who needs the sample to be unaware of the observation, and it is limited to one processor family and a short list of guests. **tklengyel/drakvuf** — DRAKVUF Black-box Binary Analysis - Repository: https://github.com/tklengyel/drakvuf - Website: https://drakvuf.com - Stars: 1,291 · Forks: 275 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/tklengyel-drakvuf ## What the system is DRAKVUF is described as a virtualization based, agentless black-box binary analysis system, and it allows for in-depth execution tracing of arbitrary binaries, including operating systems, all without having to install any special software within the virtual machine used for the analysis. That last clause is the design. Everything else about a dynamic analysis system follows from it. The alternative to an agent is instrumentation from outside the guest, and the tool that provides that is virtual machine introspection, reading the guest's memory and registers from the hypervisor layer with the cooperation of the CPU's virtualization extensions. The consequence for the analyst is that the sample behaves as if it were alone. A program that checks for a debugging driver, a hooked syscall table or an unusual device will find nothing, because there is nothing to find. The analysis does not modify the guest at all, which also means the analyst is not debugging a modified environment, a subtlety that matters when the behaviour under test is precisely the anti-analysis behaviour. The project is by Tamas Klenyel, it is written in C++, and the site is drakvuf.com. The repository carries an OpenSSF Best Practices badge, an OpenSSF Scorecard badge, a continuous integration badge and a Coverity badge, which is an unusual amount of supply chain signalling for a research tool. ## The hardware requirement, which decides everything The hardware requirements section is short and it is the most important thing in the README for anyone evaluating the tool. DRAKVUF uses the hardware virtualization extensions found in Intel CPUs. You need an Intel CPU with virtualization support, which is VT-x, and with Extended Page Tables, which is EPT. And the README states that DRAKVUF is not going to work on any other CPUs, such as AMD, or on Intel CPUs without the required virtualization extensions. That is a hard boundary, not a preference, and it is worth understanding why. The technique depends on being able to watch the guest from a privileged layer, and EPT is what makes the second level of page tables visible to that observer. Without both extensions, there is no mechanism to read the guest's state without going through the guest itself, which is exactly the thing the tool is designed to avoid. So the evaluation of DRAKVUF starts with the hardware, and if the machine you have is not an Intel one with those extensions, the rest of the documentation is not about your situation. The practical consequence for a lab is that the analysis host has to be a supported Intel machine, and since the analysis guest runs inside it, the host is also the thing whose hardware virtualisation has to be exposed to a hypervisor, which in practice means nested virtualisation on the machine that runs the hypervisor. The project publishes pre-built Debian packages of the latest builds in a separate builds repository, which saves you from building the whole stack for a first evaluation. ## Supported guests, and what tracing without an agent buys you The supported guests list is short and specific. Windows 7 to 8 in both 32 and 64-bit, Windows 10 64-bit, and Linux 2.6.x to 6.x in both 32 and 64-bit. That list is a fair description of the state of the tool. The Windows range covers the versions that malware specimens are still built for, and the Linux range reaches back far enough to run old distributions, which is the interesting direction for the analyst who has a sample from a compromised server running a long dead kernel. The tracing itself is the product, and it is worth being precise about what it means. Because the observer is outside the guest, the trace covers the whole system rather than a chosen process, and it includes the kernel. When DRAKVUF is used on a full operating system image, the trace is of everything the machine does, which is the difference between watching a process and watching a machine. The cost of the approach is the same property that gives it its value. Everything is mediated through the hypervisor layer, so the path from an event in the guest to an event in the trace is longer than it would be with an in-process tracer, and the data volume of a full system trace is large. A project that has to do this at scale, and to present the result to an analyst, is exactly what the graphical frontend in the next section is for. ## Malware analysis, and the limits of that framing The malware analysis section makes a strong claim, that DRAKVUF provides a perfect platform for stealthy malware analysis as its footprint is nearly undetectable from the malware's perspective. Nearly, not entirely, and the wording is careful. The observer is outside the guest, so there is no in-guest artefact to find, but the system is still a virtual machine, and a determined sample that checks for artefacts of virtualisation, or that looks for timing anomalies, or that inspects the hardware it is running on, can draw conclusions. The claim is that the footprint is small and hard to detect, not that the environment is indistinguishable from bare metal. That distinction is the honest core of the project, and it is also why the tool is not restricted to malware. The README says DRAKVUF has mainly been developed with malware analysis in mind, but is certainly not limited to that task, since it can be used to monitor the execution of anything that executes within a VM, including firmware, OS kernels and user-space processes. Firmware is the interesting case, because a sample that runs before any operating system exists cannot be observed by anything inside the machine. Kernel analysis benefits from the same trick, because a kernel component is far harder to hook from the inside than a user-space process. And user-space processes are the everyday case, where the advantage over a debugger is that the process is not told it is being watched. ## The graphical frontend lives in a separate project The README points to a companion project for the part of the workflow that needs a screen. If you would like a full-featured DRAKVUF GUI to set up as an automated analysis sandbox, the recommendation is the DRAKVUF Sandbox project, maintained by CERT Polska, which is a separate repository from this one. The split is a sensible division of labour. DRAKVUF is the engine, a system that needs a hypervisor, a processor with the right extensions and a guest image, and it produces traces. A sandbox needs a queue of jobs, a way to submit a sample, a way to show a result and a way to search through them, which is a user interface problem rather than a virtualisation one. So the adoption path is two projects, and it is worth noting that the second one is the one a non-specialist would actually interact with. The DRAKVUF repository gives you the tracing capability, and the sandbox gives you the workflow around it. The installation steps for the engine itself are not in the readme. They are on the project website, which is the arrangement the project has settled on for a tool whose setup depends on the hypervisor configuration. ## The build, the submodules and the release gap The repository layout shows a serious piece of infrastructure rather than a single tool. There are two build systems side by side, an autotools one with configure.ac, Makefile.am, autogen.sh and the m4 macro directory, and a meson one with meson.build and meson_options.txt. Having both is a sign of a project that is old enough to have accumulated the first and young enough to want the second, and the presence of autogen.sh means the autotools path still generates its configure script from a checkout. The subdirectories show what DRAKVUF actually depends on. There is a xen directory for the hypervisor side, a libvmi directory for the virtual machine introspection library, a dwarf2json directory for debug information, a volatility3 directory, and a src directory for the tool itself, with tools, scripts, a ci directory, a package directory for distribution and an llvm.ini configuration file. The style configuration is an astyle configuration file, which dates the code, and the licence situation has both a COPYING file and a LICENSE file, with the repository licence recorded as one that GitHub could not classify. The release history is where the project looks least current, and it is worth reading before you plan around it. The releases are 1.0 from December 2022, 0.8 from December 2021 and 0.7 from July 2020, so the last tagged release is nearly four years old, while the last push to the repository was on 2026-09-30. The work is continuing on the main branch and the tagged versions are not the whole story, and for a tool in this field that is a normal shape, because the interesting artefacts are the packages and the guest images rather than a version number. ## Conclusion Adopt DRAKVUF if you must analyse a sample that would detect an in-guest agent, or if you need to trace a whole operating system rather than a process, because the observation happens from the hypervisor and the guest has no way to notice it. Do not adopt it on AMD hardware or on an Intel CPU without the required virtualization extensions, because the README says plainly that it will not work there. Before you plan an analysis environment, check the supported guest list, since the coverage is Windows 7 through 10 and Linux 2.6 through 6.x, and budget for the hardware requirement of a machine with nested virtualization. ## FAQ ### What is DRAKVUF? It is a virtualization based, agentless black-box binary analysis system. It traces the execution of arbitrary binaries, including whole operating systems, by observing from the hypervisor layer, with nothing special installed inside the analysed virtual machine. ### What hardware does DRAKVUF need? An Intel CPU with virtualization support, which is VT-x, and with Extended Page Tables, which is EPT. The README states that it will not work on other CPUs such as AMD, or on Intel CPUs without the required virtualization extensions. ### Which operating systems can DRAKVUF analyse? Windows 7 to 8 in both 32 and 64-bit, Windows 10 64-bit, and Linux 2.6.x to 6.x in both 32 and 64-bit. Pre-built Debian packages of the latest builds are published in a separate builds repository. ### Is DRAKVUF only for malware analysis? No. The README says it has mainly been developed with malware analysis in mind, but that it can be used to monitor the execution of anything that executes within a virtual machine, including firmware, operating system kernels and user-space processes. For a graphical workflow there is a separate DRAKVUF Sandbox project from CERT Polska. ## Sources - [Issues](https://github.com/tklengyel/drakvuf/issues) - [Project website](https://drakvuf.com) - [README](https://github.com/tklengyel/drakvuf/blob/main/README.md) - [Releases](https://github.com/tklengyel/drakvuf/releases) - [tklengyel/drakvuf on GitHub](https://github.com/tklengyel/drakvuf) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tklengyel-drakvuf