JTAG Combined Attack
- Another approach for fault injection -
F. Majéric, B. Gonzalvo, L. Bossuet, Senior Member, IEEE
Abstract—The combined attacks are widely spread in the
domain of smart cards and microcontrollers but they have not
been yet democratized on complex embedded microprocessors
such as those which can be found in smart phones, tablets
and automotive systems. The main reason behind this is the
complexity to inject a fault at the right place and at the right
time to make these attacks effective on such devices. However
for development and debug, these devices provide new tools that
could be considered as potential ways for attacks. It’s the case
of the JTAG debug tool which is present on most electronic
devices today. The improper use of this latter is already known
but in this paper we present a new misuse of this one: the JTAG
as a fault injection tool. Through an example, we explain how
this tool can be used to perform a combined attack.
Index Terms—JTAG, SoC, combined attack, privilege escala-
tion, root privileges, Linux access right management, Android
6.0.1 Marshmallow.
I. I NTRODUCTION
In 1997 and for the first time, a team of researchers proposed
the use of fault injections to break the RSA encryption system
[1]. Ever since, in an environment such as the one of smart
cards and microcontrollers, this property gave way to a whole
new kind of physical attacks known as fault injection attacks.
The work in [2] gives more details about the various fault
induction methods that are frequently used on smart cards
in order to extract sensitive information. These methods use
deliberate disturbances of physical quantities related to the
systems. It was not until year 2010 that the term “combined
attack” appeared in [3]. The authors introduce a “new kind of
attack which combines fault injection and logical tampering”
in order to alter the security mechanisms of a JAVA card and
authorize the execution of a malicious application. This new
idea to combine logical and physical attack was expanded to
smart cards under different aspects. In order to evaluate the
securities weaknesses against such threats, a lot of studies
on this topic and on security to thwart such attacks is still
conducted by researchers [4].
However nowadays, with the democratization of smart-
phones and other connected devices, the manipulation of
sensitive data tends to be done not only by smart cards but
also by complex and multi-purpose embedded systems like
Fabien Majric is a PhD student with Laboratoire Hubert Curien and
Gemalto (e-mail: fabien.majeric@{univ-st-etienne.fr, gemalto.com}).
Benoit Gonzalvo is with the Security Labs, GEMALTO (La Vigie),
Av. du Jujubier, Z.I Athelia IV, 13705 La Ciotat, France (e-mail:
benoit.gonzalvo@gemalto.com
L. Bossuet is with the Laboratoire Hubert Curien, UMR CNRS 5516, Uni-
versity of Lyon, Saint-Etienne, 42000, France (e-mail: lilian.bossuet@univ-st-
etienne.fr).
System on Chip (SoC). Such devices need also to be evaluated
against fault injections and combined attacks. But so far, very
few intrusive tests, were experimented on such systems. The
rarity of these tests is essentially due to the complexity of
interacting precisely with a targeted module integrated in a
SoC at the right place and at the right time. On one hand,
this complexity comes from their complex architectures and
on the other hand it is also due to the size of the chip and the
package which coats them.
This article presents the improper use of a widespread
hardware debug tool which enables to bypass the complexity
of the SoCs for proceed to a combined attack. This tool is
used to disturb the right control process at the right time which
allows to execute a malicious software. The rest of this article
is organized as follows: Section II introduces the contribution
of this work. Section III defines and gives the example which
has inspired our combined attack. The Section IV describes
the environment setup and our experimentation on the device
under test. Finally, a discussion about this study is proposed
in section V and a conclusion is given in section VI.
II. O UR CONTRIBUTION
This work falls in the extended field of “combined attacks”
which deals with SoCs such as those found in automobiles
and mobile phones. Our research presents the debugging tool
JTAG [5] used as a new fault injection vector. This new
aspect of JTAG application is used for a combined attack by
privilege escalation. Through this example we show how we
can bypass complexities of injecting a fault into the SoCs and
how by combining the use of a very widespread hardware
debugging tool with a software it leads our attack to success.
The improper use of JTAG is not new but rather reserved for
attacks that make only use of it e.g. in [6] and [7]. In our new
approach, we present how to combine hardware (JTAG) and
software (a malicious program) to reach our goal. JTAG is
only used as a tool for injecting a fault, it’s a JTAG combined
attack.
III. P RIVILEGE E SCALATION ATTACK
This section formally defines the privilege escalation attack
along with a working example. This latter motivates our JTAG
combined attack.
A. Definition
In [8], Davi et al. define the privilege escalation attack
as: “An application with less permissions (a non-privileged
caller) is not restricted to access components of a more
privileged application (a privileged callee)”. More generally,
a privilege escalation is the act of exploiting a bug, design
flaw or configuration oversight in an operating system or
software application to gain elevated access to resources that
are normally protected from an application or user. The result
is that an application with more privileges than intended by
the application developer or system administrator can perform
unauthorized actions. One should keep in mind that this kind
of attack is one of the most feared in the digital security field.
In fact, to have an unauthorized user given permissions that he
should not have and having a potential capacity of jeopardizing
sensitive data or even worse, endangering the whole system,
is a major risk.
The example here below is one that inspired us to develop
our combined attack described in section IV-B . This software
attack shows how to take advantage of a hardware weakness
of a device in order to gain a privilege elevation.
B. Samsung Exynos Kernel Exploit
In December 2012, Alephzain, a hacker from the Android
community published a method to obtain root privileges
was proposed on many of the popular Samsung phones
thanks to a simple executable [9]. This exploit potentially
threatens all devices embedding Exynos processor 4210
and 4412 which use Samsung Android kernel sources.
The vulnerability is in the kernel memory device file
/dev/exynos-mem which is readable and writable by
any unprivileged user and gives access to all physical memory.
C. Principle of this Exploit
The vulnerability allows any unprivileged user or program
to read and write to physical memory through the kernel mem-
ory device file /dev/exynos-mem. Therefore, Alephzain
implements a simple user privileges application and executes
it on a device based on an Exynos processor. In memory, this
application looks for the sys_setresuid kernel function
which attributes or not the root privileges. Then it modifies
this function in order to give the root privileges to the ones
which normally can’t get them. Finally, the user privileges
application asks to the kernel function to be upgraded to a root
privileges application and because this function is corrupted,
the application gets this privileges.
More precisely, on Android devices, the symbols addresses
of the kernel functions in the /proc/kallsyms file are
0-masked by the /proc/sys/kernel/kptr_restrict
security feature. The addresses are only displayed to autho-
rized users. So before modifying the sys_setresuid func-
tion its address must be known. The Alephzain’s application
use the read-write vulnerability to map the memory device in a
file with the mmap function. Then, it parses this file in order to
find the format specifier string "%pK %c %s\n" used by the
.text segment of kptr_restrict. For security reasons,
the %pK format specifier is designed to hide exposed kernel
pointers, specifically via /proc interfaces. Replacing %pK by
%p force kernel to display its symbols pointers regardless of
privileges [10]. By doing that, Alephzain allows its exploit to
find sys_setresuid address in the /proc/kallsyms
file. With this address, the exploit can reach the code of
sys_setresuid in memory and reverses the comparison
operation dealing with the privileges of the function’s caller. To
do that the value considered in the comparison function "cmp
r0,#0x0" is simply replaced with "cmp r0,#0x1" or
directly with the opcode because the exploit handles only in-
tegers : "0xE3500000" is replaced with "0xE3500001".
Now if a simpler user or program asks for root privileges it
can get it. This manipulation allows a user space application to
grant itself elevated permissions that it should not have. This
is a privilege escalation attack.
Since the outbreak of that attack, Samsung addressed this
security breach by releasing a fix of the exploit making such
attacks not applicable. The /dev/exynos-mem vulnerabil-
ity does not exist any more on Samsung Exynos processors
and has never worked on other devices. But by using other
attack path it is possible to perform such an attack as it will
be presented in the following section.
IV. E XPERIMENTATION
Considering the principle of the Samsung Exynos Kernel
Exploit (see section III-C), if it exists another way to access
to the memory and change the value of the kernel function,
this attack could be still possible.
The JTAG is an hardware debug tool present on most of
embedded CPUs. It provides an interface between the debug-
ger and the chip for debugging one or more cores. Among
other functionalities, the Debug Access is used by debugger
tools to access the internals of a chip making its resources and
functionality available, modifiable and stoppable, e.g. registers,
memories and the system state. Considering that, the JTAG
tool highlights the fact that we have at our disposal a new
path for fault injection.
Thus in the rest of this article, we propose a combined
attack for privilege escalation based on the same principle as
Samsung Exynos Kernel Exploit. Note that there is a huge
amount of attack possibilities, JTAG for privilege escalation
is one example.
A. Experimental Set-up
1) Device under Test: In our experiment we use a
development board with a widespread 32-bit ARM Cortex-A9
processor embedded with Android operating system version
6.0.1 - Marshmallow. To communicate with the Android-
powered device we use Android Debug Bridge tool (ADB)
which is a command line tool without root privileges.
2) JTAG Hardware Debugger: Although it’s easy to create
a tool to communicate with the JTAG interface for performing
boundary-scan tests, developing complex communication pro-
tocols transported by JTAG to perform debugging is difficult.
Hence the debug tool that was used for the manipulations is a
commercial JTAG probe, Lauterbach trademark. The Trace32
soft of this probe provides a very detailed and tailored GUI
which gives an overview of the device and can perform a
wide set of operations on it. With recent advancements, it
exists somes tools which were earlier reserved for high-tech
laboratories are now easily accessible to attackers thus making
JTAG attacks a real risk.
B. JTAG Combined Attack for Privilege Escalation
The JTAG combined attack success depends on the ability
to modify the system call sys_setresuid which manages
the grant of the access to the kernel code.
From this point there are two ways to proceed: either
directly look for the system call function and patch it or
look for its address in the list of addresses only accessible to
privileged users. The first method is the pattern recognition
used for finding the system call in kernel code accessed by
JTAG. The pattern is the hexadecimal value of compiled code
and this value depends on the compiler used and the options
selected among others things. So the desired pattern could
be different for the same function making the search more
difficult. The second option uses the same method as the
Samsung Exynos Kernel Exploit and searches a fixed pattern
(the format specifier string) that determines if the system
call addresses display must be done or not considering the
privileges of the caller requesting for it. This last option is
probably more efficient on an Android OS assembled by an
unknown compiler.
So the JTAG combined attack for privilege escalation can
be split into three main steps:
1) Find the address of set_setresuid which manages
the privileges.
2) Modify this system call, i.e. inject the fault.
3) From the user space, ask for root permissions.
The first two steps are done with the JTAG probe. In the
step 1), the probe will be used to parse the code in order to
inject a fault to force the kernel to display the system call
addresses. Then the address is read by software means (ADB)
from user space. In step 2), the JTAG tool is only used to
inject the fault. The last step 3) is the combined attack, in
which the previous manipulations made with JTAG grants
root permissions to a software asking for it. The following
sections describe how some of difficulties encountered in
these 3 points were resolved.
1) Find the address of system call: Like in the exploit
described in section III-C, a kernel parameter is modified
thanks to the JTAG probe and then all the system call addresses
are available. The parameter modified in the kernel is a format
specifier designed to hide kernel system call addresses to
a non-authorized user. The modification replaces the format
specifier by another which has no restrictions regarding the
users authorization.
Like for the Exynos Exploit an attacker has the memory
access but he does not have the kernel system call address.
In this case, the manipulation for making the system calls
available is a deterioration of the whole system security.
Similar to the software exploit, an attacker proceeds in
order to change the security of the display of the addresses
of kernel system calls. So the attacker has to look for a
particular kernel string pattern Psought and modify this
latter to provide addresses for everyone. The hardware
debug tool facilitates to directly seek this pattern in memory
but the constraint here is the size that needs to be read
to be sure Psought belongs to it. As explained in chapter
10 of [11], a vast majority of Android devices uses the
traditional 3-gig split where kernel space occupies the highest
gigabyte of address space (≥ 0xC0000000) and user space
occupies the lower three gigabytes (below 0xC0000000).
So the proposed attack is quite simple. First it dumps
the kernel by small packages, one by one starting at the
address 0xC0000000 then it parses these package to find
the sought string pattern included in the kernel function
managing addresses display. Once Psought ="0x204b7025
0x25206325 0x00000a73" ("%pK %c %s\n") is
found, it is replaced with Psubstitution ="0x20207025
0x25206325 0x00000a73" ("%p %c %s\n"), a
depreciated kernel command pattern which has no restriction
for displaying the addresses of system calls. Algorithm 1
summarizes all the steps above. This manipulation facilitates
the display of the addresses of the system calls to anyone
who asks for it. Now, to identify the address of the system
call in which the fault will be injected, a non-privileged user
can ask the kernel through ADB with the commande line:
~$ cat /proc/kallsyms | grep setresuid
2) Inject the fault: The manipulation made in the pre-
vious paragraph 1) allows an attacker to get the address
of set_setresuid function through ADB. Regarding the
system used in the experiment, the address found which marks
the beginning of the function is 0xC00A2954. Through the
JTAG probe it is easy to observe this function in RAM system
memory (see Fig. 1).
The fault injection is carried out at the address
0xC00A298C which has the value 0xE3500000. In ARM
instruction assembly language this value is the opcode for
“cmp r0,#0x0” (see Fig. 2). Observing the instructions of
this function, it is easy to understand that the injected fault
distorts the first comparison. Using the JTAG tool an attacker
can precisely modify this instruction which determines a
connection to another function according to its result. Through
experiments it has been observed that:
∀n ∈ N, 0x0 < n ≤ 0xFF, "CMP R0,#n" ⇒ “only non-
privileged users can get root permissions, i.e. the function is
reversed.”
3) Ask for root permissions: This is the final stage of
the attack. Because sys_setresuid function has been
reversed in the previous step 2), the simple act of asking
for root privileges by a non-root user grants this user root
privileges. This will be done by executing from the ADB
interface a simple software without privileges. So the program
 Algorithm 1: REMOVE THE 0- MASK
