OnePlus स्मार्टफोन अपडेट में hardware-level anti-rollback फीचर जोड़ा गया

 (consumerrights.wiki)
1 पॉइंट द्वारा GN⁺ 2026-01-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जनवरी 2026 में जारी किए गए ColorOS 16.0.3.501 firmware में hardware-based anti-rollback फीचर शामिल है, जो पुराने version की installation या custom ROM flashing को स्थायी रूप से ब्लॉक करता है
  • यह अपडेट Qualcomm processor के electronic fuse (eFuse) को physical level पर बदल देता है, जिससे पुराने version को install करने पर device पूरी तरह unusable (hard brick) स्थिति में चला जाता है
  • OnePlus 13, 15, Ace 5 series सहित कई models प्रभावित हुए हैं, और कुछ पुराने models के downgrade packages भी official site से हटा दिए गए हैं
  • XDA forum ने custom ROM users को “.500, .501, .503 version OTA updates से बचें” की चेतावनी दी है, और जिन devices पर यह अपडेट पहले से है उन्हें custom ROM install न करने की सलाह दी है
  • OnePlus और OPPO ने कोई official statement जारी नहीं किया है, और industry में इसे Samsung Knox से कहीं अधिक कड़ा प्रतिबंध माना जा रहा है

घटना का सार

  • जनवरी 2026 में OnePlus द्वारा जारी ColorOS 16.0.3.501 firmware में hardware-level anti-rollback फीचर शामिल पाया गया
    • यह फीचर users को पुराने firmware या custom ROM install करने से स्थायी रूप से रोकता है
    • यह Qualcomm chipset के भीतर Qfprom(Programmable Read-Only Memory) क्षेत्र में मौजूद electronic fuse (eFuse) को ‘blow’ करके उसकी स्थिति बदल देता है
  • fuse एक बार बदल जाने पर उसे software से restore नहीं किया जा सकता, और mainboard replacement ही recovery का एकमात्र तरीका बताया गया है
  • OnePlus ने इस mechanism पर कोई official statement या clarification जारी नहीं किया है

पृष्ठभूमि

  • OnePlus की स्थापना 2013 में Pete Lau और Carl Pei ने की थी, और शुरुआती दौर में CyanogenMod आधारित custom ROM के साथ आए OnePlus One की वजह से modding community में यह लोकप्रिय हुआ
  • बाद में Cyanogen के साथ contract समाप्त होने के बाद कंपनी ने OxygenOS (global) और HydrogenOS (China) विकसित किए
  • 2021 में OPPO के ColorOS के साथ codebase integration के बाद, यह मौजूदा ColorOS-आधारित system में बदल गया

टाइमलाइन

  • 18 जनवरी: ColorOS 16.0.3.501 update के बाद users ने पुराने version पर लौटने की कोशिश में EDL mode (9008) में फंसने और recover न होने की घटनाएं report कीं
  • 19 जनवरी: XDA forum user AdaUnlocked ने CPU fuse damage के सबूत के साथ warning thread पोस्ट किया
    • paid recovery services ने भी “Snapdragon 8 Elite devices पर downgrade न करें” की चेतावनी दी
    • कुछ users ने mainboard replacement आवश्यक होने की reports दीं
  • 19 जनवरी के बाद: OnePlus ने official forum से downgrade firmware links हटा दिए, और OnePlus 12 के packages भी हटा दिए गए
  • 24 जनवरी: AdaUnlocked ने पुष्टि की कि “मौजूदा ROM को उसी version number के साथ दोबारा package किया गया था और उसमें fuse trigger शामिल था”

प्रभावित devices

  • OnePlus 12: ColorOS 16.0.3.500, 15.0.0.862
  • OnePlus 13 / 13T: ColorOS 16.0.3.501, 15.0.0.862
  • OnePlus 15: ColorOS 16.0.3.503
  • OnePlus Ace 5 / Ace 5 Pro: ColorOS 16.0.3.500, 15.0.0.862
  • OPPO Find X7 Ultra, OPPO Pad 4 Pro, OnePlus Pad 2 Pro / Pad 3 भी शामिल हैं
  • 16.0.2.402 या उससे नीचे के versions प्रभावित नहीं हैं, और community ने .500, .501, .503 version OTA से बचने की सलाह दी है
  • Android Authority ने OPPO Find X8 series को high-risk category में रखा है, और OnePlus 11·12 के लिए भी ऐसे update की संभावना बताई है

