2016 Workshop on Fault Diagnosis and Tolerance in Cryptography

Controlling PC on ARM using Fault Injection

Niek Timmers Albert Spruyt Marc Witteman

Riscure – Security Lab Riscure – Security Lab Riscure – Security Lab
Delft, The Netherlands Delft, The Netherlands Delft, The Netherlands
timmers@riscure.com spruyt@riscure.com witteman@riscure.com

Abstract—Fault injection attacks are a powerful technique to likely that software exists without logically exploitable
influence the intended behavior of embedded systems. They flaws, especially on smaller code bases. In such situations,
can be used to exploit or bypass robust security features found other attacks may be used to exploit the embedded system.
in secure embedded systems. Examples of such attacks include
differential fault analysis (DFA) and bypassing authentication An example of such an attack is fault injection, which
mechanisms. An embedded system’s authenticated boot chain works by injecting physical faults into the embedded system
(i.e. secure boot) is an interesting target for fault injection. The to change its intended behavior. Attackers require physical
initial boot stages are of limited size which means logically access to the embedded system to perform fault injection;
exploitable vulnerabilities are not guaranteed to be present. In remote exploitability is typically not feasible.
this paper, we introduce an ARM specific fault injection attack
strategy for exploiting embedded systems where externally This paper is structured as follows: a background for fault
controlled data is loaded in the program counter (PC) register
of the processor. This allows an attacker to control the target’s
injection, describing different fault injection techniques and
execution flow which eventually will lead to arbitrary code fault injection fault models, is described in Section II. In
execution on the target. We first simulate the attack using a section III we describe what ARM instructions there are to
common fault model, after which we demonstrate the practical- implement efficient memory copy operations and how these
ity of the attack using a development platform designed around can be attacked using fault injection. This section ends with
an ARM based, fast and feature rich system on chip (SOC).
We conclude with an overview of effective and non-effective
two practical attacks; one during boot and one during run-
countermeasures against this fault injection attack technique. time. We simulate the applicability of the described attack
in Section IV after which we demonstrate the practicality of
the described attack using an ARM development platform
Keywords-fault injection; ARM; exploitation; system on chip; in Section V-D. In Section VI we provide an overview
embedded systems. of different countermeasures and their relevance for the
described attack. Finally, we provide an overall conclusion
I. I NTRODUCTION in Section VII.

Embedded systems are often designed around a single sys-

tem on chip (SOC), which often includes one or more central II. FAULT INJECTION BACKGROUND
processing units (CPU). These can be implemented using
different architectures, such as ARM or MIPS. The fault Faults can be injected by manipulating the chip’s environ-
injection attack technique described in this paper is ARM mental conditions. Typically, the following fault injection
32-bit (AArch32 [1]) specific. This architecture is from are considered:
now on reffered to as ’ARM’. The practicality of the fault
• Clock Fault Injection Faults are injected in the
injection attack technique is demonstrated using simulation
target’s clock signal by switching between a faster and
and experimentation on a development platform designed
slower clock. This variant of fault injection is only
around a fast and feature rich SOC which implements
effective for chips using an external clock which can
the following functionality: up-to 1 GHz ARM core, 32-
be controlled by an attacker. Most embedded systems
bit DDR3 at 400 MHz, 2D/3D graphics, Gigabit Ethernet,
do not run directly from a clock and therefore this
HDMIv1.4 controller, among other functionality.
particular technique is often not very effective.
Software running on embedded systems is often found to • Voltage Fault Injection Faults are injected in the
be logically exploitable as shown in [2] (integer overflow), target’s power domain by switching between different
[3] (null pointer dereference) and [4] (incomplete signature voltage levels. This technique is often effective on
parsing). The research presented in [5] shows that open larger feature rich chips as they typically have multiple
source software has roughly 0.434 defects per thousand separated power domains, as they are derived externally
lines of code, out of which an unknown, but definitely (i.e. on the PCB). Therefore, it is possible to inject
smaller number, is logically exploitable. Therefore, it is faults in one power domain without affecting the others.

978-1-5090-1108-7/16 $31.00 © 2016 IEEE 26

25
DOI 10.1109/FDTC.2016.18

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
 • Electromagnetic Fault Injection Faults are injected A to memory address B. These instructions use the internal
