• Inicio

  • Esta es la página índice del foro

Haciendo una WiFi Pineapple NANO

 DSR! |  27 Jul 2019 | Manuales, WiFi

Soy de esas personas inquietas que buscan proyectos cortos para poder hacer cosas diferentes los fines de semana y esta vez decidí seguir el consejo de un amigo y hacer un posteo al respecto.

Ese fin de semana toco probar suerte con el firmware de la WiFi Pineapple NANO a ver cuanto podía llegar a hacer con el y que se podía aprender de ello.


1. Reconociendo el hardware y buscando candidatos para suplirlo

El hardware oficial esta conformado por:

  • CPU: 400 MHz MIPS Atheros AR9331 SoC
  • Memory: 64 MB DDR2 RAM
  • Disk: 16 MB ROM

Afortunadamente las características son idénticas al GL-iNet AR150, un router pensado para aplicaciones IoT.


2. Buscando implementaciones similares para aprender de ellas

No siempre se es el primero en hacer estas cosas y este fue el caso, veamos un poco poco en Google:

Weaponizing the GL.iNet GL-AR150

Interesante método el de generar un firmware usando parte del file system original, pero leyendo un poco a usuarios que lo hicieron esto termina llenando la overlay partition que es el espacio libre que queda en la memoria flash para los archivos dinámicos del usuario.

También se podía leer que el firmware original ya en 2018 estaba agregando chequeo por hard lo que hacia el método inútil. Lo que me llevo a pensar, ¿esto era lo mejor que se podía hacer?


3. Entendiendo la estructura de un firmware

Típicamente este tipo de dispositivos tienen esta estructura, donde el bootloader termina cargando un kernel linux que interactuá con el file system. Normalmente esa ultima parte es la que es actualizable.

Por lo menos esta seria la forma mas rápida y concisa de explicarlo para no extenderme.

En nuestro caso es un kernel 3.18.84 y un Squashfs 4.0 que es el mas usado para este tipo de aplicaciones.


4. Creando un nuevo firmware para el GL-AR150

4.1 Planificando mi acercamiento

Entendiendo como se conforma un firmware y que cosas hay en un file system me di cuenta que la mejor manera era dejar este ultimo lo mas intacto posible para no acortar la overlay partition.

Para esto decidí hacer un kernel idéntico al usado en el equipo original pero que soporte mi board, cosa que al ser tanto el firmware original como el del AR150 basados en el SoC AR9331 y OpenWrt CC fue muy fácil, en especial porque para respetar la licencia del OpenWrt tienen que publicar sus fuentes.

4.2 Cazando repos y uniéndolos

Luego de googlear unos minutos llego a ambos repositorios:

NANO: https://github.com/hak5/wifipineapple-openwrt

AR150: https://github.com/domino-team/openwrt-cc

Examinando el repo de la NANO podemos ver que parte del commit e6fbf31baae41b618ff333f3ae55ff032333bd6a y viendo el del AR150 podemos ver que nos dejaron los parches para poder hacer cualquier repo basado en OpenWrt Chaos Calmer compatible con nuestro board. Esto no puede ser mejor realmente.

Podemos ver el resultado de esto en uno de mis repos https://github.com/xchwarze/pineapple-firmware-builder donde parti del commit mencionado y aplique los parches.

Luego de esto pasamos a compilarlo con los modulos de kernel que necesitemos y continuamos nuestra tarea. Si no saben los pasos para compilar un proyecto basado en OpenWrt pueden seguir esta guia https://github.com/domino-team/openwrt-cc/blob/master/README.md

4.3 Uniendo mi Frankenstein

La forma mas cómoda de unir lo que necesitaba de cada firmware era con Firmware Mod Kit.

Dejo los pasos a seguir en Ubuntu 18 a modo de ejemplo

Instalo FMK

git clone https://github.com/rampageX/firmware-mod-kit fmk-tool

sudo apt-get install git build-essential zlib1g-dev liblzma-dev python-magic bsdmainutils

Descomprimo los firmwares con FMK

#wget https://www.wifipineapple.com/downloads/nano/latest -O nanofw.bin

wget https://www.wifipineapple.com/downloads/nano/2.5.4 -O nanofw.bin

fmk-tool/extract-firmware.sh nanofw.bin

sudo mv fmk fmk-nano

cp openwrt-cc/bin/ar71xx/openwrt-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin ar150fw.bin

fmk-tool/extract-firmware.sh ar150fw.bin

sudo mv fmk fmk-ar150

Uno lo que necesito de cada imagen

cp fmk-ar150/image_parts/header.img fmk-nano/image_parts/header.img

sudo cp fmk-ar150/rootfs/lib/ar71xx.sh fmk-nano/rootfs/lib/ar71xx.sh

sudo rm -rf fmk-nano/rootfs/lib/modules/3.18.84

sudo cp -r fmk-ar150/rootfs/lib/modules/3.18.84 fmk-nano/rootfs/lib/modules/3.18.84

fmk-tool/build-firmware.sh fmk-nano/ -min

cp fmk-nano/new-firmware.bin .

Voy a explicar el ultimo bloque de comandos que es el mas importante.

Sobrescribo la imagen del kernel por el mio que soporta mi board y después edito del file system los archivos necesarios para que el board sea correctamente detectado. Luego de esto solo queda generar un nuevo firmware con FMK.


5. Pasando las verificaciones de autenticidad del board

Luego de flashear la imagen nueva podemos ver que el kernel es la misma versión que el original y que el espacio libre también es el mismo, esto ultimo ayuda a que el fs no colapse con el tiempo e inclusive la podemos usar así sin necesidad de agregar un pendrive.

Pero al querer usar el PineAP que es la principal herramienta vemos que no funciona a pesar de haber clonado prácticamente todo del original.

Veamos que podemos encontrar decompilando un poco con Ghidra.

Bueno observando un poco las entrañas del PineAP vemos varias cosas, la primera es que como todo archivo C tiene su main con las rutinas de inicio, y ahi encontramos los chequeos del board. Todos los chequeos se ven en texto plano y podemos ver revisando los mismos que son simples comandos ejecutados concatenados con pipes.

Los chequeos están en las funciones getbrd() y gtmgc() que al ser el retorno de un exec son fácilmente alterables editando hexadecimalmente el archivo. En mi prueba opte por hacer que lea con cat archivos que emulan el hard original, pero se pueden hacer otras cosas con la misma idea para obtener el mismo resultado.

Haciendo estos cambios sobre el PineAP y PineAPd nos termina quedando un fw completamente funcional y prácticamente idéntico al original.


6. Fuentes y notas

Notas sobre el proceso para hacer un build basado en el fw 1.x (2016): https://www.securityaddicted.com/2016/11/17/weaponizing-gl-inet-gl-ar150/

No tenia imagenes de mi decompilacion del Analisis, asi que use las de este posteo al respecto: http://gerryk.com/posts/using_ghidra_to_reverse_wifi_pineapple_protection/

Comentarios sobre la overlay partition: https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

Para descargar el firmware creado con este proceso: https://github.com/xchwarze/AR150-WiFiPineapple-2019

El metodo para la 2.6.0 es el mismo, solo que hay que partir del repo oficial de OpenWRT. La overlay partition queda bastante chica luego de armar el fw (menos de 1 mega).