Taking a Look into Execute-Only Memory Marc Schink Johannes Obermaier Fraunhofer Institute AISEC Fraunhofer Institute AISEC [email protected] [email protected] Abstract development process, there is no protection against adversar- ial developers and they have unrestricted access to the binary The development process of microcontroller firmware often code. Therefore, every developer is able to reverse engineer involves multiple parties. In such a scenario, the Intellectual or copy the software, and thereby pose a threat to the con- Property (IP) is not protected against adversarial developers tainedIP. Since developers require debug interface access which have unrestricted access to the firmware binary. For and privileged code execution on a device, common firmware this reason, microcontroller manufacturers integrate eXecute- protection mechanisms that disable the debug features are not Only Memory (XOM) which shall prevent an unauthorized applicable. For that reason, a firmware protection technique read-out of third-party firmware during development. The against adversarial developers in multi-party development concept allows execution of code but disallows any read ac- scenarios is required. In such a scenario, the firmware is de- cess to it. Our security analysis shows that this concept is ployed and secured on the device before handing it over to the insufficient for firmware protection due to the use of shared next developer. As a consequence, developers need physical resources such as the CPU and SRAM. We present a method access to the device such that their firmware can be devel- to infer instructions from observed state transitions in shared oped and deployed in a trusted environment. In summary, a hardware. We demonstrate our method via an automatic re- security concept for multi-party development needs to protect covery of protected firmware. We successfully performed firmware against an adversarial developer with the follow- experiments on devices from different manufacturers to con- ing capabilities: physical access to the microcontroller, its firm the practicability of our attack. Our research also reveals integrated debug interface as well as arbitrary and privileged implementation flaws in some of the analyzed devices which code execution. Hardware modification capabilities are not enables an adversary to bypass the read-out restrictions. Alto- considered because they may be detectable by customers or gether, the paper shows the insufficient security of the XOM other involved parties of the development process. concept as well as several implementations. An approach that enables firmware protection for embed- ded devices and microcontrollers in multi-party development 1 Introduction environments has been described by ARM [24]. This ap- proach is based on eXecute-Only Memory (XOM) which Embedded systems and microcontrollers in particular became allows solely the execution of code but prevents any read or popular for a number of application fields like robotics, trans- write access to it. This feature is present in various micro- portation and medicine. Concepts such as the Internet of controllers from different manufacturers. Also, it has gained Things (IoT) even increase their pervasiveness in more areas attention through support in toolchains and the embedded sys- in industry as well as in consumer products. As a consequence, tems community [5, 17]. While the article by ARM notes that such devices comprise increasingly complex software, mak- adversaries might be able to partially guess protected code ing the contained Intellectual Property (IP) more valuable to by observing changes in CPU registers an SRAM content, adversaries. Common protection techniques prevent firmware the article also states that such an attack requires significant read-outs by disabling the debug interface of a microcontroller. effort. However, no details nor evidence from real embedded Such mechanisms are applicable against outside attackers that systems are provided. are not involved in the firmware development process. For this reason, this paper presents the following contribu- However, complex software is often not developed by a tions: single company but built upon software provided by other • An analysis of XOM as protection technique against companies, so called third-party software. In a multi-party unauthorized code read-out. • An evaluation and discovery of flaws in the XOM con- cept of several ARM Cortex-M based microcontrollers. Third-party Execute-tonly • A general procedure to automatically recover firmware library memory protected by XOM. Function call • A practical evaluation of code recovery attacks on de- Third-party Execute-only vices from different manufacturers. library memory • The discovery and exploitation of further implementa- Function tion flaws that allow reading XOM protected code. call End user Normal application memory 1.1 Related Work Code protection mechanisms have been investigated by sev- eral researchers and conceptual as well as implementation Figure 1: Flash memory with end user application and two flaws were discovered. Obermaier and Tatschner presented third-party firmware components marked as execute-only. three (non-)invasive attacks against the firmware read-out protection of STM32F0 devices [11]. Goodspeed and Fran- cillon demonstrated an attack which leverages the bootloader Some approaches exist to integrate this concept into desk- implementation of MSP430 microcontrollers to dump the top and server systems [22,23]. Since an adversary with physi- protected flash memory content [4]. They describe how to re- cal access can easily probe and read-out their main memory or cover specific instructions from its unknown firmware based data storage, the CPU is the only trusted hardware component. on whether the device performs a reset after a code injec- The encrypted code is stored in memory and is decrypted and tion attack. The found instructions are then used as gadgets executed on-demand within the CPU. for a Return-Oriented Programming (ROP) attack to circum- Small embedded systems and microcontrollers in partic- vent the read-out protection. Bittau et al. describe how to ular are usually based on a single chip incorporating CPU recover specific instructions to mount a ROP attack on un- and memory. Thus, probing and data read-out of the memory known code [3]. A similar attack which targets the Intel Soft- is impossible without invasive hardware attacks. Since the ware Guard Extensions (SGX) was presented by Lee et al. [6]. firmware can only be accessed by components within the de- The software in the secure enclave can be executed but the vice, such as the processor, XOM is implemented by partially binary is unknown to the attacker, similar to XOM. The au- restricting modifications and read-outs of the flash memory thors use an exception signal to guess instructions inside the while allowing instruction fetches. Encryption of the code enclave. Again, only very specific instructions are recovered is not necessary. This enables protection against unintended for a subsequent ROP attack. or malicious code read-outs, for example, data leakage bugs These results are only partially applicable to XOM pro- due to missing bound checks. Also, it provides protection tected memory. Despite the situation of a read-out protected against malicious or accidental firmware modifications which memory is similar, entirely recovering protected code has increases the safety of a system. never been shown to be feasible. In a multi-party firmware development scenario, XOM al- lows developers to deploy their software on a microcontroller and subsequently mark it as execute-only. After that, the mi- 2 Execute-Only Memory crocontroller including the deployed software can be utilized by other developers but the software is protected against ma- In this section, we start with a description of the general idea licious read-outs. Figure 1 illustrates an example use case behind eXecute-Only Memory(XOM) as firmware protection where the flash memory contains two libraries together with technique and its application for multi-party development an end user application. The libraries are deployed on the scenarios. Subsequently, we explain the conceptual weakness device by third-party software providers. Since both libraries that arises from it, and how this can be exploited to circumvent are placed inside the XOM, they can be utilized but are pro- the protection. tected against read-outs and modifications by the developer of the end user application. 2.1 General Concept 2.2 Conceptual Weakness The fundamental idea behind XOM-based software protection mechanisms is to ensure confidentiality and integrity by pre- The combination of XOM as a firmware protection technique venting read-outs and manipulations of the respective code, and the extensive capabilities of an adversarial developer and thereby protect the containedIP. results in a conceptual weakness. Memory address Instruction can be used to limit code execution to the target instruction 1 0x0000 0802 mov r0, #23 only. Once the CPU reaches the interrupt handler, its state Input state nop 0x0000 0804 can be obtained. Even though the exception entry modifies 0x0000 0806 ? ? ? 2 Instructiont execution the Program Counter (pc) and other registers, the state after 3 0x0000 0808 ? ? ? the execution of the target instruction can be restored from Output state 0x0000 080a ? ? ? the stack. Hence, we call this approach interrupt-driven in- struction recovery. Its advantage is that it does not