Detection of Android Third Party Libraries (3PLs)based attacks

Amina Waddizawaddiz@enseirb-matmeca.fr

Beumjin Chobeumjincho@postech.ac.kr

Sangwoo Jij1cron@postech.ac.kr

Jong Kim*jkim@postech.ac.kr

Francine Krief*krief@ipb.fr

Abstract

Smartphones are rising in popularity as well asbecoming more sophisticated over recent years. Thispopularity coupled with the fact that smartphonescontain 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 existingthird party libraries (3PLs). The paper also reportsa novel method for malware development and novelattack techniques using third party libraries. Thepossible 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. Smartphonesusers download and install software from applica-tion markets, such as Google Play, Amazon App-Store or Samsung Galaxy Apps. . . . According toAppBrain in 2015, by July 2015, the official marketfor Android applications, Google Play, hosted over1.6 million applications. Despite recent advancesin mobile security, so many malware are not de-tectable by existing techniques and sensitive dataconstitute one of the most remarkable of their tar-gets. The leakage of these sensitive information ispotentially 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, theymust bundle opaque binary code into their applica-tions. Unfortunately, developers must in essenceover privilege their Android applications by re-questing dangerous permissions, such as full In-ternet access, solely for the purpose of supportingthird party libraries. Mixing third party librariesand dangerous permissions introduces vulnerabili-ties and risks to potential compromise of privateuser data.

We present a new approach of tracking malwarein real world android applications. It consists inthird party libraries survey. For the reasons men-tioned before, the study aim to accurately and pre-cisely reveal security threats derived from thirdparty libraries by providing examples and illustra-tions of most dangerous attacks that may affect theuser privacy, android operating system and deviceutilities. Based on our dataset, new solutions couldbe implemented to mitigate to 3PLs-based attacks.

The rest of this document is organized as fol-lowing: Section 2 presents review of related workfollowed by an overview of android system archi-tecture and security model in section 3. After that,section 4 describes precisely the motivation behindthis work and mentions our main objectives. Later,Section 5 shows different third party libraries andtheir usage in android applications, whereas sec-tion 6 characterizes existing and possible androidattacks originally from third party libraries. Sec-tion 7 discusses the possibilities of mitigating toprevious threats. Finally, we summarize our work,in section 8.

2 RELATED WORK

Previous works have approached the understand-ing of application behavior in different ways. Onemuch-studied area is the permission system. Ithas significant limitations, and many papers haveexplored or attempted to address these limitations.Recent work by Bugiel and Davi, XManDroid[15] and System Centric Protection [17], detectsmechanisms by which permissions granted toone application can be leaked to another, eitherinadvertently or deliberately through collusion.Enck and Gilbert [11] present an information-flowtracking system called TaintDroid that detectsprivate data leaks. Kirin [16] detects potentiallydangerous applications at install-time based oncombinations of permissions and intent strings.However, any change to the permission systemwould require fundamental changes to Android,which may limit how likely these solutions are tobe implemented.

Other works seek to isolate advertising librariesfrom host applications. AdDroid [13] by Pearceand Felt, suggests a privilege separation manner toaddress the threats introduced by over-privilegedapplications, this approach rely on extending An-droid API to support advertising libraries as wellas introducing new permissions to detect whetherthe application contain advertisements or not.Likewise, AdSplit [12] aims for this separation,yet this work examined the impact of maliciousactivities primarily focused on fraud that harmedthe advertiser, similar to AdDroid, it deals withover-privileged applications especially those withadvertising libraries by running them into twodifferent processes. AdSplit also uses prior workQUIRE [14] to allow both applications to bedisplayed in a shared screen.

Other researches, Zhang and Ahlwat, foundout a different way to handle such a problem ofthe advertising libraries. AFrame [18] provides ageneral approach to isolate third-party librariesinto a separate process. It targets libraries thatneed strong isolation and do not interact quiteoften with the main process. Effectively, similarwork designed to separate ads and apps as anadditional ad library protection technique [20].