तकनीकी मेकैनिज़्म

  • Qfprom eFuse एक one-time programmable electronic fuse है, जिसमें voltage pulse के जरिए state ‘0’ से ‘1’ में बदल जाने पर उसे वापस नहीं किया जा सकता
  • boot के समय Primary Boot Loader, XBL(eXtensible Boot Loader) को verify करता है, और अगर firmware version fuse value से कम हो तो boot reject कर देता है
  • नया firmware सामान्य रूप से boot होने पर Qualcomm TrustZone के जरिए अतिरिक्त fuse blow किए जाते हैं, जिससे minimum version value स्थायी रूप से record हो जाती है
  • EDL mode (USB 9008) इस protection को bypass नहीं कर सकता
    • Firehose programmer के लिए OEM signature जरूरी होता है, और fuse पहले ही बदल चुका हो तो यह काम नहीं करता
  • XDA की व्याख्या के अनुसार, “fuse blow” किसी physical damage या heat से नहीं बल्कि logic gate की electrical switching से होता है, जो पुराने software execution path को पूरी तरह बंद कर देता है

custom ROM पर प्रभाव

  • XDA forum ने चेतावनी दी कि “ColorOS 16.0.3.501 या उसके बाद के versions पर मौजूदा custom ROM install करते ही तुरंत hard brick हो सकता है”
  • अधिकतर custom ROMs fuse policy लागू होने से पहले के firmware base पर बने हैं, इसलिए वे नए firmware के साथ compatible नहीं हैं
  • developer AdaUnlocked ने कहा कि custom ROM, ports और GSI projects fuse-enabled devices पर बेकार हो जाएंगे
  • community ने updated devices पर custom ROM install न करने और developers द्वारा नए firmware-based support स्पष्ट होने तक इंतजार करने की सलाह दी है

कंपनी की प्रतिक्रिया

  • 22 जनवरी 2026 तक, OnePlus और OPPO की ओर से कोई official statement, forum reply या SNS mention नहीं आया है
  • 19 जनवरी को official forum से downgrade packages हटाया जाना जानबूझकर उठाया गया कदम माना जा रहा है

