Booting a VeraCrypt-encrypted Windows VHD through Ventoy

Keishin Senzaki — Sat, 03 Oct 2026 04:47:53 +0000

I often use Ventoy as a multiboot USB drive: installer ISOs, live systems, recovery tools. Discovering its Windows VHD boot plugin suggested another use for it. Instead of giving every Windows installation its own set of partitions, I could put one in a VHD file, set it up in VirtualBox while another OS was running, and later boot that same installation directly on physical hardware through Ventoy. Replacing a system could then mean preparing a new file instead of repartitioning the drive.

I also encrypt the systems and data I use with VeraCrypt. I wanted the flexibility of a VHD file and direct hardware boot without giving up system encryption. My first attempt was to boot an ordinary Windows VHD through Ventoy and turn on VeraCrypt system encryption there. The encryption wizard failed in that native-VHD setup. I then encrypted the Windows installation inside its UEFI VirtualBox VM. It booted in the VM, but Ventoy's VHD boot path could no longer start it.

That led me to build EncryptedVhdBoot, an experimental x64 UEFI bridge. It authenticates the encrypted volume, decrypts the VHD reads needed before Windows starts, and passes VeraCrypt's standard boot state to veracrypt.sys.

The bridge hooks VHD parser callbacks in two Windows boot applications, with a third hook at the point where Boot Manager starts Winload. The VHD and Microsoft's boot files stay unchanged on disk. Below is how those hooks fit into the boot path.

The visible password prompt during a physical x64 UEFI boot. The entered characters are masked.

Why the normal boot paths do not meet

Ventoy's Windows VHD boot image starts a Microsoft Boot Manager that knows how to open VHD files. For an unencrypted Windows VHD, Boot Manager reads the virtual disk, launches winload.efi, and Windows continues.

An encrypted VHD creates two separate obstacles. In the tested configuration, VeraCrypt 1.26.29 reports an error when System > Encrypt System Partition/Drive is opened from Windows already running by native VHD boot, so the system has to be encrypted inside the VM. Once it is encrypted, Ventoy can still open the VHD file, but Boot Manager and Winload receive ciphertext from their VHD parsers before the Windows VeraCrypt driver can take over.

Here is the path the bridge creates:

Ventoy selects a Windows VHD
  -> EncryptedVhdBoot UEFI application
     -> original Windows Boot Manager
        -> VHD1 read callback: read ciphertext, return plaintext
        -> launch winload.efi
           -> its own VHD1 read callback: return plaintext
           -> Windows kernel and boot-start drivers
              -> veracrypt.sys takes over encrypted disk I/O

The word own matters: patching Boot Manager's VHD reader alone is insufficient. winload.efi has a separate VHD1 parser and continues reading the disk after Boot Manager launches it.

Intercepting virtual-disk reads

The supported Ventoy input is the official Win10Based v3.0 ventoy_vhdboot.img. Its UEFI boot image contains a specific 64-bit Windows Boot Manager build, version 10.0.10240.16384. Microsoft public symbols and the PE layout let me identify its Vhd1Parser table. The bridge loads the original Boot Manager, locates the table at RVA 0x2CF8, validates all four original table entries (Open, Close, Read, and Write) against that build, then replaces the relocated read and write pointers in RAM:

mOriginalVhdRead  = (EVB_VHD_IO)mVhd1Parser[EVB_VHD_READ_INDEX];
mOriginalVhdWrite = (EVB_VHD_IO)mVhd1Parser[EVB_VHD_WRITE_INDEX];

mVhd1Parser[EVB_VHD_READ_INDEX]  = (UINTN)EvbVhdReadPassThrough;
mVhd1Parser[EVB_VHD_WRITE_INDEX] = (UINTN)EvbVhdWritePassThrough;
MemoryFence ();

These are the actual callback assignments in EvbPreloader.c. The original callbacks remain available to the bridge; no VHD routine is copied or permanently rewritten.

Why work at this level? The VHD parser has already translated file layout into offsets on the virtual disk. A fixed VHD and a dynamic VHD store their bytes differently in the host file, but the parser presents the same disk-offset view to its callers. That gives the decryption code a useful boundary: it can reason about VeraCrypt sectors without reimplementing Ventoy's VHD file handling.

