You are on page 1of 11

Orlis: Obfuscation-Resilient Library Detection for Android

Yan Wang Haowei Wu

Ohio State University Ohio State University

Hailong Zhang Atanas Rountev

Ohio State University Ohio State University

ABSTRACT often release closed-source application. To further hinder decompi-

Android apps often contain third-party libraries. For many pro- lation tools and manual reverse engineering, apps are additionally
gram analyses, it is important to identify the library code in a given protected using obfuscation. There are several available choices
closed-source Android app. There are several clients of such library of obfuscation tools, including an obfuscation component in the
detection, including security analysis, clone/repackage detection, default Android IDE. An earlier study [55] estimates that about
and library removal/isolation. However, library detection is compli- 15% of Google Play apps are obfuscated, and more recent studies
cated significantly by commonly-used code obfuscation techniques indicate even wider use of obfuscation [55].
for Android. Although some of the state-of-the-art library detection Android apps often contain third-party libraries. Some usage
tools are intended to be resilient to obfuscation, there is still room statistics gathered commercially track 450 popular libraries [2] and
to improve recall, precision, and analysis cost. show that many of them have significant usage in the Android
We propose a new approach to detect third-party libraries in ecosystem. For example, advertisement libraries, social networking
obfuscated apps. The approach relies on obfuscation-resilient code libraries, and mobile analytics libraries are very popular. Some apps
features derived from the interprocedural structure and behavior of use more than 20 third-party libraries [35]. Developers use these
the app (e.g., call graphs of methods). The design of our approach components to monetize their apps, integrate with social media,
is informed by close examination of the code features preserved include single-sign-on services, or simply leverage the utility and
by typical Android obfuscators. To reduce analysis cost, we use convenience of libraries developed by others.
similarity digests as an efficient mechanism for identifying a small Program analysis of Android apps often requires detecting or
number of likely matches. We implemented this approach in the removing third-party library code as a pre-processing step, since the
Orlis library detection tool. As demonstrated by our experimental libraries could introduce significant noise and could substantially
results, Orlis advances the state of the art and presents an attractive affect the results of many analyses. Such library detection may
choice for detection of third-party libraries in Android apps. be needed for security analysis [4, 6, 21, 27, 41, 43, 58, 59], clone
and repackaging detection [14, 26, 61], and library removal and
KEYWORDS isolation [49, 60]. The use of libraries can also have security and
privacy implications [5, 9, 20, 22, 28, 42, 43, 49, 52–54]—for example,
Android, library detection, library identification, obfuscation, static
malicious libraries or unintended security vulnerabilities in library
code could lead to leaks of sensitive data.
ACM Reference Format: Library detection is complicated significantly by app obfuscation.
Yan Wang, Haowei Wu, Hailong Zhang, and Atanas Rountev. 2018. Orlis: Attempts to match package/class names or method signatures with
Obfuscation-Resilient Library Detection for Android. In MOBILESoft ’18:
ones from known libraries are easily thwarted by the renaming
MOBILESoft ’18: 5th IEEE/ACM International Conference on Mobile Software
Engineering and Systems , May 27–28, 2018, Gothenburg, Sweden. ACM, New
typically done by Android app obfuscators. It is highly desirable to
York, NY, USA, 11 pages. develop obfuscation-resilient third-party library detection. There
have been several efforts and research tools aiming to solve this
1 INTRODUCTION problem. However, as discussed in the next section, these tools have
various limitations.
The mobile app market has grown rapidly in the past decade. An-
Our contributions. We performed an investigation of popular
droid has become one of the largest mobile application platforms,
obfuscators and characterized their features that hinder library de-
with about 3.5 million apps in the Google Play Store [3], generat-
tection. We then studied how existing advanced publicly-available
ing about 31 billion USD revenue [8]. Some apps contain sensitive
library detection tools perform in the presence of such features.
private information or valuable business logic. Due to security con-
Although some of the state-of-the-art tools are intended to be re-
siderations, as well as intellectual property concerns, developers
silient to obfuscation, we argue that there is still room to improve
Permission to make digital or hard copies of all or part of this work for personal or recall, precision, and analysis cost.
Based on these observations, we propose a new approach to
on the first page. Copyrights for components of this work owned by others than ACM detect third-party libraries in obfuscated apps. The approach relies
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, on obfuscation-resilient method-level and class-level information.
fee. Request permissions from The richness of this information is significantly higher than what is
MOBILESoft ’18, May 27–28, 2018, Gothenburg, Sweden commonly used by library detection tools—for example, it consid-
© 2018 Association for Computing Machinery. ers transitive calling relationships between methods, as well as the
ACM ISBN 978-1-4503-5712-8/18/05. . . $15.00
structural relationships in class hierarchies and methods defined
MOBILESoft ’18, May 27–28, 2018, Gothenburg, Sweden Yan Wang, Haowei Wu, Hailong Zhang, and Atanas Rountev

in them. These features capture the inter-procedural structure and Table 1: Obfuscator features.
behavior of the app. This is in contrast with existing approaches,
which conceptually consider analysis of each separate method but ProGuard Allatori DashO
not the relationship between methods—that is, intra-procedural Identifier renaming Yes Yes Yes
analysis. The design of our approach is informed by close examina- Method renaming Yes Yes Yes
tion of the code features preserved by typical Android obfuscators. Class renaming Yes Yes Yes
The resulting library detection approach exhibits higher precision Package renaming Yes Yes Yes
and recall than prior work of similar nature. Code addition Yes Yes Yes
Library detection may have to be performed at large scale—for Code removal Yes Yes Yes
example, when app-market-scale analyses are applied for clone de- String encryption No Yes Yes
tection and security analysis. To reduce the cost of the analysis, we Repackaging/Package flattening Yes Yes Yes
use the machinery of similarity digests [16, 32, 39, 45]. Such digests Control flow modifications No Yes Yes
are similar to cryptographic hashes such as MD5 and SHA, but with Customized configuration Yes Yes Yes
the additional property that a small change in the data object being
hashed results in a small change to the hash itself. In our context,
similarity digests provide an efficient mechanism for identifying
a small number of likely matches. The use of such digests, rather packages into a new, different package and (2) flattening the package
than more traditional hashes, is critical: due to obfuscation, the hierarchy. Both Allatori and DashO can modify the code’s control
library code that is preserved in the obfuscated app does not match flow and encrypt the constant strings in the program. Finally, the
precisely the code in the original library; thus, direct comparison of tools can remove unused code (“Code removal” in the table) and
hash codes is not possible. We explore several similarity digests and add their own utility methods in the new code (“Code addition”).
demonstrate empirically that different ones are needed for different Note that all three tools can be easily configured to merge the app
aspects of the library detection process. code with the code of included third-party libraries, and obfuscate
We implemented this approach in the Orlis tool, which per- this combined code. Such a setup obfuscates the interfaces between
forms obfuscation-resilient library detection using interprocedural the app and its libraries, hides the library features being used by the
code features and similarity digests. Our experimental evaluation app, and reduces code size (e.g., unused library classes/methods can
studies the effects of various choices in the analysis implemen- be removed). However, this obfuscation makes library detection
tation, and then compares precision/recall with the state-of-the- significantly harder, as described below.
art LibDetect tool [26]. As demonstrated by our results, Orlis
presents an attractive choice for detection of third-party libraries 2.2 Existing Library Detection Tools
in Android apps. Our tool and benchmarks are available at http: Given the APK for an (obfuscated) Android app, the goal of library
//, for the benefit of other researchers detection is to determine which components of the app belong
and tool builders. to some third-party library that was used by the app developers.
The granularity of the answer is typically considered at two levels:
2 BACKGROUND package level and class level. In package-level matching, a package
in the package tree of the app is determined to be from some library.
2.1 Android Obfuscation
In class-level matching, a class in the app code is detected to be a
Code obfuscation is commonly used to protect against reverse en- library class. Package-level matching has a number of limitations,
gineering. A variety of obfuscation tools for Android are available— as described below. For the purposes of subsequent analyses (e.g.,
for example, the ProGuard tool included in the Android Studio IDE app clone detection [26]), class-level matching is both more general
from Google. Many released Android apps are obfuscated [55] since and more useful.
the unobfuscated bytecode is relatively easy to decompile using a There are currently two approaches for recognizing third-party
number of existing tools (e.g., [50]). When obfuscation is applied, libraries in Android apps. The first is to identify a component that
reverse engineering becomes much harder [30]. occurs in many apps, and to consider it to be an instance of some
In our study we investigated three obfuscators: ProGuard [44], unknown library. The specific library that was the original source
Allatori [1] and DashO [18]. They are widely used in Android devel- of the component remains undetermined. The second approach is
opment. As mentioned earlier, ProGuard is part of Google’s Android based on a database of known libraries. In this case, given an never-
Studio. Allatori is a tool developed by a Russian company, with before-seen app, the analysis determines which libraries from the
corporate clients such as Amazon, Fujitsu, and Motorola. DashO is database are present in the app.
another commercial tool, produced by a company with thousands
of corporate clients. 2.2.1 Detection of unknown libraries. Several approaches per-
The features of each obfuscator is summarized in Table 1. All form library detection without having a database of known libraries.
three can obscure identifier names, method names, class names, Such approaches divide an app into components which are regarded
and package names. Moreover, the values of the new names can as library candidates. Then a similarity metric or a feature-based
be customized, which means that developers can have their own hashing algorithm is used to classify these candidates. If a group
unique renaming schemes. In addition, the tools can modify the of similar candidates exists in many different apps, components in
package hierarchy, in particular (1) repackaging classes from several that group are considered instances of the same unknown library.
Orlis: Obfuscation-Resilient Library Detection for Android MOBILESoft ’18, May 27–28, 2018, Gothenburg, Sweden

An advantage of this approach is that there is no need to maintain when the obfuscation tool removes library methods and classes
a library database. One example from this category is the approach that are not used, directly or transitively, by the app code. This
used by Chen et al. [12], which mined libraries from a large number causes mismatches for class hashes and the ultimate failure of li-
of apps. However, when obfuscation is considered, this approach brary detection. Our experience with various obfuscation tools [57]
cannot perform well because several key assumptions are violated. confirms that such code changes are common in practice.
The first assumption is that all instances of a library included by Currently, the most sophisticated tool in this category is LibDe-
different apps have the same package name. This assumption is tect, which is a component of the CodeMatch tool for app clone
the basis of clustering algorithms used in similarity-based library and repackage detection [26]. The evaluation of LibDetect indicates
identification. However, using off-the-shelf obfuscators, it is easy that it outperforms alternative approaches [33, 37]. This approach
to violate this assumption. uses five different abstract representations of a method’s bytecode
Some researchers have considered the possibility that using pack- to match app methods against library methods. Then a mapping
age names makes library identification less robust. A recent tool between an app class and a library class is established according
called LibRadar [37] uses an algorithm that takes obfuscated pack- to method matches. The approach is resilient to many obfuscation
age names into consideration. LibRadar classifies library candidates techniques, including package renaming and removal of unused
through feature hashing and therefore does not need package-name- library code. However, the bytecode in a method’s body can the
based clustering. However, LibRadar recognizes library candidates changed in a variety of ways during obfuscation. A few examples of
according to the directory structures of packages. In particular, it such changes are adding dead code (unreachable statements as well
requires a library candidate to be a subtree in the package hier- as spurious conditionals with dead branches), replacing statements
archy. This is another assumption that is easily violated through with equivalent constructs (e.g., changing an if-then to a try-catch),
standard transformations available in obfuscation tools (as illus- and modifying expressions to use different operators (e.g., replacing
trated in Table 1). LibD [34] is another tool that does not rely on multiplication with bitshift). These bytecode changes can affect the
the hierarchy of the package tree, but instead uses the relationships code representations used by LibDetect and the matching based
among packages—e.g., inclusion and the inheritance relationships on them. Section 4 presents a detailed comparison of the library
between classes across different packages. However, these relation- detection performance of LibDetect and Orlis.
ships can be dramatically changed by obfuscation because classes There are other studies that use pre-computed information about
from several packages may be merged into one single package. known libraries to detect libraries in Android apps. For example,
Tools from this category (e.g., WuKong [56] and AnDarwin [15]) AdRisk [28] proposes to identify potential risks posed by advertise-
may also use features such as the number of different types of ment libraries; they use a whitelist of such libraries. Book et al. [9]
instructions, a method’s control-flow graph, or the number of API also use a whitelist of advertisement libraries to investigate library
calls, in order to define hashes for methods or classes. These hashes changes over time. For Android app clone detection, Chen et al. [11]
are compared during matching, with hash equality used as evidence use a library whitelist to filter third-party libraries when detecting
of a precise match. This is problematic because obfuscation may (1) app clones. Because such approaches only compare package names,
modify a method’s control-flow graph, (2) remove unused methods they cannot handle aggressive obfuscation.
and classes, and (3) add new utility methods. All three of these To summarize, none of the existing tools are highly resilient
changes are illustrated in Table 1. Such changes modify method against the code modification features that are easily available in
hashes and class hashes. To summarize, existing work on detection popular obfuscators. This motivates our work to develop a new
of unknown libraries is not resilient to obfuscation because it lacks library detection approach with better resilience to a wide range of
prior knowledge of possible libraries and the detection is entirely obfuscation transformations.
based on obfuscation-sensitive similarity metrics.

2.2.2 Detection using a repository of known libraries. The alter-

native approach, which relies on knowledge of existing libraries APPROACH FOR LIBRARY DETECTION
(using some pre-assembled repository of such libraries), is more We developed a library detection approach that belongs to the
promising when dealing with obfuscation. A representative exam- second category described in the previous section: a given obfus-
ple of a tool from this category is LibScout [5]. This tool’s matching cated app is compared against a repository of known libraries, and
is based on the package structure and hashes of classes in the high-likelihood matches are reported to the user. However, unlike
package. Class hashes themselves are based on hashes of simpli- existing tools, we do not consider the app package structure and
fied (“fuzzy”) forms of method signatures. Although robust against the detailed method body bytecode, because they can be modified
control flow modification and package/class/identifier renaming, significantly by obfuscation. The output of our approach is class-
LibScout is not fully resilient to obfuscation. For example, flattening level mapping between application code and library code: for each
the package hierarchy would still defeat this approach because the app class, the analysis reports (1) whether this class likely origi-
package hierarchy is modified and the boundaries between app and nated from one of the libraries in the repository, and (2) the specific
library code become blurred. Another problem is the removal of library class that is the most likely match for the app class. As dis-
unused library code, or the addition of obfuscation-tool-specific cussed earlier, class-level matching provides essential information
utility methods. As a result of these changes, it is common for an for subsequent analyses such as app clone/repackaging detection.
app to contain a strict subset of the set of classes and methods that Furthermore, the reported app-to-library matching is injective: at
are observed in the library code inside the database. This happens most one app class is matched with a particular library class.

3.1 Assumptions About Obfuscation Stage 1

Our approach is based on several assumptions derived from our Libs Apps
studies of Android obfuscators (Section 2). Prior work on library
detection typically does not define or validate its assumptions on
the properties of obfuscation. As a result, it is hard to reason about Lib digest App digest
the generality of various techniques and to perform systematic
comparisons between them.

3.1.1 Method-level assumptions. We assume that a method from Candidate Libs

a library is either included in the app as a separate entity, or not

included at all. This means that during obfuscation, a method is Stage 2
neither split into several new methods, nor merged with another
method. We also assume that the number and types of method for-
mal parameters are preserved, as well as the return type. Of course, Class digest Class digest

we need to assume that the name of the method could have been
modified by the obfuscator. Similarly, if a method parameter/return
type is defined by a library class, it is possible that this class was
renamed by the obfuscator—both in the class definition and in the
class mapping

method signature. a d

Our approach also assumes that regardless of changes to the b e

method body (e.g., modifications to the method’s control-flow graph,
c f
changes to statements and expressions, addition of unused code),
the calling relationships between two library methods are preserved.
Specifically, we assume that if method m 1 contains a call site that Figure 1: Workflow for library detection.
may call m 2 at run time, and the obfuscator includes m 1 in the
app, it will also include m 2 and will preserve the corresponding
call site inside m 1 . We have not observed obfuscators that violate
this assumption; one reason may be that removal of such call sites Using this approach, for each library from the repository we can
(e.g., via inlining) is complex to implement and could introduce pre-compute a library digest as well as class digests for its classes.
semantic errors due to polymorphic calls, reflection, and dynamic Given an unknown obfuscated app, its app digest and class digests
class loading. are computed. Based on this information, the library detection
workflow proceeds in two stages, as shown in Figure 1. Stage 1
3.1.2 Class-level assumptions. Another group of assumptions compares the app digest with each library digest. Libraries that are
relates to the properties of library classes. As with methods, we highly unlikely to be included in the app are removed from further
assume that a library class is either fully excluded from the app, consideration. This decision is based on similarity scores derived
or included as a separate entity and not split/merged. We also from the digests. After this stage, only a small number of libraries
assume that library classes may have been renamed, but the class from the repository are left as candidates. In Stage 2, an injective
hierarchy is preserved—that is, if a library class C is included in the mapping from app classes to library classes is determined, based
app, so is the chain of C’s transitive superclasses. In addition, we on the similarity of class digests. Only classes from the candidate
assume that some methods from C may have been removed by the libraries are considered for this mapping.
obfuscator, but the ones that are preserved are still members of C
after obfuscation. Note that the obfuscator may have added new 3.3 String Features for Methods
methods to C—for example, we have seen cases where an obfuscator Fuzzy signatures are computed as follows. Given a method signature
adds utility methods for string decryption. containing a name, parameter types, and return type, a simplified
signature is created by (1) removing the method name and (2) replac-
3.2 Code Features and Detection Workflow ing all classes defined in the library/app with a single placeholder
Based on these assumptions, we define a set of code features used name. Names of Android framework classes and Java standard
for library detection. First, for each method in a library or in an an- library classes remain unchanged. For example, if we consider a
alyzed app, we use a fuzzy signature as defined by others [5]. These library method with signature int methodA(android.view.View,
signatures are used to build a fuzzy call graph for each method, ClassA,int,java.lang.String), the corresponding fuzzy signa-
which is then mapped to a string feature for the method (Section 3.3). ture is int(android.view.View,X,int,java.lang.String). Here
The method features for a library are used to create a library digest; View and String are standard library classes that would not be re-
a similar app digest is built from the features of app methods (Sec- named by an obfuscator, while library class ClassA is replaced with
tion 3.4). Method features are also used to compute a class digest a placeholder X because obfuscation may change its name when
for each class, based on the methods appearing in the class and in the library is included in an app and that app is obfuscated.
its transitive superclasses. In all cases, similarity digests are used Recall the assumption that (transitive) calling relationships be-
(Section 3.5). tween methods would not be affected by obfuscation. If a library

Algorithm 1: Class-level mapping

alphabet Inheritance
Input: SortedPairs: list of ⟨ac i , lc j ⟩ sorted by s i j
f₀ for m₀ order
feature of method₀ in M₀ Alphabet
s₀ for c₀ hierarchy 1 Result ← { }
feature of method₁ in M₀ 2 AppClasses ← { }
f₁ for m₁ . s₁ for c₁ 3 LibClasses ← { }
. 4 foreach ⟨ac i , lc j ⟩ ∈ SortedPairs in order do
feature of methodᵢ in M₀ 5 if s i j < threshold then
f₂ for m₂ s₂ for c₂
6 break
7 if ac i ∈ AppClasses then
. . 8 continue
. . 9 if lc j ∈ LibClasses then
. . 10 continue
11 AppClasses ← AppClasses ∪ {aci }
12 LibClasses ← LibClasses ∪ {lc j }
fᵢ for mᵢ sᵢ for cᵢ 13 Result ← Result ∪ {⟨ac i , lc j ⟩}

(a) String feature for an (b) String feature for a class C 0

app or a library
3.5 Stage 2: Class Similarity
Figure 2: String features used for matching. Stage 2 determines a mapping from app classes to library classes.
Suppose an app has a set of classes S app = {ac 1 , ac 2 , . . . , acn } and
a set of candidate libraries {lib1 , lib2 , . . . , libk } as determined by
Stage 1. Let S lib = {lc 1 , lc 2 . . . , lcm } be the union of the set of classes
in libi over all i.
method m is included in an obfuscated app, m’s call graph in the li-
For each class in S app or S lib , a string feature is computed as
brary (i.e., m, its transitive callees, and the call edges between them)
illustrated in Figure 2b. Consider a class C 0 and the chain of its
would be a subgraph of m ′ call graph in the app. Note that we can-
superclasses C 1 , C 2 , . . . , Ck , accounting only for classes that are
not claim that the two call graphs are identical: it is possible that
defined in the app (or the library)—that is, excluding classes such
there are extra callees of m in the app, due to (1) app subclasses that
as java.lang.Object. As discussed earlier, we assume that if C 0
override methods defined in library superclasses, and (2) calls to
is included in the app, so are all Ci in this list. Let Mi be the set of
utility methods inserted by the obfuscator. One can try to determine
methods defined in Ci . We consider the string features of all meth-
whether m is present in a given obfuscated app by (1) constructing
ods in Mi , sort them alphabetically, and concatenate them to obtain
m’s call graph in the library, (2) constructing the app’s call graph, (3)
a string si (0 ≤ i ≤ k). Then the concatenation of s 0 , s 1 , . . . , sk (in
replacing each method in the graphs with its fuzzy signature, and
that order) defines the string feature for C 0 . Finally, a digest of this
(4) searching for an isomorphic subgraph. Unfortunately, subgraph
string is computed.
isomorphism is a classic NP-complete problem.
A pair-wise similarity score si j is computed for classes aci and lc j
Instead, we use a string representation of the fuzzy call graph
by comparing their class digests. Then all pairs ⟨aci , lc j ⟩ are sorted
of each method in a library or an app to define features that are
based on si j and the sorted list is processed using Algorithm 1. The
then used to create similarity digests. Specifically, consider a library
resulting class-level mapping is clearly injective.
with a set of methods {m 1 , m 2 , . . . , mn }. For each method mi , we
compute a feature fi : a string containing the fuzzy signatures of all
3.6 Implementation
methods reachable from mi in the library call graph, including mi
itself. To make fi deterministic, the fuzzy signatures are sorted al- To evaluate this approach, we implemented it in the Orlis tool.
phabetically and then concatenated to create the final string feature The library/app bytecode is analyzed using the Soot [50] analysis
fi . The same approach is used to define a feature f j for a method framework. The call graph is computed using class hierarchy anal-
m j in a given obfuscated app. ysis to resolve polymorphic call sites. Digest sdhash [48] is used in
Stage 1, while digest ssdeep [51] is used in Stage 2. This choice of
digests is discussed in Section 4.
3.4 Stage 1: App-Library Similarity To determine the set of transitive callees for each method, we
As described earlier, the purpose of this stage is to determine the first identify the strongly-connected components (SCC) in the call
similarity between an app and a library in order to filter out libraries graph. They are used to create the SCC-DAG, in which nodes are
that are unlikely to be included in the app. For each app (or library), SCCs and an edge represents the existence of a call graph edge
a string feature f app (or f lib ) is computed based on the method that connects two SCCs. Reverse topological sort order traversal
string features described above. The string features for the methods of the SCC-DAG is then used to compute, for each SCC, the SCCs
are sorted alphabetically and then concatenated, as illustrated in transitively reachable from it. The method features are derived from
Figure 2a. A digest is computed from this feature. The pre-computed this information.
digests in the library repository are compared for similarity with the
digest of the given obfuscated app. Experimental results presented 4 EVALUATION
in Section 4 show that this approach is very effective in filtering Our experimental evaluation had two main goals: (1) to study the
out a large number of libraries. effects of design choices in the performance of Orlis, and (2) to

Table 2: Apps in FDroidData Table 3: Comparison with LibDetect on FDroidData

ProGuard DashO Allatori recall precision F1

#Apps 203 215 241 LibDetect 0.10 0.63 0.17
Orlis 0.63 0.71 0.67

compare Orlis with the state-of-the-art LibDetect tool. Evaluation Table 4: Similarity score metrics
considered precision, recall, and analysis running time. All exper-
iments were performed on a machine with an Intel Core i7-4770 Similarity digest sdhash ssdeep TLSH nilsimsa
3.40GHz CPU and 16GB RAM. The reported running time is the
Score range 0–100 0–100 0–∞ 0–128
sum of user CPU time and system CPU time.
No similarity 0 0 N/A 0
Identical 100 100 0 128
4.1 Evaluation with Open-Source Apps
Two different data sets were used in our evaluation. The first one, de-
noted by FDroidData, is obtained from the F-Droid repository [23]. The results of this experiment are presented in Table 3. Each
The second data set, denoted by LibDetectData, is based on the data cell in the table shows the average value across all apps in the data
used in the evaluation of the LibDetect tool [26]; details of this data set. In these experiments Orlis was configured with sdhash for
set and its uses are presented in Section 4.2. Stage 1 and ssdeep for Stage 2, as described below. We examined
To collect FDroidData, we gathered apps with available source manually the output of LibDetect to determine the reasons for the
code from a variety of app categories and tried to build them with reported low recall. We observed that the tool computes a relatively
the Gradle tool; 282 apps were built and used to construct our data small number of matching class pairs; a possible explanation is
set. A total of 453 unique library jars were included in this set of that the approach does not consider methods whose size is below a
apps. These jars formed the library repository for this data set. The certain threshold. When mapped to package-level information, the
apps were then obfuscated by us. The app source code is necessary recall increases significantly. This can be observed in the results
because (1) the obfuscators are applied to Java bytecode constructed presented in Section 4.2, which describes another comparison with
from the source code, and (2) we can determine which third-party LibDetect.
library jar files are included in the build process.
We attempted to obfuscate each app using the tools described in 4.1.2 Selection of similarity digests. At present, there are four
Section 2: ProGuard, DashO, and Allatori. The number of resulting popular public implementations of similarity digests that could be
apps is shown in Table 2. The numbers differ across obfuscators used for our purposes: sdhash [45], ssdeep [32] , TLSH [40], and
because sometimes an obfuscator may fail to obfuscate an app. The nilsimsa [16]. All of them are able to (1) generate a digest for a
obfuscators were executed in a configuration that includes the third- given byte array, and (2) compute a similarity score between two
party libraries in the scope of obfuscation, and performs package digests to indicate the similarity of the represented byte data. Their
flattening and renaming. As discussed in Section 2, such obfuscation similarity score metrics are shown in Table 4. The scores for sdhash,
is not handled by many library detection tools. LibDetect [26], ssdeep and nilsimsa are in a fixed range. For data without any
which according to its evaluation represents the most advanced similarity, the similarity score is 0. TLSH uses a similarity score
current approach in terms of precision and recall, is designed to of 0 to indicate that the compared digests are identical. As the
handle this issue. We used FDroidData (which contains the total of digest difference increases, so does the similarity score, without
659 apps from Table 2) to compare the performance of Orlis and any pre-defined bound.
LibDetect. In addition, this data set was used to study the effects of Figure 3a shows how Stage 1 filtering performs when using
various similarity digests and thresholds in the design of Orlis. these digests. Recall that this stage compares an app digest with
each library digest in the repository, in order to determine which
4.1.1 Comparison with LibDetect. For each obfuscated app in libraries are likely to have been included in the app. Conservatively,
this set, we established the ground-truth mapping from app-included the tool reports a library as a possible candidate if there is any
library classes to the library classes in the library repository, using similarity between the digests. For sdhash, ssdeep, and nilsimsa
the logs provided by the obfuscation tools. We then considered the this means a similarity score greater than zero. TLSH does not have
sets of pairs (app class,library class) reported by Orlis. For each app, a pre-defined value to represent no similarity; we used 300 because
the precision for this app was computed as the ratio of the number this is the value used in the tool’s own evaluation [39]. Given the
of reported true pairs to the total number of reported pairs. Recall reported candidate library jars, we can compute precision, recall,
for an app was computed as the ratio of the number of reported and F1 score for each app. The averages of these measurements
true pairs to the total number of true pairs. The F1 score for each over the apps in the data set are presented in Figure 3a. When
app was also computed (2 times the product of recall and precision, gathering and analyzing these measurements, we found that the
divided by the sum of recall and precision). Similar metrics were results were skewed if the repository contained several versions
computed for LibDetect. That tool outputs information at the pack- of the same library, and each was treated as a separate library
age level (i.e., pairs of packages). We modified the tool to print the for computing these metrics. Thus, for Figure 3a, we computed
set of class-level pairs used to compute the package-level pairs, and the metrics by treating different versions of the same library as
used those class-level pairs to compute recall and precision. being the same entity (in the numerator and denominator of recall

(a) Precision, recall and F1 for stage I (b) Precision, recall and F1 for stage II

Figure 3: Performance of similarity digests for FDroidData

and precision). This produced metrics that faithfully represent the

relevant properties of the similarity digests.
Among the four choices, sdhash exhibits the highest F1 value
and the best trade-off between recall and precision. Thus, we used
this choice for the remaining experiments described in this section.
The average number of candidate library jars per app is around 22,
which is only 5% of the total number of libraries in the repository.
The results are similar for the LibDetectData dataset described later:
the average number of candidate library jars per app is also around
22, for a repository containing 7519 library jars. This is a promis-
ing indication that the number of candidate libraries produced by
Stage 1 is independent of the total number of libraries. Note that
depending on the desired trade-offs of the tool, another choice of a
similarity digest could be made. For example, recall can be increased
with TLSH and nilsimsa, at the expense of precision; as a result, Figure 4: Running time for FDroidData
fewer libraries would be filtered and the cost of subsequent Stage 2
matching would increase. We further examined various missing and mis-mapped classes. Most
Figure 3b shows the performance of Stage 2. This stage com- of them have very simple call graphs; some even have no callees
pares app classes with classes in the candidate library jars. Recall at all. As a result, their string features are very short and likely to
from Algorithm 1 that class pairs are processed in sorted order of be similar. This leads to a high chance of digest similarity (or no
their similarity scores: decreasing order for sdhash, ssdeep, and digest at all) and makes them indistinguishable.
nilsimsa and increasing order for TLSH. In addition, a pair is con- We also measured the running time of the four digest functions.
sidered only if its similarity score exceeds a pre-defined threshold There are two components to this cost. The first one is digest build-
(or is below that threshold, for TLSH). The default thresholds are the ing, which is the time to calculate the digest value based on the
same as the ones for Stage 1: 0 for sdhash, ssdeep, and nilsimsa given string feature. The second component is digest comparison,
and 300 for TLSH. The effect of different threshold values is studied which computes a similarity score based on the digest values. Fig-
further in Section 4.3. For each app in FDroidData, we computed ure 4 shows measurements for both components. “Digest building”
precision and recall as described earlier. The results for ssdeep represents the time to calculate digests for the 659 apps and 453
in the figure match those in Table 3. As the measurements show, libraries in FDroidData, while “digest comparison” is the time to
ssdeep has the best recall, precision, and F1 score. compute the similarity scores between apps and libraries in Stage 1
It is worth noting that sdhash and TLSH require certain amount and between app classes and library classes in Stage 2. The results
of data: in order to compute a digest, the data size should exceed show that nilsimsa is significantly more expensive than the re-
512 bytes and 256 bytes, respectively. In FDroidData, only about maining digests. For digest building, the other three choices do not
40% of library class features exceed the 512 byte threshold and show substantial differences: all three complete in around 5–6 min-
about 51% exceed the 256 byte threshold. Classes for which this utes. For digest comparison there are more significant differences in
threshold is not met do not have digests and do not appear in the running time. Although slower than TLSH, sdhash and ssdeep can
reported mapping. This causes the low recall for sdhash and TLSH. complete the digest comparison in less than 200 minutes. Taking

(a) Recall, precision and F2 (b) Running time

Figure 5: Comparison with LibDetect

into account the recall, precision, and cost of each digest function, For the i-th analyzed app, let the number of true positives, false
we decided to use sdhash in Stage 1 and ssdeep in Stage 2 of Orlis. positives, and false negatives be tpi , fpi , and fni respectively. The
average number of true positives tp is the average of all tpi . The
4.2 Evaluation with Closed-Source Apps average number of false positives fp and the average number of
The second dataset we used, denoted by LibDetectData, is based false negatives fn are defined similarly. The overall precision, recall,
on the data set used for the evaluation of the LibDetect tool [26]. and F2 score are computed as follows:
As mentioned earlier, this tool presents the state of art in Android
library detection. In order to compare the performance of Orlis tp
recall =
with LibDetect, we used data made publicly available by the au- tp + fn
thors of this work.1 We tried to collect the same data used in the tp
evaluation of LibDetect and to use the exact same metrics. In this precision =
tp + fp
prior work, 1000 apps were collected from five different app stores.
Then, the ground truth for those apps was constructed manually. 5 × precision × recall
F2 =
Since the authors of LibDetect were unable to distribute these apps, 4 × precision + recall
we searched for and downloaded the apps with the same names. To We computed the same metrics in our evaluation. Since the
ensure that the app is the same as the one used in the evaluation of ground truth provided at LibDetect’s web site does not contain
LibDetect, we matched all app packages with ones in the ground class-level mappings, we were unable to compute precision and
truth from LibDetect’s web site [13]. If any package name did not recall at the class level (unlike for FDroidData, where we know
match, we considered this as evidence that we may have a different the class-level ground truth). The results from this experiment are
version of the app, and removed that app from the data set. As a shown in Figure 5a. Overall, Orlis exhibits higher precision and
result, we were able to obtain 712 apps that matched ones used in recall. This indicates that using interprocedural features such as
this prior work. To gather the libraries used in the repository, we call graphs and class hierarchies is a viable approach for library
attempted to download all libraries used in LibDetect’s experiments, detection.
based on the library URL from the same web site. We successfully We also measured the running time for both tools. LibDetect
obtained 7519 libraries out of the 8000 listed at the web site. Some needs to parse each known library and store the necessary informa-
libraries are missing because the corresponding URLs are no longer tion in a database. Similarly, Orlis processes each known library,
available. The evaluation of LibDetect uses F2 scores, and we also builds call graphs, derives string features and digests, and stores
computed the F2 scores for our evaluation. them in its repository. Repository building is a one-time cost; it is
The metrics presented in the evaluation of LibDetect are at the also highly parallelizable. Typically, the number of known libraries
package level: the ground truth is a set of library packages for each is smaller than the number of apps that would be analyzed against
app. The class-level pairs computed by the analysis are used to the repository. Figure 5b shows the time for both repository building
construct the corresponding package sets; we did the same for the (“pre-process”) and app analysis (“computation”). Orlis takes more
output of Orlis. Recall and precision are computed based on these time to construct its repository, but the cost of app analysis is lower.
package sets. Following the metrics used in this prior work, both Besides the time cost, both LibDetect and Orlis have to store the
precision and recall were computed by using the average number library information to disk. For the libraries in the LibDetectData
of true positives, false positives, and false negatives across all apps. data set, LibDetect uses 8812 MB space in a MySQL database, while
1 We sincerely thank the authors of LibDetect for their valuable help with providing Orlis uses 460 MB of files on disk. These measurements do not
information about their experiments and benchmarks. include the space to store the library jars.

(a) Changes of recall in Stage 1 (b) Changes of precision in Stage 1

(c) Changes of recall in Stage 2 (d) Changes of precision in Stage 2

Figure 6: Effect of thresholds for FDroidData

4.3 Effect of Thresholds and their properties (e.g., monotonicity) [24]. De-obfuscation ap-
In our approach, it is possible to set a cut-off threshold in Stage 1 proaches have also been proposed. One recent example is an ap-
or Stage 2. Pairs whose similarity score does not exceed the thresh- proach based on a probabilistic model [7]. ProGuard is the only
old (or, for TLSH, is not smaller than the threshold) are considered obfuscator considered in that work; further, the technique considers
non-matching by default. The experiments described so far use the only the renaming of program elements (e.g., methods and classes),
threshold of 300 for TLSH and 0 for the remaining digest functions. but not repackaging or control-flow modifications. Wang et al. [57]
It is interesting to see how different threshold values affect both propose a machine learning approach to identify the obfuscator
stages. We selected 10 thresholds, equally spaced, from the “least used to modify a given obfuscated app. Hammad et al. [29] studied
restrictive” end to the “most restrictive” end of the similarity score the impact of obfuscation on Android anti-malware products by
range. Figure 6 shows the changes of the recall and precision for investigating 7 obfuscators and 29 obfuscation techniques. This
Stage 1 and Stage 2 using FDroidData. As expected, recall in Fig- work aimed to analyze the influence of obfuscation on existing
ure 6a and Figure 6c decreases while the precision in Figure 6b and tools. Garcia et al. [25] proposed a machine learning approach to
Figure 6d increases when the threshold becomes more restrictive. identify the family of Android malware even in the presence of
Depending on the use case, the desired trade-off may be selected obfuscation, by using Android APIs, reflection, and native calls as
by choosing the appropriate threshold. For example, when using features. This study focused on anti-malware analysis and consid-
library detection as a pre-processing step in clone/repackage de- ered obfuscation-resilient properties different from the ones used
tection (to remove library classes from further consideration), a in our work. We also investigate popular obfuscators and the tech-
relatively loose threshold may be more appropriate in order to niques they employ, but our goal is to identify code features that
detect as many as library classes as possible. can be used to identify third-party libraries.
Third-party library detection in Android. As discussed earlier,
5 RELATED WORK there is a body of work on library detection for Android [5, 9, 11, 12,
15, 26, 28, 34, 37, 56]. Some of these techniques have obfuscation-
Android obfuscation. There is a small but growing body of work resilient aspects, but as described in Section 2, several assumptions
related to Android obfuscation. One representative example is a new
obfuscation approach that integrates several techniques including
native code, variable packing, and dead code insertionc̃itekovacheva-
iait13. Another study considered several obfuscation techniques

used in these tools are violated by commonly-used Android obfus- REFERENCES

cators. Our approach is specifically designed to exploit obfuscation- [1] Allatori 2017. Allatori.
resilient features. AdDetect [38] and PEDAL [36] use machine learn- [2] Appbrain 2018. Appbrain: Android library statistics.
ing to detect advertisement libraries in Android apps. However, [3] Appbrain 2018. Appbrain: Number of Android applications.
these approaches can only handle this particular category of li- stats/number-of-android-apps.
[4] Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bar-
braries, while our approach is applicable to any library. Li et al. [33] tel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. 2014.
investigated the common libraries used in Android apps by mining FlowDroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint
libraries in a large number of apps. The purpose of this work is to analysis for Android Apps. In PLDI. 259–269.
[5] Michael Backes, Sven Bugiel, and Erik Derr. 2016. Reliable third-party library
study popular Android libraries. The resulting library package list detection in Android and its security applications. In CCS. 356–367.
is not aimed at detecting libraries for a given obfuscated app. [6] Michael Backes, Sven Bugiel, Erik Derr, Sebastian Gerling, and Christian Hammer.
Similarity digests. Similarity digests are somewhat similar to stan- 2016. R-Droid: Leveraging Android app analysis with static slice optimization.
In ASIACCS. 129–140.
dard hashes, but allow one to measure the similarity between two [7] Benjamin Bichsel, Veselin Raychev, Petar Tsankov, and Martin T. Vechev. 2016.
data objects based on comparison of their digests. Several differ- Statistical deobfuscation of Android applications. In CCS. 343–355.
[8] Bloomberg 2017. Google’s Android generates 31 billion revenue.
ent techniques have been developed in this area. One scheme is com/news/articles/2016-01-21/google-s-android-generates-31-billion-revenue-
based on feature extraction (e.g., sdhash [45]), which is a statis- oracle-says-ijor8hvt.
tical approach for selecting fingerprinting features that are most [9] Theodore Book, Adam Pridgen, and Dan S. Wallach. 2013. Longitudinal analysis
of Android ad library permissions. CoRR abs/1303.0857 (2013).
likely to be unique to a data object. Another scheme is fuzzy hash- [10] Moses Charikar. 2002. Similarity estimation techniques from rounding algorithms.
ing (e.g., ssddep [32]), which uses rolling hashes and produces In STOC. 380–388.
a pseudo-random value where each part of the digest only de- [11] Kai Chen, Peng Liu, and Yingjun Zhang. 2014. Achieving accuracy and scalability
simultaneously in detecting application clones on Android markets. In ICSE.
pends on a fragment of the input. The result is treated as a string 175–186.
and is compared with other digests on the basis of edit distance. [12] Kai Chen, Xueqiang Wang, Yi Chen, Peng Wang, Yeonjoon Lee, XiaoFeng Wang,
Bin Ma, Aohui Wang, Yingjun Zhang, and Wei Zou. 2016. Following devil’s
Roussev et al. [46] proposed a similarity approach that uses par- footprints: Cross-platform analysis of potentially harmful libraries on Android
tial knowledge of the internal object structure and Bloom filters. and iOS. In IEEE S&P. 357–376.
Follow-up work [47] attempts to balance performance and accuracy [13] CodeMatch 2017. CodeMatch.
by maintaining hash values at several resolutions, but requires un- [14] Jonathan Crussell, Clint Gibler, and Hao Chen. 2012. Attack of the clones:
derstanding of the syntactic structure of data objects, which affects Detecting cloned applications on Android markets. In ESORICS. 37–54.
its generality. Locality sensitive hashing is also a type of similarity [15] Jonathan Crussell, Clint Gibler, and Hao Chen. 2015. AnDarwin: Scalable de-
tection of Android application clones based on semantics. IEEE Trans. Mobile
digest. Locality-sensitive hashing [31] was originally used for a ran- Computing 14 (2015), 2007–2019.
domized hashing framework for efficiently approximating nearest [16] Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, and
Pierangela Samarati. 2004. An open digest-based technique for spam detection.
neighbor search in high dimensional space. Since then, it has be- In ISCA. 559–564.
come one of the most popular solutions for this type of problem. In [17] Anirban Dasgupta, Ravi Kumar, and Tamás Sarlós. 2011. Fast locality-sensitive
general, there are two approaches: (1) approximating the distance hashing. In KDD. 1073–1081.
[18] DashO 2017. DashO.
between data objects by comparing their hashes, and (2) mapping [19] Mayur Datar, Nicole Immorlica, Piotr Indyk, and Vahab S. Mirrokni. 2004. Locality-
similar objects to the same bucket in a hash table, after which search sensitive hashing scheme based on p-stable distributions. In SoCG. 253–262.
is performed within a bucket. The hashing functions TLSH [40] and [20] Dropbox Blog 2017. Security bug resolved in the Dropbox SDKs for Android.
blogs.dropbox .com/developers/2015/03/security-bug-resolved-in-the-dropbox-sdks-
nilsimsa [16] discussed in Section 4 belong to the former category. for-android.
For the second category, many hash functions (e.g., [10, 17, 19]) [21] Manuel Egele, David Brumley, Yanick Fratantonio, and Christopher Kruegel. 2013.
An empirical study of cryptographic misuse in Android applications. In CCS.
have been developed for Euclidean distance, angle-based distance, 73–84.
Hamming distance, etc. However, such distance metrics cannot be [22] William Enck, Damien Octeau, Patrick D. McDaniel, and Swarat Chaudhuri. 2011.
applied directly to our data. A study of Android application security. In USENIX Security.
[23] F-Droid 2017. F-Droid Repository.
[24] Felix C. Freiling, Mykola Protsenko, and Yan Zhuang. 2014. An empirical eval-
uation of software obfuscation techniques applied to Android APKs. In ICST.
6 CONCLUSIONS [25] Joshua Garcia, Mahmoud Hammad, and Sam Malek. 2018. Lightweight,
obfuscation-resilient detection and family identification of Android malware.
Identification of third-party libraries in Android apps is of signif- TOSEM 26, 3 (2018), 11:1–11:29.
icant interest for a variety of clients. Existing library detection [26] Leonid Glanz, Sven Amann, Michael Eichberg, Michael Reif, Ben Hermann,
Johannes Lerch, and Mira Mezini. 2017. CodeMatch: Obfuscation won’t conceal
techniques do not handle well the variety of code transformations your repackaged app. In FSE. 638–648.
employed by current Android obfuscators. We propose to use call [27] Michael I. Gordon, Deokhwan Kim, Jeff H. Perkins, Limei Gilham, Nguyen
graphs and class hierarchies as the basis for library matching, to- Nguyen, and Martin C. Rinard. 2015. Information flow analysis of Android
applications in DroidSafe. In NDSS.
gether with similarity digests for efficiency. Our experimental re- [28] Michael C. Grace, Wu Zhou, Xuxian Jiang, and Ahmad-Reza Sadeghi. 2012. Unsafe
sults indicate that the proposed Orlis tool advances the state of exposure analysis of mobile in-app advertisements. In WiSec. 101–112.
[29] Mahmoud Hammad, Joshua Garcia, and Sam Malek. 2018. A large-scale empirical
the art in obfuscation-resilient library detection for Android. study on the effects of code obfuscations on Android apps and anti-malware
Acknowledgements. We thank the MOBILESoft reviewers for their products. In ICSE.
[30] Rowena Harrison. 2015. Investigating the effectiveness of obfuscation against
valuable feedback. This material is based upon work supported Android application reverse engineering. Technical Report RHUL-MA-2015-7.
by the U.S. National Science Foundation under CCF-1319695 and Royal Holloway University of London.
[31] Piotr Indyk and Rajeev Motwani. 1998. Approximate nearest neighbors: Towards
CCF-1526459, and by a Google Faculty Research Award. removing the curse of dimensionality. In STOC. 604–613.

[32] Jesse D. Kornblum. 2006. Identifying almost identical files using context triggered
piecewise hashing. Digital Investigation 3 (2006), 91–97.
[33] Li Li, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. 2016. An
investigation into the use of common libraries in Android apps. In SANER. 403–
[34] Menghao Li, Wei Wang, Pei Wang, Shuai Wang, Dinghao Wu, Jian Liu, Rui Xue,
and Wei Huo. 2017. LibD: Scalable and precise third-party library detection in
Android markets. In ICSE. 357–376.
[35] Library 2017. Apps with most 3rd party libraries.
[36] Bin Liu, Bin Liu, Hongxia Jin, and Ramesh Govindan. 2015. Efficient privilege
de-escalation for ad libraries in mobile apps. In MobiSys. 89–103.
[37] Ziang Ma, Haoyu Wang, Yao Guo, and Xiangqun Chen. 2016. LibRadar: Detecting
third-party libraries in Android apps. In ICSE. 641–644.
[38] Annamalai Narayanan, Lihui Chen, and Chee Keong Chan. 2014. AdDetect:
Automated detection of Android ad libraries using semantic analysis. In ISSNIP.
[39] Jonathan Oliver, Chun Cheng, and Yanggui Chen. 2013. TLSH–A locality sensitive
hash. In Cybercrime and Trustworthy Computing Workshop. 7–13.
[40] Jonathan Oliver, Scott Forman, and Chun Cheng. 2014. Using randomization to at-
tack similarity digests. In International Conference on Applications and Techniques
in Information Security. 199–210.
[41] Marten Oltrogge, Yasemin Acar, Sergej Dechand, Matthew Smith, and Sascha
Fahl. 2015. To pin or not to pin—Helping app developers bullet proof their TLS
connections. In USENIX Security. 239–254.
[42] Parse Blog 2017. Discovering a major security hole in Facebook’s Android SDK. /learn/engineering/discovering-a-major-security-hole-in-facebooks-
[43] Sebastian Poeplau, Yanick Fratantonio, Antonio Bianchi, Christopher Kruegel,
and Giovanni Vigna. 2014. Execute this! Analyzing unsafe and malicious dynamic
code loading in Android applications. In NDSS.
[44] Proguard 2017. ProGuard.
[45] Vassil Roussev. 2009. Hashing and data fingerprinting in digital forensics. IEEE
Security & Privacy 7 (2009), 49–55.
[46] Vassil Roussev, Yixin Chen, Timothy Bourg, and Golden G. Richard III. 2006.
md5bloom: Forensic filesystem hashing revisited. Digital Investigation 3 (2006),
[47] Vassil Roussev, Golden G Richard, and Lodovico Marziale. 2007. Multi-resolution
similarity hashing. Digital Investigation 4 (2007), 105–113.
[48] sdhash 2017. sdhash.
[49] Jaebaek Seo, Daehyeok Kim, Donghyun Cho, Insik Shin, and Taesoo Kim. 2016.
FlexDroid: Enforcing in-app privilege separation in Android. In NDSS.
[50] Soot Framework 2017. Soot Analysis Framework.
[51] ssdeep 2017. ssdeep.
[52] The Hacker News 2017. Backdoor in Baidu Android SDK puts 100 million devices
at risk.
[53] The Hacker News 2017. Facebook SDK vulnerability puts millions of smart-
phone users’ accounts at risk.
[54] The Hacker News 2017. Warning: 18,000 Android apps contains code that spy on
your text messages.
[55] Nicolas Viennot, Edward Garcia, and Jason Nieh. 2014. A measurement study of
Google Play. In SIGMETRICS. 221–233.
[56] Haoyu Wang, Yao Guo, Ziang Ma, and Xiangqun Chen. 2015. WuKong: A scalable
and accurate two-phase approach to Android app clone detection. In ISSTA. 71–
[57] Yan Wang and Atanas Rountev. 2017. Who changed you? Obfuscator identifica-
tion for Android. In MobileSoft. 154–164.
[58] Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. 2014. Amandroid: A
precise and general inter-component data flow analysis framework for security
vetting of Android apps. In CCS. 1329–1341.
[59] Primal Wijesekera, Arjun Baokar, Ashkan Hosseini, Serge Egelman, David Wag-
ner, and Konstantin Beznosov. 2015. Android permissions remystified: A field
study on contextual integrity. In USENIX Security. 499–514.
[60] Wenbo Yang, Juanru Li, Yuanyuan Zhang, Yong Li, Junliang Shu, and Dawu
Gu. 2014. APKLancet: Tumor payload diagnosis and purification for Android
applications. In ASIACCS. 483–494.
[61] Wu Zhou, Yajin Zhou, Xuxian Jiang, and Peng Ning. 2012. Detecting repackaged
smartphone applications in third-party Android marketplaces. In CODASPY.