Jugando con los rayos 0: intro

En mi cuadra cayó un rayo y entre otras cosas se llevó parte del router, un TP-Link WDR3600n, que había elegido por que tiene USB, se puede cambiar con sencillez el firmware y otras tantas virtudes que nunca tuve tiempo de aprovechar... hasta ahora.

Normalmente comparto mis éxitos y errores, este es un caso de fracaso sin responsabilidad, puro aprendizaje.

Tras varios días de trabajo me dí cuenta que esto forma parte de la investigación en curso que vengo haciendo iniciada en la conversación[1]. Tiene tantas ramificaciones que he decido ir haciendo notas independientes, en parte para que la nota principal no sea tan larga y en parte por el MVP, si no tengo una inmensa nota que nunca termino pese a tener un montón de notitas útiles terminadas embebidas.


Me han dicho por ahí que nunca prenda un equipo que emite RF sin las antenas puestas, así que a diferencia de algún video que se puede ver por ahí, las antenas están puestas aunque el equipo esté despanzurrado.

Crónica

Un poco editado el orden pues si no es un interminable amasijo de idas y vueltas.

A la historia completa se accede por el índice.

El primer paso fue obtener una terminal serial, ayudado por [2]. Al igual que en [3], uso una edu-ciaa-nxp como adaptador USB/serial, tras haber controlado que el voltaje fuera el apropiado, 3.3v.

Mi esperanza es ver mensajes de error, ver como reacciona al conectarle y desconectarle cosas y así.

Todo arranca de maravillas, no hay errores evidentes, ni tampoco acceso a root, pues la clave que ronda por Internet no sirve.

Merodeando por ahí, hice algunas pruebas:

USB

Funcion, uno de estos días adunto evidencia, creeme, se ve en dmesg.

Ethernet

Aunque en los mensajes booteo no dice nada, roto, muy roto, tanto LAN como WAN. Algún día intentaré reemplazar los terminadores estos.

Luego los chips ...., pero antes, me han dado la pista que podría haberse roto un chip de alimentación. Es que las resistencias son sólo de LAN y si WAN tambien está rota, un elemento común sería ese.

Firmware

 

Podría continuar los pasos de [2] pues con el nuevo firmware, tendría el root que necesito, salvo que para cambiar el firmware necesito que funcione la red local...mmhhh.

Me bajé entonces el firmware oficial [4] a ver si podía hallar el password. Para esto necesito localizar /etc/shadow, lo cual implica tener que "desarmar" el archivo de boot. Mirando por encima [5] hallé que binwalk es la herramienta que necesitaba. En parte mirando los mensaje de error y en parte mirando https://github.com/ReFirmLabs/binwalk/blob/master/INSTALL.md...


sudo apt install binwalk
sudo apt install squashfs-tools


sudo apt-get install zlib1g-dev liblzma-dev liblzo2-dev
git clone https://github.com/devttys0/sasquatch
cd sasquatch
./build.sh

no me gustó para nada que ./build.sh tenga un sudo adentro, pues yo pensaba instalarlo en otro lado...

binwalk -e imagen.bin


me dejó el shadow tal como necesitaba, con password sohoadmin, que era el que había por todos lados [6] pero no funciona.

tpl

Si lográs escribir bien rápido "tpl" cuando dice "Autobooting in 1 seconds" te beneficiás con acceder al menu de boot [6].

Planes

Plan A - boot options - FAIL

Iniciar el S.O. en runlevel 1 a ver si no me pide la clave, usando la info de [7]

Parece que simplemente no está tomando bootargs, ni lo que yo modifico ni lo presente previamente, pues el kernel dice usar otra cosa.

Hay una entrada en u-boot [1] que aunque dice ser específica a ARM, quizás lo explique, no deben tener un seguimiento de lo que hace cada fabricante.

Lo que hay:
...:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),...

Lo que le pido:

...:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),...single

Lo que se usa:
...:128k(u-boot),1024k(kernel),6848k(rootfs),128k(config),... mem=128M

Hay una entrada en u-boot [8] que aunque dice ser específica a ARM, quizás lo explique, no deben tener un seguimiento de lo que hace cada fabricante.

Plan B - leer /etc/shadow actual

Obtener /etc/shadow y de allí la clave de root.

Plan B.1 - dump online via serial - FAIL

Volcar la memoria con lo que ofrece el monitor, a ver si la memoria flash es accesible por acá.

Esto lo desarrollé en la parte 1 y no funcionó. O sea, en el File System la clave es sohoadmin, pero no funciona!

Lo interesante es que lo que se puede bajar parece corresponder al último firmware, pero desordenado. Esto me lleva a tener que aprender más, voy a tener que intentar esto mismo en otros dispositivos.

Plan B.2 - dump offline via lectura de la memoria flash - FAIL

Leer la memoria flash. Habiendo fallado exitosamente el plan B.1 pues lo que se puede bajar aparentemente está desordenado, este es el camino para C.1.

Resultados [en construcción]

Plan C - nueva clave

Si no pudiera hallar la clave, siempre puedo reemplazarla

Plan C.1 - patch

Bajar el firmware, modificar /etc/shadow y volverlo a subir. Depende de B y de aprender a regenerar los checksums que entiendo que hay por ahí.

Plan C.2 - pisar

Subir un nuevo firmware pero pierdo el análisis forense que me permitiría contestar:

¿Por qué no tengo el password del firmware oficial si yo no cambié el firmware?

Resto de aventuras en el índice.

[1] Propuesta abierta de actividad ingeniería reversa
https://groups.google.com/forum/#!topic/embebidos32/V9vCEPplgC4

[2] Bricked TP-Link WDR4300 Router Recovery Using UART Serial Converter Part #1

[3]  Serial en Parallella paradumbs: trabajando más cómodo 

[4] Firmware oficial

[5] https://www.secforce.com/blog/2014/04/reverse-engineer-router-firmware-part-1/

[6] https://openwrt.org/toh/tp-link/tl-wdr3600#serie_u-boot

[7] http://redsymbol.net/linux-kernel-boot-parameters/2.6.31/

[8] https://www.denx.de/wiki/view/DULG/LinuxKernelIgnoresMyBootargs