Introduction

Embedded Device Software Architectures

Software architecture (which may include an OS) determines many of the properties and limitations of a device. We distinguish between three main types of software architectures that are present in embedded devices.

• Full stack OS based devices - devices that contain a modern operating system, such as Linux, that separates execution into kernel mode and user mode. While traditionally this architecture was preferred only when versatility and high performance was needed, more and more low-cost devices are now based on Linux due to falling component costs and the ease of developing for this operating system. In particular, many of the cameras we surveyed had a full stack Linux implementation.

• Partial stack OS based devices - devices with a specifically designed RTOS (real-time operating system) such as VxWorks or vendor-provided OS implementation. These devices are generally specially crafted for their task [20], and tend to omit some of the features of full stack OSs. Some lower-end or single tasked IoT devices use this architecture, with the RTOS handling Wi-Fi and Web protocols, and additional vendor code responsible for gathering sensor data.

• Devices with no operating system - embedded devices which directly execute compiled instructions, without any OS support for functionalities such as threading or interrupts. Devices with no OS can offer better raw performance and higher run-time predictability than other architecture, but tend to be more difficult to development, and therefore have a longer time-to-market (TTM).

Thus far, all of the IoT hacks have targeted full stack OS devices, as these are more generic and make use of various drivers and open source components that may have known vulnerabilities. For this reason, full stack OS devices have significant potential for security vulnerabilities as well.

Usually black-box reverse engineering process follows:

1. Physical inspection of the device;
2. Extraction of the device firmware image and file system;
3. Bypass boot-time security and recover the firmware image;
4. Recover the data with out-of-band means;
5. Analysis the firmware image and recovery of the new one inside it.

A. Physical inspection of the device

Electronic devices are usually held together by screws or plastic clips. Most of the devices can be opened without damaging the exterior of the device or the internal components. Some device manufacturers also use glue during assembly, thus making opening the device more difficult.

1) Locating and identifying memory components: Smart devices that run the Linux operating system require sufficient non-volatile memory to store the kernel and other mandatory file system components. A cheap and efficient way for engineering such devices is to place the memory module outside of the main processor package. Devices engineered in such configurations usually employ a processor that is capable of loading and running instructions directly from the SPI (serial parallel interface) Flash memory or EEPROM devices.

Understanding the memory technology is crucial for performing firmware extraction when there is no possibility of running commands on the tested device.

A memory module that uses technology consistent with the required capacity is often found in devices. Common examples are: 25XX \ 26XX series eight-pin SPI Flash memory with up to 32MB of storage space; larger SPI Flash devices with sixteen or thirty-two pins; NAND Flash devices that come in various capacities and shapes and are usually coupled with a 24XX EEPROM module for holding initial configuration; eMMC (embedded multimedia controller) modules or cards usually containing more than a gigabyte of data.