ハンズオン：ファームウェアの抽出・探索・エミュレーション

このハンズオンデモでは、柔軟なファームウェア抽出ツールであるUnblobを体験していただきます。このワークショップセッションでは、EV充電器からファームウェアを抽出し、ファームウェアを詳しく調べ、最終的にエミュレーションして、サービスとリアルタイムにやり取りできるようにします。Unblobはハードウェア版とダウンロード版の両方のファームウェアに対応しているため、ターゲットとなる環境は豊富です。事前経験は不要で、あらゆるスキルレベルに適したセッションです。皆様のご参加をお待ちしています。

対象ターゲット

私たちのターゲットは、Phoenix Contact製の電気自動車充電ステーションコントローラです。詳細はこちらをご覧ください。

CHARX control modular、AC充電コントローラ、組み込みLinuxシステム搭載、IEC 61851-1、動作モード: スタンドアロン、クライアント、サーバー

インターフェース:

イーサネット (2x)

セルラー通信 (4G/2G)

CHARX control modular システムバス

MICRO-USB type C

通信プロトコル:

OCPP 1.6J

Modbus/TCP

MQTT

接続可能な周辺機器:

エネルギー計

RFID

DC残留電流検出

DINレールマウント

前提条件

このワークショップで必要ないくつかのツールがあります。次のように install-prerequisites スクリプトを実行してインストールできます。```sh ./install-prerequisites

## ファームウェアの入手

ファームウェアはベンダーのウェブサイトから入手できます。このリポジトリには
`download-firmware` というスクリプトがあり、ブラウザを開くことなく
ファームウェアを取得するために使用します。

今回の焦点は、必要なものがすべて含まれているベンダー提供のファームウェアです。
ただし、同様のワークフローは、実機から抽出したメモリダンプにも適用できます。
ここで興味深いのは、実機を必要とせずに抽出、探索、エミュレーションができることです。

## Unblob による抽出

まず、すべての依存関係が利用可能であることを確認しましょう。```
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                        ✓

これでunblobを使ってファームウェアを抽出できます:``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb

標準的なノートPCでは、抽出に約3分かかります。プログレスバーが進んでいくのが確認できるはずです：

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


抽出が完了すると、ディレクトリが表示されるはずです。その名前は
`CHARXSEC3XXXSoftwareBundleV190.raucb_extract` です。移動して
その中に入って、コンテンツを一覧表示できます。

### チャンク、未知のチャンク

Unblobは、ファイル内のデータのチャンクを特定することで動作します。チャンクが
圧縮ストリームであれば解凍されます。ファイルシステムまたはアーカイブであれば、
抽出されます。抽出または解凍が成功した場合、ディスクに切り出されたチャンクは、
スペースを回復するために削除されます。

ここでは、SquashFSバージョン4のリトルエンディアンのチャンクがディスクに切り出され、抽出され、
削除されました。ファイル（したがって抽出ディレクトリも）は、
`{start_offset}-{end_offset}.{type}` という命名規則で名前が付けられます。

squashfsファイルシステムの後に、11KB分の "unknown" チャンクが存在することがわかります。```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown

それに対して binwalk を実行すると、中に何が含まれているか確認できます:``` 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

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

つまり、ファームウェアはおそらくベンダーの秘密鍵で署名されており、デバイスはファームウェアが本物であることを確認できるというわけです。

これがunblobの利点のひとつです。未知の未知を、調査可能な既知の未知に変えてくれます。

ファイルシステム

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

プレーンテキストのマニフェスト、シェルスクリプト、1つのMBR、そして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 と root.ext4 はどちらも unblob によって処理され、抽出されました。 VFAT パーティションには、ブートと OS に関連するすべてのもの（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

unblob は少し貪欲で、Linux カーネル（`zImage`）から
ELF ファイルと CPIO アーカイブを抽出します。これらは
最小限のカーネルと RAM ディスクに対応します。

EXT4 ファイルシステムには、Linux カーネルが起動時に
マウントするルートファイルシステムが含まれています。```
ls -alh root.ext4_extract 
total 88K
drwxrwxr-x 22 kali kali 4,0K sep  8 09:57 .
drwxrwxr-x  4 kali kali 4,0K dec  5 09:51 ..
drwxrwxr-x  2 kali kali 4,0K dec  5 09:51 bin
drwxrwxr-x  3 kali kali 4,0K dec  5 09:51 boot
drwxrwxr-x 16 kali kali 4,0K sep  8 09:56 data
drwxrwxr-x  2 kali kali 4,0K jul 18 00:09 dev
drwxrwxr-x 53 kali kali 4,0K dec  5 09:51 etc
drwxrwxr-x 18 kali kali 4,0K sep  8 09:56 home
drwxrwxr-x  2 kali kali 4,0K jul 18 03:13 identity
drwxrwxr-x  9 kali kali 4,0K dec  5 09:51 lib
drwxrwxr-x  2 kali kali 4,0K jul 18 03:14 log
drwxrwxr-x  2 kali kali 4,0K sep  8 09:57 lost+found
drwxrwxr-x  2 kali kali 4,0K jul 18 00:09 media
drwxrwxr-x  2 kali kali 4,0K jul 18 00:09 mnt
drwxrwxr-x  2 kali kali 4,0K jul 18 00:09 proc
drwxrwxr-x  2 kali kali 4,0K sep  8 09:57 run
drwxrwxr-x  2 kali kali 4,0K dec  5 09:51 sbin
drwxrwxr-x  2 kali kali 4,0K jul 18 03:14 sdcard
drwxrwxr-x  2 kali kali 4,0K jul 18 00:09 sys
drwxrwxrwx  2 kali kali 4,0K jul 18 00:09 tmp
drwxrwxr-x 11 kali kali 4,0K sep  8 09:56 usr
drwxrwxr-x 11 kali kali 4,0K dec  5 09:51 var

探索

ファームウェアの可視化

unblob の別のオプションセットを使って、少し探索してみましょう。``` unblob -e /tmp/out -f -k -d 3 --report /tmp/report.json
--log /tmp/unblob.log CHARXSEC3XXXSoftwareBundleV190.raucb

ここでは (`-e`) で `/tmp/out` への抽出を続けますが、(`-f`) で上書きを強制し、
(`-k`) で切り出したチャンクを保持しつつ、(`-d`) で再帰の深さを
3 に制限しています。詳細レポート (`--report`) は `/tmp/report.json` に、ログファイル
(`--log`) は `/tmp/unblob.log` に書き出します。

ログファイルを見ると、unblob の内部動作がわかります。

レポートファイルには、分析されたファイル (サイズ、ファイル
タイプ、パス、マジック、MIMEタイプ、MD5/SHA1/SHA256 ハッシュ)、チャンク (サイズ、オフセット、
エントロピー分布)、およびタスク (抽出、展開、カービング) に関する詳細情報が含まれています。
少しの Python を使えば、これらのレポートファイルから素敵な可視化を
生成することができます。

このリポジトリにある `diagram.py` Python スクリプトを使用すると、それらを
自分で作成できます:```
python3 diagram.py /tmp/report.json sunburst
python3 diagram.py /tmp/report.json treemap

これらのコマンドを実行すると、ブラウザで以下のような plotly ベースの可視化を含むページが開きます。

sunburst

treemap

情報収集

内部の概要が把握できたところで、デバイスを適切にエミュレーションするために必要な情報を列挙していきましょう。

理想的には、以下の情報を収集する必要があります。

firmware-workshop

人気