Версия 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 добился от неподдерживаемого плёночного сканера узнаваемого изображения в Linux, предварительно записав USB-команды его драйвера Windows. В своём [рассказе от 15 октября](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) он описывает, как использовал Claude для анализа этих записей и разработки бэкенда SANE. У первого скана ещё были проблемы с качеством; позднее он сообщил о гораздо более качественном драйвере. Это результаты одного разработчика и одного сканера, а не независимо воспроизведённая оценка того, как часто ИИ способен писать драйверы.

Впоследствии Schaller опубликовал [hw-harness](https://github.com/cschalle/hw-harness) — набор скриптов и документации под лицензией MIT, обобщающий его метод. Он прямо указывает, что в проектах со сканером и камерой использовался специально написанный код, а не опубликованный harness в его нынешнем виде. Для разработчика драйверов Linux, имеющего физический доступ к неподдерживаемому USB-устройству, полезная задача уже, чем «дать ИИ провести обратную разработку»: записать одну операцию с работающим драйвером производителя, ту же операцию с драйвером Linux и исследовать первое существенное различие.

## Большая перемена

- **Что изменилось:** Schaller оформил воспроизводимый способ записать работающий сеанс устройства в Windows и попытку работы драйвера Linux одним и тем же USB-рекордером на хосте. Результат со сканером показывает, чем может быть полезно такое сравнение, но остаётся единичным случаем со слов автора.
- **Почему это важно:** Разработчик драйвера может дать ИИ-помощнику по программированию размеченные трассы и попросить предложить объяснение протокола или небольшой диагностический тест. Прежде чем принимать сгенерированный код, разработчику по-прежнему нужны само оборудование, работающая эталонная операция и непосредственные проверки.
- **За чем следить:** Метод зависит от возможности наблюдать нужный трафик устройства. Для внутренней MIPI-камеры опубликованный harness вместо этого обращается к конфигурации устройств Windows и анализу ACPI: инструкция по записи USB-трассы не охватила бы сведения, необходимые разработчику.

## Что понадобится до записи

В [README hw-harness](https://github.com/cschalle/hw-harness) сказано, что проект разрабатывался и тестировался на Fedora. Документированная настройка предполагает libvirt/KVM, гостевую Windows с драйвером производителя, настоящее пробрасывание USB, запись через `usbmon` на хосте Linux и драйвер 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 и выбранный сервис ИИ; фиксированной общей стоимости репозиторий не приводит. Скрипты распространяются по MIT, но это не даёт лицензии на Windows или ПО производителя. Прежде чем использовать или распространять собранное, проверьте свои лицензионные условия и применимые правила обратной разработки.

Используйте отдельный каталог проекта для каждого устройства. Согласно README, команда `harness init` создаёт конфигурацию и игнорируемые каталоги `etc/` и `captures/`. Укажите имя виртуальной машины и USB-идентификаторы производителя и продукта своего устройства, а не копируйте примеры из 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-инициализация с перечислением устройства, начните запись на хосте до передачи USB-устройства гостю. Выполните с проброшенным устройством действие через драйвер производителя в Windows и подпишите короткую конкретную операцию, например сканирование с указанным разрешением. Команда `usbcap` записывает обмен на шине и создаёт сопутствующий файл `.meta` с устройством, адресом на шине, длительностью и меткой. Точка записи на хосте находится ниже уровня пробрасывания USB, поэтому видит операцию гостя.
2. **Запишите соответствующую операцию в Linux.** Верните устройство хосту и запишите, как драйвер Linux выполняет ту же операцию с теми же настройками и физическим материалом. Эталонная запись без соответствующего запуска в Linux не позволяет установить, на каком действии драйверы разошлись. Команда сканера в репозитории — пример для конфигурации автора, а не универсальная команда для любого устройства.
3. **Сравните и проверьте одну гипотезу.** Изучите обе трассы в Wireshark или с фильтрами `tshark` из описания метода. Проверьте передачи при инициализации, записи до и после действия, опрос состояния и временные параметры массовых передач. Меняйте по одной настройке, например разрешение, чтобы увидеть, какая передача меняется. Попросите ИИ-помощника указать возможное различие и сослаться на запись и кадр, которые его подтверждают. Затем внесите ограниченное изменение в драйвер или выполните диагностический тест и повторите ту же операцию на реальном оборудовании. Правдоподобное объяснение в ответе модели не означает успех.

Непосредственный результат — пара подписанных файлов захвата и описание первого существенного расхождения. Для успешного исправления устройство в 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, а также анализ на стороне Linux через `hwdbg`. Schaller сообщает, что применил этот другой подход к камере своего ноутбука, подготовив патчи для ядра и libcamera; эти результаты также известны из его рассказа. Нельзя подменять результатом с камерой доказательства того, что USB-цикл сработал на другом устройстве.

Исследуйте наблюдаемое поведение устройства и декларативную конфигурацию. В [руководстве по clean-room-подходу](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) репозитория исключены дизассемблирование бинарных файлов производителя и копирование их кода в драйвер Linux. Там также предупреждают, что записи могут включать серийные номера устройств, а каталог проекта содержит закрытый ключ SSH. Проверьте трассы, идентификаторы устройств и файлы гостя, прежде чем передавать их сервису ИИ или публиковать; не помещайте ключи и необработанные записи в систему контроля версий. Опубликованные инструкции задают метод, который можно попробовать. BIG CHANGE изучил блог и репозиторий на закреплённой ревизии, но не запускал виртуальную машину, не записывал работу устройства и не проверял получившийся драйвер.

### Источники и дополнительные материалы

- [Рассказ Christian Schaller от 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` от 14 октября 2026 года; репозиторий распространяется по 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, пример рабочего процесса и примечание о конфиденциальности; лицензия MIT проверена в LICENSE. Коммит закреплён при аудите источников.
- [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.