1. Detection of Android Third Party Libraries (3PLs)
based attacks
Amina Waddiz
awaddiz@enseirb-matmeca.fr
Beumjin Cho
beumjincho@postech.ac.kr
Sangwoo Ji
j1cron@postech.ac.kr
Jong Kim*
jkim@postech.ac.kr
Francine Krief*
krief@ipb.fr
Abstract
Smartphones are rising in popularity as well as
becoming more sophisticated over recent years. This
popularity coupled with the fact that smartphones
contain a lot of private user data is causing a pro-
portional rise in different malwares for the plat-
form. In this paper we analyze and classify existing
third party libraries (3PLs). The paper also reports
a novel method for malware development and novel
attack techniques using third party libraries. The
possible countermeasures are also proposed.
1 INTRODUCTION
Android is the world’s most popular mobile plat-
form. Seventy percent of smartphones use An-
droid as their operating system. Smartphones
users download and install software from applica-
tion markets, such as Google Play, Amazon App-
Store or Samsung Galaxy Apps. . . . According to
AppBrain in 2015, by July 2015, the official market
for Android applications, Google Play, hosted over
1.6 million applications. Despite recent advances
in mobile security, so many malware are not de-
tectable by existing techniques and sensitive data
constitute one of the most remarkable of their tar-
gets. The leakage of these sensitive information is
potentially caused by malicious or misuse of code,
such as third party libraries, in android applica-
tions.
Third-party libraries, such as advertising net-
works, gaming networks and user interface libraries
(UI), are an integral part of modern mobile plat-
forms. If Android developers want to integrate
functionality provided by third party libraries, they
must bundle opaque binary code into their applica-
tions. Unfortunately, developers must in essence
over privilege their Android applications by re-
questing dangerous permissions, such as full In-
ternet access, solely for the purpose of supporting
third party libraries. Mixing third party libraries
and dangerous permissions introduces vulnerabili-
ties and risks to potential compromise of private
user data.
We present a new approach of tracking malware
in real world android applications. It consists in
third party libraries survey. For the reasons men-
tioned before, the study aim to accurately and pre-
cisely reveal security threats derived from third
party libraries by providing examples and illustra-
tions of most dangerous attacks that may affect the
user privacy, android operating system and device
utilities. Based on our dataset, new solutions could
be implemented to mitigate to 3PLs-based attacks.
The rest of this document is organized as fol-
lowing: Section 2 presents review of related work
followed by an overview of android system archi-
tecture and security model in section 3. After that,
section 4 describes precisely the motivation behind
this work and mentions our main objectives. Later,
Section 5 shows different third party libraries and
their usage in android applications, whereas sec-
tion 6 characterizes existing and possible android
attacks originally from third party libraries. Sec-
tion 7 discusses the possibilities of mitigating to
previous threats. Finally, we summarize our work,
in section 8.

