Cuándo y cómo revertir una actualización de firmware de forma segura

Cuando una actualización de firmware sale mal, el susto es mayúsculo: cortes de luz, pérdida de WiFi, dispositivos que dejan de responder o routers mesh que empiezan a desconectar satélites sin motivo aparente. La buena noticia es que casi siempre se puede revertir la situación si el hardware y el proceso están bien pensados desde el principio.

Da igual que hablemos de un router doméstico tipo RBR750 con sus satélites, de un SSD, de una placa base o de una placa embebida que recibe actualizaciones OTA por WiFi: el riesgo no está en actualizar, sino en actualizar mal. Diseñar sistemas tolerantes a fallos, con doble firmware, recuperación automática y políticas claras de actualización es la clave para decidir cuándo y cómo revertir un firmware sin jugarte el equipo.

¿Qué es exactamente el firmware y por qué es tan delicado tocarlo?

Antes de hablar de revertir versiones, conviene tener claro qué estamos tocando. El firmware es el código que vive dentro del propio hardware, grabado en memorias no volátiles (ROM, EPROM, pero hoy casi siempre NAND Flash). Es el que ejecuta el microcontrolador integrado en un router, una tarjeta gráfica, un SSD, un teclado o un satélite WiFi, y el que dicta cómo debe comportarse el dispositivo a nivel más bajo.

A diferencia de un driver, que se ejecuta en el sistema operativo, el firmware se ejecuta directamente en el dispositivo. El driver le dice a Windows, Linux o al sistema que sea cómo hablar con el hardware; el firmware le dice al hardware cómo hablar con el resto del sistema y con otros chips, a qué velocidad, con qué protocolos y qué funciones tiene disponibles.

En el caso de las placas base modernas, el ejemplo clásico es la UEFI. Este firmware actúa como mini sistema operativo previo al arranque: inicializa CPU, RAM, buses, controla voltajes, aplica perfiles XMP/EXPO, gestiona el arranque seguro, etc. Sin ese código, el PC ni siquiera llega a mostrar el logo.

Ese mismo esquema se repite en routers, switches, cámaras IP, televisores, auriculares, consolas, dispositivos de streaming e incluso en periféricos aparentemente tontos como un ratón o un teclado. Casi todo lleva hoy un microcontrolador y un firmware que se actualiza periódicamente.

¿Dónde se almacena el firmware y cómo se protege?

El firmware se guarda en memorias no volátiles soldadas a la placa. Históricamente eran ROM o EPROM que solo se podían actualizar con procesos muy engorrosos; hoy en día lo normal es que sea memoria Flash (NAND, NOR) reprogramable.

Muchas placas base, routers y equipos de red modernos incluyen un segundo chip o una partición de respaldo con una copia «buena» del firmware. Si durante una actualización algo se corrompe, esa copia permite restaurar un estado funcional mínimo y repetir el proceso. En placas antiguas donde no existía esta doble BIOS era relativamente fácil dejar la placa «muerta» si fallaba la luz durante el flasheo.

En sistemas embebidos y dispositivos IoT esa idea se traduce en arquitecturas de doble banco de firmware (A/B): dos particiones de código, una activa y otra pasiva. Se escribe la nueva versión en la pasiva, se verifican firma y checksum, y solo entonces el bootloader marca esa partición como activa para el siguiente arranque. Si el arranque falla, el bootloader regresa automáticamente a la partición conocida como buena.

¿Cómo se comunica el procesador con el firmware?

Los SoC y microcontroladores se comunican con el chip de firmware a través de interfaces de bajo nivel y bajo consumo como UART, I2C, SPI u otros buses dedicados. Estos pines suelen estar activos en los primeros instantes de arranque, antes de que el resto de la electrónica esté alimentada al completo.

En muchos diseños embebidos, esa interfaz serie de depuración (por ejemplo, un UART sacado a un header oculto) es la última línea de defensa cuando todo se rompe: permite cargar un bootloader mínimo, reflashear manualmente y recuperar dispositivos que de otro modo serían ladrillos.

¿Por qué actualizar… y por qué a veces interesa volver atrás?

Actualizar el firmware no es un capricho. Cada nueva versión suele aportar correcciones de seguridad, mejoras de estabilidad, compatibilidad y a veces nuevas funciones que el hardware ya soportaba pero estaban desactivadas. Los motivos habituales para actualizar son:

Parchear vulnerabilidades críticas que permiten ejecutar código, romper el cifrado o pivotar dentro de la red.
Corregir bugs de compatibilidad con otros componentes, errores de gestión de energía o cuelgues intermitentes.
Mejorar rendimiento en ciertas cargas de trabajo, reducir consumo o afinar algoritmos (por ejemplo, de WiFi mesh o de gestión térmica).
Habilitar funciones nuevas que el fabricante añade tras el lanzamiento (nuevos modos, soporte de protocolos, características de IA, etc.).

Photoshop: flujo de trabajo para retoque y exportación eficiente

En esos casos, si la versión estable anterior funcionaba mejor, tiene todo el sentido querer revertir el firmware mientras el fabricante saca un nuevo parche. La clave está en hacerlo de forma segura y, a ser posible, en haber previsto el rollback en el propio diseño del sistema.

Riesgos reales de jugar con el firmware

Tocar firmware siempre tiene cierto riesgo porque estás modificando el código que hace que el hardware arranque. Los problemas más habituales que hacen necesario revertir (o recuperar) son:

Cortes de luz o energía inestable en pleno flasheo: dejan la imagen corrupta y el dispositivo no arranca.
Pérdida de conexión (WiFi, Ethernet) durante una actualización OTA: el archivo llega incompleto o dañado.
Bugs en la versión nueva que rompen funciones críticas: WiFi que se cae, satélites mesh que desaparecen, discos que reportan tamaños incorrectos, etc.
Firmware engañoso o manipulado en hardware dudoso: SSD «de 2 TB» que en realidad son memorias de 64 GB con el firmware trucado, pendrives que declaran capacidades falsas o tarjetas gráficas reflasheadas para parecer un modelo superior.
Firmware no oficial o de terceros mal adaptado: puede añadir funciones, pero también dejar el dispositivo en modo ladrillo o abrir un agujero de seguridad enorme.

Además, las vulnerabilidades a nivel de firmware son especialmente peligrosas porque persisten incluso si formateas o reinstalas el sistema operativo y pueden ser invisibles para el antivirus. Por eso es tan importante aplicar parches oficiales y desconfiar de cualquier imagen «mágica» de procedencia dudosa.

Buenas prácticas para actualizar y revertir firmware de forma segura

Ante la duda, la norma de oro es clara: si tu equipo funciona bien y la nota de la versión no menciona nada crítico para ti, no actualices a lo loco el mismo día de salida. Espera unos días, revisa foros y notas de otros usuarios y, si dependes del dispositivo para trabajar, valora el riesgo.

Cuando sí necesitas actualizar (por seguridad, compatibilidad o funciones clave), hay una serie de recomendaciones básicas:

Descarga siempre el firmware de la web oficial del fabricante o desde las herramientas oficiales (Magician en SSD Samsung, iCUE/Toolbox en Corsair, utilidades de la propia placa base, app oficial del router…).
Evita fuentes de terceros salvo que sepas perfectamente lo que haces. Un firmware modificado puede contener malware, backdoors o simplemente dejar el dispositivo inutilizable.
Asegura la alimentación: si es un equipo crítico, usa un SAI (UPS) para minimizar el riesgo de cortes de luz durante el flasheo.
No toques nada mientras se actualiza: no apagues, no desconectes cables, no reinicies «porque parece que se ha quedado colgado» salvo que el propio fabricante indique un tiempo máximo y se haya superado holgadamente.
Haz copias de configuración antes de actualizar routers, switches o sistemas complejos. Aunque reviertas el firmware, a veces se pierden ajustes y da mucha pereza reconfigurarlo todo.

Si después de actualizar aparece un problema claro, tu primera línea de defensa es volver a la versión anterior estable en lugar de encadenar más betas o versiones experimentales. Muchos routers y placas base permiten cargar manualmente un firmware antiguo desde archivo.

¿Cómo y cuándo revertir el firmware de un router o sistema mesh?

En equipos de red domésticos o semi profesionales, como un sistema mesh con router principal y satélites, la estrategia típica sería:

