Decrypting BitLocker Drive on Fedora
# Decrypting BitLocker Drive on Fedora
So recently I went through a change of operating system where I moved from Windows 11 to Fedora 42.
I’d used Debian with GNOME on my laptop during university, but for some reason I went back to Windows using WSL. I had almost forgotten the difference in UX and performance. Memory-heavy IDE’s like Jetbrains Rider feels almost unusable on Windows in comparison.
After the transition I was embarrassed to find out that my auxiliary SSD drive was encrypted by Windows with BitLocker and I could not remember the passphrase.
Luckily, I had saved the recovery key in my password manager (Bitwarden ⬆️ ).
Now I had to find a way to decrypt the BitLocker-locked drive on my Fedora system.
First I tried a package called dislocker
, but that didn’t work well.
It actually segfaulted on me when I ran the command
Next, I found a thread that recommended using the program cryptsetup
. It usually comes with systems that have LUKS (Linux Unified Key Setup). This program shipped with an extension called bitlk
for working with BitLocker-encrypted partitions.
To prepare the open-command with bitlk
, I placed my recovery key in a plain file bitlocker.key
, making sure not to include any newline characters.
I used the older syntax to provide the key, open the encrypted drive and give it the name aux-drive
.
Then I proceeded to mount the resulting block device mapper file (placed in in /dev/mapper/
) like so:
This partially failed though, with this debug message:
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
Could not mount read-write, trying read-only
The command returned a 0
exit code and the mount point was accessible, but the filesystem was indeed read-only.
Thank god for the wizards that create systems software like the utilities in the ntfs-3g
package.
Using the ntfsfix
command, I could resolve this issue by running:
)
)
What now remained was to setup an auto mount routine so that the drive is available when I restart my system.
Looking at the previously mentioned article, I found the suggestion to do it like this.
- Get the partition’s PARTUUID with
sudo blkid -p /dev/<partition>
Should spit out something like:/dev/nvme1n1p2: VERSION="2" TYPE="BitLocker" USAGE="crypto" PART_ENTRY_SCHEME="gpt" PART_ENTRY_NAME="Basic data partition" PART_ENTRY_UUID="8a8b2d25-b0c9-420d-af56-4f2c414e1049" PART_ENTRY_TYPE="ebd0a0a2-b9e5-4433-87c0-68b6b72699c7" PART_ENTRY_NUMBER="2" PART_ENTRY_OFFSET="32768" PART_ENTRY_SIZE="3906994176" PART_ENTRY_DISK="259:4"
- Run
sudo nano /etc/crypttab
and add a line withaux-drive PARTUUID=<your_part_uuid_here> <path_to_key_file_here> bitlk
- Edit
/etc/fstab
adding a line/dev/mapper/aux-drive /mnt/aux-drive ntfs defaults,nofail
- Test with
sudo mount -a
However, I found that I’d actually want an entry that is more specific:
# Conclusion
Moral of the story, save your recovery keys!