unblob：未知のバイナリをチャンク検出して再帰的に展開する
あらゆる種類のコンテナ形式からファイルを抽出します。 unblob バイナリ BLOB の正確、高速、そして使いやすい抽出スイート。 unblob は、78 を超えるアーカイブ、圧縮、およびファイル システム形式**の未知のバイナリ BLOB を解析し、その内容を再帰的に抽出して、未知のチャンクを切り出します。
ひと目でわかる
- これは何？
- onekey-sec/unblobの対応形式、再帰抽出、JSONメタデータ、Python API、外部ツール依存をREADMEに沿って整理します。
- 誰に向いている？
- ファームウェアや不明な添付ファイルを構造化して調べたい分析者に向きます。信頼できない入力をホストへ直接展開したくない場合は、権限を絞った一時ディレクトリと容量制限を用意してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
バイナリ全体から埋め込み形式を探す
unblob は、リポジトリの説明が 'あらゆる種類のコンテナ形式' と呼ぶバイナリブロブからファイルを抽出する Python ツールです。入力ファイルをスキャンして既知のアーカイブ、圧縮、ファイルシステム形式を探し、内容を抽出した後、抽出されたデータに対して同じ処理を繰り返します。README は、ファームウェアイメージのための正確で高速かつ使いやすい抽出スイートと紹介し、特権昇格なしで実行できるため、一般ユーザーでも使えると述べています。
unblobは形式が分からないバイナリを調べ、既知のアーカイブ、圧縮、ファイルシステムなどのチャンクを検出して抽出するツールです。単一の拡張子を展開するユーティリティではなく、ファームウェアのような入れ子コンテナを対象にします。検出できない形式まで読めるとはREADMEは述べていません。
対応アーカイブとチャンクの境界
README は 78 以上の形式に対応しているとし、SquashFS、JFFS2、UBI/UBIFS、ext、CPIO、ZIP、7-Zip、gzip、XZ、LZMA、LZ4 などを挙げています。認識された各チャンクについて、unblob は形式標準に従って開始と終了のオフセットを特定し、これにより誤検出を減らすとしています。既知の形式に一致しないデータは切り出されて報告され、null と 0xFF のパディングは自動的に識別されます。未知のチャンクについては、シャノンエントロピーとカイ二乗確率を計算し、暗号化または圧縮されたデータの発見に役立てます。
READMEが挙げる対応形式の数は、検出器と抽出器の実装範囲を理解する手掛かりです。形式名が一覧にある場合でも、破損、暗号化、特殊な配置で同じ結果になるとは限りません。小さな既知サンプルを一つずつ渡し、出力されたチャンクのオフセット、サイズ、形式名を元ファイルと照合します。
入れ子をたどる再帰抽出
抽出は再帰的で、コンテナの中のコンテナは設定可能な深さまで処理され、デフォルトは 10 レベルです。デフォルトでは利用可能なすべての CPU コアを使用し、出力先は `-e` で別のディレクトリを指定しない限り、入力ファイル名に `_extract` を付けたディレクトリになります。CLI には、抽出の強制、再帰深度の設定、エントロピー分析深度の制限、マジックプレフィックスによるファイルのスキップ、ワーカープロセス数の制御などのオプションもあります。
再帰抽出では、最初のコンテナから取り出したファイルを次の入力として処理します。深い入れ子や大量ファイルでは、出力容量と処理時間が入力サイズを大きく上回ることがあります。READMEの並列処理オプションを使う場合も、作業ディレクトリの容量と同時実行数を先に制限してください。
JSONメタデータで結果を追跡する
unblob は `--report` オプションで、チャンクのオフセット、サイズ、エントロピー、ファイル所有者、パーミッション、タイムスタンプなどを含む JSON メタデータレポートを書き出せます。同じ機能はプログラムからも利用でき、README には `unblob.processing` の `ExtractionConfig` と `process_file` を使う短い例が示され、`ExtractionConfig` は `max_depth`、`process_num`、`skip_magic`、`force_extract`、`keep_extracted_chunks` など CLI と同じオプションを受け付けると説明されています。完全な API リファレンスは unblob.org/api にあります。
JSONメタデータは、何を検出し、どこへ抽出したかを機械的に追跡する入口です。解析結果を人間向けのディレクトリだけで判断せず、JSONのパス、オフセット、エラー情報を元イメージのハッシュと一緒に保存します。Python APIを組み込む場合は、CLIと例外処理の差をサンプルで比較します。
CLIとPython APIの使い分け
推奨されるインストール方法は `pip install unblob` で、その後、外部の抽出ツールをインストールします。Ubuntu/Debian では、README は `android-sdk-libsparse-utils`、`e2fsprogs`、`p7zip-full`、`unar`、`zlib1g-dev`、`liblzo2-dev`、`lzop`、`lziprecover`、`libhyperscan-dev`、`zstd`、`lz4` を挙げています。SquashFS のサポートには別途 `sasquatch` パッケージが必要です。Docker イメージにはすべての抽出器が含まれており、README は Kali の apt、Nix、そして `uv sync` と Rust ツールチェーンを使ったソースからのビルドも説明しています。ソースビルドには Python 3.10 以上が必要です。
CLIは単発のイメージ調査、Python APIは解析パイプラインへの組み込みに向きます。READMEに示されるインストール手順と外部依存ツールを同じ環境へ導入し、バージョンを固定します。PATHにない補助コマンドの失敗を、形式未対応の失敗と混同しないようにエラー出力を分けて記録します。
外部依存とテストの位置
テストスイートは pytest を使用し、統合テストのフィクスチャは Git LFS に保存されています。README は、インストール、ユーザーガイド、対応形式、API リファレンス、開発ガイドについて unblob.org を参照するよう案内しています。貢献は issue と pull request を通じて行われ、新しい形式のリクエストでは、16進ダンプ、仕様リンク、サンプルファイルが求められます。開発ガイドはドキュメントにリンクされ、リポジトリには貢献ガイドもあります。
テスト、ドキュメント、貢献の入口があることは、検出器を追加する際の手掛かりになります。対応形式の拡張は、名前を登録するだけでなく、チャンク境界、抽出後の再帰、壊れた入力の扱いを検証する作業です。READMEにない網羅率や解析精度は、プロジェクトの実績として扱いません。
解析対象を隔離して実行する
リポジトリは MIT ライセンスで提供され、著作権は ONEKEY GmbH（2022）にあります。このライセンスは、ソフトウェアのコピーを全部または実質的に含む場合に著作権表示と許可表示を含めることを条件に、使用、コピー、修正、統合、公開、配布、サブライセンス、販売を許可します。ソフトウェアは '現状のまま' 提供され、いかなる種類の保証もなく、責任を負いません。README は具体的な性能ベンチマーク、セキュリティ保証、サポートの約束を述べていないため、これらは評価者が確認すべき未解決の問いです。
ファームウェアや不明な添付ファイルを構造化して調べたい分析者に向きます。信頼できない入力をホストへ直接展開したくない場合は、権限を絞った一時ディレクトリと容量制限を用意してください。まず既知サンプルでJSONとディレクトリの対応を確認し、次に対象イメージのハッシュと出力を保存します。
編集部の結論
ファームウェアや不明な添付ファイルを構造化して調べたい分析者に向きます。信頼できない入力をホストへ直接展開したくない場合は、権限を絞った一時ディレクトリと容量制限を用意してください。まず既知サンプルでJSONとディレクトリの対応を確認し、次に対象イメージのハッシュと出力を保存します。 READMEにない性能、互換性、運用保証は文書未記載として判断を分けます。
コミュニティノート