Firmware Re-hosting Through Static Binary-level Porting Mingfeng Xin1, Hui Wen1, Liting Deng1, Hong Li1, Qiang Li2, and Limin Sun1 1Institute of Information Engineering, CAS, China 2School of Computer and Information Technology, Beijing Jiaotong University, China {xinmingfeng,wenhui,dengliting,lihong,sunlimin}@iie.ac.cn, [email protected] Abstract are continuously increasing and used in many industrial ap- The rapid growth of the Industrial Internet of Things (IIoT) plication domains. These devices are usually connected to has brought embedded systems into focus as major targets the different types of networks for extra functionality, exe- for both security analysts and malicious adversaries. Due to cuting a special-purpose computing task with co-operations. the non-standard hardware and diverse software, embedded However, the connectivity of embedded devices significantly devices present unique challenges to security analysts for the increased their exposure to attacks. It makes analysts focus accurate analysis of firmware binaries. The diversity in hard- on the security analysis of embedded device firmware, aiming ware components and tight coupling between firmware and to discover vulnerabilities for system security assessment and hardware makes it hard to perform dynamic analysis, which firmware patching. Costin et al. [21] perform a large-scale must have the ability to execute firmware code in virtualized analysis of the security of embedded firmware through static environments. However, emulating the large expanse of hard- analysis. However, dynamic analysis plays a crucial role when ware peripherals makes analysts have to frequently modify researchers want to conduct a thorough security analysis on the emulator for executing various firmware code in differ- a specific firmware. As far as is known, dynamic analysis ent virtualized environments, greatly limiting the ability of can perform a wide range of sophisticated examinations (e.g., security analysis. taint analysis and symbolic execution) and overcome the limi- In this work, we explore the problem of firmware re-hosting tations of static analysis (e.g., packed or obfuscated code). In related to the real-time operating system (RTOS). Specifically, terms of firmware analysis, dynamic analysis of embedded developers create a Board Support Package (BSP) and develop systems can monitor detailed data flow, including memory device drivers to make that RTOS run on their platform. By layout, register values, etc., greatly improving the analysis providing high-level replacements for BSP routines and de- ability of vulnerabilities of embedded devices. vice drivers, we can make the minimal modification of the Unfortunately, embedded hardware provides limited intro- firmware that to be migrated from its original hardware en- spection capabilities, including limited numbers of break- vironment into a virtualized one. We show that an approach points and watchpoints, significantly restricting the ability of capable of offering the ability to execute firmware at scale dynamic analysis on firmware. In this case, emulation, also through the use of firmware patching in an automated man- known as firmware re-hosting, enables the host system to arXiv:2107.09856v2 [cs.CR] 29 Jul 2021 ner without modifying the existing emulators. Our approach, execute the firmware of embedded hardware in virtualized en- called static binary-level porting, first identifies the BSP and vironments for successfully performing dynamic analysis on device drivers in target firmware, then patches the firmware firmware. However, appropriate emulators are typically rare, with pre-built BSP routines and drivers that can be adapted to particularly due to the impracticality of drivers for supporting the existing emulator. Finally, we demonstrate the practical- incompatible embedded processors. Moreover, the embedded ity of the proposed method on multiple hardware platforms system relies on different peripherals and system configura- and firmware samples for security analysis. The result shows tions. It makes various peripherals and memory layouts that that the approach is flexible enough to emulate firmware for must be supported in a specialized manner by emulators. In vulnerability assessment and exploits development. conclusion, the heterogeneity in embedded hardware makes it hard to decouple the firmware from the hardware and emulate 1 Introduction a large number of hardware peripherals. To solve this problem, researchers propose many emula- With the proliferation of Industrial Internet of Things (IIoT), tion solutions for firmware analysis, such as Avatar [41], Pre- embedded devices, such as routers and many control devices, tender [28], P2IM [26] and HALucinator [20]. They present 1 a considerable performance but expose their own problems using the abstraction provided by the RTOS to solve hetero- when emulating firmware in a specific condition. For example, geneity for firmware re-hosting. By providing customized Avatar is a hardware-dependent, one-to-one dynamic analysis replacements for BSP routines and device drivers, it is easier framework, which must use a debug interface to interact with for developers to port firmware from one board to another. a physical device. This hardware-in-the-loop design greatly Based on this observation, we solve the re-hosting problem limits the scale of firmware re-hosting. Pretender and P2IM by treating firmware re-hosting as porting firmware to the model the peripherals to provide proper values for the fuzzer emulator’s board. We propose a method called static binary- thus ensure sufficient code coverage, but bring uncertainty level porting and build a tool called FirmPorter, which can with unknown execution process. Specifically, an observation modify the BSP and driver code at binary level. The tool shows that the emulated results conducted by their methods automatically replaces the BSP and drivers with proper func- present a value that out the range of the real device should tions that the emulator can successfully execute in a virtual have. HALucinator utilizes High-Level emulation method environment. In this work, the tool first identifies BSP and that provides simple, analyst-created, and high-level replace- drivers in the firmware for function replacement. Then it gen- ments, which performs the same task from the firmware’s erates object files to patch the firmware following the RTOS’s perspective. However, it only solves emulation problems for programming interface. Finally, when dealing with peripher- Arm Cortex-M-based firmware and cannot emulate firmware als not supported by the emulator, we use a new technology running on x86, MIPS, or other processors. In conclusion, called Driver Hacking to solve the communication problems these firmware re-hosting solutions only target a specific set between the host and the emulator. of firmware, such as Arm-based firmware. When analyzing a Contributions: firmware running on the other processors, researchers have to 1. We explore the problem of firmware re-hosting related re-implement the emulator, which requires a huge amount of to real-time operating system (RTOS) and show an approach manual work. that can customize function replacements for Board Support Emulators are a key component in enabling dynamic anal- Package (BSP) and device drivers, which is able to handle ysis of the firmware by emulating virtual interactions that diverse firmware. matches the real system. According to WRIGHT et al.’s 2. We build FirmPorter, a tool that can emulate RTOS work [39], execution fidelity describes how closely execution firmware through static binary-level porting technique by in the emulator can match that of the physical system, while providing function replacements for BSP and device drivers. data or memory fidelity describes in what level the memory 3. We evaluate 11 different firmware with 4 kinds of in the emulator (e.g., BlackBox, RAM, Register) is consistent RTOSes running on 5 different processors, including a Schnei- with hardware for a given point in execution. When re-hosting der SAGE2400 RTU firmware, a Schneider Modicon M241 firmware for Fuzz testing, the data fidelity can be very low. PLC firmware and three wireless temperature sensor firmware, However, when used for vulnerability assessment, the solution which run on real-world devices. The result shows that of firmware re-hosting needs high fidelity, because the proof firmware can be correctly emulated, and PoCs/exploits devel- of concepts (PoCs) or exploits developed under an emulated oped under the emulated environment can be directly applied environment have to be applied to the real device. to real devices. Nowadays, most of embedded systems use RTOS for mul- tiple tasks management to ensure better program flow and 2 Background and Motivation event response. In embedded systems, Board Support Package (BSP) is the layer of software containing hardware-specific In this section, we briefly introduce the Board Support Pack- routines that allow a particular RTOS to function in a par- age (BSP) and Device Driver Infrastructure that exist in mod- ticular hardware environment. The purpose of a BSP is to ern RTOSes, which inspires us to solve the problem of re- configure the kernel for the specific hardware on the target hosting in a novel way. board. However, the BSP does not include much more than what is needed to support a minimum number of peripherals 2.1 Board Support Package on a board, and developers have to create the remaining device drivers following the Device Driver Infrastructure defined in The purpose of a BSP is to configure