世界は立ち止まらない。RSS
BIG CHANGE.

Markdown版

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/)では、そのキャプチャーの分析とSANEバックエンドの開発にClaudeを活用したと説明している。最初のスキャンにはまだ画質の問題があり、その後、はるかに改善されたドライバーができたと報告した。これは一人の開発者と一台のスキャナーの結果であり、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ベースのGUI制御機能を使える。[VMガイド](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md)では、HomeのゲストでもSSHは使えるが、そのRDP制御機能は使えないとしている。必要なFedoraパッケージとグループ権限はリポジトリに記載されている。デバイスを接続する前に、チェックアウトしたリビジョンで`harness doctor`を実行し、不足する要素を確認する。

使用が許可されたWindows環境とメーカー製ソフトウェア、対象そのもののデバイス、繰り返せる操作、パケットキャプチャー用の空き容量を用意する。VM、ハードウェアへのアクセス、Windows、選択するAIサービスの費用を見込む必要がある。リポジトリは全工程の固定費用を示していない。スクリプトはMITライセンスだが、Windowsやメーカー製ソフトウェアのライセンスが付与されるわけではない。収集物を利用・配布する前に、自身のライセンス条件と適用されるリバースエンジニアリングのルールを確認する。

デバイスごとに別のプロジェクトディレクトリを使う。READMEによると、`harness init`は設定と、管理対象から除外される`etc/`および`captures/`ディレクトリを作成する。READMEのサンプル値をコピーするのではなく、対象デバイスに合わせてVM名とUSBのベンダーID・製品IDを入力する。`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テーブルを調べ、Linux側は`hwdbg`で調べる方法を説明している。Schallerは、カーネルとlibcameraへのパッチを伴うこの別の方法を、ノートPCのカメラに適用したと報告している。これらの結果も本人の記事に基づく。カメラの成果を、別のデバイスで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/)は、スキャナーとノートPCでの作業、本人が説明する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基準VMの設定](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md)は、ゲストへのアクセス、USBパススルー、RDP制御に関するWindows ProとHomeの違いを扱う。自身の環境のライセンス条件を確認すること。
- [クリーンルームの境界](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は独立した再現検証をしていない。
- [コミット093afc5時点のhw-harnessリポジトリ](https://github.com/cschalle/hw-harness) — README、ツール、Fedora／Windowsの前提条件、作業例、プライバシー上の注意。MITライセンスはLICENSEで確認。出典監査ではコミットを固定した。
- [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) — Windows Homeの制約を含む、ゲスト、パススルー、RDP／SSHの前提条件。インストールとライセンスの判断は利用者ごとに異なる。コミット093afc5で確認した。
- [hw-harness：クリーンルームを守る](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — 観測とメーカーバイナリーの境界、出所を記録する指針、信頼できないパッケージへの注意。法的助言ではなく技術上の実践。コミット093afc5で確認した。