Not observed.
Mistaken for unused.
- Runs one mission
- Misses interrupts and rare inputs
- Reads absence as proof
- Leaves its limits unstated
- Can break working firmware
Bind a review to one exact Cortex-M image, record what was observed and what control flow can reach, and keep every region nobody has proved safe to change.
These are recorded results from one public image and one test fixture. Choosing a local file changes nothing here: this page does not read, analyze, or upload it.
The symbolic step reached 6 blocks within its 1-second budget and added none to the kept set.
A schematic, not a graph of this firmware. The rewrite path stays closed without a checked proof and a separate operator decision.
Public image: one small run, with a smoke emulator capped at 100,000 instructions and 3 seconds, a 1-second symbolic budget, and no imported traces. These are recorded results, not customer outcomes. The evidence bundle is the authority, not this view.
It is not dead code. It is a list of what nobody has shown to be reachable or unreachable. These are the 609 unknown blocks on the public image, grouped the way a pilot delivers them.
An engineer who knows the product walks this list in a review. Is the UART ever initialized in this product? If it is not, those functions are the conversation to have with the supplier.
Two views of the same idea: a block of firmware is kept when evidence reaches it, and left unknown when nothing does. Both are animated from the recorded pilot numbers, not from any live analysis. Nothing here reads firmware bytes.
Each block is scored by the evidence that reaches it. Links show the context behind a keep decision. The names and counts are from the recorded run.
Scene 1 shows 83 blocks observed in a trace and 1,777 more reached by control flow, for 1,860 kept, while 609 stay unknown and are listed rather than removed. Scene 2 builds that same set of 2,469 blocks inside a wireframe of the image. For more information, including what these numbers do not establish, read the research note.
The service is narrow and offline on purpose. It produces evidence for a review. It does not claim that unknown code can be removed.
A reviewed PrunerSpec contract binds the raw Cortex-M image, its load address, entry point, and vector table size, and every trace, by SHA-256. Changed bytes fail before analysis starts.
BIN + PrunerSpec →Every recovered code block is recorded as observed in a trace, reachable by control flow, or unknown. Missing coverage is never read as proof.
Observed / reachable / unknown →A small declarative policy gives each block one verdict: reachable, unknown, proved unreachable, or conflict. Evidence can add a reason to keep code. It cannot remove one.
Egglog policy →The report lists what remains unknown, by function when an ELF is available and by address when it is not. An explicit exit policy lets CI act on it, and a signed reviewer decision is tied to the exact bundle.
Report + approval record →Experimental and off by default. When a separately checked, signed exclusion proof authorizes a function, PRUNER rewrites the firmware image in place, replacing only that code with fail-loud traps, then replays the result against the original. It needs a matching ELF. On 10 public test images it has rewritten only code that nothing refers to.
Certificate-gated experiment →A second reviewer verifies the bundle offline with one command and compares it against the next build. Firmware bytes are in none of it.
Hash-bound + comparable evidence →A trace tells you what ran during one mission. It does not tell you what can never run. Not observed is a measurement. Unreachable is a proof claim.
PRUNER keeps the two apart. It combines local rehosting, recovered control flow, and symbolic witnesses under a fail-closed policy of nine rules. No language model runs anywhere in that pipeline.
The report ties its conclusion to exact artifacts and says what the run cannot establish.
Read the research note ↗Most reachability tooling exists to close findings. This one records what nobody has proved yet, in a form a second reviewer can check offline. It works beside vulnerability and SBOM tools and does not replace them.
Product-security and embedded teams have to accept or reject Cortex-M firmware they did not write, and Arm Cortex-M is the dominant 32-bit microcontroller core, so almost every supplier image is in scope. PRUNED Security has not run a customer engagement yet and is selecting its first design partners.
Arm Cortex-M is the dominant 32-bit microcontroller core, shipping billions of units a year, so the firmware a team must accept or reject is almost always in scope.
An auditable accept, accept with conditions, or reject, backed by an evidence bundle a second reviewer verifies offline, in place of ad hoc reverse engineering.
Analyzed offline in the customer environment, with no source required, so supplier and product IP stay onsite.
You provide a raw image, its memory map, a representative mission, and an engineer who knows the product. You get an exact-input evidence bundle and a review session, not a patched binary.

A second reviewer checks all of it offline with one command. Firmware bytes are in none of it.
Request a pilot ↗Reviewing supplier Cortex-M firmware? PRUNED Security is selecting its first design partners: one product family, one to three raw images, analyzed offline in your environment. You get an auditable evidence bundle and a review session, not a patched binary.