The Boot Manager wrapper first calls the saved original VhdRead. On its first successful read it authenticates the VeraCrypt header, or takes the plain-VHD path if the password is empty. For an encrypted read, EvbVeraCryptDecryptRead limits the transformation to the encrypted region:

IntersectStart = (ByteOffset > mEncryptedStart) ? ByteOffset : mEncryptedStart;
IntersectEnd   = (ReadEnd < mEncryptedEnd) ? ReadEnd : mEncryptedEnd;
if (IntersectStart >= IntersectEnd) {
  return EFI_SUCCESS;
}

An aligned interior can be decrypted in place, using the virtual-disk sector number as the XTS data-unit number. For an unaligned edge, the code rereads the whole sector through the original callback, decrypts it in a scratch buffer, and copies back only the requested span. This preserves bytes outside the encrypted area. Early writes to an encrypted VHD are rejected as write-protected. The bridge does not attempt to implement encrypted writes during the pre-kernel phase. With an empty password, it leaves the ordinary unencrypted-VHD read and write behavior in place.

Finding the second parser

Boot Manager's parser is tied to one validated binary profile. For winload.efi, a version-only allowlist would be brittle: Windows 10 and 11 ship many builds, and the VHD parser's address moves.

Instead, the bridge patches Boot Manager's ImgArchEfiStartBootApplication entry point at RVA 0x6B468 after validating its expected 15-byte prologue. The patch redirects control to EvbStartBootApplication. A trampoline preserves the overwritten instructions and lets that wrapper call the original function:

CopyMem (
  Trampoline,
  mBootApplicationHookOriginal,
  EVB_BOOT_APP_HOOK_SIZE
);
EvbWriteAbsoluteJump (
  Trampoline + EVB_BOOT_APP_HOOK_SIZE,
  (UINTN)(mBootApplicationHookTarget + EVB_BOOT_APP_HOOK_SIZE)
);

EvbWriteAbsoluteJump (
  mBootApplicationHookTarget,
  (UINTN)EvbStartBootApplication
);

The jump uses an indirect RIP-relative x64 encoding that preserves registers. This boundary is reached after Boot Manager has loaded and authenticated the child boot application, but before it starts running.

At that point, the bridge scans the loaded Winload PE image for a VHD1 parser table. The scanner considers initialized, readable, non-executable sections. Its decisive checks include:

if ((Candidate[EVB_VHD_WRITE_INDEX] !=
     (Candidate[EVB_VHD_READ_INDEX] + EVB_VHD_WRAPPER_SIZE)) ||
    !EvbMatchesVhdWrapperPair (&Image, Candidate[EVB_VHD_READ_INDEX]) ||
    !EvbRangeInSection (&Image, Candidate[EVB_VHD_OPEN_INDEX], 1, TRUE) ||
    !EvbRangeInSection (&Image, Candidate[EVB_VHD_CLOSE_INDEX], 1, TRUE))
{
  continue;
}

if (Match != NULL) {
  return NULL;
}
Match = Candidate;

The read and write wrappers must have the validated instruction shapes and sit 48 bytes apart; the Open and Close targets must be executable. A second candidate makes the result ambiguous, so the scan returns no match.

Only after finding that unique table does the bridge replace Winload's own callbacks:

mOriginalWinloadVhdRead   = (EVB_VHD_IO)Parser[EVB_VHD_READ_INDEX];
mOriginalWinloadVhdWrite  = (EVB_VHD_IO)Parser[EVB_VHD_WRITE_INDEX];
Parser[EVB_VHD_READ_INDEX]  = (UINTN)EvbWinloadVhdRead;
Parser[EVB_VHD_WRITE_INDEX] = (UINTN)EvbWinloadVhdWrite;
MemoryFence ();

The Winload read wrapper calls its original callback and decrypts the returned sectors. If the encrypted path is active and a suitable parser cannot be identified unambiguously, the child launch is aborted. The bridge does not guess an address or let Winload continue reading ciphertext.

This is still a compatibility technique, not a promise that every future Windows build will match. The project records the tested versions and the structural checks in its architecture notes.

From password to Windows driver

On the first Boot Manager VHD read, the bridge can use the saved original callback to read the virtual disk's MBR and VeraCrypt system header. It asks for a password and an optional system PIM, then uses VeraCrypt-compatible header and crypto code to authenticate the volume. After header authentication, it checks that decrypting the first encrypted sector produces the expected NTFS signature before allowing the boot to proceed.