2. 2 RELATED WORK
Previous works have approached the understand-
ing of application behavior in different ways. One
much-studied area is the permission system. It
has significant limitations, and many papers have
explored or attempted to address these limitations.
Recent work by Bugiel and Davi, XManDroid
[15] and System Centric Protection [17], detects
mechanisms by which permissions granted to
one application can be leaked to another, either
inadvertently or deliberately through collusion.
Enck and Gilbert [11] present an information-flow
tracking system called TaintDroid that detects
private data leaks. Kirin [16] detects potentially
dangerous applications at install-time based on
combinations of permissions and intent strings.
However, any change to the permission system
would require fundamental changes to Android,
which may limit how likely these solutions are to
be implemented.
Other works seek to isolate advertising libraries
from host applications. AdDroid [13] by Pearce
and Felt, suggests a privilege separation manner to
address the threats introduced by over-privileged
applications, this approach rely on extending An-
droid API to support advertising libraries as well
as introducing new permissions to detect whether
the application contain advertisements or not.
Likewise, AdSplit [12] aims for this separation,
yet this work examined the impact of malicious
activities primarily focused on fraud that harmed
the advertiser, similar to AdDroid, it deals with
over-privileged applications especially those with
advertising libraries by running them into two
different processes. AdSplit also uses prior work
QUIRE [14] to allow both applications to be
displayed in a shared screen.
Other researches, Zhang and Ahlwat, found
out a different way to handle such a problem of
the advertising libraries. AFrame [18] provides a
general approach to isolate third-party libraries
into a separate process. It targets libraries that
need strong isolation and do not interact quite
often with the main process. Effectively, similar
work designed to separate ads and apps as an
additional ad library protection technique [20].
Several other studies have developed com-
plementary mechanisms to improve user and
developer control of applications. A recent work
[19] has implemented a new system PEDAL, which
can detect Ad libraries even in the presence of
obfuscated code. It performs instrumentation of
bytecode to de-escalate the privileges of sensitive
resources such as location, contacts, etc. However
these work do not cover all third party libraries,
neither capture incoming malicious attacks.
Unlike Ad libraries, that have attracted many se-
curity researchers to work on and mitigate to their
threats, other third party libraries haven’t taken
part of any prior work, after all they are a large
exploited attack surface. As far as we know, there
is no similar approach that can classify 3PLs at-
tacks and reveal their based attacks. We open the
door for a novel perspective of security vulnerabili-
ties in android system by revealing the threats and
the damage mostly used third-party libraries may
invoke.
3 Android background
Before elaborating on our survey, we briefly de-
scribe android architecture and the security mech-
anisms.
3.1 Android System architecture
Android is an open source software platform for
mobile devices. It includes a Linux kernel, mid-
dleware framework, and core applications. The
Linux kernel provides low-level services to the rest
of the system, such as networking, storage, mem-
ory, and processing. A middleware layer consists of
native Android libraries (written in C/C++), an
optimized version of a Java Virtual Machine called
Dalvik Virtual Machine (DVM), and core libraries
written in Java. The DVM executes binaries of
applications residing in higher layers. Android ap-
plications are written in Java and consist of sepa-
rated modules, so-called components. Components
can communicate to each other and to components
of other applications through an inter component
communication (ICC) mechanism provided by the
Android middleware called Binder. As Android ap-
plications are written in Java, they are basically

3. protected against standard buffer overflow attacks
due to the implicit bound checking. However, Java-
applications can also access C/C++ code libraries
via the Java Native Interface (JNI). Developers
may use JNI to incorporate own C/C++ libraries
into the program code, e.g., due to performance
reasons. Moreover, many C libraries are mapped by
default to fixed memory addresses in the program
memory space. Due to the inclusion of C/C++
libraries, the security guarantees provided by the
Java programming language do not hold any longer.
3.2 Android Security model
3.2.1 Discretionary Access Control (DAC)
The DAC mechanism is inherited from Linux,
which controls access to files by process ownership.
Each running process (i.e., subject) is assigned a
UserID, while for each file (i.e., object) access rules
are specified. Each file is assigned access rules for
three sets of subjects: user, group and everyone.
Each subject set may have permissions to read,
write and execute a file.
3.2.2 Sandboxing
Sandboxing isolates applications from each other
and from system resources. System files are owned
by either the “system” or “root” user, while other
applications have own unique identifiers. In this
way, an application can only access files owned by
itself or files of other applications that are explicitly
marked as readable/writable/executable for others.
Figure 1: Sandboxing concept in android system
3.2.3 The permission mechanism
It is provided by the middleware layer of An-
droid. A reference monitor enforces mandatory ac-
cess control (MAC) on ICC calls. Security sensi-
tive interfaces are protected by standard Android
permissions such as PHONE CALLS, INTERNET,
SEND SMS meaning that applications have to pos-
sess these permissions to be able to perform phone
calls, to access the Internet or to send text mes-
sages. Additionally, applications may declare cus-
tom types of permission labels to restrict access to
own interfaces. Required permissions are explic-
itly specified in a Manifest file and are approved at
installation time based on checks against the sig-
natures of the applications declaring these permis-
sions and on user confirmation illustrated on figure
2. Binder in Android is a reduced custom imple-
mentation of OpenBinder. Privilege Escalation At-
tacks on Android. At runtime, when an ICC call
is requested by a component, the reference monitor
checks whether the application of this component
possesses appropriate permissions. Additionally,
application developers may place reference moni-
tor hooks directly into the code of components to
verify permissions granted to the ICC call initiator.
Figure 2: Request to accept an app permissions at
install time
3.2.4 Component Encapsulation
Application components can be specified as pub-
lic or private. Private components are accessible
only by components within the same application.
When declared as public, components are reachable
by other applications as well, however, full access
can be limited by requiring calling applications to