in the target using electromagnetic emissions, generated registers to temporarily store the loaded data before it is
by driving a high current through a coil. An important copied to the destination memory address. Variants of the
characteristic of this technique is its localized nature. LDR and STR instruction are shown in [16] where differ-
Using electromagnetic fault injection, it may be possi- ent instructions are provided also supported in the ARM
ble to affect only parts of the chip. architecture. The LDR instruction loads four bytes from the
• Optical Fault Injection Faults are injected in the address stored in register R0 into register R3, after which
target using a laser beam which injects a fault locally the STR operation copies the contents from register R3 to
inside the chip. The chip’s package blocks the light the memory address stored in register R1. The assembly, hex
from reaching the die directly. Therefore, the chip must and binary representation of both instructions are shown in
be decapsulated to expose the chip’s internals to the Table I.
laser beam.
Table I
ARM LOAD AND STORE INSTRUCTIONS
These techniques have been proposed in [6], [7], [8], [9],
[10], [11], [12], [13] and [14]. The attack proposed in this ARM assembly HEX Binary
paper does not rely on a specific fault injection technique. LDR R3, [R0] E5903000 11100101 10010000
00110000 00000000
However, the for demonstration purposes we considered only
STR R3, [R1] E5813000 11100101 10000001
voltage fault injection. 00110000 00000000
The injected fault can, in principle, have an impact on any
stage of the fetch-decode-execute cycle performed for each An efficient copy operation in ARM utilizes the LDMIA
instruction, which is shown in [13] and [14]. Addition- and STMIA instructions [16], which can copy multiple
ally, any optimizations implemented by the CPU, such as words with a single instruction. The LDMIA instruction
pipelining [15], add to the complexity of executing a single copies multiple words from a memory address into multiple
instruction. Therefore, it is typically unknown what exactly general purpose registers from which they are copied into
goes wrong within the CPU when its behavior is changed another memory address. The LDMIA instruction loads four
due to fault injection, whereas the modified behavior itself 32-bit words from the address stored in register R1 into
is easier to measure. We consider a generic fault model, the registers R4 to R7, after which the STMIA instruction
likely applicable to a wide range of targets, where a variable copies to contents from the registers R4 to R7 to the
amount of bits in the instruction are flipped as a result of address stored in register R2. The exclamation mark (!)
fault injection. Two types of behavior are possible using this indicates the addresses stored in register R1 and register
fault model: R2 are automatically incremented with the amount of data
being copied (i.e. four times 32-bits equaling 16 bytes). The
• Instruction corruption The original instruction is
assembly, hex and binary representation of both instructions
modified into an instruction that has an impact on the
are shown in Table II.
behavior of the device. In practice, it may modify the
instruction to any other instruction supported by the Table II
architecture. E FFICIENT ARM LOAD AND STORE INSTRUCTIONS
• Instruction skipping Effectively a subset of instruc- ARM assembly HEX Binary
tion corruption. The original instruction is corrupted LDMIA R1!,R4-R7 E8B100F0 11101000 10110001
into an instruction that does not have an impact on the 00000000 11110000
behavior of the device. The resulting instruction does STMIA R2!,R4-R7 E8A200F0 11101000 10100010
00000000 11110000
not change the execution flow or any state that is used
later on.
From an attacker’s point of view, these load and store
Invocation of specific behavior is not a trivial task, as the low operations are an interesting target for a fault injection attack
level control required to do this is often limited. However, as the instructions:
it is possible to identify the more probable results while
assuming that bit flips affecting single or all bits are more • operate on attacker controlled data.
likely than complex patterns of bit flips. • are not part of a fault injection protected section in
the code as they are not considered security sensitive.
III. ATTACKING ARM LOAD INSTRUCTIONS All security, such as authentication and decryption, is
implemented after the load and store operations.
On ARM based chips, LDR and STR instructions are often • are executed multiple times consecutively with attacker
used when data needs to be copied from memory address controlled data which decreases the attack’s timing

26
27

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
 dependency. The attack does not require to target one B. Practical attack scenarios
