11 Finding Software Bugs in Embedded Devices
185
who is responsible for the damage caused by compromised smart devices, beyond
the malware author. The device owner may be legally responsible, but often the enduser does not have any means to detect or prevent such compromises, or to apply
a secure configuration. On the other hand, the manufacturers currently often have
no legal liability, and thus no incentive (e.g., economic, legal) to prevent a potential
vulnerability and compromise.
11.1.4 Organization of This Chapter
Solving these problems requires analyzing the software and firmware for the
embedded devices, and identifying and fixing their vulnerabilities. This chapter
describes the possible steps to systematically and consistently achieve this goal.
We first provide a classification of embedded systems that is well adapted to their
analysis. We then describe the possible steps for their analysis. We start with
ways to obtain the software to analyze, which is often a challenge in itself for
embedded devices. We then describe how to perform static analysis on the firmware
packages obtained, which has many advantages such as speed and scalability. We
then describe techniques which can be used to dynamically analyze the firmware,
which in contrast to static analysis has the advantage of larger code coverage and
lower false positive rates.
11.1.5 Classification of Embedded Systems
A general definition of embedded systems is hard to establish [261]. However,
two widely accepted differences separate embedded devices from modern generalpurpose computers, such as ordinary desktop PCs or smartphones, namely: (a)
they are designed to fulfill a specific purpose, and (b) they heavily interact with
the physical world via peripherals. The aforementioned two criteria cover a wide
variety of devices, ranging from hard-disk controllers to home routers, from digital
cameras to Programmable Logic Controllers (PLCs). These families can be further
classified according to several aspects, such as their actual computing power [171],
the extent to which they interact with their computing and physical environment,
their field of usage, or the timing constraints imposed on them.
Unfortunately, these classifications tell us very little about the type of security
mechanisms that are available on a given device. Muench et al. [430] classifies
embedded systems according to the type of operating system (OS) they use. While
the operating system is certainly not the only source of security features, it provides
several security primitives, handles recovery from faulty states, and often serves as a
185
who is responsible for the damage caused by compromised smart devices, beyond
the malware author. The device owner may be legally responsible, but often the enduser does not have any means to detect or prevent such compromises, or to apply
a secure configuration. On the other hand, the manufacturers currently often have
no legal liability, and thus no incentive (e.g., economic, legal) to prevent a potential
vulnerability and compromise.
11.1.4 Organization of This Chapter
Solving these problems requires analyzing the software and firmware for the
embedded devices, and identifying and fixing their vulnerabilities. This chapter
describes the possible steps to systematically and consistently achieve this goal.
We first provide a classification of embedded systems that is well adapted to their
analysis. We then describe the possible steps for their analysis. We start with
ways to obtain the software to analyze, which is often a challenge in itself for
embedded devices. We then describe how to perform static analysis on the firmware
packages obtained, which has many advantages such as speed and scalability. We
then describe techniques which can be used to dynamically analyze the firmware,
which in contrast to static analysis has the advantage of larger code coverage and
lower false positive rates.
11.1.5 Classification of Embedded Systems
A general definition of embedded systems is hard to establish [261]. However,
two widely accepted differences separate embedded devices from modern generalpurpose computers, such as ordinary desktop PCs or smartphones, namely: (a)
they are designed to fulfill a specific purpose, and (b) they heavily interact with
the physical world via peripherals. The aforementioned two criteria cover a wide
variety of devices, ranging from hard-disk controllers to home routers, from digital
cameras to Programmable Logic Controllers (PLCs). These families can be further
classified according to several aspects, such as their actual computing power [171],
the extent to which they interact with their computing and physical environment,
their field of usage, or the timing constraints imposed on them.
Unfortunately, these classifications tell us very little about the type of security
mechanisms that are available on a given device. Muench et al. [430] classifies
embedded systems according to the type of operating system (OS) they use. While
the operating system is certainly not the only source of security features, it provides
several security primitives, handles recovery from faulty states, and often serves as a