4. have specified permissions.
3.2.5 Application Signing
Android uses cryptographic signatures to verify
the origin of applications and to establish trust rela-
tionships among them. Therefore, developers have
to sign the application code. This allows to enable
signature-based permissions, or to allow applica-
tions from the same origin (i.e., signed by the same
developer) to share the same UserID. A certificate
of the signing key can be self-signed and does not
need to be issued by a certification authority. The
certificate is enclosed into the application installa-
tion package such that the signature made by the
developer can be validated at installation time.
4 Motivation, Objectives and
Contribution
The motivation behind this work consists in pro-
tecting the user sensitive data as well as defend-
ing the system safety against 3PLs-based attacks.
Since 3PLs are currently running within the same
process as the host application. It allows them to
have the same permissions. 3PLs can leak sensi-
tive information, access to the process address and
thereby go through the system whenever it is possi-
ble. Hence this research aim to identify the current
state of malware generated by 3PLs in Android ap-
plications, classify existing 3PLs and their threats.
This survey call for novel suggestions to tackle these
possible malwares. The main contributions of this
paper are twofold: (i) Survey and classification of
existing 3PLs and (ii) dataset of 3PLs-based at-
tacks.
5 Third party library survey
In this section, we present a systematic classifica-
tion of existing 3PLs, taking in consideration their
license, their popularity in android applications and
the field of usage.
5.1 Classification
Table 1: An overview of existing 3PLs
In table 1, we collected the most important and
the very used libraries, classified them in order to
provide a valuable dataset to rely on for later expla-
nation in the upcoming paragraph. The pack listed
above are libraries that are quite popular, widely
applicable and should probably be setup within
most Android applications. We have included a de-
scription of each library that tells the functionality
as well as the purpose of usage.
5.2 Characterization and Usage in
android applications
Applications developed for Android Smart-
phones are compressed files consisting of com-
piled source programs, resources, information files
needed to run such programs in Android OS and
developers’ code signing files. As in Figure 3,
classes.dex is the compiled JAVA source program.
Resources such as strings, images and UI screens

5. are kept in the res folder. Resources.arsc contains
the resource-related information. The META-INF
holds electronic signature files. The electronic sig-
nature uses SHA1 as its hash function and RSA as
the default signature algorithm. Once developers
sign their programs with their own private keys, de-
veloped programs can be installed on Smartphones.
AndroidManifest.xml is a compiled binary file con-
taining essential information that need be notified
to Android system before an app is executed, e.g.
the name of the app, activities that make up the
app, service, information about ContentProvider,
information about permissions to access protected
Android API and the version of the Android API.
Figure 3: Android app file structure
There are many 3PLs for android apps, yet we
only mentioned some of the extremely popular and
the most used in almost all android applications.
Each has different purposes and area of use, but all
of them make life easier for developers. Hence, the
use of 3PLs is getting spread over android applica-
tions, what makes it more complicated for security
researchers to grant the user privacy and the system
safety. Especially that 3PLs share the same process
as the host application, that is why it is needed to
clarify the usage of them in apps. As shows the fig-
ure 3, generally speaking android components that
are involved in this study are: resources (i.e. activ-
ity file..), java classes and Android manifest. An-
other important element to mention in this section
is build.gradle which is the typical file to compile
the whole package of an android application into
an apk file that will be the binary to execute once
installed from one of android markets. These are
all the components involved in setting up an ap-
plication with 3PLs. However, the usage depends
on the nature of third party library. For example
Ad libraries are totally independent from host ap-
plication, because they only provide a banner or
interstitials to show the ads and allow clicks on
them without any interaction with the host ap-
plication. Whereas, User Interface libraries tend
to interact very often with the application, as the
graphic interface is an essential part of any applica-
tion and widely spread through java classes. Other
libraries, such as network or database libraries are
likely interactive with their host application, never-
theless they are mostly susceptible to be separated,
as demonstrates figure 4.a using retrofit which is a
networking library, most of the application compo-
nents call the 3PL, yet only the service component
does implement the interface, however it doesn’t
have a regular implementation, instead the imple-
mentation is generated by Retrofit as illustrated in
figure 4.b. This analysis was based on our observa-
tions on some simple applications including most of
the libraries mentioned before. It turns out that the
usage of 3PLs changes from one another. On one
hand, it depends on the application design, the re-
quirements as well as the developer preferences. On
the other, the 3PL type implies its degree of inter-
action with the host application, which determine
whether the application and the 3PL can be sepa-
rated or it is likely a challenging issue (See figure
4.c). The possibilities of separation are discussed
in section 7.
6 Third party library based at-
tacks
After analysing 3PLs’ usage in android applica-
tions, we could observe and figure out some attack
surfaces in android system and the host application.
6.1 3PLs Threats
In actual fact, for vast majority of cases, the
3PLs-based attack is performed using some android
vulnerabilities or the host application security lack.
Although sandboxing technique in android isolates
each application into its own process and protects
every single application from other third party ap-
plications, it is still possible to perform attacks us-
ing 3PLs embedded in the application since they
both of them run within the same process. The
3PLs have total access to the same data as the

