# How the Firmware-Pentest Pipeline Uses EMBA and Firmadyne for Automated IoT Security Testing

> Discover how the firmware-pentest pipeline automates IoT security testing using EMBA for analysis and Firmadyne for emulation. Accelerate your vulnerability assessments.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-20

---

**TLDR:** The firmware-pentest pipeline orchestrates EMBA for static analysis and CVE detection, then hands off to Firmadyne for full-system emulation, creating an automated "extract → analyze → emulate → fuzz" workflow for IoT firmware security assessment.

The `reverse-skill` repository defines a structured, OWASP-FSTM-inspired pipeline that moves firmware images from raw extraction through automated vulnerability discovery to runtime exploitation testing. This article examines how **EMBA** (Embedded Analyzer) and **Firmadyne** serve as the backbone of this workflow, based on the canonical implementation in [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) and supporting documentation.

## Pipeline Architecture: Four Stages

The firmware-pentest skill organizes security testing into four sequential phases, with EMBA and Firmadyne anchoring the middle stages.

### Stage 1: Firmware Extraction

Before either tool can operate, the raw firmware image must be unpacked. The pipeline supports **binwalk v3** or **unblob** as extraction engines, as documented in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md) at line 26. This yields a mountable root filesystem that downstream tools consume.

### Stage 2: Static Analysis with EMBA

EMBA performs the "heavy lifting" of automated static analysis. According to [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) (lines 64-68), EMBA conducts a one-line scan that produces comprehensive HTML reports covering approximately **80% of routine analysis tasks**.

**Core EMBA capabilities** (from [`skills/firmware-pentest/references/emba-automated-analysis.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/references/emba-automated-analysis.md), lines 5-94):

- **Signature-based secret detection**: Hard-coded passwords, private keys, and API credentials
- **Dangerous function identification**: Insecure `system()`, `strcpy()`, and similar patterns
- **CVE cross-referencing**: Automatic matching of discovered binaries against known vulnerability databases
- **Extensible rule sets**: Custom signatures for proprietary backdoors or organization-specific threats (lines 157-161)

**Critical constraint**: EMBA is **Linux-only**. It requires the extracted rootfs to be mountable on a Linux host, as noted in [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) (lines 333-338). This design choice reflects EMBA's dependency on standard Linux filesystem tools and kernel features for accurate analysis.

### Stage 3: System Emulation with Firmadyne

After EMBA completes static analysis, the pipeline transitions to **Firmadyne** (or the newer **FAT** module) for dynamic testing. As referenced in [`skills/routing_zh.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing_zh.md) (line 228), Firmadyne spins up a **QEMU-based virtual device** that recreates the original hardware environment.

**Firmadyne's role in the pipeline**:

- Reconstructs the boot process to expose runtime behavior invisible to static analysis
- Enables inspection of network services, daemon interactions, and privilege-escalation paths
- Provides a live target for fuzzing and exploitation stages

This emulation bridge connects the "analyze" and "attack" phases, transforming static findings into verifiable runtime vulnerabilities.

### Stage 4: Fuzzing and Exploitation

With a live emulated device, the pipeline invokes **AFL++** or alternative fuzzers. The [`skills/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/SKILL.md) file (line 46) documents this as the final link in the "extract → EMBA → emulate → fuzz" chain, with [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) (lines 212-218) detailing how fuzzing discovers bugs that static analysis misses.

## Running the Complete Pipeline

The following commands reproduce the full workflow from a directory containing `firmware.bin`:

```bash

# 1️⃣ Extract the firmware

binwalk -e firmware.bin

# Alternative: unblob firmware.bin

# 2️⃣ Run EMBA static analysis

cd _firmware.extracted/
emba -i . -o ../emba-report.html

# 3️⃣ Launch Firmadyne emulation

cd ../firmadyne/
./run.sh -r ../_firmware.extracted/

# 4️⃣ Attach AFL++ for service fuzzing

afl-fuzz -i inputs -o findings -- ./target_binary -p 8080

```

### Reviewing EMBA Output

The HTML report aggregates findings across multiple categories:

```bash

# Open generated report

xdg-open emba-report.html

# Key sections to review:

# - "Hard-coded passwords"

# - "Private keys"

# - "CVE matches"

# - "Dangerous functions"

```

### Interactive Firmadyne Session

For manual exploration of the emulated environment:

```bash
qemu-system-arm \
  -M vexpress-a9 \
  -kernel vmlinux \
  -initrd rootfs.cpio.gz \
  -nographic

```

## Design Philosophy: Automation-First with Manual Override

The pipeline emphasizes **automation first** while preserving human judgment for critical decisions. As stated in [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) (lines 269-276), this means:

- EMBA and Firmadyne run unattended for bulk processing
- Analysts manually triage high-impact findings (CVE relevance confirmation, exploitability verification)
- Custom EMBA rules allow organizational threat intelligence integration

## Summary

- **EMBA** handles static analysis and CVE detection, producing actionable HTML reports from extracted firmware filesystems
- **Firmadyne** provides QEMU-based emulation, enabling runtime analysis and fuzzing that static tools cannot achieve
- The pipeline follows an **OWASP-FSTM structure**: extraction → EMBA analysis → Firmadyne emulation → AFL++ fuzzing
- EMBA's **Linux-only requirement** dictates acceptable extraction targets and host environments
- Both tools support **extensible configurations**: custom EMBA signatures and Firmadyne emulation parameters

## Frequently Asked Questions

### What firmware formats can the EMBA and Firmadyne pipeline process?

The pipeline accepts any format that binwalk v3 or unblob can unpack, including common vendor formats like `.bin`, `.img`, `.trx`, and `.chk`. EMBA specifically requires the extracted content to present as a mountable Linux root filesystem. Non-Linux embedded systems (RTOS-based devices, bare-metal firmware) fall outside EMBA's analysis scope but may still be partially examinable through Firmadyne if QEMU system emulation supports the target architecture.

### Why does EMBA require Linux specifically?

EMBA relies on native Linux filesystem mounting, kernel features for binary analysis, and standard Unix toolchains for signature matching. As documented in [`skills/firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/SKILL.md) (lines 333-338), this dependency enables deep inspection of permissions, symbolic links, and kernel modules that would be opaque or misrepresented through abstraction layers. Running EMBA on non-Linux hosts requires full virtualization of a Linux environment.

### How does Firmadyne differ from EMBA in vulnerability discovery?

EMBA discovers **static vulnerabilities**: hard-coded credentials, known CVEs in binary versions, and dangerous code patterns without execution. Firmadyne enables **dynamic discovery**: runtime service enumeration, protocol behavior analysis, and memory corruption triggering through fuzzing. The tools are complementary—EMBA finds "low-hanging fruit" at scale, while Firmadyne validates exploitability and exposes logic flaws visible only during execution.

### Can EMBA rules be customized for proprietary threat signatures?

Yes. The [`skills/firmware-pentest/references/emba-automated-analysis.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/references/emba-automated-analysis.md) documentation (lines 157-161) describes extensible rule sets that security teams can modify. Custom signatures can target organization-specific backdoors, unique cryptographic implementations, or vendor-specific misconfigurations that standard CVE databases omit.