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