Several other studies have developed com-plementary mechanisms to improve user anddeveloper control of applications. A recent work[19] has implemented a new system PEDAL, whichcan detect Ad libraries even in the presence ofobfuscated code. It performs instrumentation ofbytecode to de-escalate the privileges of sensitiveresources such as location, contacts, etc. Howeverthese 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 theirthreats, other third party libraries haven’t takenpart of any prior work, after all they are a largeexploited attack surface. As far as we know, thereis no similar approach that can classify 3PLs at-tacks and reveal their based attacks. We open thedoor for a novel perspective of security vulnerabili-ties in android system by revealing the threats andthe damage mostly used third-party libraries mayinvoke.

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 formobile devices. It includes a Linux kernel, mid-dleware framework, and core applications. TheLinux kernel provides low-level services to the restof the system, such as networking, storage, mem-ory, and processing. A middleware layer consists ofnative Android libraries (written in C/C++), anoptimized version of a Java Virtual Machine calledDalvik Virtual Machine (DVM), and core librarieswritten in Java. The DVM executes binaries ofapplications residing in higher layers. Android ap-plications are written in Java and consist of sepa-rated modules, so-called components. Componentscan communicate to each other and to componentsof other applications through an inter componentcommunication (ICC) mechanism provided by theAndroid middleware called Binder. As Android ap-plications are written in Java, they are basically

protected against standard buffer overflow attacksdue to the implicit bound checking. However, Java-applications can also access C/C++ code librariesvia the Java Native Interface (JNI). Developersmay use JNI to incorporate own C/C++ librariesinto the program code, e.g., due to performancereasons. Moreover, many C libraries are mapped bydefault to fixed memory addresses in the programmemory space. Due to the inclusion of C/C++libraries, the security guarantees provided by theJava 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 aUserID, while for each file (i.e., object) access rulesare specified. Each file is assigned access rules forthree 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 otherand from system resources. System files are ownedby either the “system” or “root” user, while otherapplications have own unique identifiers. In thisway, an application can only access files owned byitself or files of other applications that are explicitlymarked 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 Androidpermissions such as PHONE CALLS, INTERNET,SEND SMS meaning that applications have to pos-sess these permissions to be able to perform phonecalls, to access the Internet or to send text mes-sages. Additionally, applications may declare cus-tom types of permission labels to restrict access toown interfaces. Required permissions are explic-itly specified in a Manifest file and are approved atinstallation time based on checks against the sig-natures of the applications declaring these permis-sions and on user confirmation illustrated on figure2. Binder in Android is a reduced custom imple-mentation of OpenBinder. Privilege Escalation At-tacks on Android. At runtime, when an ICC callis requested by a component, the reference monitorchecks whether the application of this componentpossesses appropriate permissions. Additionally,application developers may place reference moni-tor hooks directly into the code of components toverify permissions granted to the ICC call initiator.

Figure 2: Request to accept an app permissions atinstall time

3.2.4 Component Encapsulation

Application components can be specified as pub-lic or private. Private components are accessibleonly by components within the same application.When declared as public, components are reachableby other applications as well, however, full accesscan be limited by requiring calling applications to

have specified permissions.

3.2.5 Application Signing

Android uses cryptographic signatures to verifythe origin of applications and to establish trust rela-tionships among them. Therefore, developers haveto sign the application code. This allows to enablesignature-based permissions, or to allow applica-tions from the same origin (i.e., signed by the samedeveloper) to share the same UserID. A certificateof the signing key can be self-signed and does notneed to be issued by a certification authority. Thecertificate is enclosed into the application installa-tion package such that the signature made by thedeveloper can be validated at installation time.

4 Motivation, Objectives andContribution

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 sameprocess as the host application. It allows them tohave the same permissions. 3PLs can leak sensi-tive information, access to the process address andthereby go through the system whenever it is possi-ble. Hence this research aim to identify the currentstate of malware generated by 3PLs in Android ap-plications, classify existing 3PLs and their threats.This survey call for novel suggestions to tackle thesepossible malwares. The main contributions of thispaper are twofold: (i) Survey and classification ofexisting 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 theirlicense, their popularity in android applications andthe field of usage.

5.1 Classification

Table 1: An overview of existing 3PLs

