Ratchet은 LLM이 BIOS를 망치기 전 두 번 묻는다

메인보드의 BIOS 칩을 읽을 수 있는 AI 에이전트는 편리합니다. 하지만 그것을 지우고 다시 쓸 수 있다면 전혀 다른 범주의 도구가 됩니다. Ratchet이라는 새 GitHub 프로젝트는 이 둘을 모두 가능하다고 내세웁니다.

Ratchet이 할 수 있다고 주장하는 것

Ratchet은 거의 전부 Rust로 작성된, 처음부터 새로 만든 BIOS 및 SPI 플래시 프로그래밍 툴킷입니다. 내장 Model Context Protocol(MCP) 서버를 함께 제공해 AI 에이전트가 물리적인 칩 프로그래머를 직접 제어할 수 있게 합니다. GitHub 사용자 jackulau가 공개했으며 MIT 라이선스이고, 약 98.2%가 Rust인 것으로 보고됩니다 . 먼저 짚어야 할 중요한 단서가 있습니다. 이 저장소는 2026년 6월 기준 GitHub Releases가 아직 게시되지 않았다고 명시합니다. 따라서 태그된 버전도, 변경 로그도 없고, 아래 기능에 대한 독립적인 확인도 없습니다 .

에이전트 관점에서 핵심은 ratchet-mcp입니다. stdio 위에서 동작하는 수제 JSON-RPC 2.0 서버로, LLM이 호출할 수 있는 절차 30개를 노출합니다. 이 중 18개는 BIOS 및 SPI 플래시 분석용이고, 12개는 임베디드 하드웨어 프로토콜용이며, Claude Desktop과 다른 MCP 클라이언트에 연결하는 용도로 제시됩니다 . 하드웨어 쪽에서는 저렴한 USB 프로그래머 두 가지를 대상으로 합니다. CH341A(USB ID 1a86:5512)와 CH347(1a86:55db)이며, 3.3V와 1.8V 플래시 전압을 모두 지원한다고 합니다 .

이후 내용을 모두 이 맥락에서 읽어야 합니다. 기능 목록은 단일 자체 공개 README에 담긴 출시 전 주장입니다. 배포 바이너리도 없고, 제3자 리뷰도 없으며, GitHub 핸들 외에 검증된 게시자 신원도 없습니다. 아이디어 자체는 분명 흥미롭지만, 현재 근거는 한 저장소의 설명뿐입니다.

임베디드 툴체인을 하나로 묶기: flashrom부터 AVR, JTAG까지

Ratchet의 핵심 제안은 통합입니다. 이 분야에서 개발자들이 보통 따로 다루는 다섯 가지 유틸리티를 하나의 Rust 바이너리로 대체하겠다는 것입니다. BIOS/SPI 플래시용 flashrom, AVR 마이크로컨트롤러용 avrdude, ESP8266/ESP32용 esptool, STM32용 stm32flash, JTAG/SWD를 통한 ARM Cortex-M용 OpenOCD를 대체 대상으로 둡니다 . 차별점으로 내세우는 것은 구조입니다. Ratchet은 기존 바이너리를 셸로 호출하는 래퍼가 아니라, 이러한 흐름을 프로세스 안에서 완전히 네이티브 Rust로 다시 구현했다고 말합니다.

개발자에게 이 차이는 중요합니다. 래퍼는 호스트 환경의 Python/C 의존성 체인과 각 업스트림 도구의 특성을 그대로 물려받습니다. 반면 네이티브 재구현은 프로토콜 스택 전체를 직접 책임집니다. 대신 성숙도가 문제입니다. flashrom 문서는 627개가 넘는 플래시 칩, 407개 칩셋, 539개 메인보드, 94개 PCI 장치, 30개 USB 장치를 지원한다고 나열하며, 이 지원 범위는 수년에 걸쳐 독립적으로 유지되어 왔습니다 . Ratchet은 Winbond, Macronix, GigaDevice를 아우르는 806개 칩 데이터베이스를 홍보합니다 . 플래시 칩 수만 보면 더 크지만, 그 숫자는 단일 README에서 나온 것이며 해당 항목들이나 대체 대상으로 든 다섯 도구의 전체 기능이 대규모로 작동한다는 공개 통합 테스트나 벤치마크는 없습니다.

