Attify's Firmware Analysis Toolkit (FAT) is a Rust research platform that classifies unknown firmware, extracts embedded filesystems, traces taint through binaries and shell scripts, and rehosts images under QEMU for authorized security assessments.
| Tool | attify/firmware-analysis-toolkit — Rust-based firmware security research platform with identification, extraction, taint analysis and QEMU emulation, ~1615 stars |
| Category | Firmware analysis and reverse engineering toolkit |
| Primary Use | Triage of unknown firmware images, filesystem extraction, ELF taint tracing, BMC flash inspection and QEMU-based emulation in a lab |
| Safe Use | Intended for authorized security assessments, firmware research labs, training (Attify's Offensive IoT Exploitation course) and defensive auditing of devices you own or are contracted to test; the README explicitly states authorization is the operator's responsibility |
| Telemetry Note | Purely offline static analysis and local emulation; defenders should note that emulated vendor services are untrusted code, and SARIF output (--sarif --fail-on-warning) integrates findings into CI pipelines for defensive monitoring |
attify/firmware-analysis-toolkit, marketed as FAT, positions itself as a full-lifecycle research platform for firmware security across IoT devices, robotics, mobile handsets and what the README calls Physical AI. Written in Rust and maintained by adi0x90 under the Attify banner, it grew out of the firm's Offensive IoT Exploitation training rather than out of an academic prototype, which shapes its workflow-first design. The stated ambition is unusually candid: the tool is meant to act as a cognitive amplifier for experienced researchers while remaining approachable to newcomers. With roughly 1615 stars and an active release cadence, it is one of the more serious entries in the firmware tooling space.
The feature matrix in the README is broad but coherent. FAT claims the ability to classify unknown blobs and directories, including containers, compressed members, high-entropy regions and candidate MCU signals; to extract filesystems from firmware images; to map trust-relevant code; to trace taint through binaries; and to coordinate QEMU emulation. The classification targets are diverse: firmware image headers and update envelopes, BMC flash images with FIT hash and signature metadata, extracted Linux filesystems, ELF binaries, bare-metal and MCU images with vector tables and memory maps, Edge AI artifacts such as TFLite, ONNX and Qualcomm DLC models, APK files, and even source repositories. This breadth is the toolkit's defining characteristic — it tries to be the first tool you point at any unknown artifact.
Installation is conventional for a Rust project. You can grab a binary bundle from the GitHub Releases page, or build from source with Rust 1.91 or newer using cargo build --release --locked followed by cargo install --path crates/fat_cli --locked. A runtime data bundle must then be compiled with python3 scripts/build-runtime-data-bundle.py and installed via fat data install. A one-shot ./scripts/install.sh --install-system-deps script exists for supported hosts, and Arch Linux users get dedicated prerequisite instructions in INSTALL.md. The fat doctor command appears to serve as a sanity check that the environment is complete before real work begins.
The command surface follows a pipeline mental model: identify, extract, analyze, preflight, emulate. fat $firmware is shorthand for fat identify --file $firmware, producing a compact structural overview, with --details adding supporting tables. From there, fat new, fat extract, fat analyze, fat preflight and fat emulate --project carry an image from raw blob to running emulation. This linear progression mirrors how experienced firmware analysts actually work, and the README's example chaining the five commands over .fat-projects/firmware makes the intended rhythm explicit.
BMC inspection is the most distinctive recent addition. fat inspect bmc --file $flash.mtd parses layout, FIT authentication metadata and stored U-Boot environments, with native JFFS2 reconstruction before nested decompression. Notably, the README is careful about epistemic limits: FIT signatures are reported as stored metadata only, and cryptographic validity plus hardware boot enforcement are explicitly not tested. That kind of honest scoping recurs across the documentation, including a dedicated docs/epistemics.md explaining what FAT output does and does not prove — a rarity in offensive tooling and a genuine asset for report writing.
The binary analysis side leans on radare2 integration via fat r2-triage, producing JSON triage of imports, exports and handler tables. The taint engine is where the static work gets interesting: fat taint --file ./www/cgi-bin/diag.cgi --summary performs source-to-sink analysis on ELF binaries, fat taint --lang shell extends the same idea to shell scripts across a whole extracted rootfs, and fat taint-cross --rootfs pushes dataflow reasoning across component boundaries with user-supplied --source-profile and --state-profile YAML models. For stripped binaries, the documented strategy is sink discovery first (fat sink-discovery), then fat instrument-hooks --from-sinks to emit a hooks.yaml that fat emulate consumes, connecting static findings to runtime observation at the same addresses.
Filesystem-wide evidence sweeps round out the static toolkit. fat tree --profile inventory builds a full inventory, fat search --profile credentials hunts for credential material with context lines, fat startup-map --profile cloud-tls traces startup intent, fat crypto-census enumerates cryptographic material, and fat trust-map highlights trust-bearing binaries. There is even a source-backed query mechanism: fat invariant query --rule 'Every privileged override method must call enforcePermission()' runs invariant checks against fixtures, paired with fat patch check and fat verify helpers. This suggests the maintainers are targeting not just one-off audits but repeatable, CI-embeddable analysis.
Indeed, CI integration is first-class: BMC inspection supports --sarif --fail-on-warning, emitting SARIF findings that gate pipelines, and both inspection workflows support --json for full structured reports. On the emulation side, fat rehost profiles list enumerates rehosting packs including bmc-romulus and an ASUS vendor-kernel profile, with documented Redfish readiness checks and debug endpoints in docs/bmc-emulation.md. Debug commands like fat debug redfish-session test ReadOnly role enforcement and session revocation against disposable lab accounts with an administrator positive control — a defensive posture baked into the tooling itself.
The Security section deserves emphasis because it is unusually direct for this category: emulation executes untrusted vendor code, SECURITY.md must be reviewed before processing untrusted images or exposing an emulated service to a network, and authorization for targets is the operator's responsibility. In practice this means FAT belongs in an isolated lab VM, with emulated services kept off production networks — the rehosted BMC stacks in particular are full vendor userspaces running attacker-researcher-controlled inputs.
Licensing is worth flagging before adoption: FAT 2.0 is source-available under FSL-1.1-ALv2, not a standard open-source license, with details in LICENSING.md and third-party notices separated out. The license field reads NOASSERTION on GitHub, so teams doing commercial assessments should read the actual terms. The repository's documentation depth — separate guides for architecture, capabilities, epistemics, commands, and BMC workflows — signals a project built for long-term professional use rather than a conference artifact.
For authorized professionals, FAT fits naturally into hardware security assessments of devices you own or are contracted to test: acquiring firmware, identifying it, extracting the filesystem, triaging trust boundaries, and confirming findings dynamically under emulation. The combination of static taint analysis, stripped-binary sink discovery, and instrumented emulation in one coherent CLI reduces the friction of stitching together binwalk, radare2 and custom QEMU harnesses. The one caveat the README itself makes clear is that its outputs are evidence, not proof — the epistemics guide exists precisely to keep analysts honest about what identification, extraction and emulation can and cannot establish.
attify/firmware-analysis-toolkit.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.