specific instruction.
In this section, we describe two practical attack scenarios:
a boot attack and a runtime attack. Both scenarios are
A. Controlling PC generic and could be applied to almost any embedded
system. However, attacks described in this section are always
target dependent and their success rate may vary. Also,
An ARM processor includes 16 registers. Simply said, when data is copied using a different method than the
register R0 to R12 are general purpose registers, register described ARM instruction it may affect the applicability
R13 (SP), register R14 (LR) and register R15 (PC) are of the attack. For example, utilizing dedicated hardware to
special. All registers can be modified directly using a wide perform direct memory access (DMA) based copy operations
variety of ARM instruction whereas the PC register can will not be affected by the presented attack. However, such
only be directly modified using specific instructions. For copy operations may be vulnerable to other attacks where
example, the following instructions can directly modify the the parameters passed to the DMA engine are corrupted
PC register: LDR, MOV, ADD, SUBS, etc. In all other major using fault injection. Such attacks are out of scope for this
architectures, such as MIPS, X86, X64, and even ARM64, paper.
the PC cannot be accessed by most instructions, especially
not directly. These architectures modify the PC indirectly This paper only explores the scenarios where the attacker
using jump or stack-related instructions. injects code into the system in the form of an executable
binary payload which is executed by modifying a load
Depending on the instruction under attack, a single or double instruction.
bit corruption in the instruction is required to load an
attacker controlled value in PC. The characteristic of ARM,
where the PC can be accessed directly by most instructions, C. Secure boot attack
effectively leads to the applicability of this attack. The
required bit flips to load the value into the PC register are The first attack scenario described in this paper is a boot
underlined in Table III. attack, performed during the initialization of the embedded
system. Although a SOC includes several types of internal
Table III memory, such as ROM, RAM or Flash, it typically also
G LITCHED LDR AND LDMIA INSTRUCTION uses external memory components. The SOC cannot trust
ARM assembly HEX Binary code from the external memory, since these components are
LDR PC,[R0] E590F000 11100101 10010000 physically accessible to other parties. Therefore, the usual
11110000 00000000 procedure is to first copy code from external memory to
LDMIA R1!,R4-R7,PC E8B180F0 11101000 10110001 internal memory, and then perform a cryptographic verifica-
1xxxxxxx xxxxxxxx
tion of the loaded code. Secure boot is the process of loading
and verifying data from external memory during the startup
While we do not perform an exhaustive search for all of the system. A generic secure boot sequence is shown in
possible instruction encodings leading to control of the PC Figure 1.
register, we wish to highlight the impact of the destination
register encoding for both the LDR and LDMIA instruction.
The LDR instruction requires a specific bit pattern, whereas
the LDMIA instruction allows a multitude of different bit
patterns as long as the bit for the PC register is set. This
is indicated by the ’x’ character in III. We hypothesize that
the success rate when attacking the LDMIA instruction is
higher than when attacking the LDR instruction.

Setting the PC register as the destination for the LDR or

LDMIA instruction effectively allows an attacker to load
an arbitrary value from which the next instruction will be
fetched by the CPU. This is a first step towards arbitrary
code execution. Typically, an attacker needs to perform
additional tasks in order to exploit an embedded system. For
example, an additional task is to fill the memory with exe-
cutable code from which the processor will execute. Figure 1. Generic secure boot design

27
28

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
An attacker who wants to execute arbitrary code in a high which will effectively execute the shellcode.
privilege context, may choose to attack the secure boot
mechanism. The boot of an embedded system is often Run time control gained in this way can bypass the authenti-
implemented using multiple stages which are executed in cation and encryption protection of secure boot. Secure boot
a different privileged context. The first stage, often referred implementations can use Direct Memory Access (DMA)
to as the ROM code, is an immutable stage which contains engines [17] to copy data to volatile memory. However,
the first code executed after power-on reset. The ROM code if any part of the unauthenticated data, for instance the
is responsible for loading, authenticating and decrypting the signature, is copied, the attack still applies.
next stage, which is often stored in external flash.
This multi-stage approach allows the embedded system to
gradually drop privileges until the final stage is reached.
The different stages are copied into faster volatile memory
before they are decrypted and authenticated. It is likely this
copy operation is implemented as described in Section IV,
especially considering these are based on instructions from
ARM. The boot flow of BL1 after power-on reset is as
follows:

1) The BL1 image, including its signature, is copied Figure 2. External flash modification
from external flash memory into volatile memory (e.g.
internal SRAM or DDR) using LOAD and STORE In this attack the shellcode is executed from its internal
instructions. volatile memory. A simpler scenario exists when the target
2) The BL1 image is decrypted inside volatile memory can execute directly from external flash. The pointers in the
using a symmetric algorithm (e.g. AES). The decryp- payload could then simply direct to another location in the
tion can be performed by software or hardware (e.g. external flash. In our attack we assume the more complex
cryptographic accelerators). scenario (execute from internal memory), thereby increasing
3) The BL1 image is authenticated using an asymmetric the attack scope.
cryptographic algorithm in combination with a hashing
algorithm. An immutable public key should be used D. Trusted execution environment (TEE) attack
by the ROM code to guarantee a chain of trust.
The second attack scenario is a runtime attack, performed
An important observation that must be made here is that after the embedded system is booted. More and more se-
the attack is not affected by any form of decryption or curity sensitive embedded systems are equipped with a so-
authentication of the external firmware, because the attack called trusted execution environment (TEE) which separates
is performed prior to such mechanisms. We target the copy itself from the rich execution environment (REE). A general
phase of BL1, effectively bypassing any security provided description of such a system is described in [18]. The REE
by the secure boot chain. The entire attack can be broken typically communicates with the TEE using a dedicated
down into the following steps: API, where the TEE will copy data from the REE to its
own memory. A logical representation of a system that
• First, the destination address inside the volatile memory implements a REE and a TEE is shown in 3.
of the copy operation must be recovered. For example,
this can accomplished by reverse engineering or ana-
lyzing the documentation. This address is used as the
pointer value in the next step.
• Second, the original contents in external flash must be
overwritten with a malicious payload which has the
following format: shellcode + pointers, which is shown
in Figure 2. The shellcode is malicious executable code
that gives the attacker privileged access.
• Finally, the fault is injected after the target has copied
the shellcode into its internal memory and while it is
copying the pointers into its internal memory. A suc-
cessful fault will corrupt the a load or store instruction
so that the pointer value is copied into the PC register Figure 3. Generic REE/TEE design (taken from [18])

