Objectives: The goal in the context of the project is to accumulate knowledge about handling bootloaders and passwords of the device. What basic methods for reverse engineering of IoT and Toys?

Handling bootloader and Linux passwords: While booting, the bootloader loads the kernel and passes the boot arguments to the kernel. Typically, the path for a user mode process that starts when the kernel completes booting is within the boot argument.

After booting, the Linux kernel transfers control of the console to the user-mode process. Traditionally, after executing a list of scripts, the init process may transfer control to the login or shell process. When the login process starts, it requests and verifies the user’s credentials and spawns a shell process for the user to control. The login process is protected from brute force attempts and imposes a delay between consecutive password guessing attempts.

During reverse engineering, when encountering a login request in an embedded device, a simple technique is to replace the initial part of the boot argument with a path to /bin/sh or any other process that can assist in gaining access to the system. This change can be done from within the bootloader terminal, which can be accessed when the boot process begins.

Access to the bootloader is usually accomplished by pressing some key during the initial booting stages. In some cases, the bootloader is protected by a password. Since the bootloader has a very small memory footprint, it usually lacks the infrastructure for password hashing and only performs string comparison against a hard-coded password. Such hardcoded password strings may be recovered from memory blobs obtained via out-of-band methods.

Using physical attacks to bypass passwords or recover passwords: Fault injections have a significant role in reverse engineering. The use of fault injections allows the researcher to generate a hardware fault at any given time and manipulate the underlying software. Countermeasures for fault injection attacks are constantly being investigated, but they are rarely implemented in devices that are not designed to be tamper-proof. We discovered that hardware faults which cause the initialization process to fail can cause the system to fall back into a highly-privileged shell process. This can be done by disconnecting or shorting various hardware components.

For example, shorting the GND and MISO pins of an SPI Flash module will cause any reads from the device to be malformed. Of course, this procedure carries the risk of damaging the device or its memory.

While side-channel attacks can also be used for recovering passwords, they tend to be better suited to systems with a simpler design such as ASICs (application-specific integrated circuit) or FPGAs (field-programmable gate array). They are more difficult to implement in black-box scenario which includes a fully-featured multitasking operating system. Many other types of physical attacks exist, some of which are even effective against tamper resistant devices.

Uploading additional tools onto the device: Embedded systems are often designed with the minimal set of features and components required for their designated task, and their software design reflects this. Embedded Linux may contain only a small subset of the Linux utilities and features that desktop Linux users are used to having.  Using common utilities such as FTP (file transfer protocol utility), TFTP (trivial file transfer protocol utility), Wget, and NetCat can be used to mediate data and file transfer to and from the device and over the network.

When network utilities are unavailable, data can be infiltrated through crude methods such as scripting the use of the Unix bash echo command for writing binary data into files. A simple  scripts, which use echo for transferring files over UART, are publicly available.

Obtaining the firmware: Extracting a copy of the firmware and file system is an important stage of reverse engineering since analysis of the firmware can reveal secrets and vulnerabilities. 

When network connection and console access are available, flash memory MTD (memory technology device) partitions can be streamed into NetCat and sent to a remote computer. A copy of the file system may also be compressed using the tar utility and streamed using NetCat. Doing so will eliminate the need for unpacking the file system, which is not always a trivial task.

If a network connection is unavailable, memory contents can be read over UART from a bootloader or Linux console. Bootloaders’ consoles often contain memory read/write/display primitives and can be used to slowly dump an image of the memory into the UART console. 

When the bootloader and Linux console are inaccessible, flash memory contents can be dumped via out-of-band methods. There are several ways to gain access to partial or complete data belonging to the device’s memory. A minimally intrusive option is to connect a logic analyzer to the pins of the memory module in order to record the signals while the device is booting up. Partial memory images can be extracted from the communications on the memory bus, depending on the actual addresses that were accessed during the recording. A simple script can convert the logic analyzer output to usable binary.

In order to obtain a complete and accurate image of the device memory, it is possible to desolder the memory chip and connect it to off-the-shelf memory readers such as the CH341A. If the memory module is not compatible with off-the-shelf readers, a custom reader can be built using a general-purpose USB adapter such as FT2232H or a programmable micro-controller.

Recommendations for Implementers

Based on the analysis performed and results obtained in this research, we make the following recommendations for improving the security of IoT devices.

1) Removing UART ports: UART ports typically have no function in mature devices. While obfuscation of UART ports is a widely used technique for hindering reverse engineering, it may not be effective in the face of devices such as the UART discovery assistant module described in Subsection II-A3. Whenever possible, UART ports should be removed from finalized products, and their terminals should not appear in board designs.

2) Restricting access to UART ports: In situations where UART ports are essential in consumer products, they can be set up as read-only. An example can be seen in the debug port available in Google Nexus phones that can be accessed through the headphone port; The system logs are funneled using UART communication while maintaining a read-only mode.

3) Protecting UART ports: If a UART port is required and must be write-enabled, certain protective measures should be considered. Previous works suggested safeguarding UART ports in a similar fashion to JTAG protection.

4) Hardening bootloader security: Hardening of bootloader security should be considered; bootloaders can be protected by physical means so that they only go into debug mode when specified electrical criteria are met or when using passwords. Although bootloader passwords were observed during our survey, retrieval of the passwords was easy using communication dumps, meaning that more sophisticated defenses should be employed.

5) Usage of unique passwords: Using the same passwords in devices of the same model or manufacturer enables a low resource attack to be amplified across many devices. In addition to hashing passwords with a strong hashing algorithm such as SHA-516 crypt, strong unique passwords should be used for each and every device.

6) Facilitating password replacement: Hard-coding passwords should be avoided. Users must be able and encouraged to replace passwords frequently and easily.

7) Encryption of device memory: When possible all of the device’s memory should be encrypted, similarly to what is done with mobile devices.

8) Encryption of sensitive data: All sensitive data stored on the device, including configuration, should be encryption.