De un PCB desnudo a root: hardware-hacking de un ZyXEL P-870HN por UART

Dos fotos de móvil de una placa de router sin etiquetar → consola serie → bypass de autenticación → shell root — reproduciendo la cadena real, aún sin parchear, CVE-2025-0890 (cuenta supervisor oculta) + CVE-2024-40891 (inyección de comandos en la CLI) en hardware que poseo.

por damik0 · 2026-08-13 · una guía paso a paso de hardware-hacking

  📷 PCB photos ─▶ 🔬 chip recon ─▶ 🏷️  model ID ─▶ 📍 find UART (J2)
       └─▶ 🔌 serial console ─▶ 🚪 hidden account ─▶ ⛓️  break out of CLI
              └─▶ 🐚 root shell ─▶ 🔓 dump + crack every credential

TL;DR

Tenía una placa de router cualquiera sobre mi mesa. Sin carcasa, sin etiqueta, sin idea de qué era. Partiendo de nada más que dos fotos, leí cada chip del PCB, identifiqué el modelo exacto, encontré el conector serie (UART), me conecté a él, entré a través de una cuenta backdoor de fábrica, escapé de un menú de fabricante restringido hacia una shell root de Linux, y extraje todas las contraseñas del equipo — crackeadas en menos de un segundo.

Ninguno de estos fallos es mío. Son problemas documentados de ZyXEL que el fabricante ha dicho que no va a parchear. De lo que trata este repo es del cómo, de principio a fin, y del razonamiento en cada paso.

Primero lo primero: esto es hardware mío

• El objetivo es una placa de router que poseo.
• La entrada fue a través del puerto serie físico del PCB — sin ataque remoto, sin red de terceros, nada expuesto a internet.
• Estuvo en mi banco de trabajo, aislada de la red, todo el tiempo.
• El objetivo era ejecutar el ciclo completo de hardware-hacking de principio a fin y documentarlo para que sea reproducible.

Lo que estaba trasteando

Identifiqué el modelo a partir del número de serigrafía de la placa 45-402-000022 y del código de barras, contrastándolo con TechInfoDepot, la tabla de hardware de OpenWrt y el ID de la FCC I88P870HN51B:

Por qué el número de placa es la clave que lo desbloquea todo: las pasarelas ODM como esta son diseños de referencia. Una vez que el número de pieza de serigrafía coincide con una placa documentada, heredas el trabajo de otro — el chip de flash exacto, la ubicación y el pinout de la UART, las cuentas por defecto. La identificación no es una formalidad; es lo que convierte el sondeo a ciegas en un ataque dirigido.

Cómo se desarrolló

Paso 0 — sacando las fotos del móvil

Primero, una pequeña mejora de calidad de vida: monté un minúsculo subidor de fotos por LAN (stdlib de Python, cero dependencias) para poder fotografiar la placa con el móvil y que las imágenes aterrizaran directamente en mi máquina. La mitad de una buena sesión consiste en eliminar fricciones como esta.

Paso 1 — leyendo la placa

Fui chip por chip a partir de las fotos en alta resolución. Los tipos de encapsulado te cuentan la historia antes incluso de leer las marcas: el BGA del centro es el cerebro, el TSOP-48 casi siempre es flash paralelo, la pequeña lata con el latiguillo coaxial es la radio. El SoC estaba oculto bajo un escudo RF (presente por EMI y como disipador de calor), así que desmonté la lata para leer la marca de debajo — un Broadcom BCM6368.

La placa, mapeada: (1) SoC BCM6368, (2) RAM DDR2, (3) WiFi BCM43222, (4) transformador de línea DSL, (5) magnéticos de Ethernet, (6) cabeceras USB internas, (7)(8) marcas de la placa, (9) la cabecera de consola J2, (10) una huella JTAG sin poblar.

Paso 2 — poniéndole nombre

La serigrafía 45-402-000022 coincidía exactamente con la placa documentada, y cada chip — SoC, flash, WiFi, los 64 MB de RAM — encajaba pieza a pieza con la variante -53b. Ahora no solo sabía qué era; sabía dónde vivía su UART y qué cuenta me dejaría entrar.

Paso 3 — cazando la UART

Justo al lado del SoC había una cabecera poblada de 6 pines en ángulo recto, con la serigrafía J2 y un triángulo que marca el pin 1. Lo confirmé con la página de OpenWrt para el modelo:

115200 8N1, 3.3V TTL.