단일 바이너리라는 이야기는 실제로 매력적입니다. 도구마다 Python virtualenv를 만들 필요가 없고, 컴파일용 C 툴체인도 필요 없으며, avrdude와 esptool 설치 버전이 서로 어긋날 일도 줄어듭니다. 임베디드 작업에서는 실제로 골치 아픈 지점입니다. 다만 지금으로서는 검증되지 않은 주장입니다. 이를 뒷받침하는 배포 릴리스나 제3자 리뷰가 없습니다.

오른쪽 열은 검증된 지원 범위가 아니라 목표로 읽어야 합니다. flashrom의 매트릭스는 실제 하드웨어 전반에서 수년간 이어진 커뮤니티 테스트의 결과입니다. Ratchet의 범위는 한 저장소에서 주장한 통합 목표입니다. 설계 방향은 유망하지만, 현장에서는 아직 입증되지 않았습니다.

호출 가능한 BIOS 절차 30개: LLM이 프로그래머와 연결되는 방식

Ratchet은 ratchet-mcp를 통해 LLM을 프로그래머에 연결한다. ratchet-mcp는 직접 만든 JSON-RPC 2.0 서버로, stdio로 통신하며 호출 가능한 도구 30개를 노출한다. 이 중 18개는 SPI 플래시/BIOS 작업용이고, 12개는 하드웨어 프로토콜용이다 . Claude Desktop 같은 MCP 클라이언트는 이 서버를 하위 프로세스로 실행하고, 서버가 공개한 도구 스키마를 읽은 뒤, 모델이 셸 명령 대신 구조화된 호출로 칩 작업을 실행하게 한다. Model Context Protocol은 Anthropic이 2024년 11월 25일 어시스턴트를 외부 도구와 데이터에 연결하기 위해 발표한 개방형 표준이므로 , 하드웨어 대상이 이례적일 뿐 아키텍처 자체는 통상적이다.

한 가지 설계 선택은 따져볼 필요가 있다. 이 서버는 공식 MCP SDK 위에 만든 것이 아니라 직접 구현한 것이다 . 따라서 스펙 준수에 대한 의문이 생긴다. 표준 초기화 핸드셰이크, 기능 협상, 오류 엔벌로프, 알림 시맨틱을 전제로 하는 클라이언트라면 레퍼런스 SDK가 처리했을 법한 엣지 케이스에 부딪힐 수 있다. 되돌릴 수 없는 쓰기를 실행하는 도구에서 프로토콜 드리프트는 겉모양 문제가 아니다. 잘못 형식화된 확인이나 누락된 오류 응답 하나가 거부된 호출과 벽돌이 된 보드를 가르는 차이가 된다.

SPI 플래시 하위 집합은 전체 읽기-수정-쓰기 생명주기를 포괄한다. 저장소에 나열된 18개 절차는 다음과 같다.

• 검사: status, detect, identify, blank-check, sfdp(Serial Flash Discoverable Parameters), wp-status(쓰기 보호 상태)
• 데이터 이동: read, write, verify
• 삭제 및 복구: erase, region-erase, full-repair, full-backup

하드웨어 프로토콜 하위 집합은 I2C, UART, 1-Wire, 수동 SPI 스니핑, JTAG, SWD, CAN에 걸친 도구 12개를 추가하며, 대상 MCU 계열에는 AVR, STM32, ESP8266/ESP32, ARM Cortex-M이 포함된다 . 이는 MCP를 일반적인 소프트웨어와 데이터 영역 너머로 밀어 올려, 디버그 어댑터와 버스 트래픽을 직접 감독하는 영역까지 확장한다. 엔지니어라면 보통 OpenOCD나 로직 애널라이저로 접근하던 바로 그 표면이다.

유용하게도 모든 절차는 모의 백엔드에서 실행할 수 있으므로, 개발자는 실제 프로그래머를 연결하지 않고도 칩 식별, 백업, 분석, 재플래시로 이어지는 에이전트 세션을 스크립트로 만들고 드라이런할 수 있다 . 같은 패턴은 관계없는 선행 사례에서도 보인다. Tony Loehr의 platformio-mcp는 PlatformIO Core 위에서 MCP 도구 9개를 노출해 약 1,000개 보드에 대한 컴파일과 업로드를 수행한다 . 이는 에이전트 주도 플래싱이 일회성 아이디어가 아니라 이미 인식된 패턴임을 확인해준다. Ratchet이 다른 점은 그 도구가 SPI 칩 자체까지 닿는다는 데 있다. 잘못된 erase 한 번에는 되돌리기가 없다.