In table 1, we collected the most important andthe very used libraries, classified them in order toprovide a valuable dataset to rely on for later expla-nation in the upcoming paragraph. The pack listedabove are libraries that are quite popular, widelyapplicable and should probably be setup withinmost Android applications. We have included a de-scription of each library that tells the functionalityas well as the purpose of usage.

5.2 Characterization and Usage inandroid applications

Applications developed for Android Smart-phones are compressed files consisting of com-piled source programs, resources, information filesneeded to run such programs in Android OS anddevelopers’ code signing files. As in Figure 3,classes.dex is the compiled JAVA source program.Resources such as strings, images and UI screens

are kept in the res folder. Resources.arsc containsthe resource-related information. The META-INFholds electronic signature files. The electronic sig-nature uses SHA1 as its hash function and RSA asthe default signature algorithm. Once developerssign 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 notifiedto Android system before an app is executed, e.g.the name of the app, activities that make up theapp, service, information about ContentProvider,information about permissions to access protectedAndroid API and the version of the Android API.

Figure 3: Android app file structure

There are many 3PLs for android apps, yet weonly mentioned some of the extremely popular andthe most used in almost all android applications.Each has different purposes and area of use, but allof them make life easier for developers. Hence, theuse of 3PLs is getting spread over android applica-tions, what makes it more complicated for securityresearchers to grant the user privacy and the systemsafety. Especially that 3PLs share the same processas the host application, that is why it is needed toclarify the usage of them in apps. As shows the fig-ure 3, generally speaking android components thatare involved in this study are: resources (i.e. activ-ity file..), java classes and Android manifest. An-other important element to mention in this sectionis build.gradle which is the typical file to compilethe whole package of an android application intoan apk file that will be the binary to execute onceinstalled from one of android markets. These areall the components involved in setting up an ap-plication with 3PLs. However, the usage dependson the nature of third party library. For example

Ad libraries are totally independent from host ap-plication, because they only provide a banner orinterstitials to show the ads and allow clicks onthem without any interaction with the host ap-plication. Whereas, User Interface libraries tendto interact very often with the application, as thegraphic interface is an essential part of any applica-tion and widely spread through java classes. Otherlibraries, such as network or database libraries arelikely interactive with their host application, never-theless they are mostly susceptible to be separated,as demonstrates figure 4.a using retrofit which is anetworking library, most of the application compo-nents call the 3PL, yet only the service componentdoes implement the interface, however it doesn’thave a regular implementation, instead the imple-mentation is generated by Retrofit as illustrated infigure 4.b. This analysis was based on our observa-tions on some simple applications including most ofthe libraries mentioned before. It turns out that theusage of 3PLs changes from one another. On onehand, it depends on the application design, the re-quirements as well as the developer preferences. Onthe other, the 3PL type implies its degree of inter-action with the host application, which determinewhether the application and the 3PL can be sepa-rated or it is likely a challenging issue (See figure4.c). The possibilities of separation are discussedin section 7.

6 Third party library based at-tacks

After analysing 3PLs’ usage in android applica-tions, we could observe and figure out some attacksurfaces in android system and the host application.

6.1 3PLs ThreatsIn actual fact, for vast majority of cases, the

3PLs-based attack is performed using some androidvulnerabilities or the host application security lack.Although sandboxing technique in android isolateseach application into its own process and protectsevery single application from other third party ap-plications, it is still possible to perform attacks us-ing 3PLs embedded in the application since theyboth of them run within the same process. The3PLs have total access to the same data as the

(a) Dependencies scheme between differentandroid components in an android appli-cation that includes a networking library:“Retrofit”

(b) Zoom in the service component and usageof 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 blindspot for attackers who usually aim to make revenueby different ways:

• Steal the user data: Intercept text, steal pass-words or access to location...

• Turn the device into Bots: Perform maliciousactions and gain root privileges

• Direct Financial gain: Call or text premiumnumbers or steal Online banking credential

In this section, we assume that android applicationdeveloper is benign. However, he usually includessome 3PLs blindly without any security verifica-tion. Our demonstration scenarios are based onthe threat model presented in figure 5. 3PLs arequite likely able to perform several attacks and leakusers’ sensitive data or provoke some other damagesto 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 androidsecurity (Sandboxing, permission model . . . ). Thatmakes attackers exploit physical hooks to performstheir attacks in order to steal some private infor-mation or cause other damages. In this context,we distinguish between two different classificationsas 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-

