嵌入式固件逆向分析：用CLI工具快速理清遗留镜像的分区与差异

上个月帮朋友收拾一个嵌入式项目的烂摊子。上一任工程师离职时交接文档只有一个 Word 文件上面写着三行字固件在服务器上烧录用厂家工具别乱动分区。等我打开服务器所谓的“固件”是一堆没有扩展名的 bin 文件源码找不到编译环境早没了连固件版本号都是错的。那一刻我就明白这个活不能靠问人得靠工具。那段时间我花了两个星期写了一个命令行工具专门用来接手“没人讲得清的固件”。它能做的事情说起来并不复杂把镜像文件拆开看结构识别里面的分区和关键代码段对比不同固件之间的差异再把底层日志和烧录记录整理成人能看懂的信息。这套东西帮我从一脸懵到成功把设备的启动流程、分区表、版本关系全部理清楚最后还顺利做了固件升级和定制。这篇文章就把这个工具的完整设计思路、核心实现和实操过程写出来也给那些被“历史遗留固件”折磨的同行一个可以抄作业的方案。不管是搞路由器、电视盒子、开发板还是工业设备只要你有“接手别人的固件”这种经历应该都能从中找到一点有用的东西。1. 接手固件时的真实困境1.1 文档缺失不是唯一的问题很多人以为接手固件最怕的是没有文档实际干过的人都知道文档缺失只是冰山一角。最麻烦的是固件包本身的状态它可能已经被人用各种工具拆过、改过、重新打包过你拿到的已经是“二手镜像”带着前人的修改痕迹。我遇到的这个项目就是这样。服务器上躺着一份全量固件包大小 256MB打开一看里面有 bootloader、内核、根文件系统、应用分区看起来挺全。但当我尝试用常规方式去解包的时候发现里面的分区布局跟 SoC 官方参考手册对不上。去问原厂技术支持对方答复“这是定制版本我们不对外提供布局说明”。那一刻我才意识到问题不光是文档缺失而是整个固件已经脱离了原厂的标准形态变成了一个只有部分人知道内部结构的“黑盒”。更头疼的是版本管理。目录里同时放着 update.zip、factory.bin、ota_package.img 三个文件大小不一时间戳也差了好几个月完全没有标注哪个是出货版本、哪个是测试版本。这种状态下你连“先干什么”都不知道更别提动手改固件了。1.2 “没人讲得清”背后的三个常见原因做多了之后我发现固件讲不清这件事根本不是个别现象而是产业常态。原因无非三条。第一是人员流动。嵌入式项目本来就依赖少数几个核心工程师人一走经验就带走了。尤其是外包或者小团队代码和文档往往只存在负责人的脑子里离职交接基本靠口头说能留下一个“别乱动分区”的说明已经算良心。第二是物料来源复杂。很多设备的固件不是原厂直接给的而是方案商改一版、集成商再改一版、工厂生产时又微调一版。每一层交接都会产生信息损耗到了最终使用方手里固件就只剩下一个 bin 文件加一个烧录工具内部结构全靠猜。第三是逆向成本高。不是每个人都愿意花时间去做固件逆向分析。整理分区表、识别文件系统、理解启动顺序这些工作没有直接产出看起来“不产生效益”所以长期被忽略直到出了问题才临时抓人顶上。1.3 分析边界先搞清楚哪些能碰、哪些不能碰在动手做工具之前我给自己定了一条规矩这款工具是用来“理解”固件和“梳理”固件的不是用来“绕过”固件安全机制的。拿到一份固件先确认它的来源是否合规、自己是否有授权再去做分析。如果是生产环境里的设备更得小心很多 SoC 出厂时打开了安全校验改了任意分区都会导致无法启动。我自己实操时的做法是先用只读方式扫描整个镜像把结构摸清楚确认可控后再用备份副本做拆包和重打包实验一切以恢复原厂状态为目标不保留任何临时改动。这个边界不仅是合规问题也是工程安全底线。2. 工具总体设计一个“理解助手”而非万能框架2.1 为什么要做一个专用CLI工具市面上并不缺固件分析工具比如 Binwalk、Ghidra、U-Boot 的 mkimage 系列每个都能做一部分工作。但真正到我手头的场景它们各有各的问题Binwalk 擅长识别嵌入式文件系统但对多分区 boot 镜像的拆解支持一般Ghidra 功能强大但我只是想知道固件整体结构不是每个函数都要反编译原厂工具倒是能烧录却不提供任何分析和对比能力。所以我决定自己写一个轻量级的命令行工具目标很简单输入一个镜像文件输出一份它内部的“目录页”让接手的人能在半小时内大致判断固件包含什么、分区怎么划分、改过什么。我给它起名叫 fwkit代码量不大核心逻辑其实就几块但组合起来非常顺手。它解决的核心问题不是“分析得有多深”而是“进入状态有多快”。毕竟接手固件的人没有太多时间做逆向研究他们要的是快速建立认知然后开始推进项目。2.2 四个核心功能模块这个工具的命令设计按照实际使用场景来拆分没有追求大而全。整体上分成四个模块scan扫描镜像识别文件系统、压缩层、分区边界和关键头部字段。unpack/repack把固件按分区拆出来修改后再按照原布局重新打包。diff对比两份固件找出实际发生变化的区域和关键文件。trace解析烧录日志、串口日志和 S-Record 文件把底层十六进制数据转成时间线记录。每个模块都是独立命令互相之间通过中间文件协作。比如 scan 输出的 JSON 结构可以直接喂给 unpack 做拆包diff 的结果又可以用于判断到底哪个分区变了。这种设计让工具既能在脚本里自动化执行也能手动交互调试。2.3 主动放弃的功能清单说实话在写工具的过程中我最想加的是一次性完成固件逆向外推的“一键业务逻辑还原”功能但真正做到一半就放弃了。原因很简单嵌入式固件的分析没有银弹每个 SoC 的启动流程、每个操作系统的裁剪方式、每个厂商的私有头部都不一样试图用一个框架覆盖所有情况结果一定是每个方向都做不深。同样的道理我也没打算做一个 GUI。你拿到一个待接手的固件包时第一件事一定是批量跑脚本在终端里看输出把中间结果存成文件再喂给下一步工具。GUI 在这种工作流里反而是负担。CLI 工具的好处是每一次操作都可以被复现、被记录哪怕三个月后再跑一次步骤还是一模一样。3. 核心功能实现与实操细节3.1 结构扫描五分钟摸清镜像底细接手固件的第一步永远是扫描结构。这个命令的实现思路说起来很简单读入文件后依次检测文件头部的“魔数”Magic Number和文件系统中常见的签名特征再对所有 4K 对齐位置做一轮模式匹配。实际的命令行长这样fwkit scan device_v3.img -o scan_result.json输出结果最核心的部分是一张分区概览表{ file_size: 268435456, format: raw-multi-partition, partitions: [ { name: bootloader, offset: 0, size: 524288, type: u-boot }, { name: env, offset: 524288, size: 131072, type: u-boot-env }, { name: boot, offset: 655360, size: 16777216, type: android-boot }, { name: rootfs, offset: 17301504, size: 83886080, type: squashfs }, { name: app, offset: 101187584, size: 167248872, type: jffs2 } ] }扫描逻辑最重要的是“多级识别”很多固件是套娃结构外层是 zip 或者 gzip 压缩包解开之后才是真正的分区镜像。fwkit scan 会在发现压缩层时自动解压到内存里继续扫描最后把“外层容器 内部分区”两级结构都记录下来。我在做这个项目时第一次扫描就遇到了这种情况——外层是 update.zip里面还嵌着两个独立的 boot 镜像如果不做多级识别根本找不到真正的分区。3.2 拆包与重打包安全修改并还原结构扫描只是认知层面的梳理真正动手改固件时拆包和重打包才是关键。这个模块设计的核心原则是“严格保持原始布局”也就是所有分区的大小、偏移、对齐方式都不能变。拿实际项目举例我需要在 app 分区里替换一个配置文件。操作流程是fwkit unpack device_v3.img --part app --offset 101187584 --size 167248872 --output app_partition.bin先用这个命令把 app 分区单独提出来修改文件后再用 repack 命令把整个镜像重组fwkit repack device_v3.img --replace app:app_partition_modified.bin --output device_v3_custom.imgrepack 操作有两条硬性规则一条是分区起始地址必须与原始镜像完全一致另一条是如果新分区文件比原始分区大宁可失败也不要自动扩容。为什么不能扩容因为 flash 的分区表是固定的扩容会导致后面所有分区偏移发生变化轻则启动失败重则破坏整个文件系统的布局。实际操作中还有一个容易被忽略的细节很多固件的分区后面会有“填充区”也就是空白字节区。修改后的分区如果比原来的小剩余空间必须用原始填充数据补齐不能简单填 0xFF。因为部分 SoC 的校验逻辑会把整个分区大小作为输入参与哈希计算改了填充内容同样会导致校验失败。3.3 差分对比找到真正改动的内容接手固件时经常遇到一种情况两个版本之间明明功能发生了变化但没人记得改了哪个模块。此时 diff 命令就派上用场了。diff 的设计思路分两层先做全镜像级别的粗粒度比对找出哪些偏移区域发生了变化再做分区内的细粒度比对把变化的字节范围映射到具体文件。fwkit diff factory_v2.img device_v3.img --report diff_report.html粗粒度比对我直接用块哈希的方式把镜像按 4KB 分块计算每一块的哈希值只比较哈希结果这样快很多。遇到变化的块再把这些块对应到 scan 输出的分区表里就能快速定位是 bootloader 变了、内核变了还是文件系统变了。但这个功能有个坑固件里总会有一部分区域每次打包都会变化比如文件系统的时间戳、日志区域的上下文信息甚至乱序块的排列。这些变化往往不是真正的功能变更只是“噪声”。我的处理办法是diff 报告里专门加一个分类标签把这些“疑似噪声”的差异单独分组避免干扰判断。有一次我对比两份版本整个固件只有 16 个 4KB 块发生变化其中 14 个都在日志区域只有 2 个落在 app 分区据此一下子锁定了功能的改动位置。3.4 日志与烧录记录分解最后一个模块 trace 是给生产现场准备的。很多设备在烧录和调试时会输出大量十六进制格式的日志比如 Motorola S-RecordS19/S28/S37 格式、Intel HEX、或者串口调试输出的启动信息。这些内容看着密集但关键信息其实就几十条。trace 命令做的事情是自动识别日志文件的格式把里面的地址、数据长度、校验值提取出来再清洗成一列一张启动时间线表。举例来说一段 S-Record 的原文长这样S315 00001000 6C696E75780000000000000000000000 S319 00001010 68656C6C6F2D6B65726E656C00 EE直接看很难确认哪些区域被写入过。用 trace 之后会转成一件容易检查的表记录类型起始地址数据长度校验状态S30x100016 字节通过S30x101016 字节失败看到校验失败就知道这一条烧录记录有问题需要重新生成或补充。这个模块虽然简单但处理生产环境问题时非常实用尤其是在你翻旧档案找“当初烧录时到底发生了什么”的时候。4. 常见问题与排查技巧实录4.1 最容易踩的三个深坑我把这段时间实操踩过的坑总结了一下有三类问题出现频率最高。第一类是长度字段没有同步更新。很多固件格式在头部会记录总长度、分区大小等字段拆包再打包时如果只替换了内容忘了更新头部长度值就会导致加载器读取的长度和实际数据不符。表现是设备能进入 bootloader但内核一启动就崩而且没有任何错误提示。排查起来非常隐蔽后来我的 repack 命令里特意加了一步“全头部字段校验”凡是出现这类不一致的情况直接报错。第二类是烧录地址错位。固件里的某个镜像可能并不加载到它所在的分区起始地址而是有一个独立的加载地址。如果只按文件偏移解包不了解加载地址会导致把数据烧到了错误的位置。我的建议是在用 scan 分析时就把 boot header 中的 load address 一并提取出来和文件偏移分开记录不要混为一谈。第三类是校验和与哈希验证失败。常见于带有安全启动的 SoC。这类设备在启动时会分别校验 bootloader、内核镜像、文件系统的哈希任何一处的校验值不匹配设备就直接停摆。接手这类固件时我的习惯是先从 scan 结果里看每个分区是否带签名表或者哈希字段如果带说明这个固件有完整性校验任何修改都必须同步更新校验值。而这个问题远比想象中棘手因为校验值经常是根据一个你拿不到的私钥生成的所以“改了固件怎么让它通过校验”本身就是一个很大的话题。像我这种只做工程梳理的人习惯是明确提醒项目方这个固件的完整性校验是身份验证的一部分修改它之前要先把烧录许可和密钥归属问题弄清楚。4.2 快速排查速查表症状可能原因排查建议烧录后无法启动无日志Bootloader 起始地址错误用 scan 确认第一分区偏移并比对 SoC 手册内核启动后立即崩溃头部长度字段未更新检查镜像头部长度并确认与分区大小一致文件系统挂载失败分区偏移被改动或大小不匹配对比修改前后的 repack 布局升级后功能未变差异集中在非业务分区用 diff 过滤噪声后再看 app 分区校验和不通过哈希值未同步更新检查安全启动配置与校验表字符串乱码固件层做了加密或压缩确认是否为私有格式再做针对性处理这里要特别提醒一点如果是私有加密格式不要试图绕过加密来“恢复”内容。正确做法是回到方案商或原厂拿到明文镜像或者在授权范围内按照官方接口完成数据读取。工程上我们需要的是可追溯、可维护而不是破坏性地破解。4.3 一个可复用的接手工作流写了这么多最后把整个“接手一份没人讲得清的固件”的流程浓缩成五个动作方便你直接用。第一步建副本。拿到任何固件先做完整备份分析过程中永远操作副本不要碰原始文件。第二步扫描结构。跑 fwkit scan把分区概览、格式信息、加载地址全部导出成 JSON。第三步解包验证。挑一个小分区比如 env 或者 boot做解包、重新打包看能否恢复原始状态用来验证工具和流程没问题。第四步全面解包与梳理。把所有分区解出来逐一确认类型给每个分区补充注释和来源信息形成自己的交接文档。第五步做一次差分测试。用生产固件和测试固件做 diff明确版本差异把所有变化点记录在案方便以后追溯。这套流程用在那个“什么说明都没留下”的烂摊子项目上三天时间我就把固件结构全部摸清第四天就能基于新工具实现定制固件的正常打包项目顺利推进了下去。最后再分享一点个人感受。固件分析最难的地方不是技术而是心态。面对一份没人讲得清的固件不要指望有谁能给你标准答案更不要指望一次扫描就能解决所有问题。真正可靠的路径是建立一个可复现的分析工具链把每一次操作和输出记录下来把“猜”变成“验证”。等你把整个镜像的脉络理清楚你会发现那些看似神秘的固件本质上不过是结构清晰的数据集合而你在接手过程中积累的分析工具和工作流反而成了比结果更有价值的沉淀。