cwe_checker is a suite of tools to detect common bug classes such as use of dangerous functions and simple integer overflows. These bug classes are formally known as Common Weakness Enumerations (CWEs). Its main goal is to aid analysts to quickly find vulnerable code paths.

Its main focus are ELF binaries that are commonly found on Linux and Unix operating systems. cwe_checker is built on top of BAP (Binary Analysis Platform). By using BAP, we are not restricted to one low level instruction set architectures like Intel x86. BAP lifts several of them to one common intermediate representation (IR). cwe_checker implements its analyses on this IR. At time of writing, BAP 2.1 supports Intel x86/x64, ARM, MIPS, and PPC amongst others. Hence, this makes cwe_checker a valuable tool for firmware analysis.

The following arguments should convince you to give cwe_checker a try:

  • it is very easy to set up, just build the Docker container!
  • it analyzes ELF binaries of several CPU architectures including x86, ARM, MIPS, and PPC
  • it is extensible due to its plugin-based architecture
  • it is configureable, e.g. apply analyses to new APIs
  • view results annotated in IDA Pro and Ghidra
  • cwe_checker can be integrated as a plugin into FACT


Using the docker image

The simplest way is to pull the latest Docker image from dockerhub:

  • docker pull fkiecad/cwe_checker:latest yields an image based on the current master branch.
  • docker pull fkiecad/cwe_checker:stable yields an image based on the latest stable release version.

If you want to build the docker image yourself, just run docker build -t cwe_checker .

Local installation with BAP as backend

Another way is to get cwe_checker from the Ocaml package manager Opam. You can install cwe_checker via the package cwe_checker (opam install cwe_checker). This gives you the latest stable release version of the cwe_checker.

If you plan to develop cwe_checker, it is recommended to build it using the provided Makefile. In this case you must ensure that all dependencies are fulfilled:

  • Ocaml 4.07.1
  • Opam 2.0.2
  • dune >= 2.0
  • BAP (and its dependencies). Development on the master branch depends on the master branch of BAP which can be added with opam repo add bap-testing git+https://github.com/BinaryAnalysisPlatform/opam-repository#testing to the sources of the Opam package manager. The stable release of the cwe_checker depends on BAP 1.6.
  • yojson >= 1.6.0
  • ppx_deriving_yojson >= 3.5.1
  • alcotest >= 0.8.3 (for tests)
  • Sark (latest) for IDA Pro annotations
  • pytest >= 3.5.1 (for tests)
  • SCons >= 3.0.5 (for tests)
  • odoc >= 1.4 (for documentation)
  • Rust >= 1.44.1

Just run make all to compile and register the plugin with BAP. You can run the test suite via make test. Documentation can be built via make documentation.

Local installation with Ghidra as backend

The Ghidra backend is still in early development, thus many checks are not yet available for it. To try it out, the following dependencies must be fulfilled:

Run make all GHIDRA_PATH=path/to/ghidra_folder (with the correct path to the local Ghidra installation inserted) to compile and install the cwe_checker.


The cwe_checker takes as input a binary file, runs several checks based on static analysis on the binary and then outputs a list of CWE warnings that have been found during the analysis.

If you use the official docker image, just run

docker run --rm -v /PATH/TO/BINARY:/tmp/input fkiecad/cwe_checker cwe_checker /tmp/input

If you installed the cwe_checker locally (e.g. via the Opam package), run

cwe_checker BINARY

You can adjust the behavior of most checks via a configuration file located at src/config.json. If you modify it, add the command line flag -config=src/config.json to tell the cwe_checker to use the modified file.

For more information on usage instructions and available command line flags, see the online documentation. You can also build the documentation locally via make documentation and then browse it in the doc/html/ folder.

Implemented Checks

So far the following analyses are implemented:

  • CWE-125: Out-of-bounds read (via emulation)
  • CWE-190: Integer Overflow or Wraparound
  • CWE-215: Information Exposure Through Debug Information
  • CWE-243: Creation of chroot Jail Without Changing Working Directory
  • CWE-248: Uncaught Exception
  • CWE-332: Insufficient Entropy in PRNG
  • CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
  • CWE-415: Double Free (still experimental)
  • CWE-416: Use After Free (still experimental)
  • CWE-426: Untrusted Search Path
  • CWE-457: Use of Uninitialized Variable
  • CWE-467: Use of sizeof() on a Pointer Type
  • CWE-476: NULL Pointer Dereference
  • CWE-560: Use of umask() with chmod-style Argument
  • CWE-676: Use of Potentially Dangerous Function
  • CWE-782: Exposed IOCTL with Insufficient Access Control

Please note that some of the above analyses only are partially implemented at the moment. Furthermore, false positives are to be expected due to shortcuts and the nature of static analysis as well as over-approximation. For more information about the individual checks you can look at the online documentation.

NOTE: The new memory checks for CWEs 415 and 416 are still very experimental and are disabled on a standard run. You can try them out using the -partial=Memory command line flag.

NOTE: We recently decided to deprecate the support for the old emulation based checks for CWEs 415, 416 and 787. In addition to trying out the new memory checks, users of these checks should also take a look at the BAP toolkit, which provides better-maintained (and still emulation based) versions of these checks.

Integration into other tools

cwe_checker comes with scripts for IDA Pro and Ghidra, which parse the output of cwe_checker and annotate the found CWEs in the disassembler for easier manual analysis. See the online documentation for their usage. The IDA Pro plugin also uses colors to represent the severeness of the found issues (yellow, orange, or red). The following screenshot shows some results:

IDA Pro anotation

How to extend cwe_checker?

You can find some information about how to write your own check here

If you plan to open a PR, please utilize precommit in your development environment to catch many issues before the code review.


SIPTorch – Session Initiation Protocol Testing

Previous article

Promgen – Prometheus config generator

Next article

You may also like


Leave a reply

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

More in Hacking