The bridge also prepares VeraCrypt's standard BootArguments and BOOT_CRYPTO_HEADER handoff. The relevant part of EvbPrepareBootParams shows what goes into that handoff:

Args->CryptoInfoOffset = (UINT16)OFFSET_OF (EVB_BOOT_PARAMS, BootCryptoInfo);
CopyMem (&Args->BootPassword, VcPassword, sizeof (Args->BootPassword));
Args->Flags = (UINT32)Pim << 16;
CopyMem (&Args->BootDriveSignature,
         Mbr + EVB_MBR_SIGNATURE_OFFSET,
         sizeof (Args->BootDriveSignature));

The PIM uses the upper 16 bits of BootArguments.Flags, matching VeraCrypt-DCS and the Windows driver. The full handoff includes lengths, CRCs, and crypto-header fields; the excerpt highlights the password, disk signature, and PIM. The boot-start veracrypt.sys driver receives the state it needs when firmware services are gone.

At ExitBootServices, the bridge wipes its private expanded-key workspace and partial-sector buffer. It retains the handoff block needed by veracrypt.sys; the driver later validates, consumes, and burns that block. Once Windows is running, normal encrypted-disk operation belongs to the VeraCrypt driver, not the UEFI bridge.

Building and using the image

The project builds a replacement ventoy_vhdboot.img from the verified upstream Win10Based v3.0 image. The original Boot Manager remains in the image; the new UEFI entry point loads it, installs the in-memory hooks, and starts it. The builder also preserves an easy-to-miss detail of the original ISO: its BIOS and UEFI BCD paths share one physical extent. Ventoy patches one path in memory, and the UEFI path must see the same bytes. Making independent BCD copies breaks boot.

For an encrypted system disk, the tested preparation path is:

Install Windows in an x64 UEFI VirtualBox machine whose system disk is a fixed or dynamic VHD1.
Complete VeraCrypt system encryption and its pretest inside the VM. On Windows 11, fully remove BitLocker or device encryption first.
Shut down the VM, keep a recoverable copy of the VHD, and put the VHD on the Ventoy data partition.
Install the derived vhdboot image and select the VHD from Ventoy in x64 UEFI mode.

For Windows 11, open an elevated Command Prompt inside the VM before enabling VeraCrypt system encryption:

manage-bde -off C:
manage-bde -status C:

Wait until manage-bde -status shows Conversion Status: Fully Decrypted and Percentage Encrypted: 0.0%. Protection Status: Protection Off alone does not mean decryption has finished.

The repository's README has the exact build, install, restore, and preparation commands. An empty password takes the original unencrypted-VHD path, so the same image can still boot ordinary VHDs.

There is also an optional /ventoy/ventoy_vhdboot.silent marker file. When it is present beside ventoy_vhdboot.img, the bridge clears its screen and accepts password and PIM input without showing its own prompts, characters, masking symbols, or status text. This affects only output from the bridge; Ventoy, firmware, and Windows can still display their own interfaces. It is a display option, not a claim of stronger encryption.

What has been tested, and what has not

End-to-end boot and driver handoff have been tested with VeraCrypt 1.26.29 on Windows 10 LTSC 2019, 1909, 21H2, and 22H2, and Windows 11 25H2. The tests include fixed and dynamic VHD1 files, default and custom PIM values, and several cipher and PRF combinations. The compatibility matrix gives the exact Winload versions and results.

The current release requires x64 UEFI with Secure Boot disabled and the specified Ventoy vhdboot image. VHDX, differencing VHDs, Legacy BIOS, arbitrary Boot Manager builds, hidden systems, and rescue workflows are outside the supported scope. The project has not received an independent security audit. Boot tests demonstrate compatibility in the listed setups; they do not certify the security of the bridge.

The code and detailed design are available in the repository. I would especially welcome review of the VeraCrypt driver handoff, the Winload parser validation, and the lifetime of sensitive boot state. This is an independent project and is not affiliated with or endorsed by Ventoy, VeraCrypt, or Microsoft.

Disclosure: This article was drafted with AI assistance. Its technical descriptions were checked against the project's source code and documentation.