I think the Bitlocker "vuln" is a good reminder not to use vendor provided encryption for any sensitive data. https://github.com/Nightmare-Eclipse/YellowKey/ You load a specific file onto a flash drive, plug it into a Bitlocker encrypted computer, reboot it while holding a key combination, and it pops up a command prompt with full access to the encrypted volume. There's no way this isn't a backdoor.
> I think the Bitlocker "vuln" is a good reminder not to use vendor provided encryption for any sensitive data
I don't think that's true. Some vendors have a better track record than others. Nobody's popped the storage encryption on iOS or MacOS devices yet AFAIK; and the fact that it's tied to a hardware secure element makes it pretty strong.
I don't see anything on the linked page that supports a conclusion that NSA has successfully broken the encryption at rest of an Apple device's storage since they introduced the secure element.
Prism targeted network communication to my knowledge, hence the data wouldn't be siphoned from at rest encrypted devices. Instead it would've been leaked before it was copied to that local encrypted device, whenever it was transmitted over the wire. Eg when your background task uploaded it to iCloud or similar.
There is no way for us, the users, to know wherever they have the capability to add additional keys to decrypt the data because the platform isn't open source and doesn't have attestation wrt what's actually serving the requests.
And it's worth remembering that apple had similar articles published before prism too which were ultimately proven to be groundless by prism.
The whole thing relies on hardware security modules, so even if you can prove that the whole software stack is working as described, there is literally no way to know that the SE isn’t secretly handing the OS keys that a third party can decrypt.
There needs to be trust at some level, and trust in Apple the entity to not be outright lying about its thoroughly documented security posture is a reasonable level of trust for most people on the planet, including those who are at very real risk of targeted attack by state-level actors.
Ah yes, the bizarro world where systems are normally unhackable so the default assumption is impenetrable security and you need to prove they are insecure.
Thank god this is not the world where things get hacked all the time and where any claim of meaningful security is a extraordinary claim that demands extraordinary evidence and proof before credibly asserting it, but everybody just ignores that part and just pinky promises it and everybody just believes them for the 104th time without evidence.
Microsoft quietly dropped support for encryption offload support ("OPAL") in SSD drives because the hardware vendors were doing absolute clown-shoes things like a single static hard-coded key or the key was literally empty / all zeroes!
There's levels of trust/security.
I generally trust Apple's device encryption, assume BitLocker can be popped by a well-equipped nation state attacker, and the rest I trust about as far as I can throw them.
PS: A related issue was (is?) that the comms between the CPU and the TPM chip on the motherboard isn't encrypted, signed, or in any significant way protected! Apparently it's relatively trivial to extract various keys including BitLocker encryption keys by simply clipping an oscilloscope to the TPM chip pins.
Ah, yes. Wave EMBASSY Suite, Wave Preboot, and all that other hot garbage.
Best part of Wave Systems was their horrid support organization. I loved being the tier 0 rep they contracted and trained with zero software knowledge and being a catch-and-throw for all the angry people that locked themselves out of their laptops. "Sorry, buddy, all I can do is make you a Dynamics CRM ticket."
this exploit works only if you dont use a PIN/password for your Bitlocker and the volume automatically unlocks
so it gives you access to an encrypted volume which automatically unlocks anyway
the only difference is that it immediately gives you root access to the volume instead of having to go through the Windows login procedure - this might be a stolen laptop you dont have an account on
The author claims the exploit also works with TPM+PIN, he just hasn't released the PoC:
> Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
they might mean "after you enter the bitlocker PIN you get root access without having a login password on the system" - still just a privilege escalation bug
Considering the researcher had already reported these to Microsoft, and delayed releasing them publicly until Microsoft "pulled every childish game possible" (quote) instead of patching them, it's not unreasonable for the researcher to be withholding another exploit from the public to limit harm.
I also disagree that the PIN bypass would be "10 times more impressive," but that's just my professional opinion.
We know that the PIN method wraps the key in additional layers of encryption, and that the TPM happily returns this wrapped key on boot. So the extra step(s) required would be to bruteforce the PIN and now you can unwrap the plain key.
I'm not a Windows expert but based on my understanding of how MS does this, something doesn't add up here.
If you use bitlocker in the default, insecure way, where the TPM is configured to hand the decryption keys over to the enrolled Windows environment automatically, you can just get an LPE to access the running Windows environment after it boots. That's what I think the published exploit does. It really isn't even related to bitlocker itself, right?
AIUI, TPM+PIN should actually mean the TPM itself cannot release the keys because the PIN hash is actually part of the key material.
The usual attack is in a usability feature to prevent lock out. Looking at the instructions for setup I see Bitlocker recovery code if you forget your pin.. (How does that alternative work, what are other alternative unlocks if firmware hash changes, etc, etc..)
> TPM+PIN should actually mean the TPM itself cannot release the keys
It does release the (wrapped) key actually (the above cyberlabs link explains it), it's just that the KP data this time has additional layers of encryption that are based on the PIN, which is decrypted in software after the fact. This means you can crack it offline. With the default minimum of 6 digits you can probably bruteforce it within a day.
If you're paranoid I might suggest switching to a full password-based pre-boot auth option instead of the PIN.
This article is probably not correct. The actual behavior is documented [1]:
> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.
So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.
I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.
This one does say "it appears that the user’s PIN is sent to the TPM which releases the intermediate key only if the provided secret is correct, thus effectively preventing offline bruteforce attacks."
Given this, I can't see how it would be possible for anything like YellowKey to work on a cold booted TPM+PIN system without someone already knowing the PIN.
Perhaps when the exploit author said "it works with PIN" they meant "it works if you enter the correct PIN"... or they are just lying. I'm not sure.
yeah those have shaken a lot of people's confidence in Linux and I don't really see people ditching Windows either.
In some ways the hysteria of sorts is peculiar....its not like we never had secure cybersecurity either its just that we have too much on the cloud and institutions of trust without questioning it because of herd behavior and empty suits.
Like the timing of all of these seemingly disparate events from "mystery lonewolf" is too obvious and I'm not the one to entertain conspiracies either.
I mean, there is some in the high assurance space, but that has never trickled into the broader consumer sphere. Are you referencing those systems? I am unaware of anything else.
That warning also doesn’t render right on my
iPhone (the buttons are overlapping slightly), and I don’t recall seeing it on other repos. Is it new/bespoke?
I'm logged in, but I'm seeing this now and can click on "View repository" or "Explore other repositories". Maybe that's why it's behind a login wall.
> This repository contains malicious content that may cause technical harms. We have decided to preserve this content for security research purposes. Please exercise CAUTION when clicking links, downloading releases, or otherwise interacting with this repository.
I see upvotes, so at least some people agree with this possibility.
One more reason to stick with open source, auditable solutions. Any backdoor in open source software would be quickly noticed by the community (such as recently when NPM packages got compromised).
This year looks very refreshing for software. My guess is because of the AI-assitance in grinding an unlimited amount of code. While I feel sorry for maintainers and developers who have a new CVE everyday, society seems to be sweeping away 20 years of backdoor development by shady companies and spies, making computing actually safe and trusted for the first time in our lifetime.
Or laid of NSA, laid off Mossad, or many other possibilities.
Or not laid off at all, but otherwise disgruntled security researcher who prompted AI to concoct some personal details that seem to be in line with someone inexplicably dropping Microsoft zero-days.
I think the Bitlocker "vuln" is a good reminder not to use vendor provided encryption for any sensitive data. https://github.com/Nightmare-Eclipse/YellowKey/ You load a specific file onto a flash drive, plug it into a Bitlocker encrypted computer, reboot it while holding a key combination, and it pops up a command prompt with full access to the encrypted volume. There's no way this isn't a backdoor.
> I think the Bitlocker "vuln" is a good reminder not to use vendor provided encryption for any sensitive data
I don't think that's true. Some vendors have a better track record than others. Nobody's popped the storage encryption on iOS or MacOS devices yet AFAIK; and the fact that it's tied to a hardware secure element makes it pretty strong.
You mean aside from the NSA? https://en.wikipedia.org/wiki/PRISM
I don't see anything on the linked page that supports a conclusion that NSA has successfully broken the encryption at rest of an Apple device's storage since they introduced the secure element.
Care to share a quote?
Prism targeted network communication to my knowledge, hence the data wouldn't be siphoned from at rest encrypted devices. Instead it would've been leaked before it was copied to that local encrypted device, whenever it was transmitted over the wire. Eg when your background task uploaded it to iCloud or similar.
It’s worth remembering that since Snowden, much of iCloud is now end-to-end encrypted using keys that Apple cannot unwrap: https://support.apple.com/guide/security/secure-icloud-keych...
Fwiw, that's a clear statement - but only that.
There is no way for us, the users, to know wherever they have the capability to add additional keys to decrypt the data because the platform isn't open source and doesn't have attestation wrt what's actually serving the requests.
And it's worth remembering that apple had similar articles published before prism too which were ultimately proven to be groundless by prism.
What, exactly, was proven to be groundless?
The whole thing relies on hardware security modules, so even if you can prove that the whole software stack is working as described, there is literally no way to know that the SE isn’t secretly handing the OS keys that a third party can decrypt.
There needs to be trust at some level, and trust in Apple the entity to not be outright lying about its thoroughly documented security posture is a reasonable level of trust for most people on the planet, including those who are at very real risk of targeted attack by state-level actors.
Ah yes, the bizarro world where systems are normally unhackable so the default assumption is impenetrable security and you need to prove they are insecure.
Thank god this is not the world where things get hacked all the time and where any claim of meaningful security is a extraordinary claim that demands extraordinary evidence and proof before credibly asserting it, but everybody just ignores that part and just pinky promises it and everybody just believes them for the 104th time without evidence.
Microsoft quietly dropped support for encryption offload support ("OPAL") in SSD drives because the hardware vendors were doing absolute clown-shoes things like a single static hard-coded key or the key was literally empty / all zeroes!
There's levels of trust/security.
I generally trust Apple's device encryption, assume BitLocker can be popped by a well-equipped nation state attacker, and the rest I trust about as far as I can throw them.
PS: A related issue was (is?) that the comms between the CPU and the TPM chip on the motherboard isn't encrypted, signed, or in any significant way protected! Apparently it's relatively trivial to extract various keys including BitLocker encryption keys by simply clipping an oscilloscope to the TPM chip pins.
Reference: https://www.techcentral.ie/windows-bitlocker-no-longer-trust...
> OPAL
Ah, yes. Wave EMBASSY Suite, Wave Preboot, and all that other hot garbage.
Best part of Wave Systems was their horrid support organization. I loved being the tier 0 rep they contracted and trained with zero software knowledge and being a catch-and-throw for all the angry people that locked themselves out of their laptops. "Sorry, buddy, all I can do is make you a Dynamics CRM ticket."
this exploit works only if you dont use a PIN/password for your Bitlocker and the volume automatically unlocks
so it gives you access to an encrypted volume which automatically unlocks anyway
the only difference is that it immediately gives you root access to the volume instead of having to go through the Windows login procedure - this might be a stolen laptop you dont have an account on
The author claims the exploit also works with TPM+PIN, he just hasn't released the PoC:
> Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
they might mean "after you enter the bitlocker PIN you get root access without having a login password on the system" - still just a privilege escalation bug
That’s quite a stretch, to say the least.
claiming to have a 10 times more impressive PoC but not releasing it "out of goodness of heart" is also quite a stretch
Considering the researcher had already reported these to Microsoft, and delayed releasing them publicly until Microsoft "pulled every childish game possible" (quote) instead of patching them, it's not unreasonable for the researcher to be withholding another exploit from the public to limit harm.
I also disagree that the PIN bypass would be "10 times more impressive," but that's just my professional opinion.
We know that the PIN method wraps the key in additional layers of encryption, and that the TPM happily returns this wrapped key on boot. So the extra step(s) required would be to bruteforce the PIN and now you can unwrap the plain key.
https://post-cyberlabs.github.io/Offensive-security-publicat...
If you think about it for some minutes you will maybe understand that there are many reasons not to publish it.
I'm not a Windows expert but based on my understanding of how MS does this, something doesn't add up here.
If you use bitlocker in the default, insecure way, where the TPM is configured to hand the decryption keys over to the enrolled Windows environment automatically, you can just get an LPE to access the running Windows environment after it boots. That's what I think the published exploit does. It really isn't even related to bitlocker itself, right?
AIUI, TPM+PIN should actually mean the TPM itself cannot release the keys because the PIN hash is actually part of the key material.
So what would a TPM+PIN exploit even look like?
The usual attack is in a usability feature to prevent lock out. Looking at the instructions for setup I see Bitlocker recovery code if you forget your pin.. (How does that alternative work, what are other alternative unlocks if firmware hash changes, etc, etc..)
> you can just get an LPE to access the running Windows environment after it boots
Or if you have physical access, you can probe the TPM chip with a SPI decoder to get the key directly: https://post-cyberlabs.github.io/Offensive-security-publicat...
Another method is via PXE (still not patched on most systems apparently): https://github.com/andigandhi/bitpixie
> TPM+PIN should actually mean the TPM itself cannot release the keys
It does release the (wrapped) key actually (the above cyberlabs link explains it), it's just that the KP data this time has additional layers of encryption that are based on the PIN, which is decrypted in software after the fact. This means you can crack it offline. With the default minimum of 6 digits you can probably bruteforce it within a day.
If you're paranoid I might suggest switching to a full password-based pre-boot auth option instead of the PIN.
This article is probably not correct. The actual behavior is documented [1]:
> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.
So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.
I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.
[1] https://learn.microsoft.com/en-us/windows/security/operating...
I was given this article after posting the previous one elsewhere:
https://blog.scrt.ch/2024/10/28/privilege-escalation-through...
This one does say "it appears that the user’s PIN is sent to the TPM which releases the intermediate key only if the provided secret is correct, thus effectively preventing offline bruteforce attacks."
Given this, I can't see how it would be possible for anything like YellowKey to work on a cold booted TPM+PIN system without someone already knowing the PIN.
Perhaps when the exploit author said "it works with PIN" they meant "it works if you enter the correct PIN"... or they are just lying. I'm not sure.
How does Bill Gates keep getting away with this
Do you know of a backdoor for Apple FileVault?
It's so obvious that many of the bugs being found are/were most likely M$ backdoors.
There doesn't seem to be any other plausible explanation. The reckoning needs to come and people need to stop using their products for good.
Would love a whistleblower to explain which part of the government or company forced it.
Haven't there been heaps of vulnerabilities cropping up all over recently, including CopyFail and Dirty Frag?
yeah those have shaken a lot of people's confidence in Linux and I don't really see people ditching Windows either.
In some ways the hysteria of sorts is peculiar....its not like we never had secure cybersecurity either its just that we have too much on the cloud and institutions of trust without questioning it because of herd behavior and empty suits.
Like the timing of all of these seemingly disparate events from "mystery lonewolf" is too obvious and I'm not the one to entertain conspiracies either.
We had secure cybersecurity? When?
I mean, there is some in the high assurance space, but that has never trickled into the broader consumer sphere. Are you referencing those systems? I am unaware of anything else.
A LOT of people are ditching windows. The only Windows computer I have left out of 5 is a work pc.
CachyOS is pretty amazing, too.
They might be incompetent
So weird that GitHub requires a login to view their BlueHammer repo.
https://github.com/Nightmare-Eclipse/BlueHammer
That warning also doesn’t render right on my iPhone (the buttons are overlapping slightly), and I don’t recall seeing it on other repos. Is it new/bespoke?
I'm logged in, but I'm seeing this now and can click on "View repository" or "Explore other repositories". Maybe that's why it's behind a login wall.
> This repository contains malicious content that may cause technical harms. We have decided to preserve this content for security research purposes. Please exercise CAUTION when clicking links, downloading releases, or otherwise interacting with this repository.
Oh cool. My brother's old laptop is locked. Maybe this will help
Only affects win11
Windows 11 is almost 5 years old at this point
Haha I texted him about this and he said he already re-installed Windows. Bad timing. It was just a couple weeks ago he told me about this.
This won't work if Windows on boot is already asking for BitLocker key because it means it can't retrieve the key from TPM.
Could the Bitlocker vulnerability be a backdoor mandated by some government agency?
I see upvotes, so at least some people agree with this possibility.
One more reason to stick with open source, auditable solutions. Any backdoor in open source software would be quickly noticed by the community (such as recently when NPM packages got compromised).
Some anon hero cleans up backdoored garbage.
This year looks very refreshing for software. My guess is because of the AI-assitance in grinding an unlimited amount of code. While I feel sorry for maintainers and developers who have a new CVE everyday, society seems to be sweeping away 20 years of backdoor development by shady companies and spies, making computing actually safe and trusted for the first time in our lifetime.
Laid off Microsoft researcher?
No way to know but the timing is peculiar....conspiracy?
Or laid of NSA, laid off Mossad, or many other possibilities.
Or not laid off at all, but otherwise disgruntled security researcher who prompted AI to concoct some personal details that seem to be in line with someone inexplicably dropping Microsoft zero-days.
... who converted Windows 11 into Emmentaler: https://deadeclipse666.blogspot.com/2026/04/
Related:
YellowKey Bitlocker Bypass Vulnerability
https://news.ycombinator.com/item?id=48114997
Seems odd that someone is both capable of this and homeless. This stuff has decent value on the grey market
You imagine people wind up homeless because they can’t do useful things? What a just world!
Anyone remember the Samsung ssd issue with bitlocker from maybe like a decade or so ago where it was an empty encryption key or something
i think so~