Ratchet asks twice before an LLM bricks your BIOS

An AI agent that can read your motherboard's BIOS chip is convenient. One that can erase and rewrite it is a different category of tool. A new GitHub project called Ratchet puts both on the table.

What Ratchet Claims to Do

Ratchet is a from-scratch BIOS and SPI-flash programming toolkit written almost entirely in Rust that ships with a built-in Model Context Protocol (MCP) server, so AI agents can drive a physical chip programmer directly. It is published on GitHub by the user jackulau, MIT-licensed, and reported as roughly 98.2% Rust . The important caveat up front: the repository explicitly states that no GitHub Releases have been published as of June 2026, so there is no tagged version, no changelog, and no independent confirmation of any feature below .

The headline for an agent audience is ratchet-mcp, a hand-rolled JSON-RPC 2.0 server over stdio that exposes 30 LLM-callable procedures — 18 for BIOS and SPI-flash analysis, and 12 for embedded hardware protocols — intended to plug into Claude Desktop and other MCP clients . On the hardware side, it targets two inexpensive USB programmers: the CH341A (USB ID 1a86:5512) and the CH347 (1a86:55db), with support for both 3.3V and 1.8V flash voltages .

Read everything that follows in that light. The capability list is a set of pre-release assertions from a single self-published README — no shipping binary, no third-party review, and no verified publisher identity beyond the GitHub handle. The idea is genuinely interesting; the evidence is, for now, one repository's word.

Consolidating Embedded Toolchains: From flashrom to AVR to JTAG

Ratchet's core pitch is consolidation: a single Rust binary that claims to replace five separate utilities developers normally juggle across this domain. It positions against flashrom for BIOS/SPI flash, avrdude for AVR microcontrollers, esptool for ESP8266/ESP32, stm32flash for STM32, and OpenOCD for ARM Cortex-M over JTAG/SWD . The distinguishing claim is architectural: Ratchet says it is a fully native Rust reimplementation of these flows in-process, not a wrapper that shells out to existing binaries.

That distinction matters for developers. A wrapper inherits the host environment's Python/C dependency chain and the quirks of each upstream tool; a native reimplementation owns the protocol stack end to end. The trade-off is maturity. flashrom's documentation lists support for more than 627 flash chips, 407 chipsets, 539 mainboards, 94 PCI devices, and 30 USB devices, all independently maintained over years . Ratchet advertises a chip database of 806 chips spanning Winbond, Macronix, and GigaDevice — a larger flash-chip count, but one number from a single README with no published integration test or benchmark confirming that those entries, or the five displaced tools' full feature sets, work at scale.

The single-binary story is the practical draw: no per-tool Python virtualenvs, no C toolchain to compile, no version skew between avrdude and esptool installs. That is a real pain point in embedded work. It is also, for now, an unverified claim — there is no shipping release or third-party review behind it.

Read the right column as intent, not verified coverage. flashrom's matrix is the product of years of community testing across real hardware; Ratchet's is a consolidated scope asserted in one repository. Promising in design, unproven in the field.

30 Callable BIOS Procedures: How LLMs Connect to the Programmer

Ratchet connects an LLM to the programmer through ratchet-mcp, a hand-rolled JSON-RPC 2.0 server that talks over stdio and exposes 30 callable tools — 18 for SPI-flash/BIOS work and 12 for hardware protocols . An MCP client such as Claude Desktop launches the server as a subprocess, reads its advertised tool schemas, and lets the model invoke chip operations as structured calls instead of shell commands. Model Context Protocol is the open standard Anthropic introduced on November 25, 2024 for wiring assistants to external tools and data , so the architecture is conventional even if the hardware target is not.

One design choice deserves scrutiny: the server is hand-rolled rather than built on an official MCP SDK . That raises spec-conformance questions — clients that assume standard initialization handshakes, capability negotiation, error envelopes, or notification semantics may hit edge cases a reference SDK would have handled. For a tool that issues irreversible writes, protocol drift is not cosmetic; a malformed confirmation or dropped error response is the difference between a refused call and a bricked board.

The SPI-flash subset covers the full read-modify-write lifecycle. The 18 procedures, as listed in the repository, are:

• Inspection: status, detect, identify, blank-check, sfdp (Serial Flash Discoverable Parameters), wp-status (write-protect status)
• Data movement: read, write, verify
• Erase and repair: erase, region-erase, full-repair, full-backup

The hardware-protocol subset adds 12 more tools spanning I2C, UART, 1-Wire, passive SPI sniffing, JTAG, SWD, and CAN, with target MCU families including AVR, STM32, ESP8266/ESP32, and ARM Cortex-M . That pushes MCP beyond its usual software-and-data territory into direct supervision of debug adapters and bus traffic — the same surface an engineer would otherwise reach through OpenOCD or a logic analyzer.

