Actualización de smartphones OnePlus introduce una función antirretroceso a nivel de hardware

 (consumerrights.wiki)
1 puntos por GN⁺ 2026-01-26 | 1 comentarios | Compartir por WhatsApp
  • El firmware ColorOS 16.0.3.501 distribuido en enero de 2026 incluye una función de anti-rollback basada en hardware, que bloquea de forma permanente la instalación de versiones antiguas o el flasheo de ROM personalizadas
  • La actualización modifica físicamente los fusibles electrónicos (eFuse) del procesador Qualcomm, de modo que al intentar instalar una versión anterior el dispositivo pasa a un estado completamente inoperable (hard brick)
  • Varios modelos, como OnePlus 13, 15 y la serie Ace 5, se ven afectados, y también se eliminaron del sitio oficial algunos paquetes de downgrade para modelos más antiguos
  • En los foros de XDA, se advierte a los usuarios de ROM personalizadas que “eviten las actualizaciones OTA de las versiones .500, .501 y .503”, y se recomienda a quienes ya actualizaron que dejen de instalar ROM personalizadas
  • OnePlus y OPPO no han emitido una postura oficial, y en la industria se considera una restricción mucho más fuerte que Samsung Knox

Resumen del incidente

  • En enero de 2026, el firmware ColorOS 16.0.3.501 distribuido por OnePlus incluyó una función antirretroceso a nivel de hardware
    • Esta función bloquea de manera permanente que el usuario instale firmware antiguo o ROM personalizadas
    • Cambia el estado de los fusibles electrónicos (eFuse) ubicados en la zona Qfprom (Programmable Read-Only Memory) del chipset Qualcomm mediante un proceso de “blow”
  • Una vez que el fusible cambia, no puede recuperarse por software, y se indica que reemplazar la placa madre es el único método de recuperación
  • OnePlus no ha publicado ninguna declaración oficial ni explicación sobre este mecanismo

Antecedentes

  • OnePlus fue fundada en 2013 por Pete Lau y Carl Pei, y en sus inicios ganó popularidad en la comunidad de modding con el OnePlus One, que venía con una ROM personalizada basada en CyanogenMod
  • Después de terminar su contrato con Cyanogen, desarrolló OxygenOS (global) y HydrogenOS (China)
  • En 2021, al integrar su base de código con ColorOS de OPPO, pasó al sistema actual basado en ColorOS

Cronología

  • 18 de enero: tras la actualización a ColorOS 16.0.3.501, se reportan casos de usuarios que intentaron volver a una versión anterior y terminaron en modo EDL (9008) sin posibilidad de recuperación
  • 19 de enero: la usuaria del foro de XDA AdaUnlocked publica un hilo de advertencia con pruebas de daño en los fusibles del CPU
    • Incluso servicios de recuperación de pago advirtieron que en los dispositivos con Snapdragon 8 Elite está prohibido hacer downgrade
    • Algunos usuarios reportaron casos en los que fue necesario reemplazar la placa madre
  • Después del 19 de enero: OnePlus elimina los enlaces de firmware de downgrade de su foro oficial, y también retira el paquete para el OnePlus 12
  • 24 de enero: AdaUnlocked confirma que “la ROM existente fue reempaquetada con el mismo número de versión e incluye el disparador del fusible”

Dispositivos afectados

  • 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
  • También están incluidos OPPO Find X7 Ultra, OPPO Pad 4 Pro y OnePlus Pad 2 Pro / Pad 3
  • Las versiones 16.0.2.402 o anteriores no están afectadas, y la comunidad recomienda evitar las OTA .500, .501 y .503
  • Android Authority menciona que la serie OPPO Find X8 es de alto riesgo, y que OnePlus 11 y 12 también podrían recibir actualizaciones similares

Mecanismo técnico

  • El eFuse de Qfprom es un fusible electrónico programable una sola vez; cuando un pulso de voltaje cambia su estado de ‘0’ a ‘1’, no puede revertirse
  • Durante el arranque, el Primary Boot Loader verifica el XBL (eXtensible Boot Loader), y si la versión del firmware es menor que el valor del fusible, rechaza el arranque
  • Si el nuevo firmware inicia correctamente, se soplan fusibles adicionales mediante Qualcomm TrustZone, registrando de forma permanente el valor de versión mínima
  • El modo EDL (USB 9008) no puede eludir esta protección
    • El programador Firehose requiere firma del OEM, y si el fusible ya fue modificado, no funciona
  • Según la explicación en XDA, “blow fuse” no implica daño físico ni calor, sino una conmutación eléctrica de compuertas lógicas que bloquea por completo la ruta de ejecución del software anterior

