De uma PCB nua até root: hardware-hacking de um ZyXEL P-870HN via UART

Duas fotos de celular de uma placa de roteador sem etiqueta → console serial → bypass de autenticação → shell root — reproduzindo a cadeia real, ainda sem patch, CVE-2025-0890 (conta supervisor oculta) + CVE-2024-40891 (injeção de comando no CLI) no hardware que eu possuo.

por damik0 · 2026-08-13 · um passo a passo de hardware-hacking

  📷 Fotos da PCB ─▶ 🔬 recon de chips ─▶ 🏷️  ID do modelo ─▶ 📍 encontrar UART (J2)
       └─▶ 🔌 console serial ─▶ 🚪 conta oculta ─▶ ⛓️  escapar do CLI
              └─▶ 🐚 shell root ─▶ 🔓 dump + quebrar todas as credenciais

TL;DR

Eu tinha uma placa de roteador aleatória em cima da mesa. Sem carcaça, sem etiqueta, sem ideia do que era. Partindo do nada além de duas fotos, li cada chip da PCB, identifiquei o modelo exato, encontrei o header serial (UART), liguei nele, entrei por uma conta de backdoor de fábrica, escapei de um menu do fornecedor bloqueado para um shell Linux root e extraí todas as senhas do equipamento — quebradas em menos de um segundo.

Nenhum desses bugs é meu. São problemas documentados da ZyXEL que o fornecedor disse que não vai corrigir. O que este repo mostra é o como, de ponta a ponta, e o raciocínio em cada etapa.

Antes de tudo: este é o meu próprio hardware

• O alvo é uma placa de roteador que eu possuo.
• A entrada foi pela porta serial física da PCB — sem ataque remoto, sem rede de terceiros, nada exposto à internet.
• Ela ficou na minha bancada, isolada (air-gapped), o tempo todo.
• O objetivo era executar o ciclo completo de hardware-hacking de ponta a ponta e documentá-lo para que seja reproduzível.

O que eu estava cutucando

Descobri a identificação a partir do número da placa na serigrafia 45-402-000022 e do código de barras, cruzando com o TechInfoDepot, a tabela de hardware do OpenWrt e o FCC ID I88P870HN51B:

Por que o número da placa é a chave que destranca tudo: gateways ODM como este são projetos de referência. Quando o número de parte na serigrafia corresponde a uma placa documentada, você herda o dever de casa de outra pessoa — o chip de flash exato, a localização e o pinout da UART, as contas padrão. A identificação não é uma formalidade; é o que transforma sondagem às cegas em um ataque direcionado.

Como aconteceu

Passo 0 — tirando as fotos do celular

Primeiro, uma pequena melhoria de qualidade de vida: montei rapidinho um uploader de fotos via LAN (stdlib do Python, zero dependências) para fotografar a placa com o celular e as fotos caírem direto na minha máquina. Metade de uma boa sessão é eliminar esse tipo de atrito.

Passo 1 — lendo a placa

Fui chip por chip nas fotos em alta resolução. Os tipos de encapsulamento contam a história antes mesmo de você ler as marcações: o BGA no centro é o cérebro, o TSOP-48 quase sempre é a flash paralela, a latinha com o cabo coaxial é o rádio. O SoC estava escondido sob um escudo de RF (ali por causa de EMI + como dissipador de calor), então tirei a tampa para ler a marcação embaixo — um Broadcom BCM6368.

A placa mapeada: (1) SoC BCM6368, (2) RAM DDR2, (3) WiFi BCM43222, (4) transformador de linha DSL, (5) magnéticos Ethernet, (6) headers USB internos, (7)(8) marcações da placa, (9) header de console J2, (10) footprint JTAG não populado.

Passo 2 — dando um nome a ela

A serigrafia 45-402-000022 correspondeu exatamente à placa documentada, e cada chip — SoC, flash, WiFi, os 64 MB de RAM — bateu peça por peça com a variante -53b. Agora eu não sabia apenas o que era; eu sabia onde vivia a UART e qual conta me deixaria entrar.

Passo 3 — caçando a UART