Usefully, every procedure can run against a mock backend, so a developer can script and dry-run an agent session — chip identification, backup, analysis, reflash — with no physical programmer attached . The same pattern appears in unaffiliated prior art: Tony Loehr's platformio-mcp exposes 9 MCP tools over PlatformIO Core to compile and upload across roughly 1,000 boards , confirming agent-driven flashing is a recognized pattern rather than a one-off. What separates Ratchet is that its tools reach the bare SPI chip, where a stray erase has no undo.

An LLM Calling erase() on a Physical Programmer

Erasing or overwriting a motherboard BIOS chip is physically irreversible: once an erase cycle completes, there is no software rollback and no undo path. The bytes on the SPI flash are gone, and recovery depends entirely on whether a verified backup exists or whether the board has a hardware recovery mode. This is the dividing line between Ratchet's erase, region-erase, and write tools and the read-only ones like detect or sfdp — the former mutate state that lives outside the agent's reach the instant the command lands on the CH341A or CH347 .

The risk is not theoretical. NIST SP 800-193, the Platform Firmware Resiliency Guidelines published in May 2018, frames platform firmware as critical to system trustworthiness and warns that a successful platform-firmware attack — or, by extension, a destructive write — "can render a system inoperable, perhaps permanently, or require reprogramming by the original manufacturer" . That document treats such operations as deliberate, authorized, audited human actions guarded by integrity and authenticity checks. An autonomous LLM driving the same endpoints inverts that assumption.

"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)

The specific failure mode an agent introduces is converting a deliberate human action into an automated one. A model that hallucinates a chip ID, misroutes a call to the wrong region, or fires erase against a live programmer when it meant the mock backend produces physical hardware loss, not a stack trace. There is no exception to catch. The established tooling in this space already encodes this caution: flashrom's documentation explicitly warns users not to flash on laptops, because embedded controllers can interact badly with flash-chip communication and brick the machine . That warning targets a human operator reading the manual. Any unsupervised automated flashing path — an LLM included — inherits the same hazard with none of the human's situational pause. flashrom's manual also instructs users to back up the flash chip before writing, a step a human can skip deliberately but an agent will skip silently unless the tool enforces it. That enforcement question is what the next section examines.

Confirm Gates and Backup Mandates: What Ratchet Does Before Destructive Calls

Ratchet's answer to silent agent destruction is a layered set of guardrails the README says fire before any write or erase reaches the chip. The repository lists automatic chip backups before writes, read-back verification after each write, write-protection guards, blank-image detection, and "MCP confirm gates" that require explicit confirmation before a destructive tool call proceeds . Together they aim to make the backup step the human could skip an enforced default the agent cannot bypass.

Each guard maps to a specific failure mode. Automatic backup captures the existing flash image so a botched reflash is recoverable rather than terminal — the same precaution NIST SP 800-193 frames around secure recovery, since a successful firmware corruption can render a system inoperable or require manufacturer reprogramming . Read-back verification compares what was written against what was intended. Blank-image detection blocks overwriting a populated chip with empty data, a common way to brick a board. Write-protection status is queried before the destructive invocation, and the confirm gate forces an explicit human acknowledgment before an LLM can call erase or write against a live CH341A or CH347 .

The caveat is unavoidable: every one of these guards is self-reported in the same pre-release README that lists the capabilities. The repository states no GitHub Releases are published, so there is no tagged version, no published test harness, and no third-party security review confirming the confirm gates and backups behave as documented under adversarial or malformed agent input . Claimed guardrails and audited guardrails are not the same thing.

Before trusting this on anything you care about, a minimum evaluation checklist:

• Confirm an automatic backup is actually produced and restorable on a disposable board.
• Run a full mock-backend dry-run and confirm no live hardware is touched.
• Manually verify write-protection behavior — that a protected chip refuses writes as claimed.
• Stress-test confirm-gate bypass paths: malformed JSON-RPC calls, repeated tool invocations, and any code path that could reach erase without an explicit acknowledgment.

Treat the gates as design intent worth verifying, not as a shipped safety guarantee.

Ratchet and flashrom: Claimed Coverage vs Independent Documentation

flashrom's coverage is independently documented and community-tested; Ratchet's is a single-repository claim with no published test evidence. flashrom's own documentation lists support for more than 627 flash chips, 407 chipsets, 539 mainboards, 94 PCI devices, and 30 USB devices , backed by a public contributor history spanning roughly two decades. Ratchet advertises a larger 806-chip database covering vendors such as Winbond, Macronix, and GigaDevice , but the repository ships no tagged release, no changelog, and no per-chip test log, so the higher number is a developer assertion rather than a verified result.

The gap widens on production workflows. flashrom documents remote SSH reflashing and scriptable reflashing of pools of identical machines as established, repeatable practices . Ratchet aspires to the same fleet-maintenance use cases through its MCP layer, yet there is no published evidence it has run those flows at any scale — no case study, no contributor reports, no third-party reproduction.