Impacto en las ROM personalizadas

  • El foro de XDA advierte que “desde ColorOS 16.0.3.501 en adelante, instalar una ROM personalizada existente provoca un hard brick inmediato”
  • La mayoría de las ROM personalizadas están hechas sobre firmware previo a la introducción de la política de fusibles, por lo que no son compatibles con el nuevo firmware
  • La desarrolladora AdaUnlocked menciona que el trabajo con ROM personalizadas, ports y GSI queda inutilizado en dispositivos con el fusible aplicado
  • La comunidad recomienda no instalar ROM personalizadas en dispositivos ya actualizados y esperar hasta que los desarrolladores indiquen soporte basado en el nuevo firmware

Respuesta de las empresas

  • Hasta el 22 de enero de 2026, OnePlus y OPPO no habían emitido declaración oficial, respuesta en foros ni menciones en redes sociales
  • La eliminación de los paquetes de downgrade del foro oficial el 19 de enero se interpreta como una medida deliberada

Comparación con otros fabricantes

  • Samsung Knox también usa funciones de seguridad basadas en eFuse, pero al instalar firmware no oficial normalmente solo desactiva Samsung Pay y Carpeta Segura
  • Android Authority señala que el método de OnePlus es mucho más agresivo y bloquea incluso el arranque
  • DroidWin señala que “el flasheo por EDL es una función que solo usa entre el 1% y el 2% de los usuarios; afectar a la mayoría para bloquear eso no es razonable”

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-01-26
Comentarios en Hacker News

  • Se comentó que, en un contexto de guerra, los países enemigos de EE. UU. quedarían liberados de esos dispositivos
    Se mencionó la función Qfprom (One-Time Programmable Fuse) de Qualcomm, un fusible electrónico de un solo uso que se utiliza para implementar anti-rollback
    Hubo sarcasmo sobre lo “considerado” que fue crear algo así, y también apareció la opinión de que CPU como los chinos Loongson o los rusos Baikal son sancionados porque son más difíciles de desactivar que estos fusibles programáticos

    • Este tipo de mecanismo existe para evitar el downgrade del bootloader
      La explicación es que, en una cadena de cómputo confiable, una vez que aparece una vulnerabilidad queda rota para siempre, así que esto es una medida para impedirlo
      También se dijo que es un concepto antiguo, presente ya hace 25 años en la era del Motorola p2k, y que el cómputo confiable en sí mismo no es algo maligno
    • La memoria OTP es un componente central de casi todos los sistemas de seguridad
      La clave única del dispositivo o la raíz de la cadena de certificados se guarda como hash en ese fusible, para evitar que un atacante cargue firmware antiguo y explote vulnerabilidades
      Incluso hubo quien dijo que lo sorprendente es que no tuvieran esta función hasta ahora
    • eFuse es una tecnología usada desde hace mucho tiempo en MCU y procesadores durante la etapa de fabricación
      Por ejemplo, cuando se usa el mismo MCU en placas de entrada/salida de audio pero debe comportarse distinto según la configuración, se fija esa configuración con eFuse para que el firmware no configure GPIO incorrectos
    • Un método aún más simple sería esconder dentro del CPU un bloque lógico de kill switch que se active al detectar una secuencia específica de bits
    • También hubo opiniones de que China invierte en la arquitectura open source RISC-V como estrategia para evitar este tipo de sanciones o la dependencia de tecnologías cerradas

  • Se sostuvo que este caso va más allá del simple derecho a reparar y toca el problema de la propiedad misma
    Según esa postura, vuelve a demostrar que, con actualizaciones remotas, el usuario no llega a poseer completamente el dispositivo

    • Con los autos pasa lo mismo: no se puede desactivar el módulo de comunicaciones del techo
      El fabricante controla tanto que incluso puede avisar por correo cuándo cambiar el aceite, así que se cuestiona si realmente “poseemos” el auto
    • Se argumentó que el recibo de compra es la prueba de propiedad, y que una desactivación remota a gran escala como esta violaría la CFAA (Computer Fraud and Abuse Act) y en la práctica se parece más a una venta fraudulenta
      Si la directiva sabía de esto, podría incluso constituir una violación de la ley RICO
      También hubo una reacción cínica diciendo que, aunque ganaran una demanda, al final todo terminaría en algo como “un cupón de 10 dólares de descuento para tu próximo teléfono OnePlus”

  • Surgió la pregunta de qué gana OnePlus con hacer esto
    Incluso hubo sospechas de que, si aumentan los cambios de motherboard por fallas de actualización, tal vez eso les deja más ganancias
    Y se especuló que el antiguo incidente de la línea verde pudo haber sido un caso en el que un fusible de hardware se activó mal durante una actualización de software

    • Había un bug que permitía reiniciar y reactivar teléfonos robados, y se explicó que esta medida apunta a evitar ataques de downgrade
      Podría ser una acción para prevenir robos o para cumplir requisitos de operadores y de Google
    • Como una vulnerabilidad del bootloader permitía arrancar un sistema operativo arbitrario con acceso físico, se necesita bloquear el downgrade con eFuse
      Esto no impide usar custom ROMs como tal, sino solo las ROM de versiones anteriores
      Las ROM construidas sobre firmware nuevo sí podrían arrancar normalmente
      Por eso, si los desarrolladores de ROM dan soporte al nuevo firmware, volvería a ser posible usar custom ROMs
    • Desde la perspectiva de la directiva, no quieren dar al usuario el control del hardware
      Como vender hardware por sí solo no deja suficiente ganancia, se criticó que el modelo busca encerrar al usuario en su ecosistema de OS y monetizar la recolección de datos
    • Apple también aplica una política similar de no permitir downgrade después de 7 días
      OnePlus solo lo implementó por hardware y Apple por firmas
      Se defendió que debería garantizarse el derecho del usuario a firmar y ejecutar su propio OS
      También se mencionó una queja por problemas de sincronización del Apple Watch en iOS 26

  • Este tipo de anti-rollback basado en eFuse ya es algo común en los SoC desde hace 10 a 20 años
    Cuando se descubre un root exploit, lo estándar en seguridad es quemar el eFuse para impedir volver a firmware vulnerable anterior
    Se dijo que se entiende el atractivo de las ROM o del jailbreak, pero que eso depende de firmware viejo y vulnerable

    • Sin embargo, otro usuario respondió que “eso no es normal”
      Si es un teléfono que compré, debería tener el derecho a decidir qué software ejecutar
      Si una actualización manda mis datos a otro país, debería poder volver libremente a una versión anterior, pero
      este cambio bloquea esa libertad y, si se intenta, el teléfono queda brickeado

  • Según el OP, este cambio no bloquea por sí mismo el desbloqueo del bootloader
    Solo deja de ser compatible con custom ROMs anteriores, por lo que ahora habría que desarrollar ROMs acordes al nuevo estado del eFuse

    • Ante esto, alguien preguntó: “entonces, concretamente, ¿qué hay que hacer para que sea compatible?”
      Mostró curiosidad por el proceso de crear una ROM acorde al estado del eFuse

  • Un usuario contó que ayer vio la notificación de actualización y desactivó las actualizaciones automáticas
    Dijo que no actualizará hasta entender mejor la situación

  • Se satirizó la evolución de OnePlus con la cita: “mueres como héroe o vives lo suficiente para volverte villano”

    • Otro usuario agregó que “ya se veía venir desde el lanzamiento de la línea Nord”

  • Se comentó que la Cyber Resilience Act (CRA) de la UE exigirá arranque a prueba de manipulaciones en todos los dispositivos a partir de 2027
    Se teme que eso reduzca FOSS y la capacidad de reparación, y que tenga como efecto colateral que, si el proveedor desaparece, el hardware quede brickeado

  • Antes, los teléfonos Android genéricos con SoC Mediatek venían desbloqueados por defecto y casi nunca se brickeaban, por lo que la cultura del modding prosperaba
    Se recordó que los eFuse existían, pero el software no los usaba

  • En el proceso de arranque, XBL (Extensible Boot Loader) lee la versión de anti-rollback del fusible Qfprom y la compara con la versión dentro del firmware
    Si el nuevo firmware arranca con éxito, mediante TrustZone se quema el fusible para actualizar la versión mínima
    Si una custom ROM está basada en firmware anterior, se bloquea de inmediato

    • Como explicación técnica adicional, se dijo que XBL y ABL (Secondary Bootloader) contienen información de versión y se rechaza cualquier valor inferior al del eFuse
      Android Verified Boot (AVB) compara el hash del kernel con la firma de la partición vbmeta, y la versión mínima se guarda en Replay Protected Memory Block (RPMB) para evitar rollback
      La partición super es un sistema de archivos raíz de solo lectura protegido con dm-verity
    • Otro usuario añadió que “para que esto funcione, la metadata firmada tiene que incluir la versión”
      Explicó que, si el usuario pudiera firmar por su cuenta o desactivar la verificación de firmas, mientras cumpla la condición de versión podría arrancar lo que quisiera