BinHound identifies software inside compiled binaries and proves its conclusions with machine-readable evidence.
Status: v0.1 walking skeleton — ELF header analysis works today, the rest is on the Roadmap.
English · Italiano
What it is · Features · Quick start · Usage · How it works · Roadmap · Contributors · Contributing
BinHound is a static analyzer for compiled binaries and firmware. Given a file with no source code available, it reconstructs the software inventory: which components are bundled, which versions can be proven, which cryptography is in use, and which known vulnerabilities apply — each result with the evidence behind it and a confidence level.
It is built for the era of the EU Cyber Resilience Act and the post-quantum migration, where knowing what is inside a product is a legal and practical requirement, not an option.
What works today:
- ELF header analysis. Class, endianness, type, machine, entry point and section count for ELF32 and ELF64, little and big endian.
- Safe by default. The analyzed file is never executed; no network access unless requested.
- Tested everywhere. Unit and CLI tests on Linux, Windows and macOS, with sanitizers, fuzzing and coverage gates.
What's next (see Roadmap): component inventory (SBOM), cryptography inventory (CBOM), vulnerability matching with VEX, a coverage scorecard and CycloneDX export — every result with evidence and confidence.
Requirements: CMake 3.28+, Ninja, a C++20 compiler (GCC 13+ or Clang 18+).
git clone https://github.com/kiyx/binhound.git
cd binhound
cmake --workflow --preset debug # configure, build and testRelease build with LTO and hardening:
cmake --preset release
cmake --build --preset release
cmake --install build/release --prefix "$HOME/.local"
binhound --help
binhound scan /bin/lsText output
File: /bin/ls
Class: ELF64
Endianness: little
Type: DYN
Machine: x86-64
Entry: 0x6d30
Sections: 31
Exit codes: 0 success, 1 findings, 2 error — suitable for scripts and CI.
binary ──► parse ──► extract evidence ──► detect ──► report
ELF strings, symbols, rules and CycloneDX,
Build-ID confidence coverage, text
The core is a C++20 library (binhound_core); the command line is a thin adapter on top of it.
Every finding will carry its evidence and confidence, and every report will state its coverage.
- Evidence first. A result without evidence is not a result.
- Honest coverage. Reports state what could not be analyzed; low coverage is a finding, not a failure.
- Open and inspectable. Apache-2.0, no closed detection logic.
- Safe by default. No code execution, no network access unless explicitly requested.
Status: early development. ELF header analysis works today; component detection and SBOM export are the next milestone. Each milestone ends with a tagged release.
| Version | Focus |
|---|---|
| v0.1 | ELF parsing, strings, symbols and Build-ID, signature detection, CycloneDX SBOM, coverage scorecard |
| v0.2 | CBOM, Go/Rust metadata, automated signature database |
| v0.3 | Vulnerability matching (OSV) and VEX |
| v0.4 | CRA readiness report |
| Later | PE and firmware support, medical (DICOM) module |
- doctest - unit testing
- tl::expected - error handling
- CMake and Ninja - build system
- CycloneDX - target format for SBOM, CBOM and VEX output (roadmap)
- OpenSSF Scorecard - repository security posture
Thanks to everyone who has contributed to BinHound.
Bug reports, small fixes, tests, documentation and feature proposals are welcome. Open an issue or start a discussion first; see CONTRIBUTING.md for the workflow and the quality gates, and CODE_OF_CONDUCT.md for the community rules.
Please report vulnerabilities privately; see SECURITY.md.
Apache-2.0 — see LICENSE. If you use BinHound in your work, see CITATION.cff.