1

Return Oriented Programming on TI TivaC Series Microcontroller

Danny Froerer and Taylor PetersonUtah State University Department of Electrical and Computer Engineering

Abstract—This paper discusses how to rewrite theflash memory of a Texas Instruments (TI) Tiva C SeriesTM4C123GH6PM Microcontroller with a Cortex M4processor using Return Oriented Programming (ROP).After rewriting the flash memory, new code can beinjected to make the controller do anything the attackerwants. This is done by finding gadgets in the disas-sembly code of the read only memory (ROM) of themicrocontroller that allows for new code to be injected.In this example the injected code erased a portion ofthe flash memory and then reset and reprogrammed themicrocontroller to make an LED on the board flash redand blue.

Index Terms—Return Oriented Programming, StackOverflow, Security, Tiva C, Cortex M4,

I. INTRODUCTION

S INCE their inception, buffer overflow attackshave changed to keep functioning even though

new security measures are put in place to stopthem. Most changes were brought about by at-tack mitigation techniques such as strictly definingmemory as either executable or non-executable andby placing canaries in the code [1]. One workaround to these protections was to use return ori-ented programming (ROP). This allows the attackerto use the code that is found in the system driverlibraries such as ‘libc’. This works well because thislibrary code is an integral part of almost everyembedded system. By using an ARM processor,ROP is executed by using branches and pops asthere are no return statements.

The attack was executed using an echo func-tion that called the UARTgets() and UARTprintf()functions. After some slight modification to thesefunctions, they were used to overflow the buffer.Code was then injected to branch to the ROM andstart executing code to rewrite the flash memory,restart the microcontroller, and finally cause an LEDto flash continuously on the board.

II. SOFTWARE IMPLEMENTATION

Three pieces of software were developed for usein this project: an assembly program of the code

to inject, a UARTecho program with vulnerabilities,and hexadecimal code used to exploit the system.

A. Assembly Code

The assembly code that was injected and used totake control of the microcontroller was necessaryto establish the primary goal of this project. KeiluVision V5.18 was used to develop this code. Therequirements of the assignment were to rewritethe flash to cause an on-board LED to flash ata human visible rate. The code to do this wasmodeled after the ’blinky’ project provided by theTivaware package and was simple to implement.Once the target program was written, Keil wasused to extract the disassembly of the code. Anadditional assembly program was then written torewrite the flash memory of the Tiva-C and restartthe device to immediately start running an injectedversion of the ’blinky’ program. The process ofwriting this code proved invaluable towards un-derstanding the flash memory operations and stepsneeded to successfully inject code to run on themicrocontroller. All of this code can be found inthe ’blinky’ project in the source code.

To write to flash on the microcontroller, a shortlist of steps is necessary. A full description of flashmemory manipulation can be found on page 529of the Tiva TM4C123GH6PM Microcontroller DataSheet[2]. For the purposes of this project, only theFMA, FMC, FMC2 and FWBn registers were nec-essary. With the FMA and FMC registers, a wholepage of memory could be cleared to allow room forthe new code. The first page was selected since theprogram counter (PC) needed to be reprogrammedand it is initialized at the address 0x0000.0004. TheFWBn is a buffer for storing 32 words to write tomemory. The FMC2 register is used to initiate themove of the contents of the FWBn buffer to flashmemory. The buffer became the method of choicesince our code to inject was longer than 32 words.

2

B. UART EchoSimultaneous to the development of the source

code, a ’UART echo’ function was developed inKeil in the C programming language. This programwas developed with the intention of exploitingsecurity vulnerabilities in the microcontroller. Thegoal was to turn the Tiva into an echo device thatstored queries in a buffer and promptly respondedwith the contents of the buffer. This program wasmodeled after the ’UART echo’ project includedin the TivaWare software package. Vulnerabilitieswere added to make the attack more manageable.These included creating a very small buffer tohold the incoming data, removing certain parsingcode to allow unaltered copying, and expandingoperating memory on the device to prevent faults.The development of this program continued intothe creation and debugging of the attack code.

C. Hexadecimal CodeWith the microcontroller set to receive data, a