Cómo encuentras una UART cuando no hay ninguna wiki que te diga el pinout — la parte que demuestra que esto no es solo seguir una receta:

• GND — continuidad (pitido) con el plano de tierra / escudo, con la placa sin alimentar.
• VCC — un riel que se mantiene estable en ~3.3 V una vez alimentada.
• TX — se mantiene en alto a ~3.3 V (estado de marca UART) y visiblemente baja/parpadea en el instante en que el dispositivo arranca y empieza a escupir su log. Ese parpadeo es la consola hablando.
• RX — normalmente la tranquila: flotante o con pull débil, sin actividad de arranque.

¿Y si no sabías el baudrate? 115200 es el valor por defecto del CFE de Broadcom, pero a ciegas barrerías las velocidades habituales (9600 → 115200) hasta que la basura se convirtiera en ASCII, o medirías el periodo de bit más estrecho en un osciloscopio y harías 1 / t.

Paso 4 — obteniendo una consola

Conecté un adaptador USB-TTL (HW-597, PL2303) con el jumper en 3.3V. Esto importa: la UART del BCM6368 es TTL de 3.3 V, no RS-232 (±12 V) — si le cuelgas un puerto serie real o un adaptador de 5 V, fríes el pin. Primero tierra, luego RX/TX cruzados, VCC flotante para que nada realimente la placa. Antes de aplicar alimentación confirmé GND y VCC con un multímetro, y luego:

screen /dev/ttyUSB0 115200

Lo encendí, vi al CFE pasar el control al kernel, vi arrancar el init de BusyBox y aterricé en un prompt de login.

Paso 5 — la puerta principal estaba abierta de par en par · CVE-2025-0890

El login cedió ante una cuenta oculta de fábrica que ZyXEL nunca documenta para el usuario final:

user:     supervisor
pass:     zyad1234

Privilegio total del sistema. Este es el núcleo de CVE-2025-0890.

Paso 6 — fugándose de la jaula del fabricante · CVE-2024-40891

Ese login me dejó en una CLI de fabricante bloqueada (consoled, un prompt >): sin sh, sin ninguna de las herramientas habituales de Linux — una jaula alrededor del sistema real. Pero exponía un diagnóstico ping, y ese comando insertaba su argumento directamente en una cadena de shell con cero sanitización. Así que le pasé un metacarácter de shell:

> ping 127.0.0.1; sh