6. (a) Dependencies scheme between different
android components in an android appli-
cation that includes a networking library:
“Retrofit”
(b) Zoom in the service component and usage
of the 3PL, Retrofit, in android application
(c) Example of challenges present in isolating 3PL from the host application
Figure 4: Illustration of android application using 3PLs
host application (application resources, process ad-
dress. . . .). This vulnerability provides a new blind
spot for attackers who usually aim to make revenue
by different ways:
• Steal the user data: Intercept text, steal pass-
words or access to location...
• Turn the device into Bots: Perform malicious
actions and gain root privileges
• Direct Financial gain: Call or text premium
numbers or steal Online banking credential
In this section, we assume that android application
developer is benign. However, he usually includes
some 3PLs blindly without any security verifica-
tion. Our demonstration scenarios are based on
the threat model presented in figure 5. 3PLs are
quite likely able to perform several attacks and leak
users’ sensitive data or provoke some other damages
to the device or any other digital properties.
Figure 5: An overview of 3PLs-based attack
6.2 Attacks Classification
3PLs-based attacks are meant to bypass android
security (Sandboxing, permission model . . . ). That
makes attackers exploit physical hooks to performs
their attacks in order to steal some private infor-
mation or cause other damages. In this context,
we distinguish between two different classifications
as following:
6.2.1 Functional Classification
In this part, we classify 3PLs based on their func-
tion or their impact on the user, his financial re-
sources or his device. Table 2. presents three fun-

7. damental categories of 3PLs-based attacks:
• Privacy: The first priority of security re-
searchers is privacy because user sensitive
data is quite likely to be leaked to an external
server and be exploited for some malicious
reasons such as making revenue. Our scenario
for this category is a permission based attack
illustrated in figure 6.
We assume an application that hosts a
third-party advertising library. We allow
the application to access INTERNET and
LOCATION. The library can easily get the
user’s location and send it to the advertising
server that can use it for legitimate reasons
as well as some malicious purposes. Neither
the user nor the developer know the final
destination of these data.
Hence, this attack can be very dangerous
although it’s simplicity, a secret conference for
example could be revealed by spies, which can
be an extreme risk. Historically, to mitigate to
these threats, the previous works were mostly
based on static analysis [11].
This solution is always valid to track
sensitive that, yet it has several limitations
which makes it unpractical. TaintDroid for
example, is able to only know presence or
not of a certain leakage, however since the
3PLs and the application are packaged in
the same compiled file, static analysis tool
cannot know whether the application leaked
the information or 3PLs did so.
• Financial damage: In this category, we
present some 3PLs-based attacks that brings
about financial loss. Attacks typically include
Frauds, send premium SMS or calls. Accord-
ing to ARXAN security report, adversaries
have hacked 78% paid android apps.
We believe this is also possible using 3PLs
even with benign application. Financial
attacks performed by 3PLs are more likely to
bypass android security especially within a
mild host application.
In fact, 3PLs have total access to the
application resources, thus they can for
example listen to the communication between
this application and financial applications.
Effectively, cracked versions of most popular
financial apps are 58% in android according to
ARXAN. Vulnerabilities in host applications
make it easy for 3PLs to play their attacks in
wider surface.
• Device usability: Mobile devices have al-
ways been required to satisfy a minimum per-
formance. Battery in smartphones is one of the
most important device components that makes
it valuable or not. Therefore, device utilities
are worth to be protected.
Some attacks targets battery, in order to drain
for some illegal commercial benefits or mali-
cious reasons. The screen as well has been a
direct target for android malwares, various at-
tacks have been proposed against device screen
whether for damage such as lock the screen or
retrieve some data for instance password from
touch keyboard.
These already existing attacks made my mali-
cious applications are completely possible us-
ing 3PLs within a benign application. The
3PLs can use the same techniques to get data
from the device touch keyboard and cause any
damage to the screen. Existing solutions are
only applicable for third party application as it
is identified by its own UID. Our current con-
text is completely different because the 3PLs
are hosted within the same process as the mild
application. Hence, the already existing solu-
tion are not adaptable for 3PLs-based attacks.
Figure 6: Example of a advertising 3PL leaking loca-
tion to an external server

