OnePlus claimt dat maatregelen tegen downgraden tijdelijk zijn

De maatregelen die OnePlus heeft genomen tegen het downgraden van apparaten zijn tijdelijk, zegt een woordvoerder tegen Android Authority. Volgens de woordvoerder was de maatregel tijdelijk nodig om de veiligheid van apparaten te verbeteren.

OnePlus introduceerde de Anti Rollback-functie vorige week op onder meer de OnePlus 13, 13T en 15. Daardoor werden apparaten onbruikbaar als gebruikers probeerden de software te downgraden of een custom rom te installeren. Een woordvoerder van het Chinese bedrijf zegt tegenover Android Authority dat het gaat om een tijdelijke maatregel: "Om de beveiliging van apparaten verder te versterken, hebben we de mogelijkheid om te downgraden van softwareversie 16.0.2.50x naar oudere versies tijdelijk uitgeschakeld."

"We zullen de mogelijkheid om te downgraden in onze volgende reguliere software-update herstellen, maar in de tussentijd kunnen klanten die willen downgraden rechtstreeks contact opnemen met de klantenservice van OnePlus", vervolgt de woordvoerder. Ook gebruikers die hun apparaat hebben gebrickt door te downgraden, wordt aangeraden contact op te nemen met de klantenservice.

De verklaring vanuit OnePlus is opvallend, aangezien Droidwin eerder schreef dat het om een hardwarematige ingreep ging. Volgens het medium gaat het om een e-fuse op het moederbord die doorbrandt als gebruikers de upgrade uitvoeren. Daarmee zou het vervangen van het moederbord volgens Droidwin de enige manier zijn om de functionaliteit te herstellen.

De OnePlus 15R.
De OnePlus 15R

Door Imre Himmelbauer

Redacteur

28-01-2026 • 17:28

21

Submitter: KipKroket

Reacties (21)

Sorteer op:

Weergave:

Een hardwarematige e-fuse die "tijdelijk" is? Dat is natuurkundig best knap.


​Dit statement van OnePlus rammelt aan alle kanten. Als de eerdere technische analyses van Droidwin en XDA kloppen en gezien de hoeveelheid hard bricks lijkt dat wel het geval gaat het hier om een fysieke e-fuse (Qfuse) in de processor/XBL die doorbrandt.


​Een doorgebrande zekering kun je niet met een software-update "herstellen". Een 1 wordt nooit meer een 0.


​Er zijn hier maar twee opties:
  • Ze logen over de e-fuse: Het was toch een softwarematige lock, maar dan wel eentje die zo slecht geïmplementeerd was dat telefoons onherstelbaar brickten en EDL-tools niet meer werkten.
  • Damage Control: De zekering is wel degelijk kapot, maar de "fix" in de volgende update zal simpelweg zijn dat de nieuwe bootloader de status van die zekering negeert (of de controle versoepelt).
​Dat laatste lijkt het meest waarschijnlijk, vooral gezien het advies aan slachtoffers:
"Ook gebruikers die hun apparaat hebben gebrickt door te downgraden, wordt aangeraden contact op te nemen met de klantenservice."
"Contact opnemen" is bij dit soort hard bricks meestal codetaal voor: "Stuur maar op, we moeten je moederbord vervangen (RMA)." Als het simpelweg softwarematig te fixen was via een update of tooltje, hadden ze dat wel vrijgegeven in plaats van hun supportafdeling te belasten.


​Dat ze dit nu "tijdelijk" noemen, klinkt vooral als paniekvoetbal omdat de community (en de grijze importhandel) in opstand komt.

[Reactie gewijzigd door BlazingKahn35 op 28 januari 2026 17:53]

Heeft OnePlus ueberhaupt iets gezegd over eFuses? Kan zelf niks daarover vinden, dus ook geen leugens.
Vooral anderen hebben daar vanalles over gezegd.
OnePlus zegt nu dat de antirollback tijdelijk is, niet de eFuse.
Hoe ze dat voor mekaar krijgen (met eFuses of niet) lijkt me onbelangrijk.
Al lijkt het idd wel via eFuses te gaan, waardoor je ws de bootloader niet meer kan downgraden naar een te oude.
Niets iets waar ik van wakker zou liggen, zolang er straks maar eoa bootloader is die (custom) ROMs kan booten/downgraden.
Wat natuurlijk nog moet blijken.

[Reactie gewijzigd door N8w8 op 28 januari 2026 19:01]

Hoe ze dat voor mekaar krijgen (met eFuses of niet) lijkt me onbelangrijk.
[...]
Niets iets waar ik van wakker zou liggen, zolang er straks maar eoa bootloader is die (custom) ROMs kan booten/downgraden.
Het "hoe" is in dit geval juist cruciaal, want het bepaalt of je zelf nog de regie hebt over je hardware of niet.
​Als het puur een softwarematige check was, zou je bij een foutieve flash (brick) het toestel simpelweg kunnen redden via de bekende Qualcomm EDL-modus (Emergency Download Mode) met een Firehose programmer. Dat is software: je overschrijft de foute partities en je bent weer up and running.