Identificar la versión concreta que iba bien (por ejemplo, 7.2.6.31 frente a 7.2.7.15). Suele aparecer en la interfaz web o en la app.
Revisar el registro de cambios del fabricante para ver qué cambió entre ambas versiones y si hay avisos de problemas conocidos.
Descargar desde la web oficial el archivo de firmware de esa versión estable (para el router y, si procede, para los satélites).
Actualizar primero el nodo principal por cable Ethernet, nunca por WiFi, y solo cuando no haya riesgo de cortes de luz.
Una vez estable el router, actualizar o sincronizar los satélites a esa misma versión, siguiendo la guía del fabricante.
Desactivar las actualizaciones automáticas (si el sistema lo permite) hasta que el fabricante reconozca y corrija el bug de la versión conflictiva.

Organiza tu biblioteca digital de libros electrónicos con Calibre

Si el proveedor no permite downgrade desde la interfaz normal, algunos equipos incluyen un modo de recuperación o TFTP al que se entra manteniendo pulsado un botón de reset en el arranque. Ese modo acepta una imagen de firmware (a veces solo firmas específicas) y es la última bala antes de tramitar garantía.

Diseño seguro de placas que actualizan firmware por WiFi (OTA)

1. Usa arquitectura de doble banco de firmware (A/B)

Es la base de cualquier sistema OTA serio. Consta de:

Dos particiones de firmware (slot A y slot B): una activa, otra para la nueva versión.
Bootloader robusto en una tercera región protegida, que nunca se toca en actualizaciones normales.
Marcadores de estado en memoria (flags): versión, partición activa, partición válida, último arranque correcto.

El flujo recomendado es:

Descargar el nuevo firmware en la partición inactiva (B si A está activa).
Verificar integridad (checksum, hash) y firma digital antes de hacer nada más.
Si todo cuadra, marcar B como «pendiente de activación», pero sin desactivar A todavía.
Reiniciar; el bootloader ve que hay un firmware pendiente y arranca desde B.
La aplicación en B debe ejecutar una rutina de «arranque correcto» (por ejemplo, enviar un «OK» al bootloader mediante un flag o watchdog antes de X segundos).
Si llega ese OK, el bootloader marca B como estable. Si no llega, rollback automático a A en el siguiente arranque.

Con este esquema, un corte de WiFi o luz durante la descarga no toca el firmware activo. Y si la nueva versión arranca mal, el propio sistema se revierte solo.

2. No te actualices mientras ejecutas funciones críticas

En sistemas embebidos, sobre todo industriales o de control, es vital que el proceso de actualización no interfiera con la tarea principal. Algunas pautas:

Descargar el firmware en segundo plano cuando el equipo esté en un estado seguro o de bajo uso.
No hacer el switch de partición hasta una ventana de mantenimiento controlada.
Bloquear ciertas operaciones durante el flasheo (por ejemplo, que el usuario no pueda apagar desde la interfaz).

En placas controladas por WiFi, ten en cuenta que el enlace inalámbrico es frágil. Implementa reintentos, descargas reanudables y verificación de tamaño para no aceptar paquetes incompletos como buenos.

3. Protege el bootloader a toda costa

El bootloader es lo único que te puede salvar de un desastre. Por eso:

Almacénalo en una región protegida (read-only, con bloqueos de escritura por hardware si el micro lo permite).
No permitas que el proceso OTA lo toque salvo en un procedimiento de recuperación muy controlado, idealmente solo accesible en fábrica o mediante herramientas JTAG/SWD.
Expón, si es viable, un puerto de servicio físico (UART, SWD, JTAG) para flasheo de emergencia en laboratorio o SAT.

Si el bootloader se corrompe, ya no hay WiFi ni OTA que valga; solo queda programador externo.

4. Firma y valida todo lo que entre por WiFi

En un mundo ideal, ningún firmware debería ejecutarse si no está firmado por ti. Eso implica:

Usar firmas digitales asimétricas (por ejemplo, Ed25519, ECDSA) para cada imagen de firmware.
Incluir en el bootloader una clave pública incrustada con la que se verifican todas las actualizaciones.
Rechazar cualquier imagen cuyo hash, tamaño o firma no coincidan.
Si el dispositivo se conecta a un servidor central, utilizar HTTPS/TLS y autenticación mutua cuando sea posible.

De este modo, aunque alguien intercepte la comunicación WiFi o comprometa la red, no podrá cargar firmware arbitrario sin tu clave privada.

