61 comments

[ 3.1 ms ] story [ 148 ms ] thread
You either die a hero, or live long enough to see yourself become the villain
OnePlus is a textbook case of that quote
(comment deleted)
Blind speculation: I wonder if this is in some way related to DRM getting broken at a firmware level, leading to a choice being made between "users complain that they can't watch netflix" and "users complain that they can't install custom ROMs".
Why? What advantage do they get from this? I'm assuming it's not a good one but I'm struggling to see what it is at all.
Is this for just one or several OnePlus models?

If so, is this 'fuse' per-planned in the hardware? My understanding is cell phones take 12 to 24 months from design to market. so, initial deployment of the model where this OS can trigger the 'fuse' less one year is how far back the company decided to be ready to do this?

What do OnePlus gain from this? Can someone explain me what are the advantages of OnePlus doing all this? A failed update resulting in motherboard replacement? More money, more shareholders are happy?

I still sometimes ponder if oneplus green line fiasco is a failed hardware fuse type thing that got accidentally triggered during software update. (Insert I can't prove meme here).

OnePlus has pretty much become irrelevant since Carl Pei left the company. Its more or less just a rebranded Oppo nowadays. I'm not an android user anymore but I'm rooting for his new(ish) Nothing company. Hopefully it carries the torch for the old OnePlus feel.
Yup - and worse than that too.

In the last week or two it's been rumoured that Oppo are pulling the plug on OnePlus, and are going to wind up the brand entirely. (Although it may cling on in certain markets, like India).

How likely is it that such software-activated fuse-based kill switches are built into iPhones? Any insights?
100%, if you steal a phone from the Apple store they just remote brick it.
> When the device powers on, the Primary Boot Loader in the processor's ROM loads and verifies the eXtensible Boot Loader (XBL). XBL reads the current anti-rollback version from the Qfprom fuses and compares it against the firmware's embedded version number. If the firmware version is lower than the fuse value, boot is rejected. When newer firmware successfully boots, the bootloader issues commands through Qualcomm's TrustZone to blow additional fuses, permanently recording the new minimum version

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.

It does say

> Custom ROMs package firmware components from the stock firmware they were built against. If a user's device has been updated to a fused firmware version & they flash a custom ROM built against older firmware, the anti-rollback mechanism triggers immediately.

and I know custom ROMs will often say “make sure you flash stock version x.y beforehand” to ensure you’re on the right firmware, but I’m not sure what partitions that actually refers to (and it’s not the same as vendor blobs), or how much work it is to either build a custom ROM against a newer firmware or patch the (hundreds of) vendor blobs.

This goes beyond the 'right to repair' to simply the right of ownership. These remote updates prove again and again that even though you paid for something you don't actually own it.
When a remote update can irreversibly change hardware state, ownership becomes conditional
It's my first time hearing about this "eFuse" functionality in Qualcomm CPUs. Are there non-dystopian uses for this as a manufacturer?
Almost every modern SoC has efuse memory. For example, this is used for yield management - the SoC will have extra blocks of RAM and expect some % to be dead. At manufacturing time they will blow fuses to say which RAM cells tested bad.
(comment deleted)
According to OP this does not disable bootloader unlocking in itself. It makes the up-versioned devices incompatible with all previous custom ROMs, but it should be possible to develop new ROM releases that are fully compatible with current eFuse states and don't blow the eFuse themselves.
I wonder, is there currently unpublished 0day on the SoC and they're forcing use of the latest firmware to ensure they're not vulnerable once the details become public? That would be a reason for suddenly introducing this without explanation.
This is industry standard. Flashing old updates that are insecure to bypass security is a legitimate attack vector that needs to be defended against. Ideally it would still be possible up recover from such a scenario by flashing the latest update.
Its high time we start challenging these sorts of actions as the "vandalization and sabotage at scale" that these attacks really are. I dont see how these aren't a direct violation of the CFAA, over millions of customer-owned hardware.

They are no different than some shit ransomware, except there is no demand for money. However, there is a demonstrable proof of degradation and destruction of property in all these choices.

Frankly, criminal AND civil penalties should be levied. Criminally, the C levels and boars of directors should all be in scope as to encouraging/allowing/requiring this behavior. RICO act as well, since this smells like a criminal conspiracy. Let them spend time in prison for mass destruction of property.

Civally, start dissolving assets until the people are made whole with unbroken (and un-destroyed) hardware.

The next shitty silly-con valley company thinks about running this scam of 'customer-bought but forever company owned', will think long and hard about the choices of their network and cloud.

This is absolutely cracked. I've been with OnePlus since the One, also getting the 2, 6 and now I have the 12. Stuck with them all these years because I really respected their - original - take on device freedom. I really should've seen the writing on the wall given how much pain it is to update it in the first place, as I have the NA version which only officially allows carrier updates, and I don't live in NA (and even if I did I'd still not be tied to a carrier).

