It ain't normal to me. If I bought a phone, I should be able to decide that I want to run different software on it.

Let's say OP takes a very different turn with their software that I am comfortable with - say reporting my usage data to a different country. I should be able to say "fuck that upgrade, I'm going to run the software that was on my phone when I originally bought it"

This change blocks that action, and from my understanding if I try to do it, it bricks my phone.

Sounds like that should be an option in "Developer Options" that defaults to true, and can only be disabled after re-authentication / enterprise IT authorization. I don't see anything lost for the user if it were done this way.

I understand that there is a nuance somewhere, but that's about it.

Can you explain it in simpler terms such that an idiot like me can understand? Like what would an alternative OS have to do to be compatible with the "current eFuse states"?

This kind of thing is generally used to disallow downgrading the bootloader once there is a bug in chain of trust handling of the bootloader. Otherwise once broken is forever broken. It makes sense from the trusted computing perspective to have this. It's not even new, it was still there on p2k motorollas 25 years ago.

You may not want trusted computing and root/jailbreak everything as a consumer, but building one is not inherently evil.

OTP memory is a key building block of any secure system and likely on any device you already have.

Any kind of device-unique key is likely rooted in OTP (via a seed or PUF activation).

The root of all certificate chains is likely hashed in fuses to prevent swapping out cert chains with a flash programmer.

It's commonly used to anti rollback as well - the biggest news here is that they didn't have this already.

If there's some horrible security bug found in an old version of their software, they have no way to stop an attacker from loading up the broken firmware to exploit your device? That is not aligned with modern best practices for security.

eFuses have been a thing forever on almost all MCUs/processors, and aren't some inherently "evil" technology - mostly they're used in manufacturing when you might have the same microcontroller/firmware on separate types of boards. I'm working on a board right now which is either an audio input or an output (depending on which components are fitted) and one or the other eFuse is burned to set which one it is, so subsequent firmware releases won't accidentally set a GPIO as an output rather than an input and potentially damage the device.

There's so many ways to do this, but a simpler method is to hide a small logic block (somewhere in the 10 billion transistors of your CPU) that detects a specific, long sequence of bits and invokes the kill switch.

>That’s why you sanction the hell out of Chinese Loongson or Russian Baikal

I assume that's also why China is investing so heavily into open source risc-v

This has been going on for a long, long time. Motorola used to make Android phones that would burn an efuse in the SoC if it thought it was being rooted or jailbroken, bricking the phone.

It's basically the same for our automobiles, just try to disable the "phone home" parts connected to the fin on the roof. Do we really own out cars if we can't stop the manufacturer from telling us we need to change our oil through email?

Indeed.

My ownership is proved by my receipt from the store I bought it from.

This vandalization at scale is a CFAA violation. I'd also argue it is a fraudulent sale since not all rights were transferred at sale, and misrepresented a sale instead of an indefinite rental.

And its likely a RICO act, since the C levels and BOD likely knew and/or ordered it.

And damn near everything's wire fraud.

But if anybody does manage to take them to court and win, what would we see? A $10 voucher for the next Oneplus phone? Like we'd buy another.

I think the writing has been on the wall since they started their Nord line.

My understanding is there was a bug that let you wipe and re-enable a phone that had been disabled due to theft. This prevents a downgrade attack. It's in OnePlus's interest to make their phones less appealing for theft, or, in their interest to comply with requirements to be disableable from carriers, Google, etc.

Their low-level bootloader code contains a vulnerability that allows an attacker with physical access to boot an OS of their choice.

Android's normal bootloader unlock procedure allows for doing so, but ensures that the data partition (or the encryption keys therefore) are wiped so that a border guard at the airport can't just Cellebrite the phone open.

Without downgrade protection, the low-level recovery protocol built into Qualcomm chips would permit the attacker to load an old, vulnerable version of the software, which has been properly signed and everything, and still exploit it. By preventing downgrades through eFuses, this avenue of attack can be prevented.

This does not actually prevent running custom ROMs, necessarily. This does prevent older custom ROMs. Custom ROMs developed with the new bootloader/firmware/etc should still boot fine.

This is why the linked article states:

