System emulation

---

With emulation it is possible to move the static only firmware analysis process to the next level.

We call this hybrid firmware analysis.

---

EMBA is using emulation during firmware analysis now for a while. For example, a technique called user-mode emulation is used to emulate applications from the tested firmware to gain new insights. This mechanism improves the version detection capabilities massively. Finally, it results in the best outcome in the identification of known vulnerabilities, exploits and the real-world risk of a firmware. For further details take a look at the documentation here. But, this technique has its limits and is currently only available for our so called 1-day vulnerability detection.

Beside user-mode emulation multiple projects (e.g., firmadyne and FirmAE) started using system emulation of firmware in an automated way and on a broad basis. Inspired by this paper, we started investigating into the new possibilities more in detail and finally decided to integrate basic system emulation mechanisms into EMBA. Starting with this pull request EMBA got an initial integration of the great firmadyne framework.
After a complete rework we published the new and improved system emulation modules in August 2022 with EMBA version 1.1.0 (Las Vegas Edt.). This release is based on the evolution of firmadyne called FirmAE. EMBAs system emulation is not a strict re-implementation of firmadyne or FirmAE, it is more the next generation of it. System emulation can now be used during firmware analysis with EMBA fully automated.

Overview - some facts

• System emulation can now be used during the automated firmware analysis process
• The system emulator is heavily based on firmadyne and FirmAE
• As both projects are not actively maintained any more, we decided to completely reimplement them as EMBA modules
• Automated testing of emulation and basic checks as additional testing modules are realized as L*-modules
• Currently only MIPS and ARM architecture supported
• Multiple improvements of emulation capabilities are already in place
• There is a lot of room for future improvements (e.g., new kernels, more testing modules, ...)

Enhanced EMBA architecture

The basic design principles of EMBA includes a highly modular and flexible architecture. Nevertheless, the new system emulation modules do not fit into the available module structure. With this in mind we created a new live tester module category (modules/L*).

This category includes all system emulation modules. These modules are executed after the usual EMBA standard checking modules (S*) and are able to use the results from these modules. Currently these modules are running in a non-threaded mode. Within this new category EMBA is doing the following tasks:

• Architecture check to evaluate if an appropriate kernel is available
• Iterate through the identified root filesystems
• Create a filesystem for emulation (per root directory)
• Decide which kernel should be used
• Identify possible initial processes (init)
• Identify and create service startup helpers
• An emulation test run for identification of possible network settings
• Setup networking
• Run the firmware in an emulated environment
• Do further analysis of the running system with tools like Nmap, Nikto, cutycapt, Arachni, testssl.sh

Benchmark

For our initial benchmark we used the dataset that was published by the authors of FirmAE (see here).

We tested this dataset with firmadyne and with FirmAE for verification. Afterwards the complete dataset was tested with the fresh implementation from EMBA. The firmadyne and FirmAE tests were confirmed. The EMBA tests were able to confirm a working re-implementation and additionally it was possible to confirm a significant improvement of the emulation results.

Further benchmarks with firmware files not covered by the original FirmAE testset showed a much higher successrate from EMBA compared to firmadyne and FirmAE.

Improved areas

The following overview highlights areas where the EMBA reimplementation was optimized:

• EMBA module architecture: Not multiple scripts in different languages - see here
• EMBA extractor: The EMBA extractor is more powerful compared to a binwalk-only approach

• Multiple root directories: EMBA supports multiple root directories including all identified init scripts/binaries and tests the emulation until an open TCP port is identified or EMBA is running out of possibilities

• rdinit vs. init: If we identify a kernel panic we try the other mechanism

• preInit startup detection: If EMBA does not detect a preInit script startup it tries the other init mechanism
• VLAN detection: Improved VLAN identification and configuration
• New inferService script: Detects more services for startup support
• Check online status: Improved running system and service detection

• Default settings: Always test default settings as fallback if no reachable TCP port was identified (with the automatically identified settings)

• Further analysis: Further analysis tasks are easy to implement with EMBA modules

• Reporting: Final web reporter with improved log coloring

• Qemu archive: EMBA creates a final archive with all needed components included (for later re-run of the emulation and further analysis)

• Support for further architectures:
  • ARM32 soft floating (original FirmAE support)
  • MIPS32le/be (original FirmAE support)
  • ARM32 hard float (new)
  • ARM64 (new)
  • MIPS64v1 (new)
  • x86 (new)

Start a system emulation analysis

The following command shows a useful combination of EMBA parameters for initiating a system emulation analysis:

└─$ sudo ./emba.sh -f ~/firmware.bin -l ~/emba_logs -s -z -t -W -m S24 -Q

• -Q: Enable system emulation modules
• -m S24: Uses the kernel module from the analyzers. The results are improving the system emulation
• -W: Enable web report (not mandatory)
• -s -z -t: Improve output of paths in log, colorize log, threading (all not mandatory, but recommended)

Additionally, there is a scan profile available for enabling system emulation on a default scan:

└─$ sudo ./emba.sh -f  ~/firmware.bin -l ~/emba_logs -p ./scan-profiles/default-scan-emulation.emba 

Further areas of upcoming improvements

• Further Kernels: Porting the instrumented kernel and needed pre-compiled binaries and libraries to more architectures (x86, ARM64, MIPS64, PPC, x64, ...)
• More check modules: Implement further analysis modules (e.g., Nmap, Webapp, Routersploit, Metasploit)
• WARNING: The firmware emulation environment is designed in a way that it simply allows remote code execution by design. So, do not run untrusted firmware images without further security mechanisms in place.

ACK and contribution

Please check out the great work from the original authors of firmadyne here. Also check out the massive improvements of firmadyne by the FirmAE authors here.
We can't thank those people enough for their inspiring work and hope we can carry on the torch with EMBA and if you want to help us in improving this new feature, then think about what is still missing and implement it. We are waiting for your contributions or your inspiring ideas and valuable bug reports.