# How to Perform Firmware Extraction and Emulation with EMBA: A Step-by-Step Guide > Learn firmware extraction and emulation with EMBA. This guide details how EMBA automates security analysis and generates HTML reports for actionable insights. - Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) - Tags: how-to-guide - Published: 2026-08-08 --- **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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/references/emba-automated-analysis.md), the installer handles all dependencies including Docker, QEMU, vulnerability scanners, and CVE databases. ```bash 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/./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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/firmware-pentest/references/extraction-methodology.md) recommends using **binwalk** for recursive extraction or **unblob** for deeper recursion into proprietary formats. ```bash # 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`). ```bash 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. ```bash 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//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: ```bash # 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/index.html) file within this folder provides the consolidated report interface covering all executed modules from S05 through F50.