Input: Psought : Pattern sought,
Psubsitution : Pattern for the substitution,
Df : Data file.
Output: The list of the addresses where the pattern was
replaced : addresses = [@1 , @2 , . . .].
Function(Df , Psought , Psubsitution )
1 addresses ← [ ]
2 Ptemp ← ""
3 of f set ← @0 ; the starting address of Df
4 done ← F alse
5 while done 6= T rue do
6 SD ← size(Df )
7 SP ← size(Psought )
8 Ptemp ← Df [of f set : SP + of f set] Fig. 2. Beginning of the system call sys_setreuid thanks to the
disassembler of JTAG debug tool.
9 if Ptemp = Psought then
10 Df [of f set : SP + of f set] ← Psubstitution
11 addresses ← addresses + [of f set]
12 of f set ← of f set+0x4
13 else
14 of f set ← of f set+0x4
15 end
16 if of f set < (SD − SP ) then
17 done ← F alse
18 else
19 done ← T rue
20 end
21 end
22 return addresses

Fig. 3. jtag_based_abuse.c

Fig. 1. Beginning of the system call sys_setresuid opcode in the RAM
memory displayed by JTAG debugger.
operations.
V. D ISCUSSION
Throughout the paper we described how JTAG can be use
to modify the code on the fly in order to tamper with any
Operating Systems. Thus we did not crash the system but
simply hijacked it. However a strong assumption was made
on the feasibility of such an attack : the access to the JTAG
interface without restrictions. For the sake of practicality,
most of the time, the development boards have their JTAG
port available and unlocked. But what about the commercial
systems?

