[HN Gopher] Oneplus phone update introduces hardware anti-rollback
___________________________________________________________________
Oneplus phone update introduces hardware anti-rollback
Author : validatori
Score : 254 points
Date : 2026-01-25 20:39 UTC (2 hours ago)
(HTM) web link (consumerrights.wiki)
(TXT) w3m dump (consumerrights.wiki)
| raizer88 wrote:
| You either die a hero, or live long enough to see yourself become
| the villain
| Raed667 wrote:
| I think the writing has been on the wall since they started
| their Nord line.
| alluro2 wrote:
| 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?
| Raed667 wrote:
| Exactly, why did they end up in a situation where they are
| making killers of their "main" phones ?
| zozbot234 wrote:
| 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.
| Sebb767 wrote:
| What was the issue with the Nord line?
| em-bee wrote:
| 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)
| jsheard wrote:
| I think the turning point was when they "merged" their
| Android distro development with Oppo's, which in practice
| meant adopting Oppo's distro with minimal changes. OnePlus
| was always affiliated with Oppo but they used to have a lot
| more independence.
|
| (and yeah, that's also around when the Nord line started)
| Retr0id wrote:
| 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".
| dcdc123 wrote:
| It was because a method was discovered to bypass the lockout of
| stolen devices.
| userbinator wrote:
| In other words the same old boogeyman they always use to
| justify this crap.
| IshKebab wrote:
| 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.
| hexagonwin wrote:
| 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.
| bcraven wrote:
| 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.
| jeroenhd wrote:
| 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).
| WaitWaitWha wrote:
| 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?
| TomatoCo wrote:
| 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.
| Muromec wrote:
| 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.
| scbzzzzz wrote:
| 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).
| TomatoCo wrote:
| 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.
| scbzzzzz wrote:
| 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.
| zozbot234 wrote:
| 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.
| chasil wrote:
| 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.
| cess11 wrote:
| As I understand it, this is a similar thing on Samsung
| handhelds:
|
| https://en.wikipedia.org/wiki/Samsung_Knox
| itsdesmond wrote:
| > 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.
| wnevets wrote:
| > 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.
| userbinator wrote:
| That's even _more_ dystopian.
| Zigurd wrote:
| Carriers can check a registry of stolen phone IMEIs and block
| them from their networks.
| reaperducer wrote:
| 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.
| gsich wrote:
| 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.
| TehCorwiz wrote:
| 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.
| gsich wrote:
| All offers seem to be from the US.
| ddtaylor wrote:
| 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.
| segmondy wrote:
| 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.
| HiPhish wrote:
| > 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.
| lxgr wrote:
| 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.
| lotu wrote:
| 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.
| rvnx wrote:
| 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)
| Muromec wrote:
| > 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.
| drnick1 wrote:
| > 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.
| palata wrote:
| > 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.
| ddtaylor wrote:
| 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.
| jeroenhd wrote:
| 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.
| ddtaylor wrote:
| 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.
| jeroenhd wrote:
| 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.
| syntaxing wrote:
| 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.
| Raed667 wrote:
| 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
| skeledrew wrote:
| 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.
| opan wrote:
| 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.
| zozbot234 wrote:
| 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.
| bflesch wrote:
| How likely is it that such software-activated fuse-based kill
| switches are built into iPhones? Any insights?
| jacquesm wrote:
| 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.
| hexagonwin wrote:
| 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.
| hoistbypetard wrote:
| 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.
| hexagonwin wrote:
| true, but I believe these bricked oneplus devices can also
| be revived from 9008 (EDL) if they can find the qualcomm
| firehorse loader file.
| Retr0id wrote:
| 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.
| mort96 wrote:
| 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.
| Muromec wrote:
| 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.
| tripdout wrote:
| > 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.
| Muromec wrote:
| >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.
| ARob109 wrote:
| 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.
| jacquesm wrote:
| 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.
| mystraline wrote:
| 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.
| amelius wrote:
| Their defense would probably be like: "you clicked Yes on the
| EULA form."
| dataflow wrote:
| As far as legal arguments go, I imagine their first counter
| would be that you agreed to the update, so it's on you.
| mystraline wrote:
| 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.
| bloomingeek wrote:
| 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?
| reaperducer wrote:
| 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.
| Tarball10 wrote:
| Until they switch to eSIM...
| blibble wrote:
| cut the antenna
| jeroenhd wrote:
| ... 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
| 0xbadcafebee wrote:
| 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
| g-b-r wrote:
| 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
| hypeatei wrote:
| It's my first time hearing about this "eFuse" functionality in
| Qualcomm CPUs. Are there non-dystopian uses for this as a
| manufacturer?
| Retr0id wrote:
| eFuses are in most CPUs, often used for things like disabling
| hardware debug interfaces in production devices - and rollback
| prevention.
| hexagonwin wrote:
| 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.
| thesh4d0w wrote:
| 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.
| zozbot234 wrote:
| 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.
| palata wrote:
| 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"?
| Muromec wrote:
| People need to re-sign their releases and include the newer
| version of bootloader, more or less.
| charcircuit wrote:
| 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.
| mystraline wrote:
| 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.
| skeledrew wrote:
| > no demand for money
|
| There is when the device becomes hard bricked and triggers an
| unnecessary need for a new one.
| skeledrew wrote:
| 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.
| dataflow wrote:
| This wasn't their only pain point. [1] Just get off OnePlus,
| you'll be happier.
|
| [1] https://dontkillmyapp.com/oneplus
| BeetleB wrote:
| What are good alternatives that aren't Pixel?
| palata wrote:
| For now, Pixels. I'm waiting to see what non-Pixel phone
| will be supported by GrapheneOS next, but this may take a
| while.
| RugnirViking wrote:
| isnt this just like... vandalism? nothing could give them the
| right to do this, they're damaging others property
| indescriminately.
| jijji wrote:
| im sure that is not going to improve their sales numbers
| pengaru wrote:
| Glad I didn't give these people any of my hard earned dollars.
| userbinator wrote:
| 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.
| 1a527dd5 wrote:
| I look forward to the 1hr+ rant from Louis Rossmann.
| poizan42 wrote:
| He has already made the video on this, but it is only 3:23:
| https://youtu.be/3AiRB5mvEsk?si=XapAHhHRJtssDI4F
| mycall wrote:
| How hard is it to fix a fuse with a microscope and a steady hand?
| piskov wrote:
| 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".
| rwmj wrote:
| 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.
| Muromec wrote:
| 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.
| piskov wrote:
| > It's not even new, it was still there on p2k motorollas 25
| years ago.
|
| I'm sure CIA was not founded after covid :-)
| obnauticus wrote:
| Uhh...Wut?
| pdpi wrote:
| 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.
| poizan42 wrote:
| 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.
| InsomniacL wrote:
| Does intentionally physically damaging a device fall foul of any
| laws that a software restriction otherwise wouldn't?
| plutokras wrote:
| Nintendo has been doing this for ages.
|
| https://news.ycombinator.com/item?id=30773214
| geor9e wrote:
| 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. Even cheapo devices often use an eFuse as anti-
| rollback, so you can't go back to older firmware. We do it at my
| work whenever root exploits are found. If we don't do it, then it
| becomes trivial for someone to decrypt and steal your personal
| data from your little gizmos with a USB cable, by flashing old
| signed firmware and using the exploit.
___________________________________________________________________
(page generated 2026-01-25 23:00 UTC)