
In questa sessione del workshop, estrarremo il firmware da un caricatore per veicoli elettrici, analizzeremo il firmware e, infine, lo emuleremo per poter interagire con i servizi in tempo reale.
Unisciti a noi in questa demo pratica su Unblob, il flessibile estrattore di firmware. Durante questa sessione di workshop, estrarremo il firmware da un caricabatterie per veicoli elettrici, esploreremo il firmware e, infine, lo emuleremo per poter interagire con i servizi in tempo reale. Unblob funziona sia su versioni hardware che su versioni scaricabili di firmware, quindi abbiamo un ambiente ricco di obiettivi. Non è richiesta alcuna esperienza precedente: questa sessione è adatta a tutti i livelli di competenza e non vediamo l'ora di vederti lì.
Il nostro obiettivo è un controller di stazione di ricarica per veicoli elettrici di Phoenix Contact. Puoi trovare maggiori dettagli qui.
CHARX control modular, controller di ricarica AC, con sistema Linux embedded, IEC 61851-1, modalità operativa: Stand-Alone, Client, Server,
Interfacce:
- Ethernet (2x)
- Comunicazione cellulare (4G/2G)
- Bus di sistema CHARX control modular
- MICRO-USB tipo C
Protocolli di comunicazione:
- OCPP 1.6J
- Modbus/TCP
- MQTT
Dispositivi periferici collegabili:
- Contatore di energia
- RFID
- Rilevamento corrente residua DC
- Montaggio su guida DIN
Ci sono alcuni strumenti che ci servono in questo workshop. Puoi installarli
eseguendo lo script install-prerequisites in questo modo:```sh
./install-prerequisites
## Ottenimento del firmware
Il firmware può essere ottenuto dal sito web del vendor. In questo repository è presente uno script denominato
`download-firmware` che puoi usare per scaricare il firmware
senza dover aprire un browser.
La nostra attenzione oggi è sul firmware fornito dal vendor, poiché contiene tutto
ciò di cui abbiamo bisogno. Ma un flusso di lavoro simile può essere applicato a un dump di memoria estratto da
un dispositivo reale. La cosa interessante è che possiamo estrarre, esplorare ed
emulare senza nemmeno aver bisogno di un dispositivo reale.
## Estrazione con Unblob
Iniziamo assicurandoci che tutte le dipendenze siano disponibili:```
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 ✓
Ora possiamo estrarre il firmware con unblob:``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb
L'estrazione richiede circa 3 minuti su un laptop decente. Dovresti vedere una barra di avanzamento che avanza:

Una volta completata l'estrazione, dovrebbe essere visibile una directory denominata
`CHARXSEC3XXXSoftwareBundleV190.raucb_extract`. Puoi entrarci
ed elencarne il contenuto.
### Chunk, Chunk Sconosciuti
Unblob funziona identificando chunk di dati all'interno dei file. Se un chunk è un
flusso compresso, viene decompresso. Se è un filesystem o un archivio, viene
estratto. Se l'estrazione o la decompressione ha successo, il chunk
che è stato scritto su disco viene eliminato per recuperare spazio.
Qui, un chunk SquashFS versione 4 little-endian è stato scritto su disco, estratto
ed eliminato. I file (e quindi le directory di estrazione) sono nominati con
la nomenclatura `{start_offset}-{end_offset}.{type}`.
Possiamo vedere che 11KB di chunk "unknown" compaiono dopo il filesystem squashfs.```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown
Puoi eseguire binwalk su di esso per vedere cosa contiene:```
binwalk 132173824-132184833.unknown
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
Puoi controllare i certificati 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
Questo significa che i firmware sono probabilmente firmati con la chiave privata del vendor, così i dispositivi possono assicurarsi che i firmware siano autentici.
Questo è uno dei vantaggi di unblob: trasformare le incognite sconosciute in incognite note che possono essere investigate.
Diamo un'occhiata al contenuto del nostro filesystem 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
Possiamo vedere un manifest in chiaro, uno script shell, un MBR e un filesystem 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)
Sia bootimg.vfat che root.ext4 sono stati gestiti ed estratti da unblob. La
partizione VFAT contiene tutto ciò che riguarda boot e sistema operativo (kernel 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
Vedrai che unblob è un po' avido ed estrarrà un file ELF e un archivio CPIO
dal kernel Linux (`zImage`), questi corrispondono al kernel minimale
e al ramdisk.