​Het probleem dat XDA en reparateurs nu constateren, is dat die reddingsmiddelen niet meer werken. Omdat de beveiligingsversie in de hardware (de e-fuse) is opgehoogd, weigert de bootloader (XBL) de handshake met tools die oudere signatures hebben. Het resultaat is een hard brick die je zelf niet meer kunt herstellen; het moederbord moet vervangen worden of er zijn geavanceerde tools nodig die niet publiek zijn.


​Dat OnePlus nu zegt dat de maatregel "tijdelijk" is, betekent in het gunstigste geval dat ze in een toekomstige update de bootloader instrueren om de doorgebrande zekering te negeren. Maar de fysieke verandering in je chip is permanent. Je bent vanaf dat moment dus 100% afhankelijk van de gratie van OnePlus (en of ze die 'negeer'-functie in de bootloader laten zitten) om ooit nog custom ROMs te draaien. Dat is wel degelijk iets om wakker van te liggen als je waarde hecht aan eigenaarschap van je apparaat.
Voor deze update was downgraden geen probleem. Er na wel. En het betreft oudere toestellen. Hoe aannemelijk is het dan dat er in de SOC reeds de e-fuse aanwezig is en deze ook belangrijk is voor het booten? Het klink mij meer als een upgrade die certificaten vervangt en mogelijk een nieuwe recovery software zet. En terug naar een oudere versie hierdoor niet meer mogelijk is. Dit is iets dat bij de bios van moederborden vaker is voorgekomen.
[...] Hoe aannemelijk is het dan dat er in de SOC reeds de e-fuse aanwezig is en deze ook belangrijk is voor het booten? Het klinkt mij meer als een upgrade die certificaten vervangt [...]
Dat is juist heel aannemelijk. Sterker nog, dat is de standaard architectuur van vrijwel alle moderne Qualcomm (Snapdragon) SoCs.


Die QFuses zitten fysiek in elke chip gebakken vanaf de fabriek. Ze zijn onderdeel van de Chain of Trust (Secure Boot). Het mechanisme is er dus altijd al geweest, maar fabrikanten zoals OnePlus kozen er voorheen vaak voor om de specifieke 'Anti-Rollback' (ARB) counters in die fuses niet daadwerkelijk door te branden bij updates. Nu doen ze dat wel.


Het bewijs dat het niet slechts om software/certificaten op de opslag gaat (zoals bij een BIOS update), is het feit dat de EDL-modus (Emergency Download Mode) onbruikbaar wordt.


Als het puur een corrupte partitie of een software-certificaat op de flash-chip was, zou de Primary Bootloader (die 'hardcoded' in de ROM van de CPU zit) nog steeds een 'Firehose' programmer accepteren om de boel te redden. Dat die handshake nu faalt en tools niet meer werken, bevestigt dat de hardware (de CPU zelf) weigert de code te starten omdat de versie in de fysieke zekering hoger is dan de software die je probeert te laden.


Technische analyses op XDA bevestigen dit ook: het gaat specifiek om de "CPU Anti-Rollback Fuse" die de XBL (Secondary Bootloader) security version checkt.
Ok, ja dat is idd wel een dingetje.
Maar ik begrijp dat je voorheen ook al geheime gelekte Firehose tools nodig had om zelf te herstellen.
Nu moet je datzelfde nog steeds hebben, alleen n nieuwere versie.
Als die beschikbaar komen, heb je weer evenveel controle als voorheen?
Laten we dat hopen.
Je moest dus eerst stock volledig geüpdated zijn om vervolgens na die update weer te gaan diwngraden of een custom rom gaan gebruiken?


Zijn er dan echt zoveel mensen die hier de dupe van zijn? Want het klinkt mijn inziens niet heel logisch om bovenstaande stappen in die volgorde te doen, of ik mis iets.

Al met al heel vervelend voor de mensen die wél zijn getroffen! Kan mezelf nog herinneren dat ik mijn OnePlus vroeger een keer gesoftlocked had omdat ik de verkeerde versie had geïnstalleerd, niet wetende dat er een aparte EU versie was (die nog niet uit was op hun Telegram/website). Dat waren een paar avondjes flink aan de gang met ADB... Sindsdien root ik eigenlijk nooit meer. Zie er persoonlijk ook weinig meerwaarde meer van in, behalve een syslevel adblocker!

[Reactie gewijzigd door royzegthoi op 28 januari 2026 18:29]