अन्य manufacturers से तुलना

  • Samsung Knox भी eFuse-आधारित security फीचर्स इस्तेमाल करता है, लेकिन unofficial firmware install करने पर असर आमतौर पर Samsung Pay और Secure Folder disable होने तक सीमित रहता है
  • Android Authority ने स्पष्ट किया कि OnePlus का तरीका कहीं अधिक सख्त है और boot itself को block कर देता है
  • DroidWin ने कहा कि “EDL flashing कुल users में सिर्फ 1–2% लोग इस्तेमाल करते हैं, लेकिन इसे रोकने के लिए बड़ी संख्या में users को प्रभावित करना तर्कसंगत नहीं है”

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-26
Hacker News की राय

  • यह बात उठी कि युद्ध की स्थिति में अमेरिका के दुश्मन देश इन डिवाइसों से मुक्त हो जाएंगे
    Qualcomm की Qfprom(One-Time Programmable Fuse) सुविधा का ज़िक्र हुआ, जो एक बार लिखे जाने वाला इलेक्ट्रॉनिक fuse है और anti-rollback लागू करने में इस्तेमाल होता है
    इस तरह की सुविधा बनाने को लेकर काफ़ी व्यंग्यात्मक ढंग से इसे ‘बहुत विचारशील’ कहा गया, और यह राय भी आई कि चीन के Loongson या रूस के Baikal जैसे CPU पर प्रतिबंध लगने की एक वजह यह भी है कि इन्हें ऐसे programmatic fuse की तुलना में निष्क्रिय करना कठिन है

    • ऐसे मेकैनिज़्म bootloader downgrade रोकने के लिए मौजूद होते हैं
      भरोसेमंद computing chain में एक बार vulnerability आ जाए तो वह हमेशा के लिए टूट सकती है, इसलिए इसे रोकने के लिए यह व्यवस्था रखी जाती है
      यह 25 साल पहले Motorola p2k के दौर में भी मौजूद एक पुरानी अवधारणा थी, और trusted computing अपने आप में बुरी चीज़ नहीं है, ऐसा मत रखा गया
    • OTP memory लगभग हर security system का एक मुख्य घटक है
      डिवाइस-विशिष्ट key या certificate chain का root इन fuse में hash किया जाता है, ताकि हमलावर पुराना firmware चढ़ाकर vulnerability का फायदा न उठा सके
      उल्टा, कुछ लोगों ने कहा कि हैरानी की बात तो यह है कि अब तक ऐसी सुविधा नहीं थी
    • eFuse बहुत पहले से MCU या processor में manufacturing stage पर इस्तेमाल होने वाली तकनीक है
      उदाहरण के लिए, audio I/O board जैसी स्थिति में जहाँ वही MCU इस्तेमाल हो लेकिन configuration के हिसाब से अलग तरह से काम करना हो, वहाँ eFuse से setting को स्थिर कर दिया जाता है ताकि firmware गलत GPIO सेट न करे
    • एक और सरल तरीका यह भी है कि CPU के अंदर kill switch logic block छिपा दिया जाए, जो किसी खास bit sequence को पहचानते ही सक्रिय हो जाए
    • यह राय भी आई कि चीन RISC-V open source architecture में निवेश इसलिए कर रहा है ताकि ऐसे प्रतिबंधों या बंद तकनीक पर निर्भरता से बचा जा सके

  • यह भी कहा गया कि यह मामला सिर्फ right to repair से आगे बढ़कर सीधे ownership का सवाल है
    remote update के ज़रिये फिर से यह दिखता है कि उपयोगकर्ता वास्तव में डिवाइस का पूरा मालिक नहीं है

    • कारों में भी यही हाल है; उनकी छत पर लगा communication module बंद नहीं किया जा सकता
      निर्माता अगर ईमेल से oil change का समय तक बता रहा है, तो क्या हम सच में कार के ‘मालिक’ हैं, इस पर सवाल उठाया गया
    • खरीद की रसीद मेरे ownership का सबूत है, लेकिन इस तरह का बड़े पैमाने पर remote disablement CFAA(Computer Fraud and Abuse Act) का उल्लंघन है और व्यवहार में fraudulent sale के काफ़ी करीब है, ऐसा दावा किया गया
      अगर management को यह पहले से पता था, तो यह RICO(संगठित अपराध कानून) का मामला भी हो सकता है
      और भले ही मुकदमे में जीत मिल जाए, अंत में शायद “अगले OnePlus फ़ोन पर 10 डॉलर का discount coupon” जैसा कुछ ही मिलेगा, ऐसा निंदक स्वर भी दिखा

  • यह सवाल उठा कि OnePlus को ऐसा करके हासिल क्या होगा
    यह शक भी जताया गया कि कहीं update failure के बाद mainboard replacement बढ़ने से कमाई तो नहीं होती
    और पुराने green line incident को लेकर यह अटकल भी लगी कि शायद software update के दौरान hardware fuse ने गलत तरीके से काम किया हो

    • पहले एक bug था जिसमें चोरी हुआ फ़ोन reset करके फिर से activate किया जा सकता था, और यह कहा गया कि मौजूदा कदम downgrade attack रोकने के लिए है
      यह चोरी-रोध, या carrier·Google की आवश्यकताओं के पालन के लिए किया गया कदम हो सकता है
    • bootloader vulnerability की वजह से physical access के साथ मनचाहा OS boot किया जा सकता था, इसलिए eFuse के ज़रिये downgrade block करना ज़रूरी हो गया
      इसका मतलब custom ROM के इस्तेमाल को पूरी तरह रोकना नहीं है, बल्कि सिर्फ पुराने version वाले ROM को रोकना है
      नए firmware पर आधारित ROM सामान्य रूप से boot हो सकते हैं
      इसलिए अगर ROM developer नए firmware को support करें, तो custom ROM फिर से चल सकेंगे
    • management के नज़रिए से वे hardware पर control उपयोगकर्ता को देना ही नहीं चाहते
      केवल hardware बेचकर पर्याप्त मुनाफ़ा नहीं होता, इसलिए उपयोगकर्ता को अपने OS ecosystem में बाँधकर data collection के ज़रिये लाभ कमाने की संरचना है, ऐसी आलोचना की गई
    • Apple भी इसी तरह 7 दिन बाद downgrade न होने देने की policy रखता है
      OnePlus ने इसे hardware तरीके से लागू किया है, Apple ने signing-आधारित तरीके से
      यह तर्क दिया गया कि उपयोगकर्ता को खुद OS sign करके चलाने का अधिकार मिलना चाहिए
      साथ ही iOS 26 में Apple Watch sync समस्या को लेकर नाराज़गी भी जताई गई

  • इस तरह का eFuse-आधारित anti-rollback SoC में 10~20 साल से सामान्य सुविधा रही है
    root exploit मिलते ही eFuse जलाकर पुराने vulnerable firmware पर वापस जाने से रोकना standard security procedure है
    ROM या jailbreak का आकर्षण समझ में आता है, लेकिन यह मूलतः कमज़ोर पुराने firmware पर निर्भर रहने जैसा है, ऐसा कहा गया

    • लेकिन कुछ उपयोगकर्ताओं ने इसका विरोध करते हुए कहा, “यह सामान्य नहीं है”
      अगर फ़ोन मैंने खरीदा है, तो उसमें कौन-सा software चलेगा यह तय करने का अधिकार मेरा होना चाहिए
      अगर कोई update मेरा data किसी दूसरे देश भेजता है, तो मुझे पुराने version पर लौटने की आज़ादी होनी चाहिए
      लेकिन यह बदलाव उस आज़ादी को रोकता है, और कोशिश करने पर फ़ोन brick हो जाता है

  • OP के अनुसार यह बदलाव bootloader unlock को खुद नहीं रोकता
    लेकिन अब पुराने custom ROM के साथ compatibility नहीं रहेगी, इसलिए नए eFuse state के हिसाब से ROM विकसित करना होगा

    • इस पर सवाल उठा, “तो फिर compatible बनाने के लिए ठीक-ठीक क्या करना होगा?”
      लोगों ने पूछा कि eFuse state के अनुरूप ROM बनाने की प्रक्रिया क्या है

  • एक उपयोगकर्ता ने कहा कि उसने कल update notification देखते ही automatic updates बंद कर दिए
    जब तक स्थिति और स्पष्ट न हो जाए, वह update नहीं करेगा

  • “या तो नायक की तरह मरते हो, या इतना जीते हो कि खलनायक बन जाते हो” इस उद्धरण से OnePlus के बदलाव पर तंज कसा गया

    • एक अन्य उपयोगकर्ता ने जोड़ा, “Nord line लॉन्च के समय से ही इसके संकेत दिखने लगे थे”

  • कहा गया कि EU का Cyber Resilience Act(CRA) 2027 से सभी डिवाइसों में tamper-proof boot अनिवार्य कर देगा
    इससे FOSS या repairability कम होगी, और vendor गायब होते ही hardware brick हो जाने जैसे दुष्प्रभाव पैदा हो सकते हैं, ऐसी चिंता जताई गई

  • पहले Mediatek SoC-आधारित बिना-ब्रांड वाले Android फ़ोन डिफ़ॉल्ट रूप से unlock रहते थे, और लगभग कभी brick नहीं होते थे, इसलिए modding culture खूब फला-फूला
    याद किया गया कि eFuse तो थे, लेकिन software उनका इस्तेमाल नहीं करता था

  • boot प्रक्रिया में XBL(Extensible Boot Loader) Qfprom fuse का anti-rollback version पढ़ता है और firmware के version से उसकी तुलना करता है
    नया firmware सफलतापूर्वक boot हो जाने पर TrustZone के माध्यम से fuse जलाकर minimum version अपडेट किया जाता है
    अगर custom ROM पुराने firmware पर आधारित हो, तो उसे तुरंत block कर दिया जाता है

    • इसके तकनीकी स्पष्टीकरण में कहा गया कि XBL और ABL(Secondary Bootloader) version information रखते हैं, और अगर version eFuse के मान से कम हो तो उसे reject कर दिया जाता है
      Android Verified Boot(AVB) kernel hash की तुलना vbmeta partition के signature से करता है, और Replay Protected Memory Block(RPMB) में minimum version स्टोर रहकर rollback रोकता है
      super partition एक read-only root filesystem है, जिसे dm-verity से सुरक्षित रखा जाता है
    • एक अन्य उपयोगकर्ता ने जोड़ा कि “यह संभव होने के लिए signed metadata में version शामिल होना चाहिए”
      अगर उपयोगकर्ता खुद sign कर सके या signature verification बंद कर सके, तो version की शर्त पूरी होने पर वह अपनी पसंद का boot चला सकता है, ऐसा समझाया गया