AI 에이전트가 내 마이크와 웹캠을 해킹했다

Everything I own, owned

AI 에이전트가 내 마이크와 웹캠을 해킹했다

저자는 AI 에이전트(Claude Opus 5)를 활용해 주변의 5가지 주변기기(웹캠, 모니터, 마이크, 비디오 캡처, 키라이트)의 펌웨어를 역공학했다. 결과적으로 마이크에서 전체 평문 명령 셸을 발견하고, 웹캠의 활동 LED를 끄는 패치를 적용했으며, 키라이트는 서명 검증을 우회할 수 있는 취약점을 찾았다. 대부분의 기기는 펌웨어 보호가 거의 없었고, 총 13시간의 자동 작업과 98번의 프롬프트로 완료했다.

단일 HTTP POST 요청으로 서명 검증을 무력화할 수 있다.
  1. SillyUsername

    저도 이렇게 했지만 Silicon Motion sm750 GPU 전용 머신으로 했습니다. 서버용 저가 단일 HDMI 출력 GPU 카드이고 최대 해상도는 1080p입니다. 같은 하드웨어의 구형 VGA/DVI 버전을 기반으로 합니다.

    아직 테스트 중이지만 와, 정말 놀랍네요. 제 새 드라이버는 이제 21:9 울트라와이드 2048x864 비율에서도 작동하고, 2048x1152도 처리합니다.

    드라이버는 잘 작동하며 이제 완전한 DRM 및 DKMS 지원이 있습니다. 제조사가 커널 5.x까지만 지원하기로 한 후에도 최신 Linux에서 실행됩니다. Windows 지원은 당연히 여전히 잘 됩니다.

    원본 소스에서 많은 결함을 발견했습니다. 누군가 HDMI 사양을 읽지 않았거나 뭘 하고 있는지 전혀 몰랐던 것 같습니다.

    새 드라이버는 사양 타이밍과 시퀀스를 완전히 준수하고, 더 이상 종료 시 멈추지 않으며, 더 많은 화면 모드를 허용하기 위해 EDID를 무시합니다.

    또한 더블 버퍼링, 섀도 버퍼링, 16비트 색상을 위한 사용자 정의 매직 스퀘어 디더 모드가 있으며 32비트 모드보다 확실히 빠릅니다. 제가 발명한 디더는 몇 년 전 레트로 하드웨어를 위해 만든 것에서 파생되었지만, 너무 좋아서 (제 생각에는) 일반적인 JPEG 아티팩트와 구별할 수 없고 찾거나 보기가 매우 어렵습니다. GPU가 32비트 색상이 아닌지 확인하기 위해 Codex에게 몇 번 물어봐야 했습니다.

    GPU에는 여전히 성가신 버그가 있어서 VESA 모드에서 동기화를 잃지 않고 KVM을 통해 일관되게 작동하지 않지만, GPU 하드웨어 때문이라고 생각하지 않습니다. 직접 연결하면 완벽하게 작동합니다.

    곧 GitHub 저장소를 올릴 예정입니다...

  2. ndiddy

    > 제 ASUS ROG Swift PG42UQ 모니터가 실제로 시작점이었습니다. 가끔 '픽셀 청소'를 실행하라는 팝업 오버레이가 뜨는 것이 짜증났기 때문입니다. 저는 이 모니터에서 의도적으로 픽셀 청소를 실행한 적이 없고 앞으로도 없을 것이며, 신경 쓰지 않습니다. 그 오버레이가 영원히 사라졌으면 좋겠습니다. 어쩌면 그것을 끌 수 있는 디버그 메뉴가 있거나, 최악의 경우 펌웨어에서 분기를 패치할 수 있지 않을까요?

    참고로 이것은 OLED 모니터이므로 '픽셀 청소'는 아마 일종의 번인 방지 기능일 것입니다. AI에게 펌웨어를 살펴보고 무엇을 하는지 설명하도록 요청할 수 있을 것입니다.

  3. phh

    이 기사와 정신을 확실히 좋아합니다. 저는 저렴한 IoT 제품을 많이 모아왔고, 아마 계속 소유하게 될 것입니다!

    두 가지:

    - 축제에 물을 끼얹자면, 유럽 RED 지침은 인터넷에 연결된 모든 제품에 대해 안전한 업그레이드를 의무화합니다(아마도 이것이 Elgato Key Light Mini가 서명된 펌웨어를 가진 이유일 것입니다). 따라서 OEM은 이제 사용자가 그렇게 하는 것을 방지해야 합니다. (EN18031-1). 또한 네트워크 자격 증명(WiFi SSID/PSK)을 보안 저장소에 저장하도록 요구합니다(보안 부팅 없이 이 요구 사항을 통과할 수 있는지 모르겠습니다. Elgato는 아마 할 것 같습니다?). '안전한 업그레이드'는 '설치 시점에 무결성과 신뢰성이 유효함'으로 느슨하게 정의되므로 이 요구 사항이 하드웨어 업그레이드를 금지하지는 않지만, OEM의 가장 가능성 있는 구현은 그렇게 합니다.

    - Android 스마트폰에서 이 작업을 수행하려면(부디 해주세요!): GSI/Treble 경로를 통해 진행하는 것이 좋습니다. 이렇게 하면 빠르게 부팅되는 OS를 얻을 수 있습니다. 고쳐야 할 것이 많지만 대부분 사용자 공간 문제일 것이며 에이전트가 작업하기 더 쉬울 것입니다. 에이전트는 OEM의 사용자 공간을 디컴파일하고 AOSP의 사용자 공간과 비교하여 차이점을 구현할 수 있을 것입니다. (이것은 커널 관련 내용을 포함하고 '부팅만 되는' 상태에 도달하기가 복잡할 수 있는 '레거시' 또는 LineageOS 공식 방법과 비교됩니다.)

  4. philips

    저는 몇 주 전에 에이전트와 함께 Supernote 노트 파일 형식을 리버스 엔지니어링했습니다. 수년 동안 커뮤니티는 형식에 대한 문서를 요청해 왔습니다. 그리고 몇 시간 만에 에이전트는 20개 정도의 파일 형식 예제 픽스처와 30개 정도의 프롬프트로 형식을 역추적했습니다.

    이런 틈새 장치를 위해 손으로 이 작업을 하는 것은 전혀 가치가 없었을 것입니다. 이제 몇 시간의 노력으로 작동하는 코드와 문서가 있습니다.

    https://github.com/philips/supernote-typescript/blob/main/pl...

    https://philips.github.io/supernote-typescript/

  5. Waterluvian

    2주 전에 저는 Claude에게 "LAN에 <wifi 콘센트 릴레이>가 <IP>에 있습니다. 직접 제어하세요."라고 말했습니다. 그리고 약 8번의 명령 승인 후에 새 펌웨어가 실행되었습니다.

    참고로, 이 장치 제품군을 위한 기존 펌웨어 플래싱 라이브러리를 찾아서 사용했습니다. 하지만 제가 관심 없었던 몇 시간이고 몇 시간의 연구와 실험을 20분 만에 한 것이 정말 놀라웠습니다. 저는 그냥 WiFi 용암 램프를 원했을 뿐입니다.

  6. srcreigh

    > 아직 그렇게 용감하게 수정된 펌웨어를 실제로 써본 적은 없습니다. 꽤 비싼 모니터라서요. 하지만 언젠가는 하겠죠.

    솔직히 작동하는 패치가 없다면 실제로 소유한 것이 아닙니다.

    펌웨어를 안전하게 반복적으로 패치하는 방법을 더 잘 이해하고 싶습니다. 지난주에 부트 파티션에 TFTP 부팅 경로를 추가하려다 라우터를 벽돌로 만들었습니다. 그렇게 위험하다는 것이 정말 짜증납니다.

    또한 저렴한 장치라도 일부 펌웨어는 암호화되지 않은 상태로 제공되지 않고 플래시 읽기가 비활성화되어 있기 때문에 좋은 글리칭 도구도 필요합니다...

    우리는 아직 그 단계에 있지 않지만 곧 도달하기를 바랍니다.

  7. bobek

    솔직히 이것은 LLM에 대해 흥미로운 몇 안 되는 것 중 하나입니다. 저는 최근에 리버스 엔지니어링과 펌웨어 교체를 통해 오래된 버스의 플립-닷 패널을 부활시켰습니다 -- https://www.bobek.cz/buse/

  8. Retr0id

    LLM을 리버스 엔지니어링과 버그 사냥에 사용하는 것은 정말 재미있습니다. 오늘 저는 Google VRP에 정말 대단한 버그를 보고했습니다. 그 취약점은 소스가 없는 HTTP API 엔드포인트에 있었고, 리버스 엔지니어링된 클라이언트 로직만 있었습니다.

    버그의 아이디어는 제 것이었고, "설마 xyz를 잊을 만큼 어리석지는 않겠지"라는 종류였습니다. 취약점을 찾기 위한 코드를 손으로 작성하는 것은 protobuf 스키마 재구성 등을 포함하여 몇 시간의 노가다가 필요했을 것입니다. 과거에는 성공 확률이 너무 낮아 가치가 없다고 생각하여 시도조차 하지 않았을 것입니다. 하지만 한 문장짜리 프롬프트였으니 왜 안 되겠습니까? 그리고 효과가 있었습니다!

  9. teddyh

    핵심 요점:

    > WebUSB, WebHID, WebBluetooth의 존재는 일부 장치의 경우, 사용된 클래스의 특정 사항에 따라, 권한 프롬프트를 수락하는 사용자의 한 순간의 실수로 연결된 장치 중 하나에 영구적인 백도어를 설치할 수 있음을 의미합니다.

  10. Abishek_Muthian

    이쯤 되면 제조사들은 펌웨어를 오픈소스로 공개해야 합니다. 리버스 엔지니어링에 진입 장벽이 없기 때문입니다. 대신 버그를 무료로 고치는 데 시간과 토큰을 투자할 의향이 있는 최종 사용자 군대의 이점을 얻을 수 있을 것입니다.

이 날의 다른 글

2026-08-23