Firmware SBOM Scanner
Deusbom
Reads a compiled firmware image, identifies the third-party libraries inside it, and produces the software bill of materials the EU Cyber Resilience Act requires.
Firmware ships with third-party code. The EU Cyber Resilience Act requires you to know exactly what is in there and to document it. Deusbom does that work: it reads the compiled image your toolchain produces, matches the symbol table against a component database, and gives you a bill of materials you can file.
The result can be saved as a CycloneDX 1.6 document for machine consumption, or as a readable report for a compliance folder. Output is byte-reproducible, so a bill of materials can be committed next to a release and diffed in CI.
What it does.
Reads the unstripped ELF
Your toolchain produces an unstripped .elf before objcopy or strip removes the symbol table. That is the file Deusbom reads. Give it the .bin or .hex you flash to the device and it will say so rather than report an empty result.
Matches against a component database
Symbol tables are matched against a fingerprint database of widely-used components across common microcontroller families. Where a version is shown, it was recovered from source paths the compiler left in the image.
Reports what it could not attribute
Components not in the database produce no entry and no warning. The absence of something from the list is not evidence of its absence from the firmware. Deusbom also reports the symbols it could not attribute — that is where an unknown component would be hiding.
Outputs three formats
Plain text for reading, HTML for filing, CycloneDX 1.6 for toolchain integration. The same image scanned twice produces identical bytes. SOURCE_DATE_EPOCH pins the timestamp.
Three limits worth knowing.
The database is finite
A component it does not cover produces no entry. This is why the unattributed-symbols section exists — it is where an unknown component would appear.
Versions are not always recoverable
Version information comes from source paths. A library copied into a project's own source tree usually carries none. Nothing is guessed: an absent version is safer in a regulatory filing than a wrong one.
Stripped images cannot be read
No symbol table, nothing to match against. Deusbom will say so rather than return a silent empty result.
Privacy.
Deusbom runs entirely on the machine it is installed on. It makes no network connections, sends nothing anywhere, and collects no analytics or telemetry. The firmware you select is read from disk and analysed in memory. Nothing is written anywhere except where you explicitly choose to save a report.
Using it.
WINDOWS
Download the .exe and double-click it. Or run it from a terminal and pass a firmware path.
LINUX
Download the binary, make it executable, run it.
chmod +x deusbom-linux-x86_64 ./deusbom-linux-x86_64 # opens the window ./deusbom-linux-x86_64 firmware.elf # prints to terminal
Command line
deusbom [options] <firmware.elf>
-f, --format <fmt> text (default), html, or cyclonedx
-o, --output <file> write to a file instead of stdout
-v also list ELF sections
-s dump every symbol found
--no-unknown hide the unattributed-symbols section
--gui open the application window
-h, --help The result is machine-assisted analysis, not a certification. It should be reviewed by someone who knows the product's build before it is relied upon.
The public database covers common components.
The public build covers widely-used components across common microcontroller families. Vendor SDKs, in-house libraries and third-party code copied into a source tree are indistinguishable from an application's own code when seen from the binary — and any of them may be a component you are obliged to declare.
Quandeus builds fingerprint databases for one specific product: your toolchain, your vendor SDK, your own libraries. If the public database does not cover your stack, that is the service.
Describe your stackDownload Deusbom.
Free. No account, no installer, no runtime. One file.
Download