…y caí en una shell root de BusyBox (#).

Por qué basta un punto y coma: el manejador de la CLI hace el equivalente de system("ping " + userinput). El ; cierra el comando ping e inicia un segundo — sh — que hereda el stdin/stdout de la consola, así que obtienes una shell interactiva. La cuenta ya era uid 0; la CLI era lo único que se interponía entre yo y una shell real, y la entrada sin sanitizar derribó esa pared. Encadenar una inyección autenticada en la CLI con la cuenta oculta es exactamente el patrón registrado como CVE-2024-40891.

Paso 7 — recogiendo el botín

Con root, eché un vistazo al sistema y al flash:

# cat /proc/version
Linux version 2.6.30 ... (Buildroot 2010.02) #1 Mon Jun 11 2012

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 004f5000 004f5000 "Physically mapped flash"     # 5,197,824 bytes = the whole firmware

Lo que te está diciendo /proc/mtd: el flash es NOR paralelo, mapeado en memoria — la CPU lo ve como un rango de direcciones plano (hacia 0xB8000000 en MIPS KSEG1), expuesto como una única partición MTD. Son excelentes noticias para un volcado: el NOR se lee limpio, sin los bytes spare/OOB ni las rarezas de ECC con las que peleas en NAND. /dev/mtdblock0 es la imagen del firmware.

Luego las contraseñas. No hay /etc/shadow — los hashes están directamente en /etc/passwd, usando el antiguo DES crypt:

supervisor:SuO7vycdWI/rU:0:0:Administrator:/:/bin/sh
support:xoKf506EVkGKw:1:0:Technical Support:/:/bin/sh
user:QWOftoXez8Goo:2:0:Normal User:/:/bin/sh
admin:OJGXQ9dWyb9m2:100:0:Administrator:/:/bin/sh

Los extraje y los crackeé sin conexión con John the Ripper (--format=descrypt). Los seis cayeron en menos de un segundo:

Por qué se evaporan al instante: el crypt(3) de DES solo usaba los primeros 8 caracteres de la contraseña y una sal de 12 bits, pasados por 25 rondas de DES. En una CPU moderna, un cracker de DES bitslice mastica decenas de millones de candidatos por segundo — así que contraseñas de fábrica triviales como admin o support ni siquiera se notan como trabajo. Este esquema quedó obsoleto hace décadas; encontrarlo en firmware en circulación es el hallazgo real.

Cuatro cuentas de fábrica con privilegio a nivel root, contraseñas triviales, idénticas en todas las unidades de este modelo.

Qué está realmente roto

Toda la cadena, en una línea:

PCB photo → ID the SoC → find the UART (J2) → serial console
   → hidden account (F-1) → locked CLI → command injection (F-2)
   → root shell → dump + crack every credential (F-3)

«Buen 0-day, tío» — no, y ese es el punto

No descubrí nada de esto. Es reproducción, mediante acceso físico, de fallos públicos y actualmente relevantes:

• CVE-2025-0890 — credenciales débiles/ocultas, incluyendo explícitamente supervisor:zyad1234, en CPE DSL heredados de ZyXEL. → F-1
• CVE-2024-40891 — inyección de comandos autenticada en la CLI, comandos pasados sin verificar a una shell; explotado encadenado con CVE-2025-0890. → F-2
• El linaje más antiguo de inyección ping de ZyXEL: CVE-2015-6018, CVE-2017-6884. → F-2

Estos afectan a equipos al final de su vida útil que ZyXEL ha dicho que no arreglará, y se ha visto que se explotan en el mundo real — que es exactamente por lo que importa ensuciarse las manos con la mecánica. El valor aquí no es un fallo nuevo; es el flujo de trabajo completo de silicio a shell, hecho y documentado.

Cómo lo arreglarías de verdad

• Elimina las cuentas hardcodeadas. Credenciales únicas por dispositivo, cambio forzado en el primer arranque.
• Sanitiza cada entrada de diagnóstico — lista blanca de caracteres, nunca concatenes la entrada del usuario en una shell (usa execve con un vector de argumentos, no system()).
• Mueve el almacenamiento de contraseñas a /etc/shadow con un hash moderno (bcrypt / SHA-512-crypt), no DES.
• Para hardware EOL que el fabricante no va a parchear: reemplázalo.

Asuntos pendientes

• Volcar el firmware desde mtd0 (/dev/mtdblock0, 5,197,824 bytes) por el propio WiFi del router + nc, y luego desempaquetarlo con binwalk (espera cabecera CFE + kernel comprimido con LZMA + rootfs SquashFS + nvram). Método completo en evidence/dump-methods.md.
• Extraer los secretos del ISP del nvram/config (PPPoE, PSK WiFi, URL ACS de TR-069, VoIP).

El equipo que usé

Análisis del PCB a partir de fotos (ImageMagick), un multímetro, un adaptador USB-TTL PL2303 (HW-597) a 3.3 V, screen para la consola serie (115200 8N1), y John the Ripper (descrypt) para los hashes. Identificación mediante OpenWrt, TechInfoDepot y la base de datos de la FCC.

Fuentes y referencias

Identificación del dispositivo

• TechInfoDepot — ZyXEL P-870HN-51b (número de placa 45-402-000022, flash MX29LV640EBTI-70G)
• TechInfoDepot — ZyXEL P-870HN-53b (variante de 64 MB de RAM)
• OpenWrt — ZyXEL P-870HN-5xb (página del dispositivo + pinout del puerto serie)
• FCC ID I88P870HN51B

Vulnerabilidades

• CVE-2025-0890 — cuenta supervisor oculta
• CVE-2024-40891 — inyección de comandos autenticada en la CLI · contexto del informe
• CVE-2015-6018 · CVE-2017-6884 — inyección de comandos ping anterior de ZyXEL

Hardware y técnica

• Hoja de datos del Macronix MX29LV640E (PDF)
• OpenWrt — Referencia de consola serie
• River Loop Security — Cómo obtener una shell root vía UART
• Secure Ideas — Cómo encontrar pinouts de UART en PCBs
• SparkFun — Guía de conexión USB-a-serie del CP2102

Herramientas

• John the Ripper · binwalk

Una vez más, para que conste

Hecho en hardware mío, aislado de la red, sin sistemas de terceros de por medio. Los fallos están documentados públicamente y citados arriba. Lo que pongo bajo mi nombre es el método de hardware-hacking de extremo a extremo y su ejecución — no el descubrimiento de los fallos.