# firmware-analysis-toolkit: a firmware security platform that publishes what its results do not prove

> FAT is a Rust workspace for classifying unknown firmware, extracting filesystems, tracing taint and rehosting binaries under QEMU. Its distinguishing feature is not the command count but a document that tells you which of the results are evidence and which are guesses, and a licence that is source available rather than open source.

**attify/firmware-analysis-toolkit** — Firmware security research platform combining binary analysis, taint tracing, and emulation across IoT, edge AI, mobile devices, and robotics.

- Repository: https://github.com/attify/firmware-analysis-toolkit
- Stars: 1,609 · Forks: 288
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/attify-firmware-analysis-toolkit

## The epistemics document is the most important file in the repository

Most security tools ship a list of what they find. This one ships a document explaining what its findings do and do not prove, and that single choice does more for trust than any amount of feature marketing. The guide index lists an item described as how to read the output, what results do and do not prove, and it sits alongside the architecture and capabilities guides rather than buried in a wiki. For a tool that classifies unknown firmware, extracts filesystems and traces taint, this matters because almost every output it produces is an inference. A recovered string is a fact. A crypto-census entry is a fact about the bytes. A trust map, a startup map and a taint summary are judgements layered on top of those facts, and a tool that does not draw that line will have its heuristics quoted as findings. Publishing that boundary is the behaviour of a tool built by people who have had to defend their output to someone. It also reframes adoption. You are not choosing whether the tool finds things, you are choosing how much weight each category of output can bear in your workflow, and the document is where that is decided. Read it before the command reference, because the command reference will otherwise flatten every line into looking equally trustworthy.

## A taint pipeline that hands static addresses to a dynamic hook

The interesting mechanism in this toolkit is how it handles binaries that have been stripped, where you cannot rely on function names to know what reaches a dangerous operation. The quick reference lays out a six-step chain for exactly this case. A binary triage pass produces a report. A sink-discovery pass writes the candidate dangerous operations to a file. A handler-table pass writes the dispatch tables to another file. The taint pass consumes the candidate file as its sink list and writes a taint report. And then, rather than stopping at the static result, an instrumentation pass converts those same discovered addresses into runtime hooks, which the emulation pass then uses while the code runs. The elegance is that the static and dynamic phases share identifiers. The addresses found by static analysis are the addresses hooked at run time, so a sink you found without a symbol table is the sink you can watch being called. That closes a loop most triage tooling leaves open, where static findings and dynamic observation are separate artefacts you have to reconcile by eye. That chain is the whole workflow, and the ordering matters because each stage consumes the previous stage's output file: 

```bash
fat r2-triage --file ./usr/sbin/httpd --json
fat sink-discovery --file ./usr/sbin/httpd --json > sinks.json
fat handler-table --file ./usr/sbin/httpd --json > handlers.json
fat taint --file ./usr/sbin/httpd --sink-candidates sinks.json --json > taint.json
fat instrument-hooks --from-sinks sinks.json --output hooks.yaml
fat emulate --project .fat-projects/firmware --instrument hooks.yaml
```

The same pattern extends across languages, with taint passes for shell scripts that read a whole extracted filesystem and can apply profiles. If you work on firmware with stripped binaries, this pairing of sink discovery, handler tables and instrumentation is the feature that would make you keep the tool, and it is the thing to test on a sample you already understand before you trust it on one you do not.

## Unusual scope: MCU vector tables and quantized Edge AI files

