Dans cette session d'atelier, nous extrairons le firmware d'une borne de recharge pour véhicule électrique, nous l'analyserons en profondeur, puis nous l'émulerons afin de pouvoir interagir avec les services en temps réel.
Rejoignez-nous pour cette démonstration pratique d'Unblob, l'extracteur de firmware flexible. Au cours de cet atelier, nous extrairons le firmware d'un chargeur de VE, nous l'explorerons en profondeur, puis nous l'émulerons afin d'interagir avec les services en temps réel. Unblob fonctionne à la fois sur les versions matérielles et téléchargeables du firmware, ce qui nous offre un environnement riche en cibles. Aucune expérience préalable n'est requise, cette session convient à tous les niveaux de compétence et nous nous réjouissons de vous y voir.
Notre cible est un contrôleur de borne de recharge pour véhicules électriques de Phoenix Contact. Vous pouvez en savoir plus à son sujet ici.
CHARX control modular, contrôleur de charge CA, avec système Linux embarqué, IEC 61851-1, mode de fonctionnement : autonome, client, serveur,
Interfaces :
- Ethernet (2x)
- Communication cellulaire (4G/2G)
- Bus système modulaire CHARX control
- MICRO-USB type C
Protocoles de communication :
- OCPP 1.6J
- Modbus/TCP
- MQTT
Périphériques connectables :
- Compteur d'énergie
- RFID
- Détection de courant résiduel DC
- Montage sur rail DIN
Quelques outils sont nécessaires pour cet atelier. Vous pouvez les installer en
exécutant le script install-prerequisites comme ceci :```sh
./install-prerequisites
## Obtention du firmware
Le firmware peut être obtenu depuis le site web du fournisseur. Un script nommé
`download-firmware` dans ce dépôt vous permet de récupérer le firmware
sans avoir besoin d'ouvrir un navigateur.
Notre attention se porte aujourd'hui sur le firmware fourni par le fournisseur, car il contient tout
ce dont nous avons besoin. Mais un flux de travail similaire peut être appliqué à un vidage mémoire extrait d'un
appareil réel. Ce qui est intéressant ici, c'est que nous pouvons extraire, explorer et
émuler sans même avoir besoin d'un appareil réel.
## Extraction avec Unblob
Commençons par vérifier que toutes les dépendances sont 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 ✓
Maintenant, nous pouvons extraire le firmware avec unblob :``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb
L'extraction prend environ 3 minutes sur un ordinateur portable correct. Vous devriez voir une barre de progression avancer :
Une fois l'extraction terminée, un répertoire nommé
`CHARXSEC3XXXSoftwareBundleV190.raucb_extract` devrait être visible. Vous pouvez vous y rendre
et lister son contenu.
### Chunks, chunks inconnus
Unblob fonctionne en identifiant des chunks de données dans les fichiers. Si un chunk est un
flux compressé, il est décompressé. S'il s'agit d'un système de fichiers ou d'une archive, il
est extrait. Si l'extraction ou la décompression a réussi, le chunk
qui a été extrait sur le disque est supprimé pour récupérer de l'espace.
Ici, un chunk SquashFS version 4 little-endian a été isolé sur le disque, extrait,
puis supprimé. Les fichiers (et donc les répertoires d'extraction) sont nommés selon la
nomenclature `{start_offset}-{end_offset}.{type}`.
On peut voir qu'un chunk "unknown" de 11 Ko apparaît après le système de fichiers squashfs.```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown
Vous pouvez exécuter binwalk dessus pour voir ce qu'il contient :```
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
Vous pouvez vérifier les certificats avec 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
Cela signifie que les firmwares sont probablement signés avec la clé privée du fournisseur, afin que les appareils puissent vérifier l'authenticité des firmwares.
C'est l'un des avantages d'unblob : transformer les inconnues inconnues en inconnues connues qui peuvent être investiguées.
Regardons le contenu de notre système de fichiers 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
Nous pouvons voir un manifeste en clair, un script shell, un MBR et un système de fichiers 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)
bootimg.vfat et root.ext4 ont tous deux été traités et extraits par unblob. La
partition VFAT contient tout ce qui est lié au boot et au système d’exploitation (noyau 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
Vous verrez qu'unblob est un peu gourmand et extraira un fichier ELF et une archive CPIO du noyau Linux (`zImage`), qui correspondent au noyau minimal et au ramdisk.