에이전트 기반 리버스 엔지니어링으로 웹캠, 모니터, 마이크, 캡처 장치, WiFi 조명의 펌웨어와 제어 표면을 분석한 기록입니다.
2026년 8월 23일 지난 몇 주 동안 손이 닿는 곳에 있는 주변기기를 에이전트 주도 방식으로 리버스 엔지니어링했다. 그 기기들에서 나는 마이크 안의 완전한 평문 명령 셸, 녹화 중에도 활동 LED를 끌 수 있는 웹캠, WiFi에 연결된 누구에게나 메모리 쓰기를 제공하는 키 라이트를 얻어냈다. 주변기기는 에이전트형 RE의 이상적인 대상임이 입증되었다. 내 컴퓨터에 연결된 작은 컴퓨터이고, 호스트와의 데이터 연결 및 대개 펌웨어 업데이트 수단을 갖추고 있으므로 에이전트가 반복 작업할 대상이 있기 때문이다. 최종적으로는 내 장비를 더 잘 제어하고 이해하게 되었다.
이 기기들 각각에 대한 내 과정은 대체로 같았다. 제조사에서 기기의 펌웨어와 관련 업데이트 도구 사본을 가져와 리버스 엔지니어링 환경에 넣고, Claude Opus 5에게 목표를 알려 준 뒤 작업하게 뒀다. 기기에 따라 목표는 다소 달랐지만, 보통은 이런 형태였다.
In this directory is the firmware and update utility for ___. The device is also attached to this computer, and you may interact with it in non-mutating ways. Exhaustively document and cross-validate the entire firmware, including the following goals:
* reverse engineer the firmware update format and update protocol
* implement our own update utility
* determine the security properties of the update protocol, including checksums, signature validation, secure boot
* use static and dynamic analysis to determine all protocol surfaces and completely enumerate functionality
* find any hidden or debug functionality in the product and how to access it
결과에 따라 후속 작업의 방향은 달랐지만, 대략적인 취지는 이해했을 것이다. 목록을 훑어보자. 각 기기에는 생성형 슬롭 문서와 스크립트로 가득한 GitHub 저장소가 연결되어 있으며, 그 대부분은 실제 하드웨어에서 실시간으로 검증했다. Claude Code 세션 기록에서 가져온 각 기기별 작업량도 포함했다. “작업 시간”은 긴 유휴 구간을 제외하고 Claude가 실제로 작업한 시간이다. “내 프롬프트”는 계속하라고 한 단어로 지시한 것까지 포함해 내가 입력한 모든 메시지다. 다섯 기기를 합치면 2주간의 저녁 시간에 걸쳐 약 13시간의 작업 시간과 98개의 프롬프트가 들었다.
GitHub 저장소 - Claude 작업 시간 3.7시간, 내 프롬프트 33개
나는 얼굴을 추적해 촬영 구도를 자동으로 맞춰 주는 멋진 짐벌식 팬틸트줌 카메라인 Insta360 Link 웹캠을 사용한다. 고전적인 iSeeYou 익스플로잇처럼 활동 LED를 무력화할 수 있는지 알고 싶었다.
흥미롭게도 이 카메라 내부에서 많은 일이 일어난다는 점은 즉시 분명했다. 알고 보니 이 기기는 업스트림 SoC 공급업체인 Ambarella에서 가져온 완전한 RTOS인 ThreadX를 실행한다. 이 RTOS에는 앞서 언급한 얼굴 추적과 설정 제어용 제스처 감지 같은 기능을 제공하는 여러 작은 비전 모델이 올라가 있다. 작은 웹캠 안에 놀라운 복잡성이 들어 있지만, 그만큼 흥미로운 공격 표면도 있다는 뜻이다.
USB Video Class 인터페이스에는 기기를 “대용량 저장소” 모드로 전환하는 XU(확장 유닛) 명령이 있다. 그러면 준비된 펌웨어 업데이트를 기기 내부 FAT 파일 시스템으로 전송할 수 있고, 기기는 재부팅 시 이를 자신에게 적용한다. 이 경로는 다시 연결해 재부팅하는 사용자 개입이 필요하다. 하지만 USB 벤더 클래스에는 임의 파일 읽기/쓰기와 재부팅 명령을 노출하는 다른 명령 채널이 실제로 있다. 이를 이용하면 사용자 상호작용 없이 기기를 완전히 플래시할 수 있다. 펌웨어가 올바른 위치에 놓이면 사실상 변조 방지는 없고, 무결성 확인용으로 덧붙인 MD5 해시만 있다.
표시 LED는 펌웨어에 색상, 점멸 패턴 등을 규정하는 잘 구조화된 “패턴” 집합이 있고, 여러 기기 상태에서 이를 인덱싱한다는 사실이 드러났다. 나는 Claude에게 카메라 활동용 테이블 항목을 제거하고, 무결성 해시를 수정한 뒤 카메라에 플래시하는 도구를 작성하게 했다. 빠른 시험 결과, 녹화 중에 평소 켜지던 녹색 LED가 더는 켜지지 않았다. 끔찍하다! 이 기기에서는 녹화하지 않을 때 짐벌 자체도 아래로 꺾이므로 완전히 은밀하지는 않지만, 그래도 기분이 좋지는 않다.
패치 전과 후의 LED 동작.
GitHub 저장소 - Claude 작업 시간 1.2시간, 내 프롬프트 13개
내 ASUS ROG Swift PG42UQ 모니터는 “픽셀 클리닝”을 실행하라고 가끔 나타나는 팝업 오버레이가 짜증 나서 실제로 시작한 대상이었다. 나는 이 모니터에서 픽셀 클리닝을 의도적으로 실행한 적도 없고 앞으로도 없을 것이다. 신경 쓰지 않으며, 그 오버레이가 영원히 사라졌으면 한다. 이를 끌 수 있는 디버그 메뉴 같은 것이 있거나, 최악의 경우 펌웨어의 분기를 패치할 수 있지 않을까?
Claude는 펌웨어에 사실상 아무 보호도 없다는 것을 발견했다. 2슬롯 A/B 구성과 단순 체크섬은 있지만, 결국 기기에 원하는 무엇이든 쓸 수 있다. 펌웨어 업데이트는 USB로 브리지된 I2C 버스를 통해 실행된다.
픽셀 클리닝 경고는 비활성화하는 기본 방법이 없으며, 작동 시간 8시간 후에는 항상 나타난다. 뭐, 어쩔 수 없다. 그래도 Claude는 해당 기능을 죽일 적절한 패치 영역을 찾았다. 아직 이 기기에 수정 펌웨어를 쓸 용기는 내지 못했다. 꽤 비싼 모니터이기 때문이다. 하지만 언젠가는 하게 될 것이다.
또 다른 멋진 부분은 DDC/CI 인터페이스 탐색이었다. 이는 디스플레이 케이블 자체에서 제공되는 제어 채널로, 호스트가 입력과 기타 설정을 변경할 수 있게 한다. ASUS는 Windows 유틸리티인 DisplayWidget을 통해 이를 제공하는 듯하지만, Linux에서는 별 도움이 되지 않는다. 그래서 이제는 하드웨어 조준선이나 확대 오버레이, FPS 카운터, 카운트다운 타이머 같은 DDC/CI 기능을 전환할 수 있는 셸 스크립트가 있다. 나중에는 쉽게 접근할 수 있도록 이들 중 일부를 단축키에 연결할 수도 있다.
GitHub 저장소 - Claude 작업 시간 4.2시간, 내 프롬프트 32개
이 시점에는 이 기기들을 계속 뚫어 볼 실질적 동기보다 음산한 호기심이 더 크다. 내 마이크인 Shure MV7은 USB로 연결되며, 기기 내 디지털 볼륨 제어 등이 있으니 분명 어느 정도 지능을 갖추고 있다.
이 기기의 펌웨어는 Windows 소프트웨어인 MOTIV Mix 안에 숨겨져 있었다. 그래서 Claude는 이를 Wine에 설치하고, 업데이트 서버를 찾아 내려받았다. 나는 최신 버전이 아니었으므로, Linux에서 마이크를 업데이트하기 위해서라도 이 작업을 해낼 합리적인 동기가 있었다. 펌웨어에는 DSP와 MCU 펌웨어가 모두 들어 있었고, 예상할 만하게도 솔직히 꽤 지루했다. 다시 말해, 펌웨어 플래시 자체에는 실질적인 보안이 없었다.
하지만 업데이트 프로토콜을 살펴보니 전체 기기가 48개의 서로 다른 명령을 구현한 USB HID 벤더 클래스 프로토콜 위에서 실행되는 완전한 평문 명령 셸을 실제로 갖고 있다는 사실이 드러났다. HID이므로 Chrome의 웹페이지에서 WebHID를 통해 실제로 접근할 수 있다. 그래서 나는 Claude에게 셸을 사용할 웹 인터페이스를 만들게 했다. 여기에는 12개가량의 DSP 노브, 임의 메모리 읽기/쓰기, LED 제어, 그리고 요청한 등급의 이름과 문자열 비교하는 것이 전체 인증 과정인 4단계 사용자 권한 체계 등 온갖 흥미로운 설정이 있다. su sup는 그냥 작동한다. 최상위 등급에서는 기기에서 음소거할 수 없도록 터치 패널을 비활성화하고, 마이크가 실제로 음소거되었는지와 관계없이 음소거 LED를 독립적으로 제어할 수 있다. 마이크에서 다시 등장한 웹캠 LED 수법이다. 분명히 말하지만, 그 UI를 사용하다 어리석은 일을 하면 기기를 망가뜨릴 수도 있으니 주의하라.
WebHID 셸 인터페이스. 왼쪽의 DSP 노브는 기기 자체 설정이고, 오른쪽 콘솔은 HID를 통해 통신하는 평문 명령 셸이다.
GitHub 저장소 - Claude 작업 시간 1.5시간, 내 프롬프트 10개
Elgato Cam Link 4K는 그저 HDMI 비디오 캡처 기기이며, 솔직히 앞선 것들과 거의 같았다. 이 기기에서 흥미로웠던 점은 완전히 무인 상태로 작업하게 했다는 것이다. 잠들기 전에 말 그대로 과정을 시작했고, 일어나 보니 분석 결과와 작동하는 펌웨어 업데이터가 만들어져 있었다. 펌웨어에는 실제 HDMI 처리를 위한 MCU 이미지와 FPGA 비트스트림이 들어 있으므로, 그 리버스 엔지니어링을 충분히 깊게 파고들면 FPGA로 재미있는 일을 할 수도 있다. 펌웨어 업데이트 경로에는 보호가 없다.
비디오 매개변수 협상에 사용되는 모든 EDID 정보를 추출할 수 있었으므로, 기기에 제공되는 해상도, 재생률, 색 공간, 크로마 서브샘플링 옵션을 정확히 알 수 있다.
벤더 HID 프로토콜에는 내부 I2C 버스에 대한 터널링 접근도 포함되어 있다. 내부 HDMI 수신기 레지스터를 건드려 볼 수 있으니 꽤 멋지다.
GitHub 저장소 - Claude 작업 시간 2.4시간, 내 프롬프트 10개
마지막으로 USB가 아니라 WiFi로 연결된 Elgato Key Light Mini를 살펴봤다. 이 기기는 예상보다 훨씬 더 흥미로웠다. 의미 있는 펌웨어 무결성 보호 기능을 가진 유일한 기기였다. Elgato는 펌웨어 페이로드의 SHA-512 해시에 대해 Ed25519로 펌웨어 업데이트에 서명하고, 검증되지 않는 펌웨어는 거부한다. 이 기기는 기본적으로 WiFi 네트워크에 연결된 뒤 같은 네트워크의 누구에게나 인증 없는 접근을 제공하므로, 위협 모델이 본질적으로 다르다. 따라서 이는 타당하다.
안타깝게도 앞서 살펴본 다른 모든 기기보다 나은 점이기는 해도, 펌웨어를 보호하는 시점은 정확히 한 번, 즉 업데이트가 일어날 때뿐이다. 부트로더나 다른 종류의 보안 부팅 체계가 강제하는 부팅 시점 검사가 아니다. 그리고 업데이터는 기기 안의 _다른 모든 것_이 여전히 작동하는 동안 실행되므로, 그 서명 검증을 비활성화하려 시도할 विशाल한 공격 표면이 있다. 나는 Claude에게 이를 가능하게 할 익스플로잇을 찾아보라고 했고, 대단한 것을 발견했다. 내부 UART에 페이로드를 곧바로 넣는 HTTP POST 요청인데, 여기에는 메모리 포크 명령이 포함되어 있다. 즉 ATSE=0200ED94,0E001009라는 HTTP POST 한 번으로 서명 검사를 무동작으로 만들 수 있고, 정상 서명이 없는 펌웨어 이미지로 자유롭게 업데이트할 수 있다. 기기의 이름을 바꾸는 간단한 패치로 이를 성공적으로 시험했다. 그러니, 음, 이 기기를 신뢰할 수 없는 네트워크에 두지 말라.
이 모든 일에 대해 여러 감정이 든다. 3월에 썼듯이, 이는 상호운용성과 우리가 원하는 대로 작동하지 않는 것들을 고치는 데 놀라울 정도로 유용하다. 이제 하드웨어는 대체로 기기당 몇 시간의 거의 완전 자동화된 기계 작업만으로 만져 볼 수 있도록 “열려” 있다. 가까운 미래에는 Linux 장비에서 실행하는 소프트웨어에 기능을 추가하듯이 웹캠 펌웨어에도 손쉽게 기능을 추가할 수 있기를 기대한다.
반면 보안 전문가로서, 여러 이유로 이 점이 두렵다. 컴퓨터에 연결된 모든 기기는 악성 펌웨어 임플란트가 심어졌을 수 있다는 전제에서 운영하겠다. 이전에는 이런 일이 모델별로 상당한 투자가 필요했고 “국가 행위자” 종류의 활동으로 전형화되었다. 운영체제는 마이크가 마이크로 남고, 방이 충분히 조용해 사용자가 보고 있지 않다고 판단하면 갑자기 Win+R을 누르는 키보드로 변해 모든 데이터를 훔칠 페이로드를 내려놓지 않도록 사용자와 함께 보장할 준비가 되어 있지 않다. 또한 WebUSB, WebHID, WebBluetooth의 존재는 사용된 클래스의 구체적 특성에 따라, 사용자가 권한 요청을 무심코 수락하는 순간 연결된 기기 중 하나에 영구적인 백도어가 생길 수 있음을 의미한다.
네트워크 연결 기기는 이제 거의 보편적으로 망한 것처럼 보인다. 여기 문서화하지 않은 채 살펴본 다른 기기도 몇 개 있지만, 상용 Dell 디스플레이에서 루트 셸을 얻었고 Eaton UPS에서는 RCE를 얻었다. 당연히 신뢰할 수 없는 클라이언트가 이런 기기에 접근하게 하는 것은 원래도 모범 사례가 아니었다. 그러나 이를 실행할 수 있는 속도와 규모 때문에 이제 위험은 훨씬 더 커졌다.
마지막으로, 오늘날 AI를 탑재해 자동으로 리버스 엔지니어링하는 웜이 무엇을 할 수 있을지 생각하지 않을 수 없다. 환경을 탐색하고, 감염된 대상 근처에서 발견한 액세서리, IoT 기기, 산업 장비로 스스로를 밀어 넣기 위해 능동적으로 작업하는 똑똑한 명령 및 제어 체계로 정찰 정보를 전달하는 자기 복제형 악성코드를 누군가 만들 수 있다고 상상하는 것은 _아주 작은 도약_일 뿐이다. 이를 막아 온 것은 두 가지다. 기기 모델마다 자체 리버스 엔지니어링이 필요하다는 점, 그리고 이를 검증하려면 하드웨어를 손에 넣어야 한다는 점이다. 첫 번째 노동은 내가 방금 에이전트에게 넘겼다. 두 번째는 이미 감염된 호스트에 존재하는 악성코드에는 공짜다. 솔직히 이것이 이미 존재한다고 해도 놀라지 않을 것이며, 앞으로 몇 년은 극도로 흥미로울 것이라고 생각한다. 🫠