Markdown 버전

AI-translated from English; not yet reviewed by a fluent editor.

# 지원되지 않는 Linux 장치를 조사하려면 짝지은 USB 추적 기록을 활용하라

> 문서에 근거해 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 라이선스 스크립트·문서 모음이다. 그는 스캐너와 카메라 프로젝트에서 현재 공개된 하니스가 아니라 맞춤 코드를 사용했다고 명시한다. 지원되지 않는 USB 장치를 직접 다룰 수 있는 Linux 드라이버 개발자에게 유용한 과제는 ‘AI에게 역공학을 맡기기’보다 좁다. 정상 작동하는 제조사 드라이버로 동작 하나를 캡처하고, Linux 드라이버로 같은 동작을 캡처한 뒤, 처음 나타나는 의미 있는 차이를 조사하는 것이다.

## 큰 변화

- **무엇이 달라졌나:** Schaller는 정상적인 Windows 장치 세션과 Linux 드라이버의 시도를 동일한 호스트 측 USB 기록기로 관찰하는 반복 가능한 절차를 묶었다. 스캐너 결과는 이 비교가 유용할 수 있는 이유를 보여 주지만, 여전히 하나의 보고 사례다.
- **왜 중요한가:** 드라이버 개발자는 표시를 붙인 추적 기록을 AI 코딩 도우미에 제공하고 프로토콜 설명이나 작은 탐색 프로그램을 제안해 달라고 할 수 있다. 생성된 코드를 받아들이기 전에는 여전히 하드웨어, 정상적인 기준 동작, 직접 시험이 필요하다.
- **무엇을 살펴봐야 하나:** 관련 장치 트래픽을 관찰할 수 있어야 이 방법을 쓸 수 있다. 내장 MIPI 카메라에서는 공개된 하니스가 Windows 장치 설정과 ACPI 조사로 방향을 바꾼다. USB 추적 절차만 따르면 필요한 정보를 놓치게 된다.

## 캡처 전에 필요한 것

프로젝트의 [hw-harness README](https://github.com/cschalle/hw-harness)는 Fedora에서 개발·시험했다고 밝힌다. 문서의 구성에는 libvirt/KVM, 제조사 드라이버를 실행하는 Windows 게스트, 실제 USB 패스스루, Linux 호스트의 `usbmon` 캡처, 비교할 Linux 드라이버나 탐색 프로그램이 필요하다. Windows 11 Pro는 하니스의 RDP 기반 GUI 제어를 가능하게 한다. [가상 머신 가이드](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를 입력한다. `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 패치를 만들었다고 보고하며, 이 결과 역시 그의 설명에 근거한다. 카메라 결과를 다른 장치에서 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에 부여한 역할, 공용 하니스가 맞춤 스크립트 뒤에 나온 이유를 설명한다. 스캐너 결과는 그의 보고이며 이 기사에서 독립적으로 재현하지 않았다.
- [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/) — 작성자의 스캐너·카메라 작업 경험담. 일반화한 하니스가 맞춤 프로젝트 스크립트 이후에 나왔다고 명시한다. 개별 장치의 결과는 일화적이며 BIG CHANGE가 독립적으로 재현하지 않았다.
- [커밋 093afc5의 hw-harness 저장소](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) — Windows Home 제약을 포함한 게스트, 패스스루, RDP·SSH 전제 조건. 설치와 라이선스 결정은 사용자별로 해야 한다. 커밋 093afc5에서 검토했다.
- [hw-harness: 클린룸 유지하기](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — 관찰과 제조사 바이너리의 경계, 출처 지침, 신뢰할 수 없는 패키지에 대한 주의. 법률 조언이 아닌 엔지니어링 관행이다. 커밋 093afc5에서 검토했다.