当前位置：首页 > news >正文

Binwalk解压固件翻车实录：从sasquatch报错到firmware-mod-kit救场的完整复盘

news 2026/6/3 10:20:47

固件解压实战：从Binwalk报错到多工具协同分析的完整指南

那天下午，当我拿到那台TP-Link路由器的固件文件时，本以为只是次常规分析。按照标准流程运行binwalk -Me firmware.bin后，终端突然弹出鲜红的报错：

WARNING: Extractor.execute failed to run external extractor 'sasquatch -p 1 -le -d 'squashfs-root' '%e'': [Errno 2] No such file or directory: 'sasquatch'

这个看似简单的错误提示，开启了我接下来三天的工具链调试之旅。本文将完整还原这个典型固件分析案例的解决路径，涵盖从基础工具配置到高级解压方案的完整知识体系。

1. 初识固件解压工具链

嵌入式设备固件分析的第一步往往是文件系统提取。现代路由器固件通常采用SquashFS这种为嵌入式系统优化的只读文件系统，配合LZMA等压缩算法减小体积。主流的解压工具链包含三个关键组件：

Binwalk：自动化固件分析瑞士军刀
squashfs-tools：官方维护的SquashFS操作套件
sasquatch：社区改进版解压工具

典型的依赖关系如下表所示：

工具名称	维护方	主要功能	版本敏感度
binwalk	ReFirm Labs	自动化签名识别与文件提取	中
squashfs-tools	squashfs官方	标准SquashFS操作工具集	高
sasquatch	社区开发者	支持非标准SquashFS的补丁版本	极高

当这些工具版本不匹配时，就会出现各种"command not found"或解压失败的情况。我的案例中，问题核心在于sasquatch这个本应作为备选的工具反而成为了主要报错源。

2. 基础方案：构建纯净工具链

面对sasquatch command not found错误，第一个直觉是安装缺失的组件。但直接apt install sasquatch往往不能解决问题，因为：

软件源中的版本可能过旧
预编译二进制可能与当前系统不兼容
依赖关系可能未正确解析

更可靠的方式是从源码构建。以下是经过验证的构建流程：

# 安装编译依赖 sudo apt update sudo apt install -y build-essential liblzma-dev liblzo2-dev zlib1g-dev # 从GitHub克隆源码 git clone https://github.com/devttys0/sasquatch cd sasquatch # 关键步骤：应用社区补丁 chmod +x build.sh ./build.sh

但这个方法在我使用的Ubuntu 22.04系统上依然失败，错误指向LZMA压缩支持问题。此时有两条路径可选：

继续调试sasquatch的编译问题
转向更稳定的squashfs-tools方案

考虑到时间成本，我选择了第二条路径。

3. 进阶方案：squashfs-tools深度配置

官方squashfs-tools的4.5+版本已支持大多数现代压缩格式。手动构建流程如下：

# 克隆最新源码 git clone https://github.com/plougher/squashfs-tools cd squashfs-tools/squashfs-tools # 关键编译选项 make XZ_SUPPORT=1 LZO_SUPPORT=1 LZ4_SUPPORT=1 sudo make install

安装后需要配置binwalk优先使用系统自带的unsquashfs。通过编辑~/.binwalk/config/extract.conf：

[signature] signature = squashfs command = unsquashfs -d %e%.extracted/squashfs-root -f %e

这个方案解决了80%的标准固件解压需求。但在处理某些厂商的特殊修改版固件时，仍可能遇到如下错误：

Filesystem uses lzma compression, this is unsupported by this version Decompressors available: gzip

4. 专家方案：firmware-mod-kit工具包

当标准工具全部失效时，firmware-mod-kit（FMK）成为了最后的救命稻草。这个专为固件逆向设计的工具包包含多个针对特殊情况的处理脚本：

extract-multisquashfs-firmware.sh：处理多重嵌套的SquashFS
unsquashfs_all.sh：自动尝试所有已知解压方法
uncpio.sh：处理CPIO封装的特殊情况

典型使用流程：

# 下载并初始化FMK git clone https://github.com/rampageX/firmware-mod-kit cd firmware-mod-kit/src ./configure && make # 处理特殊固件 ./extract-multisquashfs-firmware.sh ../firmware.bin

FMK的强大之处在于其深度解析能力。以我遇到的TP-Link固件为例，它能正确识别以下结构：

0x0-0x10F30：厂商自定义头部
0x10F30-0x16F80：X.509证书
0x16F80-0x17030：U-Boot信息
0x20200-0x20400：二级固件头
0x120200：实际SquashFS文件系统

5. 工具链优化与自动化

经历这次调试后，我建立了自己的固件分析工具链最佳实践：

版本控制：使用Docker容器固定工具版本

FROM ubuntu:20.04 RUN apt update && apt install -y squashfs-tools git build-essential RUN git clone https://github.com/plougher/squashfs-tools WORKDIR /squashfs-tools/squashfs-tools RUN make && make install

智能路由：根据固件特征自动选择工具

def extract_firmware(firmware): if check_signature(firmware, 'TP-Link'): run_fmk_extract(firmware) elif check_compression(firmware, 'lzma'): run_squashfs_tools(firmware) else: run_binwalk(firmware)

日志分析：建立错误代码与解决方案的映射表

错误代码	可能原因	推荐方案
sasquatch command not found	路径或版本问题	源码编译sasquatch
lzma unsupported	squashfs-tools版本过低	升级到4.5+版本
misleading-indentation	源码补丁冲突	使用FMK替代
invalid filesystem	厂商自定义修改	十六进制手动分析