This has been a commonplace feature on SOCs for a decade or two now. The comments seem to be taking this headline as out‑of‑the‑ordinary news, phrased as if Oneplus invented it. Even cheapo devices often use an eFuse as anti-rollback. We do it at my work whenever root exploits are found that let you run unsigned code. If we don't blow an eFuse, then those security updates can just be undone, since any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc. I get the appeal of ROMs/jailbreaking/piracy but it relies on running obsolete exploitable firmware. It's not like they're forcing anyone to install the security patch who doesn't want it. This is normal.
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.
The whole point of this is so that when someone steals your phone, they can't install an older vulnerable version of the firmware than can be used to set it back to factory settings which makes it far more valuable for resale.
> any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc
A lot of my phones stopped receiving firmware updates long ago, the manufacturer just simply stopped providing them. The only way to safely use them is to install custom firmware that are still address the problems, and this eFuse thing can be used to prevent custom firmware.
This eFuse is part of the plot to prevent user from accessing open source firmware, it's just that. Your "user safety" jargon cannot confuse people anymore, after all the knowledge people (at least the smart few) has learned during the years.
On most devices, anti-rollback means "older firmware won't boot" or "you lose secure features." Here it seems to mean "try it and you permanently brick the device," with no warning in the updater and no public statement explaining the change
I don't know about most devices, but for all the ones I've messed with, eFuse anti-rollback always "bricked" them if you rolled back. It was a natural consequence of the firmware essentially being a binary with a USB flashing mode, plus a bootloader to continue into the operating system. If the firmware can't load at all due to failing eFuse check, then you can't load into flashing mode. The same thing would happen if you wrote garbage to the bootloader partition. That's enough for customers and journalists to call it "permanantly bricked". There might be some SOC recovery mode that lets you load a newer bootloader into RAM, but it would need some software tooling from the SOC manufacturer, and at that point few customers will figure it out.
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.
Once they have hardware access who cares? They either access my data or throw it in a lake. Either way the phone is gone and I'd better have had good a data backup and a level of encryption I'm comfortable with.
This not only makes it impossible to install your own ROMs, but permanently bricks the phone if you try. That is not something my hardware provider will ever have the choice to make.
It's just another nail in the coffin of general computing, one more defeat of what phones could have been, and one more piece of personal control that consumers will be all too happy to give up because of convenience.
why don't they work the same way PCs do with UEFI and secure boot? where users decide what certificates go in as trusted root, so they can install their own OS? I'm surprised there hasn't been any anti-trust suits over this by competitor ROM makers.
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 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"?
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 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.
A discussion you don't see nearly enough of is that there is a fundamental tradeoff with hardware security features — every feature that you can use to secure your device can also be used by an adversary to keep control once they compromise you.
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.
> they have no way to stop an attacker from loading up the broken firmware to exploit your device
You mean the attacker having a physical access to the device plugging in some USB or UART, or the hacker that downgraded the firmware so it can use the exploit in older version to downgrade the firmware to version with the exploit?
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.
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.
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.
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
Agreed that robust downgrade prevention is necessary. However it's not paranoid at all and the problem isn't limited to eFuses. A network connected device that the vendor ultimately controls is a device that can be remotely disabled at the vendor's whim. It's like a hardware backdoor except it's out in the open and much more capable.
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.
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?
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.
Do you mean because the previous "flagship killer" company now needed a "flagship killer" sub-brand, since they could no longer be categorised as such?
Unfortunately similar things will be mandated by EU law through cyber resiliance act (CRA) in order to ensure tamper free boot of any kind of device sold in the EU from Dec 2027.
Basically breaking any kind of FOSS or repairability, creating dead HW bricks if the vendor ceases to maintain or exist.
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).
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.
Make perfect sense, Thanks kind stranger. Hope it is the reason and not some corporate greed. It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
The effects on custom os community is causing me worried ( I am still rocking my oneplus 7t with crdroid and oneplus used to most geek friendly)
Now I am wondering if there are other ways they could achieved the same without blowing a fuse or be more transparent about this.
> It's in OnePlus's interest to make their phones less appealing for theft,
I don't believe for a second that this benefits phone owners in any way. A thief is not going to sit there and do research on your phone model before he steals it. He's going to steal whatever he can and then figure out what to do with it.
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.
That makes sense, but how would an attacker flash an older version of the firmware in the first place? Don't you need developer options and unlocking + debugging enabled?
thank you for this, I have a follow up question:
Now an attacker can not install an old, vulnerable version.
But couldn't they just install a new, vulnerable version?
Is there something that enforces encryption key deletion in one case and not the other?
> 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.
A bit overdramatic, isn't it? Custom ROMs designed for the new firmware revisions still work fine. Only older ROMs with potentially vulnerable bootloader code cause bricking risks.
Give ROM developers a few weeks and you can boot your favourite custom ROMs again.
Note that Google also forces this indirectly via their "certification" - if the device doesn't have unremovable AVB (requires qualcomm secure boot fuse to be blown) then it's not even allowed to say the device runs Android.. if you see "Android™" then it means secure boot is set up and you don't have the keys, you can't set up your own, so you don't really own the SoC you paid for..
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)
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.
It's Google's fault. I want to buy a smartphone without AVB at all. With no "secure boot" fuse blown (yes I DO know that this is not the same fuse) and ideally I'd want to provision my own keys.
But vendors wouldn't be able to say the device runs "Android" as it's trademarked. AVB is therefore mandatory and in order for AVB to be enforced, you can't really control the device - unlocking the bootloader gives you only partial control, you can't flash your own "abl" to remove AVB entirely.
But I don't want AVB and I can't buy such device for money.. this isn't free market, this is Google monopoly..
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.
That's not really true, there will be a warning shown that "the phone is loading a different operating system" - I've seen that when installing GrapheneOS on my pixel.
But it's not just about that, it's about the fact that I can't flash my own "abl" or the software running in the TrustZone there at all as I don't control the actual signing keys (not custom_avb_key) and I'm not "trusted" by my own device.. There were fuses blown as evident by examining abl with its fastboot commands - many refuse to work saying I can't use it on a "production device". Plus many of those low-level partitions are closed source proprietary blobs..
Yes yes - I DO understand that for most people this warning is something positive, otherwise you could buy a phone with modified software without realizing it and these modifications could make it impossible to restore the original firmware.
> 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.
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.
What exactly is the threat model here of preventing Joe Nobody Famous or Important Poweruser from rooting the hardware they bought and paid for?
If someone has physical access to your phone, you have a lot more to worry about than mere root exploits. And given those who root their devices are far out of the profile of ordinary users, so a specially targeted hack like this is pointless as compared to the regular kind of exploits in apps that can target a wider base.
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".
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.
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.
Nothing phones also allow seamless bootloader unlocking, just like OnePlus. There's been some rumors that OnePlus might be about to exit the market altogether, if so Nothing will probably expand into their niche and beyond their current approach based on "unique" design.
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.
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).
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.
Damn, I just saw that update yesterday on my phone and did not update it for no reason. Turned off auto-update right now until I figure out what to do.
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?
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 does not surprise me from the company that accidentally deleted the widevine L1 certificate on my phone (that never had any third party OS) during an update and could not restore it, nor would it replace the motherboard (for which it claimed it was the only possible fix).
That's insane. If the CPU has enough fuses (which according to the wiki it does) why the h*ck can't they just make it impossible to reflash the >= minimum previously installed version of the OS after preventing the downgrade? Why the hard brick?
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".
"No security features should exist for anyone" is itself fanatically hyperbolic narrative. The primary reason this event has elicited such a reaction is because OnePlus has historically been perceived as one of the brands specifically catering to people that wanted ultimate sovereignty over their devices.
As time goes on, the options available for those that require such sovereignty seem to be thinning to such an extent that [at least absent significant disposable wealth] the remaining options will appear to necessitate adopting lifestyle changes comparable to high-cost religious practices and social withdrawal, and likely without the legal protections afforded those protected classes. Given the "big tech's" general hostility to user agency and contempt for values that don't consent to being subservient to its influence peddling, intense emotional reaction to loss of already diminished traditional allies seem like something that would reasonably viewed compassionately, rather than with hostility.
I’ve posted about this on HN before; I think that there’s a dangerous second-order enshittification going on where people are so jaded by a few bad corporate actions that they believe that everyone is out to get them and hardware is evil. The most disappointing thing to me is that this has led to a complete demolition of curiosity; rather than learning that OTP is an ancient and essential concept in hardware, the brain-enshittification has led to “I see hardware anti-*, I click It’s Evil” with absolutely no thought or research applied.
Given how the opposition has radicalized into "you should own nothing and be happy", it's not surprising.
None of the situations you mentioned are realistic or even worth thinking about for the vast majority of the population. They're just an excuse to put even more control into the manufacturer's hands.
The attack is simple: the attacker downgrades the phone to a version of firmware that has a vulnerability. The attacker then uses the vulnerability to get at your data. Your data is PIN-protected? The attacker uses the vulnerability to disable the PIN lockout and tries all of them.
There's over a 10x difference in fence price between a locked and unlocked phone. That's a significant incentive/deterrent.
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.
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.
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.
They make it clear that this feature is unsupported and it's possible to mess things up. The reason why it's an ideal and not an expectation is that flashing alternate operating systems is done at one's own risk and is unsupported. They have already told the users that they bear no responsibility for what may go wrong if they flash the wrong thing on that device. Flashing incompatible operating systems to the device requires people to be careful and proper care to ensure compatibility before going through with flashing was not done.
The phone. It's the same attacks that secure boot tries to protect against. The issue is that these old, vulnerable versions have a valid signature allowing them to be installed.
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.
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.
The significant difference is that if it were placed into DFU mode and connected to an appropriate device that had access to appropriately signed things, it could be "unbricked" without replacing the mainboard.
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.
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.
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.
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.
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.
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.
This has been a commonplace feature on SOCs for a decade or two now. The comments seem to be taking this headline as out‑of‑the‑ordinary news, phrased as if Oneplus invented it. Even cheapo devices often use an eFuse as anti-rollback. We do it at my work whenever root exploits are found that let you run unsigned code. If we don't blow an eFuse, then those security updates can just be undone, since any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc. I get the appeal of ROMs/jailbreaking/piracy but it relies on running obsolete exploitable firmware. It's not like they're forcing anyone to install the security patch who doesn't want it. This is normal.
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.
The whole point of this is so that when someone steals your phone, they can't install an older vulnerable version of the firmware than can be used to set it back to factory settings which makes it far more valuable for resale.
21 replies →
> any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc
A lot of my phones stopped receiving firmware updates long ago, the manufacturer just simply stopped providing them. The only way to safely use them is to install custom firmware that are still address the problems, and this eFuse thing can be used to prevent custom firmware.
This eFuse is part of the plot to prevent user from accessing open source firmware, it's just that. Your "user safety" jargon cannot confuse people anymore, after all the knowledge people (at least the smart few) has learned during the years.
> and this eFuse thing can be used to prevent custom firmware.
This is not what's happening here, though.
On most devices, anti-rollback means "older firmware won't boot" or "you lose secure features." Here it seems to mean "try it and you permanently brick the device," with no warning in the updater and no public statement explaining the change
I don't know about most devices, but for all the ones I've messed with, eFuse anti-rollback always "bricked" them if you rolled back. It was a natural consequence of the firmware essentially being a binary with a USB flashing mode, plus a bootloader to continue into the operating system. If the firmware can't load at all due to failing eFuse check, then you can't load into flashing mode. The same thing would happen if you wrote garbage to the bootloader partition. That's enough for customers and journalists to call it "permanantly bricked". There might be some SOC recovery mode that lets you load a newer bootloader into RAM, but it would need some software tooling from the SOC manufacturer, and at that point few customers will figure it out.
[dead]
This is a phone with an unlockable bootloader (as they should all be). For such a device,
Reasonable: anti-rollback is enforced when the bootloader is locked
Unreasonable: anti-rollback is enforced when the bootloader is unlocked
Unhinged: attempting a download hard-bricks the 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.
> since any random enemy with hardware access
Once they have hardware access who cares? They either access my data or throw it in a lake. Either way the phone is gone and I'd better have had good a data backup and a level of encryption I'm comfortable with.
This not only makes it impossible to install your own ROMs, but permanently bricks the phone if you try. That is not something my hardware provider will ever have the choice to make.
It's just another nail in the coffin of general computing, one more defeat of what phones could have been, and one more piece of personal control that consumers will be all too happy to give up because of convenience.
[dead]
why don't they work the same way PCs do with UEFI and secure boot? where users decide what certificates go in as trusted root, so they can install their own OS? I'm surprised there hasn't been any anti-trust suits over this by competitor ROM makers.
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 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"?
People need to re-sign their releases and include the newer version of bootloader, more or less.
4 replies →
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.
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 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.
Trusted computing means trusted by the vendor and content providers, not trusted by the user. In that sense I consider it very evil.
23 replies →
A discussion you don't see nearly enough of is that there is a fundamental tradeoff with hardware security features — every feature that you can use to secure your device can also be used by an adversary to keep control once they compromise you.
5 replies →
I’d like to think I’m buying the device, not a seat to use the device, at least if I do not want to use their software.
9 replies →
> It's not even new, it was still there on p2k motorollas 25 years ago.
I’m sure CIA was not founded after covid :-)
2 replies →
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.
> they have no way to stop an attacker from loading up the broken firmware to exploit your device
You mean the attacker having a physical access to the device plugging in some USB or UART, or the hacker that downgraded the firmware so it can use the exploit in older version to downgrade the firmware to version with the exploit?
6 replies →
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.
Isn't this normally done with a GPIO bootstrap?
1 reply →
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.
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.
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.
>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 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
Agreed that robust downgrade prevention is necessary. However it's not paranoid at all and the problem isn't limited to eFuses. A network connected device that the vendor ultimately controls is a device that can be remotely disabled at the vendor's whim. It's like a hardware backdoor except it's out in the open and much more capable.
[dead]
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.
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?
Buy a Volvo. Then you can pop out the SIM card to disable the car's cellular communication. (On mine, located behind the mirror.)
When you really need it, like to download maps into the satnav, you can connect it to your home WiFi, or tether via Bluetooth.
17 replies →
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.
As far as legal arguments go, I imagine their first counter would be that you agreed to the update, so it's on you.
8 replies →
Their defense would probably be like: "you clicked Yes on the EULA form."
When a remote update can irreversibly change hardware state, ownership becomes conditional
You either die a hero, or live long enough to see yourself become the villain
I think the writing has been on the wall since they started their Nord line.
Do you mean because the previous "flagship killer" company now needed a "flagship killer" sub-brand, since they could no longer be categorised as such?
3 replies →
What was the issue with the Nord line?
1 reply →
OnePlus is a textbook case of that quote
Unfortunately similar things will be mandated by EU law through cyber resiliance act (CRA) in order to ensure tamper free boot of any kind of device sold in the EU from Dec 2027.
Basically breaking any kind of FOSS or repairability, creating dead HW bricks if the vendor ceases to maintain or exist.
What's worrying isn't the CRA itself, but that companies may use it as cover to lock things down more than necessary
Shouldn't the EU then escrow keys?
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).
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.
Carriers can check a registry of stolen phone IMEIs and block them from their networks.
8 replies →
Make perfect sense, Thanks kind stranger. Hope it is the reason and not some corporate greed. It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
The effects on custom os community is causing me worried ( I am still rocking my oneplus 7t with crdroid and oneplus used to most geek friendly) Now I am wondering if there are other ways they could achieved the same without blowing a fuse or be more transparent about this.
4 replies →
> It's in OnePlus's interest to make their phones less appealing for theft,
I don't believe for a second that this benefits phone owners in any way. A thief is not going to sit there and do research on your phone model before he steals it. He's going to steal whatever he can and then figure out what to do with it.
3 replies →
> 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.
This makes sense and much less dystopia than some of the other commenters are suggesting.
1 reply →
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.
That makes sense, but how would an attacker flash an older version of the firmware in the first place? Don't you need developer options and unlocking + debugging enabled?
2 replies →
thank you for this, I have a follow up question: Now an attacker can not install an old, vulnerable version. But couldn't they just install a new, vulnerable version? Is there something that enforces encryption key deletion in one case and not the other?
1 reply →
> 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.
A bit overdramatic, isn't it? Custom ROMs designed for the new firmware revisions still work fine. Only older ROMs with potentially vulnerable bootloader code cause bricking risks.
Give ROM developers a few weeks and you can boot your favourite custom ROMs again.
2 replies →
Note that Google also forces this indirectly via their "certification" - if the device doesn't have unremovable AVB (requires qualcomm secure boot fuse to be blown) then it's not even allowed to say the device runs Android.. if you see "Android™" then it means secure boot is set up and you don't have the keys, you can't set up your own, so you don't really own the SoC you paid for..
2 replies →
> In the mind of tech executives
To be fair, they are right: the vast majority of users don't give a damn. Unfortunately I do.
1 reply →
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)
> Not for technical reasons, but because of an arbitrary lock (achieved through signature).
There is a good reason to prevent downgrades -- older versions have CVEs and some are actually exploitable.
1 reply →
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.
It's Google's fault. I want to buy a smartphone without AVB at all. With no "secure boot" fuse blown (yes I DO know that this is not the same fuse) and ideally I'd want to provision my own keys.
But vendors wouldn't be able to say the device runs "Android" as it's trademarked. AVB is therefore mandatory and in order for AVB to be enforced, you can't really control the device - unlocking the bootloader gives you only partial control, you can't flash your own "abl" to remove AVB entirely.
But I don't want AVB and I can't buy such device for money.. this isn't free market, this is Google monopoly..
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.
That's not really true, there will be a warning shown that "the phone is loading a different operating system" - I've seen that when installing GrapheneOS on my pixel.
But it's not just about that, it's about the fact that I can't flash my own "abl" or the software running in the TrustZone there at all as I don't control the actual signing keys (not custom_avb_key) and I'm not "trusted" by my own device.. There were fuses blown as evident by examining abl with its fastboot commands - many refuse to work saying I can't use it on a "production device". Plus many of those low-level partitions are closed source proprietary blobs..
Yes yes - I DO understand that for most people this warning is something positive, otherwise you could buy a phone with modified software without realizing it and these modifications could make it impossible to restore the original firmware.
2 replies →
> 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.
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.
What exactly is the threat model here of preventing Joe Nobody Famous or Important Poweruser from rooting the hardware they bought and paid for?
If someone has physical access to your phone, you have a lot more to worry about than mere root exploits. And given those who root their devices are far out of the profile of ordinary users, so a specially targeted hack like this is pointless as compared to the regular kind of exploits in apps that can target a wider base.
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".
It was because a method was discovered to bypass the lockout of stolen devices.
In other words the same old boogeyman they always use to justify this crap.
3 replies →
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.
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.
Nothing phones also allow seamless bootloader unlocking, just like OnePlus. There's been some rumors that OnePlus might be about to exit the market altogether, if so Nothing will probably expand into their niche and beyond their current approach based on "unique" design.
1 reply →
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.
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).
If this becomes the norm, it effectively ends the idea that you own the hardware you paid for
I look forward to the 1hr+ rant from Louis Rossmann.
He has already made the video on this, but it is only 3:23: https://youtu.be/3AiRB5mvEsk?si=XapAHhHRJtssDI4F
isnt this just like... vandalism? nothing could give them the right to do this, they're damaging others property indescriminately.
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-...
Damn, I just saw that update yesterday on my phone and did not update it for no reason. Turned off auto-update right now until I figure out what to do.
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?
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.
Otherwise you could change IMEI left and right and it's a big no-no.
You can still change the IMEI on many phones if you know how to.
This is in the Qualcomm SOC chip, so it's not something that has to be designed into the phone per se.
This does not surprise me from the company that accidentally deleted the widevine L1 certificate on my phone (that never had any third party OS) during an update and could not restore it, nor would it replace the motherboard (for which it claimed it was the only possible fix).
That's insane. If the CPU has enough fuses (which according to the wiki it does) why the h*ck can't they just make it impossible to reflash the >= minimum previously installed version of the OS after preventing the downgrade? Why the hard brick?
So much ignorance in this thread. There's nothing new here. All manufacturers worth their salt have this feature.
This is ultimately about making the device resistant to downgrade attacks. This is what discourages thieves from stealing your phone.
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.
"No security features should exist for anyone" is itself fanatically hyperbolic narrative. The primary reason this event has elicited such a reaction is because OnePlus has historically been perceived as one of the brands specifically catering to people that wanted ultimate sovereignty over their devices.
As time goes on, the options available for those that require such sovereignty seem to be thinning to such an extent that [at least absent significant disposable wealth] the remaining options will appear to necessitate adopting lifestyle changes comparable to high-cost religious practices and social withdrawal, and likely without the legal protections afforded those protected classes. Given the "big tech's" general hostility to user agency and contempt for values that don't consent to being subservient to its influence peddling, intense emotional reaction to loss of already diminished traditional allies seem like something that would reasonably viewed compassionately, rather than with hostility.
I’ve posted about this on HN before; I think that there’s a dangerous second-order enshittification going on where people are so jaded by a few bad corporate actions that they believe that everyone is out to get them and hardware is evil. The most disappointing thing to me is that this has led to a complete demolition of curiosity; rather than learning that OTP is an ancient and essential concept in hardware, the brain-enshittification has led to “I see hardware anti-*, I click It’s Evil” with absolutely no thought or research applied.
Given how the opposition has radicalized into "you should own nothing and be happy", it's not surprising.
None of the situations you mentioned are realistic or even worth thinking about for the vast majority of the population. They're just an excuse to put even more control into the manufacturer's hands.
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.
The attack is simple: the attacker downgrades the phone to a version of firmware that has a vulnerability. The attacker then uses the vulnerability to get at your data. Your data is PIN-protected? The attacker uses the vulnerability to disable the PIN lockout and tries all of them.
There's over a 10x difference in fence price between a locked and unlocked phone. That's a significant incentive/deterrent.
1 reply →
Glad I didn't give these people any of my hard earned dollars.
Nintendo has been doing this for ages.
https://news.ycombinator.com/item?id=30773214
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.
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.
The article suggests custom roms can just be updated to be 'newer' than this.
At the moment they're 'older' and would class as a rollback, which this fuse prevents.
Does intentionally physically damaging a device fall foul of any laws that a software restriction otherwise wouldn't?
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.
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.
>and you may damage your device permanently
https://service.oneplus.com/us/search/search-detail?id=op588
They make it clear that this feature is unsupported and it's possible to mess things up. The reason why it's an ideal and not an expectation is that flashing alternate operating systems is done at one's own risk and is unsupported. They have already told the users that they bear no responsibility for what may go wrong if they flash the wrong thing on that device. Flashing incompatible operating systems to the device requires people to be careful and proper care to ensure compatibility before going through with flashing was not done.
What's being attacked in this particular case?
The phone. It's the same attacks that secure boot tries to protect against. The issue is that these old, vulnerable versions have a valid signature allowing them to be installed.
How likely is it that such software-activated fuse-based kill switches are built into iPhones? Any insights?
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.
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.
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.
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.
The significant difference is that if it were placed into DFU mode and connected to an appropriate device that had access to appropriately signed things, it could be "unbricked" without replacing the mainboard.
1 reply →
100%, if you steal a phone from the Apple store they just remote brick it.
Example: https://www.techspot.com/news/108318-stolen-iphones-disabled...
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.
You'll need at least an electron microscope... but defeating MCU readout protection using a FIB is actually a thing:
https://www.eag.com/services/engineering/fib-circuit-edit-de...
Costs are what you'd expect for something of this nature.
I thought they were the one okay manufacturer. Guess not.
So OnePlus is no better than the rest of the pack.
How does an eFuse even work?
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.
> no demand for money
There is when the device becomes hard bricked and triggers an unnecessary need for a new one.
im sure that is not going to improve their sales numbers
It's my first time hearing about this "eFuse" functionality in Qualcomm CPUs. Are there non-dystopian uses for this as a manufacturer?
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.
eFuses are in most CPUs, often used for things like disabling hardware debug interfaces in production devices - and rollback prevention.
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.
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.
What advantage do you see from using eFuses and not some other way to store the password?
2 replies →
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.
Oneplus went shit since the 6. Pretty sad, they used to be a great brand...
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.
This wasn't their only pain point. [1] Just get off OnePlus, you'll be happier.
[1] https://dontkillmyapp.com/oneplus
Fascinating. I've had a OnePlus 6 from 2018 until 2023 (all on stock software) and I've not had or noticed any issues like that.
1 reply →
What are good alternatives that aren't Pixel?
2 replies →