binwalk实战：识别伪装zip并提取SquashFS固件

简介面向CTF参赛者与信息安全初学者的binwalk工具整合包重点解决Windows环境下无法直接使用Linux binwalk的痛点。包内整理了binwalk核心组件、依赖脚本和常见固件与镜像分析示例并系统梳理了Cygwin、WSL及FLOSS替代工具的使用思路适用于固件逆向、隐写提取和数据恢复练习。资源共189个文件以89个py脚本为主体这些脚本承担扫描解析、特征匹配与结果输出另含sample、head等样本与文件头文件以及squashfs、jffs2、gzip、lzma、cpio、ihex、srec等文件系统与压缩格式测试数据可帮助读者对比真实固件结构压缩包整体约81.74MB目录按功能模块划分清晰并附带binwalk.bat便于直接调用。目前已有2966人学习下载。通过阅读源码、扫描规则和样本输出读者不仅能理解binwalk的文件标识与字节模式匹配机制还能掌握Windows下搭建等效分析环境的具体方法并灵活迁移到更多CTF MISC题目中。 前几天群里有个朋友发来一个文件名字叫 update.zip说解压一直报错系统提示could not find end of central directory。我拿到手先file看了一眼输出就是一个data再用unzip -l试也是一样的结果。折腾了几分钟我突然意识到后缀虽然是.zip但它可能根本不是 zip 格式而是固件包或者某个自定义封包。于是把 binwalk 请出来跑了一下几秒钟后结果摆在眼前——里面藏着一个完整的 SquashFS 文件系统。这种后缀骗人的情况在分析固件、CTF 取证、处理来路不明的压缩文件时实在太常见了。这篇文章就围绕binwalk zip这个组合展开。我会把 binwalk 的核心原理、在 Windows 下用 WSL 的安装过程、对伪装 zip 文件的完整分析流程以及我自己踩过的几个坑一次性说清楚。适合刚接触固件分析、遇到 zip 解压异常或者想在安全方向上入门的朋友参考。1. 场景与思路一个打不开的zip背后是什么1.1 后缀名只是表面身份先说个常识文件的真实格式跟后缀名没有必然关系。Windows 靠扩展名关联打开方式所以一个文件叫 .zip系统就会拿压缩软件去开但里面的字节如果跟 zip 格式毫无关系解压失败是必然的。Linux 下的file命令会读文件头部的魔数来做判断比 Windows 的看后缀靠谱不少但它也有局限——file通常只看开头一小段文件整体是什么就当什么返回对拼接文件、伪装文件经常误判。实际遇到假 zip的情况常见的有这么几类第一是固件包很多路由器、物联网设备的升级包文件名就叫xxx.zip实际内容却是 bootloader 加内核加文件系统厂商只是顺手起了个压缩包的名字第二是游戏资源包或软件安装包用了自定义封包格式第三是加密过的数据开头没有可识别签名第四才是真的 zip 损坏了头部或者尾部信息不完整。判断方法也很简单先用file看类型再用十六进制编辑器看文件头。正常的 zip 开头是PK\x03\x04也就是十六进制的50 4B 03 04如果开头根本不是PK那就要怀疑文件被伪装过。1.2 binwalk 在这种场景里扮演的角色binwalk 是 Craig Heffner 开源的工具最初就是为了分析路由器固件写的后来慢慢变成固件安全、取证、CTF 逆向的标配。它的核心思路是指纹识别拿着一个已知格式的签名数据库在整个文件里从头到尾做匹配只要发现某个偏移位置出现了可识别的魔数就报告出来。这跟file的整体判定思路完全不同binwalk 不做这文件是什么的判断只做这块数据可能是什么的命中报告所以特别适合处理拼接文件、隐藏数据和被改了后缀的文件。我在处理 zip 相关的问题时binwalk 解决了一个最大的痛点当解压工具报错、file又说不清类型的时候它能告诉我这个文件里面到底有什么。哪怕一个文件真的就是 zipbinwalk 也能把里面嵌套的其它格式找出来——比如压缩包里藏了图片、可执行文件、甚至完整的文件系统镜像。这就是我把它作为首选分析工具的原因。2. binwalk 的核心能力文件签名、熵分析与自动提取2.1 文件签名Magic Number识别原理文件签名是各种格式在设计时留下的身份证。PNG 图片固定以\x89PNG\r\n\x1a\n开头JPEG 以\xff\xd8\xff开头zip 以PK\x03\x04开头gzip 是1F 8BELF 可执行文件是7F 45 4C 46。binwalk 内置了 magic 数据库扫描时会在文件中逐块查找这些签名命中后输出偏移地址和描述信息。这里的偏移量非常关键因为多段数据拼接在一起时偏移量就是后续提取和切割的依据。格式文件头十六进制说明zip50 4B 03 04普通 zip 本地文件头png89 50 4E 47PNG 图片jpegFF D8 FFJPEG 图片gzip1F 8Bgzip 压缩流ELF7F 45 4C 46Linux 可执行文件SquashFS68 73 71 73常见于固件文件系统我在实际使用中有一个体会binwalk 的签名扫描速度很快但对于没有完整签名或者签名被混淆过的格式会失效。所以它不是一个万能检测器而是已知格式探测器。遇到扫描不出结果的情况就要用到熵分析。2.2 熵分析与多文件拼接的检测逻辑熵分析是 binwalk 一个容易被忽略但实际价值很高的功能。执行binwalk -E 文件它会按块计算数据的信息熵并输出一个数值分布。信息熵衡量的是数据的混乱程度纯文本、可执行代码的熵值通常较低在 4.0 到 6.0 之间加密数据、压缩数据的熵值接近 8.0因为字节分布非常均匀几乎看不出规律。这个功能在分析假 zip时特别好用。假如一个文件开头有几百字节的明文头后面跟着一大段高熵数据基本可以推断这是一个明文头 压缩负载的结构。如果整个文件的熵都很高说明内容要么被压缩过、要么被加密过这时候就算binwalk扫不出签名你也可以明确知道里面不是普通文件。熵分析配合签名扫描能覆盖绝大多数文件穿了马甲的场景。2.3 提取能力-e、--dd、-D 参数说明binwalk最实用的是自动提取。最常用的几条命令# 自动提取所有识别到的内容 binwalk -e target.bin # 指定提取某种类型格式类型描述:扩展名:命令 binwalk -D png:png:raw target.bin # 提取所有签名命中的原始块 binwalk --dd.* target.bin # 检测可执行文件架构 binwalk -A target.bin # 递归提取配合 -e 使用解完一层继续解下一层 binwalk -Me target.bin其中-e会在当前目录生成_目标文件名.extracted目录把识别出的内容按偏移量放进去。-D适合手动指定提取方式尤其是 binwalk 内置数据库无法自动处理某些格式时可以强制按自定义类型提取。要注意的是binwalk 2.x 的提取本质上是调用外部工具完成的解 squashfs 需要squashfs-tools解 ubi 需要ubi_reader解 jffs2 需要jefferson。如果依赖装不全-e会频繁报 cannot extract 之类的错误。3. 第一步实操在 Windows 的 WSL 里装好 binwalk3.1 为什么选 WSL 而不是 Windows 原生binwalk 是 Linux 生态的工具依赖了一堆命令行工具Windows 原生跑起来非常折腾。WSLWindows Subsystem for Linux是目前在 Windows 上使用 Linux 工具最舒服的方案文件系统互通Windows 的磁盘挂载在/mnt/c/下命令体验和原生 Linux 几乎一样。尤其是做固件分析时经常要配合unsquashfs、strings、xxd这些工具在 WSL 里一条命令全搞定不用来回切换系统。3.2 安装命令与依赖在 WSL 的 Ubuntu 终端里执行sudo apt update sudo apt install -y binwalk装完用binwalk --help和binwalk --version验证一下。Ubuntu 24.04 仓库里默认是 2.3.4 版本对常规扫描和使用已经够用。但如果要提取固件里的文件系统我建议把常用依赖一并装上sudo apt install -y mtd-utils gzip bzip2 tar arj lhasa p7zip-full cabextract squashfs-tools sleuthkit default-jre lzop srecord这些工具覆盖了大部分压缩格式和文件系统类型。装完依赖后binwalk -e的成功率会高很多。另外提一句如果你实在不想用 WSL也可以用 Docker 跑一个带 binwalk 的容器镜像。但文件路径映射、权限处理比 WSL 麻烦而且每次都要挂载目录体验不如 WSL 直接。我个人建议 Windows 用户优先选 WSL 路线。3.3 Ubuntu 24.04 上可能遇到的报错与处理我在新版 Ubuntu 上遇到过两个比较典型的坑。一个是 Python 3.12 环境下 numpy 版本过低运行 binwalk 时会报module numpy has no attribute bool这是因为 numpy 在 1.24 之后移除了bool别名升级一下就好sudo pip3 install --upgrade numpy另一个是 sasquatch 工具缺失。很多老固件里的 squashfs 是非标准块大小Ubuntu 官方源里的squashfs-tools解不了需要自己编译 sasquatch。如果遇到-e报错提示无法识别 squashfs我的做法是先不依赖自动提取而是用--dd把对应偏移的数据块抽出来再找专门工具处理。这个后面会在实战里详细演示。4. 实战对一个伪装zip文件进行完整体检4.1 获取文件并做基础验证假设现在手头有一个文件叫app.zip大小 8.4MB。拿到文件第一步先做基础检查file app.zip stat app.zip xxd app.zip | head -n 5如果file输出的是dataxxd看到的前几个字节还不是50 4B那基本可以确定这不是一个正常的 zip 文件。接下来就要请 binwalk 上场了。4.2 binwalk 扫描输出解读对文件执行扫描binwalk app.zip假设输出是类似这样的DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Android bootimg, kernel size: 5160960 262144 0x40000 SquashFS filesystem, little endian, version 4.0, compression: xz这个结果信息量很大。文件开头偏移 0x0 处是一个 Android bootimg偏移 0x40000 处有一个 SquashFS 文件系统。也就是说app.zip 根本不是压缩包而是一个 Android 设备固件。如果你只是想解压里面的某个文件现在就知道真正的目标在 0x40000 偏移之后而不是在一开始的 bootimg 里。4.3 用 -e 提取并识别真实内容确认里面有可提取的内容后执行自动提取binwalk -e app.zip命令结束会在当前目录生成_app.zip.extracted目录里面是按偏移命名好的文件。对于 squashfs直接解包unsquashfs 40000.squashfs解出来的 rootfs 目录里就是完整的文件系统。想要找配置文件、密钥或者某个二进制直接grep -r就完了。整个流程跑下来你会发现 binwalk 最大的价值不是知道文件是什么而是把隐藏的内容完整剥出来。如果在-e过程中报错比如提示无法识别某个签名我的习惯是用--dd强制把原始块抽出来再手动处理binwalk --ddsquashfs:rootfs app.zip4.4 如果扫描结果为空怎么办有一次我遇到一个文件binwalk 默认扫描什么都查不出来。这时候不要直接放弃换几个思路继续# 看熵分布判断有没有加密或压缩段 binwalk -E app.zip # 抓可读字符串找路径、文件名之类的线索 strings -n 8 app.zip | head -n 50 # 看文件尾部很多格式会在尾部写版本信息或 EOCD xxd app.zip | tail -n 5 # 检测内部是否包含可执行代码 binwalk -A app.zip熵分析如果显示接近 8.0 的高熵大段说明内容被加密或者压缩过strings能帮你找到一些明文线索文件尾部往往藏着 zip 的 EOCD 或固件版本字符串。组合使用这几个命令大部分伪装文件都能现出原形。5. 常见问题与排查心得5.1 invalid zip archive: could not find eocd 是什么原因这个报错很典型。EOCDEnd of Central Directory是 zip 格式的收尾记录签名是0x06054b50zip 解析器依赖它来定位中央目录。报could not find eocd原因无外乎几种文件被截断zip 的尾部记录丢失文件被附加了其它数据导致 EOCD 偏移对不上文件本身不是 zip只是改了后缀或者某些工具生成的伪 zip只写了本地文件头根本没写中央目录。如果是截断导致的可以尝试用 zip 自带的修复功能zip -FF damaged.zip --out repaired.zip如果修复也失败那大概率不是 zip直接上 binwalk 扫描。我处理过很多次这种问题最终都发现受害文件其实是固件或者其它自定义格式。5.2 真正需要处理 zip 密码时怎么办网上有些标题写着zip 无视密码直接解压基本都是标题党。zip 的经典加密 ZipCrypto 确实有已知明文攻击的可能通过已知的未加密文件可以还原密钥但前提是你得有对应的已知明文而且工具链复杂对普通用户来说不现实。现在主流压缩工具默认都支持 AES-256 加密没有密码基本无解。类似百事牛 ZIP 密码恢复这类工具本质是暴力枚举或者字典攻击只是把穷举过程包装得好看一点。真忘了密码我的建议是先回忆自己常用的密码组合用字典跑一遍同时检查压缩包里有没有未加密的同名文件也许能走已知明文攻击的路线。但从源头避免更靠谱重要压缩包建议把密码存到密码管理器里。5.3 分卷 z01 没有主 zip 文件时的处理z01是分卷压缩的第一个分卷真正的主文件是最后一个.zip里面保存了中央目录。如果只拿到一个z01而没有配套的其它分卷基本没法解压因为 zip 解析器不知道完整文件的结构。可以做的只有两件事一是用十六进制工具看看z01尾部有没有 EOCD 记录有时候文件作者只是改了名中央目录还在二是核对分卷数量和大小一般分卷命名是xxx.z01、xxx.z02、xxx.zip缺一个都不行。想解压还是得先找齐分卷。5.4 WSL 与 Windows 文件路径交互的小坑WSL 里访问 Windows 文件要经过/mnt/c/但跨文件系统操作速度很慢尤其是binwalk -e提取大量小文件时经常会有莫名其妙的权限和 IO 问题。我的习惯是把要分析的文件先复制到 WSL 的 Linux 侧目录再操作cp /mnt/c/Users/you/Desktop/app.zip ~/analysis/ cd ~/analysis binwalk -e app.zip这样不但速度快还能避免文件被 Windows 程序占用导致读取失败。另外Windows 侧解压 zip 时如果中文文件名乱码可以在 WSL 里用unzip -O GBK指定编码。之前我在处理 nvm-windows 这类工具的 zip 解压路径时也遇到过类似问题核心就是把路径和编码处理干净。踩过几次坑之后我现在拿到任何来路不明的zip都不会急着双击解压。先file看一眼再binwalk扫一轮确认里面到底是什么再做下一步。binwalk 的命令就那么多真正值钱的其实是不要被文件名骗了这个意识。希望这篇文章能帮你少走一点弯路。本文还有配套的精品资源点击获取