> The community recommendation is that users who have updated should not flash any custom ROM until developers explicitly announce support for fused devices with the new firmware base.

Once ROM developers update their ROMs, the custom ROM situation should be fine again.

> What do OnePlus gain from this? Can someone explain me what are the advantages of OnePlus doing all this?

They don't want the hardware to be under your control. In the mind of tech executives, selling hardware does not make enough money, the user must stay captive to the stock OS where "software as a service" can be sold, and data about the user can be extracted.

It is the same concept on an iPhone, you have 7 days to downgrade, then it is permanently impossible. Not for technical reasons, but because of an arbitrary lock (achieved through signature).

OnePlus just chose the hardware way, versus Apple the signature way

Whether for OnePlus or Apple, there should definitively be a way to let users sign and run the operating system of their choice, like any other software.

(still hating this iOS 26, and the fact that even after losing all my data and downgrading back iOS 18 it refused to re-sync my Apple Watch until iOS 26 was installed again, shitty company policy)

Firmware (XBL and other non OS components) are versioned with anti rollback values. If the version is less than the version burned into the fuses the firmware is rejected. The “boot” partition is typically the Linux kernel. Android Verified Boot loads and hashes the kernel image and compares it to the expected hash in the vbmeta partition. The signature of the hash of the entire vbmeta metadata is compared to a public key coded into the secondary boot loader (typically abl (fastboot before fastbootd was done in user space to support super partitions))

The abl firmware contains an anti rollback version that is checked with the eFuse version.

The super partition is a bunch of lvm logical partitions on top of a single physical partition. Of these, is the main root filesystem which is mounted read only and protected with dm-verity device mapping. The root hash of this verity rootfs is also stored in the signed vbmeta.

Android Verified Boot also has an anti rollback feature. The vbmeta partition is versioned and the minimum version value is stored cryptographically in a special flash partition called the Replay Protected Memory Block (rpmb). This prevents rollback of boot and super as vbmeta itself cannot be rolled back.

>What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.

This doesn't make sense unless the secondary boot is signed and there is a version somewhere in signed metadata. Primary boot checks the signature, reads the version of secondary boot and loads it only if the version it's not lower than what write-once memory (fuse) requires.

If you can self-sign or disable signature, then you can do whatever boot you want, as long as it's metadata satisfies the version.

I've been dismayed by how fast the "we should own our hardware" crowd has so quickly radicalized into "all security features are evil", and "no security features should exist for anyone".

Not just "there should be some phone brands that cater to me", but "all phone brands, including the most mainstream, should cater to me, because everyone on earth cares more about 'owning their hardware' than evil maid attack prevention, Cellebrite government surveillance, theft deterrence, accessing their family photos if they forget their password, revocable code-signing with malware checks so they don't get RATs spying on their webcam, etc, and if they don't care about 'owning their hardware' more than that, they are wrong".

It is objectively extremist and fanatical.

How is graphene considered the most secure phone os but you can still flash on new firmware?

I don't care if they can downgrade the device, just that I boot into a secure verified environment, and my data is protected.

I also think thieves will just grab your phone regardless, they can still sell the phone for parts, or just sell it anyway as a scam etc.

He has already made the video on this, but it is only 3:23: https://youtu.be/3AiRB5mvEsk?si=XapAHhHRJtssDI4F

As an early OnePlus user (1, 3, 5, 7, 13) i find myself unimpressed with what Nothing is proposing, feels more like a design exercise than a flagship killer

They consistently have allowed bootloader unlocking without extra fuss and have had good LineageOS support. That is their main appeal, IMO. Nothing phones had no LineageOS support until recently (spacewar is now supported, unsure about other models), and it's not clear if there's enough of a community/following to keep putting LineageOS on them. I do not want any phone where I'm stuck with the stock ROM.

I've been with OnePlus since the beginning, and am not at all impressed by the Nothing. Primary missing feature which I've come to depend on, off screen gestures, is missing. And the device just comes across as foreign in general; makes me think of the iPhone, which is not something I want to think of.

It was because a method was discovered to bypass the lockout of stolen devices.