물리 프로그래머에서 LLM이 erase()를 호출할 때

메인보드 BIOS 칩을 지우거나 덮어쓰는 일은 물리적으로 되돌릴 수 없다. 삭제 사이클이 완료되면 소프트웨어 롤백도, 실행 취소 경로도 없다. SPI 플래시의 바이트는 사라지고, 복구 가능성은 검증된 백업이 있는지 또는 보드에 하드웨어 복구 모드가 있는지에 전적으로 달려 있다. 이것이 Ratchet의 erase, region-erase, write 도구와 detect나 sfdp 같은 읽기 전용 도구를 가르는 선이다. 전자는 명령이 CH341A나 CH347에 도달하는 순간 에이전트의 손이 닿지 않는 곳의 상태를 바꾼다 .

이 위험은 이론이 아니다. 2018년 5월 발행된 Platform Firmware Resiliency Guidelines인 NIST SP 800-193은 플랫폼 펌웨어를 시스템 신뢰성의 핵심으로 규정하며, 성공적인 플랫폼 펌웨어 공격은, 더 넓게 보면 파괴적인 쓰기 역시, “시스템을 작동 불능으로 만들 수 있으며, 어쩌면 영구적으로 그렇게 만들거나 원 제조사의 재프로그래밍을 필요로 할 수 있다”고 경고한다 . 이 문서는 그런 작업을 무결성과 진정성 검사를 통해 보호되는, 의도적이고 승인되었으며 감사 가능한 인간의 행위로 다룬다. 같은 엔드포인트를 자율 LLM이 구동하면 그 전제가 뒤집힌다.

"A successful attack on system platform firmware... could render a system inoperable, perhaps permanently, or requiring reprogramming by the original manufacturer." — NIST SP 800-193, Platform Firmware Resiliency Guidelines (source: NIST, 2018-05)

에이전트가 만들어내는 구체적인 실패 양상은 의도적인 인간 행동을 자동화된 행동으로 바꿔버리는 것이다. 모델이 칩 ID를 환각하거나, 호출을 잘못된 영역으로 보내거나, 모의 백엔드를 대상으로 한다고 생각했는데 실제 프로그래머에 erase를 실행하면 결과는 스택 트레이스가 아니라 물리 하드웨어 손실이다. 잡아낼 예외는 없다. 이 분야의 기존 도구들은 이미 이런 주의를 코드화해두고 있다. flashrom 문서는 노트북에서 플래시하지 말라고 명시적으로 경고한다. 임베디드 컨트롤러가 플래시 칩 통신과 나쁘게 상호작용해 장치를 벽돌로 만들 수 있기 때문이다 . 그 경고는 매뉴얼을 읽는 인간 작업자를 대상으로 한다. LLM을 포함한 감독 없는 자동 플래싱 경로는 인간의 상황 판단에 따른 멈춤 없이 같은 위험을 그대로 물려받는다. flashrom 매뉴얼은 쓰기 전에 플래시 칩을 백업하라고도 지시한다. 인간은 그 단계를 의도적으로 건너뛸 수 있지만, 에이전트는 도구가 강제하지 않는 한 조용히 건너뛴다. 다음 절에서는 바로 그 강제 문제를 살펴본다.

확인 게이트와 백업 의무화: Ratchet이 파괴적 호출 전에 하는 일

조용히 진행되는 에이전트의 파괴적 동작에 대해 Ratchet은 여러 겹의 안전장치로 대응한다. README에 따르면 쓰기나 삭제가 칩에 도달하기 전에 이 장치들이 먼저 작동한다. 저장소는 쓰기 전 자동 칩 백업, 각 쓰기 후 읽기 검증, 쓰기 보호 가드, 빈 이미지 감지, 그리고 파괴적 도구 호출이 진행되기 전에 명시적 확인을 요구하는 "MCP confirm gates"를 listed한다 . 이 장치들의 목적은 사람이 건너뛸 수 있는 백업 단계를 에이전트가 우회할 수 없는 기본값으로 강제하는 데 있다.

