Christian Schaller 先记录了一台尚不受支持的胶片扫描仪在 Windows 驱动下通过 USB 发送的内容，随后让它在 Linux 上生成了可辨认的扫描图像。在他的10 月 15 日文章中，他描述了如何借助 Claude 分析抓包记录并开发 SANE 后端。第一次扫描仍有画质问题；后来，他表示驱动已有明显改善。这只是一个开发者和一台扫描仪的结果，并不是经过独立复现、用于衡量 AI 编写驱动成功频率的测评。
Schaller 随后发布了hw-harness。这套采用 MIT 许可的脚本和文档把他的方法做了通用化整理。他明确说明，扫描仪和摄像头项目使用的是专门编写的代码，并非目前公开版本的 harness。对于能实际接触一台尚不受支持的 USB 设备的 Linux 驱动开发者，有用的任务比“让 AI 做逆向工程”更具体：用正常工作的厂商驱动记录一项操作，用 Linux 驱动记录同一操作，再调查第一个有意义的差异。
重大变化
- 发生了什么变化：Schaller 整理出一种可重复执行的方法，用宿主机上的同一套 USB 记录工具观察正常工作的 Windows 设备会话和 Linux 驱动的尝试。他的扫描仪结果说明了这种比较为何可能有帮助，但它仍只是一个由当事人报告的案例。
- 为什么重要：驱动开发者可以把带有标签的抓包记录交给 AI 编程助手，请它提出协议解释或小型探测程序。不过，在接受生成的代码之前，开发者仍需要硬件、正常工作的参考操作，以及直接测试。
- 需要关注什么：这一方法取决于能否观测到设备的相关通信。对于内置 MIPI 摄像头，公开的 harness 转而检查 Windows 设备配置和 ACPI；照搬 USB 抓包流程会漏掉开发者所需的信息。
抓包前需要准备什么
项目的hw-harness README表示，它是在 Fedora 上开发和测试的。文档中的配置要求包括 libvirt/KVM、运行厂商驱动的 Windows 虚拟机、真正的 USB 直通、在 Linux 宿主机上用usbmon抓包，以及用于比较的 Linux 驱动或探测程序。Windows 11 Pro 支持 harness 基于 RDP 的图形界面控制功能。虚拟机指南指出，Home 版虚拟机仍可使用 SSH，但无法使用上述 RDP 控制功能。代码库列出了 Fedora 软件包和用户组权限；连接设备之前，应在检出的修订版本中运行harness doctor，查找缺失的组件。
准备好获准使用的 Windows 安装和厂商软件、准确对应的设备、可重复的操作，以及存储数据包记录的空间。预算应包括虚拟机、硬件访问、Windows 和自行选择的 AI 服务；代码库没有给出固定的全流程费用。脚本采用 MIT 许可，但这不等于获得了 Windows 或厂商软件的使用许可。使用或分发采集内容之前，应检查自己的许可条款和适用的逆向工程规则。
每台设备使用单独的项目目录。README 表示，harness init会创建配置，以及被忽略的etc/和captures/目录。虚拟机名称和 USB 厂商／产品 ID 应根据自己的设备填写，不要照抄 README 中的示例值。winctl auth、harness iso及文档中的虚拟机初始化流程用于建立对 Windows 虚拟机的控制；抓包之前，winctl status应显示ssh: ok。这是项目文档所述的配置，不是 BIG CHANGE 实际执行过的步骤。
让两个系统执行同一操作
- 记录基线和 Windows 参考操作。按照代码库的方法文档，先了解空闲通信是什么样子。如果需要设备最初的枚举过程，应在把 USB 设备交给虚拟机之前启动宿主机抓包。用厂商的 Windows 驱动操作直通设备，并为一项简短、具体的动作加上标签，例如按指定分辨率扫描。
usbcap会记录总线通信，并写入一个.meta附属文件，包含设备、总线地址、持续时间和标签。宿主机的抓包点位于 USB 直通层之下，因此能够观测虚拟机的操作。 - 记录对应的 Linux 操作。把设备交还给宿主机，记录 Linux 驱动在相同设置下、对同一份实物材料执行同一操作的过程。只有参考抓包而没有对应的 Linux 运行记录，无法确定驱动在哪个动作上出现分歧。代码库的扫描仪命令只是作者配置的示例，不是适用于所有设备的通用命令。
- 比较记录，检验一个假设。用 Wireshark 或方法文档中的
tshark过滤条件读取两份记录。检查初始化传输、动作前后的写入、状态轮询和批量传输的时序。每次只改变一项设置，例如分辨率，观察哪项传输发生变化。请 AI 助手指出一个可能的差异，并引用支持它的抓包记录和帧。然后对驱动做有限修改或编写探测程序，在真实硬件上重复同一操作。模型给出一个看似合理的解释，并不代表测试成功。
直接产出是两个带标签的抓包文件，以及对第一个有意义差异的说明。要认定修复成功，Linux 设备必须在开发者自己的检查中，持续执行预期操作并生成预期输出。几个字节相同，或得到一张不完整的图像，都不足以证明驱动整体质量。在 Schaller 的叙述中，第一次可辨认的扫描仍需改进；而在他工作的同时，SANE 主项目通过另一条途径加入了对其扫描仪的支持。
如果两份记录难以比较，应缩短操作，并确认设备、设置和抓包层一致。该方法建议使用只回答一个问题的小型抓包，并单独记录一次设备接入过程。如果直通或虚拟机控制失败，在把空记录解释为驱动故障之前，先使用harness doctor、hostdev status和虚拟机配置指南进行检查。保留原始记录和笔记，让建议采用的寄存器常量能追溯到实际观察到的帧。
USB 抓包的边界
内置 MIPI 摄像头不会向宿主机 USB 记录工具暴露同样有用的通信。方法文档转而介绍用winctl probe查看 Windows PnP 属性、INF 文件、注册表项和 ACPI 表，以及通过hwdbg进行 Linux 侧检查。Schaller 表示，他对笔记本摄像头采用了这条不同的路径，并编写了内核和 libcamera 补丁；这些结果同样来自他的个人叙述。不能把摄像头的结果当作 USB 操作循环在另一台设备上成功的证据。
调查应局限于观察到的设备行为和声明式配置。代码库的clean-room 指南排除了反汇编厂商二进制文件，或把其中代码复制到 Linux 驱动的做法。它也提醒，抓包记录可能包含设备序列号，项目目录中还存有 SSH 私钥。把内容交给 AI 服务或公开分享之前，应检查记录、设备标识符和虚拟机文件；不要把密钥或原始抓包记录放入版本控制。公开文档给出的是一种可尝试的方法。BIG CHANGE 检查了博客和固定修订版本的代码库，但没有运行虚拟机、抓取设备通信，也没有验证最终驱动。
来源与延伸阅读
- Christian Schaller 10 月 15 日的文章介绍了扫描仪和笔记本项目、他认为 Claude 发挥的作用，以及为什么共享 harness 出现在专用脚本之后。扫描仪结果由他本人报告，本文没有独立复现。
- hw-harness 代码库说明了工具、Fedora 和 Windows 前置条件、示例配置，以及项目隐私提醒。BIG CHANGE 检查的提交为
093afc5c576c200f29b771d01624a327d0ff1806，日期是 2026 年 10 月 14 日；代码库采用 MIT 许可，在该修订版之后可能发生变化。 - 方法文档规定了基线、参考操作、Linux 比较和重复测试流程、抓包数据的处理注意事项、USB 记录的读取，以及设备没有宿主机可见总线时的另一条路径。
- Windows 参考虚拟机配置指南涵盖虚拟机访问、USB 直通，以及 Windows Pro 和 Home 在 RDP 控制方面的区别。应检查自己安装的许可条款。
- Clean-room 边界说明阐述了项目基于观察的实践、处理厂商二进制文件的限制，以及记录常量出处的必要性。这是项目的工程指导，不是法律意见。
