Ledger Donjon rompe el Secure Debug del RP2350 con láser

Un láser de US$250.000 recuperó un secreto “borrado” del RP2350

El equipo Ledger Donjon publicó esta semana un ataque práctico contra el modo Secure Debug del microcontrolador Raspberry Pi RP2350, capaz de recuperar un secreto guardado en memoria OTP incluso después de que el fabricante había marcado el chip como debug-desactivado de forma permanente. El procedimiento, descrito por el propio Donjon, requirió desecapsular el chip por la parte trasera, aplicar pulsos láser de 980 nm calibrados con microscopía de emisión de fotones (PEM) y disparar un “rescue reset” para leer la página protegida antes de que el firmware endureciera el bloqueo en tiempo de ejecución. Según el equipo, el laboratorio completo cuesta aproximadamente US$250.000 y exige experiencia en fault injection a nivel de dado.

Qué es el RP2350 y por qué importa su modelo de seguridad

El RP2350 es el microcontrolador dual-core de Raspberry Pi: cada zócalo puede arrancar como Arm Cortex-M33 o como RISC-V Hazard3. Su arquitectura se diseñó pensando en firmware firmado y separación de ejecución Secure/Non-secure: trae secure boot contra huellas SHA-256 grabadas en OTP, Armv8-M TrustZone y flags persistentes para desactivar el debug de forma irreversible. El propio fabricante invitó a la comunidad a romperlo mediante los RP2350 Hacking Challenges; la versión analizada por Ledger Donjon es la revisión A4, posterior a los hallazgos del primer reto que corrió entre agosto y diciembre de 2024.

El dato clave para un founder de hardware: la seguridad del chip depende de una cadena completa — OTP persistente, registros de control mutables, comportamiento ante reset y permisos de firmware. Que cada eslabón “funcione según su documentación” no garantiza que la cadena entera aguante.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Cómo funciona el ataque, paso a paso

Localizar el registro DEBUGEN con emisión de fotones

El registro DEBUGEN tiene cinco bits funcionales (PROC0, PROC0SECURE, PROC1, PROC1SECURE y MISC) y, según el datasheet, no cuenta con codificación redundante, paridad ni voto por mayoría, a diferencia de los flags críticos en OTP. Para encontrar dónde vive cada bit, Donjon hizo que el firmware alternara máscaras de bits en bucles y comparó mapas de emisión infrarroja: restando el promedio de dos loops solo quedaba la señal asociada a los bits seleccionados. Esto redujo la zona de búsqueda a “pocos micrómetros” en el dado.

Fault injection con pulsos láser

Con un láser pulsado a 980 nm (≈1,2 W, pulsos de 100 ns, objetivo 50x) exploraron esa zona y encontraron dos posiciones separadas por pocos micrómetros: una ponía en alto PROC1 y la otra forzaba PROC1_SECURE. Un script iteraba entre ambas hasta activar Secure Debug. Curiosamente, con un objetivo 20x no se lograba: el spot más ancho borraba el bit mientras escribía el otro. Una vez fijados ambos bits, el registro DEBUGEN quedaba en 0xc y se mantenía sin más pulsos.

Rescue reset para leer antes de que el firmware bloquee

La OTP del reto tiene PAGE48LOCK1 = 0x3c3c3c, lo que permite lectura Secure pero no Non-secure. El firmware endurece un soft lock runtime a 0b1111 en cada arranque, haciendo la página inaccesible incluso para Secure Debug. La clave está en que el RP-AP sigue accesible aunque el debug externo esté deshabilitado: escribir CTRL.RESCUERESTART dispara un reset que detiene el boot ROM en un lazo de espera, sin ejecutar el firmware. Con el soft lock todavía en su valor permisivo, el atacante lee el secreto desde las filas 0xc08–0xc0f de la OTP.

Por qué DEBUGEN_LOCK no salvó la situación

El datasheet dice que DEBUGEN_LOCK “write 1 to lock” cada bit para evitar escrituras accidentales. Donjon documenta que los pulsos láser también fijan bits de lock, dejando el DEBUGEN y su lock en 1; nunca observaron un lock volviendo a 0, así que, una vez alterado, el firmware no puede restaurar el estado “debug deshabilitado”. El atacante, además, queda con capacidad de halt, single-step e inspección de registros del core Secure, comprometiendo la separación de TrustZone a través de extracciones mediadas por el propio núcleo.

Qué aprende un founder de hardware de este ataque

Diseña asumiendo que el debug mutable existe. Si tu producto depende de que DEBUG_DISABLE en OTP sea “para siempre”, confirma que el datasheet documente redundancia para cada bit del registro que pueda reescribirlo. Donjon subraya que DEBUGEN “no tiene equivalente” de la triple redundancia que protege a la OTP.
No confundas mitigaciones runtime conConfidentiality boundaries. ACCESSCTRL reduce exposición del Mem-AP, pero tras un rescue reset vuelve a sus valores por defecto antes de que el firmware pueda reconfigurarlo. Cualquier ruta de reset que detenga el boot es un vector.
Acepta límites y comunícalos. Raspberry Pi no ha parcheado esto: es la arquitectura de la revisión A4. Si vendes un dispositivo basado en RP2350, tu amenaza realista debe incluir atacantes con laboratorio de seis cifras y acceso físico prolongado.

Qué significa esto para tu startup

Si tu producto usa RP2350 (controladores industriales, llaves criptográficas, periféricos autenticados, prototipos de device-as-a-service) el reporte te obliga a decisiones de modelo de amenaza:

Evalúa migrar a revisiones posteriores o a otros SoCs para productos que prometan seguridad ante adversarios con recursos de laboratorio; el propio equipo de Donjon señala que la revisión analizada es la A4 y que el hallazgo se disclosed el 28 de julio de 2026.
Implementa monitorización post-boot desde el propio firmware Secure: comprobar DEBUGEN periódicamente y disparar un fail-safe reset del dominio cold si su valor cambia fuera de lo esperado. Es una mitigación best-effort — Donjon aclara que el rescue reset ocurre antes de que el monitor pueda ejecutarse —, pero reduce la ventana de exposición.
Diseña tu roadmap pensando en capas independientes: como recuerda Cointelegraph sobre el caso paralelo de Trezor y TROPIC01, una vulnerabilidad en un único chip no compromete los fondos del usuario si la custodia se reparte entre múltiples elementos y firmware. La lección coincide con el reporte de Donjon: la seguridad del sistema depende de la cadena, no del eslabón más fuerte.

Conclusión

Ledger Donjon convirtió un “deshabilitar debug para siempre” en una frase negociable: dos pulsos láser en posiciones separadas por micrómetros bastaron para reactivar el Secure Debug del RP2350, y un rescue reset completó la exfiltración del secreto. La investigación deja tres lecciones transferibles: la seguridad reside en la cadena completa, los registros mutables sin redundancia son un patrón de riesgo y cualquier ruta de reset que detenga el boot merece auditoría. Para founders de hardware hispanohablantes, el reporte es una guía práctica para diseñar asumiendo que el adversario tiene tiempo, dinero y un microscopio de emisión.