Bem ao lado do SoC havia um header de 6 pinos em ângulo reto, populado, com serigrafia J2 e um triângulo marcando o pino 1. Confirmei na página do OpenWrt para o modelo:

115200 8N1, TTL de 3,3 V.

Como encontrar uma UART quando não há wiki informando o pinout — a parte que mostra que isto não é apenas seguir uma receita:

• GND — continuidade (bip) com o plano de terra / a blindagem, com a placa desenergizada.
• VCC — um trilho que se mantém estável em ~3,3 V quando energizado.
• TX — fica em nível alto em ~3,3 V (estado de marca da UART) e oscila/pisca visivelmente no instante em que o dispositivo inicia e começa a despejar o log. Essa oscilação é o console falando.
• RX — normalmente o quieto: flutuante ou com pull fraco, sem atividade no boot.

E se você não soubesse o baud? 115200 é o padrão do CFE da Broadcom, mas às cegas você varreria as taxas comuns (9600 → 115200) até o lixo virar ASCII, ou mediria o período de bit mais estreito num osciloscópio e faria 1 / t.

Passo 4 — obtendo um console

Liguei um adaptador USB-TTL (HW-597, PL2303) com o jumper em 3,3 V. Isso importa: a UART do BCM6368 é TTL de 3,3 V, não RS-232 (±12 V) — conecte uma porta serial de verdade ou um adaptador de 5 V nela e você queima o pino. Terra primeiro, depois RX/TX cruzados, VCC deixado flutuante para que nada realimente a placa. Antes de aplicar energia, confirmei GND e VCC com um multímetro e então:

screen /dev/ttyUSB0 115200

Liguei, vi o CFE passar o controle para o kernel, vi o init do BusyBox subir e parei em um prompt de login.

Passo 5 — a porta da frente estava escancarada · CVE-2025-0890

O login cedeu a uma conta de fábrica oculta que a ZyXEL nunca documenta para o usuário final:

user:     supervisor
pass:     zyad1234

Privilégio total do sistema. Esse é o núcleo da CVE-2025-0890.

Passo 6 — escapando da jaula do fornecedor · CVE-2024-40891

Esse login me jogou em um CLI do fornecedor bloqueado (consoled, um prompt >): sem sh, nenhuma das ferramentas Linux usuais — uma jaula em volta do sistema real. Mas ele expunha um diagnóstico ping, e esse comando montava o argumento direto numa string de shell com zero sanitização. Então dei a ele um metacaractere de shell:

> ping 127.0.0.1; sh

