How to Perform Firmware Extraction and Emulation with EMBA: A Step-by-Step Guide

EMBA automates the complete firmware security workflow by combining format detection, extraction, static analysis, and QEMU emulation into a single Dockerized command that generates actionable HTML reports.

The zhaoxuya520/reverse-skill repository provides comprehensive documentation for IoT security workflows, including detailed methodologies for firmware extraction and emulation with EMBA (Embedded Analyzer). This guide walks through the complete process from environment setup to vulnerability reporting using the exact tooling configurations documented in the repository's firmware-pentest skill.

Installing EMBA from Source

Begin by cloning the official EMBA repository and running the automated installer. According to skills/firmware-pentest/references/emba-automated-analysis.md, the installer handles all dependencies including Docker, QEMU, vulnerability scanners, and CVE databases.

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

The -d flag installs Docker and pulls the required container images, while ./emba --help verifies the binary functions correctly. If the installer reports outdated CVE data, run ./emba_db_update.sh to refresh the vulnerability databases before proceeding.

Preparing Firmware Images with Manual Extraction

Although EMBA can internally invoke extraction tools, manually unpacking the firmware ensures correct filesystem recognition. The methodology documented in skills/firmware-pentest/references/extraction-methodology.md recommends using binwalk for recursive extraction or unblob for deeper recursion into proprietary formats.

# Recursive extraction with binwalk

binwalk -Me firmware.bin

# Alternative: deep extraction with unblob

unblob --depth 10 -d out/ firmware.bin

These commands produce directories like _firmware.bin.extracted/ or out/ containing the root filesystem. Manual extraction is particularly useful when EMBA's automated unpacker fails to recognize compressed segments or non-standard partition layouts.

Configuring EMBA Scan Profiles

EMBA uses scan profiles to determine which analysis modules execute during a run. The repository ships with several predefined profiles located in ./scan-profiles/:

• default-scan.emba: Executes full static analysis plus QEMU system emulation
• quick-scan.emba: Performs rapid static analysis without emulation for initial reconnaissance
• default-scan-no-notify.emba: Full scan without notification modules

Select a profile based on your time constraints and analysis depth requirements.

Executing Firmware Analysis

Full System Emulation Scan

For comprehensive analysis including runtime service detection, execute EMBA with the default-scan profile and enable QEMU emulation. The command below runs EMBA inside Docker (-D), enables multi-threading (-t), activates QEMU emulation (-Q), and generates an HTML report (-W).

sudo ./emba -D \
    -l ./logs/router_v1.2.3 \
    -f ./firmware/router_v1.2.3.bin \
    -p ./scan-profiles/default-scan.emba \
    -t -Q -W

The -l flag specifies the log output directory, while -f points to the target firmware image. This configuration executes the L10 system emulation module, which discovers runtime services like HTTP and SSH that static analysis misses.

Rapid Static Analysis

When you need a quick overview to determine if deeper analysis is warranted, use the quick-scan profile without QEMU emulation.

sudo ./emba -D \
    -l ./logs/quick \
    -f ./firmware.bin \
    -p ./scan-profiles/quick-scan.emba

This mode skips emulation and focuses on S05 firmware details, S09 version detection, and S12 binary protection checks, completing in minutes rather than hours.

Interpreting EMBA Reports

After execution, open logs/<run>/html-report/index.html in a browser to view the aggregated results. As detailed in the reference documentation, the HTML report contains several key sections:

• Summary block: Risk rating and aggregated CVE count
• S05: Firmware architecture and filesystem details
• S09: Software version detection and known vulnerability mapping
• S12: Binary protection mechanisms (NX, ASLR, stack canaries)
• S108: Extracted passwords, certificates, and hardcoded secrets
• L10: System emulation results showing active network services
• F50: Final aggregation of all findings

The F50 section provides a consolidated view of critical vulnerabilities, while L10 reveals runtime behavior only observable through QEMU emulation.

Extending EMBA with Custom Rules

EMBA's modular architecture allows customization by adding rules to specific directories. To enhance detection capabilities, copy custom signatures into the following locations:

# Add custom YARA rules

cp my_rule.yar ~/tools/emba/external/yara/

# Add custom Semgrep rules

cp my_rule.yaml ~/tools/emba/config/semgrep_rules/

Advanced users can modify ~/tools/emba/config/emba_emulator_db.cfg to adjust emulation parameters or add custom modules to the modules/ hierarchy. These modifications persist across analysis runs and integrate seamlessly with the default reporting engine.

Summary

• Docker mode (-D) isolates the analysis environment and prevents host system contamination during firmware extraction.
• Manual extraction using binwalk -Me or unblob ensures proper filesystem unpacking when automated methods fail.
• QEMU emulation (-Q) is essential for discovering runtime services and dynamic vulnerabilities invisible to static analysis.
• Scan profiles control analysis depth, with default-scan.emba providing full coverage and quick-scan.emba offering rapid reconnaissance.
• HTML reports aggregate findings into actionable sections including S05 firmware details, S108 secrets extraction, and L10 emulation results.

Frequently Asked Questions

What is the difference between EMBA's quick-scan and default-scan profiles?

The quick-scan profile executes only static analysis modules without QEMU emulation, completing in minutes to provide a rapid risk assessment. The default-scan profile enables full system emulation via the -Q flag and activates all detection modules, requiring significantly more time but discovering runtime services and dynamic vulnerabilities that static analysis misses.

When should I manually extract firmware before running EMBA?

Manual extraction is recommended when EMBA fails to recognize the firmware format or produces incomplete filesystem structures. Using binwalk -Me or unblob --depth 10 on stubborn images ensures the root filesystem is properly unpacked before EMBA analysis begins, as documented in skills/firmware-pentest/references/extraction-methodology.md.

How does EMBA's QEMU emulation improve vulnerability detection?

QEMU emulation executes the firmware's init system and services in a virtualized environment, allowing EMBA to map active network ports, identify runtime configuration weaknesses, and detect vulnerabilities that only manifest during execution. The L10 module specifically targets these runtime characteristics, providing visibility into services like Telnet, SSH, and web interfaces that static analysis cannot verify.

Where does EMBA store analysis reports and logs?

EMBA writes all output to the directory specified by the -l flag, creating a timestamped subdirectory containing JSON logs, extracted files, and an html-report/ folder. The index.html file within this folder provides the consolidated report interface covering all executed modules from S05 through F50.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}