A non-default-installation set of AMD tools (Ryzen Master and probably others) had an auto-updater which used HTTP instead of HTTPS. It's clear this is a feature they'd basically forgotten about; it even pointed to an ATI domain. A third-party bug bounty company rejected it because MITM was out of scope. AMD are incompetent at making software (news at 11), kept asking for extensions, and took an incredible amount of time to deal with it. Eventually they removed this updater entirely and replaced it with one in the app (rather than the installer) that uses HTTPS + a CRC32 (for some reason). The initial vuln was very stupid and should have been fixed faster. As for the current system, if you're mad about HTTPS-protected auto-updaters (which is valid), you've probably got a lot of them to go to war against.

For example, previously I used the Frigate web UI over VPN to access my cameras, but I instead had Claude help set up go2rtc to push the video to HomeKit. I used the Eufy app for my doorbell, which I was instead able to integrate into HomeAssistant and then push to HomeKit as well, and I was also able to integrate some TP-Link Kasa plugs with HomeAssistant too.

This is all stuff I could have done relatively easily myself, but I hate nothing more than wading through horribly documented disparate configuration systems (I do that enough all day), so having Claude to do it for me is what unlocked it actually getting done.

I also added on to some custom one-offs like an ESP32-based controller for my kid's RGB LED nightlight for fun, although that stuff was more hand-coded since I find it enjoyable.

What's funny is that Twitter SRE used to be horrible and the app probably would have collapsed entirely (rather than the little bit that it did) without hundreds of manual operators, but in the few years leading up to the "acquisition," massively improved to the point that they literally automated themselves out of a job.

Anyway, Twitter had thousands of engineers, salespeople, support people, and so on. They were working on tens of new products in an attempt to find more revenue (everything from clones of every single social media app you can imagine to becoming a sports TV network), and on the other side (Goldbird), selling and supporting ads, the thing that made Twitter money.

The metric to look at isn't uptime, it makes no sense that people keep parading this metric. The metrics are revenue and revenue growth and surprise! by most available metrics, the Elon strategy torpedoed those.

Twitter was, like almost every "web" company in ~2020, a very "fat" company because they were re-investing free ZIRP money in future growth investment. Elon turned it into a KTLO operation, and didn't even manage to succeed at the standard PE style "fat" company slim-down (where you chop growth initiatives and keep the revenue, like everyone else is doing now), because he also chopped the revenue side.

I also build a ton of household glue stuff; I was never really passionate enough about the whole "homeserver" thing to spend the effort in going beyond basic video recording for my security system, but now I have all of my local-only home automation stuff wired together, mostly into HomeKit, and have been able to ditch a ton of cloud services.

This exploit is cool but there are similar exploits discovered in any given year and nothing really reeks of a backdoor; this one seems to be gaining attention mostly because Microsoft’s robo-call level initial response caused the researcher to dramatically crash out.

For a company, they're also nice for "I want to make an IoT device that's heavier weight than an ESP32 and/or I only want to hire Linux Application People and not Firmware People; what's the cheapest Linux module I can get that's widely supported, backed by a real company, and has regulatory approvals" - Pi Zero W. My understanding is this exact pattern is why it's harder to get them as a hobbyist.

I use them widely in automotive reverse engineering; ESP32 can and does work just as well or better for an end product, but for experiments it's really nice to have a self-contained appliance to SSH into and use SocketCAN on rather than some bespoke firmware project to manage and iterate on.

Given the price and availability issues I suspect the market is "correcting" a bit and companies are hiring Firmware People and switching to true MCUs in places they'd previously have avoided doing so, but it was definitely a thing for a long time.

It's concerning that Intel don't seem to have been responsive to anyone with respect to this issue and it doesn't appear to have an official errata yet, although Raptor Lake was the Intel CPU with voltage issues and basically random bit rot so I suppose it's hard to tell if this is a silicon level errata caused by bad design or by some kind of post-manufacturing damage. Raptor Lake in general causes enough non-reproducible noise that I believe Firefox gave up on automated crash reports from it ( https://bugzilla.mozilla.org/show_bug.cgi?id=1975808 ).

EDIT: I read that Oodle article (which is SO good!) again and realized that their customer-provided reproduction of the bug was directly linked to boost clock speeds (the customer said that overclocking by 5% made it happen entirely reliably), so this is definitely not a "the architecture has a 100% bug in it" but rather some deeper issue with clock propagation that appears at edge cases.

More modern devices are of course more difficult due to layers, feature size, and less visually obvious ROM bit designs.

Anyway, the impressive part of this project was really understanding the undocumented microcode assembly language through inference and trace following; the 1s and 0s look like they were the easy part!

We know how PIN-locked BitLocker works, and it requires unwrapping using a key sealed behind a TPM PIN policy and stretching it using the PIN itself. So we can deduce that this would require that:

* The attacker was able to bypass the TPM PIN sealing policy _and_ brute-force the stretching applied to the decrypted key. Brute-forcing the stretch is plausible on a "lots of expensive stuff" timeline but not an easy attack. Bypassing TPM PIN policy across multiple platforms would be something quite incredible. Given that TPMs are implemented by multiple vendors across multiple fundamental architectural approaches, and aren't based on a universal reference implementation, it would be rather bizarre to find a mistake in many or all of them.

* There is a secret volume key stored on a volume which can be decrypted by another mechanism. This would be a backdoor, but seems vanishingly unlikely given the amount of research which has been applied against BitLocker historically.

* The attacker is at some point able to inject something which allows them to observe the victim applying the PIN. There could be an attack here but it isn't nearly as interesting.

A fun next step would be to look at different fstx versions to see if it’s just something that was patched or refactored out at some point. At that point it could be a patch-door (ie an organic bug where the patch was held back by interference), but again, that would be a crappy setup due to the propensity for Windows vulnerability engineers to use binary diffing - if you had the exploit and the power to hold back the patch, it would be way better to hold it back everywhere.

WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster).

By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.

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.

(as an aside): I'm not trying to say Lockdown Mode is infallible; I am sure phones in Lockdown Mode are or will be compromised. But it's clearly a very powerful tool, and to try to argue that it is some kind of marketing-driven conspiracy, against the body of evidence of its success, using bug bounty payout numbers (???), as the grandparent post did, is ridiculous.

My general conclusion is: it's stupid that Apple continue to allow this and Trust Us Bro is not a good permission system to allow app developers do shady things, especially when research indicates that they are, unsurprisingly, doing shady things. Apple's static analysis based App Store approval system is also historically swiss-cheesey and I know they could do better. Overall, thematically a black mark on Apple, which has always been surprising for me because they tend to genuinely care about privacy in many other facets.

The economics of the device exploitation industry are completely orthogonal from bug bounty payouts; the markets only overlap at the _extreme_ fringes. Trying to use one as a proxy for the other is meaningless.

I didn’t find it too difficult to set up TPM backed encryption on Arch using systemd-cryptenroll for my home server, although for anything I use interactively I just use a passphrase instead.