…e caí em um shell BusyBox root (#).

Por que um ponto e vírgula é suficiente: o handler do CLI faz o equivalente a system("ping " + userinput). O ; encerra o comando ping e inicia um segundo — sh — que herda o stdin/stdout do console, então você obtém um shell interativo. A conta já era uid 0; o CLI era a única coisa entre mim e um shell de verdade, e a entrada não sanitizada derrubou essa parede. Encadear uma injeção de CLI autenticada na conta oculta é exatamente o padrão rastreado como CVE-2024-40891.

Passo 7 — pegando o butim

Com root, examinei o sistema e a 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

O que /proc/mtd está lhe dizendo: a flash é NOR paralela mapeada em memória — a CPU a enxerga como uma faixa plana de endereços (por volta de 0xB8000000 no KSEG1 do MIPS), exposta como uma única partição MTD. Isso é ótimo para um dump: a NOR faz leitura limpa, sem os bytes spare/OOB e as esquisitices de ECC com que você luta em NAND. /dev/mtdblock0 é a imagem do firmware.

Então, as senhas. Não há /etc/shadow — os hashes estão bem em /etc/passwd, usando o antigo crypt DES:

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

Extraí os hashes e os quebrei offline com o John the Ripper (--format=descrypt). Todos os seis caíram em menos de um segundo:

Por que elas evaporam instantaneamente: o crypt(3) DES só usava os primeiros 8 caracteres da senha e um salt de 12 bits, passados por 25 rodadas de DES. Numa CPU moderna, um cracker DES em bitslice processa dezenas de milhões de candidatos por segundo — então senhas de fábrica triviais como admin ou support nem contam como trabalho. Esse esquema já era obsoleto há décadas; encontrá-lo em firmware de produção é o verdadeiro achado.

Quatro contas de fábrica com privilégio de root, senhas triviais, idênticas em todas as unidades deste modelo.

O que está realmente quebrado

A cadeia completa, em uma linha:

Foto da PCB → ID do SoC → encontrar a UART (J2) → console serial
   → conta oculta (F-1) → CLI bloqueado → injeção de comando (F-2)
   → shell root → dump + quebrar todas as credenciais (F-3)

"0-day maneiro, mano" — não, e é exatamente esse o ponto

Não fui eu que descobri nada disso. É reprodução, por acesso físico, de bugs públicos e atualmente relevantes:

• CVE-2025-0890 — credenciais fracas/ocultas, incluindo explicitamente supervisor:zyad1234, em CPE DSL legados da ZyXEL. → F-1
• CVE-2024-40891 — injeção de comando autenticada no CLI, comandos passados sem verificação para um shell; explorada encadeada com a CVE-2025-0890. → F-2
• A linhagem mais antiga de injeção no ping da ZyXEL: CVE-2015-6018, CVE-2017-6884. → F-2

Essas falhas atingem equipamentos em fim de vida que a ZyXEL disse que não vai corrigir, e já foram vistas sendo exploradas na natureza — exatamente por isso colocar as mãos na mecânica importa. O valor aqui não é um bug novo; é o fluxo de trabalho completo de silício até o shell, feito e documentado.

Como você realmente consertaria isso

• Elimine as contas com credenciais fixas. Credenciais únicas por dispositivo, troca forçada no primeiro boot.
• Sanitize toda entrada de diagnóstico — lista de permissão de caracteres, nunca concatene entrada do usuário num shell (use execve com um vetor de argumentos, não system()).
• Mova o armazenamento de senhas para /etc/shadow com um hash moderno (bcrypt / SHA-512-crypt), não DES.
• Para hardware em fim de vida que o fornecedor não vai corrigir: substitua-o.

Tarefas pendentes

• Faça o dump do firmware de mtd0 (/dev/mtdblock0, 5,197,824 bytes) pelo próprio WiFi do roteador + nc e depois desempacote com binwalk (espere header CFE + kernel comprimido em LZMA + rootfs SquashFS + nvram). Método completo em evidence/dump-methods.md.
• Vasculhe a nvram/config em busca de segredos do ISP (PPPoE, PSK do WiFi, URL do ACS do TR-069, VoIP).

O equipamento que usei

Análise da PCB a partir das fotos (ImageMagick), um multímetro, um adaptador USB-TTL PL2303 (HW-597) em 3,3 V, screen para o console serial (115200 8N1) e John the Ripper (descrypt) para os hashes. Identificação via OpenWrt, TechInfoDepot e o banco de dados da FCC.

Fontes e referências

Identificação do dispositivo

• TechInfoDepot — ZyXEL P-870HN-51b (número da 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 do dispositivo + pinout serial)
• FCC ID I88P870HN51B

Vulnerabilidades

• CVE-2025-0890 — conta supervisor oculta
• CVE-2024-40891 — injeção de comando autenticada no CLI · contexto do relato
• CVE-2015-6018 · CVE-2017-6884 — injeção de comando ping da ZyXEL, mais antiga

Hardware e técnica

• Macronix MX29LV640E datasheet (PDF)
• OpenWrt — Referência de console serial
• River Loop Security — Obtendo um shell root via UART
• Secure Ideas — Encontrando pinouts de UART em PCBs
• SparkFun — Guia de ligação USB-para-serial do CP2102

Ferramentas

• John the Ripper · binwalk

Mais uma vez, para registro

Feito no meu próprio hardware, isolado (air-gapped), sem sistemas de terceiros envolvidos. Os bugs são publicamente documentados e citados acima. Aquilo em que estou pondo meu nome é o método completo de hardware-hacking e sua execução — não a descoberta das falhas.