8. Table 2: 3PLs-based attacks Functional Classification
6.2.2 Agent-based classification
An attack needs sinks and vulnerabilities in order
to be able to play malicous actions. Although the
advanced security policies in android system, there
are some blind spots that can be exploitable by
3PLs. Table 3. shows the most important vulner-
able agents susceptible to be attacked by external
parties via 3PLs. In our survey, we include three
main categories:
Table 3: Agent-based classification of 3PLs
• Memory: In general, physical attack needs
a rooted privilege. However some applications
could perform Bus monitoring attack that con-
sists in injecting a tool in the bus memory
and wait for the CPU to request some sen-
sitive data, then steal them. We also believe
that 3PLs are absolutely able to perform such
an attack, since 3PLs can easily access to the
memory allocated to the application as well
as any other system files that are accessible
via the host application. Some Encryption-
based extensions were suggested to mitigate
to it [22] and [23]. These solutions are appro-
priate for 3PLs-based bus monitoring attack
because it enforces the basic principle of En-
cryption which is general, since the 3PLs don’t
have access to the Authentication keys. An-
other example is direct memory attack, which
tackles the directly the RAM.
• Side Channel: Side-channel attacks aim
to obtain sensitive information by exploiting
physical properties of the cryptographic im-
plementation, such as timing information or
power consumption. For example, different
keys could affect the amount of processing time
or power required to do the encryption dif-
ferently, revealing something about the keys’
structure. On of the solution for this attack
suggest to observe memory access patterns.
However, it doesn’t address completely the at-
tack since most of the side channels are phys-
ical externally measurable. Hence, Side chan-
nel attack remains one of the most sophis-
ticated attacks that 3PLs can easily use to
download, install or run arbitrary code on an-
droid devices. We developed a simple appli-
cation that hosts a 3PL which can download
an arbitrary code from an external server and
run it, all in the background, thus the user
won’t be alerted of any of these actions. With
a malicious code, this attack can result seri-
ous damages not only to the application itself
but also to the device and to the system other
components.
• Network: Denial of service is from the most
challenging attacks that has been discovered in
android. In fact, In order for a mobile device
to communicate through a mobile network, a
certain procedure must first take place. This
procedure, shown in figure 7, includes a client
connection request followed by an authentica-
tion procedure. If the client successfully com-
pletes this procedure, he is authenticated to
the network, a connection channel is given to
the device, and the client may then send and
receive data.
In 2G, 3G and 4G networks, all data commu-
nication performed after this initial authen-
tication procedure is encrypted and digitally

