binwalkで解析できない場合などの、firmwareイメージを自力で解析する方法のメモです。Mac OS X El Capitanで実行しています。

stringsコマンド

バイナリに含まれる文字列を確認します。文字列のオフセットを確認することもできます。-8などを指定して長めの文字列を確認するとよいです。文字列が出てこない場合は圧縮などのエンコードされている可能性が高いです。

$ strings -t x original.bin | grep config.har
330000 config.har

オプションはmanページを確認してください。

hexdumpコマンド

バイナリを確認します。

$ hexdump original.bin
0000000 10 00 01 03 24 1a 00 00 10 00 02 9c 24 1a 00 01
0000010 10 00 02 d1 24 1a 00 02 10 00 02 cf 24 1a 00 03
0000020 10 00 02 cd 24 1a 00 04 10 00 02 cb 24 1a 00 05
0000030 10 00 02 c9 24 1a 00 06 10 00 02 c7 24 1a 00 07

grepしてgzipのヘッダーの"1f 8b 08"などを探します(binwalkでもやってくれますが)。またブロックの終端は0xffなどで埋まっていて、塊の見当がつけられます。

データの固まりの確認はこんな感じでできます。

$ hexdump original.bin | grep -1 '^*'

FreeBSDではhexdumpに-Cオプションをつけるとバイトでの表示になりこれはhdというコマンドと同等になります。この表示はなぜかオフセットが1桁多く表示されます。

% hd Softbank_E-WMTA22.zimage | head
00000000  27 05 19 56 19 7e 4d bc  5d bf 60 d6 00 15 84 de  |'..V.~M.].`.....|
00000010  80 05 01 80 80 05 01 80  20 91 70 29 05 02 02 01  |........ .p)....|
00000020  46 72 65 65 42 53 44 20  4b 65 72 6e 65 6c 20 49  |FreeBSD Kernel I|
00000030  6d 61 67 65 00 00 00 00  00 00 00 00 00 00 00 00  |mage............|
00000040  1f 8b 08 08 d6 60 bf 5d  02 03 53 6f 66 74 62 61  |.....`.]..Softba|
00000050  6e 6b 5f 45 2d 57 4d 54  41 32 32 5f 6b 65 72 6e  |nk_E-WMTA22_kern|
00000060  65 6c 2e 6b 62 69 6e 00  dc bd 0b 98 5c 55 99 2e  |el.kbin.....\U..|
00000070  bc 76 5d 77 77 2a c9 ee  a4 03 6d d3 c2 4e 68 34  |.v]ww*....m..Nh4|
00000080  66 5a 53 b9 a0 31 87 81  0a 20 32 80 52 b9 71 9b  |fZS..1... 2.R.q.|
00000090  88 85 97 19 e7 8c 33 16  0c 9e 71 1c 1d ab fa 9e  |......3...q.....|

ddコマンド

バイナリの一部分を抜き出すことができます。

$ dd if=original.bin of=tp.gz bs=1 skip=262660 count=48702
48702+0 records in
48702+0 records out
48702 bytes transferred in 0.225961 secs (215533 bytes/sec)
$ file tp.gz
tp.gz: gzip compressed data, was "welkin-tp.b", from Unix, last modified: Fri Apr  9 01:01:29 2010, max compression

バラしたものを連結するときはcatコマンドで。

xxdコマンド

bootのコーンソールなどでアスキーダンプしたバイナリを元に戻せます。

$ head -1 hexdump.asc 
bfc40000:46 69 72 6d 77 61 72 65-00 ff ff ff ff ff ff ff Firmware........
$ sed 's/^.\{9\}//;s/.\{17\}$//' hexdump.asc | xxd -r -p > hexdump.bin

これらのコマンドとbootのコンソールを駆使して某ルータのflashイメージを解析したところこんな感じになってました。

ここまで解析するのはbinwalkだけでは無理なんで、職人の感と技でやるしかありません。

bootは64Kの2ブロックでhexdumpで見ると二つの部分に分かれているのがわかる。最初の部分は通常のインストラクションで、後半は圧縮された実行形式と思われるがgzipではなさそう。最初の部分を実行して後半をRAMに展開して実行を移していると思われる。

展開しているアドレスはカーネルのロードアドレスが0x80040000となっているので、それより前のアドレスになるようだ。

bootが管理するFirmwareなどのファイルの64K毎のセクタのヘッダー構造。tftpでpushするとできるので、直接操作することはないかもしれません。

タイプ	バイト数	備考
ファイル名	16	NULLターミネートの文字列
ブロック番号	4
ファイルサイズ	4
?	4
?	36

Versionブロックはただの文字列。welkin-tp.bはテストプログラムで起動時やbootのコンソールでtpコマンドを実行すると読み込まれて処理を行うものと思われる。実際のfirmwareのnetbsdの部分だと想像される。

welkin-tp.bはgzip形式だがnetbsdは不明の形式。

Firmwareの中のブロックのヘッダー構造は調べた方がいてこんな感じのよう

タイプ	バイト数	備考
フラグ	4	おそらく31ビットがgzipフラグ 17ビット目が実行可能フラグ 16ビットがENDフラグ
データ長	4
データ開始位置	4	0x18固定
チェックサム	2	データー長以降の16ビット単位のIPヘッダーと同様のチェックサム。と思ったのですがカーネルの部分だけ上位バイトが微妙にあいません。いくつかのファームウエアを調べていたところ、差がデータサイズに比例していることがわかりました。カーネル以外はサイズが小さいので、ちゃんと一致するというのもうなずけます。試しにデータ長を250000くらいで割った数字を足しこんでみたところうまくいくことがありました。
ダミー	2
ロードアドレス	4	実行可能な場合のロードアドレス
エントリーポイント	4	実行可能な場合のエントリーポイント

チェックサムの範囲は、短いデータのブロックで確認して見当をつけるのが良いです。

このターゲットのチェックサムは謎なので上記のロジックで適当にいじるとあたりがでます。

チェックサムがNGな場合

boot> load Firmware
Firmware system: load fail

チェックサムがOKな場合

boot> load Firmware
begin  : 0x80040100
length : 1807018
startup: 0x80040100

このターゲットにはrootfs部分が無いが、kernel内にufsとして入っているようだ。現在のCPUやメモリのスペックを考えると、あまり良い方法ではないきがする。

rubyなどで、構造をチェックするスクリプトを書くことも有効です。（例：EZ-USB FX2のfirmware抜き取りスクリプト)

objdumpでのアセンブラの解析も可能ですが、手間がかかるので本当に最後の手です。逆アセンブラの解析は現実的ではないのでAIを使った逆コンパイラがあると良いのですが。

$ objdump -b binary -m mips -D hoge.bin

エンディアンがどちらか分からない時はELとEBオプションを付けて、それっぽい命令が並ぶか確認します。

解析にはQUEM上でバイナリを実行する方法もあるかもしれません。

バイナリを編集したいときはMacだとHex FiendというアプリがApp Storeにあって定番のようです。