각 가드는 특정 실패 모드에 대응한다. 자동 백업은 기존 플래시 이미지를 캡처해 잘못된 재플래시가 치명적인 실패로 끝나지 않고 복구 가능하도록 한다. 이는 NIST SP 800-193이 안전한 복구를 설명할 때 드는 예방책과도 맞닿아 있다. 펌웨어 손상이 성공하면 시스템이 작동 불능이 되거나 제조사 재프로그래밍이 필요할 수 있기 때문이다 . 읽기 검증은 실제로 기록된 내용과 의도한 내용을 비교한다. 빈 이미지 감지는 데이터가 들어 있는 칩을 빈 데이터로 덮어써 보드를 벽돌로 만드는 흔한 상황을 막는다. 파괴적 호출 전에 쓰기 보호 상태를 조회하고, 확인 게이트는 LLM이 실제 CH341A 또는 CH347을 대상으로 erase나 write를 호출하기 전에 명시적인 사람의 승인을 강제한다 .

단서는 피할 수 없다. 이 모든 가드는 기능을 나열한 것과 같은 선공개 README에서 자체적으로 설명한 내용이다. 저장소에는 GitHub Releases가 게시되어 있지 않다고 되어 있으므로, 태그가 붙은 버전도, 공개된 테스트 하니스도, 적대적이거나 잘못 구성된 에이전트 입력 아래에서 확인 게이트와 백업이 문서대로 동작하는지 검증한 제3자 보안 리뷰도 없다 . 주장된 안전장치와 감사된 안전장치는 같은 것이 아니다.

중요한 대상에 이 도구를 신뢰하기 전에 최소한 다음은 평가해야 한다:

• 폐기 가능한 보드에서 자동 백업이 실제로 생성되고 복원 가능한지 확인한다.
• 전체 mock-backend dry-run을 실행해 실제 하드웨어가 건드려지지 않는지 확인한다.
• 쓰기 보호 동작을 수동으로 검증한다. 보호된 칩이 주장대로 쓰기를 거부해야 한다.
• 확인 게이트 우회 경로를 스트레스 테스트한다: 잘못된 JSON-RPC 호출, 반복 도구 호출, 명시적 승인 없이 erase에 도달할 수 있는 모든 코드 경로.

이 게이트들은 출시된 안전 보장이 아니라 검증할 가치가 있는 설계 의도로 봐야 한다.

Ratchet과 flashrom: 주장된 범위와 독립 문서의 차이

flashrom의 지원 범위는 독립적으로 문서화되어 있고 커뮤니티에서 시험되어 왔다. Ratchet의 범위는 공개된 테스트 증거가 없는 단일 저장소의 주장이다. flashrom 자체 문서는 627개 이상의 플래시 칩, 407개 칩셋, 539개 메인보드, 94개 PCI 장치, 30개 USB 장치를 지원한다고 listing한다 . 이는 약 20년에 걸친 공개 기여 이력의 뒷받침을 받는다. Ratchet은 Winbond, Macronix, GigaDevice 같은 벤더를 포함하는 806칩 데이터베이스를 홍보한다 . 그러나 저장소에는 태그 릴리스도, changelog도, 칩별 테스트 로그도 없으므로 더 큰 숫자는 검증된 결과라기보다 개발자의 주장에 가깝다.

프로덕션 워크플로에서는 격차가 더 커진다. flashrom은 원격 SSH 재플래시와 동일한 머신 풀을 대상으로 하는 스크립트 기반 재플래시를 확립된 반복 가능 관행으로 문서화한다 . Ratchet도 MCP 레이어를 통해 같은 fleet-maintenance 용례를 지향하지만, 이런 흐름을 어떤 규모로든 실행했다는 공개 증거는 없다. 사례 연구도, 기여자 보고도, 제3자 재현도 없다.

