Hardware Hacking Parte 1: Rodando DOOM em Um Roteador

Opa, eae?! Pouco tempo de hiato por aqui no blog, tô ligado… Bora lá hackear uns hardware??? Segue a parte 1, ou um “começando a hackear rodando DOOM num TP-Link”, que eu fiz com o mano @LucasCardoso

Sempre bom um disclaimer já que é hacking (este vai ser pequeno)

Este presente e maravilhoso post possui apenas cunho educacional e de pesquisa. Utilize as informações aqui contidas e os demais links apontados, de nossa autoria ou de terceiros, apenas para melhorar os seus conhecimentos.
A utilização dos conhecimentos e demais informações contidas aqui (e nos links apontados) é de única, total e exclusiva responsabilidade de você (o leitor); use-as com sabedoria e assuma seus riscos.
Caso venha a citar ou utilizar trechos deste texto, a licença vinculada a este artigo encontra-se no rodapé da página, com o selo Creative Commons. Caso cite, pedimos também que inclua um disclaimer que pode ser igual ou próximo a este. 🙃

Parte 0: O objetivo

Pegar um roteador e rodar DOOM de algum jeito nele! 🦆
Let’s Hacking!

Parte 0.5: O Hardware

TP-Link TL-WR841ND(BR), será nosso hardware porque era o roteador que tínhamos aqui de bobeira e quebrar ele não seria um grande problema, além do mais ele é bem antigo, o firmware dele data de 2015 (como vamos ver no futuro) o que deve facilitar acharmos exploits já na internet ou só esperar que ele tenha uma segurança não tão boa pela idade.

Parte 1: OSINT

A Clássica parte inicial de todo hacking que é o “conheça o seu inimigo” no caso seu hardware, confesso que eu (Marlon, o cara que está escrevendo isso não fez, mas o Lucas que estava comigo pesquisou um pouco).

E o que obtivemos foi algumas informações do site do OpenWRT.

Passando rapidinho o OpenWRT é um sistema operacional para roteadores aberto baseado em linux, o objetivo dele é basicamente ser uma alternativa para você trocar o firmware de fábrica de um roteador que tem um sistema proprietário (como esse) para um sistema aberto de seu total controle, ele também é muito útil para salvar hardwares antigos que não recebem mais atualizações.

De fato não queremos instalar o OpenWRT aqui já que achamos que seria meio sem graça, após instalar ele teríamos todo o controle total do sistema e seria fácil cumprir nosso objetivo. Porém o site dele tem uma página focada neste roteador (ou quase já que o nosso é versão BR e o deles versão internacional) e nos deu algumas informações iniciais.

Link: https://openwrt.org/toh/tp-link/tl-wr841nd

Parte 1.5: Olhando o hardware

Abrimos o hardware e demos uma olhada inicial pela placa, aqui eu já tinha um pouco de familiaridade por experiências passadas e foi fácil conhecer alguns componentes maiores e de maior relevância.

Mas caso essa seja a sua primeira vez, vale procurar os ‘chips’ (os invólucros pretos com muitas pernas) e pesquisar o que está escrito neles, lupa, microscópio ou uma câmera com macro ou bom zoom irão te ajudar.
Uma coisa que percebemos é que o GEMINI (e outras IAs provavelmente também) leem muito bem essas imagens e já pode além de te dar o OCR do chip fácil, já te dar algumas informações (que podem estar certas ou não kkkk).

No final temos isso aqui como uma olhada macro da placa:

Vamos em ordem:

SPI Flash: Essa aqui é uma clássica e queridinha dos hardwares embarcados. Várias empresas produzem, mas elas seguem o mesmo padrão, 4 pinos de cada lado e protocolo SPI de comunicação. Essa ai tem 4MB de memória e como é flash é ROM, ou seja, não volátil.

Ram de 256MB: Tão simples quanto a flash, é a RAM do roteador, não me parece que seria fácil usar ela para algum hacking, é uma memória volátil e usada pelo sistema enquanto ele está funcionando, mas ela é fácil de identificar.