damental categories of 3PLs-based attacks:

• Privacy: The first priority of security re-searchers is privacy because user sensitivedata is quite likely to be leaked to an externalserver and be exploited for some maliciousreasons such as making revenue. Our scenariofor this category is a permission based attackillustrated in figure 6.

We assume an application that hosts athird-party advertising library. We allowthe application to access INTERNET andLOCATION. The library can easily get theuser’s location and send it to the advertisingserver that can use it for legitimate reasonsas well as some malicious purposes. Neitherthe user nor the developer know the finaldestination of these data.

Hence, this attack can be very dangerousalthough it’s simplicity, a secret conference forexample could be revealed by spies, which canbe an extreme risk. Historically, to mitigate tothese threats, the previous works were mostlybased on static analysis [11].

This solution is always valid to tracksensitive that, yet it has several limitationswhich makes it unpractical. TaintDroid forexample, is able to only know presence ornot of a certain leakage, however since the3PLs and the application are packaged inthe same compiled file, static analysis toolcannot know whether the application leakedthe information or 3PLs did so.

• Financial damage: In this category, wepresent some 3PLs-based attacks that bringsabout financial loss. Attacks typically includeFrauds, send premium SMS or calls. Accord-ing to ARXAN security report, adversarieshave hacked 78% paid android apps.We believe this is also possible using 3PLseven with benign application. Financialattacks performed by 3PLs are more likely tobypass android security especially within amild host application.

In fact, 3PLs have total access to theapplication resources, thus they can forexample listen to the communication betweenthis application and financial applications.Effectively, cracked versions of most popularfinancial apps are 58% in android according toARXAN. Vulnerabilities in host applicationsmake it easy for 3PLs to play their attacks inwider surface.

• Device usability: Mobile devices have al-ways been required to satisfy a minimum per-formance. Battery in smartphones is one of themost important device components that makesit valuable or not. Therefore, device utilitiesare worth to be protected.Some attacks targets battery, in order to drainfor some illegal commercial benefits or mali-cious reasons. The screen as well has been adirect target for android malwares, various at-tacks have been proposed against device screenwhether for damage such as lock the screen orretrieve some data for instance password fromtouch keyboard.These already existing attacks made my mali-cious applications are completely possible us-ing 3PLs within a benign application. The3PLs can use the same techniques to get datafrom the device touch keyboard and cause anydamage to the screen. Existing solutions areonly applicable for third party application as itis identified by its own UID. Our current con-text is completely different because the 3PLsare hosted within the same process as the mildapplication. 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

Table 2: 3PLs-based attacks Functional Classification

6.2.2 Agent-based classification

An attack needs sinks and vulnerabilities in orderto be able to play malicous actions. Although theadvanced security policies in android system, thereare some blind spots that can be exploitable by3PLs. Table 3. shows the most important vulner-able agents susceptible to be attacked by externalparties via 3PLs. In our survey, we include threemain categories:

Table 3: Agent-based classification of 3PLs

• Memory: In general, physical attack needsa rooted privilege. However some applicationscould perform Bus monitoring attack that con-sists in injecting a tool in the bus memoryand wait for the CPU to request some sen-sitive data, then steal them. We also believethat 3PLs are absolutely able to perform suchan attack, since 3PLs can easily access to thememory allocated to the application as wellas any other system files that are accessible

via the host application. Some Encryption-based extensions were suggested to mitigateto it [22] and [23]. These solutions are appro-priate for 3PLs-based bus monitoring attackbecause it enforces the basic principle of En-cryption which is general, since the 3PLs don’thave access to the Authentication keys. An-other example is direct memory attack, whichtackles the directly the RAM.