Lots of CPUs that have secure enclaves have a section of memory that can be written to only once. It's generally used for cryptographic keys, serials, etcetera. It's also frequently used like this.

Fuses are there on all phones since 25+ years ago, on the real phone CPU side. With trusted boot and shit. Otherwise you could change IMEI left and right and it's a big no-no. What you interact with runs on the secondary CPU -- the fancy user interface with shiny buttons, but that firmware only starts if the main one lets it.

This is in the Qualcomm SOC chip, so it's not something that has to be designed into the phone per se.

Standard?? The standard is for the upgrade to be refused or not boot until you flash a newer one, not to brick the phone permanently. It's not an "ideally" thing for the manufacturer to not intentionally brick your device you bought and paid for.

What's being attacked in this particular case?

The closest thing you can get is probably the Pixel, ironically. You can provision your own keys, enroll it into AVB, and re-lock the bootloader. From the phone hardware's perspective there is no difference between your key and Google's. No fuse is ever blown.

So this article isn't about a kill switch, just blocking downgrades and custom ROMs.

But to answer your question: we know iPhones have a foolproof kill switch, it's a feature. Just mark your device as lost in Find My and it'll be locked until someone can provide your login details. Assuming it requires logging in to your Apple account (which it does, AFAIK; I don't think logging in to a local account is enough), this is the same as a remote kill switch; Apple could simply make a device enter this locked-down state and then tweak their server systems to deny logins.

Apple has been doing that since forever and will remotely kill switch devices so they need to be destroyed instead of reused: https://fighttorepair.substack.com/p/activation-locks-send-w...

Millions of fully working apple devices are destroyed because of that even - Apple won't unlock them even with proof of ownership.

I'd say for commercial hardware it is a near certainty even if you won't ever know until it is much too late.

Realize that many of these manufacturers sell their hardware in and employ companies in highly policed societies. Just the fact that they are allowed to continue to operate implies that they are playing ball and may well have to perform a couple of favors. And that's assuming they are fully aware of what they are shipping, which may not be always the case.

I don't think it is a bad model at all to consider any cell phone to be compromised in multiple ways even though you don't have hard proof.

It's there on all phones since forever lol. Apple can ship an update that adds "update without asking for confirmation" tomorrow and then ship another one that shows nothing but a middle finger on boot and you would not be able to do anything, including downgrading back.

The M-series CPUs found in iPads (which cannot boot custom payloads) are the same as the M-series CPUs found in Macbooks (which can boot custom payloads) - just with different fuses pre-burnt during manufacturing.

Pre-prod (etc.) devices will also have different fuses burnt.

iPhones already cannot be downgraded, they can only install OS versions signed by apple during the install time. (search SHSH blobs) They also can't run unsigned IPA files (apps). Not sure if they have a physical fuse, but it's not much different.

They patched a low-level vulnerability in their boot process. Their phones' debug features would allow attackers to load an old, unpatched version of their (signed) software and exploit it if they didn't do some kind of downgrade prevention.

Using eFuses is a popular way of implementing downgrade prevention, but also for permanently disabling debug flags/interfaces in production hardware.

Some vendors (AMD) also use eFuses to permanently bond a CPU to a specific motherboard (think EPYC chips for certain enterprise vendors).

They can kill custom roms and force the latest vendor firmware. If they push a shitty update that slows down the phone or something, users have no choice other than buying a new device.

Samsung uses this for their Knox security feature. The fuse gets broken in initial bootloader unlock, and all features related to Knox (Samsung Pay, Secure Folder, etc) gets disabled permanently even after reverting to stock firmware.

I use them in an esp32 to write a random password to each of my products, so when I sell them they can each have their own secure default wifi password while all using the same firmware.

eFuses are in most CPUs, often used for things like disabling hardware debug interfaces in production devices - and rollback prevention.

There are not. The entire premise of eFuses are that after you buy something, the manufacturer can still make changes that you can't ever undo.

> no demand for money

There is when the device becomes hard bricked and triggers an unnecessary need for a new one.

This wasn't their only pain point. [1] Just get off OnePlus, you'll be happier.

[1] https://dontkillmyapp.com/oneplus