Everything Umbra does.
Umbra is a type-1 hypervisor for AMD machines. It starts before Windows, rebuilds the firmware, the TPM, Secure Boot and the IOMMU in software, and hands every other device to Windows directly. This page lists everything it does, for people who use it and for developers who build on it.
Runs your Windows, as it is.
Umbra starts before Windows and boots the installation you already have, so your apps, files and accounts stay as they are. Nothing needs reinstalling or converting.
Your existing installation
Boots the Windows already on your drive, in place. No reinstall, no disk image, no migration, no second copy of anything.
Starts before Windows
Runs from its own firmware boot entry. Windows' own boot entry is never edited.
Fail-safe start
If the hypervisor ever fails to come up, the next boot goes straight to plain Windows. A bad start can't lock you out.
On or off in one click
Switch Umbra on or off for the next boot from the console or the command line. Neither changes anything about Windows.
Every core
Each logical processor gets its own virtual processor, one to one, up to 32. Windows numbers them the way it does on the bare board.
Nearly all of your memory
The machine's RAM goes to Windows apart from a small reserve for the hypervisor. On a 32 GB machine Windows sees about 31.5 GB.
A real clock
Windows reads true processor frequencies (Task Manager shows the real clock speed) and gets precise system timers.
Your hardware, as itself
Windows sees your board's own identity: its firmware tables, system information and processor layout. Drivers find the hardware they expect.
Normal power behaviour
Shut down turns the machine off and restart restarts it, exactly as Windows expects.
Rebuilt in software.
Umbra builds these parts of the machine for Windows itself. Windows gets the complete feature, and the physical part behind it stays out of reach.
UEFI firmware
A complete UEFI environment that starts fresh from its first instruction on every boot and hands over to the Windows boot manager.
Firmware variables
Its own variable store. Everything Windows reads or writes there stays in the virtual store and never reaches the board's flash.
TPM 2.0
A full TPM 2.0 that Windows reports as Ready. It covers RSA and elliptic-curve keys, sealing, attestation and PCRs. It reports the same manufacturer and firmware version as your board's own TPM.
Measured boot from the first instruction
Boot measurements start at the virtual firmware's first instruction and continue through the boot manager, so the PCR values come from a genuine boot chain.
A TPM that survives power-offs
Optional. The TPM's keys and state are kept sealed in a small private partition that Windows can't read. If that store can't be read at power-on, Windows gets no TPM. It never gets a different TPM in its place.
Secure Boot, enforced
On and enforced, using your board's own keys (PK, KEK, db, dbx). Windows reports Secure Boot as on, and every boot image is checked against those keys.
The boot drive
Your NVMe system drive sits behind a virtual controller that shows the drive's own model and serial number. Writes go to the real drive.
Fast storage
Up to 32 commands in flight at once, host-memory caching for DRAM-less drives, write-through when Windows asks for it, and honest flushes.
Survives a drive hang
If the drive stops answering, it is reset and the commands that were in flight are sent again. Windows sees a slow request instead of a failed one.
Virtual IOMMU
Windows gets DMA remapping it can depend on, so Kernel DMA Protection turns on. Device interrupts are remapped through it as well.
Interrupt controllers
Each core has its own virtual interrupt controller with hardware-accelerated delivery between cores.
Passed straight through.
Everything else belongs to Windows outright. It runs on its own drivers at native speed, with the IOMMU making sure each device can only reach Windows' memory.
Graphics card
Your GPU belongs to Windows with its normal drivers and full performance. A driver timeout and GPU reset recovers the way it does on the bare board.
USB
Keyboards, mice, controllers and everything else you plug in work through the machine's own USB controllers.
Audio and network
Sound and network adapters run on their own drivers.
Other drives
Second NVMe drives and other storage go straight to Windows.
Native interrupts
Device interrupts are delivered straight to the core, at the rates and latencies Windows gets on bare hardware.
Gaming-grade
High-refresh gaming at native frame rates, with VBS and memory integrity on.
Windows security, all on.
Windows' own virtualization-based security runs on top of Umbra, so you don't have to switch any of it off.
Hyper-V inside
Windows starts its own hypervisor on Umbra, and its System log records it as started.
VBS and memory integrity
Virtualization-based security and memory integrity (HVCI) run as they do on bare metal, Secure Kernel included.
Kernel DMA Protection
On, through the virtual IOMMU.
Shown bare metal
Hyper-V is shown the processor's virtualization as if it were the bare machine, and nothing tells it another hypervisor is underneath.
Secure Boot + TPM + VBS together
All three run at once, with the TPM measuring the boot and Secure Boot enforcing it.
What Windows can never reach.
Everything is denied unless Umbra allows it. If a protection can't be put in place, the feature it protects is turned off instead of left exposed.
Physical firmware variables
Windows has no path to the board's real UEFI variables. Its requests are never passed on to them.
The physical TPM
The board's TPM is invisible to Windows and can't be reached.
The hypervisor itself
Umbra's memory isn't mapped into Windows, and no device can reach it by DMA.
Device DMA
Every device is confined to Windows' own memory, and any device that isn't confined is blocked.
Registers, ports and MSRs
Only what Umbra explicitly provides is answered. Everything else is denied by default.
The sealed store
The TPM's saved state is encrypted and kept in a partition Windows can't read.
The control channel
Only programs the machine's owner has approved can talk to the hypervisor. See "Trusted programs" below.
Seen from below.
From underneath the kernel, the hypervisor can see and change the live machine. Users get this through the included tools and developers through the SDK. Nothing is loaded into Windows to do it.
Read any process
Read the memory of any process, kernel included. No handle is opened, no driver is loaded, and nothing in the target changes.
Write memory
Write wherever the target's own page tables allow writing. Shared code pages are never written.
Batched transfers
Many reads or writes in one call: over 1 GB/s bulk, and up to about 20,000 batches of 100 reads a second.
Physical memory
Read physical memory as Windows sees it. VBS-protected pages and the hypervisor stay out.
The system, listed
Processes, threads, the modules of any process, every loaded kernel driver, memory regions, and process details.
Address spaces
Find any process's page-table root from its ID, or sweep physical memory for it.
Real page permissions
See which pages the hardware actually lets run, read or write, not just what Windows' page tables say.
Execution watches
Learn which code ran on any page, in any process or the kernel, without stopping it. These are breakpoints that never pause the target, and a watch can follow a pointer.
Boot recorder
Records the next boot from its first driver: every driver load and unload, and every kernel callback registered for processes, threads, image loads and the registry, naming the driver whose code each one runs. It can also record while Windows is running.
The hypervisor's own log
Readable live and saved on every boot, so even a machine with no debug port has its diagnostics.
The toolkit, included.
Every tool reads through the hypervisor. They open in UMBRA's own windows, and most also run from the command line with JSON output.
Kratos
The reverse-engineering platform: disassembler, decompiler, debugger, graph view, an AI agent and MCP server, and Python scripting. With Umbra it gets a hypervisor backend that reads and writes the live machine and sets execution watches.
Lens
A memory viewer. Shows a process or the kernel as a tree of images, PE headers, sections and pages, with a hex view that shades each page by where it came from, a data inspector, and "follow the pointer".
Argus
A cross-view rootkit check that asks every question several ways and flags whatever disagrees. It covers hidden processes, threads and drivers, code that belongs to no module, hijacked callbacks and dispatch tables, registry, handle and file-system filter hooks, drivers whose code differs from the file on disk, and hidden network connections. Includes snapshots and comparisons.
Lynceus
YARA rules run over live memory, both processes and kernel drivers. Each region is scanned at its real address and images are seen whole, so the PE module works.
Mnemosyne
Physical memory acquisition. It writes a RAW image plus the metadata that Volatility 3 and MemProcFS need to start without a scan.
Charybdis
Dumps any module or kernel driver and rebuilds its imports, including tables that have been deliberately destroyed. Comes as a window and a scriptable CLI.
pe-sieve-hv
hasherezade's pe-sieve with every option, with each question about the target answered by the hypervisor.
Memory test harness
Exercises every hypervisor function against a live process and reports pass or fail.
UMBRA, the console.
Comes with every licence. It shows the state of the hypervisor and the machine at a glance and lets you change settings.
Overview
Whether the hypervisor is running, uptime, cores, activity and licence.
Security posture
VBS, memory integrity, Secure Boot, test signing and IOMMU / DMA protection, checked live.
Hardware report
Board, processor, TPM, drives and network adapters, as Windows sees them.
Applications
Opens every included tool in one window.
Trusted programs
Approve or revoke the programs allowed to use the hypervisor, either right away or confirmed at the next boot.
TPM persistence
Keep the TPM across power-offs, or not. One switch.
Boot recorder explorer
A timeline of each recorded boot with checklists, search, plain-language details, and JSON or CSV export.
Logs and diagnostics
The hypervisor's log live, a log folder for every boot, the driver log, and a one-click diagnostics export.
Boot control
The firmware boot order and the background agent service, both visible and controllable.
Tray
Lives in the tray. It can launch at sign-in and start minimized.
For developers and resellers.
Build on the hypervisor, or ship it inside your own product. Approved developers get the SDK and the reseller tools.
C SDK
One header and one DLL. The API stays stable across Umbra updates, so your binary keeps working.
Everything above, from code
Memory, physical memory, address spaces, system lists, page permissions, execution watches, the boot recorder, trust and the log.
Precise refusals
When the hypervisor declines a call, it says exactly why: not trusted, not elevated, foreign code in the process, and so on.
Activation from your product
Your product activates Umbra itself through a small agent. The key goes in on standard input and every answer comes back as JSON.
Command line
Status, sign-in, sign-out, enable, disable, diagnostics and version, each a single JSON reply.
Licence linking
Tie a customer's Umbra licence to your product's own key.
Reseller API
Issue, suspend, restore and revoke licences, and free their machines, from your own systems.
Your brand
A tray client in your name, logo and colours, configured from your panel.
Billing your way
Credit packs at 35–65% off retail, or a flat monthly plan.
On the bench, not yet shipped.
Built and on test machines now. Each one arrives in an update once it has run cleanly on real hardware.
- In testing
Write watches
Which instruction wrote to an address, and which driver it belongs to.
- In testing
IOCTL monitor
Which program sends which control code to which driver, captured live.
- In testing
Boot log on disk
The whole boot's log saved to the drive, for machines with no other way to read it.
- In testing
Driver latency
Interrupt and deferred-procedure time per driver, to find the one causing stutter.
What it runs on.
- Processor
- AMD, with AMD-V (SVM) and the IOMMU switched on in the BIOS
- Windows
- Windows 10 22H2 or Windows 11 25H2, 64-bit, booting in UEFI mode
- System drive
- NVMe
- Optional
- 128 MiB of free space after C: to keep the TPM across power-offs