11 Finding Software Bugs in Embedded Devices
197
architecture of the device whose firmware is being dynamically analyzed. Then the
firmware root filesystem is uploaded to the emulation host OS, where its Linux
boot sequence scripts are initiated, most likely in a chroot environment under the
emulation host OS. Once the firmware’s Linux boot sequence concludes, various
services (e.g., a web server, SSH, telnet, and FTP) of the device/firmware under
analysis should be running, and are ready for logging, tracing, instrumentation and
debugging. The work in [137] extends this approach by running a custom operating
system kernel which is able to emulate some of the missing drivers.
11.5 Conclusion
We have provided a short overview of the field: from our excursus, it is clear that
analyzing the software of IoT/embedded devices and finding security vulnerabilities
within them is still a challenging task. While multiple directions and techniques are
being actively explored and developed within the field, more research, insights and
tools are still required.
Unfortunately, the existing proven techniques (e.g., static, dynamic, hybrid
analysis) cannot be applied in a straightforward manner to embedded devices
and their software/firmware. One reason for this is the high heterogeneity and
fragmentation of the technological space that supports embedded/IoT systems.
Another reason is the “opaque” nature of embedded devices, which can be seen as
akin to the “security by obscurity” principle. Such reasons make embedded systems
harder to analyze compared to more traditional systems.
Indeed, the current embedded firmware “population” may still contain many
latent backdoors and vulnerabilities, both known and unknown. However, as
we detailed in this chapter, positive and promising avenues for the detection
of embedded software bugs are becoming increasingly available. Such avenues
include large-scale analysis and correlation techniques, hybrid/dynamic analysis
of emulated firmware or running devices, and advanced techniques to specifically
detect backdoors.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing,
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate
credit to the original author(s) and the source, provide a link to the Creative Commons licence and
indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative
Commons licence, unless indicated otherwise in a credit line to the material. If material is not
included in the chapter’s Creative Commons licence and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly from
the copyright holder.
197
architecture of the device whose firmware is being dynamically analyzed. Then the
firmware root filesystem is uploaded to the emulation host OS, where its Linux
boot sequence scripts are initiated, most likely in a chroot environment under the
emulation host OS. Once the firmware’s Linux boot sequence concludes, various
services (e.g., a web server, SSH, telnet, and FTP) of the device/firmware under
analysis should be running, and are ready for logging, tracing, instrumentation and
debugging. The work in [137] extends this approach by running a custom operating
system kernel which is able to emulate some of the missing drivers.
11.5 Conclusion
We have provided a short overview of the field: from our excursus, it is clear that
analyzing the software of IoT/embedded devices and finding security vulnerabilities
within them is still a challenging task. While multiple directions and techniques are
being actively explored and developed within the field, more research, insights and
tools are still required.
Unfortunately, the existing proven techniques (e.g., static, dynamic, hybrid
analysis) cannot be applied in a straightforward manner to embedded devices
and their software/firmware. One reason for this is the high heterogeneity and
fragmentation of the technological space that supports embedded/IoT systems.
Another reason is the “opaque” nature of embedded devices, which can be seen as
akin to the “security by obscurity” principle. Such reasons make embedded systems
harder to analyze compared to more traditional systems.
Indeed, the current embedded firmware “population” may still contain many
latent backdoors and vulnerabilities, both known and unknown. However, as
we detailed in this chapter, positive and promising avenues for the detection
of embedded software bugs are becoming increasingly available. Such avenues
include large-scale analysis and correlation techniques, hybrid/dynamic analysis
of emulated firmware or running devices, and advanced techniques to specifically
detect backdoors.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing,
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate
credit to the original author(s) and the source, provide a link to the Creative Commons licence and
indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative
Commons licence, unless indicated otherwise in a credit line to the material. If material is not
included in the chapter’s Creative Commons licence and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly from
the copyright holder.