Perseus Products
Restricted access
Firmware
Product security management for device makers, on a restricted platform. Onboarded customers organise product groups, products and versions, submit a software bill of materials or the firmware image itself, and get findings, dispositions and evidence they can hand to a regulator. Static analysis across the architectures embedded products actually ship on, with intelligence from the Vulnerability Core Engine. Onboarding is by application and review.
Know what is in the image, and what that means
Overview
Firmware takes an image and works out what is inside it: the file systems, the packages, the statically linked libraries, the scripts, the keys and the hard-coded endpoints. From that it builds a bill of materials and sends the components to the Vulnerability Core Engine, which returns matched findings with scores from multiple scoring parties, exploited-in-the-wild flags, proof-of-concept references where one exists, fix versions, vendor statements, and vulnerabilities published in advisories without a CVE.
If you already have a bill of materials, submit that instead and monitor it. Either way each product version gets a report in which every finding opens to its proof, analyst dispositions exported as VEX, a compliance evidence map, and a station-by-station test record. Versions are re-assessed every six hours against the live corpus, without re-extraction, so a new advisory shows up on the products it affects.
SBOM from the binary
Package databases, banners, shared-object names, symbols and binary similarity, exported as CycloneDX or SPDX.
Static analysis lanes
Hardening, secrets and crypto material, configuration, backdoor markers, hard-coded endpoints, signatures, scripts, dataflow and reachability.
Every finding shows its proof
Where it is, what matched, why the rule fired and how to check it yourself. Signature matches are leads; candidates stay candidates.
Evidence you can hand over
VEX dispositions, a compliance evidence map and a sealed test record. Evidence, not a certificate.
software components recovered from one router firmware image in a validated static run
dataflow-confirmed weakness paths on one sample product; a lower bound, as two binaries timed out
binaries explored in which symbolic execution reached a command sink, on the same product
matches on a sample SBOM-only product scored by a party other than the public national database
hard-coded hosts inventoried as public on the same sample product
static analysis stations in the chain-of-custody test record, in six benches
regulatory and standards frameworks in the evidence mapper
symbol-recovery corpus slices shipped, each with a false-positive gate passed
Capabilities
What the tool does
Static analysis only. Every capability below is serving on the current build.
Extraction and classification
Linux root file systems, RTOS images, bare-metal MCU images and flash containers are extracted and classified; encrypted containers are identified.
SBOM from firmware, or SBOM upload
Build a bill of materials from the image, or submit CycloneDX or SPDX JSON and monitor it, with or without the image. Export both formats.
Engine-delegated vulnerability assessment
Components are assessed by the Vulnerability Core Engine and come back with scores from multiple scoring parties, each named, exploited-in-the-wild flags, exploit probability, proof-of-concept references, fix versions and vendor statements.
Full disclosure: every finding opens to its proof
Where it is (path, file hash, line or byte offset), what matched, why it fired (tool, version, rule and rule text) and how to verify it yourself. Lists state how many rows they show out of how many, never a silent cap.
Static hygiene lanes
Binary hardening flags; private keys, tokens and credentials, shown in full to the organisation that owns the firmware; weak or expired certificates; configuration weaknesses; backdoor markers; and an inventory of hard-coded endpoints classified as public, private or reserved.
Signature leads and script analysis
Rules from curated public rulesets run over every extracted file; each match shows the matched bytes, the offsets and the rule's own text, and the rules left out are listed with the reason. Matches are leads to investigate. Shell and Python scripts are checked by real linters.
Dataflow weakness lanes
Taint analysis on the binaries confirms source-to-sink paths for command-injection and format-string classes across x86, ARM, MIPS and PowerPC, with a second lane for bare-metal Xtensa and TriCore, and LoongArch. Everything else stays a candidate.
Symbolic reachability
Symbolic execution shows whether program input can reach a command sink and recovers the input that gets there. Unreached within budget is reported as unconfirmed, never as safe.
CVE-targeted verification
For the CVEs that matter most, the public fix commit is fetched, the functions it changed are named, and the tool tries to locate them in your image. A CVE is marked verified only when an analysis lane proves it on that function; on the showcase data no CVE is verified.
Symbol recovery for stripped binaries
Function names recovered in stripped, statically linked MIPS and ARM binaries from a curated signature corpus, so the deep lanes have something to analyse.
Binary similarity
Library presence in statically linked binaries identified against same-toolchain corpora; version is reported only when a banner or shared-object name corroborates it.
AI-assisted annotation, advisory
An AI model annotates weakness candidates with a one-line reading. The note is advisory: it never changes a tier, a severity or a count.
Compliance evidence map
Findings and bill-of-materials facts mapped to controls across eight frameworks, including the EU Cyber Resilience Act, radio-equipment security, consumer IoT security and medical-device guidance. Evidence coverage, never a readiness score, and not a certificate.
Test record with chain of custody
Thirteen static analysis stations record which tool ran, at which version, on which input hash, with timings; stations that did not run are shown as bypassed with the reason. A sealed PDF and an evidence bundle follow.
Analyst dispositions as VEX
Record not affected, affected, fixed or under investigation with a justification and written reasoning, stamped with author and time and kept append-only. Exported as OpenVEX or CycloneDX VEX; dispositions carry forward to the next version flagged for re-affirmation.
Right-to-analyse record
Every analysis records the basis on which the tenant may analyse the firmware. The platform records it; the onboarding review checks it.
Continuous re-assessment
Every stored bill of materials is re-assessed against the live corpus every six hours, without re-extraction, with alerts, remediation clocks, SIEM export and a CI gate.
Portfolio: groups, products, versions
Product groups, products and versions with posture rollups, a declared-versus-discovered SBOM deviation view, and version-over-version compare with a tamper analysis.
Multi-tenant with roles
Tenants, four roles, password and one-time-code sign-in, per-tenant API keys and plan-gated features.
Support matrix
What is supported, and what is not
Static analysis only. Each row states the limit as plainly as the capability.
| Area | Supported today | Not supported or limited |
|---|---|---|
| Image classes | Linux root file systems, RTOS images, MCU bare-metal images, flash containers; encrypted containers identified | Encrypted vendor containers are not opened: one vendor container format is unwrapped, otherwise customer-supplied keys only |
| Container and flash formats | U-Boot uImage, ARM zImage, FIT and FDT, DTB, Intel HEX, Motorola S-record, ESP32 and ESP8266 partition tables | — |
| SBOM input | CycloneDX 1.2 to 1.6 JSON; SPDX 2.1 to 2.3 JSON; up to 25,000 components | No SPDX tag-value, no XML |
| Architecture detection | ELF machine type for every ELF, plus raw-flash loaders for ESP and Xtensa and for TriCore | V850 and RH850 loader blocked on samples |
| Binary hardening checks | Every ELF, any architecture: NX, PIE, RELRO, canary, FORTIFY, stripped | — |
| Dataflow weakness lanes | Main lane: x86, ARM, MIPS and PowerPC; second lane: bare-metal Xtensa and TriCore, and LoongArch | Named-sink checks fire only on imported sinks; only taint-class findings reach confirmed |
| Disassembly coverage lane | Every instruction set the coverage disassembler supports; capability signal on x86 and x86-64 | Coverage, not depth; the capability signal is x86 and x86-64 only |
| Symbolic reachability | x86-64, ARM, MIPS, for dynamically and statically linked binaries; standard input, arguments and CGI environment | Reachability of a sink call, not proof of argument taint; unreached is never safe |
| Symbol recovery | MIPS big- and little-endian with musl, glibc and uClibc; little-endian ARM with the same three C libraries; 64-bit ARM with musl | 64-bit ARM with glibc held; no x86, PowerPC, RISC-V or big-endian ARM |
| Binary similarity | x86-64, MIPS, 64-bit ARM and ARMv7 corpora, same toolchain only | No transfer across toolchains; presence first, version only when corroborated |
| CVE function location | Any architecture with a readable symbol table; stripped MIPS, ARM and 64-bit ARM through symbol recovery; Linux kernel images and modules through their own symbol and export tables | A missing symbol table is never read as a missing function; kernel rows are located only |
| Outputs | CycloneDX and SPDX 2.3 SBOM, OpenVEX and CycloneDX VEX, SARIF, CSV, SIEM export, sealed PDF test record, evidence bundle | — |
From image to evidence
How it works
- 1
Intake
Submit an image or a bill of materials against a product version; the right-to-analyse basis is recorded.
- 2
Extract and classify
File systems, packages, scripts and binaries are recovered; the image class and architecture are identified.
- 3
Build the SBOM
Package databases, banners, shared-object names, symbols and binary similarity produce the component list.
- 4
Assess
Components go to the Vulnerability Core Engine and come back scored, with exploit evidence and vendor statements.
- 5
Analyse statically
Hygiene, signature, script, dataflow and reachability lanes run within recorded budgets; every finding keeps its proof.
- 6
Record and monitor
Dispositions, compliance evidence, the sealed test record; then six-hourly re-assessment as advisories arrive.
Showcase
Sample products, real analysis
Screens from a sample tenant, the device maker Veltaris Controls. Two products run on sample images; the deep-lane field router runs on an open-source, deliberately vulnerable research image under a sample product name. Secret values are blurred here; the console shows them in full to the organisation that owns the firmware. Nothing on this page takes input.
A deep-lane verdict
The verdict card of the sample field router: exploited-in-the-wild CVEs, critical findings and dataflow-confirmed weakness paths. The confirmed count is a lower bound because two binaries timed out.
Sample data
A product and its versions
A sample substation gateway with two analysed versions: the timeline shows what changed between them, the current version's posture, and every analysis. The product holds a declared bill of materials next to its image scan.
Sample data
CVE-targeted verification, not verified
For one CVE, the fix commit named four changed functions and the tool tried to locate them in a stripped binary. Their present state is unknown within the budget, so the CVE stays unverified. No CVE on this screen is verified.
Sample data
A weakness kept as a candidate
A command-execution call in a stripped, statically linked web server, found by symbol matching. With no source-to-sink dataflow proof it stays a candidate; the AI note beside it is advisory.
Sample data
A signature lead with its proof
A public rule matched a constant table in a binary: the drawer shows the file, the matched bytes at the offset and the rule's own source. This one is informational; matches are leads, never verdicts. The rule author's handle is blurred here.
Sample data
A shipped private key
A private key found in the image, with its path, file hash, offset and value. The console shows the value in full to the organisation that owns the firmware; it is blurred on this page.
Sample data
A product monitored from its bill of materials
A declared CycloneDX bill of materials with nine components and no image. The binary lanes do not apply and the screen says so; the components are assessed by the Vulnerability Core Engine.
Sample data
Declared versus discovered
A declared bill of materials against what the scan found in the image. Missing means not corroborated by the scan, not removed.
Sample data
| Component | Declared | Discovered in image | Reading |
|---|---|---|---|
| openssl | 1.1.1k | 1.1.1k | Matched |
| zlib | 1.2.11 | 1.2.13 | Version mismatch |
| busybox | 1.31.1 | 1.31.1 | Matched |
| libcurl | 7.68.0 | 7.68.0-r0, found twice | Matched with release suffix; duplicate flagged |
| dropbear | 2019.78 | not found | Declared, not in image |
| json-c | 0.13.1 | json-c-dev 0.13.1 | Name variant, flagged for review |
| hostapd | not declared | 2.9 | Undeclared component |
| telnetd | not declared | version unknown | Undeclared component, version unknown |
Six declared components, eight discovered. Reading column as the fixture pair reads; names are open-source components.
Declared versus discovered, component by component
A richer case from the sample router pair in the product's test suite. The deviation view computes this for every version with a declared bill of materials.
Sample data
Version compare with a tamper analysis
Two versions of the same product: a binary lost partial RELRO and a private key at the same path changed value. The tamper score is a lead to investigate, not a confirmation.
Sample data
On the planted images the static lanes report the private key, the weak root password hash, the insecure telnet service, the raw-shell backdoor and the beacon host, and the stripped static web server yields three command-injection candidates on one C library and three more plus three buffer-overflow candidates on another. On the benign control every lane reports zero. On a real router image the bill of materials recovers 364 components.
What a scan surfaces on the test corpus
From the product's validated test corpus: two sample router images with planted content and one benign control.
Questions we are asked
FAQ
Device makers, and organisations a device maker has authorised in writing to analyse its firmware. Every customer goes through a review of the organisation and the products it will analyse before onboarding.
Apply for access
Tell us what you make and which obligations you are working towards. Onboarding includes a review of your organisation and the products you will analyse.