1. 当binwalk遇到sasquatch报错现象与根源分析第一次用binwalk解压路由器固件时那个刺眼的红色报错让我记忆犹新WARNING: Extractor.execute failed to run external extractor sasquatch...。相信很多做固件分析的朋友都见过这个经典错误网上的解决方案清一色都是安装sasquatch就行。但真实情况远没这么简单——这背后其实是binwalk插件机制与squashfs工具链版本脱节导致的代沟问题。去年分析某款智能家居设备固件时我发现用binwalk -e解压总是报sasquatch缺失错误即便已经安装了最新版sasquatch。通过strace跟踪发现binwalk其实先调用了系统的unsquashfs来自squashfs-tools包但由于固件采用LZMA压缩格式而系统自带的squashfs-tools版本太旧4.2解压失败后才fallback到sasquatch方案。这里有个关键细节binwalk的插件调用是有优先级的在它的配置文件config/extract.conf中明确写着unsquashfs的优先级高于sasquatch。这就解释了为什么我们看到的报错是sasquatch相关但实际根源可能是unsquashfs版本过低。通过逆向分析binwalk的extractor模块我发现其工作流程是这样的检测到squashfs文件系统特征优先调用系统环境中的unsquashfs需4.5版本支持LZMA若unsquashfs不存在或执行失败尝试调用sasquatch两者都失败时抛出最后执行的错误信息这就导致了一个现象误导明明是新版squashfs-tools能解决的问题错误提示却把我们引向sasquatch这个替罪羊。我在三台不同Linux发行版Ubuntu 18.04/20.04、Kali 2023上测试发现只要squashfs-tools版本≥4.5即使完全不安装sasquatchbinwalk也能完美处理LZMA压缩的squashfs。2. LZMA压缩与squashfs版本兼容性内幕为什么版本号如此关键这得从squashfs的发展史说起。早期squashfs4.2之前主要支持gzip压缩而LZMA支持是作为补丁形式存在的。直到4.5版本LZMA才被正式合并到主线代码。这就是为什么处理现代路由器固件时它们普遍采用LZMA压缩节省空间旧版工具会提示this version Decompressors available: gzip。我曾用010 Editor对比分析过不同版本squashfs-tools生成的镜像4.2版本创建的squashfs文件头中压缩类型字段值为1gzip4.5版本则新增了2LZMA、3LZO等类型支持某些厂商还会魔改文件头比如TP-Link在0x120200偏移处有特殊标记更棘手的是不同版本的unsquashfs对异常情况的处理方式不同。测试中发现4.2版本遇到LZMA压缩直接报错退出4.3版本会尝试解压但可能得到损坏的文件树4.5版本能正确识别但可能因厂商定制需要额外参数这也是为什么在物联网安全研究中我强烈建议使用最新版squashfs-tools。去年分析某品牌摄像头固件时就遇到其使用非标准blocksize196K而非默认的128K只有4.6以上版本的unsquashfs支持-b参数指定特殊块大小。3. 彻底解决方案编译安装新版squashfs-tools经过多次踩坑我总结出最可靠的解决方案是手动编译安装squashfs-tools 4.5版本。具体操作如下# 先卸载旧版本如有 sudo apt remove squashfs-tools -y # 安装编译依赖 sudo apt install build-essential liblzma-dev liblzo2-dev zlib1g-dev help2man -y # 获取最新源码2023年更新了4.6版本 git clone https://github.com/plougher/squashfs-tools.git cd squashfs-tools/squashfs-tools # 关键编译参数 make XZ_SUPPORT1 LZO_SUPPORT1 sudo make install这里有几个容易踩坑的点help2man缺失在CentOS上编译时可能报错cannot find help2man需先yum install help2man头文件路径问题如果遇到lzma.h not found需要安装liblzma-devDebian系或xz-develRHEL系符号链接更新安装后执行which unsquashfs确认路径是/usr/local/bin而非/usr/bin验证安装是否成功unsquashfs -version # 应显示4.6-git (2023-08-15)类似版本对于binwalk建议重新编译安装并禁用sasquatchgit clone https://github.com/ReFirmLabs/binwalk.git cd binwalk sed -i s/install_sasquatch/#install_sasquatch/ deps.sh ./deps.sh python setup.py install4. 高级技巧处理特殊固件案例在某些特殊场景下即使新版unsquashfs也可能遇到问题。比如4.1 多段squashfs拼接某次分析D-Link路由器固件时发现其包含两个连续的squashfs段。此时可以# 先用dd切割出squashfs部分 dd iffirmware.bin ofsquashfs1 bs1 skip1180160 count2774624 dd iffirmware.bin ofsquashfs2 bs1 skip4057184 # 分别解压 unsquashfs -d rootfs1 squashfs1 unsquashfs -d rootfs2 squashfs2 # 合并结果 cp -ra rootfs2/* rootfs1/4.2 非标准字节序遇到大端序的squashfs多见于MIPS架构需要添加-be参数unsquashfs -be -d rootfs firmware.bin4.3 密码保护的squashfs少数厂商会使用修改过的squashfs工具加密文件系统。这时可以尝试# 使用firmware-mod-kit工具包 git clone https://github.com/mirror/firmware-mod-kit.git cd firmware-mod-kit/src ./unsquashfs_all.sh ../firmware.bin对于实在无法解压的疑难案例可以尝试用十六进制编辑器手动修复文件头。常见特征值sqsh小端序魔数hsqs大端序魔数0x800000常见的压缩块大小标志记得备份原始固件这些操作都有可能导致数据损坏。我在某次分析中不小心改错了压缩标志位导致整个文件系统无法恢复不得不重新下载1.2GB的固件包。
从sasquatch报错到unsquashfs解压：深入解析binwalk处理LZMA压缩squashfs的版本兼容性实战
1. 当binwalk遇到sasquatch报错现象与根源分析第一次用binwalk解压路由器固件时那个刺眼的红色报错让我记忆犹新WARNING: Extractor.execute failed to run external extractor sasquatch...。相信很多做固件分析的朋友都见过这个经典错误网上的解决方案清一色都是安装sasquatch就行。但真实情况远没这么简单——这背后其实是binwalk插件机制与squashfs工具链版本脱节导致的代沟问题。去年分析某款智能家居设备固件时我发现用binwalk -e解压总是报sasquatch缺失错误即便已经安装了最新版sasquatch。通过strace跟踪发现binwalk其实先调用了系统的unsquashfs来自squashfs-tools包但由于固件采用LZMA压缩格式而系统自带的squashfs-tools版本太旧4.2解压失败后才fallback到sasquatch方案。这里有个关键细节binwalk的插件调用是有优先级的在它的配置文件config/extract.conf中明确写着unsquashfs的优先级高于sasquatch。这就解释了为什么我们看到的报错是sasquatch相关但实际根源可能是unsquashfs版本过低。通过逆向分析binwalk的extractor模块我发现其工作流程是这样的检测到squashfs文件系统特征优先调用系统环境中的unsquashfs需4.5版本支持LZMA若unsquashfs不存在或执行失败尝试调用sasquatch两者都失败时抛出最后执行的错误信息这就导致了一个现象误导明明是新版squashfs-tools能解决的问题错误提示却把我们引向sasquatch这个替罪羊。我在三台不同Linux发行版Ubuntu 18.04/20.04、Kali 2023上测试发现只要squashfs-tools版本≥4.5即使完全不安装sasquatchbinwalk也能完美处理LZMA压缩的squashfs。2. LZMA压缩与squashfs版本兼容性内幕为什么版本号如此关键这得从squashfs的发展史说起。早期squashfs4.2之前主要支持gzip压缩而LZMA支持是作为补丁形式存在的。直到4.5版本LZMA才被正式合并到主线代码。这就是为什么处理现代路由器固件时它们普遍采用LZMA压缩节省空间旧版工具会提示this version Decompressors available: gzip。我曾用010 Editor对比分析过不同版本squashfs-tools生成的镜像4.2版本创建的squashfs文件头中压缩类型字段值为1gzip4.5版本则新增了2LZMA、3LZO等类型支持某些厂商还会魔改文件头比如TP-Link在0x120200偏移处有特殊标记更棘手的是不同版本的unsquashfs对异常情况的处理方式不同。测试中发现4.2版本遇到LZMA压缩直接报错退出4.3版本会尝试解压但可能得到损坏的文件树4.5版本能正确识别但可能因厂商定制需要额外参数这也是为什么在物联网安全研究中我强烈建议使用最新版squashfs-tools。去年分析某品牌摄像头固件时就遇到其使用非标准blocksize196K而非默认的128K只有4.6以上版本的unsquashfs支持-b参数指定特殊块大小。3. 彻底解决方案编译安装新版squashfs-tools经过多次踩坑我总结出最可靠的解决方案是手动编译安装squashfs-tools 4.5版本。具体操作如下# 先卸载旧版本如有 sudo apt remove squashfs-tools -y # 安装编译依赖 sudo apt install build-essential liblzma-dev liblzo2-dev zlib1g-dev help2man -y # 获取最新源码2023年更新了4.6版本 git clone https://github.com/plougher/squashfs-tools.git cd squashfs-tools/squashfs-tools # 关键编译参数 make XZ_SUPPORT1 LZO_SUPPORT1 sudo make install这里有几个容易踩坑的点help2man缺失在CentOS上编译时可能报错cannot find help2man需先yum install help2man头文件路径问题如果遇到lzma.h not found需要安装liblzma-devDebian系或xz-develRHEL系符号链接更新安装后执行which unsquashfs确认路径是/usr/local/bin而非/usr/bin验证安装是否成功unsquashfs -version # 应显示4.6-git (2023-08-15)类似版本对于binwalk建议重新编译安装并禁用sasquatchgit clone https://github.com/ReFirmLabs/binwalk.git cd binwalk sed -i s/install_sasquatch/#install_sasquatch/ deps.sh ./deps.sh python setup.py install4. 高级技巧处理特殊固件案例在某些特殊场景下即使新版unsquashfs也可能遇到问题。比如4.1 多段squashfs拼接某次分析D-Link路由器固件时发现其包含两个连续的squashfs段。此时可以# 先用dd切割出squashfs部分 dd iffirmware.bin ofsquashfs1 bs1 skip1180160 count2774624 dd iffirmware.bin ofsquashfs2 bs1 skip4057184 # 分别解压 unsquashfs -d rootfs1 squashfs1 unsquashfs -d rootfs2 squashfs2 # 合并结果 cp -ra rootfs2/* rootfs1/4.2 非标准字节序遇到大端序的squashfs多见于MIPS架构需要添加-be参数unsquashfs -be -d rootfs firmware.bin4.3 密码保护的squashfs少数厂商会使用修改过的squashfs工具加密文件系统。这时可以尝试# 使用firmware-mod-kit工具包 git clone https://github.com/mirror/firmware-mod-kit.git cd firmware-mod-kit/src ./unsquashfs_all.sh ../firmware.bin对于实在无法解压的疑难案例可以尝试用十六进制编辑器手动修复文件头。常见特征值sqsh小端序魔数hsqs大端序魔数0x800000常见的压缩块大小标志记得备份原始固件这些操作都有可能导致数据损坏。我在某次分析中不小心改错了压缩标志位导致整个文件系统无法恢复不得不重新下载1.2GB的固件包。