28
29

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
We again assume that the copy operation is implemented the simulation runtime. Using this technique we test 41448
using the instructions described in Section III. The logical different instructions derived from the original instruction.
flow of a call from the REE to the TEE is as follows: Pseudo code for the bit flipping code is shown in Figure
4.
1) The REE sets up the required data for an API com-
mand exposed by a Trusted App in the TEE, using the flips = [ 1, 2, 4, ... 2147483648 ]
shared buffer.
2) The REE uses an exception to notify the TEE a s = Set()
for a in flips:
command is ready inside the shared buffer. for b in flips:
3) The TEE copies the API command data into its own for c in flips:
context using a copy operation. for d in flips:
s.add(a | b | c | d)
Again, because the fault will be injected during the copy
Figure 4. Pseudo bit flipper code
operation, the attacker will not be restricted by any verifi-
cation performed by the TEE. The following steps can be
performed to mount an attack: The bit flipper code is implemented in a Python wrapper that
passes the flipper value as a parameter to a C application.
• First, an attacker needs to identify an application This application uses the flipper value to flip bits in the target
programming interface (API) command into the TEE instruction, which is part of piece of shellcode stored in a
which fulfills the following requirements: data must local buffer. The C application jumps to the shellcode after
be copied from the non-secure context to the secure the target instruction’s bits are flipped. Another function,
context. Such functionality can be derived from the API from now on named the identifier function, prints a string
documentation, passed parameters or reverse engineer- on the serial interface, which is used to identify if the PC
ing. register is modified to the controlled value. This approach is
• Second, the data originating from the non-secure con- very fast and allows simulating the proposed attack vector
text is under control of the attacker, assuming full natively.
control of the REE is established. Therefore, the attack
has full control over what data passed into the API
command. Depending on the implementation of the A. Simulation: LDR instruction
TEE, the provided shellcode could be executed from
non-secure memory. Otherwise, the destination address
must be recovered by other means. The simulation program loads data, using an LDR instruc-
• Third, the data going into the API command is con- tion, from a memory address stored in register R0 into
structed similarly to the secure boot attack described register R3. The source data consists of a pointer pointing
earlier: shellcode + pointers (see Figure 2). to the identifier function.
• Finally, the fault is injected when the payload is in We identified multiple ways to corrupt the LDR instruction
place, while the TEE is copying the pointer values. into an instruction that loads the controlled value into the
A successful fault will corrupt the a load or store PC register. These are shown in Table IV. The difference be-
instruction so that the pointer value is copied into the tween the original instruction and the corrupted instruction is
PC register which will effectively execute the shellcode also listed, expressed as the hamming distance (HD).
in the secure context.
Table IV
IV. S IMULATION M ODIFIED LDR INSTRUCTIONS
Modified instruction Differences (HD)
We used a simulation program to determine the likelihood LDR R3, [R0] 0
a load instruction is modified into an instruction that loads LDR PC, [R0] 2
externally controlled values into PC. The simulation program LDRGE PC, [R0] 3
is executed natively on an development boards that contains LDRLE PC, [R0] 4
an ARM processor that implements the ARMv7-A architec-
ture which supports the ARM execution state. We executed
The LDR instruction can be implemented using a different
the simulation program as a user-land Linux application on
register (e.g. register R6 instead of register R3) which
top off Ubuntu 12.04 LTS [19].
influences the required fault model. Hence, when R7 is used,
A generic fault model is used where we corrupt the instruc- only a single bit corruption will modify the PC register into
tion with a hamming distance difference up-to 4, to limit the controlled value.

