I read it as the author is / was going through the vulnerability disclosure process with Microsoft and they're annoyed for unclear reasons and decided to publicly disclose, rather than being an insider.

Previously discussed numerous times on HN, like: https://news.ycombinator.com/item?id=48130519

Whether this is a backdoor or not boils down to whatever your usual proclivities about "bug or backdoor" are; it's not like "if microsoft = 1 hack bitlocker" like the tech press seem to love to report.

This is a bug in the NTFS transaction log replay functionality in the Windows Recovery Environment WinRE, where it will read NTFS transaction logs from an external volume and apply them to the mounted filesystem. This allows the attacker to perform an authentication bypass against WinRE. With BitLocker without PIN or Password, _any_ authentication bypass becomes a disk encryption bypass, since the disk is unsealed by the bootloader (this architectural "flaw" is true for Linux with the same configuration, as well, like Ubuntu installed with their newish Hardware Disk Encryption checkbox in the installer).

In lieu of additional evidence, whether you think the NTFS transaction log issue is a planted backdoor or a simple enumeration bug depends on your conspiracy theory level, like most things in exploit development. To me, it seems like a plausible bug. The weaknesses in boot-time unseal are well known and obvious and this is just one of many, so I don't see it as an earth-shattering revelation, although it is a fun bug.

Can’t wait to read the blogpost of what have truly happened and motivated this person to expose M$ like this

And there is a level above PIN with Bitlocker too, you can have a USB stick with a key on it which you use only during boot. I would imagine that is secure from this attack as the data isn't even stored on the device (I hope).

Assuming that the PIN version claim is true, it's interesting to think why they would've released a nerfed useless version rather than the PIN version. I have some ideas but they're completely baseless.

>The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?

The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.

I don't use Microsoft products generally but not with even with your computer would I run VeraCrypt.

You are confused. They are not "security" roles, they are compliance roles. That's all most enterprise customers really care about. They satisfied all of the compliance rules, and are following "best practices" (influenced by MS), anything that happens is not their fault.

As opposed to iOS, which does iCloud backups that are not E2E encrypted by default, so that law enforcement can request your chats (except Signal because they opt out), browser history, etc.?

You can enable ADP for E2E encrypted backups, but it's probable not going to help you much, because the people you are communicating with likely didn't.

This is not to defend Microsoft, more to say that all these companies were part of PRISM.

For enterprise, there seems to be so much money in doing it, that I don't think people are going to start turning it down just because it's troublesome.

> And now backdoors!

"now"?

Shall we have a discussion about the excuse Microsoft gave as to why keys they claimed, back then, were "secondary keys" belonging to Microsoft, were called ..._NSAKEY when a version of Windows NT shipped, by mistake, with debug symbols on?

One time, just freaking one time, a version of Windows shipped with debug symbols on and, by chance, there had to be cryptographic keys named "NSAKEY" in there.

Yeah.

Now that people constantly turning a blind eye on the wrongdoings of the state are of course going to say that it's totally normal and just repeat the, carefully crafted, excuses from Microsoft from back, that it was totally not a backdoor etc.

> What Microsoft is doing here in general they are selling something that is not secure. They are selling it as as full disk encryption but it's not.

But you can configure Linux LUKS in the same way.

This doesn't seem an attack on BitLocker so much as it is an attack on the secure boot chain.

>If there is a stick you can boot from and drop into an emergency shell

This won't work because the TPM will only give you the keys if you're booting an "approved" OS, specifically the PCR states that the encryption keys are bound to.

>or if you have to buy a $5 microcontroller and solder it to certain pins on the main board to sniff the TPM keys.

That only works with dTPMs. fTPMs aren't vulnerable to this, and are far more popular than dTPMs.

Ubuntu also released TPM based FDE a few versions ago. I had these thoughts then and decided against using it. Typing my passphrase on boot is muscle memory and gives me simple security I can trust.

Also can recover data without my mainboard.

Maybe a hybrid (secureboot-TPM+phrase) slot for day to day to also prevent against evil maid attacks, and another slot with a backup passphrase would be acceptable.

They claim they have TPM + PIN exploit too, though how credible it is remains to be seen.

https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...

This doesn't make much sense. Almost every single organization using Bitlocker knows that it's backdoored. It's like Push Notifications or SMS, warrantless surveillance is the norm and you don't get to opt-out. Nobody's IT department is waking up in cold sweats at the idea of the Fed stealing their data, it's part and parcel with using Windows services.

If you really think this will be prosecuted as fraud, then you'll be shocked by how American courts handle these sorts of things.

I'm not aware of the connection between truecrypt and bitlocker, want to enlighten us?

That was my immediate first thought. "Oh, is Bitlocker Not Safe Anymore?"

You're probably thinking of VeraCrypt, which is a fork of TrueCrypt. I don't think BitLocker is related.

Another way to look at this is that Microsoft, Google, Apple, et al are in the business of providing products and services to regular people, for a low cost. This means they end up providing ways to escrow keys, recover locked accounts and so on that are weak. Not because they want to provide back doors for TLAs but because to provide strong security would be so expensive they couldn't meet the price point for regular customers. If, for example, MS only provided disk encryption that relied on a smart card or a memorized strong passphrase at boot/wake, they'd go out of business providing support to people who forgot their passphrase and being sued by people who lost their data.

The nagging to upgrade is insane. Even the 'dismissal' option is a dark pattern still designed to make you click the wrong thing

You only need to use the aka.ms link if you lost your recovery key. That feature also can be disabled without disabling Bitlocker as a whole.

My harddrives (laptop, work laptop, desktop, server) contain emails, browser sessions, saved passwords, personal data from family and friends.

I do not want someone stealing my laptop on a train ride potentially being able to have all of that data.

With a proper real backup strategy, i have everything save. I do not need easy access to a hard drive from a broken computer.

But hey you do you :)

If "things go catastrophic" your hard drive is not usable at all anymore. At the very least some files can't be recovered at all. So you need backups in any case. Once you have backups, you might as well encrypt your hard drives, especially if you store these in different locations (which you should).

An advantage of encryption is that it makes it easier to give away or resell devices. With recent encryption schemes (well the ones on Linux, given this article), I feel confident that overwriting the encryption keys gets me close enough to not leaking my data once I get rid of an old hard drive.

Additional problem is if physical access is obtained, illegal material could be covertly added to the drive then picked up by the built in scanners in your OS. Depends on how important you are.

That's called LUKS2 and it's the default on Linux. You just type passphrase on boot. It's not tied to the motherboard.

But it's also plug&play for anyone stealing your laptop, see for instance

https://news.ycombinator.com/item?id=39941021

I was happy to give up my side-hobby of drilling drives after FDE became standard everywhere. Plug and play is great, but you don't want it to be plug and play for whoever pulls your drive out of the trash.

Same here. If anything happens I want a decent chance to be able to recover my data. The most I may do is create encrypted files, and some of them I've forgotten the passwords for, which makes me even more wary.

So long as you've backed up the key you can fairly easily decrypt on any machine.

What's not plug and play if using some sensible fde like idk, dm-crypt? You are only a passphrase away from mounting that drive in any other system you plug it into.

I mean... you can use an encryption scheme compatible with this (if you know the password).

I suppose this makes some sense for home computers (burglars and police raids are rare) but for a laptop, you really don't want thieves getting all your details.

Ironically -- this probably was paranoid a few years ago, but now -- "ChatGPT, use this prepared prompt to extract all useful info from this hard drive"

the point is having a choice and the choice actually doing what it claimed.

I've heard this before, so what I think it means is this:

If you want to encrypt some data that gets stored persistently somewhere on your machine, rather than invent an application-specific encryption scheme for that data alone, instead use a mainstream full-partition encryption mechanism, then store the data as plaintext within said partition.