你打算给一份固件镜像做模块注入——替换或插入一个驱动模块，改完再刷回去。第一个念头是"找个现成的工具，写个脚本自动化"。下载、解压、打开一看，你调用它，它弹出了一个图形界面。你试着给它加参数，它理都不理。
现象
- 想用某个固件编辑工具做模块注入，期望它能接受命令行参数；
- 实际调用时，无论传什么参数，它都只是打开一个图形窗口；
--help、-h之类的常规手段全都无效——不是报错，而是根本不被解析；- 想自动化，无从下手。
根因
根因是：这个工具是纯 GUI 程序，没有命令行接口。
判断依据不需要猜——去看了它的源码入口就一清二楚：程序的第一件事就是把命令行第一个参数当成文件名拿去打开，然后进入图形界面。也就是说，它只接受"一个文件"这一个输入，参数被当作"要打开哪个文件"，而不是"要执行什么操作"。剩下的交互全靠图形界面完成。
这不是"这个工具不好"，而是它的设计定位就是给人手操作用的。很多固件/二进制编辑工具都是这样：功能很全，但交互方式是点鼠标。它们的发布形态里可能还有多个版本——某些版本带脚本接口，某些不带；而你手边这个，恰好是不带的那一类。
关键教训：工具的能力边界（尤其是"能不能脚本化"）属于选型阶段该确认的事，不能等拿起来用了才发现。
解决
既然没有现成的命令行，就自己写脚本做字节级的注入。
固件镜像本质上是一个有结构的二进制文件：里面有卷（volume）、卷里有文件（section/module）、每个模块有头部（包含 GUID、大小、类型等信息）。注入模块的脚本要做的事情是：
1. 解析镜像的卷结构
- 读固件头，定位各个固件卷（FV）的起始与大小
- 卷内遍历文件，解析每个文件头（GUID、大小、类型、属性）
2. 定位插入/替换的位置
- 替换：找到目标 GUID 的文件，原地覆盖，并更新大小相关字段
- 插入：找到目标所在卷的末尾或指定位置，插入新文件
→ 注意插入会改变后续偏移，卷头和后续文件的偏移字段都要同步改
3. 写回并修校验
- 更新卷内各文件的偏移/大小
- 重新计算需要重算的校验值（卷头校验等）
- 输出新镜像
4. 验证
- 用解析工具重新读一遍新镜像，确认结构完整、目标模块在位
写这种脚本要注意几件事：
- 先备份原始镜像，任何时候都能回退；
- 在写入前把结构完整解析一遍，别一边解析一边改——偏移算错会破坏整个镜像；
- 改完必须重新解析验证，而不是只相信写入成功；
- 校验值和偏移字段最容易漏改，"结构看起来对、但刷进去不认"经常就是这里出的问题（相关案例见"刷回自己改的固件后隐藏设置不生效，顺序错了一步"）。
延伸与预防
这条坑的通用教训是：拿工具前先确认它的运行模式（GUI / CLI）和版本能力。
这条经验在动手之前花一分钟就能确认，省下的却可能是半天的手工操作。确认清单：
- 它是 GUI 还是 CLI。 查它的用法说明、
--help输出、README 的第一段，或者直接看源码入口。有 CLI 才谈自动化。 - 这个版本有什么能力。 同一工具的不同版本会差很多：有的版本有脚本接口，有的只给界面；有的支持批量，有的只能一个个来。网上教程写的可能是别的版本。
- 它的设计意图是什么。 比如"只能替换、不能插入"这种边界，往往写在用法说明里——它决定了你这条路走不走得通（相关案例见下一条）。
- 有没有替代品。 官方工具不行时，社区里常有专门做脚本化处理的工具或库；实在没有，才轮到"自己写"。
一个更高层的习惯：把"能不能自动化"当成选型的硬指标之一。 如果一个任务你会反复做，那么"只能手工点"的工具就不该进候选——哪怕它单次用起来很顺手。反过来，如果一个工具只支持"手工操作"，那就趁早接受"这件事没法全自动"，要么接受手工，要么自己写底层脚本，别在"想办法让它接受参数"上耗时间。