29
30

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
B. Simulation: LDMIA instruction • The capacitance in the core power domain which pow-
ers the ARM processor, is reduced to a minimum by
The simulation is repeated using the LDMIA instruction, removing all the external capacitors from the PCB.
where the target instruction loads data from a memory These capacitors are in place to stabilize the power
address stored in register R0 into register R4, R5, R6 and R7. signal of the target when low frequency and high
The source data consists of pointers pointing to the identifier frequency anomalies are present in the power domain,
function. such as our injected faults. In theory, removing the
We identified multiple ways to corrupt the LDMIA in- capacitors should destabilize the target under normal
struction into an instruction that loads the controlled value conditions but we do not observe such behavior.
into the PC register. These are shown in Table V. The • A trigger is implemented using a general purpose IO
difference compared to the original instruction, expressed pin of the target. The test program running in the target
as the hamming distance, is also listed. can set this trigger shortly before the injection moment,
which simplifies the timing of the attack.
Table V • The reset signal of the target is fed into our fault
M ODIFIED LDM INSTRUCTIONS
injection setup which allows us to reset the target when
Modified instruction Differences (HD) required. Fault injection may cause the target to enter an
LDMIA R0!, R4-R7 0 unrecoverable state which can only be overcome using
LDMIA R0!, R4-R7,PC 1 a full system reset.
LDMDA R0!, R4-R7,PC 2
LMDGT R0!, R4-R7,PC 2
B. Fault injection setup
LMDGE R0!, R4-R7,PC 2
LMDIB R0!, R4-R7,PC 2
Dedicated high speed hardware is used to generate a pulse,
and an amplifier is used to glitch the power line of the
A successful glitch may change the original operands into target. An logical representation of the setup is shown in
anything, as long as the bit is set to copy the data from R1 Figure5. The setup includes a PC that controls the exper-
into PC. iment and configures the glitch parameters: Normal VCC,
The simulation showed that the PC register might be modi- Glitch VCC, Glitch Length and Glitch Delay. The Normal
fied by corrupting LDR and LDMIA instructions using fault VCC is the power provided to the target power domain. The
injection, as long as the chosen fault model is applicable. Glitch VCC is the voltage level during the glitch, which
We believe it provides enough confidence to demonstrate is subtracted from the Normal VCC. The Glitch Length is
the practicality during the experiments. the duration of the glitch. The Glitch Delay is the duration
between the moment the trigger is detected, and the glitch
V. E XPERIMENTAL RESULTS is injected.

We use the same development platform used during the

simulation phase as the target. We created a test bench
to demonstrate the practicality of the described attack sce-
narios. We use commercially available FI hardware and
software [20] to inject a glitch in the core power domain
of the target, which powers ARM processor.
This paper only considers voltage fault injection, other fault
injection methods are not applied. However, the proposed
attack may be applicable to all fault injection techniques
introduced in Section I. Figure 5. Fault injection setup used for the experiments

A. Target modification The test program is copied from external flash and executed
Multiple modifications are made to the platform, which from external DDR. The ARM processor runs at 800 MHz
allow us to perform effective fault injection. These can be on a single core. We power the target during all experiments
summarized as follows: at 1.1 volt, even though the target’s original power supply
provides 1.2 volt. The target is stable between 1.1 volt and
• A power cut on the PCB is made to be able to 1.3 volt. We assume the injected faults are more effective
control the power to the ARM processor using our fault when the target operates on its minimal voltage. Hence,
injection equipment. for this reason we also remove the capacitors from the

30
31

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
target’s PCB. However, we did not investigate further if this
hypothesis is correct.

C. Characterization phase

The effectiveness of the fault injection setup is verified using

a characterization phase where a simple test program is
attacked using fault injection. The results of the character-
ization phase serve as a baseline to support our hypothesis
that the instruction encoding influences the fault injection
success probability.
The resulting counter value is sent back to the software
running on the workstation. The trigger signal is set before
the first ADD instruction and set low after the last ADD Figure 7. Relation between Glitch Length and Glitch Voltage
instruction. A snippet of the code is shown in Figure
6.
D. Experiments
MOV R1, #0
MOV R0, %[loopcnt] The test applications used for the experiments are imple-
LOOP: mented as an additional command in U-Boot [21], which
ADD R1, R1, #1
...
is the de facto standard boot loader embedded systems and
ADD R1, R1, #1 is publicly available as open source software. The primary
SUBS R0, R0, #1 purpose of U-Boot is typically to load a subsequent stage,
BNE LOOP such as the Linux Kernel. However, U-Boot provides a
... functionality rich environment in the form of a shell which
Figure 6. Test program: ADD instructions can be utilized to perform various operations. We do not use
any of the functionality provided by U-Boot other than our
test applications.
Using a randomized parameter search, where we randomize
the glitch length and the glitch voltage, we determine opti- We reuse the parameter ranges identified in the characteri-
mal parameters where the counter value, stored in register zation phase to optimize the initial parameter search.
R1, is corrupted, which is used as an indication for a
1) Experiment 1: LDR
successful glitch.
The 1st experiment consists of 25 subsequent LDR instruc-
We perform 18.000 experiments using the glitch parameters
tions which copy from a local buffer into register R7. The
in Table VI.
instructions are placed inside a loop which is executed 100
Table VI times, resulting in the execution of 2500 LDR instructions
P ROFILING GLITCH PARAMETERS which take approximately 300 microseconds. A snippet of
Glitch parameter Value the test application is shown in Figure 8.
Normal VCC 1.1 volt ...
Glitch VCC Random between -1.4 volt and -1.0 volt MOV R0, %[loopcnt]
Glitch length Random between 0 ns and 1000 ns MOVW R1, #0x0F1C
MOVT R1, #0x2FFA
Glitch delay Random between 30 μs and 35 μs
LOOP:
LDR R4, [R1]
Figure 7 shows a plot of the experiments where the chip’s LDR R5, [R1]
LDR R6, [R1]
behavior is indicated by plotting the glitch length against LDR R7, [R1]
the glitch voltage. No effect is plotted as ’Expected’, a ...
successful glitch where the counter value changed is plot- SUBS R0, R0, #1
ted as ’Success’ and all resets and mutes are plotted as BNE LOOP
’Mute’. ...

Figure 8. Test program: LDR instructions

The characterization showed the fault injection is effective
in changing the behavior of the target using voltage fault
The local buffer is filled with pointers pointing to a function
injection.
that prints a string on the serial interface and then enters an

31
32

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
endless loop. The address of the local buffer (0x2FFA0F1C) Table VIII
E XPERIMENT 1: F INAL G LITCH PARAMETERS
is stored in register R1 using a MOVW and MOVT in-
struction. The fault is injected when the LDR instructions Glitch parameter Value
are executed. A successful attack loads one of the pointers Normal VCC 1.1 volt
from the local buffer into the PC register, which results in Glitch VCC -1.293 volt
the execution of shellcode that prints a string on the serial Glitch length 862 ns
interface. Glitch delay 31 μs

We start off with a parameter sweep to identify efficient

glitch parameters using the parameters outlined in Table VII. 2) Experiment 2: LDMIA
In total we perform 10.000 experiments, which takes roughly
4 hours. The 2nd experiment consists of 25 subsequent LDMIA
instructions, which copy from a local buffer into register
Table VII R4, R5, R6 and R7. The instructions are placed inside a
E XPERIMENT 1: I NITIAL GLITCH PARAMETERS loop which is executed 100 times, resulting in the execution
Normal VCC 1.1 volt of 2500 LDMIA instructions which takes approximately 330
Glitch VCC Random between -1.4 volt and -1.0 volt microseconds. A snippet of the test application is shown in
Glitch length Random between 700 ns and 1000 ns Figure 10.
Glitch delay Random between 30 μs and 35 μs ...
MOV R2, %[loopcnt]
MOVW R1, #0x0F24
Figure 9 shows a plot of the experiments where the chip’s MOVT R1, #0x2FFA
behavior is indicated by plotting the glitch voltage against LOOP:
the glitch length. We grouped the resets and mutes to LDMIA R1, {R4-R7}
generate a clear picture. ...
LDMIA R1, {R4-R7}
SUBS R2, R2, #1
BNE LOOP
...

Figure 10. Test program: LDMIA instructions

The local buffer is filled with pointers pointing to a function

that prints a string on the serial interface and then enters an
endless loop. The address of the local buffer (0x2FFA0F24)
is stored in register R1 using a MOVW and MOVT instruc-
tion. The fault is injected when the LMDIA instructions are
executed. A successful attack loads one of the pointers from
the local buffer into the PC, which results in the expected
string being printed on the serial interface.
We start off with a parameter sweep to identify efficient
Figure 9. Target behavior: Glitch Voltage vs Glitch Length glitch parameters using the parameters outlined in Table IX.
In total we perform 10.000 experiments, which takes roughly
Out of the 10.000 experiments, we identify 1 (0.01%) 4 hours.
successful glitch, 3436 (34.36%) mutes/resets and 6563 Table IX
(65.63%) glitches did not yield influence on the target’s E XPERIMENT 2: I NITIAL G LITCH PARAMETERS
operation. The resets are caused by different exceptions, Glitch parameter Value
such as data abort and illegal instruction. Normal VCC 1.1 volt
We perform 1000 experiments with the parameters of the Glitch VCC Random between -1.4 volt and -1.0 volt
successful glitch, which are shown in VIII. We perform Glitch length Random between 700 ns and 1000 ns
this experiment to approximate the reproducibility of a Glitch delay Random between 30 μs and 35 μs
successful glitch.
Figure 11 shows a plot of the experiments where the chip’s
Using these parameters, we identify 7 successful glitches
behavior is indicated by plotting the glitch voltage against
(0.7%) where the expected string is printed on the serial
the glitch length. We grouped the resets and mutes to
interface.
generate a clear picture.

32
33

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
 • Deflect Manipulation of a computer chip typically
requires a fault to be injected at exactly the right time
to affect a specific instruction. If the code execution
progress is fully deterministic an attacker can use a
precise time base to determine the best moment in time
for the fault to occur. It is possible to deflect the fault
and lower the predictability by running the processor at
varying speed, or by introducing random delays. This
could be implemented at a hardware level, using an
unstable clock, or a software by having waiting loops
of variable length.
• Detect If faults are timely detected it is possible
to prevent insecure behavior. In hardware this could
be done with sensors that measure the environmental
Figure 11. Target behavior: Glitch Voltage vs Glitch Length conditions and generate alarms when extraordinary
conditions are detected. In software this could be done
by double checking conditions before branching, or to
Out of the 10.000 experiments, we identify 27 (0.27%) verify sensitive data values. Also it is possible to check
successful glitches, 2653 (26.53%) mutes/resets and 7320 that the expected program flow was executed.
(73.20%) glitches did not yield influence on the target’s • React Even with reduced hit probability and increased
operation. The resets are caused by different exceptions, detection probability it is still possible that an attack
such as data abort and illegal instruction. would succeed, given enough time. Fault response uses
detected faults to impose a penalty. This could be
We perform 1000 experiments with the parameters of a a temporary penalty, like a waiting time before the
successful glitch, which are shown in Table X. We perform behavior targeted by the attack can be repeated, or a
this experiment to approximate the reproducibility of a more permanent one like terminating the device.
successful glitch.
An extensive list of countermeasures using these approaches
Table X is discussed in [22]. However, many of these countermea-
E XPERIMENT 2: F INAL G LITCH PARAMETERS
sures are not very effective against the presented attack
Glitch parameter Value vector. To summarize:
Normal VCC 1.1 volt
Glitch VCC -1.321 volt • Firstly, random delays are used to decrease the suc-
Glitch length 946 ns cess rate for a fault injection attack. However, copy
Glitch delay 31 31 μs operations are often implemented as a loop and are of
significant length, resulting in the consecutive execution
Using these parameters, we identify 27 successful glitches of vulnerable instructions, effectively rendering the
(2.7%) where the expected string is printed on the serial randomization ineffective as a successful glitch can
interface. occur at different moments in time.
• Secondly, detection of fault injection works requires
3) Conclusions: LDR vs LDMIA that the checks are executed. When the fault triggers a
jump to a different code section this countermeasure
The success rate and reproducibility of a successful attack
is bypassed. An alternative could be to apply traps,
is significantly different between the LDR and LDMIA
small code segments that detect anomalies due to
instruction. The impact of the destination register encoding
fault injection, interleaved with the copy instructions.
difference for each instruction is likely the reason, which
However, this does not rule out the described attack.
matches our earlier hypothesis: the success rate when attack-
• Lastly, reaction is possible. In case a trap would detect
ing the LDMIA instruction is higher than when attacking
a fault, this could trigger blowing a fuse (or OTP
the LDR instruction due to the difference in instruction
cell) that would block, or terminate, the target. This
encoding.
countermeasure should be designed with care to prevent
unintentional defects.
VI. C OUNTERMEASURES
Traditional logical exploitation protection mechanisms such
as NX/DEP [23] where code can only be executed from
Mitigation of fault injection is possible at the hardware and
designated pages in memory, and ASLR [24] where memory
software level. Three principle approaches include:

33
34

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
addressing is randomized, increase the complexity of the R EFERENCES
attack. However, these hurdles can be overcome, using
techniques utilized by logical exploitation, and can therefore [1] ARM. AArch32 execution modes. http://infocenter.arm.com/
not mitigate the fault injection threat. help/index.jsp?topic=/com.arm.doc.ddi0488d/CHDGAIDG.
html. [Online; accessed 2016].
In our experiments we confirm that power glitching is more
difficult when complex bit flips are required for the attack. A [2] Dan Rosenberg. Reflections on Trusting TrustZone.
redesign of the instruction set that would maximize hamming https://www.blackhat.com/docs/us-14/materials/
distance from valid to potentially harmful instructions, could us-14-RosenbergReflections-on-Trusting-TrustZone.pdf.
[Online; accessed 2016].
be an interesting approach to reduce the sensitivity for fault
attacks. However, the risk imposed by fault injection would
[3] Geohot. limera1n. https://www.theiphonewiki.com/wiki/
not be entirely mitigated. Limera1n. [Online; accessed 2016].
In any case, we believe hardware countermeasures are re-
quired to increase the robustness of embedded chips. For [4] CodeAurora. Incomplete signature parsing during boot image
example, such countermeasures are described in [11] and authentication leads to signature forgery (CVE-2014-0973).
https://www.codeaurora.org/projects/security-advisories/.
[9]. However, typically these countermeasures aim to prevent [Online; accessed 2016].
a single fault injection technique. Therefore, a combination
of different countermeasures must be considered when the
[5] Ben Chelf. Measuring software quality: A Study of Open
risk imposed by all fault injection techniques must be Source Software. http://www.coverity.com/library/pdf/open
mitigated. source quality report.pdf. [Online; accessed 2016].

VII. C ONCLUSION [6] A. Spruyt. Building fault models for microcon-

