EMBA: the firmware security analyzer that runs as a Bash pipeline

What EMBA solves for people who have to open a firmware image

A firmware image arrives as a blob. Before anyone can say whether it is dangerous, someone has to find the filesystem inside it, mount it, work out which binaries and scripts are present, identify the components and their versions, and then decide what to look at first. EMBA is built to absorb that first pass. The README describes it as "the central firmware analysis and SBOM tool for penetration testers, product security teams, developers and responsible product managers", and lists the target findings plainly: insecure binaries, old and outdated software components, potentially vulnerable scripts, and hard-coded passwords. The stated posture matters as much as the feature list. EMBA says it provides as much information as possible so that the tester decides on focus areas, and that the tester is responsible for verifying and interpreting the results. That is the honest framing for a tool of this kind: it narrows the search space, it does not close the case. If your job is to hand a product team a list of components and a set of leads, the output shape fits. If your job is to produce a signed attestation with no human in the loop, it does not.

The pipeline: extraction, static analysis, emulation, SBOM, report

The README describes the process as a sequence: firmware extraction, static analysis, dynamic analysis via emulation, SBOM building, and finally a web based vulnerability report. That ordering is the architecture. Extraction has to succeed before anything else means much, because every later module reads from the extracted filesystem rather than from the original blob. Static analysis then works over files, binaries and scripts. Emulation is the part that separates EMBA from a pure unpacker: it boots a system in an emulated environment to observe behaviour that static reading cannot show. The SBOM step turns the discovered components into a component inventory, and the report step assembles the findings into something a human can browse. The project ships separate scan profiles for these intents rather than one default: the README shows a default scan profile, a default SBOM profile, and a system-emulation scan profile. Choosing the profile is choosing how much of that pipeline you want to run, and the emulation profile is the one that needs the most from the host. The repository layout reflects the same modular split: there is a modules/ directory, a config/ directory, a scan-profiles/ directory, and a helpers/ directory, with the emba script and an installer.sh at the top level.

Installing EMBA and running a first scan

The README gives the installation as a clone followed by the installer script with the -d flag, run under sudo. The README also states that you should have installed all dependencies with the installation script and met the prerequisites before running EMBA, and points at the wiki Installation page for both.

git clone https://github.com/e-m-b-a/emba.git
cd emba
sudo ./installer.sh -d

After that, a first scan uses the emba entry point with a log directory, a firmware path and a scan profile. The README's quick start for the default profile is:

sudo ./emba -l ~/log -f ~/firmware -p ./scan-profiles/default-scan.emba

The three flags are the whole interface you need to start: -l sets where logs and results go, -f points at the firmware image, and -p selects the profile file. The README documents two more profiles in the same shape. The SBOM profile is ./scan-profiles/default-sbom.emba, and the emulation profile is ./scan-profiles/default-scan-emulation.emba. Both take the same -l and -f arguments. Expect the run to take a long time on a real image; the README does not publish a duration, and the amount of work depends on the profile and the image. When it finishes, the log directory holds the results and the web report, which the README describes as the final stage of the pipeline. The project publishes an interactive demo report on its site if you want to see the output shape before installing anything.

The host requirements are the real adoption cost

EMBA is not a library you add to a build. It is a Linux tool that installs a large dependency set onto the machine, and the Docker path is explicit about how much privilege it wants. The repository's docker-compose.yml runs the emba service with privileged: true, with a comment stating that all pre-checker mount modules need privileged mode. It adds SYS_ADMIN and a /dev/fuse device, mounts /dev from the host, and uses tmpfs entries with exec for /tmp and for several tool caches, with comments naming binwalk, cwe_checker, opengrep and capa as the reasons. The Dockerfile builds from kalilinux/kali-rolling and runs the installer inside the build with the -s -D flags, which means the image is large and the build pulls a toolchain rather than a single binary. The practical consequence is that this does not belong on a shared CI runner you do not control, and it does not belong on a laptop you also use for other work without thinking about it. The compose file also defines a second service, emba_quest, with read_only: true and a different tmpfs set, which suggests the project has a way to run a more restricted variant, but the truncated compose file does not show the full configuration. Read the wiki before assuming the restricted mode covers your case.

Where EMBA is the wrong tool

Two cases stand out. The first is firmware that is not a Linux system. The project's topics list embedded-linux and embedded-systems, and the extraction and emulation stages are built around the shape of a Linux firmware image. A bare-metal microcontroller image, a proprietary RTOS blob with no filesystem, or a vendor format that the extraction modules do not recognise will produce thin results, and emulation of a system that is not Linux will not boot. The second case is anything that needs a deterministic, fast, per-commit answer. The pipeline is a full analysis run over an image, with emulation in one of the profiles and a dependency set that includes a Ghidra cache and a Metasploit directory in the container's tmpfs list. That is a heavyweight process, and the README frames the output as material for a tester to verify and interpret rather than a pass or fail gate. If you want to fail a build on a known-bad package version, a package level scanner is the cheaper instrument. EMBA answers a different question: what is in this image, and what in it looks exploitable.

How EMBA differs from a plain extraction toolchain

The obvious alternative is to assemble the pieces yourself: binwalk to extract, a version scanner over the extracted files, and a separate emulation setup such as FirmAE or a hand-built QEMU environment. That approach gives you full control and no privileged container, and for a single known format it can be faster to set up. The difference in approach is that EMBA treats the stages as one pipeline with a shared result set and a single report, and it ships the profiles as named files rather than as a set of instructions you wire together. The trade-off is the opposite of the one you get from hand-assembly: you accept a large dependency surface, a privileged container and the project's own choices about which tools run, in exchange for not maintaining the glue. The README also notes that EMBA is part of the OWASP Firmware Security Testing Methodology, which is a statement about where it fits in a process rather than about its internals. If your team already has a working extraction and emulation setup tuned to your hardware, EMBA is more likely to duplicate it than to replace it.

Maintenance, licensing and what a GPL-3.0 tool implies for internal use

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and named: v2.0.4-summer_edition on 2026-09-21, v2.0.3-legacy-time on 2026-07-21, and v2.0.2-big-2k on 2026-06-08. The docker-compose.yml pins the image tag embeddedanalyzer/emba:2.0.4a, so the container path gives you a version you can hold still while the repository moves. Upgrade cost is dominated by the dependency set, not by the emba script itself: the Dockerfile installs the toolchain at build time, and the compose file allocates tmpfs for tool caches, so a rebuilt image is the clean way to move versions. The licence is GPL-3.0, stated in the README and present as a LICENSE file. For internal analysis that is normally unproblematic, but if you plan to embed EMBA in a product you distribute, or to link its code into a proprietary tool, the copyleft terms are the thing to read. This is a description of the licence, not legal advice; take it to counsel if distribution is on the table.

Editorial conclusion

Adopt EMBA if you already triage embedded Linux images and want extraction, static checks, emulation and an SBOM in one pipeline, and if you can give it a privileged Linux host. Do not adopt it if you need a lightweight library to embed in a build, or if you cannot run privileged containers. Before committing, verify the installer completes on your base image, that your firmware image is one the extraction modules recognise, and that the scan profile you pick matches the question you are asking.

Frequently asked questions

Official sources

1. e-m-b-a/emba on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases