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.
If the user doesn't trust an operating system, why would they use it. The operating system can steal sensitive information. Trusted computing is trusted by the user to the extent that they use the device. For example if they don't trust it, they may avoid logging in to their bank on it.
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.
Yeah, not disagreeing with you. It's just that, every time we have this discussion, we see comments like GP's rebutted by comments like yours, and vice versa.
All I'm saying is that we have to acknowledge that both are true. And, if both are true, we need to have a serious conversation about who gets to choose the core used in our front door locks.
Not only can, but inevitably is. Security folks - especially in mobile - are commonly useful idiots for introducing measures which are practically immediately coopted to take away users ability to control their device and modify it to serve them better. Every single time.
You can't have that with phones. You are always at the mercy of the hardware supplier and their trusted boot chain that starts with the actual phone processor (the one running GSM stuff, not user interface stuff). That one is always locked down and decides to boot you fancy android stuff.
The fact that it's locked down and remotely killable is a feature that people pay for and regulators enforce from their side too.
At the very best, the supplier plays nice and allows you to run your own applications, remove whatever crap they preinstalled and change to font face. If you are really lucky, you can choose to run practically useless linux distribution instead of practically useful linux distribution with their blessing. Blessing is a transient thing that can be revoked any time.
There are some open firmware, or partially open firmware projects, but they're more proof-of-concepts and not popular/widely-used. The problem is the FCC or corresponding local organization requires cell phones get regulatory approval, and open firmware (where just anybody could just download the source and modify a couple of numbers to violate regulations) doesn't jive with that.
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.
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.
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?
Hahah, I just traded in 2023 (unrelated brand) for 2012 model since it was less of a computer. Computer systems in the newer car kept having faults that caused sporadic electrical issues workshops couldn’t fix. I just want my car to be a car and nothing else.
... and get a Check Engine light+fault code for the built-in emergency SOS feature, thereby making it unable to pass vehicle inspection until you fix the antennae
so either 1) disconnect it most of the time and reconnect it for inspections, or 2) buy a dummy load RF terminator matching the resistance of your antenna
OnePlus and other Chinese brands were modders-friendly until they suddenly weren't, I wouldn't rely on your car not getting more hostile at a certain point
A phone without SIM can still be used to call emergency services (911/999/0118999 8819991197253). The situation we're discussing though is an attack by an extremely-APT. You really think not having the SIM card is going to do anything? If the cell phone hardware is powered up, it's available. All the APT has to do is have put their code into the baseband at some point, maybe at the Volvo factory when the car was programmed, and get the cooperation of a cell-phone tower, or use a Stingray to report where the car is when in range.
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.
A forced update or continual loop of "yes" or "later" is not consent. The fact that there is no "No" option shows that.
Fabricated or fake consent, or worse, forced automated updates, indicates that the company is the owner and exerting ownership-level control. Thus the sale was fraudulently conducted as a sale but is really an indefinite rental.
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.
right, but the stolen phones get sold in other countries where the carriers don't care if the phone was stolen but care that someone is spending money on their service.
I the lines between IMEI banning or blacklisting and the modern unlocking techniques they use have been blurred a little bit and so some carriers and some manufacturers don't really want to do or spend time doing the IMEI stuff and would prefer to just handle it all via their own unlocking and locking mechanisms.
Visit eBay and search for "blocked IMEI" or variants. There are plenty of used phones which are IMEI locked due to either: reported lost, reported stolen, failed to make payments, 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.
I don't think so. Blowing a fuse is just how the "no downgrades" policy for firmware is implemented. No different for other vendors actually, though the software usually warns you prior to installing an update that can't be manually rolled back.
> It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
You absolutely do not, this is an extremely healthy starting position for evaluating a corporations behavior. Any benefit you receive is incidental, if they made more money by worsening your experience they would.
> 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.
Which is why I mentioned that carriers or Google might have that as a requirement for partnering with them. iPhones are rarely stolen these days because there's no resale market for them (to the detriment of third party repairs). It behooves large market players, like Google or carriers, to create the same perception for Android phones.
Thieves don't do that research to specific models. Manufacturers don't like it if their competitors' models are easy to hawk on grey markets because that means their phones get stolen, too.
It actually seems to work pretty well for iPhones.
Thieves these days seem to really be struggling to even use them for parts, since these are also largely Apple DRMed, and are often resorting to threatening the previous owner to remove the activation lock remotely.
Of course theft often isn't preceded by a diligent cost-benefit analysis, but once there's a critical mass of unusable – even for parts – stolen phones, I believe it can make a difference.
Yes thieves do, research on which phones to steal. Just not online more in personal talking with their network of lawbreakers. In short a thief is going to have a fence, and that person is going to know all about what phones can and cannot be resold.
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.
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.
Not really dramatic IMO. Basically mirrors everything we have seen in other industries like gaming consoles, etc. that have destroyed ownership over time in favor of "service models" instead.
Sure if you want to compete against Google or Samsung. Maybe that is the plan that one plus has. My understanding was that they were going after a different Market of phone users that might want a little bit more otherwise why not just go with one of the other people that will screw you just as hard for less.
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)
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"?
Yes, though noting that since the antirollback is apparently implemented by the bootloader itself on this Qualcomm SoC, this will blow the fuse on devices where the new version is installed, so the unofficial EDL-mode tools that the community seems to be most concerned about will still be unavailable, and users will still be unable to downgrade from the newer to older custom ROM builds.
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.
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.
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?
Because all midrange phones are "flagship killers" on a features basis now, flagships are just about the exclusivity. The market has adapted and the term no longer makes much sense. OnePlus still leads on custom ROM support though, e.g. no special codes or waiting times needed for unlocking the bootloader, it all works out of the box with standard commands.
yeah, i'd like to know that too. i have a oneplus nord running /e/OS and i am quite happy with it. in fact it's probably the best phone i had so far performance wise (i got it refurbished at a very good price which may have something to do with that though)
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.
> 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.
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.
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.
Yeah I'm surprised that they announced it but not the vendor name. I'm sure Google with their infinite resources already know which vendor it is. So who are they hiding it from?
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?
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.
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'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..
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 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.
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.
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.
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.
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.
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.
This is the only way I could come up with that would allow an end user to do a full factory reset, and end up back in a known good secure state afterwards.
Storing it in the firmware would mean every user has the same key. Storing it in eeprom means a factory reset will clear it. This allows me to ship hardware with the default key on a sticker on the side, and let's a non technical user reset it back to that if they need to.
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.
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.
If the user doesn't trust an operating system, why would they use it. The operating system can steal sensitive information. Trusted computing is trusted by the user to the extent that they use the device. For example if they don't trust it, they may avoid logging in to their bank on it.
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.
Fair enough, but so does your front door. Either thing is not smart enough to judge the legitimacy of ownership transitions.
Yeah, not disagreeing with you. It's just that, every time we have this discussion, we see comments like GP's rebutted by comments like yours, and vice versa.
All I'm saying is that we have to acknowledge that both are true. And, if both are true, we need to have a serious conversation about who gets to choose the core used in our front door locks.
Not only can, but inevitably is. Security folks - especially in mobile - are commonly useful idiots for introducing measures which are practically immediately coopted to take away users ability to control their device and modify it to serve them better. Every single time.
We just had the Google side loading article here.
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.
You can't have that with phones. You are always at the mercy of the hardware supplier and their trusted boot chain that starts with the actual phone processor (the one running GSM stuff, not user interface stuff). That one is always locked down and decides to boot you fancy android stuff.
The fact that it's locked down and remotely killable is a feature that people pay for and regulators enforce from their side too.
At the very best, the supplier plays nice and allows you to run your own applications, remove whatever crap they preinstalled and change to font face. If you are really lucky, you can choose to run practically useless linux distribution instead of practically useful linux distribution with their blessing. Blessing is a transient thing that can be revoked any time.
> You can't have that with phones.
Why not?
Obviously we don't have that. But what stops an open firmware (or even open hardware) GSM modem being built?
There are some open firmware, or partially open firmware projects, but they're more proof-of-concepts and not popular/widely-used. The problem is the FCC or corresponding local organization requires cell phones get regulatory approval, and open firmware (where just anybody could just download the source and modify a couple of numbers to violate regulations) doesn't jive with that.
https://hackaday.com/2022/07/12/open-firmware-for-pinephone-...
Of course you can have that.
The governments can ban this feature and ban companies from selling devices with that.
Not true on the pinephone, the modem is a peripheral module, so the boot chain does not start with it.
> It's not even new, it was still there on p2k motorollas 25 years ago.
I’m sure CIA was not founded after covid :-)
Uhh…Wut?
>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
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.
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.
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.
Hahah, I just traded in 2023 (unrelated brand) for 2012 model since it was less of a computer. Computer systems in the newer car kept having faults that caused sporadic electrical issues workshops couldn’t fix. I just want my car to be a car and nothing else.
Until they switch to eSIM...
cut the antenna
... and get a Check Engine light+fault code for the built-in emergency SOS feature, thereby making it unable to pass vehicle inspection until you fix the antennae
so either 1) disconnect it most of the time and reconnect it for inspections, or 2) buy a dummy load RF terminator matching the resistance of your antenna
Chinese-owned Volvo?
OnePlus and other Chinese brands were modders-friendly until they suddenly weren't, I wouldn't rely on your car not getting more hostile at a certain point
A phone without SIM can still be used to call emergency services (911/999/0118999 8819991197253). The situation we're discussing though is an attack by an extremely-APT. You really think not having the SIM card is going to do anything? If the cell phone hardware is powered up, it's available. All the APT has to do is have put their code into the baseband at some point, maybe at the Volvo factory when the car was programmed, and get the cooperation of a cell-phone tower, or use a Stingray to report where the car is when in range.
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.
A forced update or continual loop of "yes" or "later" is not consent. The fact that there is no "No" option shows that.
Fabricated or fake consent, or worse, forced automated updates, indicates that the company is the owner and exerting ownership-level control. Thus the sale was fraudulently conducted as a sale but is really an indefinite rental.
Their defense would probably be like: "you clicked Yes on the EULA form."
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.
right, but the stolen phones get sold in other countries where the carriers don't care if the phone was stolen but care that someone is spending money on their service.
I have never seen this happen.
I have however experienced that a ISP will write to you because you have a faulty modem (some Huawei device) and asks you to not use it anymore.
I the lines between IMEI banning or blacklisting and the modern unlocking techniques they use have been blurred a little bit and so some carriers and some manufacturers don't really want to do or spend time doing the IMEI stuff and would prefer to just handle it all via their own unlocking and locking mechanisms.
Visit eBay and search for "blocked IMEI" or variants. There are plenty of used phones which are IMEI locked due to either: reported lost, reported stolen, failed to make payments, etc.
All offers seem to be from the US.
There is a surprising number of carriers in the world that don't care if you're using a stolen phone.
Not surprisingly, stolen phones tend to end up in those locations.
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.
I don't think so. Blowing a fuse is just how the "no downgrades" policy for firmware is implemented. No different for other vendors actually, though the software usually warns you prior to installing an update that can't be manually rolled back.
Are you quite certain?
Google pushed a non-downgradable final update to the Pixel 6a.
I was able to install Graphene on such a device. Lineage was advertised and completely incompatible, but some hinted it would work.
> It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
You absolutely do not, this is an extremely healthy starting position for evaluating a corporations behavior. Any benefit you receive is incidental, if they made more money by worsening your experience they would.
As I understand it, this is a similar thing on Samsung handhelds:
https://en.wikipedia.org/wiki/Samsung_Knox
> 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.
That's even more dystopian.
> 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.
Which is why I mentioned that carriers or Google might have that as a requirement for partnering with them. iPhones are rarely stolen these days because there's no resale market for them (to the detriment of third party repairs). It behooves large market players, like Google or carriers, to create the same perception for Android phones.
Thieves don't do that research to specific models. Manufacturers don't like it if their competitors' models are easy to hawk on grey markets because that means their phones get stolen, too.
It actually seems to work pretty well for iPhones.
Thieves these days seem to really be struggling to even use them for parts, since these are also largely Apple DRMed, and are often resorting to threatening the previous owner to remove the activation lock remotely.
Of course theft often isn't preceded by a diligent cost-benefit analysis, but once there's a critical mass of unusable – even for parts – stolen phones, I believe it can make a difference.
Yes thieves do, research on which phones to steal. Just not online more in personal talking with their network of lawbreakers. In short a thief is going to have a fence, and that person is going to know all about what phones can and cannot be resold.
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.
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.
Not really dramatic IMO. Basically mirrors everything we have seen in other industries like gaming consoles, etc. that have destroyed ownership over time in favor of "service models" instead.
And now governments are starting to take advantage of that loss of control by demanding surveillance tech like chatcontrol and other backdoors.
> 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.
Sure if you want to compete against Google or Samsung. Maybe that is the plan that one plus has. My understanding was that they were going after a different Market of phone users that might want a little bit more otherwise why not just go with one of the other people that will screw you just as hard for less.
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)
> 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.
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.
Yes, though noting that since the antirollback is apparently implemented by the bootloader itself on this Qualcomm SoC, this will blow the fuse on devices where the new version is installed, so the unofficial EDL-mode tools that the community seems to be most concerned about will still be unavailable, and users will still be unable to downgrade from the newer to older custom ROM builds.
Not being able to downgrade and using the debug tools was the exact point of doing this thing, as far as I understand.
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.
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.
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?
Exactly, why did they end up in a situation where they are making killers of their "main" phones ?
Because all midrange phones are "flagship killers" on a features basis now, flagships are just about the exclusivity. The market has adapted and the term no longer makes much sense. OnePlus still leads on custom ROM support though, e.g. no special codes or waiting times needed for unlocking the bootloader, it all works out of the box with standard commands.
What was the issue with the Nord line?
yeah, i'd like to know that too. i have a oneplus nord running /e/OS and i am quite happy with it. in fact it's probably the best phone i had so far performance wise (i got it refurbished at a very good price which may have something to do with that though)
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.
> 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.
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-...
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
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
What are good alternatives that aren't Pixel?
For now, Pixels. I'm waiting to see what non-Pixel phone will be supported by GrapheneOS next, but this may take a while.
Yeah I'm surprised that they announced it but not the vendor name. I'm sure Google with their infinite resources already know which vendor it is. So who are they hiding it from?
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?
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.
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.
isnt this just like... vandalism? nothing could give them the right to do this, they're damaging others property indescriminately.
Nintendo has been doing this for ages.
https://news.ycombinator.com/item?id=30773214
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..
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.
This is in the Qualcomm SOC chip, so it's not something that has to be designed into the phone per se.
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.
How hard is it to fix a fuse with a microscope and a steady hand?
Glad I didn't give these people any of my hard earned dollars.
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.
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.
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.
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.
true, but I believe these bricked oneplus devices can also be revived from 9008 (EDL) if they can find the qualcomm firehorse loader file.
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.
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.
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?
This is the only way I could come up with that would allow an end user to do a full factory reset, and end up back in a known good secure state afterwards.
Storing it in the firmware would mean every user has the same key. Storing it in eeprom means a factory reset will clear it. This allows me to ship hardware with the default key on a sticker on the side, and let's a non technical user reset it back to that if they need to.
It gives you a 256bit block to work with - https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
But couldn't you also just set aside a bit of the EEPROM your factory reset skips, and accomplish the same thing?
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.
im sure that is not going to improve their sales numbers
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.