LLM 기반 플래싱 패턴 자체가 Ratchet에서 처음 나온 것은 아니다. Tony Loehr의 platformio-mcp(v2.0.0, 2024년 5월)는 PlatformIO Core를 감싸 에이전트가 9개의 MCP 도구를 통해 약 1,000개 보드와 30개 이상의 플랫폼에서 컴파일, 업로드, 모니터링할 수 있게 한다 . Ratchet과는 무관하지만, 임베디드 플래싱을 MCP 절차로 노출하는 방식이 이 프로젝트보다 앞서 있었다는 점을 보여준다. Ratchet의 차별점은 에이전트 제어 아이디어가 아니라 네이티브 Rust 재구현과 직접 SPI/BIOS 접근이다.

공정하게 읽으면 이렇다. flashrom은 수치에 독립적 무게가 실린 성숙한 기준선이고, Ratchet의 더 넓은 범위와 에이전트 네이티브 레이어는 아직 선공개 단계의 주장으로 남아 있다. 둘을 비교하는 사람은 806칩 지원과 여섯 도구 대체라는 수치를, 릴리스나 기여자 로그 또는 제3자 리뷰가 이를 뒷받침하기 전까지는 검증되지 않은 것으로 다뤄야 한다 .

누가 먼저 써봐야 하며 무엇부터 확인해야 할까

Ratchet의 현실적인 초기 사용자는 펌웨어 수리 기술자, 하드웨어 랩 운영자, 에이전트 기반 플래싱 워크플로를 평가하는 임베디드 개발자입니다. 프로덕션 IT 장비군 관리자가 아닙니다. 이유는 구조적입니다. 이 프로젝트는 단일 자체 공개 저장소에서 배포되며, 태그가 붙은 릴리스도, 변경 로그도, 제3자 리뷰도 없습니다 . 폐기 가능한 하드웨어에서 벤치 실험을 하는 데는 받아들일 수 있지만, 잘못된 삭제나 쓰기로 보드를 동작 불능으로 만들거나 제조사 재프로그래밍이 필요해질 수 있는 BIOS 유지보수 자동화의 기반으로 삼기에는 부족합니다 .

실제 칩을 대상으로 작업하기 전에는 두 가지를 먼저 확인하세요. 첫째, Winbond, Macronix, GigaDevice 또는 다른 벤더의 정확한 부품 번호가 Ratchet의 806개 칩 데이터베이스에 실제로 들어 있는지 확인해야 합니다. 통합 지원 범위에 포함될 것이라고 가정하지 마세요 . 둘째, 에이전트가 대체 불가능한 장치를 건드리기 전에, 버려도 되는 보드에서 백업과 복원 루프를 예행연습하고 읽어낸 이미지가 실제로 동작하는 이미지를 재현하는지 검증하세요.

이를 기존 펌웨어 관행에 맞춰 평가하려는 팀이라면, NIST SP 800-193이 에이전트 기반 구성에 적용할 수 있는 구체적인 점검 목록을 제공합니다 :

• 무결성: 쓰기 이후뿐 아니라 쓰기 전에 서명된 펌웨어를 검증합니다.
• 변경 감지: 플래시 영역의 승인되지 않았거나 예상 밖인 수정을 표시합니다.
• 감사 로그: LLM이 시작한 모든 삭제 또는 쓰기 작업을 개별적이고 추적 가능한 이벤트로 기록합니다.
• 하드웨어 허용 목록: 에이전트가 대상으로 삼을 수 있는 프로그래머와 칩 ID를 내장합니다.

프로덕션 사용을 검토하기 전에는 세 가지 신호를 지켜볼 필요가 있습니다. 버전 번호가 붙은 Ratchet의 첫 태그 릴리스, 주장하는 칩 지원 범위와 대체한다고 말하는 여섯 가지 도구에 대한 독립 감사, 그리고 에이전트와 파괴적 호출 사이에 놓인 confirm-gate 구현에 대한 공개 보안 리뷰입니다 . 그것들이 나오기 전까지 결론은 단순합니다. Ratchet은 잃어도 되는 하드웨어에서 신중히 탐색할 만한 유망한 벤치 도구로 다루세요. 인프라로 보아서는 안 됩니다.

마지막 업데이트: 2026-06-26. 게시 시점에 이용 가능한 프로젝트 저장소와 NIST SP 800-193 지침을 기준으로 검토했습니다.

자주 묻는 질문

Ratchet은 무엇이며, 지금 실제 하드웨어에서 써도 안전한가요?

