8MB vs 16MB Flash固件逆向工程实战：Squashfs与JFFS2文件系统深度解析
当我们需要对嵌入式设备进行固件逆向或功能定制时，文件系统的选择往往成为决定工作效率的关键因素。在8MB和16MB Flash存储的设备中，Squashfs和JFFS2这两种截然不同的文件系统设计，带来了完全不同的修改流程和技术挑战。
1. 存储容量与文件系统架构的关联性
嵌入式设备的存储容量直接决定了文件系统的选型策略。在资源受限的8MB Flash设备中，开发者通常会选择Squashfs这种压缩只读文件系统来最大化利用有限空间。而16MB及以上容量的设备则更倾向于采用JFFS2这类可读写文件系统，以提供更好的灵活性。
关键差异对比表：
| 特性 | Squashfs | JFFS2 |
|---|---|---|
| 存储效率 | 高压缩比（通常40-50%） | 无压缩 |
| 写入支持 | 只读 | 完全可读写 |
| 内存占用 | 解压时需额外内存 | 直接访问 |
| 典型应用场景 | 8MB及以下小容量设备 | 16MB及以上设备 |
| 修改复杂度 | 需完整解压-修改-重打包流程 | 可直接挂载修改 |
在实际项目中遇到过这样的案例：某运营商定制路由器采用8MB Flash+Squashfs方案，其rootfs分区压缩后仅3.2MB，解压后却达到7.8MB——这种压缩特性使得Squashfs成为小容量设备的必然选择。
2. 固件逆向工程工具链配置
针对两种文件系统的处理需要完全不同的工具链配置。以下是经过多个项目验证的推荐环境搭建方法：
Squashfs工具链安装：
# Ubuntu/Debian系统 sudo apt update sudo apt install squashfs-tools binwalk python3-pip pip3 install pycryptodome backports.lzma # 验证安装 unsquashfs -version mksquashfs -versionJFFS2工具链配置：
# 编译安装最新版mtd-utils sudo apt install build-essential liblzo2-dev zlib1g-dev git clone git://git.infradead.org/mtd-utils.git cd mtd-utils/ ./autogen.sh ./configure make -j$(nproc) sudo make install注意：JFFS2处理需要内核支持mtdram模块，建议使用4.x以上内核版本。遇到挂载问题时，可尝试
sudo modprobe mtdblock手动加载相关模块。
在最近一次设备分析中，发现某型号16MB Flash设备虽然采用JFFS2，但其分区布局非常规。通过以下命令可快速确认实际分区结构：
# 查看MTD分区信息 cat /proc/mtd # 提取特定分区（示例为mtd4） dd if=full.bin of=mtd4.bin bs=1 skip=$((0x500000)) count=$((0x300000))3. 文件系统修改全流程对比
3.1 Squashfs修改流程详解
Squashfs的只读特性决定了其修改必须遵循"解压-编辑-重压缩"的完整流程。经过多次实践，我总结出以下高效工作流：
固件提取与分解：
# 使用改进版提取脚本（支持自动偏移检测） python3 squashfs_extract.py --auto full.bin这个脚本会自动识别固件中的Squashfs分区偏移，相比手动计算更不易出错。
文件系统解压：
# 使用并行解压提升速度（特别适合大体积rootfs） unsquashfs -processors 4 rootfs.squashfs常见修改操作：
- 删除监控组件：
rm -f squashfs-root/bin/monitor* - 开启调试接口：
sed -i 's/#DEBUG=1/DEBUG=1/g' squashfs-root/etc/init.d/rcS - 替换Web界面：
cp custom-web.zip squashfs-root/etc_ro/web/web.zip
- 删除监控组件：
重打包优化技巧：
# 使用XZ压缩算法最佳参数（平衡大小与解压速度） mksquashfs squashfs-root/ new.squashfs -comp xz -Xbcj arm -b 256K -no-exports
踩坑记录：早期项目中使用默认参数打包会导致某些设备启动失败，后来发现添加
-no-exports选项可解决此问题。
3.2 JFFS2实时修改方案
JFFS2的可写特性允许更灵活的修改方式，但也带来了新的挑战。下面是通过多次实践验证的可靠方法：
内存挂载法：
# 计算JFFS2镜像正确大小（单位KB） JFFS2_SIZE=$(du -k mtd4.jffs2 | awk '{print $1}') sudo modprobe mtdram total_size=$((JFFS2_SIZE + 1024)) # 额外预留1MB # 加载镜像到虚拟MTD设备 sudo dd if=mtd4.jffs2 of=/dev/mtd0 sudo mount -t jffs2 /dev/mtdblock0 /mnt/jffs2修改时的注意事项：
- 权限保持：使用
cp -a命令保留原始文件属性 - 符号链接处理：避免破坏设备节点等特殊文件
- 空间监控：
df -h /mnt/jffs2随时检查剩余空间
重新生成镜像：
# 采用最新sumtool优化擦除块分布 sudo umount /mnt/jffs2 sumtool -i /dev/mtdblock0 -o new.jffs2 -e 0x20000 -p在修改某企业级AP时发现，其JFFS2分区使用了不常见的128KB擦除块大小，导致标准工具生成的镜像无法启动。通过sumtool -e 0x20000指定正确参数后问题解决。
4. 典型问题与解决方案库
4.1 Squashfs常见故障
问题1：解压时报"Filesystem uses unknown compression"
- 原因：内核不支持特定压缩算法
- 解决方案：
# 检查可用压缩算法 grep CONFIG_SQUASHFS /boot/config-$(uname -r) # 若缺少xz支持，需重编内核或使用用户空间工具 unsquashfs -no-xz rootfs.squashfs
问题2：修改后设备启动失败
- 排查步骤：
- 检查文件权限：
find squashfs-root -type f -exec ls -l {} \; - 验证符号链接：
find squashfs-root -type l -exec ls -la {} \; - 检查设备节点：
ls -l squashfs-root/dev/
- 检查文件权限：
4.2 JFFS2典型错误
问题1：挂载时报"jffs2: Empty flash at xxxx ends at xxxx"
- 原因：擦除块大小不匹配
- 修复方案：
# 获取设备实际擦除块大小（从内核日志） dmesg | grep "erase size" # 重新生成镜像时指定正确参数 mkfs.jffs2 -e 0x40000 -o new.jffs2 -r /mnt/jffs2
问题2：修改后文件丢失
- 预防措施：
- 修改前备份关键目录：
tar czf jffs2-backup.tar.gz /mnt/jffs2/etc /mnt/jffs2/config - 使用
sync命令确保写入完成 - 避免直接编辑，采用副本替换策略
- 修改前备份关键目录：
5. 高级技巧与性能优化
5.1 混合文件系统策略
在某些特殊场景下，可以结合两种文件系统的优势：
Squashfs+OverlayFS方案：
# 创建可写叠加层 mkdir -p /overlay/upper /overlay/work mount -t overlay overlay -o lowerdir=/squashfs,upperdir=/overlay/upper,workdir=/overlay/work /merged这种方案既能保持Squashfs的压缩优势，又能获得修改能力。
JFFS2分区精简技巧：
# 清理无用文件后压缩分区 find /mnt/jffs2 -type f -name "*.log" -delete tar czf jffs2-optimized.tar.gz -C /mnt/jffs2 .
5.2 自动化修改脚本框架
对于需要批量处理的情况，建议使用如下脚本结构：
#!/usr/bin/env python3 import os import subprocess class FirmwareModifier: def __init__(self, input_file): self.input = input_file self.temp_dir = "fw_temp" def extract_squashfs(self): os.makedirs(self.temp_dir, exist_ok=True) subprocess.run(f"unsquashfs -f -d {self.temp_dir} {self.input}", shell=True, check=True) def apply_patches(self): # 自定义修改逻辑 if os.path.exists(f"{self.temp_dir}/etc/init.d/rcS"): with open(f"{self.temp_dir}/etc/init.d/rcS", "a") as f: f.write("\n# Added debug mode\nexport DEBUG=1\n") def repack(self, output_file): subprocess.run(f"mksquashfs {self.temp_dir} {output_file} -comp xz", shell=True, check=True) print(f"Successfully created {output_file}") if __name__ == "__main__": mod = FirmwareModifier("original.squashfs") mod.extract_squashfs() mod.apply_patches() mod.repack("modified.squashfs")在实际项目中，这种自动化处理方式可以将修改效率提升3-5倍，特别适合需要频繁测试的场景。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
