dislocker: a FUSE driver for reading BitLocker volumes on Linux and macOS

A library underneath five binaries

dislocker is structured as a core library with several command line tools built on top of it, and the split is the fastest way to understand what each tool is for. dislocker-bek dissects a .bek file and prints information about it. dislocker-metadata prints information about a BitLocker encrypted volume. dislocker-find is not a binary at all but a Ruby script that looks for a BitLocker encrypted partition among the plugged in disks, and it only works if the library is compiled with the Ruby bindings. dislocker-file decrypts a volume into a flat file formatted as an NTFS partition. dislocker-fuse is the tool you reach when you call dislocker, and it decrypts dynamically through FUSE. The library is written in C, the project is driven by CMake with a CMakeLists.txt at the top level, and the source lives under src/ with headers under include/ and tests under test/. There is also a man/ directory, which matches the documentation's claim that usage details are in dislocker(1) once installed. The licence is GPL-2.0, which matters for how you redistribute a build, and the repository has no GitHub releases, so version tracking is through commits and a CHANGELOG.md.

dislocker-fuse exposes a virtual NTFS partition instead of a directory

The dynamic mode is the one that feels like a mount and behaves differently from it. You give dislocker-fuse a mount point, and once the keys are decrypted a file named dislocker-file appears inside it. That file is a virtual NTFS partition, so you mount it as any NTFS partition and then read from or write to it. The important detail is the write path: writing to the NTFS virtual file changes the underlying BitLocker partition's content. The FUSE approach is therefore not a read only view, it is a live mount of the decrypted volume, which makes it convenient for a triage workflow where you want to look at the files and then copy the ones you need without first writing out a full image. The same mechanism is what the fstab example relies on, since a BitLocker partition can be mounted through /etc/fstab using dislocker's long options.

/dev/sda2 /mnt/dislocker fuse.dislocker user-password=blah,nofail 0 0

The line has to be adapted for each case, and it assumes you already know the partition device path and the credential you are passing.

dislocker-file trades disk space for access speed

The other route is to decrypt once into a flat file and work with that. dislocker-file takes the encrypted partition as a command line argument and, when it finishes, produces a file that is an NTFS partition. The critical semantic difference from the FUSE mode is that the result has no link to the original BitLocker partition. If you write to the decrypted file, the BitLocker volume does not change, only the file does. That makes dislocker-file the safer option for evidence handling, where a working copy is wanted and the original must stay untouched. The costs are explicit. Creating the file can take a long time, since it depends on the size of the encrypted partition, and the tool needs disk space equal to the size of the volume being decrypted. Once the decryption is done, access to the NTFS partition is faster than the FUSE path. So the choice between the two binaries is a choice between live, writable, slower access and a one time, disk hungry, faster copy.

What the driver can read: AES modes and BitLocker-To-Go

The supported scope is spelled out. The driver reads Windows Vista, 7, 8, 8.1 and 10 encrypted partitions, which covers AES-CBC and AES-XTS at 128 or 256 bits, with or without the Elephant diffuser. It also handles BitLocker-To-Go encrypted partitions, the USB and FAT32 case. The BitLocker-To-Go layout is worth understanding because it explains a detail of the usage. On that media the data has a dual format: the partition is a valid FAT32 filesystem that stores executables and data files used to access the encrypted volume, and alongside those sit large files holding the actual encrypted volume. From the BitLocker point of view the FAT32 area is unused space. The practical consequence for the user is that dislocker treats the whole partition as the volume, so the way you invoke it is identical whether you are pointing at a standard BitLocker partition or a BitLocker-To-Go device. The documentation names the tested Windows versions explicitly, which is also a boundary: the tool is written against those layouts, and anything newer is outside what the README claims.

Building only the binary you need with CMake

The full build produces all five binaries, and the project lets you compile one of them by naming it as the makefile target. If you only want the FUSE binary, the build is two commands.

$ cmake .
$ make dislocker-fuse

That is the only build command shown in the project documentation, and it is worth knowing that the broader install story is split across two files. INSTALL.md covers the install process, BUILD.md covers building native packages for your operating system, and dislocker(1) covers usage once it is installed. macOS support is credited in the acknowledgements rather than described as a separate guide, so an OSX user follows the same INSTALL.md and BUILD.md path and can expect the details to be incomplete for that platform. The build is CMake based rather than a distribution package, so a Linux user on a mainstream distribution will either find it in the distribution repositories or follow INSTALL.md, and a native package for your OS is the route BUILD.md documents.

Where dislocker is the wrong tool

There are clear limits. dislocker is an offline access tool: it works on a volume you can point a device at, and it needs the keys, which in practice means the recovery key or the user password. It does not unlock a running Windows installation, and it does not help with a machine where you have neither the drive nor the key. The FUSE mode's write behaviour is a genuine hazard in the wrong hands, because writes to the virtual NTFS file reach the original partition, so for a forensic workflow where the original must remain unmodified, dislocker-file is the correct choice and the FUSE path should be avoided. The flat file route has its own hazard, which is disk space equal to the volume size, and that can be prohibitive for a large disk on a small machine. Finally, the supported operating system versions and the GPL-2.0 licence both narrow the audience. The GPL-2.0 terms govern redistribution and derivative works, and anyone embedding the library in a product needs to read the licence text rather than take the summary as sufficient. The project publishes no GitHub releases, so the source tree is the only artifact available.

Editorial conclusion

dislocker suits a forensic or migration workflow where you hold a BitLocker encrypted disk and the recovery key or user password, and you need the contents readable on a Linux or macOS machine without booting Windows. It does not suit live access to a running Windows installation, because the decryption is driven by keys the operator supplies, and it is not a good fit for a machine you are not authorised to open. Before you build it, read INSTALL.md for the install path and BUILD.md for native packages, and remember that the flat file route needs disk space equal to the size of the encrypted volume, and the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. Aorimn/dislocker on GitHub
2. Issues
3. License: GPL-2.0
4. README