cwe_checker statically analyzes ELF binaries across CPU architectures to flag common bug classes like buffer overflows and use-after-free, supporting authorized firmware assessments and defensive code review.
| Tool | fkie-cad/cwe_checker — a suite of static checks that detects CWE bug classes in binary executables using Ghidra's intermediate representation |
| Category | Binary static analysis / vulnerability scanner |
| Primary Use | Triaging ELF binaries and firmware images for bug classes such as CWE-119 buffer overflows, CWE-416 use-after-free, and CWE-476 null pointer dereferences |
| Safe Use | Educational and documentary analysis for authorized security assessments, firmware research in lab environments, and defensive code auditing of software you own or are contracted to test |
| Telemetry Note | Purely local static analysis — reads binaries and emits warnings; it performs no network activity and leaves only log/JSON output artifacts on the analyst's machine |
cwe_checker is an open-source static analysis suite from Fraunhofer FKIE that scans compiled binaries for common bug classes formally catalogued as Common Weakness Enumerations (CWEs). Rather than auditing source code, it operates on ELF executables of the kind found on Linux and Unix systems, which makes it a natural fit for firmware triage where source is unavailable. The project describes its goal as helping analysts quickly find potentially vulnerable code paths, and it deliberately positions itself as a triage instrument rather than a proof-of-vulnerability oracle. With roughly 1,356 stars on GitHub, an active maintainer in fkie-cad, and partial financing from the German Federal Office for Information Security (BSI), it sits firmly in the reputable research-tool camp.
The architectural decision that defines cwe_checker is its use of Ghidra as the disassembly front end. Binaries are lifted into Ghidra's common intermediate representation, and the tool implements its own analyses on top of that IR. The consequence is architecture independence: any CPU architecture Ghidra can disassemble is fair game, and the README explicitly calls out x86, ARM, MIPS, and PPC support. For firmware analysts staring at a router image with a MIPS userland, this removes the usual friction of per-architecture toolchains. The implementation language is Rust, with a plugin-based architecture that lets new checks be added without surgery on the core.
The check catalog is broad and reads like a greatest-hits list of memory-safety and API-misuse bug classes. On the memory side it covers CWE-119 buffer overflow plus variants CWE-125 (out-of-bounds read) and CWE-787 (out-of-bounds write), CWE-416 use-after-free with CWE-415 double free, CWE-789 excessive allocation size, and CWE-476 null pointer dereference. On the API-hygiene side it flags CWE-134 externally-controlled format strings, CWE-190 integer overflow, CWE-676 dangerous function use, CWE-467 sizeof() on a pointer type, CWE-560 misuse of umask(), and CWE-243 chroot jails created without changing the working directory. Randomness weaknesses appear as CWE-332 insufficient PRNG entropy and CWE-337 predictable seeds, and it also detects CWE-367 TOCTOU races, CWE-426 untrusted search paths, CWE-782 exposed IOCTLs with insufficient access control, CWE-215 information exposure through debug messages, and CWE-78 OS command injection (disabled in standard runs).
Analysis techniques range from simple heuristics — pattern-matching known-dangerous API calls, for instance — up to abstract interpretation-based data-flow analysis, which is how it reasons about values propagating through a binary without executing it. That spread matters when interpreting results: the README is refreshingly candid that both false positives and false negatives are expected due to shortcuts, over-approximation, and the inherent limits of static analysis. Per-check documentation pages explain the inner workings of each analysis and enumerate the known reasons for imprecision. In an authorized workflow this means cwe_checker output is a prioritization signal — a ranked list of addresses and functions worth manual review in a disassembler — not a vulnerability report you ship unverified.
Deployment is deliberately low-friction. The recommended path is Docker: docker pull ghcr.io/fkie-cad/cwe_checker:stable fetches the latest stable release, while the :latest tag tracks master and versioned tags like :v0.9 pin specific releases. The README advises moving to new stable versions promptly since improvements between them are significant, and notes that prebuilt images are x86-only — ARM-based machines, including newer Apple Macs, should build locally with docker build -t cwe_checker .. A local install needs Rust >= 1.82 and Ghidra >= 10.2, built via make all GHIDRA_PATH=/path/to/ghidra_folder; if GHIDRA_PATH is omitted the installer searches the filesystem for a Ghidra installation. Nix users get a third option through nix run github:fkie-cad/cwe_checker.
Invocation is a single-argument operation: cwe_checker BINARY for local installs, or docker run --rm -v /PATH/TO/BINARY:/input ghcr.io/fkie-cad/cwe_checker /input under Docker. The tool runs its check suite and prints a list of CWE warnings. Behavior is tuned through src/config.json — notably, it is configurable enough to apply existing analyses to new APIs, which extends coverage to vendor-proprietary function sets common in firmware. Pass the modified file with --config=src/config.json, and use --help for the full flag list. For pipeline integration, --json combined with --quiet or --out=... emits machine-parseable warnings for feeding into your own tooling.
Beyond desktop ELF files, the tool has two interesting experimental surface areas. Linux loadable kernel modules (LKMs) are auto-detected on input, with a subset of the user-space checks executed and a separate configuration at src/lkm_config.json. Bare-metal binaries are supported through the --bare-metal-config flag, with a shipped example configuration at bare_metal/stm32f407vg.json created and tested for an STM32F407VG microcontroller — a concrete hint at embedded/IoT research use cases where there is no OS at all. Both features carry the experimental label, so treat their output with correspondingly more skepticism.
The Ghidra integration deserves specific attention because it closes the loop between automated triage and manual reverse engineering. A bundled script at ghidra_plugin/cwe_checker_ghidra_plugin.py parses cwe_checker output and annotates the discovered CWEs directly in the disassembly, so an analyst jumps from a warning straight to the flagged instructions with full context. The tool is also integrated as a plugin into FACT_core, FKIE's large-scale firmware analysis framework, making it one component in a factory-style analysis pipeline. That placement reinforces where the project sees itself: a scalable first-pass filter over binary populations too large to reverse by hand.
For teams building custom chains, the --json output is the key extension point, and the plugin architecture means organizations with house bug taxonomies can add checks without forking the analysis engine. The README points deeper for the curious: internal documentation is built with cargo doc --open --document-private-items --no-deps, conference slides from Pass The SALT 2019 and Black Hat USA 2019/2022 live in the doc folder, and questions are fielded on the GitHub discussions page. Test binaries are reproducible via make compile_test_files (Docker required) with the suite run through make test, and source documentation via make documentation.
Licensing and provenance round out the picture: the code is LGPL-3.0 licensed, copyright 2018–2024 Fraunhofer FKIE, with acknowledged intellectual debt to the BAP community for discussions around binary analysis techniques. For authorized assessors, firmware researchers, and defenders doing supply-chain review of third-party binaries, cwe_checker offers a mature, architecture-agnostic first pass — provided you treat its findings, as its own documentation insists, as leads to verify rather than conclusions.
fkie-cad/cwe_checker.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.