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 ![Two sheets with abstract trace rows, one orange highlighted, beside a closed generic USB device connected to a small computer.](https://bigchange.ai/api/media/file/usb-trace-comparison-concept-v1.png) 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 整理出可重複的方法，讓正常運作的 Windows 裝置工作階段與 Linux 驅動程式的嘗試，都由同一個主機端 USB 記錄器觀察。他的掃描器成果說明比較為何可能有用，但仍只是單一回報案例。 - **為何重要：** 驅動程式開發者可以把標記清楚的擷取紀錄交給 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/` 目錄。VM 名稱和 USB 廠商／產品 ID 應取自自己的裝置，不要照抄 README 範例。`winctl auth`、`harness iso` 和文件中的客體初始設定流程，可建立 Windows VM 的控制能力；擷取前，`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` 和[VM 設定指南](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 流程在另一台裝置上成功的證據。 調查應聚焦於觀察到的裝置行為與宣告式設定。儲存庫的[淨室開發指南](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md)排除反組譯廠商二進位檔，或把其程式碼複製到 Linux 驅動程式。指南也提醒，擷取內容可能包含裝置序號，而專案目錄內有 SSH 私密金鑰。交給 AI 服務或公開分享前，應檢查紀錄、裝置識別資訊與客體檔案；金鑰與原始擷取不要納入版本控制。公開指示建立的是一套可以嘗試的方法。BIG CHANGE 檢查了部落格與固定版本的儲存庫，但沒有執行 VM、擷取裝置資料，或驗證產生的驅動程式。 ### 來源與延伸閱讀 - [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 查閱的是2026年10月14日的提交 `093afc5c576c200f29b771d01624a327d0ff1806`；儲存庫採 MIT 授權，該版本之後可能已有變動。 - [方法文件](https://github.com/cschalle/hw-harness/blob/main/doc/method.md)詳述基線、參考操作、Linux 比較與重複測試流程、擷取資料的妥善處理、USB 紀錄閱讀，以及匯流排對主機不可見時的替代路徑。 - [Windows 參考 VM 設定](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md)涵蓋客體存取、USB 直通，以及 Windows Pro 與 Home 在 RDP 控制上的差異。應檢視自身安裝的授權條款。 - [淨室開發界線](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 參考 VM](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — 客體、直通與 RDP／SSH 前置條件，包括 Windows Home 限制；安裝與授權決策仍須依使用者自身情況處理。查閱版本為093afc5。 - [hw-harness：維持淨室開發](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — 專案對觀察與廠商二進位檔的界線、來源追溯指引，以及不可信套件提醒；這是工程做法，而非法律建議。查閱版本為093afc5。