嵌入式固件解包实战：海思安卓盒子黑盒固件逆向与重打包

前阵子接手了一台老安卓盒子主控是海思 hi3798mv100需求是定制开机动画、预装两个应用、改默认桌面。这种活儿放到有完整文档的厂商环境里半小时就能跑完可现实是我手里只有一份update.zip压缩包里嵌套着好几个没名字的 bin 文件没有分区说明、没有打包脚本、没有平台手册同事故交代得很直白“这个应该能解包你自己想办法吧。”说实话拿到那份固件的前两天我几乎零进展。file识别成 databinwalk扫出来一堆琐碎特征strings里能看到一些路径但完全拼不出结构。网上确实能搜到不少同名机型固件包也有付费代改的服务但没几个人愿意把这类“黑盒固件”的内部结构讲透。后来我花了两周时间把这些 bin 一层层拆开又把反复踩坑沉淀的过程固化成一个小工具 fwparser。这篇博客就把完整分析流程、工具的设计思路和实操中遇到的坑一次写全给正准备接手类似固件的同行做个参考。1. 接手之后先别急着写工具固件到底是怎么组成的1.1 为什么一份固件会“没人讲得清”这种情况在行业里太常见了。嵌入式产品的固件通常由方案商写好整机厂只做外壳、排线和包装方案商交付给产线的是最终量产镜像不会把完整文档和源码一起移交。等产品过了两三年停产、方案商那边换了对接人打包环境和源代码基本就彻底失联了。设备要返修、定制、升级你手里只剩一份不完整镜像这是最典型的“没人讲得清”。更麻烦的是很多固件在出产前会被反复拼接。设备里实际跑的不是一个 bin而是 bootloader、kernel、recovery、system、userdata 等一串镜像按固定偏移拼成的大容器。有些厂商还会在容器外再套一层自解压或简单加密。没文档、没脚本时唯一的出路是把结构特征一项项从二进制里挖出来。1.2 固件的基本解剖结构固件像一栋楼bootloader 是承重墙负责上电初始化、初始化 DDR、加载内核kernel 是水电管线提供驱动、网络栈和 flash 读写rootfs 是室内装修存放应用、链接库、配置脚本另外还有几个“杂物间”分区放 MAC 地址、型号参数、环境变量、开机 logo。具体到常见平台结构大致是 uboot或 Rockchip 的 loader→ boot 分区 → recovery 分区 → system 分区 → 私有配置分区。Rockchip 平台喜欢把所有分区镜像统一塞进一个update.img头部写有每个分区的偏移和大小海思平台常见update.zip里放多个 img 镜像由升级脚本按块刷写Amlogic 平台又往往用一个自定义头部把多个分区串在单个镜像里。这些平台之间没有统一标准通用工具很难面面俱到这也是为什么我坚持自建一套分析流程。1.3 准备工作清单工欲善其事必先备好料。硬件方面USB 转 TTL 串口线强烈建议准备很多信息靠串口日志才看得出来。如果设备有烧录模式瑞芯微 Maskrom 模式、海思 HiTool、Amlogic USB Burning Tool 都得先确认怎么进。软件方面Linux 环境最顺手主力命令基本是这些file unknown.bin hexdump -C unknown.bin | head -30 binwalk unknown.bin strings -n 8 unknown.bin | grep -iE kernel|android|hisilicon|rockchip|amlogic|squash|ext4|jffs2 | head -40这几条命令能快速判断平台、文件系统类型和大致分区位置。大多数时候 30 分钟内就能确定方向。2. 工具设计思路把“猜”变成“算”2.1 为什么不用现成 binwalk 硬扫binwalk 是逆向固件的入口工具但面对这种没人讲得清的固件短板特别明显。第一关键特征如果被自定义头或加密壳挡住binwalk 只能扫出一堆碎片特征给不出完整架构第二它不关心偏移对齐和分区大小约束容易把正常文件尾部误判成分区边界第三对“无魔数”的私有容器基本无能为力。我要的不是“找出几个可疑碎片”而是把固件完整还原成可修改、可重新回刷的形态。所以工具目标在设计之初就很明确输入一个 bin输出分区清单、可解包的文件系统、可重新打包的镜像。自动识别常见平台结构如果平台未知允许手工标定并把标定结果保存成可复用模板。2.2 fwparser 的三层设计第一层是指纹识别。维护一张特征表记录常见 bootloader、SquashFS、JFFS2、ext 系列、gzip、cpio、Android boot header、Rockchip 分割头、Amlogic header 的魔数与偏移特征。扫描时不仅比对魔数还要校验魔数两侧结构的合理性减少误报。第二层是结构标定。根据指纹结果列出候选分区边界支持人工修正偏移。把“system 起始地址按 4KB 对齐”“镜像尾部补零到下一个块边界”这类约束记录成 profile。这样同平台新一代固件来了直接套 profile 就能秒级复用。第三层是重组打包。按 profile 重新生成整个镜像自动对齐、填充、修正校验值。没有这一层分析再透彻也只敢看不敢改。2.3 分析模板的作用模板文件就是一个 YAML 或 JSON记录各分区偏移、大小、文件系统类型和校验位置。大致长这样name: hisilicon_hi3798mv100 loader: { offset: 0x0, size: 0x100000 } boot: { offset: 0x100000, size: 0x2000000 } recovery: { offset: 0x2100000, size: 0x2000000 } system: { fs_type: squashfs, offset: 0x4100000, size: 0x30000000 }遇到同平台新版本固件先把模板套上去校验各分区偏移是否吻合全部对上就能直接进修改环节。比每次从 hexdump 重新猜偏移快太多。3. 核心实现细节识别、提取、加密与重组3.1 指纹识别与偏移扫描魔数只是起点。U-Boot 镜像头部有 “U-Boot” 字符串Android bootimg 头部是 8 字节 “ANDROID!”SquashFS 是 “hsqs”ext 系列是0x53 0xEFgzip 是0x1F 0x8Bcpio 是0x070701或0x070702。扫到魔数之后还必须做三件事看偏移是否落在合理区间看头部记录的长度与实际文件长度是否一致看起始偏移能不能被对齐单位整除。约束越多误报越少。有个常用技巧拿同一型号两个不同版本 bin 做对比。cmp -l看差异字节分布差异区域的边界往往就是分区边界或校验字段。这是没有文档时最可靠的定位手段之一。3.2 文件系统提取电视盒子、路由器最常遇到的 rootfs 是 SquashFS 和 ext4。SquashFS 用unsquashfs -d rootfs system.squashfs解包但要先确认是不是被塞进了自定义头。遇到binwalk定位不准时直接dd按推算偏移把区段切出来再file一次看类型。ext4 分区可以先用debugfs -R ls -l / system.img查看确认没问题再 loop 挂载或用debugfs -R dump导出。JFFS2 是 NAND 设备常见格式jefferson工具能解但经常遇到交叉编译版本差异导致崩溃。这时可以在 Linux 上模拟挂载mount -t jffs2利用内核自带支持读取遇到自研块格式就只能strings找路径后手动按 inode 结构分析了。3.3 加密与安全启动带加密的固件处理顺序值得分享一下。先判断是不是“伪加密”很多设备只做了简单异或或整体 gzip头部和尾部还留着明文结构用hexdump和strings就能发现线索。再把 uboot 的 env 分区 dd 出来看看有没有解密密钥或开关项有些平台会把关键参数直接放在 env 的bootargs里。如果确认启用了芯片级 secure boot修改后直接刷回去必然失败这种场景一般不去碰 bootloader优先改 rootfs同时关闭校验选项仅针对自己拥有或授权的设备做功能定制。最实用的一招是观察串口打印。启动日志会直接暴露问题方向kernel panic、crc mismatch、signed image verify fail 分别指向不同原因。日志信息往往比静态猜测高效得多。3.4 重新打包对齐、校验和与分区表改完 rootfs 必须重新打包这一步翻车率最高。常见校验有三类长度对齐、头部 size 字段、CRC32。一个常用于处理头部 size 和尾部 CRC 的 Python 片段import binascii def pad_to(data, align): pad_len (align - (len(data) % align)) % align return data b\x00 * pad_len def fix_size_at(data, offset, length_bytes4, endianlittle): size len(data) b size.to_bytes(length_bytes, endian) data bytearray(data) data[offset:offset length_bytes] b return bytes(data) def fix_crc32_tail(data, tail_offset-4): crc binascii.crc32(data[:tail_offset]) 0xffffffff return data[:tail_offset] crc.to_bytes(4, little)用之前一定要确认头部 size 字段的位置和 CRC 的计算范围。改完后先在测试机上验证不要直接刷生产机。4. 完整实操一台老盒子从解包到改完刷回去4.1 第一步确认平台并导出固件手里的update.zip解压后有boot.img、system.img、recovery.img和几个不带名字的 bin。先执行基础诊断file boot.img strings -n 10 boot.img | head -30 strings -n 10 system.img | grep -iE squash|ext4|android|version | head -20看到ANDROID!确认 boot 分区是 Android bootimage看到hsqs确认 system 分区是 SquashFSstrings里出现的 “hi3798mv100” 直接锁定了平台。整个方向瞬间清晰。4.2 第二步分区识别与 system 分区解包boot.img直接用abootimg或unpack_bootimg解开得到 kernel 和 ramdisk。system.img先跑一遍binwalk找 SquashFS 偏移binwalk system.img dd ifsystem.img ofsystem.squashfs bs512 skip偏移块数 unsquashfs -d rootfs system.squashfs解出目录后发现里面有preinstall、etc、framework等标准 Android 目录说明整个分析思路走通了。顺便把recovery.img也解开竟然在脚本里发现上一位维护者留的调试打印侧面印证这块固件确实被人改过但没留任何记录。4.3 第三步修改内容并重新打包在rootfs里替换开机动画、放好预装 APK改掉build.prop的默认桌面配置然后用 mksquashfs 重新打包mksquashfs rootfs system_new.squashfs -comp xz -b 131072注意原 SquashFS 的 block size 和压缩算法尽量保持一致否则 bootloader 挂载参数会对不上。再按 profile 里记录的 size 字段位置把新镜像长度写回头部重算 CRC。最后按分区顺序拼回完整 bin。4.4 第四步刷写与验证先把原始固件完整备份两遍再烧录到测试芯片上接串口看 log。第一次启动卡在 CRC mismatch查下来是只改了头部 size 却忘了尾部补零到分区固定长度导致 CRC 范围包含了旧数据。修正后再次启动顺利进桌面。整个过程耗了一个晚上如果一开始就有成熟模板半小时内就能完成同平台改包。5. 常见问题与排查技巧实录5.1 刷机卡 logo 或校验失败怎么办卡在 logo 说明 bootloader 已开始加载 kernel 或 system但后续校验没过。优先看串口输出crc mismatch就是校验没更新sha mismatch是安全校验链断了mount failed多半是 SquashFS 打包参数不一致。建议先在测试机上反复验证再上批量设备。5.2 文件系统解不开、魔数对不上binwalk扫不到特征时用hexdump -C看分区开头几十字节很多自定义头部会在固定位置保留明文标识。把前面的头剥掉按推算偏移切出真正文件系统区段再file一次。极端情况就用strings在整分区里搜路径关键字反向定位 inode 表位置。5.3 修改后分区不够装原厂 SquashFS 压缩率很高稍微堆点新内容就容易超出分区固定大小。处理思路清理 rootfs 里无用资源比如预装商店、第三方输入法、多余字体检查是否有重复库再不行就调小 block size 提升压缩率。如果分区大小定义在头部且支持调整可以连带调整后续分区偏移但整体重算风险很高新手不建议碰。5.4 设备连烧录工具都连不上先确认驱动和工具版本瑞芯微平台要短接 maskrom 引脚或进入 loader 模式海思平台用 HiTool 烧写模式Amlogic 平台按住 reset 再插 USB。如果设备进的是正常系统烧录工具必然识别不到要从启动阶段入手。串口完全没有输出时检查接线和波特率很多盒子默认 115200但部分 SoC 是 1500000参数选错会满屏乱码。5.5 一套顺手的工作流与避坑速查现在处理新固件的顺序已经固定先备份原版、跑 file 和 strings、再 binwalk 粗扫、按指纹定位分区、提取文件系统、修改、重打包、测试机验证。中间最容易踩的坑整理成一张速查表现象常见原因排查手段刷后卡 logo校验值未更新或分区偏移错串口看 crc/sha mismatch挂载失败SquashFS 打包参数不一致保持原 block size 和压缩算法binwalk 无结果自定义头或加密壳hexdump 头部找可见标识分区不够装原压缩率高于修改后清理无用资源调 block size烧录连不上未进入对应烧录模式短接或按键进入 loader 模式串口乱码波特率或接线错误尝试 115200 / 1500000最后说一点实际操作中的体会不管工具做得再顺手拿到任何新旧固件第一步永远是完整备份原镜像。很多人跳过这步直接改包翻车后连原厂包都找不回来只能对着砖头发呆。我的习惯是原版 bin 和拆出的每个分区各留两份、存到不同目录这习惯已经帮我省了不知道多少时间。