5. Define una política clara de versionado y rollback

No basta con el mecanismo técnico: necesitas una estrategia de versiones y de gestión de errores:

Usa versionado semántico (Mayor.Menor.Parche) y guarda ese dato en un campo accesible desde el bootloader.
Impide downgrades que rompan compatibilidad de datos (por ejemplo, cambios de formato de configuración). En ese caso, el propio firmware debe incluir rutinas de migración o, como mínimo, advertencias.
En sistemas gestionados (fleet de dispositivos), mantén un registro central de qué versión lleva cada unidad y cómo ha respondido a la actualización.
Implementa canary deployments: actualiza primero a un pequeño porcentaje de equipos, monitoriza, y solo después amplía al resto.

Cómo localizar drivers problemáticos sin reinstalar Windows

Si algo sale mal, puedes ordenar remotamente que todos los equipos vuelvan a la versión N-1 marcada como estable, siempre aprovechando esa arquitectura A/B.

6. Apóyate en frameworks y stacks probados

No hace falta inventar la rueda. Existen frameworks embebidos y stacks OTA ya muy rodados que implementan muchas de estas ideas:

En el ecosistema ESP32/ESP8266, el propio ESP-IDF ofrece OTA con particiones A/B, verificación y rollback automático.
En Linux embebido, proyectos como RAUC, Mender, SWUpdate o OSTree proporcionan actualización robusta de imágenes, firma y gestión centralizada.
En plataformas comerciales, muchos SoC de IoT incluyen SDK con soporte OTA integrado (NXP, ST, Nordic, etc.), con ejemplos de doble imagen y recuperación.

La ventaja de usar estas soluciones es que ya han sufrido en campo los cortes de luz, las WiFi inestables y los bugs, y suelen incluir patrones de diseño que minimizan el riesgo.

Cómo detectar firmware engañoso y verificar que está actualizado

Más allá del desarrollo propio, como usuario conviene saber cuándo el firmware que llevas no es de fiar. Hay dos escenarios:

Productos de marcas desconocidas y absurdamente baratos (sobre todo en mercados asiáticos y segunda mano) que anuncian especificaciones imposibles para su precio.
Dispositivos de marca reconocida que hace años que no reciben parches de seguridad y se quedan anclados a una versión vulnerable.

En el primer caso, hay muchas historias de SSD «de 2 TB» que en realidad son tarjetas de 64 GB con firmware manipulado para reportar más capacidad de la real. Al escribir más allá de ese límite, los datos se corrompen. Herramientas como H2testw o pruebas de escritura secuencial completa permiten ver la capacidad real ignorando lo que reporta el firmware.

En el segundo caso, aplicaciones de diagnóstico como AIDA64 o utilidades oficiales del fabricante consultan el identificador de firmware y lo comparan con un repositorio de versiones conocidas. Si ven un código que no coincide con ninguna versión oficial o se ha quedado muy atrás, lo marcan como desactualizado o incluso desconocido.

Si quieres mantener tu PC lo más seguro posible, merece la pena revisar de vez en cuando:

UEFI/BIOS de la placa base, sobre todo cuando hay vulnerabilidades públicas.
Firmware de SSD, donde patches mejoran estabilidad y corrigen fallos de escritura.
Routers y puntos de acceso, que son la puerta de entrada de tu red doméstica o de oficina.
Dispositivos IoT expuestos a Internet (cámaras, NVR, domótica…).

Revertir sin perder de vista la seguridad

Cada vez que bajas de versión para evitar un bug funcional estás, potencialmente, renunciando también a algunos parches de seguridad. Por eso, al decidir retroceder, conviene valorar:

Si el dispositivo está expuesto a Internet o solo en una red interna muy controlada.
Si el problema de la nueva versión afecta a la disponibilidad (cortes de conexión, inestabilidad) de forma más crítica que una posible vulnerabilidad.
Si el fabricante ha publicado mitigaciones adicionales (configuraciones, reglas de firewall, etc.) que reduzcan el riesgo al hacer rollback.

En muchos casos, sobre todo en routers domésticos, tiene sentido volver temporalmente a una versión anterior que funcionaba bien y monitorizar de cerca los avisos del fabricante. En cuanto salga una revisión que corrija tanto el bug como las vulnerabilidades, lo sensato es actualizar de nuevo.