Research noteNot observed is not unreachable.14-minute readRead the note

Review firmware.
Keep unknowns safe.

PRUNER Assurance controlled pilot

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.

Designed forEmbedded engineeringProduct securitySoftware assurance
01Know the evidenceSeparate observed, reachable, and unknown code.
02Keep unknowns safeMissing coverage never authorizes a change.
03Review offlineVerify the report without sharing firmware bytes.
Recorded pilot evidence

See what PRUNER knows.
See what it does not.

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.

RECORDED RUNARDUINO-F103-PWM.bin
Firmware size25.46 KBInput unchanged
Recovered code blocks2,469Control-flow recovery
Unknown candidates609Kept, and listed
Kept on evidence1,860Trace + control flow
Authorized rewrites0No proof
EVIDENCE COMPOSITION2,469 recovered code blocks
Trace + control flow
  • Observed in the trace833.4%
  • Reachable by control flow1,77772%
  • Unknown, kept and listed60925%
  • Proved unreachable00%
  • Conflict00%
  • Authorized for rewrite00%

The symbolic step reached 6 blocks within its 1-second budget and added none to the kept set.

EVIDENCE FLOWHow a verdict is reached
Schematic

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.

THE UNKNOWN INVENTORY

The unknown set is the part worth reading.

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.

  1. 311In functions reachable only through a stored address.61 functions, for example HAL_NVIC_EnableIRQ, HAL_RCCEx_PeriphCLKConfig, HAL_RCC_GetSysClockFreq
  2. 198Fragments inside functions that are otherwise kept.58 functions
  3. 91In functions that a second analysis reaches by direct calls and the block walk does not. The two have not been reconciled.6 functions, for example HAL_SYSTICK_CLKSourceConfig, HAL_UART_Init, HAL_UART_MspInit
  4. 8Outside any function.
  5. 1In a function that nothing refers to._fini
The gap

Not observed is
not unreachable.

TRACE-ONLY DECISION

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
PRUNER ASSURANCE

Record what is known.
Keep what is not.

  • Binds the exact input
  • Adds evidence only to keep code
  • Lists every unknown
  • Changes nothing without a checked proof
  • Lets a second reviewer verify offline
How it works

How reachability
is decided.

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.

SCENE 1 OF 2The evidence behind each verdict

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.

Controlled product slice

Analyze, classify, and
document Cortex-M firmware.

The service is narrow and offline on purpose. It produces evidence for a review. It does not claim that unknown code can be removed.

01

Exact input binding

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 →
02

Three kinds of evidence

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 →
03

Four verdicts, nine rules

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 →
04

Review-ready report

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 →
05

Proof-gated rewrite

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 →
06

Offline verification

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 →
Workflow

From exact input
to reviewable evidence.

01Load
02Hash
03Observe
04Recover CFG
05Gather witnesses
06Classify
07Review
08Verify
SAFETY RULEEvery unknown is kept. Nothing changes without a checked proof and a separate operator decision.
PRUNERpolicy coreREHOSTruntimeBINARYstructureGRAPHpathsEGGLOGpolicyVERIFYevidenceHASHbinding
Research and engineering

Policy tied to
firmware 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.

Cortex-MRehostingEgglog policyEvidence verification
Read the research note ↗
Where it runs

Offline, in your environment.

01Firmware image→
02Memory map→
03Local runner→
04PRUNER Assurance→
05Engineering review→
06Evidence bundle→
07Approval→
08Archive
Product boundary

Know what is included.
Know what is not.

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.

CapabilityIn a pilot today
Exact-input hash bindingThe image, the contract, and every trace, by SHA-256✓Included
Keep-side evidenceTraces, recovered control flow, and symbolic witnesses✓Included
Unknown inventoryBy function with an ELF, by address without one✓Included
Offline HTML and JSON evidence bundleNo firmware bytes in it✓Included
Comparison against the next buildWith an explicit pass or fail policy✓Included
Signed reviewer decisionBound to the exact bundle✓Included
Proof-gated rewriteNeeds a matching ELF. On public test images it has removed only code that nothing refers toExperimental
Automatic debloating under a registered policyA documented method, run on public test images with a pattern matcher proposing. No language-model run, hardware, or customer image yetExperimental
SBOM, CVE scanning, VEXKeep the tools you already use for theseNot included
Attack surface reductionRemoving code that nothing refers to is not a measured reduction in riskExperimental
Design-partner pilot

What a pilot delivers.
What it does not.

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.

Almost every supplier image

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.

Faster, defensible sign-off

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.

Firmware never leaves

Analyzed offline in the customer environment, with no source required, so supplier and product IP stay onsite.

INITIAL ENGAGEMENT

Supplier firmware reachability review

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.

  1. 01Bind the supplied image
  2. 02Observe representative missions
  3. 03Walk the unknown inventory
  4. 04Verify and archive the evidence
What you bringWhat you getWhat PRUNED Security will not claim
One to three raw Cortex-M images with SHA-256 delivery recordsPrunerSpec source, compiled profile, and an exact-input hash recordThat unknown code is dead or removable
Load address, entry point, and vector table sizeA hash-bound HTML and JSON evidence bundle with per-block verdicts and no firmware bytesVulnerability discovery, SBOM, VEX, or compliance certification
Fuzzware or hardware traces for named missionsAn inventory of what remains unknown, with stated limitsAttack surface reduction, or any percentage
An engineer who knows the interrupts, DMA, boot, and update pathsA comparison against your next build, and a readout sessionReview time saved. Measuring that is the point of the pilot
A matching ELF, only if you want the rewrite gate evaluatedA signed reviewer decision: accept, accept with conditions, or rejectResults beyond public test images and one fixture
Evidence report for the pinned public image: 2,469 recovered code blocks, 1,860 kept, 609 unknown, 0 authorized for rewrite.
The report from the recorded run on the pinned public image, as a reviewer receives it. This bundle is unsigned.
WHAT THE EVIDENCE BUNDLE BINDS
  1. 01Inputs. The image, the contract, and every trace, bound by SHA-256.
  2. 02Analysis artifacts. The trace, the reachability map, and the per-block verdicts.
  3. 03Attestation. One record that binds every artifact and the report by hash.
  4. 04Signature. Optional, checked against a key you already trust.
  5. 05Reviewer decision. A signed accept, accept with conditions, or reject.

A second reviewer checks all of it offline with one command. Firmware bytes are in none of it.

Request a pilot ↗
Start with one product family

Review firmware
without hiding uncertainty.

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.

Request a pilot ↗What a pilot delivers