The list of what the toolkit can analyse is broader than a typical firmware tool and contains a few entries you would not expect. It goes beyond the obvious cases of firmware images with headers, partitions and bootloaders, and extracted Linux filesystems, to cover bare-metal and microcontroller images by reading vector tables, memory maps, peripheral hints and flash-write authority, which is how you work out where a device can be made to write code. It also handles ELF binaries with handler tables and source-to-sink taint. Two entries stand out. The first is Edge AI artifacts, which the guide lists as quantized model formats and runtime files, covering common mobile inference formats, the standard interchange formats for trained graphs, and a vendor-specific container format. Looking for model files inside a firmware image is a real task when the device ships a learned model, and it is not something the mainstream firmware tools do. The second is Android application packages, handled for inventory and capability chains. Robotics and physical AI appear in the framing, and the model-artifact support is consistent with that. The scope is not a marketing claim here, it is a list of input types, which makes it testable. Run it against an image you know well and see which of these categories it actually recognises, because a scope list tells you what the author intended to cover and only your own test tells you where the coverage ends.

## Fourteen workspace crates, and lints switched off on purpose

The build is a Cargo workspace with fourteen member crates, and the names are the architecture. There is a core crate, a CLI crate, and separate crates for the analysis, bootloader, packaging, backend, emulation, extraction, family, query, taint and plugin stages, plus a plugin API and a plugin host. That last pair is the extension story: a plugin API defines the surface, a plugin host loads implementations, and a backend crate abstracts the engines underneath, which together mean the toolkit is built to be extended rather than to be a single closed binary. Two details in the workspace file show how the project is actually maintained. First, the minimum supported Rust version is pinned, and the readme tells you to build with that version or newer and to pass the lockfile flag, which is a discipline signal, since it means the committed dependency versions are the intended ones. Second, and more revealing, the workspace turns off three classes of lint with a comment explaining that they are deliberate design choices rather than defects, naming rich command signatures, large domain error enums and expressive graph types, and stating that continuous integration still treats the rest as errors. A project that documents the lints it disables and why is a project where you can trust its warnings about everything else. The quick start builds from source and installs the CLI crate from the workspace, with the lockfile honoured on both steps and a doctor command as the first thing to run: 

```bash
git clone https://github.com/attify/firmware-analysis-toolkit.git
cd firmware-analysis-toolkit
cargo build --release --locked
cargo install --path crates/fat_cli --locked
fat doctor
```

The development guide and the architecture guide are both linked, so if you plan to extend this with a plugin the intended seam is documented rather than reverse-engineered.

## Source available under a functional licence, not open source

The licence is the decision to read first, because it changed. The readme states that the 2.0 line is source available under a functional source licence variant, and the workspace metadata records the same identifier. The repository holds a licence file, a separate licensing document with more detail, a directory of licence texts, and a third-party notices file. That is a company-maintained project, and the current 2.0 release is explicitly source available rather than open source. This is not a nitpick. A functional source licence typically grants you the right to use, study and modify the code but reserves a commercial dimension, and it is designed so the project can later be released under an open licence. The effect on you is that adoption is a business decision as much as a technical one, and the licensing document is where the terms are. The third-party notices file matters just as much here as the licence itself, because a toolkit that bundles a reverse-engineering library, a QEMU build and a set of analysis libraries is distributing all of them under their own terms, and the notices file is your map of what you are shipping. The previous generation of this project was distributed under a permissive open-source licence, so if you are reading older material about FAT, the licence you are reading about is not the one that applies to 2.0.

## QEMU binaries tagged in 2022, then a 2.0 alpha in 2026

The version history is unusual and worth understanding before you pin anything. The two most recent tagged releases besides the current one are not releases of the toolkit at all; they are tagged static QEMU binaries for three architectures, both from late 2022. The newest toolkit artefact is a 2.0 alpha from September 2026, which matches the last commit. So the practical picture is a project that spent several years without tagging the toolkit itself and has just published its first 2.0 alpha, with a significant gap of time between the last tagged binary bundle and now. The 2.0 rewrite is why the licence changed and why the workspace is structured as it is, so the alpha is a genuine new architecture rather than an incremental release. For a tool you might run against a client engagement, that gap has two consequences. First, there is no long release history to draw confidence from, so pin the specific alpha you evaluated and record it, because a 2.0 alpha will move under you. Second, the versioned QEMU binary tags are a convenience, not the product, and do not read a 2022 binary tag as the version of the toolkit. If reproducibility matters to your work, capture the exact build you tested rather than tracking a branch, and lean on the fact that the build honours the lockfile.

