Embed Size (px)
Citation preview
ApkCombiner: Combining Multiple AndroidApps to Support Inter-App Analysis
Li Li1, Alexandre Bartel2, Tegawende F. Bissyande1,Jacques Klein1, Yves Le Traon1
1 Interdisciplinary Center for Security, Reliability and Trust (SnT),University of Luxembourg
2 EC SPRIDE, Technische Universitat [email protected], [email protected]
Abstract. Android apps are made of components which can leak infor-mation between one another using the ICC mechanism. With the growingmomentum of Android, a number of research contributions have led totools for the intra-app analysis of Android apps. Unfortunately, thesestate-of-the-art approaches, and the associated tools, have long left outthe security flaws that arise across the boundaries of single apps, inthe interaction between several apps. In this paper, we present a toolcalled ApkCombiner which aims at reducing an inter-app communica-tion problem to an intra-app inter-component communication problem.In practice, ApkCombiner combines different apps into a single apk onwhich existing tools can indirectly perform inter-app analysis. We haveevaluated ApkCombiner on a dataset of 3,000 real-world Android apps,to demonstrate its capability to support static context-aware inter-appanalysis scenarios.
1 Introduction
Everyday, millions of users exploit their handheld devices, such as smartphones,for online shopping, social networking, banking, email, etc. At the Google I/O2014, it was revealed that there are now more than 1 billion active Androidusers and over 50 billion app downloads so far. Thus, mobile applications areincreasingly playing an essential role in our daily life, making the safety guards inmobile operating systems an important concern for researchers and practitioners.Because the Android OS accounts for more than 80% of the global smartphoneshipments, it has become a primary target of hackers who are now developingmalicious apps at an industrial scale [1]. Kaspersky has even reported in a recentsecurity bulletin that, now, 98% of mobile malware found target the Androidplatform.
An Android app is a combination of components that use a special interac-tion mechanism to perform Inter-Component Communication (ICC). This lightcommunication model has been exploited by developers to design rich appli-cation scenarios by reusing existing functionality. Unfortunately, because manyAndroid developers have limited expertise in security, the ICC mechanism has
2 Li Li et al.
brought a number of vulnerabilities [4,18]. Examples of known ICC vulnerabili-ties 3 include the Activity Hijacking vulnerability (where a malicious Activity islaunched in place of the intended Activity) and the Intent spoofing vulnerability(where a malicious app sends Intents to an exported component which originallydoes not expect Intents from that app). In previous work [17], we have shownthat Android components can exploit such ICC vulnerabilities to leak privatedata. More recent works have further demonstrated that Android apps exhibitvarious privacy leaks that are built around the ICC mechanism [13,16,20].
The privacy leaks in Android are further exacerbated by the fact that severalapplications can interact and “collaborate” to leak data using the inter-appcommunication (IAC) mechanism. IAC and ICC are similar in Android, andthus present the same vulnerabilities. Unfortunately, state-of-the-art analysistools are focused on ICC by analyzing a single app at a time. Consequently,inter-app privacy leaks cannot be identified and managed by existing tools andapproaches from the literature.
In this paper we propose to empower existing static analysis tools for Androidto work beyond the boundaries of a single app, so as to highlight security flawsin the interactions between two or more apps. To that end we have designedand developed a tool called ApkCombiner which takes as input several appsthat may cohabit in the same device, and yields a single app package (i.e.,apk) combining the different components from the different apps. The resultingpackage is ensured to be ready for analysis by existing tools. Thus, since the IACmechanism is the same as the ICC mechanism, by combining apps, ApkCombinerreduces an IAC problem to an ICC problem, allowing existing tools to indirectlyperform inter-app analysis without any modification.
During the combination of multiple Android apps, some classes may conflictwith one another. In this paper, we take into account two types of conflict:1) the conflicted classes are exactly same (same name and same content), wesolve this type of conflicts by simply dropping the duplicated classes and 2) theconflicted classes are different (same name but different content), we solve thistype of conflicts by first renaming the conflicted classes, and then ensuring thatall dependencies and calls related to those classes are respected throughout theapp code.
The contribution of this paper are as follows:
– We discuss the need for tools to support inter-app analysis, and present anon-intrusive approach that can be leveraged by existing tools which arefocused on intra-app analysis.
– We provide a prototype implementation of ApkCombiner4, using an effectivealgorithm to solve different conflicts which may arise during the combinationof multiple Android apps into one.
– We propose an evaluation of ApkCombiner on both a motivating exampleand on a dataset of real-world Android apps. The experimental results show
3 Refer to Section 2.1 for the concept of component, Activity and Intent in Android.4 We make available our full implementation, along with the experimental results at:https://github.com/lilicoding/ApkCombiner
ApkCombiner: Combining Multiple Android Apps 3
that state-of-the-art intra-app analyzers can efficiently leverage our approachto indirectly perform inter-app analyses.
2 Background and Motivation
In this section we first briefly introduce different concepts that are specific toAndroid (cf. Section 2.1). Then, we motivate our work by highlighting the limita-tions of state-of-the-art static analysis approaches targeting the Android system(cf. Section 2.2). Finally, we discuss in Section 2.3 an IAC vulnerability througha running example.
2.1 Android IAC Overview
In Android, the inter-component communication (ICC) mechanism allows twocomponents to exchange data and invoke each other. The Android inter-appcommunication (IAC) mechanism works in the same way and exploits the ICCmechanism to make components from different apps interact. An ICC is typicallytriggered by one of several specific Android methods which are related to thedifferent components in presence (i.e., either an Activity, Service, Content
Provider, Broadcast Receiver). Those methods5 take as parameter a specialkind of object, called Intent, which specifies the target component(s), eitherexplicitly, by setting the name of the target component’s class, or implicitly, bysetting the action to perform, the category and the input data. Obviously, sinceit is hard for developers to predict which other apps will be available at the sametime, IAC invocations are almost always performed through implicit Intents. Inorder to receive implicit Intents, target components in separate apps need todeclare their capabilities, through an Intent Filter, in the app manifest file sothat the Android system may match them when requested by a given app.
2.2 Static Analysis for Android Apps
Static program analysis has been widely used to address security issues, e.g.,related to data integrity and confidentiality of information flow [7], as well asfor anomaly detection [11,19]. More recently, static analysis techniques have alsobeen applied for dissecting Android applications [9,12,14]. However, we note thatcurrent approaches still present a number of limitations when they are targetedto code from the Android system.
In the most common case, a static analysis of Android is reduced to anintra-app analysis, where the bytecode of an app is extracted, and parsed toproduce a control-flow graph (CFG) to further perform specific analysis. Forexample, FlowDroid [2], a recent state-of-the-art Android analysis approach,builds CFG for static taint analysis. When the analysis must take into accountthe interaction between two or more apps, it is refered to as an inter-app analysisand may operate in three different ways as illustrated in Fig. 1.
5 Except Content Provider related methods.
4 Li Li et al.
m1
m2
m1 m2
m3 m4
m3
m4
m1 m4
m1
m2
m3
m4
m1 m4
(1)
(f1)
scenario (B1): combine the
resulting flows
(f2)
app 1
app 2
scenario (B2): combine the
resulting CFGs
scenario (C): combine the
apps
analysing the apps
separately
CFG 1
CFG 2
m1
m2
CFG 1
m3
m4 CFG 2
combine the apps first
Fig. 1: Different approaches for Enabling Inter-App analysis of Android apps.
At a high livel, there are two options for enabling inter-app analysis: (1)perform intra-app analysis of each app independently from the others and relyon these analysis results to infer inter-app analysis output; or (2) combine theapps first before performing the analysis.
In scenario (B1), the results of the intra-app analyses (i.e., flows f1 and f2)are combined to yield a potential flow between the apps. However, because thecombination is performed after the analysis, no context data (e.g., variable valuessuch as data handled by the Intents) is available, and thus the scenario requiresto approximate the flows between the apps (e.g., here line (1)). This scenariomay thus lead to a significant number of false positives.
Scenario (B2) is an improved version of (B1) where it is no longer the resultsthat are combined but the CFGs instead. This scenario thus supports a context-aware inter-app analysis by operating on a combined CFG and on a data depen-dence graph (DDG) between the apps. Nevertheless, such an approach cannotbe generalized to any instances of CFG. In practice for example, the workloadfor combining CFGs generated by Soot [15] can not even be applied in the caseof CFGs generated by Wala6. Thus, specific development effort must be put intoeach and every static intra-app analyzer to support inter-app analysis.
Scenario (C) considers the caveats of all previous approaches by further im-proving scenario (B2) to yield a general approach for enabling context-awareinter-app analysis of Android apps. Thus, instead of combining separate CFGsfrom different apps as in scenario (B2), the approach would consist in combiningthe complete apps at the bytecode level. The generated single app package is thusimmediately ready for analysis with static intra-app analysis tools. The analysisresults will then contain information that could only be obtained through inter-app analysis. This paper presents the design and implementation of a tool for
6 http://wala.sourceforge.net/wiki/index.php
ApkCombiner: Combining Multiple Android Apps 5
supporting such an approach where no modification of current state-of-the-arttools will be required to perform inter-app analyses.
Table 1 summarizes the fact that most state-of-the-art static analysis ap-proaches for Android only deal with intra-app analysis. DidFail [13], the onlyapproach that considers inter-app analysis, falls under scenario (B1) describedabove. Yet, as reminded by the classification in Table 2, this scenario leads to acontext-unaware analysis, and thus to many false positives in the results.
Table 1: State-of-the-art approaches
Intra-App(Inter-Comp) Inter-App
IccTA [16] DidFail [13]AmanDroid [20]
ScanDroid [10]SEFA [21]
CoChecker [5]
Table 2: Classification of scenarios for staticinter-app analysis approaches. (B1), (B2)and (C) refer to the scenarios illustrated inFig. 1.
Non-General General
Context-Unaware (B1)
Context-Aware (B2) (C)
2.3 A Running Example
Fig. 2 presents a running example that shows an IAC vulnerability. The ex-ample is extracted from a test case of DroidBench7 refered among its list asInterAppCommunication sendBroadcast1. The example consists of two Androidapplications, refered to as sendBroadcast1 source and sendBroadcast1 sink.
11: class InFlowActivity extends Activity 12: {13: protected void onCreate(Bundle b) {14: Intent i = getIntent();15: String imei = i.getStringExtra("DroidBench");16: Log.i("DroidBench", imei);17: }}
1: class OutFlowActivity extends Activity{2: protected void onCreate(Bundle b) {3: //tm = default TelephonyManager; 4: String imei = tm.getDeviceId();5: Intent i = new Intent();6: i.setAction("lu.uni.serval.iac_sendbroadcast1.ACTION");7: i.putExtra("DroidBench", imei);8: sendBroadcast(i); }}
21: <activity android:label="@string/app_name" android:name="lu.uni.serval.iac_sendbroadcast1_sink.InFlowReceiver">22: <intent-filter>23: <action android:name="lu.uni.serval.iac_sendbroadcast1.ACTION" />24: <category android:name="android.intent.category.DEFAULT" />25: </intent-filter>26: </activity>
App1: sendbroadcast1_source App2: sendbroadcast1_sink
App2: AndroidManifest
Fig. 2: A running example that shows an inter-app vulnerability.
App sendBroadcast1 source contains a simple Activity component, namedOutFlowActivity, which first obtains the device ID (line 4) and then storesit into an Intent (line 7) which is then forwarded to other components (poten-tially in other applications since the Intent is implicit (line 6)). App sendBroad-cast1 sink contains a component called InFlowActivity, which first extractsdata from the received Intent and then logs it into disk.
7 DroidBench is a set of hand-crafted Android apps used as a ground truth datasetto evaluate how well static and dynamic security tools find data leaks. https://
github.com/secure-software-engineering/DroidBench
6 Li Li et al.
In this example, we consider device ID, which is protected by a permissioncheck of the Android system, to be sensitive data. We also consider the log()method to be dangerous behavior since it writes data into disk, therefore leavingit accessible to any applications, including anyone which does not have permis-sion to access the device ID through the Android OS. Thanks to the declarationsin the Manifest file in the package of sendBroadcast1 sink, OutFlowActivityis able to communicate with InFlowActivity using the sendBroadcast() ICCmethod. Thus, through the interaction between these two apps, a sensitive datacan be leaked.
Unfortunately, the current state-of-the-art static analysis tools, includingFlowDroid and IccTA, cannot tackle the kind of IAC problem described above.Since these tools have already proven to be efficient in statically identifying bugsand leaks across components inside a single app, we aim at enabling them todo the same across applications. We further put a constrain on remaining nonintrusive, i.e., to avoid applying any modification on them, so as to avoid intro-ducing limitations or new bugs in these tools. We thus propose ApkCombiner,which, by combining multiple apps into one, reduces the IAC problem to an ICCproblem that state-of-the-art tools can solve in an intra-app analysis.
3 ApkCombiner
We now discuss the design and implementation of ApkCombiner. First we presentan overview of the approach in Section 3.1 before providing details on how weaddress the case of conflicting code, typically same-name classes, when combiningapps (cf. Section 3.2). Although, for the sake of simplicity, we describe the caseof merging two apps, the approach, and the prototype tool, can perform onmerging any number of apps.
3.1 Overview
The main objective of our work is to enable Android-targeted state-of-the-artstatic analysis tools, which have proven to be effective in intra-app analyses, toperform as well in inter-app analyses. ApkCombiner takes a set of Android appsas input and yields a new Android app in output. The newly generated appcontains all the features of the input apps except for their IAC features: there isno more IAC but only ICC in the new generated app.
The different steps of how ApkCombiner works are shown in Fig. 3. Each appis first disassembled into smali files and a Manifest file using a tool for reverseengineering Android apk files, namely android-apktool 8. Second, all files fromthe apps are checked together for conflicts and integrated (with conflicts solved)into a directory. The Manifest files, one from each app, are merged into a singleManifest file. Finally, ApkCombiner assembles the smali files and the Manifestfile along with all other resources, such as image files, into a single apk. Although
8 https://code.google.com/p/android-apktool/
ApkCombiner: Combining Multiple Android Apps 7
potential conflicts on such extra-resources may be met, ApkCombiner does nottake them into account since the objective is not to produce a runnable apk, butan apk that can be analyzed statically.
App 1 Smali Files + Manifest1
Conflicts Solving
Smali Files
MergedManifestApp 2 Smali Files + Manifest2
NewApp
Fig. 3: Working steps of ApkCombiner
3.2 Resolution of Conflicts
Our prototype of ApkCombiner is focused on solving conflicts that may arisein the merging of code from two different apps. Such conflicts occur whentwo classes have the same name (up to the package level, i.e., the absolutelyfull qualified name). Thus, given class c1 in app a1 and class c2 in app a2, ifname(c1) = name(c2), we consider that there is a conflict between a1 and a2.
Fig. 4 illustrates the process of conflict checks we use. ApkCombiner considersthat there is no conflict when two classes are named differently. If the name oftwo classes are the same, ApkCombiner distinguishes two cases according to thecontent of the classes. In a first type of conflict, the classes share the same nameand their content is also the same (after verification of their footprint with thecryptographic hash), In this case, one copy of the class files is simply dropped.In the second type of conflict, i.e., when the content of the conflicting files aredifferent, a thorough refactoring is necessary. This type of conflict occurs when,for example, two classes are actually from two different versions of the samelibrary used in the two apps.
name(cls1) == name(cls2) hash(cls1) == hash(cls2)T TClass
cls1 and cls2
No conflict
The second type of conflict (C2)
The first type of conflict (C1)
F F
Fig. 4: The conflict checking process of ApkCombiner. Class cls1 and cls2 are fromdifferent apps.
Algorithm 1 details the described strategy for solving conflicts during mergingas implemented by the procedure CheckAndSolveConflicts(). Given two sets(set1 and set2) of class files corresponding to the code of two apps (a1 and a2),the algorithm must identify and manage all conflicts.
First, two maps, referred to as confliSameMap and confliDiffMap arecreated to keep track of the classes that belong to the two types of conflict(lines 2-3). After identifying the kind of conflict that exists for each pair of classesacross the two sets, the algorithm can attempt to solve the eventual conflicts.This resolution is performed in a two-step process. In step 1 (lines 17-22), thealgorithm addresses the cases of type 1 conflicts. In step 2, type 2 conflicts aresolved by refactoring the code.
Refactoring the code to solve conflicts is not as straightforward as renamingthe conflicting classes. Indeed, there is a lot of dependencies to consider within
8 Li Li et al.
Algorithm 1 Checking and solving conflicts
1: procedure CheckAndSolveConflicts(set1, set2)2: confliSameMap← new Map()3: confliDiffMap← new Map()4: for all cls1 ∈ set1 do5: if set2.contain(cls1) then6: cls2← set2.get(cls1)7: if hash(class(cls1)) == hash(class(cls2)) then8: confliSameMap.put(cls1, cls2)9: else
10: confliDiffMap.put(cls1, cls2)11: end if12: end if13: end for14: if empty(confliSameMap, confliDiffMap) then15: return16: end if17: for all cls1, cls2 ∈ confliSameMap do18: remove class(cls2)19: if isComponent(cls2) then20: remove cls2 from Manifest221: end if22: end for23: for all cls1, cls2 ∈ confliDiffMap do24: rename cls225: solvingDependence(cls2, set2)26: if isComponent(cls2) then27: rename cls2 in Manifest228: end if29: end for30: end procedure
the code of other classes. Procedure solvingDependence(), in line 25, is usedto handle these dependencies, where we take into account three types of de-pendencies: 1) for a given class c we need to rename, another class ci may useit as one of its attribute, 2) method mi of class ci may hold a parameter of cand 3) statement si of method mi may use c as a variable. For the third typeof dependency, we deal with statements that instantiate the variable as well asaccess the variable’s attributes and methods because only such statements holdinformation related to class c.
To combine multiple Android apps to one, we need not only to integratethe different apps’ bytecode, but also to merge their Manifest files. In particularthe merge of Manifest files must take into account the fact that some classeswhere dropped while others were renamed. If those classes represent Androidcomponents, and not helper code, these changes should be reflected in the finalManifest of the new app (line 20 and 27).
ApkCombiner: Combining Multiple Android Apps 9
4 Evaluation
To assess the efficiency of our approach, we must evaluate the run time perfor-mance of ApkCombiner to ensure that this does not hinder its practical usability(cf. Section 4.1). Then, using a dataset with real-world apps, we check whetherour approach is, in the end, capable of enabling state-of-the-art intra-app ana-lyzers to support inter-app analysis (cf. Section 4.2).
Hypotheses. To run our experiments, we start with the assumption thatthe inter-app analysis may reveal significant security issues when a maliciousapplication can exploit a leak in another, or when two apps can collude to leakdata. To that end, we select a dataset containing both benign and maliciousapps, and assume that, by pairs, they may cohabit in the same device.
Experimental Setup. We select two app sets G and M for our evaluation,where G is a set of apps randomly selected from Google Play store and Mis a set of malicious apps. These malicious apps were recognized as such afteranalysis by VirusTotal antivirus products: we consider that an app is “really”malicious when at least 20 different antivirus flag it as such. Both G and Mconsist each of 3,000 Android apps. Then, for each app gi randomly selectedfrom G, we associate an app mi, also randomly selected from M . This randomcombination only considers the possibility that two apps in one device may beindependently installed by a user on his device. This kind of association provides3000 opportunities of merging to ApkCombiner.
Our prototype tool succeeded in combining 2, 648 (88.3%) pairs of apps.Most failures were actually due to the limitations of android-apktool9. A fewfailures must however be attributed to the current implementation strategy ofthe refactoring process in ApkCombiner. These failures however are currentlyunder investigation to improve the tool.
During the process of successful combinations, ApkCombiner solved 1,789 firsttype conflicts in 322 (12.2%) cases of combining pairs of apps. ApkCombiner alsoaddressed 3,557 second type conflicts in 493 (18.6%) combination cases.
4.1 Time performance
The evaluation of time performance investigates the scalability of our approach.Indeed, a user may have on its device dozens apps that cohabit together. Thus,the inter-app analysis may require a fast combination of all those apps. Fig. 5plots the running times10 of ApkCombiner for each combined app. The runningtime is plotted against the sum size of each pair of apps (we use the bytecodesize, as resource files that are not considered in the merging may introduce abias).
9 android-apktool often throws brut.common.BrutException for some combinations(e.g., could not exec command or Too many open files).
10 Note that in this paper we consider the wall clock time (from start to finish of theexecution). That means not only the actual CPU time but also the waiting time(e.g., waiting for I/O) are taken into account.
10 Li Li et al.
●
●●
●
●
●
●●
●
●●
●●
●
●
●
●
●
●● ●●
●●
●
● ● ●●●
●
●●
●
●
●
●●
●●
●
●
●●
● ●●
●
●
●●●● ●
●
●●
● ●●
●
●● ● ●
●●
● ●●●●
● ● ●●
● ●
●
●●
●●
●●
●
●●●
●
●
● ●●
●●●●
●
●
●
●●
●
●
●●
●
●
●●
●
●
●
●
●●
●●
●
● ●
●●●● ●
●●●
●
●● ●●
●●
●
●
● ●●
●
●
●
●
●● ●
● ●
●●
● ●●●
●
● ●●
●●
●● ●●
●
●
●
●
●● ●
●
●●
●●●
●●
●
●●
● ●●
●●
●●
●
●●●
●●
●
●
●
●
●
●
●
●●
●
●
●●
●
●
●●
● ●
●
●●
● ●
●
●●
●
●●●
●
●●
●
●
●
●
●
●●
●
●●●
●
●
●
●●●●
●●
●●●
●
●●
●
● ●
●
●
●
●
●
●●●
● ●● ●
●
●●●
●
●●●
●
●
●
●
●
● ●●● ●
●●
●●
●●● ●● ●●
●
● ●●
●
●
●
● ●
●●●
●
●●
●
●● ●●
●
● ●
●
●●●
●●●● ●
●
●
●
●
●
●
●●
●
● ●●●
●● ●
●
●●●
●●
●
●
●
●
●
● ●●
●
●
●●
●●●●●●
●
●●
●
●●
●
●
●●
●●
●
●●●
●●
●●
●●●●
● ● ●●
●●
●● ●
●●
●● ●
●●● ●
●●
●●
●
●
●●
●●
●
●●●
●●●●
●
● ●●
●
●●
●
●●● ●
●
●
● ●●
●● ●
●●●
●●
● ●●
●
●
●
●
●
●
● ●
●
●●
●●
●
●● ●
●●
●
● ●
● ●●●
● ● ●●●
●●
● ● ●
●
●
●
●
●
●●
●●
●
●
●●
●●
●
●
●●●
●● ●●
●
● ● ●●
●
●
●
●
●
●●●
●
●
●
●
●
●
●●
●
●
●
●●
●● ● ●
●
●●
● ●●
●●
●●
●
●
●
●
●
●● ●●
●●
●● ●
●
●
●●
●
●
●●
●●●
●●
●●
●●
●●●
●
●● ●
●
●
●
●
●●
● ●●●
●
●
●●
●
● ●
●
●● ●
● ● ●
●
●
●●
●●
● ●
●●
●●
● ●
●
●
●
●
●●
●
●●
●●●●
● ●●
●
●
●●
● ●
● ●●
●
● ●●
● ●●
●●●
●
●
● ● ●●●
●
●
●●
●●
●
●
●
●
●●● ●●●
●
●●●
●
●
●
●
●
●
●●
●●
●●
● ●●●
●● ●
●●
●●
●●
●
●●
●●●
●●
●
●●
●●
●●
●●
●●
●
●
●● ● ●●●●
●
●
●
●●●
● ●
●●
●
●● ●●
●
●
●
● ●
●
●●● ●●●●
● ●●
●●
●
●●
●●
●
● ●
●●●
●
●
●
●●
●
●● ●● ●
●●●
●●
●
●
●● ●
●● ●
●●
●●
● ●
●
●
●
●
●●●●●
●● ●
●
●●
●
●●
●
●
●●●
●
●●
●●
●
●
●●
● ●●
●
●
● ●
●
●●
● ●●●●●
●●
●
●●
●●●
●●
●
●
●
●●
●● ●●●
●
●●
●●
●
●
● ●● ●●
●●● ●●
●
●●●● ●●
●
●●●●
●
●●
●
●●
●
●
●●●●
●●
●●
●
●●
●●
●● ●
●●
●
● ●●
●
●●●
●
●
●
● ●●●
● ●
●
●●
●
●●
●
● ●●
●●
●
●●
●
●● ●
●
●
●
●
●
● ●
●
●● ●
●
●
●
●●●
●●
● ●● ●●
●
●
●
● ●
●
●
●
●●●
●
●
●●
● ●
●●●
●●●
● ●●
●
●
●
●
●
●● ●●
●
●● ●
●●
●●
●●●
●●● ●
●●
●●
●●
●●
● ●
●
●
●●
●●
●●●
●
●●
●
●●●
●●●●● ●
● ●●
●●
●
●●
●● ●
●●
●●
●
●
●●
●
●●●
● ●●
●●
●
●
●
●
●
●●
●●●
●
●
●●●●
●
●
●
●
●●
●●
●●●
●
●
●●
●
●●
●
●●
●
●●
●
●●
●●
●● ●
●
●
●●●
●
●●●
●
●
●●
● ●
●●● ●
●
●
●●
●●
●●
●
●
●
●
●
●●
●
●●● ●● ●●●●
●●
●
●
●●●
●●
● ●●●●
●●●
●●●
●
●
●●
●●
● ●● ●●● ●
●●
●●●●
●
●
●
●
● ●
●
●
●●
●
●
●
●●
●●
●
●
●
●●● ●
●
●
●
●
●●●●
●●
●
●
●●
●
● ●●
●
●
●
●
●
●
●
●
●
●
●
●
● ●●
●●●
●●●
●●●
●
●●●●
●
●
●
●
●
●
●
●●●
●
●● ●●
●
●●
●
●●
●
●
●
●● ●●
●●● ●
●●
●
●● ●●
●
●
●
●● ●
●●
●
●
●
●●
●
●
●
●●
●●
●
●●●●
●
● ●●●●
●
●●
● ●
●
●●
●
●●
●
●
●●●
●●
●
●
●
●● ●●
●●●●●
●●
●●●●●
●
● ●●●
●
●
●●
●
●● ●● ● ●●
●
● ●
● ●
●
●
●
●
●
●
●
●
●●
●
●
●●●
●
●
●●●●
●
●
●●●
●
●
●
●
●
●
●●
●
●
● ●●● ●●
●
●●
● ●●● ●
●●
●
●
●●● ●
●
●●
●
●
●
●●●
●●●
●●
●●●
●
●
●
●
● ●●● ●●
●
●
●
●● ●
● ●●●●
●
●●
●●
●
●
●
●
●
●
●
● ●
●
●
●●●●
●
●●
●
●
●●
●●
●●
●
●
●●●
●
●● ●●●
● ●●
●
●● ●
● ●●
● ●●● ●●●● ●
●
●
●● ●●
●●
● ●●● ●●
●●●●●●
● ●●
●●
●●●
●
●
●● ●● ●
●
●
●
●
●●●● ●●
●
●
●●● ●● ●
●
●
●●
●
●●●●
● ●● ●
● ●●
●●●
●
●●
● ●●
●
●
●
●●
●● ●
●
●
●
●
● ●●●
● ●
●
●
●●
●
●
●
●
●
● ●●
● ●●●
●
●
●●●●●
●●●
●
●●
● ●
●
●
●
●
●
● ●●● ●●●
● ● ●●●
●● ●● ●
●●
●●
●
●●
●●●
● ●
●
● ●●●
●●
●
●
●
● ●●
●
●●
●● ●
●
●
●
●●
● ●
●●
●● ●●●●
●
●
●●
●●●
●
●
● ●●●●●● ●
●
●
●
●
● ●
●
●●●●
●
●
●●● ●
●
●
●
●● ●●● ●
●
●●
●
●
●● ●●●●
●●
●
●●
●
●
●
●●
●●● ● ●●
●●●
●
●
●
●
●
●
●●
●
●
●
● ●
●
●●
●
●
●
●
●
●
●
●●
●
●
●
●● ●
● ●
●
● ●
●
●
●
●●●
●
●
●
●
●●
●
●
●
●●●●
●●● ●
●●●●
●●●
●● ●●
●●
● ●●
●
●● ●●●
●●
●
●● ●●
● ●●●● ●
●
●
●
●
●●
●●●
●
●●
●●
●
●●
●●
●
● ●
●●●
●●
●
●●
●
●●
●●
● ●
●●
●
● ●● ●●
●
●
●
●
●
●●
●
●●
●
●
●●
●
●● ● ●
●
●
●
●●
●●●
●●●●
●
● ●●
●
●●
●●● ●●
●
●●
●
●●
●●
●
●
● ●●
●●
●● ●●●●●
●●
●●●●
● ●● ●
●
●●
●
●●
●●●
●
●
●
●●
●●●●
●
●● ●●●●
●
●
●
● ●
●
●●
●
●●
●●
●●●
●
●
●
0 200 400 600 800 1000 1200
020
040
060
080
010
00
The bytecode size (KB)
The
run
ning
tim
e (s
)
y= 18.019 + 0.246 x
(a) C1 ∪ C2 ∪ C1 ∪ C2
●●●
●●
●●
●●
●
●
●●
●● ●●
●●● ● ●●●
●●
●
●●
●●
●
●● ●●
●
●
●●●● ●
●
●●
●●
●● ● ●
●
● ●●●●
● ● ●●
● ●
●
●●
●●
●●●
●●●● ●
●
●●●● ●●
●●
●
●●
●●●
●
●●
●
●●
● ●
●●●● ●
●●●
●
●● ●●●
● ●● ●
●
●● ●
●
●●
● ●●●● ●
●
●●
●● ●
●
●
●
●
●● ●
●
●●
●●●
●●
●
●●
● ●●
●●
●●●●
●●
●
●
●
●
●
●
●
●●●
● ●●
●● ●
●●
●●●
●
●●
●● ●●
●●●
●●●●●
●●
●●●
●
●●● ●●●●
●● ●
●●●
●
●●●●
●
● ●●● ●
●●
●
●●● ●● ●●● ●
●
●
● ●
●●●
●
●●
●
●● ●●
●
● ●●●● ● ●●
● ●●● ●
●●
●● ●
●●●
●●
●
●
●
●
● ●●
●●
●
●●●●●● ●●
●
●●
●
●
●●
●●
●
●●
●●
●●
●●●●
● ● ●●
●
● ●
●●
●● ●
●●● ●
●●
●●
●
●
●
●●
●
●●●
●●●●
●
● ●●
●●●
●● ●
●
● ●●
●● ●
●●
●
●●●
●
●●
●
●
●●
●● ●● ●
●●
●
●●●
● ● ●●●
●
● ● ●
●
●
●●
●
●
●
●●
●●
●●
●● ●●
●
● ● ●●
●
●
●
●●●●
●● ●
●●
●●
●●
● ● ●●
●● ●● ●
●
●
●
●
●
●● ●●●
●● ●●
●●
●
●●
●●●
●●
●●
●●●
●
●● ●
●
●
●
●●
● ●●
●
●
●●● ●
●● ●
● ● ●
●
●
●●
●●
●
●
●● ●
●
●●●
●●
●●●
● ●●
●
●
●●
● ●● ●●
●
●●●
●
●
● ● ●●●
●●●●
●
●
●
●
●
●●● ●●●●●
●●
●
●
●
●
●●●
●
● ●●●
● ●
●
●●
●●
●●●
●
●
●●
●
●●
●●
●● ●
●
● ●●●●●
●
●●●
● ●
●●●● ●●
●
●
●
●
●●● ●●●●
●●
●● ●●●
● ●
●●●
●
● ●●
●
●● ●● ●
●●●
●●
●
●● ●
●● ●
● ●
●●
●
●●●●
●● ●
●
● ●●●
●●
●●●
●●
● ●●
●
● ●●● ●●
●●●●
●
●●●
●
●●
●●● ●●
●
●●
●● ●
●●
●●● ●● ●●●
●● ●●●● ●
●●● ●●●●●
●●
●●
●●
● ●
●●● ●
● ●●●
●
● ●●●
● ●●●●●● ●
●
●●
●● ●● ●●
●
● ●●● ●●
●●
● ●● ●● ●● ●
●
●●●●●●
●●●
●●●
● ●●
●●
●
●● ●●
●
●● ●●
●●●
●●● ●
●●
●●
●●
●●
●
●
●●
●● ●●●●
●●●●● ●
● ●●
●●
●●
●● ●
●●
●●
●
●●
●●●
● ●●
●●
●
●
●
●●●
●
●
●
●●●●
●
●
●
●
●●
●●
●●●
●●
●●
●
●●●●●
●●
●
● ●
●●●●●
●●
●●
●
●●● ●
●●
●●
●●
●●
●
●●
●●
●
●●● ●● ●●●●
●●
●●●
●●
● ●●●●
●●●
●●●
●
●
●●●
●● ●●● ●
●●
●●●●
●
●● ●
●
●●●●●● ●●
● ●●●● ●
●●
● ●●
●●●●●
●
● ●●●●
●
●●●●
●
●●●●
●●
●●
●●●● ●●●●
●
●●
● ●● ●●
●●● ●
●●●
● ●●
●
●● ●
●●
●
●
●
●●
●●
●●● ●●
●●● ●●●●
●
●●
●
●●●●
●
●
●●●
●●●●● ●
●●●●●
●●
●●
●●●● ● ●●
●
●
●● ●● ●
● ● ●●●
● ●
●●
● ●●
●●●
●●
●
●●●
●●●●●●
●
●
●
● ●●● ●●
●●
● ●●●
●●
●● ●●
●
●●●
●●●
●●
●●● ●
● ●●● ●●
●
●●
●● ●●●
●●
●●
●●
●
● ●
●
● ●●●●●
●
●
●●
●●
●
●●●● ●● ●●●
● ●●
●● ●
● ●●
● ●●● ●●●● ●
●● ●●
● ●●● ●●
●●●●●●
● ●● ●●●
●●
● ●● ●●
●●●● ●●
●
●
●●● ● ●
●
●
●●●
●●●
● ●● ●
● ●●
●●
●
●● ●●
●●
●●● ●
●
●
●
● ●●
● ●●
●
●
●
● ● ●●
● ●●●
●
●
●●●●●
●●●
●
●●
● ●
●
●
●
● ●●● ●●●
● ● ●●●
●● ●● ●
●
●● ●●
●●●
● ●
●
● ●●●
●●●● ●● ●
●●
● ●●
●
●●
● ●
●●
● ●●●●
●
●●
●●●
●● ●●●
●●● ●●
●
●
● ●●●●●
●
●●● ● ●
●
●● ●●● ●
●
●●
●● ●●●●
●●
●●
●●
●●
●●● ●●●
●●
●●
●
●
●
●●
●● ●
●
●
●
●
●
● ●● ●●
● ●● ●● ●
●
● ●●
●●
●●● ●●●●
●●● ●
●●●●
●●● ●●
●
● ●●
●
●● ●●● ●
● ●●
● ●●●● ●●
●●
●●●
●
●●
●●
●
●●
●●● ●
●●●
●● ●●
●●
● ●
●●
●
● ●● ●●
●● ●
●●●●●●
●
●● ● ●
●●
●●
●●●●●
●
●
● ●● ●●
●●● ●●
●●
●
●●● ●
●●
●●● ●●●●
●
●●
●●●●
● ●●●●
●
●●
●●●
●
●●
●●●●
●
●● ●●●●
●
●
●
●
●
●●
●●
●●
●●●●
0 200 400 600 800 1000 1200
020
040
060
080
010
00
The bytecode size (KB)
The
run
ning
tim
e (s
)
y= 22.566 + 0.157 x
(b) C1 ∪ C2
●●
●
●
●
●
●
● ●●
●●●
●●
●●
●●
●●
●●
●
●
●●
●
●
●●
●●
●
●●
●
●●
●
●
●●
●●
●
●
●
● ●
●
● ●
● ●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●●●
●●●●
●
●
●●
●
●●
●
●●
●
●
●
●●
●●
●●
●
●
●
●●
●
●●●
●
●
●●
●
●
●
● ●
●● ●
●
●●
●
● ●
●
●
●
●
●
● ●
●
●●
●
●
●●
●
●●
●
●
● ●●●
●●
●
●●
●
●
●●●
●
●●●
●
●●
●
●
●
●
●
●
●
●
●
●●
●
● ●●
●
●
●
●●
●●
●
●
●●
0 200 400 600 800 1000 1200
020
040
060
080
010
00
The bytecode size (KB)
The
run
ning
tim
e (s
)
y= 82.931 + 0.206 x
(c) C1 ∪ C2
●
●
●●
●
●
●
●●●
●
●
●
●
●
●
●
●●●
●● ●●
●
● ●● ●
●
●
●●
●● ●●●
●●
●●●
● ●●●
● ●●
●
●●
200 400 600 800 1000
020
040
060
080
010
00
The bytecode size (KB)
The
run
ning
tim
e (s
)y= 29.832 + 0.12 x
(d) C1
●
●●
●●
●
●● ● ● ●
●●
●
●
● ● ●
●●
●
●
●
●●
●
●●●
●●
●
●●
● ●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●●●
●
●
●
●
●●
●●
●
●●●
●
●
●●
●
●
●
●
●●
●
●
● ●
●
●●
●
●
●
●
● ●
●●
●
●
●
●
● ●
● ●
●
●●
●
●●
● ●
●●
●
●●
●●
●
●
● ●●●
●● ●
●
●
●
●
●●
●
●●
● ●
●
●●
●●
●
●
●
●●
●
●●●
●
●
●
●
●●●
● ●● ●
● ● ●
● ●
●
●
●●
●
●●
●
●
●●
●
●●
● ●●
●
●●
●
●● ●
0 200 400 600 800 1000
020
040
060
080
010
00
The bytecode size (KB)
The
run
ning
tim
e (s
)
y= 71.649 + 0.29 x
(e) C2
Fig. 5: Time performance against the byte code size. C1 represent the set of combina-tions where first type conflicts were solved, while C2 represents the set of combinationswith second type conflicts.
Let C1 and C2 represent the successful combinations where conflicts of, re-spectively, first type and second type were solved. Consequently, C1∪C2∪C1 ∪ C2
represents all the successful combinations.Fig. 5a plots the time performance for all combinations. The linear regression
between the plots shows that there is a correlation between the execution timeand the bytecode size. Comparing with Fig. 5b, we note that the slope of theregression is lower when we do not consider combinations that lead to conflicts.The limited difference in slope values (0.246 against 0.157) indicates that theconflict solving module is not a runtime bottleneck.
The differences between Fig. 5c, Fig. 5d and Fig. 5e further confirm howthe resolution of second type conflicts requires more execution time than theresolution of first type conflicts.
4.2 Inter-app analysis
We consider IccTA [16], a state-of-the-art Android intra-app analysis tool, whichoriginally aims at detecting inter-component privacy leaks inside a single Androidapp. We select IccTA to validate our approach by investigating the effectivenessof ApkCombiner in supporting existing tools for performing inter-app analyses.
With ApkCombiner we build app packages by combining pairs of apps. Wethen feed IccTA with these newly generated apps and assess its analysis results.We evaluate the use of IccTA in combination with ApkCombiner in two steps.
ApkCombiner: Combining Multiple Android Apps 11
In the first step, we evaluate the impact of ApkCombiner on DroidBench, whichincludes three test cases related to inter-app communication leaks. We found thatIccTA is able to report inter-app privacy leaks for the analyzed apps by analyzingthe combined package provided by ApkCombiner. To the best of our knowledge,DidFail is currently the only tool which claims to be able to perform static inter-app analysis for privacy leaks. We therefore compare DidFail with our approachassociated to an existing state-of-the-art tool for intra-app analysis. The resultsin Table 3 based the DroidBench benchmark show that IccTA, while it cannothandle inter-app analysis alone, outperforms DidFail when it is supported byApkCombiner. The reason why DidFail fails on two test cases is that at themoment DidFail only focuses on Activity-based privacy leaks.
Table 3: Comparison between IccTA, DidFail and ApkCombiner+IccTA.
Test Case (from DroidBench) IccTA DidFail ApkCombiner+IccTA
InterAppCommunication startactivity1 7 3 3
InterAppCommunication startservice1 7 7 3
InterAppCommunication sendbroadcast1 7 7 3
In the second step, we evaluate ApkCombiner on 3,000 real Android apps.We first build an IAC graph through the results of our extended Epicc [16, 18],where an app stands for a node and an inter-app communication is modeled asan edge. For each of such edges, we launched ApkCombiner on the associatedpair of apps and then used IccTA on the generated app.
We were thus able to discover an IAC leak between app Ibadah Evaluation11
and app ClipStore12. In the Ibadah Evaluation apk code, the source method find-ViewById is called in component com.bi.mutabaah.id.activity.Statistic,where the data of a TextView is obtained. Then this data is stored into an Intentalong with two extras, a subject named android.intent.extra.SUBJECT andthe text referred to as android.intent.extra.TEXT. Subsequently, the trigger-ing method startActivity is used to transfer the Intent data to the ClipStrore appwhich extracts the data from the Intent with the same extra names and writesall the data into a file named clip.txt. Note that we consider saving sensitivedata into disk as a leak.
5 Discussion
Scalability. As introduced in Section 4.1, ApkCombiner scales linearly withthe bytecode size. Unfortunately, in practice, when increasing the bytecode size(e.g., increasing the number of apps to combine), the processing time and mem-ory requirement of Android analysis tools (e.g., IccTA or FlowDroid) also growsignificantly. Thus such approaches may not be scalable when running on top ofApkCombiner. To limit the impact of this scalability issue, a possible approach isto limit the number of Android apps to combine. This is a reasonable limitation,as the number of apps obstructs the work of attackers as well. For example, given
11 https://worldapks.com/ibadah-evaluation/, com.bi.mutabaah.id in our dataset.12 https://worldapks.com/clipstore/, jp.benishouga.clipstore in our dataset.
12 Li Li et al.
a1
t = 2
t = 3
Fig. 6: An example of an IAC graph and a trade-off threshold t.
an effective attack, the more number of apps involved, the more complexity ofbuilding such attack introduced and the less probability of a user installing allof the involved apps. Our solution is to build an IAC graph to represent thedependencies among apps, the idea being that if there is no link (edge) betweentwo apps (nodes) there is no need to combine them. Based on the IAC graph, weintroduce a threshold t to denote the maximum number of apps ApkCombiner
may combine together. The trade-off limitation length t enables existing intra-app analyzers to remain scalable when used with ApkCombiner.
Let us take Fig. 6 as an example, which shows an IAC graph and the conceptof threshold t. For app a1, if we set t = 2, then we only need to run ApkCombiner
6 times (the small circle) and most importantly we only need to combine 2 (or t)apps each time. Notice that with the built IAC graph, new apps can be added tothe graph in an iterative and incremental manner. When new apps are involved,we only need to add them to the existing IAC graph. We do not need to run thepreviously computed apps again when adding the new apps. In short, by buildingan IAC graph and setting up a threshold t, the original set of Android apps issplit into multiple small sets that both ApkCombiner and the state-of-the-artintra-app analysis tools can analyze.
Limitations. At the moment, we do not offer a guarantee that the newlygenerated app can be executed. Except from the bytecode and Manifest, wesimply combine all the other resources such as native code, layout files withoutchecking whether they are conflicted or not. This may result in errors for analysistools that rely on such resources.
6 Related Work
To the best of our knowledge, in the Android community, our approach is the firstwork that attempts to complement existing state-of-the-art intra-app analysistools to indirectly support inter-app analyses. Our approach is also the firstproposal that supports context-aware inter-app analysis. However, researches ondetecting IAC vulnerabilities are not new.
Privilege escalation attack, an IAC vulnerability, has been studied by a largebody of works [3, 6, 8]. Davi et al. [6] show that a genuine app can be exploitedat runtime and a malicious app can escalate granted permissions. Prominentexamples of privilege escalation attacks are confused deputy and collusion at-tacks [3]. Confused deputy attack is about the possibility for malicious app toexploit another privileged (but confused) app’s vulnerable interface. Collusion
ApkCombiner: Combining Multiple Android Apps 13
attack concerns the collusion of apps that combine their permissions to be ableto perform actions beyond their individual privileges. Our approach differs fromtheirs because we are focusing on supporting static inter-app analysis, while theyare using dynamic testing to detect such vulnerabilities.
ComDroid [4] analyzed inter-app communication in Android apps and dis-covered IAC vulnerabilities such as Broadcast Injection and Activity Hijacking.Epicc [18] is another tool that dedicated to identify IAC vulnerabilities in An-droid apps. Besides, Epicc records the actual values of IAC objects, which makesit appropriate to build inter-component (or inter-app) links. ContentScope [22]is another tool which detects Content Provider based vulnerabilities. It ar-gues that a Content Provider component can leak sensitive data to other appsand malicious apps can also pollute data maintained by a Content Provider.More recently, PCLeaks [17] was proposed to perform data-flow analysis on theabove IAC vulnerabilities to discover potential component leaks, which may leakprivate data across Android apps. While the above static approaches are tack-ling IAC vulnerabilities, they are actually only analyzing one app at a time andtheir outputs are so-called potential results. Our approach is able to complementthem by enabling them to indirectly perform inter-app analysis and give theman opportunity to conform that the aforementioned potential vulnerabilities areexploitable in real-world apps.
To the best of our knowledge, there is only one, recent, static approach,DidFail [13], which is able to perform static inter-app analysis. However, asshown in Section 2.2 (type (B1)), DidFail simply combines the results of intra-app analyses following an approach which is neither context-aware nor general.In contrast, our approach is able to provide a general context-aware inter-appanalysis, and therefore, all intra-app analyzers can benefit from it.
7 Conclusion
We discussed ApkCombiner, a tool-based approach for reducing an Inter-AppCommunication problem into an intra-app Inter-Component Communicationproblem by combining multiple Android apps into one. After the combination,existing intra-app analysis approaches can be applied on the generated An-droid app to indirectly report inter-app results. Since we combine apps at codelevel, our approach is context-aware and general. We evaluate ApkCombiner todemonstrate that, despite a conflict resolution algorithm that requires a time-consuming refactoring process, the approach is scalable. We further showed thatit can improve the capabilities of existing state-of-the-art tools. For example, weshowed that using ApkCombiner can enable tools such as IccTA to discover IACprivacy leaks in real-world apps.
Acknowledgments. This work was supported by the Fonds National de laRecherche (FNR), Luxembourg, under the project AndroMap C13/IS/5921289,by the BMBF within EC SPRIDE, by the Hessian LOEWE excellence initiativewithin CASED and by the DFGs Priority Program 1496 Reliably Secure SoftwareSystems and the project INTERFLOW.
14 Li Li et al.
References
1. K. Allix, Q. Jerome, T. F. Bissyande, J. Klein, R. State, and Y. L. Traon. Aforensic analysis of android malware–how is malware written and how it could bedetected? In COMPSAC. IEEE, 2014.
2. S. Arzt, S. Rasthofer, E. Bodden, A. Bartel, J. Klein, Y. Le Traon, D. Octeau, andP. McDaniel. Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps. In PLDI 2014, 2014.
3. S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A.-R. Sadeghi, and B. Shastry.Towards taming privilege-escalation attacks on android. In NDSS, 2012.
4. E. Chin, A. P. Felt, K. Greenwood, and D. Wagner. Analyzing inter-applicationcommunication in android. In MobiSys, New York, NY, USA, 2011. ACM.
5. X. Cui, D. Yu, P. Chan, L. C. Hui, S. Yiu, and S. Qing. Cochecker: Detectingcapability and sensitive data leaks from component chains in android. In ACISP’14.
6. L. Davi, A. Dmitrienko, A.-R. Sadeghi, and M. Winandy. Privilege escalationattacks on android. In Information Security, pages 346–360. Springer, 2011.
7. D. E. Denning and P. J. Denning. Certification of programs for secure informationflow. Communications of the ACM, 20(7):504–513, 1977.
8. W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. Sheth.Taintdroid: An information-flow tracking system for realtime privacy monitoringon smartphones. In OSDI, 2010.
9. W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A study of android appli-cation security. In USENIX Security, 2011.
10. A. P. Fuchs, A. Chaudhuri, and J. S. Foster. Scandroid: Automated security cer-tification of android applications. Manuscript, Univ. of Maryland, 2009.
11. J. T. Giffin, S. Jha, and B. P. Miller. Efficient context-sensitive intrusion detection.In NDSS, 2004.
12. M. Haris, H. Haddadi, and P. Hui. Privacy leakage in mobile computing: Tools,methods, and characteristics. arXiv preprint arXiv:1410.4978, 2014.
13. W. Klieber, L. Flynn, A. Bhosale, L. Jia, and L. Bauer. Android taint flow analysisfor app sets. In SOAP@PLDI, pages 1–6. ACM, 2014.
14. M. La Polla, F. Martinelli, and D. Sgandurra. A survey on security for mobiledevices. Communications Surveys & Tutorials, IEEE, 15(1):446–471.
15. P. Lam, E. Bodden, O. Lhotak, and L. Hendren. The soot framework for javaprogram analysis: a retrospective. In CETUS, 2011.
16. L. Li, A. Bartel, T. F. Bissyande, J. Klein, Y. Le Traon, S. Arzt, S. Rasthofer,E. Bodden, D. Octeau, and P. Mcdaniel. IccTA: Detecting Inter-Component Pri-vacy Leaks in Android Apps. In ICSE, 2015.
17. L. Li, A. Bartel, J. Klein, and Y. Le Traon. Automatically exploiting potentialcomponent leaks in android applications. In TrustCom. IEEE, 2014.
18. D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, and Y. Le Traon.Effective inter-component communication mapping in android with epicc: An es-sential step towards holistic security analysis. In USENIX Security, 2013.
19. D. Wagner and D. Dean. Intrusion detection via static analysis. In S&P, 2001.20. F. Wei, S. Roy, X. Ou, et al. Amandroid: A precise and general inter-component
data flow analysis framework for security vetting of android apps. In CCS, 2014.21. L. Wu, M. Grace, Y. Zhou, C. Wu, and X. Jiang. The impact of vendor customiza-
tions on android security. In CCS, pages 623–634. ACM, 2013.22. Y. Zhou and X. Jiang. Detecting passive content leaks and pollution in android
applications. In NDSS, 2013.