SOC: Para quem não está acostumando com o mundo de hardware o termo SOC pode parecer estranho. Mas é o que no passado chamávamos de processador ou até microcontrolador. E a diferença entre alguns pode ser ambígua e difícil de traçar. Porém o SOC vem de System On a Chip, ou seja, em vez de termos um processador em uma placa e demais elementos como RAM, ROM, chip de rádio, criptografia, gráfico, comunicação e tudo mais que sua imaginação pode pensar… Temos tudo isso que seriam elementos separados em uma placa em um único chip, essa é a maravilha da evolução da microeletrônica.
Esses elementos são variados de cada modelo de SOC e não vamos também nos aprofundar nesse SOC em específico (o Qualcomm Atheros QCA9533), mas caso nossas tentativas de hacking não dessem certo conhecer mais sobre essa parte do hardware poderia ser importante.

Serial: A gente não se aprofundou em ver mais sobre esses pinos, essa é a verdade. Mas chutaria que é um J-Tag daria para usar eles e um J-Link provávelmente (caso queira saber mais sobre isso recomendo meu post anterior a este “Usando Devkits Nordic como J-link” onde explico mais sobre as J-Tags e J-links: https://blog.marlonhenq.dev/posts/10/usando-devkits-nordic-como-j-link.php)

4 Pinos (SWO)?: Spoiler! Não é uma SWO! Ok, ter lido a página do OpenWRT poderia ter me poupado dessa tentativa.

Talvez… Só…

Mas, quando eu vi isso, na placa:

Eu tinha muita certeza que isso era SWO, pois era igual os SWOs que já utilizei enquanto hackeava ESLs (Etiquetas Eletrônicas de Prateleira) em um projeto da UFSCar junto a Leroy Merlin.
E pior ainda, eu tinha certeza que isso era um GND, afinal ele é quadrado, poxa! Era para ser GND!

Voltando no assunto: SWO é um tipo de comunicação para ARM e para debug, com ela você consegue extrair o firmware de um SOC, gravar um firmware, ter terminal com ele, fazer debug parando a execução no meio, enfim, bem massa.

E claro! Após seguir o pinout de 4 pinos do SWO e ligar no J-Link… Não deu certo, afinal… Não era SWO!!!
Aí o GEMINI soltou a carta: Isso não é ARM, é um MIPS, cara! Não tem SWO! (Ele não falou exatamente dessa forma, eu sei, mas precisamos de dramaturgia neste post também)

E a conclusão lógica foi “Ok. Só pode ser UART”, como eu disse, ter lido antes a página do OpenWRT ajudaria muito, mas a ansiedade de fazer algo prático soou maior.

Parte 2: Comunicação Serial

É UART! E agora…?

Bacana, vocês tem a informação que era só ver a imagem no site do OpenWRT, mas eu não tinha!

Estávamos na UFSCar e sem boa parte dos meus equipamentos, mas o objetivo era descobrir o pinout (qual era RX, TX, GND e VCC talvez), nisso fomos buscar por um multímetro, já que se eu descubro o GND e VCC os outros dois serão o RX e o TX e se de primeira não funcionar é só inverter os dois que assim irá funcionar.

Pegamos dois multímetros em lugares diferentes da Federal e lógico, os dois queimados, não se pode confiar em equipamento utilizado por estudantes mesmo!

No final a verdade é que com muita tentativa e erro conseguimos descobrir o TX ao menos.

Ligando no computador usando um conversor TTL USB e puxando um terminal serial (eu usei a extensão da Nordic “nRF Terminal” no VS Code, mas pode ser o de sua preferência) obtivemos isso:

Ok, eu sei, essa imagem está horrível! O problema é que não documentamos bem o processo durante o processo e eu não consegui replicar mais esse problema para poder ter um bom print.

Como dá para ver (ou não) o terminal soltou caracteres basicamente aleatórios, o que fizemos para resolver isso foi uma mistura de não confiar mais no que achávamos que era o GND da UART e para fazer isso riscamos a malha de GND da placa e soldamos um fio. E além disso, o Lucas descobriu que o terminal estava no padrão 7n1 de bits e não o 8n1, que é o default e mais convencional no UART.

Isso para quem não está acostumando com hardware pode ser estranho, mas no geral todas as placas colocam no “espaço livre” uma malha, ou seja, deixam o cobre lá e interligam isso ao GND da placa. Os motivos são vários como diminuir a interferência eletromagnética, controle de impedância, diminuição de ruído, dissipação térmica, facilitar o roteamento e melhorar o processo de fabricação dessas placas mesmo.
Ou seja, quando achar uma grande malha de cobre em uma placa, muito provavelmente aquilo é GND.

Configurando tudo isso temos como resultado:

IHHA! And that worked! Somehow!

O problema é: Não temos login para o root do sistema, tentamos os básicos (root, admin, 1234, “”), mas nada funciona. Também tentamos os possíveis comandos para parar o bootloader como CTRL + C, F, SPACE_BAR, como as IAs e a documentação do OpenWRT dizia, porém nada funcionou pois o U-Boot era travado e não aceitava inputs, muito provavelmente pela segurança mesmo.

Passo 3: Obtendo acesso ao root, como?

Temos um terminal, mas sem login nele, já descobrimos que logins padrão não funcionam e não temos isso vazado na internet, provavelmente é gerado uma senha aleatória por roteador, então parece que não conseguiríamos transponir isso de maneira fácil.
O bruteforce além de deselegante poderia demorar muito mesmo, nem cogitamos.

Voltando a placa, o que temos que pode nos ajudar?

Acho que por aqui teríamos duas opções, a primeira era tentar esse serial e ver a fundo o que são os pinos, se são mesmo J-tag, ou outra coisa e começar por ai.

A segunda era olhar a flash, bom… Temos todo os arquivos na Flash, o sistema operacional todo, inclusive o root e sua senha "hasheada, se pudéssemos olhar isso e achar a senha equivalente a esse flash ou sumir com ela e voltar com o sistema sem senha, problema resolvido certo?

Ok! Vamos dumpar essa flash!

Para fazer isso precisamos de um clássico do hardware o CH431, se você atualizou uma BIOS no passado ou teve que "desbricar uma placa mãe com BIOS corrompida você já deve ter visto um desses antes.

O CH431 é um gravador/programador e leitor de memórias EEPROM e Flash, então era tudo o que precisávamos. Além disso ele é frequentemente vendido em kit com uma garra jacaré que permite você ter contato com o chip de memória sem nem mesmo retirar ele dá placa original e felizmente esse era o kit que eu tinha.

Show! Pegamos o CH431 e a Garra conectamos ela na flash e o CH431 no computador e…

Obviamente deu errado de primeira. Nos primeiros erros o problema é que o CH431 nem estava sendo reconhecido pelo meu computador, isso provavelmente estava ocorrendo pois quando colocavamos a garra na flash passavamos a alimentar o roteador e ele começava a funcionar, porém o Ch431 e até talvez a minha USb não tinham corrente para isso tudo e passavam a falhar.

A segunda tentativa foi então alimentar o roteador via sua fonte, tomar o cuidado de não ligar o VCC da garra no CH431 para não voltar tensão para minha USB e talvez queima-lá e testar.
Assim o CH431 passou a ser reconhecido, mas a memória não e o problema é que o roteador começava a bootar e funcionar com o SOC acessando a memória, impedindo que outro dispositivo a acessasse.

Dessa forma, não tivemos outra opção além de dessoldar a memória da placa do roteador e soltar no CH431.
Eu tinha um soldador de 30w sem regulagem de temperatura, uma solda e as habilidades do Marlon de uns 10~11 anos que não tinha mais nada a se fazer além de brincar com placas-mãe queimadas.

E deu certo!

Passo 4: Modificando o Filesystem

Beleza, agora temos a flash dumpada. Ou seja: temos o sistema operacional inteiro do roteador na nossa mão. Kernel, bootloader, filesystem, configs… tudo ali dentro daquele .bin.

O próximo passo era simples em teoria e chato na prática: entender o que tem dentro desse binário.

Encontrando as partições

Para encontrar as partições utilizamos o binwalk (segundo o Lucas, magia), ele tem a capacidade mágica de receber um bin e analisar ele, devolvendo o que temos nesse .bin.

binwalk flash_dump.bin

E como esperado, lá estava ele: um SquashFS, que é basicamente o filesystem comprimido usado pelo Linux embarcado do roteador.

Separando a partição do filesystem

Sabendo o offset certinho do SquashFS, usamos o dd para recortar somente a parte da memória que continha o filesystem:

dd if=flash_dump.bin of=rootfs.bin bs=1 skip=< OFFSET>

Agora temos um arquivo que representa apenas o filesystem do roteador.

Descomprimindo o SquashFS

Com a partição em mãos, o próximo passo foi transformar isso em algo navegável. Para isso usamos o unsquashfs:

unsquashfs rootfs.bin

E pronto! Temos uma pasta squashfs-root/ com toda a estrutura de um Linux:

Estamos quase lá! Se temos um sistema Linux-like e queremos acesso ao root, não tem tanto segredo, vamos para o /etc/shadow e simplesmente removemos a parte da senha transformando ela apenas em um valor vazio “”.

Reempacotando tudo

Filesystem modificado, agora precisamos transformar isso de volta em um SquashFS válido. Usamos o mksquashfs: mksquashfs squashfs-root new_rootfs.bin -noappend

Agora temos um novo filesystem, já com o root sem senha.

Sobrescrevendo apenas o rootfs no firmware

Não queremos bagunçar o firmware inteiro, só substituir a partição do filesystem. Então usamos novamente o dd, agora no sentido inverso:

dd if=new_rootfs.bin of=wr841nd_v9.3_patched.bin bs=1 seek=$((0x120000)) conv=notrunc

Aqui estamos pulando para o offset que começa o rootfs, sobrescrevendo só essa região e mantendo o resto do firmware intacto! (vlw ao Gemini por ter ajudado nessa parte também!)

Se rodarmos um binwalk nesse novo firmware podemos ver ele agora com uma data nova, o resto (partes originais do firmware) estão datadas de 2015 e temos a nossa parte modificada em 2025:

Gravando de volta na flash Com o firmware modificado em mãos, é hora de devolver ele ao chip:

sudo flashrom -p ch341a_spi -c "MX25L3206E/MX25L3208E" -w wr841nd_v9.3_patched.bin

Passo 5: Root sem senha

Soldamos de volta a flash no roteador e… Bootou! 🦆

Aí foi só mandar um ‘root’ e enter e temos um terminal!

Navegando

Agora só dar um mkdir… Então, não temos mkdir, nem touch nem VI, muito menos NANO.

Apenas conseguimos utilizar alguns comandos, através do busybox, um software que agrupa várias ferramentas essenciais de forma compacta, o que é muito comum em sistemas embarcados como esse.

Passo 6: Finalizando o Hacking

Descobrimos também que não conseguimos editar arquivos já que o sistema todo é read only com exceção do diretório /tmp.
A solução aqui foi criar um arquivo ‘index.htm’ com ‘echo’ contendo um iframe para um DOOM em /tmp.

echo "<html>
<head><title>ROUTER HACKEDtitle>head>
<body style="margin:0; padding:0; overflow:hidden;">
<iframe src="https://grahamthe.dev/demos/doom/"
style="border:none; width:100%; height:100%;">
iframe>
body>
html>" > /tmp/index.htm

E fazer um mount bind do arquivo de login (tela inicial de configuração do roteador) para o index recém criado. Fazendo com que o servidor web do roteador passasse a prover o nosso arquivo e assim provesse o DOOM.

mount --bind /tmp/index.htm /web/userRpm/LoginRpm.htm

E Fim! Hack completo!

Fim e considerações finais

Ufa! Terminamos mais um post esse um pouco mais diferente dos outros por aqui marcando mais uma jornada do que um tutorial ou um conteúdo de ensino mesmo. Dito isso, espero que você tenha aprendido apenas alguma coisa aqui e principalmente tenha, quem sabe, ficado com vontade de hackear algo.

“Mas Marlon, ele não está rodando DOOM de fato ele está servindo DOOM…”
De fato! O DOOM não está rodando no roteador. Hacking para todo efeito é fazer com que o sistema/hardware faça algo que ele não foi projetado para fazer, e de fato um roteador não foi feito para servir DOOM haha! O legal também é que usamos tudo “por padrão” dele, o servidor web é o do roteador, e ele continua funcionando perfeitamente por baixo dos panos, tanto é que roteia a WWW para o computador o que faz com que o iframe funcione mesmo apontando para um servidor externo.

Este foi o primeiro capítulo do que eu espero (mas não prometo) ser uma série sobre hardware hacking, aqui já passamos por alguns protocolos como SPI e UART, falamos de outros como SWO, usamos algumas ferramentas diferentes tanto físicas quanto em software e espero continuar escrevendo sobre isso por aqui. É um aprendizado sendo criado e compartilhado ao mesmo tempo como jornada.

Um valeu de novo para o Lucas por ter feito toda essa jornada junto comigo e ter revisado este texto.

É isso! Muito obrigado como sempre por ter lido este post até aqui, e até mais!