## Emulation runs untrusted vendor code, and the tool says so

The security section is three lines and they are the most important operational guidance in the readme. Emulation executes untrusted vendor code, so you are told to read the security document before processing untrusted images or before exposing an emulated service to a network. And you are told that having authorisation for your targets is your responsibility. That last line is a firm statement of the intended use, and it matches the training context the project is built around, which is authorised offensive IoT work rather than indiscriminate scanning. The practical model is a local, offline workflow. You feed the tool an image, it produces a project directory, and you rehost the relevant binary under an instrumented emulator driven by hooks derived from your own static analysis. Nothing in the workflow reaches out to the target's network, which is what makes firmware research safe to do on a laptop rather than only in a lab, and it is a meaningfully different risk profile from a scanner that talks to a live device. The second warning is the one to take seriously in practice. Rehosting a vendor binary means executing code that was written to run with elevated privilege, and the hooks you generate are derived from automated sink discovery, so a mis-identified sink is a hook in the wrong place. Isolate the emulated run, review the hooks before you attach them, and read the security document rather than inferring the model from the happy path in the quick start.

## Conclusion

Adopt FAT if you need to move from an unknown firmware blob to emulated, taint-traced evidence quickly and you have the authorisation to work on the target, because the classification, extraction, taint and emulation stages are chained into a single pipeline and the tool ships QEMU rehosting to make dynamic work practical on stripped binaries. Do not adopt it expecting open-source governance, because the current 2.0 line is source available under a functional source licence and a separate notices file governs the bundled third-party components. Three things to verify before you commit. Read the epistemics document first, because it tells you which outputs are proof and which are heuristics, and that determines how much you can defend in a report. Pin a tagged release rather than the alpha, given the gap since the previous tagged binaries. And treat emulation as hostile code execution, reviewing the security document before you ever point it at an untrusted image or expose an emulated service to a network.

## FAQ

### How do I build and install the Attify Firmware Analysis Toolkit?

Clone the repository, build with a recent Rust toolchain using the lockfile, and install the CLI crate from the workspace, then run the doctor command. There is also a one-shot installer script that can pull system dependencies, with a separate install document for more customisation.

### What is the licence of FAT 2.0?

The current 2.0 line is source available rather than open source, under a functional source licence variant recorded in the workspace metadata. The repository ships a licence file, a separate licensing document with detail, and a third-party notices file for the bundled components. Earlier versions were under a permissive open-source licence.

### What can FAT analyse?

Unknown blobs and directories, firmware images with headers and partitions, extracted Linux filesystems, ELF binaries, bare-metal and microcontroller images, Edge AI artifacts including quantized model formats, Android application packages, and source repositories.

### How does FAT handle stripped binaries?

It chains static discovery with dynamic instrumentation. Binary triage, sink discovery and handler-table passes produce candidate addresses without relying on symbols, the taint pass consumes those as sinks, an instrumentation pass turns the same addresses into runtime hooks, and the emulation pass runs the code with those hooks attached.

### What are the security considerations for FAT?

The readme states that emulation executes untrusted vendor code, tells you to read the security document before processing untrusted images or exposing an emulated service to a network, and makes it your responsibility to have authorisation for the targets you work on.

## Sources

- [attify/firmware-analysis-toolkit on GitHub](https://github.com/attify/firmware-analysis-toolkit)
- [Issues](https://github.com/attify/firmware-analysis-toolkit/issues)
- [README](https://github.com/attify/firmware-analysis-toolkit/blob/master/README.md)
- [Releases](https://github.com/attify/firmware-analysis-toolkit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/attify-firmware-analysis-toolkit