Full Report
Firmware analysis is an essential part of security research and targeted search for vulnerabilities in IoT products. This article examines conventional methods of dynamic analysis and some less obvious methods.
Analysis Summary
# Research: Dynamic analysis of firmware components in IoT devices
## Metadata
- **Authors:** Kaspersky ICS CERT (Lead researcher: Sergey Anisimov)
- **Institution:** Kaspersky Industrial Control Systems Cyber Emergency Response Team (ICS CERT)
- **Publication:** Kaspersky ICS CERT Technical Portal
- **Date:** July 06, 2022
## Abstract
This research explores the methodologies for performing dynamic analysis on IoT firmware, moving beyond static analysis to identify vulnerabilities that only manifest during runtime. The paper details various levels of emulation—from individual snippets of code to full system emulation—and introduces specialized techniques for handling the "hardware dependency" problem that often stalls IoT security research.
## Research Objective
The primary objective is to systematize the process of dynamic firmware analysis to identify vulnerabilities (such as buffer overflows and logic errors) in IoT devices. The research addresses the challenge of executing firmware code in a virtual environment without the original physical hardware components.
## Methodology
### Approach
The researchers utilized a multi-tiered approach to dynamic analysis:
1. **Snippet/Function Emulation:** Executing specific blocks of code to observe behavior.
2. **User-mode Emulation:** Running individual Linux binaries from the firmware (e.g., a web server).
3. **Full System Emulation:** Simulating the entire operating system and hardware environment.
4. **Hybrid Analysis:** Combining physical hardware with emulated components (Hardware-in-the-loop).
### Dataset/Environment
Tests were conducted on firmware typically found in industrial and consumer IoT devices, specifically targeting MIPS and ARM-based architectures running Linux derivatives.
### Tools & Technologies
- **QEMU:** The core emulator for cross-architecture execution.
- **Unicorn Engine:** For fine-grained CPU instruction emulation.
- **Firmadyne / FirmAE:** For automated full-system emulation.
- **GDB & IDA Pro/Ghidra:** For debugging and remote inspection.
- **Qiling Framework:** For cross-platform instrumentation and emulation.
## Key Findings
### Primary Results
1. **Hardware Dependencies are the Bottle-Neck:** Most dynamic analysis fail because code expects responses from non-existent physical peripherals (NVRAM, GPIO, sensors).
2. **The "Stubs" Strategy:** Creating fake responses for hardware calls is often more efficient than full hardware emulation.
3. **Cross-Architecture Execution:** Dynamic analysis allows researchers to run MIPS/ARM binaries on x86 servers, enabling high-performance fuzzing.
### Supporting Evidence
- Successful identification of vulnerabilities in the communication protocols of common IoT web interfaces by intercepting network traffic within an emulated environment.
- Demonstration of bypassing initialization checks by "patching" hardware detection cycles in the emulator.
### Novel Contributions
- Detailed workflows for **Partial Emulation** using the Qiling framework to skip hardware drivers.
- Methods for **Snapshotting** emulated states to rapidly restart fuzzing processes from specific programmatic checkpoints.
## Technical Details
The research emphasizes the use of **QEMU's User Mode** versus **System Mode**.
- In **User Mode**, only the target binary is run, while the emulator maps system calls to the host OS. This is fast but fails if the binary interacts directly with hardware.
- In **System Mode**, a full kernel and virtual hardware are provided.
- The paper highlights the **Library Hooking** technique: intercepting calls to `libnvram.so` (a common IoT library) and redirecting them to a structured file on the host's disk to satisfy the binary's configuration requirements.
## Practical Implications
### For Security Practitioners
- Practice "Lazy Emulation": Do not try to emulate the whole device if you only need to test one CGI script or network daemon.
- Use `chroot` and QEMU-static to quickly set up a testbed for foreign architectures on Linux.
### For Defenders
- Dynamic analysis reveals how a device behaves under stress (fuzzing), helping vendors identify "silent" crashes that might not trigger a reboot but leave a device in an insecure state.
### For Researchers
- The focus shifted from physical hardware hacking (UART/JTAG) to repeatable, scalable cloud-based firmware fuzzing.
## Limitations
- **Opaque Hardware:** Propitiatory ASICs (Application-Specific Integrated Circuits) remain almost impossible to emulate without the vendor's documentation.
- **Timing Issues:** Some security checks rely on precise hardware timing, which high-level emulators like QEMU cannot perfectly replicate.
## Comparison to Prior Work
While previous research often focused strictly on **Static Analysis** (reading the code), this work advances the field by providing a roadmap for **Dynamic Execution**. It builds on the work of projects like *Firmadyne* but adds manual instrumentation methods for when automated tools fail.
## Real-world Applications
- **Automated Vulnerability Scanning:** Scaling firmware analysis across thousands of IoT product lines.
- **Malware Analysis:** Safely executing IoT botnet samples (like Mirai variants) to observe command-and-control behavior without risking physical hardware.
## Future Work
- Integration of **Symbolic Execution** (e.g., using Angr) with dynamic emulation to solve complex branch conditions automatically.
- Development of more sophisticated "Generic Peripheral Simulators" to handle a wider array of IoT sensors.
## References
- QEMU Documentation: hxxps://www[.]qemu[.]org/
- Qiling Framework: hxxps://qiling[.]io/
- Kaspersky ICS CERT Reports: hxxps://ics-cert[.]kaspersky[.]com/