method of sending large amounts of data over se-rial was created. Realterm served as a useful serialtool and the dump file over serial command wasespecially helpful. Sublime Text and its excellentcode manipulation tools were used to write thehexadecimal code to be passed over serial. Theprogram HxD was then used to copy the code fromsublime into a file that could retain the raw hex-adecimal data called transmit.bin. Once this methodwas created, the attack code was developed. Thetransmit.bin file contained enough data to create abuffer overflow in the system. It then proceeded tooverflow the buffer into a link register stored loweron the stack and beyond. As long as the link registerwas overwritten with a proper address branchingto a gadget, the stack would remain in the controlof injected code.

III. GADGETS

To be able to use the code, gadgets had to befound in the disassembled ROM of the Tiva. Thesegadgets are machine instruction sequences that typ-ically end in a return statement. As this project usedan ARM processor, return statements were foundin the form of blx or pop. The blx were thoughtto be the most useful, but did not work as wasexpected. This was because when using blx, the PCwould return back to it’s starting point and wouldnot execute the remaining injected code. This led tothe discovery and use of the pop command. Usingthe grep function in Linux, all the pop instructionswere found and a list of the most useful ones

were saved in a file found in the software foldergadgets.txt. After reviewing the list, the first twogadgets proved to be the most useful and theywere used to both load and store values into the R4register and then pop R4 and PC. These can beenseen in Figures 1 and 2.

Fig. 1: Loading Gadget

Fig. 2: Storing Gadget

Apart from the two main load and store gadgets,there was one other gadget that was needed to beable to rewrite the flash memory. This was a delayor wait gadget shown in Figure 3.

Fig. 3: Delay or Wait Gadget

This was brought up in a discussion in class andit was determined that a gadget that terminatedwith a single pop of the PC was needed. This wouldallow for instructions to be executed and loop backto execute them again. As stated, this was necessaryto give the flash memory enough time to reset.

IV. RESULTS

After the the code was written and the gadgetswere found, it was injected onto the Tiva C andworked as expected. The flash was rewritten, the’blinky’ code injected and Figure 4 shows the lightsflashing blue and red.

Fig. 4: Alternating Lights Flashing Red and Blue

3

A. Obstacles

1) There were quite a few obstacles that had tobe overcome in this project. Some that shouldhave been trivial took more time than washoped and expected. Setting up Keil uVision towork with the Tivaware was quite a struggle.Making sure everything was linked correctlyso that the UARTgets() function would workwas harder and took more time than expected.

2) Sending the correct information serially turnedout to be quite a challenge as well. The codehad to be converted to assembly, then to hex-adecimal, then use a converter to make thehex to ASCII correct. Every time that infor-mation was sent serially, it was interpretedas ASCII characters. This turned out to bequite a problem and more time than expectedwas spent figuring out how to send the databecause copying and pasting didn’t work inRealterm because of size limitations. Finally itwas converted, saved to a file and the wholefile was able to be sent serially. This can be seenin Figure 5.

Fig. 5: ASCII Equivalent of the Hexadecimal Code

V. CONCLUSION

It was shown that by overflowing the buffer andknowing where the return address is, that it is pos-sible to use return oriented programming to repro-gram the Tiva TM4C123GH6PM Microcontroller.Even though that at first glance it seemed like itwas going to be difficult finding usable gadgets,once the right gadgets were identified, it was fairlyeasy to locate the necessary functions in the ROM ofthe microcontroller. The flash memory can be seenbefore and after the rewrite in Figures 6a and 6b.

(a) Flash Memory Before Injecting theCode

(b) Flash Memory After Injecting theCode

REFERENCES

[1] S. Moyer. (2007, August). (un)Smashing the Stack: Overflows,Countermeasures, and the Real Wrold[Online]. Available:https://www.defcon.org/images/defcon-15/dc15-presentations/Moyer/dc-15-moyer-WP.pdf

[2] (2007). Tiva TM4C123GH6PM Micro-controller Data Sheet[Online]. Available:http://www.ti.com.cn/cn/lit/ds/spms376e/spms376e.pdf