jtag_based_abuse.c (see Fig. 3) is compiled and loaded
in the /data/local/tmp directory of the OS running on
the SoC. Then it is executed from ADB comand-line and
provides to new terminal window with the root privileges.
However, it should be noted that in order to finalize this
attack, root privileges obtained through ADB the attacker
must restore sys_setresuid, the function of permission
management to its initial state to perform future privileged
From there two approaches can be addressed:
A. Anyway, try to access to the JTAG interface
This tool is used in circuit fabrication to ensure the quality
of the product or to load the manufacturer’s data and it’s also
useful in the life cycle of devices. Indeed, by using such
a tool it is possible to perform maintenance operations, re-
flash the memory and detect defective product areas. Depriving
electronic industry of such tools would be an obstacle to the
quick marketing of some products. Considering this, there are
several points of view. The first is to not be aware or worried
by the risks related to JTAG. This is still the case, too many
manufacturers feel that simply removing the JTAG connector
is enough to restrict its access. Which is not the case as it is
easy to find many tutorials online which explain how to take
control of such devices without JTAG connector.
The second point of view is to become aware of the risks
associated with JTAG. As explained in some academic articles
such as [6] it is possible to take preventive measures to
ensure the JTAG integrity. Also many manufacturers provide
limited solutions such as NXP which offers 3 security level
for JTAG access [12]: Open access, password access and
no-debug functionality access. The JTAG security mode is
selected irreversibly with fuses. Moreover a disabled JTAG
access mode prevents the use of the JTAG debug tool. This
secured JTAG access prevents the use of the debug tool for
malicious purposes.
Therefore, it is interesting to study these new protection
mechanism. As shown in this work [13], it is possible to
imagine new attack paths and several fault injections in order
to bypass such security mechanism and get access to the JTAG.
In the same context of securing the JTAG, new architectures
with security measures are emerging in recent years. For
example the idea in TrustZone/TEE architectures proposed
by ARM, with hardware support (via a dedicated bus) it is
possible to limit the access permissions to various modules
based on their privileges (including JTAG). The possibility of
bypassing the protections on the JTAG represent an important
domain of study for the security of such systems.
B. Use the JTAG to simulate an prepare a fault injection
In the introduction we explain the complexity to set up a
fault injection attack on SoCs. Even if the JTAG is disabled
on the device that an attacker would like to attack, it could
be still used on a development board similar to this device
in order to simulate if an attack is feasible. On our privilege
escalation attack we have seen that only one bit have to be
flipped. By using other physical quantity like electromagnetic
field for example, it is possible to measure the emission field
related to the call of the function and detect it. This kind of
detection is already done for encryption process on SoCs [14].
Once the function call is detected by pattern matching on
the fly or by interrupts, an electromagnetic pulse is injected
in order to disturb it, as in [15]. The set up of this kind
of manipulation is very important but by repeating the call
to the function and the EM pulse injection it is statistically
possible to succeed.
Both approaches show that the JTAG should not be
considered as a risk only linked to debug. This tool can also
be seen as a support for the set up of a fault attack.
VI. C ONCLUSION
We have demonstrated the use of JTAG debugger to modify
the code on the fly in order to tamper with an Operating
System no matter what it is. JTAG can be considered as
a new fault injection tool for performing or simulating the
feasibility of a combined attack targeting complex embedded
microprocessor. The example presented in this article is based
on an existing software exploit which is now ineffective by the
recent updates for Android operating systems. However using
our demonstrated technique this attack is still feasible.
The only constraint in carrying out this type of attack is
to have unrestricted access to the JTAG interface. This last
assumption is decisive, however, given the state of the art about
current security measures for the JTAG access, our attack is
still relevant.
R EFERENCES
[1] D. Boneh, R. DeMillo, and R. Lipton, “On the importance of checking
cryptographic protocols for faults,” in Advances in Cryptology EURO-
CRYPT 97, ser. Lecture Notes in Computer Science.
[2] H. Bar-El, H. Choukri, D. Naccache, M. Tunstall, and C. Whelan, “The
sorcerer’s apprentice guide to fault attacks,” Proceedings of the IEEE,
vol. 94, no. 2, pp. 370–382, Feb 2006.
[3] “Attacks on java card 3.0 combining fault and logical attacks,” in
Smart Card Research and Advanced Application, ser. Lecture Notes in
Computer Science, D. Gollmann, J.-L. Lanet, and J. Iguchi-Cartigny,
Eds., vol. 6035.
[4] E. Vetillard and A. Ferrari, “Combined attacks and countermeasures,”
in Smart Card Research and Advanced Application, ser. Lecture Notes
in Computer Science.
[5] IEEE Std 1149.1-2013: IEEE Standard for Test Access Port and
Boundary-Scan Architecture – IEEE Computer Society, May 2013,
(Revision of IEEE Std 1149.1-2001).
[6] K. Rosenfeld and R. Karri, “Attacks and defenses for jtag,” Design Test,
IEEE, vol. PP, no. 99, pp. 1–1, 2013.
[7] “Forensic analysis of mobile phone internal memory,” in Advances in
Digital Forensics, ser. IFIP The International Federation for Information
Processing, M. Pollitt and S. Shenoi, Eds., vol. 194.
[8] “Privilege escalation attacks on android,” in Information Security,
ser. Lecture Notes in Computer Science, M. Burmester, G. Tsudik,
S. Magliveras, and I. Ili, Eds., vol. 6531.
[9] Alephzain, “Root exploit on Exynos,” http://forum.xda-
developers.com/galaxy-s3/general/root-root-exploit-exynos-t2047991,
December 2012, [Online; accessed 15-December-2012].
[10] D. Rosenberg, “kptr restrict for hiding kernel pointers from unprivi-
leged users,” https://lwn.net/Articles/420403/, December 2010, [Online;
accessed 18-December-2010].
[11] J. J. Drake, Z. Lanier, C. Mulliner, P. O. Fora, S. A. Ridley, and
G. Wicherski, Android Hacker’s Handbook, 1st ed. Wiley Publishing,
2014.
[12] NXP, “Configuring secure jtag for the i.mx 6 series
family of applications processors - application note,”
http://www.nxp.com/files/32bit/doc/app note/AN4686.pdf, March
2015, document Number: AN4686 Rev. 1.
[13] “Breakthrough silicon scanning discovers backdoor in military chip,”
in Cryptographic Hardware and Embedded Systems CHES 2012, ser.
Lecture Notes in Computer Science, E. Prouff and P. Schaumont, Eds.,
vol. 7428.
[14] J. Longo, E. De Mulder, D. Page, and M. Tunstall, “Soc it to em:
Electromagnetic side-channel attacks on a complex system-on-chip,” in
Cryptographic Hardware and Embedded Systems – CHES 2015: 17th
International Workshop, Saint-Malo, France, September 13-16, 2015,
Proceedings.
[15] S. Ordas, L. Guillaume-Sage, and P. Maurine, “EM injection: Fault
model and locality,” in 2015 Workshop on Fault Diagnosis and
Tolerance in Cryptography, FDTC 2015, Saint Malo, France,
September 13, 2015, 2015, pp. 3–13. [Online]. Available:
http://dx.doi.org/10.1109/FDTC.2015.9