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/crypttaband add a line withaux-drive PARTUUID=<your_part_uuid_here> <path_to_key_file_here> bitlk - Edit
/etc/fstabadding 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!