11 Finding Software Bugs in Embedded Devices
195
11.4.1 Device-Interactive Dynamic Analysis Without
Emulation
When the device is present for analysis, the simplest form of device-interactive
dynamic analysis is to test the devices in a “black-box” manner. The general
idea of this approach is to setup and run the devices under analysis as in normal
operation (e.g., connect to Ethernet LAN, WLAN, smartphone), and then test it
with various tools and manual techniques (e.g., generic or specialized fuzzers,
web penetration) and observe their behavior via externally observable side-effects
such as device reboots, network daemon crashes, or XSS artifacts [439]. Similar
approaches and results were reported by several independent and complementary
works [259, 280, 292].
While being simple and easy to perform, this type of dynamic analysis has certain
limitations, some of which are due to the “black-box” nature of the approach. For
example, it is challenging to know what is happening with the entire system/device
while the dynamic analysis is performed, i.e., the introspection of the system is
missing or is hard to achieve. Also, in this approach it is not easy to control in
detail what specifically is being executed and analyzed, the analysis being mostly
driven by the data and actions fed to the device. In addition to this, some types of
vulnerabilities might not have side-effects that are immediately [430] or externally
visible (e.g., a crash of a daemon which does not necessarily expose a network port),
therefore those bugs could be missed or misinterpreted during the analysis.
11.4.2 Device-Interactive Dynamic Analysis with Emulation
As an extension to the aforementioned approach, emulation can be coupled with
device-interactive dynamic analysis to provide the required depth and breadth,
therefore outperforming other static or dynamic analysis methods. The general idea
of this approach is to split the execution of the embedded firmware between the
analysis host and the actual running device. The analysis host is connected to the
device via a debug (e.g., JTAG) or serial (e.g., UART) interface. Therefore one
requirement is that the device under analysis must provide at least such an interface,
whether documented or not. The analysis host then runs a dynamic analysis
environment which is typically an emulator (e.g., QEMU-based) augmented or
extended with additional layers and plugins such as symbolic execution and taint
analysis. The analysis host has access to the execution and memory states both for
the emulator and for the running device. The firmware is being analyzed first in
the extended emulator environment. During the firmware emulation and analysis,
certain parts of the analyzed firmware are transferred for execution by the analysis
host from the emulator to the running device. This is sometimes required, for
example, when the firmware needs to perform an I/O operation with a peripheral
present on the devices but not in the emulator. The execution and state transfer to
195
11.4.1 Device-Interactive Dynamic Analysis Without
Emulation
When the device is present for analysis, the simplest form of device-interactive
dynamic analysis is to test the devices in a “black-box” manner. The general
idea of this approach is to setup and run the devices under analysis as in normal
operation (e.g., connect to Ethernet LAN, WLAN, smartphone), and then test it
with various tools and manual techniques (e.g., generic or specialized fuzzers,
web penetration) and observe their behavior via externally observable side-effects
such as device reboots, network daemon crashes, or XSS artifacts [439]. Similar
approaches and results were reported by several independent and complementary
works [259, 280, 292].
While being simple and easy to perform, this type of dynamic analysis has certain
limitations, some of which are due to the “black-box” nature of the approach. For
example, it is challenging to know what is happening with the entire system/device
while the dynamic analysis is performed, i.e., the introspection of the system is
missing or is hard to achieve. Also, in this approach it is not easy to control in
detail what specifically is being executed and analyzed, the analysis being mostly
driven by the data and actions fed to the device. In addition to this, some types of
vulnerabilities might not have side-effects that are immediately [430] or externally
visible (e.g., a crash of a daemon which does not necessarily expose a network port),
therefore those bugs could be missed or misinterpreted during the analysis.
11.4.2 Device-Interactive Dynamic Analysis with Emulation
As an extension to the aforementioned approach, emulation can be coupled with
device-interactive dynamic analysis to provide the required depth and breadth,
therefore outperforming other static or dynamic analysis methods. The general idea
of this approach is to split the execution of the embedded firmware between the
analysis host and the actual running device. The analysis host is connected to the
device via a debug (e.g., JTAG) or serial (e.g., UART) interface. Therefore one
requirement is that the device under analysis must provide at least such an interface,
whether documented or not. The analysis host then runs a dynamic analysis
environment which is typically an emulator (e.g., QEMU-based) augmented or
extended with additional layers and plugins such as symbolic execution and taint
analysis. The analysis host has access to the execution and memory states both for
the emulator and for the running device. The firmware is being analyzed first in
the extended emulator environment. During the firmware emulation and analysis,
certain parts of the analyzed firmware are transferred for execution by the analysis
host from the emulator to the running device. This is sometimes required, for
example, when the firmware needs to perform an I/O operation with a peripheral
present on the devices but not in the emulator. The execution and state transfer to