Keishin Senzaki - 2026-09-06

I have implemented an experimental x64 UEFI bridge that allows a VeraCrypt system-encrypted Windows installation stored in a VHD file to boot through Ventoy's native Windows VHD boot path.

Source code, architecture documentation, and release:

https://github.com/reordo/EncryptedVhdBoot

This is related to the older request for system-encryption support for bootable image files:

https://sourceforge.net/p/veracrypt/discussion/features/thread/51daceaa/

In the tested configuration, VeraCrypt 1.26.29 displays an error as soon as System > Encrypt System Partition/Drive is opened from Windows natively booted from a VHD. The Windows system is therefore prepared and encrypted inside a UEFI VirtualBox VM. The resulting VHD can then be used both by the VM and, while the VM is shut down, as a native Ventoy-booted Windows system.

This is not a modification of the VeraCrypt installation or its normal EFI boot entry. It is a compatibility bridge for the early Ventoy/Windows VHD I/O path.

Implementation outline

  • The UEFI application loads the original Windows Boot Manager from the Ventoy Win10Based v3.0 image.
  • It validates the expected Boot Manager binary profile and replaces its relocated VHD1 read/write callbacks in memory.
  • VeraCrypt-compatible header and XTS code authenticate the system volume and transform early VHD reads, using the saved original VHD read callback as the raw backend.
  • The bridge intercepts Boot Manager's authenticated child-launch boundary.
  • It finds the VHD1 parser inside the loaded winload.efi using structural validation rather than a Windows version allowlist and replaces its read/write callbacks.
  • Encrypted pre-kernel VHD writes are rejected as write-protected.
  • The standard VeraCrypt BootArguments/BOOT_CRYPTO_HEADER handoff is provided to the Windows boot-start driver.
  • At ExitBootServices, the bridge wipes its expanded-key workspace and partial-sector buffer. Only the standard handoff page needed by veracrypt.sys remains; the Windows driver later validates, consumes, and burns it.
  • After kernel startup, the ordinary veracrypt.sys driver takes over the encrypted system disk.

The password and optional system PIM are entered in the bridge. The PIM is encoded using the same upper 16 bits of BootArguments.Flags used by VeraCrypt-DCS and the Windows driver.

End-to-end boot and driver handoff were tested with VeraCrypt 1.26.29 on:

  • Windows 10 Enterprise LTSC 2019 x64
  • Windows 10 1909, 21H2 and 22H2 Pro x64
  • Windows 11 25H2 Pro x64
  • fixed and dynamic VHD1 disks
  • default and custom PIM values
  • several cipher/cascade and PRF combinations

For Windows 11, BitLocker/device encryption had to be removed completely with manage-bde -off C: before starting VeraCrypt system encryption.

I would particularly appreciate technical feedback from VeraCrypt developers on:

  1. Whether the BootArguments construction and PIM flag handling match all current expectations of veracrypt.sys.
  2. Whether any additional pre-boot state should be preserved for the Windows driver beyond the standard boot crypto header.
  3. Whether wiping the private crypto workspace at ExitBootServices while retaining only the driver handoff block is the correct lifecycle.
  4. Whether there are cipher, PRF, system-encryption, or driver-version compatibility assumptions that should be validated more explicitly.
  5. Whether any part of this approach could be made more compatible with future VeraCrypt versions.

The project is unsigned, requires Secure Boot to be disabled, and has not received an independent security audit. It should currently be treated as experimental research and tested only with recoverable VHD copies.

The project is independent and is not presented as an official VeraCrypt feature. Any corrections or security concerns would be very welcome.