The LLM-driven flashing pattern itself is not new to Ratchet. Tony Loehr's platformio-mcp (v2.0.0, May 2024) wraps PlatformIO Core so agents can compile, upload, and monitor across roughly 1,000 boards and 30+ platforms via 9 MCP tools . It is unaffiliated with Ratchet, but it demonstrates that exposing embedded flashing through MCP procedures predates this project — Ratchet's distinction is native-Rust reimplementation and direct SPI/BIOS reach, not the agent-control idea.

The fair reading: flashrom is a mature baseline whose numbers carry independent weight, while Ratchet's broader scope and agent-native layer remain pre-release claims. Anyone weighing the two should treat the 806-chip and six-tool-replacement figures as untested until a release, a contributor log, or a third-party review exists to corroborate them .

Who Should Pilot This and What to Examine First

The realistic early adopters for Ratchet are firmware repair technicians, hardware lab operators, and embedded developers evaluating agentic-flashing workflows — not production IT fleet administrators. The reason is structural: the project ships from a single self-published repository with no tagged release, no changelog, and no third-party review . That is acceptable for a bench experiment on disposable hardware; it is not the basis for automating a fleet's BIOS maintenance, where a faulty erase or write can render a board inoperable or require manufacturer reprogramming .

Before any live-chip session, do two things. First, confirm your exact part number — Winbond, Macronix, GigaDevice, or another vendor — actually appears in Ratchet's 806-chip database rather than assuming the consolidated scope covers it . Second, rehearse the backup-and-restore loop on a known-disposable board, verifying that a read-back actually reproduces a working image, before you let an agent touch anything you cannot replace.

For teams that map this against established firmware practice, NIST SP 800-193 offers a concrete checklist to apply to an agent-driven setup :

• Integrity: validate signed firmware before any write, not just after.
• Change detection: flag unauthorized or unexpected modifications to the flash region.
• Audit log: record every LLM-initiated erase or write as a discrete, attributable event.
• Hardware allowlists: bake in which programmers and chip IDs the agent may target.

Three signals are worth watching before anyone considers production use: the first tagged Ratchet release with a version number, an independent audit of the claimed chip coverage and the six tools it says it replaces, and a published security review of the confirm-gate implementation that stands between an agent and a destructive call . Until those exist, the concrete takeaway is simple: treat Ratchet as a promising bench tool to explore deliberately on hardware you can afford to lose — not as infrastructure.

Last updated: 2026-06-26. Reviewed against the project repository and NIST SP 800-193 guidance available at publication.

Frequently asked questions

What is Ratchet, and is it safe to use on real hardware today?

Ratchet is a from-scratch BIOS/SPI-flash and hardware-debugging toolkit written almost entirely in Rust (reported ~98.2%, MIT-licensed) that ships an MCP server so AI agents can drive a physical chip programmer . It is not production-ready by standard release criteria: the repository states no GitHub Releases are published yet, so there is no tagged version, changelog, or independent verification . Confine it to lab and evaluation use on disposable hardware. Its confirm gates exist per the README but remain unaudited.

How is Ratchet different from flashrom?

The core difference is the agent interface: Ratchet adds an MCP stdio layer letting an LLM invoke chip operations directly, while flashrom has no LLM integration. flashrom is mature and community-verified, documenting support for more than 627 flash chips, 407 chipsets, and 539 mainboards over a long contributor history . Ratchet claims a 806-chip database spanning vendors like Winbond, Macronix, and GigaDevice, but it is pre-release and unverified . Treat flashrom as the documented baseline and Ratchet's wider scope as developer claims.

Can an LLM autonomously brick a motherboard through Ratchet?

In principle, yes — but only if the confirm gates are bypassed or misconfigured. The design intent is that each destructive tool call (erase, write, region-erase) requires explicit user confirmation through "MCP confirm gates," alongside automatic pre-write backups and read-back verification . The underlying risk is real: NIST SP 800-193 warns that successful platform-firmware attacks can render a system inoperable, perhaps permanently, or require reprogramming by the manufacturer . No independent audit of these guardrails has been published.

What is a CH341A USB programmer, and why does Ratchet target it?

The CH341A is a cheap (~$5–10) USB-to-SPI/I2C bridge (USB ID 1a86:5512) widely used in firmware-repair communities for BIOS chip programming and recovery. Ratchet targets it as a primary physical programmer, along with the higher-speed CH347 successor (USB ID 1a86:55db), supporting both 3.3V and 1.8V flash . These programmers are ubiquitous and inexpensive, which makes them the natural hardware target for a tool aiming to consolidate SPI-flash workflows behind a single binary.

Does Ratchet replace OpenOCD for JTAG and SWD debugging?

Not on current evidence. Ratchet claims ARM Cortex-M JTAG/SWD coverage among its 12 hardware-protocol MCP tools, alongside I2C, UART, 1-Wire, passive SPI sniffing, and CAN . But OpenOCD has years of community-tested MCU support, and Ratchet's JTAG/SWD path is pre-release and unverified. Evaluate it against your specific target MCU before relying on it over OpenOCD — the native-Rust reimplementation may reduce tool sprawl, but maturity and breadth still favor the established tool.