DiskCryptor encrypts Windows system partitions, and shows its age in the bootloader
DiskCryptor Open Source full disk encryption tool
At a glance
- What is it?
- DiskCryptor is an open source full disk encryption tool for Windows, offering AES, Twofish and Serpent with pre-boot authentication and UEFI/GPT booting. It is a serious, license-clean option whose weak point is the fragility of its own boot chain in front of Windows updates.
- Who is it for?
- DiskCryptor fits anyone who needs transparent full disk encryption on Windows and refuses to accept a proprietary product for confidential data. It does not fit Linux or macOS users, and anyone unwilling to keep a recovery script for post-update boot failures.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A GPL full disk encryptor aimed squarely at Windows confidential data
DiskCryptor is an open source encryption solution that encrypts disk partitions, including the system partition, under a GNU GPLv3 license. The project positions this squarely against proprietary encryption software, arguing that most comparable products are closed and therefore unfit for protecting confidential data. That premise is the whole reason the project exists and still explains its shape: it is a Windows tool under a copyleft licence with a visible source tree, not a general purpose storage stack.
The feature set is aimed at people who want the volume mounted transparently once the system starts, while the disk itself stays encrypted at rest. Dynamic disks are supported, as are devices with large sector sizes, which matters for hardware RAID setups where a 4K-sector array is otherwise awkward to encrypt. External USB storage gets the same treatment, and encrypted CD and DVD images can be created.
The history explains the code layout. The project began as a replacement for DriveCrypt Plus Pack and PGP WDE, developed by a user who stopped working on it in 2014. The current maintainers continued from that point, and the repository still carries a directory named ntldr alongside DCrypt, DcsPkg, Installer, and Doc. The last push was on 2026-10-03, the same day as the v2.0.2 release, so this is not abandoned code, although release labels such as Build v2.0.1 show the version numbering carries internal build identifiers.
Transparent encryption with pre-boot authentication and key media
The mechanism DiskCryptor advertises is driver level transparency. Once a volume is mounted, files read from it come back decrypted and files written to it are encrypted on the way to the platter, with no per-file action from the user. The project also handles mounting automatically for disk partitions and external devices, so the encrypted container behaves like an ordinary volume once authentication has happened.
System partitions add the hard part. DiskCryptor supports encryption of a system partition with pre-boot authentication, meaning the credential is requested before the operating system loads. Alongside password entry, the project documents key files and the option to place the bootloader on external media, in which case the key media itself is what authenticates the machine. For a laptop whose disk may be removed and read elsewhere, that separation between the boot program and the key that grants access is the feature that matters most.
Cipher choice is explicit rather than automatic. AES, Twofish, and Serpent are supported, and the feature list calls out support for their combinations. Nothing in the project description explains how a combined cipher is configured, so the practical advice is to pick one primitive and treat the combination option as an advanced path you verify yourself. Performance claims ride on hardware acceleration rather than on cipher cleverness: AES New Instructions on recent Intel and AMD processors, and PadLock extensions on VIA parts, plus TRIM support so SSDs can discard blocks that encryption would otherwise report as in use.
Getting the build, and where to get it when there are no install steps
There is no install command to copy. The project pages point readers to the project homepage at diskcryptor.org rather than spelling out a package manager invocation, a checksum, or a silent installer switch. The repository itself carries an Installer directory and a DcsPkg directory, which tells you that builds ship as a packaged Windows installer and that the sources are laid out as a native Windows project rather than a cross platform one.
So the honest first use of DiskCryptor starts outside the source tree. Download the release build from the project site, install it on a machine whose data you can afford to lose, and only then point it at a real partition. Two things are worth checking early because the project pages are quiet about them: whether the installer registers a driver that survives a reboot into Windows 10 or 11, and whether your firmware exposes the boot path the tool expects.
The tool offers hot keys and an optional command-line interface alongside the graphical shell, which matters if you want to script mounting of an encrypted USB device on a kiosk or a shared workstation. The project pages do not enumerate the command-line flags, so treat the CLI as an area to explore in the running application rather than a documented interface you can script against today.
The bootloader chain breaks when Windows restores bootmgfw.efi
This is the part of DiskCryptor that will cost you an afternoon. In the configuration where the EFI firmware boots the Microsoft loader path rather than the DiskCryptor one, DiskCryptor replaces the Microsoft bootloader with its own. A Windows update can restore the original Microsoft file, and the result is a machine that drops straight into Windows recovery on the next restart.
The documented recovery path runs inside the Windows Recovery Environment. First boot into WinRE and open a Command Prompt, then mount the EFI system partition, which is done with the mountvol command shown further down, and write a small script that swaps the loader back.
The script goes into a new file named S:\EFI\DCS\fix_dcs.cmd with these contents:
cd \EFI\Microsoft\Boot
del bootmgfw_ms.vc.old
ren bootmgfw_ms.vc bootmgfw_ms.vc.old
ren bootmgfw.efi bootmgfw_ms.vc
copy ..\..\DCS\DcsBoot.efi bootmgfw.efiRun the script, or execute the commands one at a time, and reboot. The project is explicit that this can happen again after future Windows updates, and that keeping the script on hand is what makes the recovery quick. The permanent fix is a firmware change: correct the EFI boot order so the system boots the DiskCryptor loader directly instead of the Microsoft one. DiskCryptor also ships an MBR bootloader and is said to coexist with third party loaders such as LILO and GRUB, and the project added a UEFI/GPT bootloader for modern Windows.
Secure Boot through a SHIM and a custom MOK
DiskCryptor does answer the Secure Boot question rather than leaving it open. The answer is a SHIM mechanism with a custom machine owner key, and the project describes setup as simple and claims it works wherever Linux Secure Boot works. That is a narrow but useful statement: it says the implementation rides the same signed-shim chain that mainstream Linux distributions use, rather than relying on legacy BIOS behaviour or on disabling verification.
The trade-off sits in the word custom. Enrolling a machine owner key means the machine trusts a key your organisation holds, not one issued by a public vendor. That is the correct model for an internal certificate authority and a poor fit for a fleet you do not control. The project pages do not walk through key generation or enrolment step by step, so the operational detail of rotation and revocation has to come from the home page FAQ.
Read together with the bootloader section, the picture is coherent: DiskCryptor wants to own the pre-OS boot path, and the SHIM approach is how it does that on a machine with Secure Boot enabled. Expect to configure it once per machine, and expect to check the result after any firmware update.
Cases where DiskCryptor is the wrong tool
The clearest boundary is the platform. The project describes itself as updated for Windows 10 and 11 with a UEFI/GPT bootloader, and nothing in the project pages suggests a Linux, macOS, or BSD client. If you need one encrypted volume readable from several operating systems, DiskCryptor does not describe that scenario, and the boot chain it installs is Windows shaped.
The second limitation is operational. The tool intercepts the boot path of the operating system, and the project itself documents a recurring failure caused by an operating system update overwriting a file it depends on. That is a different maintenance profile from a tool that encrypts only data volumes and leaves the system partition untouched. Encrypting external USB storage alone avoids the pre-boot side entirely and is the lower risk way to start.
The third is measurement. The feature list claims efficiency comparable to a non-encrypted system and mentions hardware AES acceleration, but no numbers, no benchmark method, and no hardware configuration accompany those claims, so there is no basis for sizing throughput expectations from the project pages alone. Test on your own hardware with your own workload before signing off on it.
Finally, the project states a GPLv3 licence while the licence field for the repository itself shows no value, and the top level is a source tree rather than a packaged distribution. Licence terms of a fork or redistribution therefore need checking against the actual files you receive rather than a summary line.
Editorial conclusion
DiskCryptor fits anyone who needs transparent full disk encryption on Windows and refuses to accept a proprietary product for confidential data. It does not fit Linux or macOS users, and anyone unwilling to keep a recovery script for post-update boot failures. Before adopting it, verify that your EFI boot order points at the DiskCryptor bootloader rather than the Microsoft one, because that single setting decides whether a routine Windows update strands the machine in recovery.
Frequently asked questions
Is DiskCryptor still maintained if the last release was over a year ago?
The project states that it is still actively maintained, and that releases are infrequent because the software is mature and little ongoing development is required. The v2.0.2 release was published on 2026-10-03, the same date as the last push.
What should I do if a Windows update breaks the DiskCryptor bootloader?
Boot into the Windows Recovery Environment, open a Command Prompt, mount the EFI system partition with the mountvol command, and run a script that copies the DiskCryptor bootloader over the restored Microsoft one, then reboot. For a lasting fix, change the EFI boot order so the machine boots the DiskCryptor loader directly.
Does DiskCryptor support Secure Boot on modern Windows machines?
Yes. It uses a SHIM mechanism with a custom machine owner key, and the project says it works on the systems where Linux Secure Boot also works.
Which encryption algorithms does DiskCryptor offer?
AES, Twofish, and Serpent, including combinations of them. The project also lists hardware AES acceleration through AES New Instructions on recent Intel and AMD processors and PadLock extensions on VIA processors, plus TRIM support for SSDs.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/diskcryptor-diskcryptor)Was this useful?