unblob：把固件拆开，看清里面到底是什么
从任何类型的容器格式中提取文件。 unblob 准确、快速且易于使用的二进制 blob 提取套件。 unblob 解析超过 78 种存档、压缩和文件系统格式的未知二进制 blob，递归提取其内容，并切出未知块。
秒懂
- 它是什么？
- unblob 是一个用 Python 写的二进制 blob 提取工具，支持 78 种以上格式，能递归解包固件并识别未知数据。它的价值在于准确识别块边界，而不是简单扫描魔数。
- 适合谁用？
- 如果你经常处理固件镜像，需要把多层嵌套的压缩包和文件系统完整拆开，unblob 是目前少有的能把边界算准的工具。它适合固件安全研究员、逆向工程师和 CI 流水线维护者。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
固件分析的第一步，卡在拆包上
拿到一个固件镜像，你面对的是几十 MB 的二进制数据。里面可能套着 gzip 压缩流，压缩流里是一个 SquashFS 文件系统，文件系统里又有一个 CPIO 归档。手动拆要一层层试，用 binwalk 扫描又经常误报，把正常数据当压缩流切出来。unblob 解决的就是这个具体问题：自动识别容器格式，递归提取到指定深度，把所有未知块单独切出来。它面向的是固件安全研究人员、逆向工程师，以及需要批量处理固件的自动化系统。这类用户不关心某个格式能不能解，关心的是解出来的内容是否完整、偏移是否准确。
先识别边界，再决定怎么提取
unblob 的核心机制是两步走。第一步是 chunk 识别，它对每个候选位置计算格式标准的起始和结束偏移，而不是只匹配文件头魔数。这意味着它能区分真正的 gzip 流和恰好以 1f 8b 开头的普通数据。第二步是提取，对识别出的 chunk 调用对应的提取器，然后递归处理提取出的内容，直到达到配置的深度上限。这种设计直接减少了误报，因为边界是根据格式规范推导的，不是猜的。README 里强调它计算 Shannon 熵和卡方概率，用于识别未知块中的加密或压缩数据。这部分是分析辅助，不是提取功能，但能帮你判断某个未知块是否值得深挖。
装起来不复杂，但依赖清单吓人
pip install unblob 只是第一步。真正的工作在装外部提取器：Ubuntu 上要装 android-sdk-libsparse-utils、e2fsprogs、p7zip-full、unar、zlib1g-dev、liblzo2-dev、lzop、lziprecover、libhyperscan-dev、zstd、lz4。SquashFS 还需要单独装 sasquatch 的 .deb 包。这不是 unblob 的问题，是固件格式本身依赖多种系统工具。它提供了一个验证命令 unblob --show-external-dependencies，能列出缺失项。如果你不想折腾系统依赖，Docker 镜像 ghcr.io/onekey-sec/unblob:latest 预置了所有提取器，直接挂载目录就能跑。注意 README 里的要求：挂载目录的 uid:gid 必须一致，多用户系统要加 -u $UID:$GID。从源码编译则需要 Python 3.10 以上、uv 和 Rust 工具链，因为包含编译扩展。
命令行和 Python API，两种用法各有侧重
命令行最常用的是 unblob firmware.bin，输出到同名 _extract 目录。加 -e 指定输出目录，--report 生成 JSON 报告，-d 控制递归深度，-n 控制熵计算深度。--skip-magic 跳过匹配特定前缀的文件，比如跳过所有 POSIX tar 归档。这在你只关心非 tar 内容时很省时间。Python API 提供 ExtractionConfig 和 process_file，参数与 CLI 一一对应，适合嵌入到自己的分析脚本里。需要注意，API 返回的是 result 对象，具体字段 README 没列出，需要查官方 API 文档。CLI 的 --process-num 默认用满所有 CPU 核，这在处理大固件时是好事，但在共享服务器上可能抢资源。
一个明显的局限：格式覆盖是动态的
README 说支持 78+ 格式，但这不是一个静态数字。新格式靠社区提 issue 和 PR 添加，所以某个冷门格式可能长期不支持。如果你的固件用了私有文件系统或变种格式，unblob 会把它当作未知块切出来，不会报错，但你也得不到提取内容。另一个限制是递归深度默认 10 层，虽然可以调大，但每层都可能触发多个提取器，深度增加后时间开销非线性增长。熵分析只对未知块生效，对已知格式内部的数据不做判断，所以加密数据如果被识别成某个格式，熵分析不会介入。这些限制在 README 里没有展开，但通过 CLI 参数和功能描述可以推断出来。
与 binwalk 的差异：边界计算 vs 魔数扫描
提到固件提取，必然要对比 binwalk。binwalk 的做法是扫描已知魔数序列，标记可能的文件头，然后让你手动指定提取范围。它速度快，但误报率高，尤其对压缩流，因为很多格式的头部字节在普通数据中也会出现。unblob 的不同在于它要求每个 chunk 同时有起始和结束偏移，并且偏移必须符合格式标准。这意味着它不会把一个 0x78 0x9c 开头的随机字节序列当成 zlib 流，除非它能验证整个流的长度和校验。代价是需要为每个格式实现完整的解析逻辑，所以支持列表的增长速度不如 binwalk 的签名库快。但换来的是提取结果的可靠性，对于自动化流水线来说，误报比漏报更致命。
维护成本与许可证，值得知道的细节
unblob 采用 MIT 许可证，可以自由使用和修改。但它依赖的外部工具各有各的许可证，比如 e2fsprogs 是 GPL，sasquatch 也是 GPL。如果你的项目要分发二进制，需要注意这些依赖的许可证兼容性，MIT 只覆盖 unblob 自身的代码。维护方面，项目最近一次提交是 2026 年 6 月，版本号 26.6.4，说明保持活跃。测试套件需要 Git LFS 拉取 fixture，开发环境用 uv sync --all-extras --dev，运行 pytest。升级成本主要在于外部提取器版本变化，unblob 本身通过 pinned dependencies 控制风险。如果你要长期依赖它，建议关注 release 日志，因为格式解析逻辑变动可能影响提取结果。
编辑结论
如果你经常处理固件镜像，需要把多层嵌套的压缩包和文件系统完整拆开，unblob 是目前少有的能把边界算准的工具。它适合固件安全研究员、逆向工程师和 CI 流水线维护者。不适合只解一两个常见格式的人，那用 binwalk 或 7z 就够，不必引入一堆系统依赖。采用前先验证三件事：确认你的目标格式在官方支持列表里，因为 78 种听起来多，但总有边缘格式没覆盖；检查外部依赖是否齐全，运行 unblob --show-external-dependencies 逐项核对；如果你的输入包含加密或强压缩数据，确认熵分析功能是否满足需求，它只能提示，不能解密。unblob 的边界识别能力来自对格式规范的严格实现，这是它的核心优势，也是它比简单扫描工具更可靠的原因。
社区笔记