Extracción, exploración y emulación práctica de firmware

Únete a nosotros en esta demostración práctica de Unblob, el extractor de firmware flexible. Durante esta sesión del taller, extraeremos firmware de un cargador de vehículos eléctricos, indagaremos en el firmware y, finalmente, lo emularemos para poder interactuar con los servicios en tiempo real. Unblob funciona tanto con versiones de hardware como descargables de firmware, por lo que tenemos un entorno rico en objetivos. No se necesita experiencia previa, esta sesión es adecuada para todos los niveles y esperamos verte allí.

Nuestro objetivo

Nuestro objetivo es un controlador de estación de carga para vehículos eléctricos de Phoenix Contact. Puedes encontrar más detalles al respecto aquí.

CHARX control modular, controlador de carga de CA, con sistema Linux embebido, IEC 61851-1, modo de funcionamiento: independiente, cliente, servidor,

Interfaces:

• Ethernet (2x)
• Comunicación celular (4G/2G)
• Bus de sistema modular CHARX control
• MICRO-USB tipo C

Protocolos de comunicación:

• OCPP 1.6J
• Modbus/TCP
• MQTT

Dispositivos periféricos conectables:

• Medidor de energía
• RFID
• Detección de corriente residual de CC
• Montaje en carril DIN

Requisitos previos

Hay algunas herramientas que necesitamos en este taller. Puedes instalarlas ejecutando el script install-prerequisites de la siguiente manera:```sh ./install-prerequisites

## Obtención del firmware

El firmware se puede obtener desde el sitio web del proveedor. Hay un script llamado
`download-firmware` en este repositorio que puedes usar para descargar el firmware
sin necesidad de abrir un navegador.

Nuestro enfoque de hoy está en el firmware proporcionado por el proveedor, ya que contiene todo
lo que necesitamos. Pero se puede aplicar un flujo de trabajo similar a un volcado de memoria extraído de
un dispositivo real. Lo interesante aquí es que podemos extraer, explorar y
emular sin siquiera necesitar un dispositivo real.

## Extracción con Unblob

Comencemos asegurándonos de que todas las dependencias estén disponibles:```
unblob --show-external-dependencies
The following executables found installed, which are needed by unblob:
    7z                          ✓
    debugfs                     ✓
    jefferson                   ✓
    lz4                         ✓
    lziprecover                 ✓
    lzop                        ✓
    sasquatch                   ✓
    sasquatch-v4be              ✓
    simg2img                    ✓
    ubireader_extract_files     ✓
    ubireader_extract_images    ✓
    unar                        ✓
    zstd                        ✓

Ahora podemos extraer el firmware con unblob:``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb

La extracción tarda unos 3 minutos en un portátil decente. Deberías ver una barra de progreso avanzando:

![unblob_progress](https://assets.kitploit.com/production/public/readmes/48963/9bdd3fefdf4e600ee070a461172a3ef07e482cde75b8e8a5d881021c7fa341e6.png)

Una vez que la extracción ha terminado, debería ser visible un directorio llamado
`CHARXSEC3XXXSoftwareBundleV190.raucb_extract`. Puedes entrar
en él y listar su contenido.

### Fragmentos, Fragmentos Desconocidos

Unblob funciona identificando fragmentos de datos dentro de los archivos. Si un fragmento es un
flujo comprimido, se descomprime. Si es un sistema de archivos o un archivo,
se extrae. Si la extracción o descompresión fue exitosa, el fragmento
que fue extraído al disco se elimina para recuperar espacio.

Aquí, un fragmento SquashFS version 4 little-endian fue extraído al disco,
extraído y eliminado. Los archivos (y por lo tanto los directorios de extracción) se nombran con
la nomenclatura `{start_offset}-{end_offset}.{type}`.

Podemos ver que aparecen 11KB de fragmento "desconocido" después del sistema de archivos squashfs.```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown

Puedes ejecutar binwalk sobre él para ver qué contiene:``` binwalk 132173824-132184833.unknown

DECIMAL HEXADECIMAL DESCRIPTION

0 0x0 Object signature in DER format (PKCS header length: 4, sequence length: 10997 58 0x3A Certificate in DER format (x509 v3), header length: 4, sequence length: 4372 4434 0x1152 Certificate in DER format (x509 v3), header length: 4, sequence length: 4387

Puedes comprobar los certificados con openssl:```
dd if=132173824-132184833.unknown bs=1 skip=58 | openssl x509 -in /dev/stdin -inform der -noout -text
dd if=132173824-132184833.unknown bs=1 skip=4434 | openssl x509 -in /dev/stdin -inform der -noout -text

Esto significa que los firmware probablemente están firmados con la clave privada del proveedor para que los dispositivos puedan asegurarse de que los firmware sean auténticos.

Esa es una de las ventajas de unblob: convertir incógnitas desconocidas en incógnitas conocidas que pueden investigarse.

Sistemas de archivos

Veamos el contenido de nuestro sistema de archivos squashfs:``` ls -al 0-132173824.squashfs_v4_le_extract total 460532 drwxrwxr-x 4 kali kali 4096 dec 5 09:51 . drwxrwxr-x 3 kali kali 4096 dec 5 09:51 .. -rw-rw-r-- 1 kali kali 20971520 sep 8 09:59 bootimg.vfat drwxrwxr-x 3 kali kali 4096 dec 5 09:51 bootimg.vfat_extract -rwxrwxr-x 1 kali kali 2654 sep 19 2022 hook -rw-rw-r-- 1 kali kali 442 sep 8 09:59 manifest.raucm -rw-rw-r-- 1 kali kali 450584576 sep 8 09:59 root.ext4 drwxrwxr-x 22 kali kali 4096 sep 8 09:57 root.ext4_extract

Podemos ver un manifiesto en texto plano, un script de shell, un MBR y un sistema de archivos EXT4:```
find -maxdepth 1 -type f -exec file {} \;
./manifest.raucm: ASCII text
./hook: a /usr/bin/env sh script, ASCII text executable
./bootimg.vfat: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors 4, root entries 512, sectors 40960 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 40, sectors/track 63, heads 255, hidden sectors 163158016, reserved 0x1, serial number 0xd09aad9c, label: "KERNEL     ", FAT (16 bit)
./root.ext4: Linux rev 1.0 ext4 filesystem data, UUID=8ed19606-02c4-42e7-9cfb-1a2839f93ec4 (extents) (large files) (huge files)

Tanto bootimg.vfat como root.ext4 fueron procesados y extraídos por unblob. La partición VFAT contiene todo lo relacionado con el arranque y el sistema operativo (kernel de Linux, DTB, TEE):``` oftree: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756 tee.bin: data zImage: Linux kernel ARM boot executable zImage (little-endian) zImage-imx6ul-ksp0632.dtb: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756

Verás que unblob es un poco codicioso y extraerá un archivo ELF y un archivo CPIO
del kernel de Linux (`zImage`); estos corresponden al kernel mínimo y al
ramdisk.