`hosts`-file based ablocking, system wide inderdaad, is voor mij ook zo'n handige feature. Dat en Viper4Android en het enigzins spyware vrij maken van de software zijn voor mij altijd redenen genoeg geweest om te rooten.

Draai nu GrapheneOS op een Pixel dus dat lost het spyware issue op, maar VPN based ad-blocking is gewoon niet goed genoeg. Lastig met meerdere VPN's en regelmatig knalt 'ie er uit of wordt de app gekilled door de battery optimizer of vind de kernel het niet meer leuk met internet routering bij netwerkwissel 5G simkaart 1 en 2. Gedoe.

Kijken of ik binnenkort maar zelf GrapheneOS builds kan maken maar dat schijnt een stuk makkelijker gezegd te zijn dan gedaan...
Ik heb in Grapheneos gewoon de private dns ingesteld op dns.adguard.com, zie nooit ads. Geen idee of dat secure genoeg voor je is, maar een stuk makkelijker dan eigen builds maken. :Y)
Goede tip, vergeten dat die functie bestond. Ik ga dat eens proberen.
Dat heb ik opgelost met pihole en dns-over-tls. Dan een prive dns instellen.
Ik kan je aanraden om jdsp (jamesdsp) te gebruiken ipv viper4android. De v4a driver is 32 bit, closed source, in zowat een decenium niet geupdatet (alleen de frontend app) en downsampelt alles naar 48kHz.

Bij jdsp kun je alle effecten ook gebruiken zonder alle downsides.

Oh en voor een niet geroote telefoon is wavelet ook heel nice.
Je moest dus eerst stock volledig geüpdated zijn om vervolgens na die update weer te gaan diwngraden of een custom rom gaan gebruiken?
Dit is een reden voor als je voornemens bent om een custom ROM te draaien, dat je dit zo snel mogelijk doet na het aanschaffen van het betreffende toestel. Fabrikanten hebben in het verleden vaker de mogelijkheid hiervoor weggenomen voor bestaande toestellen.
Ik geloof er echt geen snars van! OnePlus was voor mij het merk met goede specs, fijne toestellen en de mogelijkheid om custom roms te draaien. Voor nu heb ik de update volledig op handmatig gezet. Dat voorkomt dat OP iets op MIJN telefoon doet wat ik niet wil. Het enige nadeel is dat OxygenOS regelmatig zeurt over de update.

Ik wacht het even af en als OP dit soort gekke berichten de wereld in blijft sturen dan gaat LineageOS erop.
Kwesite van tijd.

Veel bedrijven doen dat, eerst zieltjes winnen met leuke specifieke features zoals deze en als de userbase groot genoeg is de stap maken naar de massa, prijzen omhoog gooien en alles dichtzetten. OnePlus was misshien net te vroeg hiervoor, voor deze stap.

Tweakers heeft hier zelf ook een artikel over geschreven recent, zie review: Na OPPO en Xiaomi ook OnePlus: waarom telefoonmerken liefhebbers altijd loslaten
MKBHD heeft op zijn youtube kanaal enkele dagen geleden ook een video geplaatst waarin hij uitlegt waarom bedrijven starten met de tech enthousiasts en die dan loslaten ten voordele van de grotere markt.

YouTube: The Downfall of OnePlus will be Studied
Succes met de update volledig op handmatig zetten - heb ik in het verleden een paar keer gedaan bij mijn OP13, omdat er grote battery drain bugs in zaten rond het begin van 2025. Werkt welgeteld 1 week, en daarna gaat 'ie alsnog doodleuk z'n update geforceerd binnenhalen en installeren. Tenzij je root hebt en actief daar zaken blokkeert heeft die hele "manual update" switch totaal geen nut.
Voorlopig heb ik nergens last van, ook niet van de nag dat er een update is. Uitgezet via Developer Tools.
Dan draait de service van OP nog altijd op de achtergrond - het kán even werken, maar ik had dezelfde toggle uit én in de update instellingen van de telefoon zelf automatisch downloaden uitgezet. Alsnog kreeg ik de update voor mijn kiezen zodra OP 'm echt als kritisch bestempelde. In mijn ervaring kun je het nog iets vertragen door update services via ADB uit te zetten (werkte op mijn Samsung goed, maar OP geeft die update service niet goed vrij via ADB, dus dat is al irritant), maar het echt tegenhouden van updates kan enkel met root.
Even goed om te weten eFuses zijn er meestal in twee varianten. Latch Off en auto retry.

Auto retry: na een delay gaat de zekering uit zichzelf proberen op te starten
Latch Off: efuse blijft in uit positie, externe signaal is nodig om te resetten.. <-- dus ja ALS er inderdaad een efuse zit en deze Latch-Off is dan kan het met een update worden "gefixt"
Met andere woorden: we fucked up en we gaan het weer fixen, want we gaan niet wegkomen hiermee.

Om te kunnen reageren moet je ingelogd zijn