Dumping Memory to Bypass BitLocker on Windows 11
noinitrd.github.io
noinitrd.github.io
Now I've been trying for months to do the same for Linux. There's systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm trying to encrypt a few sensitive directories on a super slow internal eMMC with fscrypt (keys for secure boot and /home). The TPM is _EXTREMELY_ hard to code for when things go beyond the basics:
1. Bind to PCR 7
2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated)
3. Use a PIN - but not the AuthValue, because I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually.
4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub.
Maybe this isn't the right place to ask, but there's almost nothing but basic TPM guides out there, so if you're an expert I could really use your help. It's just for a personal project, but I'll write about it once I'm done - if I ever figure it out!
Surely there must be a backdoor access for three letter agencies to just download all the pins and passwords and then take a dip in the data, no worries.
TPM is one piece of a larger puzzle and provides a middle ground where among other things you can get full disk encryption without needing to input a memorized key on every boot.
"successful open source encryption software" don't solve the main usability problem with encryption: "Where do I store my super secure 4096-bit private key so it's both secure and convenient to use"
It'd be similar to secure boot: usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.
> usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.
You can control what's your TPM. That's how they work today. Sure their software isn't "open source" but there aren't that many 100% "open source hardware" options around. If you want to be able to flash it, build your own HSM. I don't know if there is a market for a prebuilt microcontroller with something like picokeys preinstalled. I know that the market for "open" hardware is tough.
The main advantage of the TPM is how it is made physically. It should be designed to make it hard or impossible to read the secrets out of it and those things depends on how the components are manufactured on the silicon wafer.
Maybe the manufacturing process could be published, but I don't think it would help much.
You could probably write your own TPM emulator or modify swtpm a bit and compile it to any microcontroller, but in that case the chip could be easily decapped to make all the secrets readable.
They’re built from essentially the same secure MCUs as traditional TPMs and both the hardware and the proprietary crypto libraries used on them have been exploited many times over.
If you know how the lock is built, you can rule out existence of master key for instance. You don't know if your TPM chip has API where three letter agency can just download the keys from it. You are in the dark.
Same with cryptography, you can choose the method, just like you can choose type of lock. There are locks that have not yet been picked, but you can use a hammer, similar with cryptography - you can use quantum computer etc.
https://en.wikipedia.org/wiki/Secure_cryptoprocessor#Feature...
These things make it harder to break into the internals of the chip regardless of they being kept secret, so I wouldn't call it security by obscurity. I'm not even sure you can apply that principle to physical security.
The TPM emulation offers a full TPM implementation in software, for providing TPM functionality to a virtual machine when the host doesn't have one (or, when the TPM needs to be virtualized for other reasons, e.g. migration).
This type of /r/ufos|/r/aliens speculation isn't particularly useful. It comes with no evidence of TPMs being backdoor'ed. Have they been compromised [at least pre-2.0]? Yes, in as much as Apple's Secure Enclave has as an example.
Gut feelings aren't always correct and for topics which have a sort of 'correctness' about them, they're not useful.
Otherwise we're debating to prove a negative.
The government is also pretty silent about AES. Does it mean that's backdoored as well? More to the point, I'm not sure what the proposed alternative is. Not using TPM, and exposing yourself to bootkits and evil maid attacks?
This is what I actually do. I also store the OS kernel on the USB memory and I boot from there, with the root file system set to mount an internal SSD. The SSDs in the computer are completely encrypted with such long "super secure" keys (distinct for each SSD and selected automatically based on their serial number), and they do not store any information about the keys.
I have used this system for years and I find it very convenient. My computers cannot be booted without inserting the bootable USB memory and also giving the correct password. I have multiple bootable keys stored in different places, for the case when one becomes defective or lost.
TPMs work great against things like common thieves and probably corporate espionage, if set up well. When implemented well, they provide no additional friction (except for having to store a recovery key somewhere) but all the security against a laptop being stolen at the airport you could wish for.
Their main purpose is to generate and store keys that cannot leave the device, instead performing signing operations as needed internally and only returning the result, and only if attestation passed. This is a lot better than just having private keys on disk.
People just forget that security isn't absolute, and each solution has a threat model it is appropriate for. In case of full disk encryption, neither a TPM nor user input can protect against evil maid on its own for example - the TPM will unlock for anyone, while user input might be collected by a modified and malicious bootloader. Having both, however, works well.
"TPM" is a bit dated as a term as it's all directly built into the processor nowadays, including for smartphones and such. Another modern feature in that catalogue is memory encryption, which rules out the attack described by OP as the rebooted machine would be unable to read old memory content.
This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate it.
You can then go further up the chain with a UEFI settings password and no usb booting. If the password is hard to decrypt, then that's a pretty good approach.
Then there's custom Secure Boot certificates that replaces the ones from MS. It'll work for Linux, not sure about BitLocker. But my Surface tablet doesn't even support custom sb certs.
Having said that a number of laptops can still be opened without being powered-off if you do it carefully.
> Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.
https://support.microsoft.com/en-us/topic/september-24-2019-...
https://threadreaderapp.com/thread/1059435094421712896.html
This is amazing.
> The encrypted SSD has a master password that’s set to “”
HN discussion here: https://news.ycombinator.com/item?id=18382975
Original paper here: https://cs.ru.nl/~cmeijer/publications/Self_Encrypting_Decep...
If the TPM doesn't have a PIN, this attack works even if the attacker obtains the system when it's powered off. They can start the computer, proceed to the Windows logon screen (that they can't get past and that hence prevents them from exfiltrating data from the running system), then just reset the computer and perform this attack to obtain the encryption key. This obviously doesn't work if the PIN prevents Windows from ever even starting.
Even on Win11 it's still possible to do the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot), from there you can change account passwords at will.
Can you elaborate on this?
Avoid GRUB, difficult to secure with it.
Kernel updates will also be painful…
GRUB and all other boot loaders are unecessary with UEFI. See my comment history for more.
Kernel updates + Secure Boot is easy with a Debian hook.
The hard part is making it work with TPM when you want to add encryption...
Say that you have disabled usb booting and secured UEFI settings with a password. If you extract the cpu (and thereby its tpm) and the disk, then you'd still be able to boot, right? Meaning that without a TPM pin, you'd be able to do OP's attack on a different motherboard even when the original machine was off and UEFI settings secured.
What am I missing? Is it that easy to circumvent UEFI settings protection and maintain the PCR 7 value?
[1] https://blog.scrt.ch/2023/09/15/a-deep-dive-into-tpm-based-b...
So I really doubt TPM will release the keys on a different motherboard with different UEFI settings.
User changed motherboard and TPM complains: https://old.reddit.com/r/pcmasterrace/comments/vdvni1/swappe...
> PCR 7 changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) are updated. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR. — https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...
It makes sense to use the certificates to generate PCR 7. I wonder if you can swap out the motherboard with one of the same model with the same certificates without modifying the PCR 7 digest...
But if Shim actually modifies the digest, I guess that SB would completely mitigate OP's exploit since the TPM policy is going to fail when the PCR 7 values doesn't match.
If you have to put a password in before boot that needs to be combined with the TPM key to unlock the drive, it would help in scenarios where a TPM key can be found later.
I’m not sure how much anything helps against this attack though. Retrieving data from RAM in this way should work for most scenarios by changing where you look for the key (as it needs to be held somewhere by the OS to maintain read/write access to the drive).
I would assume Apple devices aren’t vulnerable to this type of attack as IIRC the keys never exit the enclave. Maybe TPM 3.0 needs to look a lot more like that.
Bitlocker already does this if you use a PIN/password.
If Bitlocker PIN is split key then yes that would be ideal, but I think you can change the PIN without re-encryption (which implies it's challenge/response).
LUKS has multiple "key slots" so IIRC you can use one slot for TPM unlock, and a different one for long password unlock.
Have you considered using that as your recovery mechanism?
> It's just for a personal project,
One of the reasons very few hobbyists touch the open source TPM stuff is there are a number of alternatives that scratch similar itches much more easily.
Need to protect a crucial encryption key by locking it up in hardware? Buy a Yubikey.
Disk encryption password on your laptop is inconvenient? Just use standby when you close the lid instead of powering off fully. Login password is inconvenient? Fingerprint reader, or biometric yubikey.
Unattended kiosk, school computer lab or similar that needs to boot without a password? Just put it in a sturdy metal box and chain it to the wall.
Server in a data centre that needs to boot unattended? Move to a data centre with physical security you can trust. Still worried? Dropbear or Tang so it has to be on the right network before it'll boot.
Home lab hobbyist, working with the TPM for fun? Assess whether you're actually having fun working with the TPM, and you'll probably notice you're not.
A power-on password (set in the BIOS) should also work, since without it the system will never get to the point where the TPM unlocks the FVEK, right?
I prefer this setup to a Bitlocker PIN because I can use a fingerprint instead of the power-on password on my Thinkpad, and because it should make the device largely unusable to a thief.
Of course, power-on password and fingerprint auth are only as strong as my TPM, but the same goes for Bitlocker TPM+PIN, right?
So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless.
With LUKS it at least has a password prompt to unlock the drive.
It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around.
> With LUKS it at least has a password prompt to unlock the drive.
Configuration dependent. You can set up Linux to do the same thing as Windows here (I have my home video-security server set up this way, as it needs to reboot silently - I know that I'm vulnerable to warm/coldboot attack and software attack surface, but at least if someone yoinks the drive I'm safe), and Windows can also be configured to prompt for a password or use PIN-authenticated TPM sealed keys.
> Fundamentally I don't understand BitLocker's security model.
Minus the parameter encryption / bus-sniffing issue, it moves the boundary from "anyone can read your drive" to "someone needs to either perform a platform-level attack to access the contents of memory, or hack whatever services are running at the login screen to read your drive." It's a decent security improvement, actually, because it protects very well against stuff like "someone stole our financial data off of a random recycled hard drive."
AFAIK it is useless, there is no way the TPM could authenticate the CPU. You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.
Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU and probing the signals in the chip is probably outsider of the budget of TikTok influencers.
At an enormous cost of having to remember and enter a PIN - not practical for corporate IT due to the propensity for forgetting and not practical for offline server use.
> Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU
On AMD this is almost 100% prevalent, yes.
On Intel platforms a physical TPM is still common and PTT (firmware TPM) is usually disabled by default for some reason - a user/manager would usually have to re-select it in the BIOS. On desktop platforms I think PTT runs externally in the PCH, too, which is off-package and connected over DMI (I think on most mobile parts PCH is a separate on-package die). I don't think anyone has done research on how the fTPM part of PCH <-> CPU comms work on modern Intel platforms; this has always seemed like a fun topic for a deep dive and talk to me, but I've never had the time.
I don't think either of these things excuses the lack of encrypted parameter support from BitLocker, though. I'd love to know why Microsoft continue not to use it. The only reason I've ever seen given is "it was deemed too complex / has an attack surface," which is an interesting idea but quite bunk when UEFI is already in the picture IMO.
It would be unusual for any current device to have a discrete TPM, at least in the consumer space given current x86 processors have an fTPM.
The disk PIN on boot is uncommon/harder to do for home users, but it's a common setup in the corpo world. Enforced by AD, or Intune.
The disk password actually encrypts the disk, so you can't just pull the disk out and read it, or boot Linux from a flash drive and read it.
You can do the above attacks when all that's set is a Windows password. In fact, you could even modify the OS at that point so it logs and exfiltrates passwords in the future.
Yes, it's the same kind of useless.
This isn't true for all implementations of TPM, but for AMD/Intel/Qualcomm where BitLocker is relevant, fTPM is used.
Where it states: Module dTPM 2.0 (Discrete Trusted Platform Module)
Same for HP EliteBook and ProBooks: https://h20195.www2.hp.com/v2/GetPDF.aspx/c08049273.pdf
"Useless" is grossly incorrect. Bitlocker is not invincible, but it lowers your threat surface by a huge %.
In real terms: if i get your unbitlockered hard drive, i own your shit. It's not a hack you pay crypto for on the dark web, it's a trivial compromise that every person in IT has known for at least a decade. If you google it, you'll find it. Ring 0 access to all nonbitlockered windows installs. Takes like 2 minutes and a usb or cd.
With bitlocker, at least every idiot on the planet can't login to your profile; that's not nothing
In modern CPUs, the TPM is built directly into the CPU, so you can't do this.
Yes, but the idea is that from the login screen (winlogon) you really can't do much unless you actually have account credentials on the computer - or are bio-metrically enrolled into the computer* - and if you attempt to reboot to safe mode, or reboot to a different OS (or firmware update utility, etc) you do need to enter the Bitlocker recovery key.
* I'm not sure how it works in terms of "hacking" fingerprint sensors or face recognition webcams.
Keyword is powered off.
With any general purpose drive encryption, the TPM doesn't actually decrypt the bulk of the data as its too slow so the OS eventually ends up with a key that is extractable.
In Pro editions it is also possible to require an interactive step at boot time via group policy (this also works if you have no TPM available), then it will ask for a password on each startup.
It was my understanding that veracrypt was considered more tested than bitlocker due to the lack of backdoors or workarounds. Can anoyone point me at some good resources regarding this?
BitLocker should ideally be used with a PIN/password too. This means the key isn't decrypted until the correct PIN is entered. No SPI sniffing, UEFI exploits, or memory dump would help the attacker in this preboot state. BitLocker with TPM and PIN is a pretty powerful combination.
But by default, without any second factor, BitLocker is two parts convenience and one part security. Probably the price of user adoption.
That'd bring them to a login screen. Without your password or biometrics, they're not getting past that. They'll have to figure out some kind of workaround (like a RCE exploit, or booting an old, vulnerable Windows bootloader somehow) because they can't do the usual "replace the software keyboard with cmd.exe" workaround as the drive remains locked.
Without Bitlocker, you can plug a Windows drive into your PC and browse all the files. With Bitlocker, you need to faff about with exploits and vulnerable Microsoft software and dumped memory, and even that doesn't always work.
With Bitlocker configured in TPM+PIN mode, you can't even do that, as you don't have the password to unlock the TPM. You could also put Bitlocker in password-only mode, but that's much easier to brute-force. Same goes for LUKS, by the way, which also supports TPM and TPM+PIN in most Linux distros these days.
If someone steals the device and removes the drive the data is encrypted.
If someone steals the device and powers it on, the os that wrote the encrypted data (and is presumably secured) can enforce login authorization which the thieves presumably cannot bypass.
Both of these are big ifs, but the installed os won’t just divulge the contents of the disk so the trick is locking down the disk so that it’s easy for the installed os to access but becomes useless if the disk is removed from the computer.
All of this depends on the TPM implementation not being trash, which integrated instances help with. Ultimately this is a trade off for convenience. I don’t worry about random thieves probing the buses in my computer to get my tax info, so I don’t use luks’ other stuff.
https://techdirectarchive.com/2023/10/08/how-to-enable-a-pre...
It isn't enabled by default likely because it makes updates more of a manual process and they decided timely updates were a more important attack surface
Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
Theoretically no, but realistically I doubt even intel agencies can pull this off.
> Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though.
> In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
This already exists: it's the MOR bit and it's supposed to be in play here.
I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.
Having it only inside the cache SRAM mitigates all the offline attacks. SRAM immediately loses content on power disruption (its state is encoded in the current path, not in a capacitor charge). And it's trivial to completely and unconditionally erase on boot.
"BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory."
I would extremely not trust most platform implementation of TCG Reset Attack Mitigation, though. I've never seen a UEFI platform that is even close to correctly implemented in any form. It would be interesting to know which platform this researcher was working with, and whether it purports to support the MOR bit or not.
(Edit: No this is a UEFI request to clear memory. Below is incorrect.)
I don't think this is what the commenter was mentioning. I think this essentially makes it only possible to extract the key from the TPM once and then the TPM needs to be powered off and back on to get it again.
The TPM has no control over whats in the system memory, so if they key is in system memory, no TPM mitigations are going to help.
UEFI firmware must support clearing the keys from RAM.
The naming there is definitely confusing. Particularly as it sounds like a key attribute bit.
The real mitigation is the memory encryption feature of modern CPUs. Being on-die means tweezers won't reach, and being just a key means the wipe is instant and very difficult to mess with even if it survived a power cycle.
I'm surprised given that the article mentions stepping into the boot process and `SymCryptSessionDestroy` that they didn't look more deeply into this; it's not how I really intended to spend my new years but I might have a new debugging project now...
I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets.
Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...
What if Windows forgot to wipe a spot after having relocated a page? What happens if the firmware's boot flow is interrupted by, say, a hardware fault prompt, a low battery prompt, etc.? There's a lot of places where that approach can go wrong.
The key approach is simpler and comparatively bullet proof: If the machine is rebooted, clean or not, the key will be lost and no memory that was previously used will be readable. All it takes is the OS initializing a single CPU feature on boot, with the only downside being that it requires support for a quite modern CPU feature.
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
Both Intel and AMD are working on embedding this into their CPUs.
However, the target use appears to be servers with multiple VMs, not laptops.
https://techcommunity.microsoft.com/blog/windowsosplatform/m...
Memory compression has been around for ages, at least since Windows 10 RTM. All major operating systems have implemented this feature -- it has no relation to security, though.
That said, previous side-channel attacks on CPUs have shown it possible to attack encrypted memory (https://www.usenix.org/conference/usenixsecurity21/presentat...), targetting the cache as the CPU decrypts memory for normal operation. While it'll stop memory dumps from being effective, encrypted RAM won't be the end of dumping keys from memory, especially for patient or highly-skilled attackers.
I'm thinking of something like the old "Action Replay" devices for Gameboys, which modified memory from the game cartridge as it went into the system to be loaded (or executed in the case of code) in order to cheat in games. You slotted the cartridge into the Action Replay, then slotted the Action Replay into the Gameboy.
Could you do something similar between the RAM and the motherboard? Slot your ram into the device, slot the device into the motherboard, and capture the state of memory at any moment by simply watching how memory is read/written? That way, you'd save yourself the hassle of manually powering off the machine and hoping the data you need is available?
I'm not an electrical engineer so maybe what I am proposing is completely infeasible - physical space and bandwidth limitations certainly seem likely. But is it possible?
It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%)
But it would completely prevent this attack.
Game over, any laptop with data worth stealing will have this disabled in bios
Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
(Whenever you wipe the drive through OPAL, you're just overwriting the key.)
Microsoft patched out support for self encrypting drives.
If nothing else, use it in combination - the encryption of OPAL drives is always active anyway, all that changes when the feature is "active" is whether the key is stored as-is on the controller or whether its protected by a passphrase.
The Crucial drive did not have any association between the encryption key and the passphrase, making it possible to bypass encryption.
The Samsung drive had an issue where when setting a passphrase, wear leveling could cause the old unprotected key to still exist on a flash bank (not normally accessible) until that bank got reused.
Only one of them is horrible incompetence - the other is bad but fixable and expires on its own after a bit of use.
The drive manufactures software was making Microsoft look bad. The advantage of SED was small when we have AES-NI.
Note that the advantage is still very large - easily 20% and an associated hit to battery life, depending on the specific cipher mode and access pattern. Without AES-NI it just wouldn't be practical to even consider AES-based FDE.
Not earth shattering, but for SATA3 era SSDs, it's not nothing either. The old 850 EVOs work well, and they're quality disks IME.
Now, drives with eDrive, as MS calls it, are becoming harder to find. It is no longer advertised (as native 4k sectors aren't either...). Soon it'll be dropped all together.
The support experience was one of the absolute worst I’ve ever seen — and I was the guy on the end of the phone that had to say “thank you for calling Wave Systems Gold Support” having been given zero documentation into what the product even did, but being told we had to log tickets into MS Dynamics and pray that a Wave engineer would call a panicked locked out user back “soon”.
See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards.
Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout.
This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery.
And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
Do this experiment.
Boot into any Linux live CD on a machine with bitlocker enabled.
Reboot and see what happens.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
https://learn.microsoft.com/en-us/windows/security/operating...
I didn't change any parameters of the Windows boot option or the rest of the system.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
https://learn.microsoft.com/en-us/windows/security/operating...
And as mentioned it's never had issues if I did a one off choice from the boot menu.
It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.
> In my experience I have had the most success restarting the system while Windows is loading but before the login screen has appeared, at least in the case of finding FVEK keys.
So what is this? It was supposed to be memory attack and he's dumping the keys after someone unlocked it and it's booting?
So this is just another theoretical attack where perfect conditions must be met.
I do wish they provided the hardware specs too, though, as this reflects an incorrect UEFI platform implementation of MOR.
The guy unlocked the bitlocker, then restarted PC just before login screen appeared. He said that's when he had most success. What sense does it make to restart and start looking for key in memory, when bitlocker has been just unlocked.
You steal a laptop. You turn on the laptop. You reboot it into UEFI and steal the keys. This is bad for BitLocker. Ideally this is not possible because the MOR bit should cause the keys to be erased by the platform initialization before boot-from-USB is possible.
If I understand correctly, you need to start the PC, reboot just before the login screen appears, and boot to an USB application, which will copy the memory content.
So this is a viable attack on many, many real-world systems. Adding a BitLocker password/PIN is a mitigation that prevents this attack.
Note that BitLocker is still very useful even in this mode: it guarantees that someone who steals your laptop can't just connect the disk to another system and read everything on it, unless they can actually extract the keys from RAM, or bypass Windows authentication - this attack allows them to do the former relatively easily.
It uses secure boot and it’s pretty darn decent at detecting any form of tampering.
TPM 2.0 isn’t particularly resilient against physical key extraction attacks but believe it or Microsoft did threat model this…
I tried a few non-hardware exploits, even CVE-2022-41099 about WinRE but to no avail.
I’m not a security pro, but I assume once it is in recovery mode lockout you’re pretty much out of luck. From what I can tell most other exploits require it to be unlocked in the first place. Even the hardware hacks seem to require a drive being in a non-lockdown state in order to sniff things during boot.
That NVMe drive is just a keepsake now. I plan to frame it and put it on my wall as a memento.
My threat model is a lost or stolen device or RMA/repair.
If someone wants my data so badly that they’ll be able get into my OneDrive account that is protected with a passkey or a 32 char password + MFA and also have physical access to my devices let them have it.
Anyone who is that determined and capable can always resort to rubber hose cryptography and I want none of that in my life.
The only thing that would be unencrypted is the system restore partition.
That hasn't been my experience. All the recent laptops I've owned (Dell and HP) had a default secure boot setup that allowed booting to Ubuntu and Fedora without disabling Secure Boot. In fact, nowadays even Ventoy works with Secure Boot [0], and I've managed to use it with the setting enabled on all machines I've tested, however in this case you might need to enroll the keys on the first boot, which I imagine will trigger BitLocker.
Apparently what happened is that Microsoft now signs some third party certs for common Linux distributions, and some setups allow these to boot by default. However, it also looks like Microsoft wants these certs disabled by default [1], which should improve BitLocker integrity on average.
Although I believe what happened in OP's situation was that BitLocker wasn't actually enabled or working, likely due to misconfiguration or lack of any.
[0]: https://www.ventoy.net/en/doc_secure.html
[1]: https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-...