onekey-sec/firmware-workshopIn dieser Workshop-Sitzung extrahieren wir die Firmware aus einem EV-Ladegerät, tauchen tief in die Firmware ein und emulieren sie schließlich, damit wir in Echtzeit mit den Diensten interagieren können.
Machen Sie mit bei dieser praktischen Demo von Unblob, dem flexiblen Firmware-Extraktor. In dieser Workshop-Sitzung extrahieren wir Firmware aus einem EV-Ladegerät, tauchen in die Firmware ein und emulieren sie schließlich, damit wir in Echtzeit mit den Diensten interagieren können. Unblob funktioniert sowohl mit Hardware- als auch mit herunterladbaren Versionen von Firmware, sodass wir eine zielreiche Umgebung haben. Keine Vorerfahrung erforderlich, diese Sitzung ist für alle Kenntnisstufen geeignet, und wir freuen uns, Sie dort zu sehen.
Unser Ziel ist ein Ladesteuerungs-Controller für Elektrofahrzeuge von Phoenix Contact. Weitere Details dazu finden Sie here.
CHARX control modular, AC-Ladesteuerung, mit Embedded-Linux-System, IEC 61851-1, Betriebsmodus: Stand-Alone, Client, Server,
Schnittstellen:
- Ethernet (2x)
- Mobilfunkkommunikation (4G/2G)
- CHARX-control-modular-Systembus
- MICRO-USB Typ C
Kommunikationsprotokolle:
- OCPP 1.6J
- Modbus/TCP
- MQTT
Anschließbare Peripheriegeräte:
- Energiezähler
- RFID
- DC-Fehlerstromerkennung
- Hutschienenmontage
Für diesen Workshop benötigen wir ein paar Werkzeuge. Sie können sie installieren,
indem Sie das Skript install-prerequisites wie folgt ausführen:```sh
./install-prerequisites
## Beschaffung der Firmware
Die Firmware kann von der Website des Anbieters bezogen werden. In diesem Repository gibt es ein Skript namens
`download-firmware`, mit dem du die Firmware herunterladen kannst, ohne einen Browser öffnen zu müssen.
Unser Fokus liegt heute auf der vom Anbieter bereitgestellten Firmware, da sie alles enthält, was wir brauchen.
Aber ein ähnlicher Arbeitsablauf kann auf ein Speicherabbild angewendet werden, das von einem Live-Gerät extrahiert wurde.
Das Interessante daran ist, dass wir extrahieren, untersuchen und emulieren können, ohne ein echtes Gerät zu benötigen.
## Extraktion mit Unblob
Zuerst stellen wir sicher, dass alle Abhängigkeiten verfügbar sind:```
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 ✓
Jetzt können wir die Firmware mit unblob extrahieren:``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb
Die Extraktion dauert auf einem ordentlichen Laptop etwa 3 Minuten. Sie sollten einen Fortschrittsbalken sehen, der sich nach oben bewegt:
Sobald die Extraktion abgeschlossen ist, sollte ein Verzeichnis mit dem Namen
`CHARXSEC3XXXSoftwareBundleV190.raucb_extract` sichtbar sein. Sie können
hineinwechseln und den Inhalt auflisten.
### Chunks, unbekannte Chunks
Unblob funktioniert, indem es Datenblöcke in Dateien identifiziert. Wenn ein Chunk ein
komprimierter Stream ist, wird er dekomprimiert. Wenn es sich um ein Dateisystem oder ein Archiv
handelt, wird er extrahiert. Wenn die Extraktion oder Dekompression erfolgreich war, wird der
Chunk, der auf die Festplatte geschnitten wurde, gelöscht, um Speicherplatz zurückzugewinnen.
Hier wurde ein SquashFS-Chunk Version 4 (Little Endian) auf die Festplatte geschnitten, extrahiert
und gelöscht. Dateien (und damit auch Extraktionsverzeichnisse) werden mit der
Nomenklatur `{start_offset}-{end_offset}.{type}` benannt.
Wir können sehen, dass nach dem squashfs-Dateisystem ein "unbekannter" Chunk von 11KB erscheint.```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown
Du kannst binwalk darauf ausführen, um zu sehen, was es enthält:```
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
Sie können die Zertifikate mit openssl überprüfen:```
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
Das bedeutet, dass Firmwares wahrscheinlich mit dem privaten Schlüssel des Herstellers signiert sind, damit Geräte sicherstellen können, dass Firmwares authentisch sind.
Das ist einer der Vorteile von unblob: unbekannte Unbekannte in bekannte Unbekannte zu verwandeln, die untersucht werden können.
Schauen wir uns den Inhalt unseres squashfs-Dateisystems an:``` 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
Wir können ein Klartext-Manifest, ein Shell-Skript, einen MBR und ein EXT4-Dateisystem sehen:```
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)
Sowohl bootimg.vfat als auch root.ext4 wurden von unblob verarbeitet und extrahiert. Die VFAT-Partition enthält alles, was mit Boot und Betriebssystem zu tun hat (Linux-Kernel, 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
Du wirst sehen, dass unblob ein wenig gierig ist und eine ELF-Datei sowie ein CPIO-Archiv aus dem Linux-Kernel (`zImage`) extrahiert – diese entsprechen dem minimalen Kernel und der Ramdisk.