No son poco frecuentes las noticias acerca de la aparición de
backdoors presentes en miles y miles de dispositivos. Su descubrimiento, muchas veces explotado por atacantes malintencionados, suele ser el resultado de un análisis exhaustivo del firmware correspondiente. Si nunca os habéis enfrentado a este tipo de ejercicio, en el blog de
15/85 Security daban una breve introducción para extraer el sistema de ficheros de un binario, una buena piedra de toque:
1.- Descarga de firmware de prueba, en este caso la versión 1.14.04 de la cámara D-Link modelo
DCS-932L:
$ wget ftp://ftp2.dlink.com/PRODUCTS/DCS-932L/REVA/DCS-932L_REVA_FIRMWARE_1.14.04.ZIP
$ unzip DCS-932L_REVA_FIRMWARE_1.14.04.ZIP
Archive: DCS-932L_REVA_FIRMWARE_1.14.04.ZIP
inflating: DCS-932L_REVA_RELEASENOTES_1.14.04_EN.PDF
inflating: dcs932l_v1.14.04.bin
2.- Para empezar echamos un vistazo a las strings con 10 o más caracteres imprimibles:
$ strings -10 dcs932l_v1.14.04.bin | more
NetInitTcp
NetTcpSend
NetReceive
send_syn_ack
send_reset
ArpTimeoutCheck
HttpHandler
mpfd_decode
do_httpsvr
rf - read/write rf register
rf r <reg> - read rf register
rf w <reg> <data> - write rf register (reg: decimal, data: hex)
Signature: DCS-930 932L Release 1.11 (2011-05-31)
*** failed ***
relocate_code Pointer at: %08lx
Please choose the operation:
%d: Load system code to SDRAM via TFTP.
%d: Load system code then write to Flash via TFTP.
%d: Boot system code via Flash (default).
%d: Entr boot command line interface.
%d: Load Boot Loader code then write to Flash via Serial.
%d: Load Boot Loader code then write to Flash via TFTP.
Please Input new ones /or Ctrl-C to discard
Input device IP
Input server IP
0x80200000
0x88001000
0x80100000
Input Uboot filename
Input Linux FileSystem filename
0x80800000
Input Linux Kernel filename
Entering HTTP server.
Entering program & boot linux.
Erase linux block (0x%x ~ 0x%x)
Erase linux block (0x%x ~ 0x%x
### ERROR ### Please RESET the board ###
Warning: Abort rw rf register: too busy
Warning: still busy
Error: rw register failed
rf reg <%d> = 0x%x
*** Error: D+/D- is 1/1, config usb failed.
config usb
Watchdog Reset Occurred
******************************
Software System Reset Occurred
Software CPU Reset Occurred
============================================
Ralink UBoot Version: %s
--------------------------------------------
(Port5<->None)
DRAM component: %d Mbits %s
DRAM bus: %d bit
...
...
3.- Ahora usamos binwalk, me atravería a decir la herramienta de facto cuando nos enfrentamos a análisis de firmware. Al ejecutarlo directamente nos devolverá varios "hits" del binario:
$ binwalk dcs932l_v1.14.04.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
106352 0x19F70 U-Boot version string, "U-Boot 1.1.3"
106816 0x1A140 CRC32 polynomial table, little endian
124544 0x1E680 HTML document header
124890 0x1E7DA HTML document footer
124900 0x1E7E4 HTML document header
125092 0x1E8A4 HTML document footer
125260 0x1E94C HTML document header
125953 0x1EC01 HTML document footer
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0x88345E96, created: 2016-09-09 13:52:27, image size: 3804958 bytes, Data Address: 0x80000000, Entry Point: 0x803B8000, data CRC: 0x531E94DE, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6558763 bytes
Mirando la primera línea, vemos que binwalk encontró un string U-Boot en 106352, ya sabéis, el cargador de arranque. Y por supuesto, en 327680, podemos ver un encabezado de uImage que nos indica que encontraremos la imagen del kernel del SO en un archivo LZMA que comienza en 327744.
