4、固件文件系统分析：Binwalk、jefferson、sasquatch等工具使用，识别文件系统（Squashfs/Cramfs/JFFS2/UBIFS），提取文件系统并分析关键文件

固件文件系统分析是IoT设备安全研究的核心环节。当我们通过串口、JTAG或OTA升级包获取到固件二进制后，绝大多数情况下固件内部并非单一的可执行文件，而是由一个引导加载程序（Bootloader）、内核镜像（Kernel Image）以及一个或多个文件系统镜像（Filesystem Image）组成。文件系统承载了设备运行所需的全部用户态程序、配置文件、Web服务脚本、动态链接库以及敏感密钥。本章将深入讲解如何利用Binwalk、jefferson、sasquatch等专用工具，准确识别固件中嵌入的文件系统类型（Squashfs、Cramfs、JFFS2、UBIFS），完成提取与关键文件分析，为后续的漏洞挖掘（如命令注入、硬编码凭据、越权访问）奠定数据基础。

上图展示了固件文件系统分析的整体决策链路。从固件二进制出发，首先通过Binwalk进行熵分析与签名扫描，判断是否存在加密或压缩；随后根据识别出的文件系统类型选择对应的提取工具；最终进入根文件系统内部，对关键文件进行安全审计。下面我们将逐一拆解每个环节的具体操作与实战要点。

4.1 核心原理：固件结构、文件系统签名与熵分析

嵌入式固件通常采用“Bootloader + Kernel + RootFS”的三段式布局，其中RootFS（根文件系统）是安全分析的主要目标。为了节省Flash存储空间并提高读取效率，厂商普遍采用压缩型只读文件系统，最常见的有Squashfs、Cramfs、JFFS2和UBIFS。每种文件系统在二进制层面都有独特的魔数（Magic Number）或结构特征，Binwalk正是通过扫描这些特征来定位文件系统在固件中的偏移位置。

理解文件系统的底层布局至关重要。例如，Squashfs的超级块（Superblock）通常以“hsqs”（0x68737173）开头，包含inode数量、压缩类型、块大小等元数据；Cramfs的魔数为0x28CD3D45（小端序显示为45 3D CD 28），其结构相对简单，不支持写入操作；JFFS2专为NOR/NAND Flash设计，节点头以0x1985或0x1986标记，支持磨损均衡；UBIFS则基于UBI卷管理层，需要先解析UBI卷标识（通常以“UBI#”开头），再提取其中的UBIFS数据。

熵分析是判断固件是否加密或压缩的重要手段。如果固件整体熵值接近8.0（即数据高度随机），则很可能经过了AES等加密处理，此时静态分析将无法直接进行，需要结合硬件调试接口或动态运行环境。反之，如果熵值在5.0-7.5之间，通常意味着存在压缩数据段，Binwalk可以依据签名定位这些段。

4.2 判断方法与操作流程：从扫描到提取的完整步骤

下面以一台典型IP摄像头固件（假设文件名为 IPC_fw_v1.2.bin）为例，演示完整的文件系统识别与提取流程。

步骤一：初步扫描与熵分析

# 查看固件基本信息
file IPC_fw_v1.2.bin
# 输出: IPC_fw_v1.2.bin: data

# 计算熵值，判断是否加密
binwalk -E IPC_fw_v1.2.bin

# 执行签名扫描
binwalk -Me IPC_fw_v1.2.bin

扫描结果通常会显示类似以下内容：

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             DLOB firmware header, boot partition
262144        0x40000         Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5242880 bytes

从输出可知，固件在偏移 0x40000 处存在一个Squashfs文件系统，压缩算法为LZMA。此时可以直接使用 dd 命令切割该段，或使用Binwalk的自动提取功能。

步骤二：根据文件系统类型选择提取工具

下表总结了不同文件系统对应的推荐工具及注意事项：

步骤三：执行提取

# 方法1：Binwalk自动提取（适用于标准Squashfs）
binwalk -Me IPC_fw_v1.2.bin

# 方法2：手动切割后使用unsquashfs
dd if=IPC_fw_v1.2.bin of=squashfs.img bs=1 skip=262144 count=5242880
unsquashfs squashfs.img

# 方法3：使用sasquatch处理非标准Squashfs（如LZMA压缩）
sasquatch squashfs.img

对于JFFS2文件系统，推荐使用 jefferson 工具，它专门针对JFFS2的节点结构进行了优化，能够处理损坏或非对齐的数据块。对于UBIFS，则需要先使用 ubireader_extract_files 解析UBI卷，再提取UBIFS镜像。

4.3 案例拆解：从Squashfs中定位硬编码后门账号

下面通过一个真实场景展示文件系统分析的实际价值。某安防摄像头固件（固件大小8MB）在Binwalk扫描后，于偏移 0x1A0000 处发现Squashfs文件系统。使用 sasquatch 成功提取后，得到完整的根文件系统目录树。

初始现象：设备存在未授权访问漏洞，攻击者无需登录即可获取root shell。初步怀疑是Web服务存在命令注入，但代码审计未发现明显问题。

分析过程：在提取出的文件系统中，重点检查了以下关键路径：

• /etc/passwd 和 /etc/shadow：发现root账号的密码哈希为空（即无需密码即可登录）。
• /etc/init.d/rcS：启动脚本中有一条 telnetd -l /bin/sh -p 9999 命令，意味着设备默认开启telnet服务。
• /usr/sbin/boa.conf：Web服务器配置中，User 指令设置为 root，导致CGI程序以最高权限运行。

关键输入数据：通过 grep -r "password" etc/ 搜索，在 /etc/webshell_passwd 文件中发现明文密码 admin:Zte521，该密码同时被用于SSH和Web登录。

实际操作步骤：

# 进入提取后的文件系统目录
cd _IPC_fw_v1.2.bin.extracted/squashfs-root/

# 检查用户账号
cat etc/passwd
# root:x:0:0:root:/root:/bin/sh

# 检查启动服务
cat etc/init.d/rcS | grep -i "telnet\|ssh\|shell"

# 搜索硬编码密钥
grep -r "password\|passwd\|secret" etc/ usr/ 2>/dev/null | head -20

结果对比：通过文件系统分析，确认了三个叠加风险：空密码root账号、默认开启的telnet服务、Web服务以root权限运行。这三个因素共同导致了设备可被完全远程控制。修复方案包括：强制设置强密码、关闭telnet、降低Web服务运行权限。

复盘经验：固件文件系统分析不应只停留在“能提取”层面，更要建立“关键文件清单”意识。建议优先审计 /etc 下的配置文件、/bin 和 /sbin 下的关键二进制（如 busybox）、Web目录（/www 或 /htdocs）中的CGI脚本，以及所有包含“password”、“key”、“”字样的文件。

4.4 常见误区与总结复盘

在实际的固件分析工作中，初学者常陷入以下误区：

• 误区一：Binwalk提取失败即认为固件加密。实际上，很多提取失败是因为文件系统被嵌套（如Squashfs内嵌JFFS2），或使用了非标准压缩参数。此时应尝试 binwalk -A 查看opcode，或使用 binwalk --run-as=root 提升权限后重试。
• 误区二：忽略文件系统挂载点的实际意义。提取出的文件系统目录结构并不总是与设备运行时的挂载点一致。例如，某些设备会将可写分区（如 /overlay）单独存放，分析时需注意区分只读根文件系统与可写数据分区。
• 误区三：只关注二进制漏洞，忽略配置文件。IoT设备中大量漏洞源于配置不当，如默认口令、调试接口未关闭、日志泄露敏感信息等。文件系统分析应兼顾配置审计与二进制逆向。