• Side Channel: Side-channel attacks aimto obtain sensitive information by exploitingphysical properties of the cryptographic im-plementation, such as timing information orpower consumption. For example, differentkeys could affect the amount of processing timeor power required to do the encryption dif-ferently, revealing something about the keys’structure. On of the solution for this attacksuggest 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 todownload, install or run arbitrary code on an-droid devices. We developed a simple appli-cation that hosts a 3PL which can downloadan arbitrary code from an external server andrun it, all in the background, thus the userwon’t be alerted of any of these actions. Witha malicious code, this attack can result seri-ous damages not only to the application itselfbut also to the device and to the system othercomponents.

• Network: Denial of service is from the mostchallenging attacks that has been discovered inandroid. In fact, In order for a mobile deviceto communicate through a mobile network, acertain procedure must first take place. Thisprocedure, shown in figure 7, includes a clientconnection request followed by an authentica-tion procedure. If the client successfully com-pletes this procedure, he is authenticated tothe network, a connection channel is given tothe device, and the client may then send andreceive data.In 2G, 3G and 4G networks, all data commu-nication performed after this initial authen-tication procedure is encrypted and digitally

signed when sent over the radio network. Thisprevents eavesdropping, modifying or replay-ing of the data by third parties. However, thedata flow preceding the authentication proce-dure (i.e. all data sent and received in stages1-4 in figure 7) contains no encryption or digi-tal signing, since the trust required for imple-menting these protections is gained only afterthe authentication procedure (stage 5) is com-

plete. This behavior could be misused by 3PLsin order to create an attach flood. The attackerwill send a high rate of fake attach messagesto the network, causing high resource utiliza-tion on the backend signaling gateways (MME,HSS for 4G or MSC, BSC, VLR on 3G). Thismay cause anything from a local station outageto 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 leavetheir users vulnerable to a range of risks, includingthe 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 havebecome general purpose computing devices wheresensitive information is readily available: Contactlists, phone numbers, geolocation, financial and so-cial data. Android does not provide users with suf-ficient control over their data and privacy. Ourgoal is to offer users proper control over their datawhile minimizing the burden of change to applica-tion developers and consumers. This work presentsa reliable dataset of 3PLs and their specificationsas well as 3PLs-based attacks. It turns out that weneed to develop a security extension that appliesthe 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 implementationof this solution since we had to keep the applica-tion integrity which is one of the most importantprinciples of security. Two prototype implementa-tions were suggested showing different possibilitiesto separate the two processes:The first one was to isolate 3PLs process before theapplication encapsulation, it means that we need tomodify the compiler. The second was to interveneafter the application installation by separating thepermissions related to 3PLs from those used by thehost application.Both solutions are challenging. The first keeps theapplication integrity, however it presents a licenceproblem since the compiler is an Oracle property.The second is not practical since separating per-missions is not sufficient while both 3PLs and theapplication run in the same process.

8 CONCLUSION

In this paper, we have presented an analysis andclassification for Android 3PLs and their threats.We have collected, studied and classified the mostused 3PLs in android apps. This classification isprovided in terms of their behaviour and usage.We have also identified and unveiled 3PLs-basedthreats attacking most android components. Theseresults show the necessity of a novel approach totackle 3PLs-based already existing malware andprevent from some of the possible attacks. Wehope to build an efficient tool to separate 3PLsfrom the host application leveraging a novel solu-tion and countermeasure against threats discussedin this paper.

9 ACKNOWLEDGEMENT

This work is part of Android Security projectlaunched by High Performance Computing Lab.in Pohang University Of Science and Technology(POSTECH) in Pohang, South Korea in collabora-tion with ENSEIRB-MATMECA Graduate Schoolof Engineering in Bordeaux, France. We wouldlike 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 mymentor, 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, CollinMulliner, Pau Oliva Fora, StephenA. Ridley,Georg Wicherski. AndroidHacker’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’sSecurity 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. InProc. 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. InUSENIX 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

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 applicationcertification. In Proc. of the ACM conferenceon 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 Symposiumon 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 29thAnnual 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 Librariesin Mobile Apps. In Proceedings of the 13thInternational 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 CodeLoading in Android Applications,” in Proceed-ings of the 20th Annual Network DistributedSystem 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 tabletsfrom memory attacks,” in Proceedings of theTwentieth International Conference on Archi-tectural Support for Programming Languages

and Operating Systems, ASPLOS ’15, (NewYork, 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.