The AI firmware security engineer

Make the silicon prove it.

Learn the hardware. Break the firmware. Prove it on silicon. Ruptor captures how a real chip behaves, builds an executable model of it with AI-assisted synthesis, fuzzes your firmware against that model at software speed, and replays findings on the physical chip.

See a run See a finding
└─ CVE-2026-37535 · found by the fuzzer at run 52,589 · replayed on F446 · MemManage fault · hardware-confirmed · 0x0451
capture → fuzz → replay on silicon  ·  currently bare-metal Cortex-M 3 public CVEs  rediscovered · all 3 replayed on F446 silicon
Ground truth

Capture the real device once. Fuzz its firmware against it.

Inside a run

From a firmware build to a finding reproduced on the chip.

Ruptor fuzzes the firmware in software, against a model captured from the chip, with no board on the desk. Every crash arrives deduplicated, mapped to a CWE and tied to the interface that reached it.

Ruptor console fuzzing isotp-c on the captured STM32F446 model: the coverage curve flattens, 3,504 executions, 284 coverage edges, one out-of-bounds write found at 15.6 seconds, with the engine log and run settings.

A crash in a model is just a question.
We made the chip reproduce it.

Scanners never run your code, so they hand you maybes. Inference fuzzers do run it, but against a model of the peripherals inferred from the firmware or the datasheet, so they can flag states the device never reaches and miss bugs that depend on real hardware. Our model is observed from silicon, not inferred: we capture the chip, fuzz the firmware against that model, and replay the finding on the physical chip. Our fuzzer independently rediscovered three public CVEs in third-party code, and we replayed all three on a real STM32F446.

  1. CVE-2026-37535 isotp-c, out-of-bounds write
  2. found by the fuzzer run 52,589, unaided
  3. replayed on STM32F446, MPU guard harness
  4. chip fault MemManage · DACCVIOL ✓
Reproduce it yourself github.com/ruptorhq/benchmark 
$ git clone https://github.com/ruptorhq/benchmark
$ python replay/run_hw_isotp.py
finding      isotp-c CVE-2026-37535 (OOB write)
CFSR         0x00000082   DACCVIOL=1  MMARVALID=1
MMFAR        0x20000080   in guard=True
T2 VALIDATED  the fuzzer-found OOB faults precisely at the guard on real F446 silicon

Three public CVEs, pristine upstream libraries, the harnesses and the replay scripts. Apache-2.0. A $15 NUCLEO-F446RE and ten minutes.

Physical evidence Physical consequences demand physical evidence. Firmware runs the physical world, so we reproduce what actually happens on the device, not what a model assumes.

How a run works

Capture on hardware. Fuzz in software. Replay on the chip.

Fuzz without tying up your hardware: after one capture, fuzzing runs in software; the board is needed only for capture and to validate findings.

01

Capture

On real hardware. Attach your board once and record the device's real behavior. The trace becomes an executable device model: AI agents propose rules, and replaying the recorded trace decides what stays. A configuration change or unsupported behavior may need a new capture.

02

Fuzz

Hardware set aside. Fuzz the firmware against the captured model in software, no board in the loop, exploring what the device actually runs: interrupts, sleep and handler races included.

03

Reproduce

Back on the chip. Replay a finding on the physical chip; a crash in a model is just a question until the silicon reproduces it.

04

Evidence

A repro, not a score. Each reproduced finding ships with a runnable repro and the conditions it needs, not just a severity score. FDA and EU CRA evidence mapping is planned.

Evidence tiers

Every finding carries its level of proof.

Evidence tiers describe how far a finding has been validated, from emulation to a replay on the physical chip.

T0 — Emulated

Observed in emulation; hardware unverified.

T1 — Model-consistent

All stimulus stays within captured or spec-legal values the model checks; hardware unverified.

T2 — Hardware-confirmed

Reproduced on the physical chip with matching fault registers.

In short

Evidence levels describe validation, not exploitability.

The report

Every run ends in a test report.

Scope, the chip model it ran against, every finding with its evidence tier and the CI gate verdict, in one document that leads with what the silicon confirmed. SARIF for CI and a CycloneDX VDR ship with it.

Ruptor console with the campaign test report for the run: firmware fuzz test report for isotp on STM32F446, with the firmware hash, target MCU, chip model and an executive summary: CI gate BLOCK, 3,504 executions in 53 seconds, one root-cause finding, reproduced on the physical chip (T2).
Deployment

Capture on the bench. Fuzz in software.

Capture on the bench, then fuzz off it

Attach the board once to record a device model. Fuzzing then runs in software against that model, with no device in the loop, so nothing wears out and you don't need a lab full of boards.

Fits your firmware build

Capture integrates our SDK into a firmware build. Findings come back with a runnable repro, not just a severity score.

Decided on the real chip

Hardware-confirmed means the chip reproduced it. Nothing else gets that label.

Built for
Industrial IoTMedicalRoboticsAutomotivecomplex-peripheral devices
Who we are

Built by people who break firmware for a living.

A small team out of San Francisco, now opening Ruptor to its design partners.

Aliaksandr Piarkouski

Aliaksandr Piarkouski

Co-founder · CEO

Repeat founder building AI for the physical world. A career of building machines and breaking software, now aimed at the firmware inside them.

Nikita Volkov

Nikita Volkov

Co-founder · CTO

Embedded engineer who knows the chip down to the register. Wrote bare-metal CAN on STM32 before Ruptor existed: no vendor libraries, just the silicon.

Why now

The moment hardware security stops being manual.

01Regulation

Device makers now have to show their work.

The EU Cyber Resilience Act has required vulnerability reporting since September 2026 and applies in full from December 2027. The FDA already asks connected medical devices for cybersecurity evidence before market.

02AI writes firmware

More code reaches devices, faster, with fewer eyes on it.

Coding agents now write embedded C. The check that matters is not another review of the source, it is what the firmware does on the chip it ships on.

03Models can be automated

Modeling the hardware was the bottleneck.

Research rehosting and fuzzing tools spent most of their effort on peripheral models. Measured traces now build them automatically, AI agents resolve what a trace leaves open, and the real chip checks the result.

Where this goes

Firmware, proven on the real device before it ships.

Today

Capture a board, fuzz its firmware, reproduce bugs on the chip.

A working prototype: our fuzzer independently rediscovered three public CVEs in third-party code and replayed all three on a real STM32F446. Device models now cover three STM32 chips (F446, L476, H753), each checked against the real silicon.

Don't take our word for it. Confirmed findings ship with a repro you can run yourself.
Private beta

See it run on your firmware.

We're opening a small number of design-partner slots for device makers. Leave your work email and we'll set up a technical demo.

or email [email protected]