9. signed when sent over the radio network. This
prevents eavesdropping, modifying or replay-
ing of the data by third parties. However, the
data flow preceding the authentication proce-
dure (i.e. all data sent and received in stages
1-4 in figure 7) contains no encryption or digi-
tal signing, since the trust required for imple-
menting these protections is gained only after
the authentication procedure (stage 5) is com-
plete. This behavior could be misused by 3PLs
in order to create an attach flood. The attacker
will send a high rate of fake attach messages
to the network, causing high resource utiliza-
tion on the backend signaling gateways (MME,
HSS for 4G or MSC, BSC, VLR on 3G). This
may cause anything from a local station outage
to a local area network outage.
Figure 7: LTE Mobile Device Attach Procedure (source: www.lteandbeyond.com)
7 DISCUSSION
Developers regularly supplement their mobile ap-
plications with functionality or advertising rev-
enue offered by 3PLs. When developers overprivi-
lege their applications to support 3PLs, they leave
their users vulnerable to a range of risks, including
the potential unauthorized disclosure of privacy-
sensitive user data.
We can apply the concepts we present in this pa-
per to analyze over-privileging problems with ad-
vertising networks, gaming networks, user inter-
face or networking libraries. Smartphones have
become general purpose computing devices where
sensitive information is readily available: Contact
lists, phone numbers, geolocation, financial and so-
cial data. Android does not provide users with suf-
ficient control over their data and privacy. Our
goal is to offer users proper control over their data
while minimizing the burden of change to applica-
tion developers and consumers. This work presents
a reliable dataset of 3PLs and their specifications
as well as 3PLs-based attacks. It turns out that we
need to develop a security extension that applies
the principle of least privilege to mobile applica-
tions and 3PLs.
We found a solution that uses privilege separa-
tion to isolate 3PLs functionality from host appli-
cations. Our idea was to isolate, in another pro-
cess, the 3PLs from their host application process.
Many difficulties were faced in the implementation
of this solution since we had to keep the applica-
tion integrity which is one of the most important
principles of security. Two prototype implementa-
tions were suggested showing different possibilities
to separate the two processes:
The first one was to isolate 3PLs process before the
application encapsulation, it means that we need to
modify the compiler. The second was to intervene
after the application installation by separating the
permissions related to 3PLs from those used by the
host application.
Both solutions are challenging. The first keeps the
application integrity, however it presents a licence
problem since the compiler is an Oracle property.
The second is not practical since separating per-
missions is not sufficient while both 3PLs and the
application run in the same process.

10. 8 CONCLUSION
In this paper, we have presented an analysis and
classification for Android 3PLs and their threats.
We have collected, studied and classified the most
used 3PLs in android apps. This classification is
provided in terms of their behaviour and usage.
We have also identified and unveiled 3PLs-based
threats attacking most android components. These
results show the necessity of a novel approach to
tackle 3PLs-based already existing malware and
prevent from some of the possible attacks. We
hope to build an efficient tool to separate 3PLs
from the host application leveraging a novel solu-
tion and countermeasure against threats discussed
in this paper.
9 ACKNOWLEDGEMENT
This work is part of Android Security project
launched by High Performance Computing Lab.
in Pohang University Of Science and Technology
(POSTECH) in Pohang, South Korea in collabora-
tion with ENSEIRB-MATMECA Graduate School
of Engineering in Bordeaux, France. We would
like to thank our shepherd in POSTECH, Pro-
fessor Jong Kim and my adviser in ENSEIRB-
MATMECA, Mme. Francine Krief for their sup-
port and supervising. I would like to thank my
mentor, Beumjin Cho, for his follow-up and thor-
ough feedbacks on earlier drafts of this paper.
References
[1] Google, “Android Open Source Project.” [On-
line]. Available: https://source.android.com/
[2] Advertising ID. [Online]. Available:
https://developer.android.com/google/play-
services/id.html,2014.
[3] Android API Guides. [Online]. Available:
https://developer.android.com/guide/
index.html,2014.
[4] Android NDK. [Online]. Available:
http://developer.android.com/tools/sdk/ndk/
index.html,2014.
[5] AppBrain Statistics on Android Libraries:
Third party libraries. [Online]. Available:
http://www.appbrain.com/stats/libraries.
[6] Google Play. [Online]. Available:
https://play.google.com/store,2014.
[7] AdMob: Mobile Advertising. [Online]. Avail-
able: http://www.admob.com/.
[8] Apache Coyote. 2011. Apache coyote –
Open source Java platform. [Online]. Avail-
able: http://tomcat.apache.org/tomcat-4.1-
doc/config/coyote.html.
[9] Joshua J. Drake, Zach Lanier, Collin
Mulliner, Pau Oliva Fora, Stephen
A. Ridley,Georg Wicherski. Android
Hacker’s Handbook. Available in Amazon:
http://www.amazon.fr/Android-Hackers-
Handbook-Joshua-Drake/dp/111860864X
[10] Nikolay Elenkov. Android Security Inter-
nals: An In-Depth Guide to Android’s
Security Architecture. Available in Ama-
zon: http://www.amazon.fr/Android-
Security-Internals-In-Depth-
Architecture/dp/1593275811
[11] W. Enck, P. Gilbert, B. Chun, L. Cox, J.
Jung, P. McDaniel, and A. Sheth. TaintDroid:
An Information-flow Tracking System for Re-
altime Privacy Monitoring on Smartphones. In
Proc. OSDI, 2010.
[12] S. Shekhar, M. Dietz, and D. Wallach. AdSplit:
Separating Smartphone Advertising from Ap-
plications. In Proc. USENIX Security, 2012.
[13] P. Pearce, A. Felt, G. Nunez, and D. Wag-
ner. AdDroid: Privilege Separation for Appli-
cations and Advertisers in Android. In Proc.
ACM ASIACCS, 2012.
[14] Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A.,
and Wallach, D. S. Quire: Lightweight Prove-
nance for Smart Phone Operating Systems. In
USENIX Security Symposium (SSYM) (2011).
[15] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer,
and A. Sadeghi. 2011. Xmandroid: A new an-
droid evolution to mitigate privilege escalation