trollers. https://www.os3.nl/ media/2011-2012/courses/rp2/
p61 report.pdf. [Online; accessed 2016].
In this paper we describe a fault injection attack strategy
which poses a significant risk towards secure embedded [7] G. Thessalonikefs. ElectroMagnetic Fault Injection Char-
systems that implement the ARM 32-bit (AArch32) architec- acterization. https://www.os3.nl/ media/2013-2014/courses/
ture. We show it is possible to load attacker controlled values rp1/p67 report.pdf. [Online; accessed 2016].
in the program counter (PC) register which may compromise
the overall security of an embedded system. [8] J. Gratchoff. Proving the wild jungle jump. http://delaat.net/
rp/2014-2015/p48/report.pdf. [Online; accessed 2016].
We simulated the fault injection attack strategy to form a
hypothesis on its practicality. The hypothesis stressed the [9] Hagai Bar-El, Hamid Choukri, David Naccache, Michael
fact that the destination register encoding difference for the Tunstall, and Claire Whelan. The sorcerer’s apprentice guide
LDR and LDMIA instruction impacts the attack’s success to fault attacks. IACR Cryptology ePrint Archive, 2004:100,
rate. The experiments performed on a development platform 2004.
design around a popular, ARM-based, fast and feature rich
system on chip (SOC), indicate that the hypothesis is cor- [10] Sergei P. Skorobogatov and Ross J. Anderson. Optical fault
rect. induction attacks. In Revised Papers from the 4th Interna-
tional Workshop on Cryptographic Hardware and Embedded
The described fault injection strategy is architecture specific, Systems, CHES ’02, pages 2–12, London, UK, UK, 2003.
but its principles may be applicable to other architectures. Springer-Verlag.
More complex code constructs may allow an attacker to
control the program counter (PC) register using fault injec- [11] Dr Sergei Skorobogatov. Physical attacks on tamper resis-
tion. tance: Progress and lessons.

[12] Nicolas Moro, Amine Dehbaoui, Karine Heydemann, Bruno

ACKNOWLEDGMENT Robisson, and Emmanuelle Encrenaz. Electromagnetic fault
injection: towards a fault model on a 32-bit microcontroller.
CoRR, abs/1402.6421, 2014.
This research is supported by Riscure. We thank our col-
leagues at Riscure, including Lukasz, for all their wonderful
insights and pearls of wisdom. We are immensely grateful [13] Loı̈c Zussa, Jean-Max Dutertre, Jessy Clédière, and Assia
Tria. Power supply glitch induced faults on FPGA: an in-
for their help reviewing preliminary versions of this paper. depth analysis of the injection mechanism. In 2013 IEEE 19th
Their input immensely improved the readability of this International On-Line Testing Symposium (IOLTS), Chania,
report. Crete, Greece, July 8-10, 2013, pages 110–115, 2013.

34
35

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.
[14] Thomas Korak and Michael Höfler. On the effects of clock [19] Canonical Ltd. Ubuntu 12.04.5 LTS (Precise Pangolin). http:
and power supply tampering on two microcontroller plat- //releases.ubuntu.com/12.04/. [Online; accessed 2016].
forms. In 11th Workshop on Fault Diagnosis and Tolerance
in Cryptography, pages 8 – 17, 2014.
[20] Riscure. Inspector FI. https://www.riscure.com/securitytools/
inspector-fi/. [Online; accessed 2016].
[15] Bilgiday Yuce, Nahid Farhady Ghalaty, and Patrick Schau-
mont. Improving fault attacks on embedded software using [21] DENX. Das U-Boot the Universal Boot Loader. http://www.
RISC pipeline characterization. In 2015 Workshop on Fault denx.de/wiki/U-Boot. [Online; accessed 2016].
Diagnosis and Tolerance in Cryptography, FDTC 2015, Saint
Malo, France, September 13, 2015, pages 97–108, 2015.
[22] M. Witteman. Secure Application Programming in the
Presence of Side Channel Atacks. https://www.riscure.com/
[16] ARM. What is the fastest copy memory on a Cortex- benzine/documents/Paper Side Channel Patterns.pdf. [On-
A8? http://infocenter.arm.com/help/index.jsp?topic=/com. line; accessed 2016].
arm.doc.faqs/ka13544.html. [Online; accessed 2016].
[23] HP. Data Execution Prevention v1.2. http://h10032.www1.
hp.com/ctg/Manual/c00387685.pdf. [Online; accessed 2016].
[17] David Geier. An overview of direct memory access. https:
//geidav.wordpress.com/tag/dma-engine/. [Online; accessed
2016]. [24] Hristo Bojinov, Dan Boneh, Rich Cannings, and Iliyan
Malchev. Address space randomization for mobile devices.
In Proceedings of the Fourth ACM Conference on Wireless
[18] ARM. Development of TEE and Seucre Montior Code. Network Security, WiSec ’11, pages 127–138, New York, NY,
https://www.arm.com/products/processors/technologies/ USA, 2011. ACM.
trustzone/teesmc.php. [Online; accessed 2016].

35
36

Authorized licensed use limited to: Yale University. Downloaded on April 17,2023 at 17:14:00 UTC from IEEE Xplore. Restrictions apply.