本記事では、ファームウェア解析ツールunblobについて、基本的な特徴と使用方法、既存の代表的なツールであるbinwalkとの違いについて紹介します。
注意事項
本ブログは、筆者による独自の調査に基づいて執筆していますが、記載内容がすべて正確・最新であることを保証するものではありません。また、本ブログの内容を使用したことによって発生する不利益等について、筆者および関係者はいかなる責任も負いません。
本記事で紹介する解析手法は、対象ソフトウェア・ファームウェア等の権利者から適切な許諾を得ている場合、または法令・契約上認められる範囲でのみ実施してください。権利者の権利を侵害する目的での利用は行わないでください。
1. はじめに
IoT機器やネットワーク機器、産業用制御システムなど、組み込みLinuxを搭載した機器のセキュリティ検証を行う際、最初の関門となるのがファームウェアのアンパックです。ベンダーが配布するファームウェアイメージは多くの場合、ブートローダ、カーネル、複数のファイルシステム（squashfs、UBIFS、JFFS2など）が独自のヘッダやオフセットで連結されており、さらにそれらが圧縮・アーカイブされた状態でネストされていることも珍しくありません。
このアンパック作業を手作業や不完全なツールで行うと、以下のような問題が発生します。
- 一部のファイルシステムやアーカイブが検出されず、解析対象の重要な実行ファイルや設定ファイルを見逃す
- ネストされた圧縮データを手動で何段も展開する手間がかかる
- 解析対象ごとに異なるツール（unsquashfs、jefferson、ubireaderなど）を個別に使い分ける必要があり、再現性のある解析フローを組みにくい
このような課題を解決するために開発されたのが、本記事で紹介するunblob[1]です。
2. unblobとは何か
概要
unblobはPythonで実装されたファームウェア/バイナリ抽出ツールです。単一のファームウェアイメージを入力として与えると、内部に含まれるファイルシステム、圧縮データ、アーカイブなどを自動的に検出し、それらを再帰的に展開・抽出します。unblobの大きな特徴の一つが再帰的な抽出を行う点です。例えば、あるファームウェアイメージの中にgzip圧縮されたデータがあり、その中にsquashfsイメージが存在し、さらにそのsquashfs内にcpioアーカイブが含まれているような多段ネスト構造であっても、unblobは各層を自動的に検出・展開しながら、最終的にすべてのファイルを取り出すところまで一貫して処理します。
開発元と開発背景
unblobはファームウェアセキュリティを専門とする企業ONEKEY（旧IoT Inspector）[2]によって開発・公開されているオープンソースツールです。ONEKEYはファームウェアの自動セキュリティ診断プラットフォームを提供しており、その内部で使用していたアンパック技術をOSSとして切り出し、コミュニティに公開したのがunblobの成り立ちです。商用のファームウェア解析基盤を支えるコア技術がベースになっているため、実務のスケールで求められる正確性、安定性、拡張性を重視した設計[1]になっている点が特徴です。
対応フォーマットの広さ
unblobは非常に多くのファイルフォーマットに対応しています。代表的なものは以下の通りです。
- ファイルシステム：SquashFS、UBIFS、EROFS、CramFS、JFFS2、ext2/3/4、YAFFS など
- 圧縮フォーマット：gzip、bzip2、xz、lzma、lz4、zstandard、lzo など
- アーカイブ：tar、cpio、zip、7z、arj、rar など
このように、組み込みLinux機器の解析で遭遇しやすいフォーマットを広くカバーしています（2026年9月15日時点）。対応フォーマットの一覧は公式リポジトリのドキュメントで随時更新されているため、最新の対応状況はGitHubリポジトリ[3]を参照することを推奨します。
抽出結果のレポート機能
unblobは単にファイルを展開するだけでなく、抽出処理の内容を構造化されたレポートとして出力する機能を持っています。抽出結果は、検出されたチャンクごとにディレクトリツリーとして整理されて出力されます。どの部分がどのフォーマットとして認識され、どこに展開されたかが一目で分かる構造になっています。
--reportオプションを用いることで、抽出処理の詳細（検出されたチャンク、オフセット、抽出先パスなど）をJSON形式で出力できます。このJSONレポートは、後続の自動解析パイプライン（SCA/SASTツールとの連携や、CI/CDでのファームウェア検査など）に組み込みやすい設計になっています。詳細については5章で説明します。
3. binwalkとの違い、使い分け
ファームウェア解析においてアンパック処理をする際、まず候補に挙がるのが binwalk[4]でしょう。binwalkはファームウェア解析ツールのデファクトスタンダードとして長年使われてきた実績があります。最近では、binwalk v3としてRust言語により全面的に実装が書き直され、導入方法もbinwalk v2までと異なります。binwalk v3に興味のある読者はGitHubリポジトリ[4]をご確認ください。
この章では、unblob（v26）とbinwalk（v2）のアーキテクチャ上の違いや、実務での使い分けの指針について整理します。
アーキテクチャの違い
binwalkはバイナリシグネチャ（マジックバイト）ベースの検出を基本としています。入力ファイルをバイトストリームとしてスキャンし、既知のフォーマットのシグネチャにマッチする位置を発見し、そこから対応する抽出処理を実行します。これはLinuxの file コマンドが使うlibmagic[5]の仕組みに似ており、ファイル中のどこにどのようなデータが埋め込まれているかを高速に洗い出すのに向いた設計です。一方、unblobは再帰的かつ網羅的な抽出アプローチを採用しています。unblobもbinwalk同様にシグネチャベースの検出を利用していますが、それに加えて、検出したチャンクを実際に抽出し、抽出後のデータに対しても同じ検出・抽出処理を再帰的に繰り返す、という点が特徴的です。
精度と網羅性
この再帰処理の有無は実際の解析結果に大きな差を生みます。binwalkは単発のシグネチャスキャンが基本のため、ネストされた構造、例えば、gzip圧縮データの中にsquashfsがあり、その中にさらに別の圧縮ファイルが格納されているといった多段構造を完全に展開するには、ユーザーが抽出結果を確認しながら手動で繰り返しbinwalkを実行する必要があります。補足として、binwalkにも-Mオプション（matryoshkaモード）による再帰的展開の仕組みはありますが、対応フォーマットの広さや再帰の深さの点から、unblobの方が解析に成功する事例があります（6章を参照）。unblobはこの「発見→抽出→再スキャン」のループを標準の動作として組み込んでおり、加えて対応フォーマットの種類も非常に広範です。
そのため、複雑にネストされた組み込みLinuxファームウェアであっても、人間が介入せずに最後まで自動的に展開できる可能性が高くなります。これはCI/CDパイプラインやセキュリティ診断の自動化基盤に組み込むうえで大きなアドバンテージです。
外部依存と使い分け
unblob自体はPythonで書かれたある種のオーケストレータのようなものであり、実際の各ファイルフォーマットの展開処理は多数の外部ツールに依存します。外部ツールの多くはPythonパッケージとして pip経由でインストールできますが、一部はソースからビルドが必要なバイナリや、Linuxディストリビューションのバージョンによってパッケージの入手方法が異なるなど、環境構築がやや重いという側面があります。
対してbinwalkは、binwalk v2についてはaptによる簡潔なインストールが可能であり、手軽に導入できるのが特徴です。
したがって、まずは環境への導入が容易なbinwalkを利用してアンパックを試みたうえで、抽出結果が不十分な場合などにはunblobを導入し利用する、という手順が良いと思います。
注意：
binwalk v2においても、高精度な抽出・展開を実施する場合には外部ツールを導入する必要がある場合があります。
4. unblobの導入
ここでは実際に unblob を導入する手順を示します。テストした環境は Ubuntu 24.04、python 3.12.3 です。前述の通り、unblobは多くの外部ツールを必要とします。
まずは python venv 環境を作成し、その中で unblob を導入します。
$ source venv_unblob/bin/activate
unblob自体は pip によるインストールが可能です。
$ unblob --version
26.6.4
この時点では、unblobが必要とする多くの外部ツールが未導入となっています。必要な外部ツールと導入状況を下記のように確認できます。
The following executables found installed, which are needed by unblob:
7z ✗
debugfs ✓
fsck.erofs ✗
jefferson ✓
lz4 ✗
lziprecover ✗
lzop ✗
partclone.restore ✗
sasquatch ✗
sasquatch-v4be ✗
simg2img ✗
ubireader_extract_files ✓
ubireader_extract_images ✓
unar ✗
zstd ✓
実際に外部ツールを導入していきましょう。必要なパッケージはGitHubリポジトリに記載の手順を確認することを推奨します。また、環境により追加パッケージが必要になる場合があります。
sasquatchパッケージは下記のようにして導入する必要があります。
$ sudo dpkg -i sasquatch_1.0.deb && rm sasquatch_1.0.deb
さて、これで外部ツールをすべて導入できました。
The following executables found installed, which are needed by unblob:
7z ✓
debugfs ✓
fsck.erofs ✓
jefferson ✓
lz4 ✓
lziprecover ✓
lzop ✓
partclone.restore ✓
sasquatch ✓
sasquatch-v4be ✓
simg2img ✓
ubireader_extract_files ✓
ubireader_extract_images ✓
unar ✓
zstd ✓
5. unblobの使い方
基本的な使い方
最も基本的な使用方法としては、対象のファームウェアを引数にするだけです。
※表示上の体裁は一部調整しています。
Output path: /home/user01/firmware_analysis/target.bin_extract
Extracted files: 660
Extracted directories: 266
Extracted links: 1012
Extraction directory size: 315.35 MB
Chunks distribution
Chunk type Size Ratio
──────────────────────────────────────────
ELF64 │ 117.99 MB │ 38.43% │
SQUASHFS_V4_LE │ 61.68 MB │ 20.09% │
TAR │ 48.24 MB │ 15.71% │
XZ │ 46.90 MB │ 15.28% │
UNKNOWN │ 20.65 MB │ 6.73% │
GZIP │ 9.34 MB │ 3.04% │
CPIO_PORTABLE_ASCII │ 1.97 MB │ 0.64% │
LZMA │ 236.42 KB │ 0.08% │
ELF32 │ 4.82 KB │ 0.00% │
レポート出力
前述の通り、unblobはネストされたアーカイブや圧縮ファイルを再帰的に解析していきます。unblobには--reportオプションがあり、抽出処理の詳細な記録をJSON形式で出力できます。どのファイルが、どこから、どういう経緯で取り出されたかを追跡したいときに役立つ機能になっています。
report.jsonはトップレベルが配列になっており、各要素が1つのtaskを表しています。unblobは、
- ファイルを解析
- 見つかった構造を抽出
- 抽出結果を新たな入力として再度解析
という処理を繰り返すため、この再帰の各ステップがひとつのtaskとして記録されています。
"task": {
"path": "...",
"depth": m
},
"reports": [ ... ]
}
report.jsonに含まれるいくつかの重要な要素について簡単に紹介します。
-
task.path：taskが処理しているファイルの実際のパス
-
task.depth：再帰の深さ。元の入力ファイルがdepth 0で、抽出1回ごとに1増える
-
reports配列：taskに対する解析結果のリスト
-
ChunkReport：主なフィールドは以下の通り
- handler_name：認識されたフォーマット（squashfs_v4_le、xz、tarなど）
- start_offset/end_offset/size：チャンクの範囲。task.pathが指すファイル自身の中での相対位置。
- is_encrypted：暗号化されたコンテナかどうかの判定
- extraction_reports：チャンクに対する抽出処理結果（成功/失敗、警告など）
上記の構成を踏まえて、report.jsonの読み方の指針の一例を挙げます。
- depthでグルーピングし、階層構造を大まかに把握します。
- 各depthのhandler_nameを並べることで、xz → tar → squashfs → ELFのような変換のチェーンが見えてきます。
- sizeが0や極端に小さい/大きいエントリ、extraction_reportsにエラーが記録されているエントリは、抽出が意図通りに進まなかった可能性があります。個別に抽出してさらなる分析などをしてみるのもよいでしょう。
また、jqコマンドを利用すると、report.jsonから必要な情報を容易に抽出できます。
例：全チャンクのhandler_nameとoffset/sizeを一覧表示
unblobには他にも出力関係や解析階層の深さ指定など細かなオプションがありますので、興味のある読者はぜひ確認してみてください（参考：[3]、[6]）。
6. unblobが効果的だった事例
筆者は実務の中で、binwalkが抽出できなかった実行ファイル（ELFファイル）を、unblobで正しく抽出できた事例を確認しましたので、参考例として簡単に共有します。
※パスやファイル名は一部編集してあります。
以下は、unblobによる解析で判明した対象ファームウェアファイル（target.bin）の階層構造です。depth 0から順に記載していますが、実際の分析手順としては、最終的に抽出できたELFファイル（depth 4）からtaskを上位方向につなげていきました。squashfsがネスト構造になっていることがわかります。
今回判明した階層構造：
depth 1: tar
depth 2: squashfs_v4_le (外側のsquashfs)
depth 3: squashfs_v4_le (/var/lib/test/target3.sfs として格納されていた内側のsquashfs)
depth 4: ELF (対象ファイル)
前述の通り、binwalkにも再帰解析を行うオプション（matryoshkaモード）があり、再帰的な抽出が可能です。しかし筆者が "binwalk -eM -d 16 target.bin" コマンドによる抽出を試みたところ、どうやらdepth 3のtarget3.sfsファイルに対して再帰的な抽出が走らなかったようで、結果として、binwalkではdepth 4のELF実行ファイルを抽出することができませんでした。
※binwalk v2.3.3を利用しました。新しいバージョンでは問題が解決している可能性があります。
7. まとめ
今回はファームウェア解析ツールであるunblobについて、その特徴や基本的な使い方、そしてbinwalkとの違いについて簡単にご紹介しました。ファームウェア分析においてアンパック処理は必須の工程ですが、ここがうまくいかないと後の分析作業に多大な影響を与えるため、アンパックツールの存在は非常に重要です。その点でもunblobは実務に耐えうるだけの対象フォーマットの多さと抽出精度を有していると考えます。
このブログでの紹介が皆様のお役に立つことを祈っております。
参考文献
[1] unblob - extract everything!
https://unblob.org/
[2] Effortless Product Cybersecurity & Compliance | ONEKEY
https://www.onekey.com/
[3] GitHub - onekey-sec/unblob: Extract files from any kind of container formats · GitHub
https://github.com/onekey-sec/unblob
[4] GitHub - ReFirmLabs/binwalk: Firmware Analysis Tool · GitHub
https://github.com/ReFirmLabs/binwalk
[5] libmagic(3) - Linux manual page
https://www.man7.org/linux/man-pages/man3/libmagic.3.html
[6] unblob · PyPI
https://pypi.org/project/unblob/
執筆者プロフィール
S田（えすだ）※ハンドルネーム
担当領域：リスクハンティング
専門分野：バイナリ解析、ソフトウェアセキュリティ
ソフトウェアの不正機能検査技術の研究開発業務を経て、現在はペネトレーションテスト、脆弱性診断、ソフトウェア検査などに従事。