11. attacks. Tech. rep. TR-2011-04, Center for Ad-
vanced Security Research Darmstadt, Technis-
che Universitat Darmstadt, Darmstadt, Ger-
many.
[16] Enck, W., Ongtang, M., and McDaniel, P.
On lightweight mobile phone application
certification. In Proc. of the ACM conference
on Computer and Communications Security
(2009).
[17] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer,
A.-R. Sadeghi, and B. Shastry, “Towards Tam-
ing Privilege-Escalation Attacks on Android,”
in Proceedings of the 19th Annual Symposium
on Network and Distributed System Security,
2012.
[18] Zhang, X., Ahlawat, A., and Du, W. AFrame:
Isolating Advertisements from Mobile Appli-
cations in Android. In Proceedings of the 29th
Annual Computer Security Applications Con-
ference (ACSAC) (New Orleans, Louisiana,
USA, December 9-13 2013).
[19] B. Liu , B. Liu† , H. Jin„ R. Govindan. Effi-
cient Privilege De-Escalation for Ad Libraries
in Mobile Apps. In Proceedings of the 13th
International Conference on Mobile Systems,
Applications and services
[20] H. Kawabata, T. Isohara, K. Takemori, A.
Kubota, J. Kani, H. Agematsu, and M. Nishi-
gaki, “Sanadbox: Sandboxing third party ad-
vertising libraries in a mobile application,”
in Communications (ICC), 2013 IEEE In-
ternational Conference on. IEEE, 2013, pp.
2150–2154.
[21] S. Poeplau, Y. Fratantonio, A. Bianchi, C.
Kruegel, and G. Vigna, “Execute This! An-
alyzing Unsafe and Malicious Dynamic Code
Loading in Android Applications,” in Proceed-
ings of the 20th Annual Network Distributed
System Security Symposium (NDSS), 2014.
[22] P. Colp, J. Zhang, J. Gleeson, S. Suneja, E.
de Lara, H. Raj, S. Saroiu, and A. Wolman,
“Protecting data on smartphones and tablets
from memory attacks,” in Proceedings of the
Twentieth International Conference on Archi-
tectural Support for Programming Languages
and Operating Systems, ASPLOS ’15, (New
York, NY, USA), pp. 177– 189, ACM, 2015.
[23] X. Zhou, S. Demetriou, D. He, M. Naveed, X.
Pan, X. Wang, C. A. Gunter, and K. Nahrst-
edt. Identity, location, disease and more: In-
ferring your secrets from android public re-
sources. In Proceedings of the 2013 ACM Con-
ference on Computer and Communications Se-
curity, CCS ’13, pages 1017–1028, New York,
NY, USA, 2013. ACM.