Now I have to consider my device dead re updates, because if I haven't already gotten the killing update I'd rather avoid it. First thing I did was unlock the bootloader, and I intend to root/flash it at some point. Will be finding another brand whenever I'm ready to upgrade again.

isnt this just like... vandalism? nothing could give them the right to do this, they're damaging others property indescriminately.
(comment deleted)
im sure that is not going to improve their sales numbers
Glad I didn't give these people any of my hard earned dollars.
I'm not sure if this is the case anymore, but many unbranded/generic Androids used to be completely unlocked by default (especially Mediatek SoCs) and nearly unbrickable, and that's what let the modding scene flourish. I believe they had efuses too, but software never used them.
I look forward to the 1hr+ rant from Louis Rossmann.
How hard is it to fix a fuse with a microscope and a steady hand?
Very hard. FIB is the only known way to do this but even then, that's the type of thing where you start with a pile of SoCs and expect to maybe get lucky with one in a hundred. A FIB machine is also millions of dollars.
So that’s how in an event of war US adversaries will be relieved of their devices

> The anti-rollback mechanism uses Qfprom (Qualcomm Fuse Programmable Read-Only Memory), a region on Qualcomm processors containing one-time programmable electronic fuses.

What a nice thoughtful people to build such a feature.

That’s why you sanction the hell out of Chinese Loongson or Russian Baikal pity of CPU — harder to disable than programmatically “blowing a fuse”.

This is absurdly paranoid with absolutely zero evidence. For embedded and mobile threat models where physical access or bootloader unlock is possible, eFuses are effectively mandatory for robust downgrade prevention
Baikal definitely has anti-rollback, and Loongson should have it too. That's a common feature.

As of efuses, they are present essentially anywhere. In any SoC and microcontroller. They are usually used to store secrets (keys) and for chip configuration.

The linked wiki article written in a way that the reader might assume that OnePlus did something wrong, unique, anti-consumer, or something along the lines. Quite the contrary: OnePlus issued updated official firmware with burned the anti-rollback bit to prevent older vulnerable official firmware from being installed. Either new bootloader-level vulnerability has been found, or some kind of bootloader-level secret has leaked from OnePlus, with which the attacker can gain access to the smartphone's data it should not have. By this update, OnePlus secured data of the smartphone owners again.

You still can unlock the bootloader and install custom firmware (with bumped anti-rollback version in the firmware metadata I guess, that would require newer custom firmware or a recompilation/header modification for the older). Your device with the custom firmware installed won't receive the official firmware update to begin with, so it could not be bricked.

Does anyone know if it has been confirmed that this only applies to the "ColorOS" branded firmware versions? Because I currently have an update to OxygenOS 16.0.3.501 pending on my OnePlus 15, which is presumably built from the same codebase.

Edit: It seems that this does apply to OxygenOS too: https://xdaforums.com/t/critical-warning-coloros-16-0-3-501-...

Does intentionally physically damaging a device fall foul of any laws that a software restriction otherwise wouldn't?