I can’t understand this design. You should derive the disk’s encryption key from the user’s login password. You have a small, secure program that presents a login screen on boot. It takes the password you input and uses it to unlock the disk. It passes the username and password along to the OS so that it can take you right into your account after it boots.<p>As long as your encryption is decent, this makes it fundamentally impossible to read the drive from a turned-off state without knowing or cracking the password.
This is all correct, but it’s been fairly well known since over 15 years ago that BitLocker only really protects a computer if you configure BitLocker to require a pre-boot password, and also only after you turned off the computer [0].<p>[0] <a href="https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno" rel="nofollow">https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno</a>...
> Okay, so now we know how to edit a BCD file. But what do we put in there? This was the trickiest part of this exploit chain, as you get very little feedback when things go wrong. Recall the bug we are trying to reproduce: We want the bootloader to attempt to boot from our BitLocker partition, fail, and then trigger a PXE soft reboot into our controlled OS.<p>> The easiest way to get this working has three parts:<p>> Get the original BCD from the victim’s device. This ensures the configuration matches the specific partition GUIDs. You can do that by shift-rebooting Windows, going “Troubleshoot > Advanced options > Command Prompt”, mounting the boot partition, and copying its contents to a USB drive. Or, be more advanced and use an SMB mount, if you don’t have USB access.<p>Do I understand it correctly that to bypass the encryption you need access to the decrypted contents of the encrypted disk? Did the original exploit guess the layout of the partitions instead?
Video presentation at <a href="https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38c3-816-eng-Windows_BitLocker_Screwed_without_a_Screwdriver.mp4" rel="nofollow">https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38...</a>
TL;DR, like all secure-boot disk-encryption outrage-bait articles of late: if you're really concerned about any of this, set a TPM PIN and/or explicit disk encryption password.