Ratchet은 거의 전부 Rust로 작성된 처음부터 새로 만든 BIOS/SPI 플래시 및 하드웨어 디버깅 툴킷입니다(보고 기준 약 98.2%, MIT 라이선스). AI 에이전트가 물리적 칩 프로그래머를 구동할 수 있도록 MCP 서버를 함께 제공합니다 . 표준 릴리스 기준으로는 프로덕션 준비가 되어 있지 않습니다. 저장소에는 아직 GitHub Releases가 게시되지 않았다고 명시되어 있어, 태그된 버전, 변경 로그, 독립 검증이 없습니다 . 폐기 가능한 하드웨어에서 랩 및 평가 용도로만 제한하세요. README에 따르면 confirm gate는 존재하지만, 아직 감사를 거치지 않았습니다.

Ratchet은 flashrom과 어떻게 다른가요?

핵심 차이는 에이전트 인터페이스입니다. Ratchet은 LLM이 칩 작업을 직접 호출할 수 있게 하는 MCP stdio 계층을 추가하지만, flashrom에는 LLM 통합이 없습니다. flashrom은 성숙하고 커뮤니티 검증을 거친 도구로, 오랜 기여자 이력을 바탕으로 627개가 넘는 플래시 칩, 407개 칩셋, 539개 메인보드 지원을 문서화하고 있습니다 . Ratchet은 Winbond, Macronix, GigaDevice 같은 벤더를 아우르는 806개 칩 데이터베이스를 주장하지만, 아직 프리릴리스이며 검증되지 않았습니다 . flashrom은 문서화된 기준선으로, Ratchet의 더 넓은 범위는 개발자 주장으로 보는 편이 맞습니다.

LLM이 Ratchet을 통해 자율적으로 메인보드를 벽돌로 만들 수 있나요?

원칙적으로는 가능합니다. 다만 confirm gate가 우회되거나 잘못 설정된 경우입니다. 설계 의도는 각 파괴적 도구 호출(삭제, 쓰기, 영역 삭제)에 대해 “MCP confirm gates”를 통한 명시적 사용자 확인을 요구하고, 자동 사전 쓰기 백업과 읽기 검증을 함께 수행하는 것입니다 . 근본적인 위험은 실제입니다. NIST SP 800-193은 성공적인 플랫폼 펌웨어 공격이 시스템을 영구적일 수도 있는 동작 불능 상태로 만들거나 제조사의 재프로그래밍을 필요하게 할 수 있다고 경고합니다 . 이러한 보호 장치에 대한 독립 감사는 아직 공개되지 않았습니다.

CH341A USB 프로그래머는 무엇이며, Ratchet은 왜 이를 대상으로 하나요?

CH341A는 저렴한(약 5~10달러) USB-SPI/I2C 브리지(USB ID 1a86:5512)로, BIOS 칩 프로그래밍과 복구를 위해 펌웨어 수리 커뮤니티에서 널리 쓰입니다. Ratchet은 이를 주요 물리 프로그래머로 삼고 있으며, 더 빠른 후속 제품인 CH347(USB ID 1a86:55db)도 함께 대상으로 합니다. 3.3V와 1.8V 플래시를 모두 지원합니다 . 이런 프로그래머는 흔하고 저렴하기 때문에, 단일 바이너리 뒤에 SPI 플래시 워크플로를 통합하려는 도구의 자연스러운 하드웨어 대상입니다.

Ratchet은 JTAG 및 SWD 디버깅에서 OpenOCD를 대체하나요?

현재 증거만으로는 그렇지 않습니다. Ratchet은 12개의 하드웨어 프로토콜 MCP 도구 중 하나로 ARM Cortex-M JTAG/SWD 지원을 주장하며, I2C, UART, 1-Wire, 수동 SPI 스니핑, CAN도 함께 내세웁니다 . 하지만 OpenOCD는 여러 해 동안 커뮤니티 테스트를 거친 MCU 지원을 갖추고 있고, Ratchet의 JTAG/SWD 경로는 프리릴리스이며 검증되지 않았습니다. OpenOCD 대신 의존하기 전에 특정 대상 MCU를 기준으로 평가하세요. 네이티브 Rust 재구현은 도구 난립을 줄일 수 있지만, 성숙도와 폭에서는 여전히 검증된 도구가 우세합니다.