NativeGuard: Protecting Android Applications from

Third-Party Native Libraries

Mengtao Sun Gang Tan

Lehigh University Lehigh University
27 Memorial Drive West 27 Memorial Drive West
Bethlehem, PA 18015, United States Bethlehem, PA 18015, United States
[email protected] [email protected]

ABSTRACT a separate process. Furthermore, privileges of applications

Android applications often include third-party libraries writ- are controlled by a dedicated permission system.
ten in native code. However, current native components Android applications are mostly written in Java. Similar
are not well managed by Android’s security architecture. to desktop Java programs, Android supports the Java Na-
We present NativeGuard, a security framework that isolates tive Interface (JNI) and allows applications to incorporate
native libraries from other components in Android applica- native libraries. It is well known that in a conventional set-
tions. Leveraging the process-based protection in Android, ting, native code defeats Java’s security, as native code is not
NativeGuard isolates native libraries of an Android applica- covered by Java’s security model and has access to the entire
tion into a second application where unnecessary privileges address space. In Android, on the other hand, the story is
are eliminated. NativeGuard requires neither modifications different. First, previous studies (e.g., [6]) have shown low
to Android nor access to the source code of an application. utilization of native code in Android applications. Second,
It addresses multiple technical issues to support various in- process isolation, as the basis of security in Android, regu-
terfaces that Android provides to the native world. Exper- lates all application components above the kernel, regardless
imental results demonstrate that our framework works well of the programming language used in development. There-
with a set of real-world applications, and incurs only modest fore, it is generally believed that “native code is not perva-
overhead on benchmark programs. sive”, and that “native code is as secure as Java” in Android
applications. Hence neither researchers in academia nor en-
gineers in industry have paid much attention to native-code
Categories and Subject Descriptors security in Android.
D.4.6 [Software]: Operating Systems—Security and Pro- However, we believe Android’s defense against native threats
tection; D.2.12 [Software]: Software Engineering—Interop- is not as strong as it appears. Our survey (detailed in Section
erability 3) over the most popular Android applications shows that
native libraries are used pervasively in popular Android ap-
plications. Nowadays, applications tend to provide diverse
Keywords functionalities in order to take full advantage of cutting-
Android; Java Native Interface; Privilege isolation edge hardware in modern Android phones. Tasks like 3D
rendering and audio/video encoding have become extremely
common in popular applications, where third-party native
1. INTRODUCTION libraries are much more likely to appear. To make matters
Smartphones have been increasingly popular and widely worse, these third-party native libraries enjoy all permissions
adopted around the globe. Evolution and development of the user grants to the whole application, which is often un-
smartphones benefit from a large number of applications necessary and violates the principle of least privilege.
available in online stores such as Apple’s App Store for iOS Given the prevalence of third-party native libraries in pop-
and Google’s Google Play for Android. Apple adopts a con- ular Android applications, the question is how to limit native
fidential vetting process on all applications submitted to the libraries’ privileges so that the damage caused by malicious
App Store. On the contrary, Google has built a security or buggy third-party native libraries can be controlled. A
framework for Android that in general keeps its ecosystem natural idea is to design a framework in which native li-
secure and at the same time open and flexible. Each Android braries are privilege separated from the rest of the applica-
application is assigned a unique Linux user ID and runs in tion. Native libraries can have their own set of permissions,
different from the permissions used in Java code.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
For this purpose, we have designed NativeGuard, a frame-
for profit or commercial advantage and that copies bear this notice and the full citation work that utilizes Android’s process isolation to sandbox
on the first page. Copyrights for components of this work owned by others than the native libraries of an application. Generally speaking, Na-
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or tiveGuard improves Android’s security in the following two
republish, to post on servers or to redistribute to lists, requires prior specific permission aspects. First, NativeGuard separates native libraries con-
and/or a fee. Request permissions from [email protected]. tained within an Android application to another standalone
WiSec’14, July 23–25, 2014, Oxford, UK.
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
application, where native code does not have full access to
ACM 978-1-4503-2972-9/14/07 ...$15.00. the entire application address space and the interaction be-
http://dx.doi.org/10.1145/2627393.2627396.
tween native and Java code is fulfilled via Android’s in- application sandboxing and the permission system are two
terprocess communication (IPC) mechanism. Second, the key features.
native-library application is no longer granted all permis- System-level security: application sandboxing. An-
sions the original application possesses; therefore, there would droid utilizes the Linux kernel as the basis of security and
be much less damage if those libraries were exploited. isolation. In Android, each application runs as a unique
The main contributions of this paper are as follows: user with its own Linux user ID (UID). This design sets An-
• Our survey shows the prevalence of native libraries in droid apart from the traditional Linux system, and provides
popular Android applications, contrary to previous be- natural kernel-level sandboxing among applications: each
liefs. application stays within its own process boundary and does
• To the best of our knowledge, NativeGuard is the first not have the privilege to interact with other applications.
work on Android focusing on security threats of native Thanks to the kernel-level isolation, protection covers both
libraries. We addressed multiple technical challenges Java and native code.
in NativeGuard, involving the support of JNI function
calls and the accommodation of Android’s Native De- Application-level security: the permission model. As
velopment Kit (NDK) API. The framework takes ad- described earlier, applications on Android are sandboxed
vantage of the existing Android security architecture, and by default do not possess permissions to access security-
does not need special hardware or system support, and critical information and devices. In order to be privileged,
can be easily deployed to the current Android system an application has to declare its necessary capabilities and
without much pain. gets user approval upon installation. Most permissions are
• We evaluated the prototype of NativeGuard over both checked when sensitive APIs are invoked, which is the only
the most prevalent Android applications today and way an application could access corresponding protected re-
industrial-strength benchmark programs, which fully sources. There are also a few permissions enforced by the
demonstrated its practicality and efficiency. Linux kernel. Moreover, applications may define custom
We stress that, in NativeGuard’s threat model, an applica- permissions to limit interactions with other applications.
tion’s Java components are trusted, while the application’s It is worth mentioning that under the current Android
native libaries are untrusted. We are mainly concerned with permission model, permissions obtained by an application
the scenario in which an Android developer incorporates a apply to all of its components. It is not possible to grant
third-party native library into her application, treats it as a permissions to only part of the application.
black box, and blindly assigns all permissions of the applica-
tion to the library. Through NativeGuard, the developer can 2.2 The Java Native Interface
assign a much smaller permission set to the native libraries The Java Native Interface (JNI) [13] is a framework al-
and as a result security is improved. Clearly, the Java com- lowing Java programs to interoperate with native libraries.
ponents of an application could be malicious as well. But In Java, the native keyword is used to declare native meth-
malicious applications are a well recognized threat and de- ods. The following code snippet of the PlasmaView class
fenses have been proposed in many other studies. We instead is extracted from a sample of the Android NDK, which de-
focus on the security of native libraries. The threat model clares a native method renderPlasma. Once declared, native
of NativeGuard will be detailed later in the paper. methods can be invoked in the same way as ordinary Java
The rest of the paper is organized as follows. We first methods. In the example, the onDraw Java method invokes
introduce the background of Android security and the JNI renderPlasma.
interface in Section 2. In Section 3, we show the prevalence
of native libraries in popular applications and explain how public class PlasmaView {
Android controls their security. Section 4 is an overview of ...
NativeGuard, followed by Section 5, where we describe the private Bitmap mBitmap;
isolation achieved by the framework, as well as several tech- protected void onDraw (Canvas canvas)
nical challenges and our solutions. We present in Section 6 { long time_t = ...;
our prototype implementation and experimental evaluation. renderPlasma(mBitmap, time_t); ...;}
In the end, we discuss related work, future work and con-
clude. private static native void renderPlasma
(Bitmap bitmap, long time_ms);

2. BACKGROUND: JNI AND ANDROID static {System.loadLibrary(‘‘plasma’’);}

}
In this section, we present a high-level overview of the
Android architecture and its deployed security mechanisms. A native method is implemented in a native language,
We also introduce the necessary background about the Java such as C, C++, or assembly. Native code may also use
Native Interface. JNI functions to interact with Java. Through these JNI
functions, native code can inspect, modify, and create Java
2.1 Android Security Overview objects, invoke Java methods, catch and throw Java excep-
Android is a software framework designed for mobile de- tions, and so on.
vices. It is built upon an adapted Linux kernel and supports In Android, the NDK includes a cross-compilation toolchain,
Applications written in Java. Similar to desktop Java pro- which helps generate libraries from native code. It also pro-
grams, they are also allowed to contain native modules. An- vides a collection of APIs and system libraries that facil-
droid provides a set of security mechanisms to maintain the itate developers to perform various tasks from traditional
security of user data and system resources. Among them, libc function calls to OpenGL-based 3D graphics rendering.
 Category Apps Apps with Percentage their contents or popularity. As an example, Zhou et al.
native libs collected 204,040 applications from various online stores and
Social 7 7 100% reported native code deployment rate of 4.52% in total [31].
Communication 5 4 80% However, the majority of the applications may not be in-
Gaming 19 18 95% stalled and used by most smartphone users: according to
Entertainment 2 2 100% statistics shown in Google Play in November 2013, the No.1
Other 17 12 71% application in the chart has accumulated almost a billion
Total 50 43 86% installs, while the application ranking 300 shows less than
500,000 installs in total, which is approximately only 0.05%
Table 1: Top 50 Applications and Their Use of Na- of the top application. Second, the computing power in
tive Libraries. smartphones today has increased dramatically. Users are ex-
pecting more powerful applications and breathtaking games
right in their palms. Hence, applications tend to be more
3. NATIVE CODE IN ANDROID: THE CUR- sophisticated with more features and the possibility to in-
RENT SITUATION corporate native libraries increases.
In this section, we first present a small-scale study with 3.2 Deployed Security Mechanisms
a focus on the most popular applications on Google Play,
As introduced in Section 2.1, two core defenses are de-
which helps us better understand the use of native libraries
ployed in Android: the application sandbox and the permis-
in popular applications. Then we summarize how current se-
sion model, which cover both Java and native code. We next
curity mechanisms in Android confine the behavior of native
take a closer look at each of them, with a focus on how the
libraries.
protection extends to native code.
3.1 Trends and Statistics First, the application sandbox builds upon the Linux user-
based process protection, covering everthing running above
Native libraries are often treated as black boxes or simply
the kernel, regardless of the language being used. Different
trusted in past security research. In general, only a small
from a traditional Java Virtual Machine, where native code
portion of Android applications contain native libraries. A
is not covered by the Java security manager, native com-
previous study showed that native libraries are found in less
ponents in Android stay within the context of a particular
than 10% of the total applications inspected [6]. However,
application and cannot read/write other applications’ data
this reflects only part of the story.
or files or perform privileged tasks, unless granted necessary
More smartphone applications nowadays are about social
permissions.
networking, sharing, and entertainment. Social networking
Second, the permission model ensures that only applica-
and gaming applications are among top categories that have
tions with necessary permissions may access resources that
been used by most users. Since native libraries are often
may harm users’ privacy or lead to unexpected result if vis-
used to perform CPU-intensive tasks such as image filter-
ited or used improperly. The permission model extends to
ing, pixel rendering, audio/video encoding/decoding, which
native code in the following two aspects:
are common features provided by social applications, or are
• Most security-sensitive system resources are accessed
frequently performed in cellphone games, we expect native
via Android API functions, which native code does
libraries to be much more likely to appear in popular appli-
not have direct access to. Native code may instead
cations.
invoke Java methods through JNI’s method-invocation
To confirm this hypothesis, we investigated into those top
functions, in which permissions are enforced.
applications: We downloaded the application package files
• For those resources that are not wrapped by the API
(APKs) of the top 50 applications from the “Top Free in An-
functions, they are controlled by Linux groups [7]. In
droid Apps” chart in Google Play in November 2013, which
these cases, the Linux kernel takes care of the per-
are the most popular Android applications at the time, re-
mission checking when the underlying system calls are
gardless of their contents or categories. We then unpacked
invoked.
those APK packages and collected statistics on their usage
of native libraries.
We identified 200 native libraries in total, showing an av- 4. DEFENSE OVERVIEW
erage of 4 native libraries per application. Table 1 presents In this section, we discuss the threat model of NativeG-
the statistics. The first two columns show that according uard, as well as defenses it provides. Technical details are
to the categorization in Google Play, applications in social, left to Section 5.
communication, gaming, or entertainment categories con-
tribute to about two thirds of the applications in the Top 50 4.1 Threat Model
ranking. Among them, native libraries are pervasive: almost As shown in the survey, native libraries are prevalent in
all applications falling in those categories carry at least one popular Android applications. Oftentimes, they are incor-
native library. Even in other categories such as music/audio porated to fulfill some fixed and repeating tasks, such as
or shopping, more than half of the applications inspected in- file compression, 3D rendering, and audio/video stream de-
clude native libraries. In fact, only 7 out of 50 applications coding. Rather than implementing the functionalities from
surveyed are written solely in Java. scratch, application developers often tend to utilize exist-
Our survey results and some previous studies (for exam- ing third-party native libraries, and connect them to their
ple, [6, 31]) may seem contradictory. This can be explained Java code via a small amount of glue code upon neces-
by the following reasons. First, previous studies collected sity. For instance, we have identified the same photo edit-
large numbers of applications without paying attention to ing library (namely, libaviary_native.so) that appears in
several popular social and photography applications. The Java Area
Sandbox A
downside, on the other hand, is the potential security threats Permission Set !"
brought by third-party native components: although devel-
opers can improve the quality of their work through careful Stub Library
Process Boundary
examination and thorough testing, they cannnot fully trust
arbitrary third-party binaries. Service Trampolines
Despite Android’s security mechanisms discussed in the Sandbox B
Permission Set !#"
previous section, native libraries still pose serious threats Native Area
$!#!!%"
to the application and system security. At a high level, our
threat model puts an application’s Java components into the
Trusted Computing Base (TCB), together with the rest of Figure 1: Overview of the isolation.
the system, while focusing on the security of native code.
The threat model is justified by the following reasons:
• In the context of Android, native libraries are inher- tion. In addition, if native libraries are separated from an
ently not as safe as Java components. First, devel- application with permissions P , where P is the set of permis-
opers have no control over third-party native libraries sions granted to the application at install time, then native
they incorporate: in most cases these third-party com- libraries are jailed in another sandbox with permissions P ′ ,
ponents appear as black boxes with only documented where P ′ ⊆ P . That is, native code has only a subset of the
interfaces. Second, native libraries are the weak link original permission set. In fact for most applications, as is
of an application because native languages are more shown in Section 5 and Section 6, P ′ = ∅.
prone to various vulnerabilities due to their lack of After separation, the process that holds native libraries
basic safety mechanisms, such as type checking and can communicate with the Java process through the JNI in-
bounds checking. terface, which unfortunately was not designed with security
• A large amount of research work has been performed in mind. One worry is that malicious native code might
to either strengthen Android’s security mechanisms or misuse the JNI interface to cause integrity or confidential-
mitigate security threats (e.g., [5, 27, 29]). Unfortu- ity violations. For example, native code can issue JNI calls
nately, they do not deal with the security of native to modify fields of Java objects with values of incompatible
code. By concentrating on native code security, our types, which corrupts the integrity of the Java process. For
work complements related Android security research. another example, native code can forge a Java reference and
In NativeGuard, we focus on the following two ways through issue a JNI call that uses the reference to read any mem-
which buggy or malicious native libraries may compromise ory in the Java process. This violates confidentiality. To
the safety and security of the application or the Android prevent such violations, NativeGuard strengthens the JNI
system. interface by performing runtime type checking when JNI
• Native libraries in an Android application reside in the functions are called. This guarantees that native code, even
same address space as the rest of the application and if malicious, can perform only type-preserving modification
therefore have access to the entire address space of the of the Java process and can read the Java process’s memory
application sandbox. Native code, once exploited, may through only the set of references passed from Java. This
potentially access/modify any data within the process type safety guarantee is the same as what Robusta [21] pro-
boundary, leading to possible privacy violation or ap- vides to a conventional Java Virtual Machine.
plication malfunction. One concern about process-based isolation is the perfor-
• As per Android’s permission model, once granted, per- mance overhead brought by context switches and interpro-
missions are applied to the entire application. Native cess communications. However, we believe it should work
modules possess the same privileges and may possibly with most Android applications after a careful analysis of
abuse system resources, resulting in leak of confidential the Android NDK and usage patterns of most cellphone ap-
information or unexpected results. plications. First of all, based on the official document of
the NDK [8], native code should be used only on tasks that
perform CPU-intensive operations and that do not consume
4.2 Defenses Provided much memory, where context switches are not expected to
In order to defend against the listed threats, native code occur frequently. Moreover, most applications today follow
needs to be insulated from the rest of the application, and a user-driven model, where interactions with users are fre-
should run without unnecessary permissions. In NativeG- quent and are the dominant factor in the application life-
uard, we utilize the natural process boundary provided by cycle. Hence, we consider that the idea of process isolation
the underlying Linux kernel in Android to isolate untrusted would not incur significant overhead most of the time. We
native code. Figure 1 depicts the isolation at a high level. present evaluation and performance data over benchmark
As the basis of isolation, native libraries are relocated to a programs in Section 6.
second sandbox besides the original one. The native-code
sandbox runs in a separate process, so native libraries no
longer have direct access to the rest of the original appli- 5. SANDBOXING NATIVE LIBRARIES
cation. To support ordinary native method calls and JNI In NativeGuard, native libraries are put into another sand-
function calls, a stub library and a set of service trampo- box with limited permissions so that their security is con-
lines are introduced, which hide implementation details of trolled by Android’s existing security mechanisms. We have
interprocess communication (IPC) from the original Java different choices of implementing this sandbox.
and native code. Following this design, there is no need to (1) Isolating native code in a second process within the same
retrofit application code: IPC is transparent to the applica- application. By default, all components in one applica-
 tion run in one process. Yet Android does allow one ap- modifies the launcher class(es) (shown in dashed boxes in
plication to have multiple processes by supporting the Figure 2) to achieve the separation. Next we elaborate sev-
android:process attribute in the manifest file of the eral key components in the architecture.
application. It would be clean if native libraries run in Modified launcher activities. Similar to the main method
another process but still stay in the same application as of a Java program, the launcher activity is the starting exe-
the rest of the code and resource files. However, this cution point of an Android application. A callback method
idea would not work with the current Android system, of the activity named onCreate is automatically invoked by
where permissions are enforced at the application level. the system when the application is launched. To ensure
Modifications to the underlying permission enforcement that the service application starts together with the client
implementation would be inevitable, which would hin- and the client is bound to it after launched, NativeGuard lo-
der NativeGuard from working directly with current An- cates the onCreate callback method in the application and
droid smartphones. adds necessary code so that when launched, the client proac-
(2) Isolating native code in a second application. In another tively binds to the service by sending out an intent. In
approach, native libraries are moved to an entirely new order to keep NativeGuard working with arbitrary applica-
service application running alongside the original one, tions, where source code is not always available, we inject
the client application. The disadvantage is that the crafted Dalvik bytecode sequences with the help of apktool,
two applications have to be installed together, and there a widely-used reverse engineering tool for Android applica-
is no way to explicitly enforce any correlation between tions. We leave the implementation details to Section 6.
them. The benefit, on the other hand, is the compati-
bility with current Android systems. By putting native Proxy native libraries. Since Java components and na-
libraries into another application with less permissions, tive libraries are put into two different applications, those
this approach sandboxes untrusted native libraries with- Java components no longer have direct access to native li-
out requiring any modification to the system. braries. NativeGuard’s solution is to introduce a level of
In the end, we chose the latter approach to keep Native- indirection through a layer of trusted proxy libraries. For
Guard a portable solution. Figure 2 shows the architecture each native library, there is one proxy library with the same
of NativeGuard at a high level. An Android application name. Proxy libraries are put in the client application and
is separated into two: the client application, which holds provide implementations for exactly the same native meth-
the Java side of the original application, and resource and ods as the original ones. The implementation of a native
user-interface files for interacting with users; and the ser- method in a proxy library invokes an appropriate AIDL in-
vice application, which takes the native libraries. The two terface method, which uses the IPC to invoke the corre-
applications interact via interfaces defined by the Android sponding native method in the service application. This
Interface Definition Language (AIDL) and the application level of indirection keeps changes transparent to Java code.
holding native libraries acts as a service. It runs in the The AIDL interface for native method calls. An AIDL
background and responds to requests from the client. Extra interface is defined for native methods and is exposed to the
code is generated to support functionalities including native client application. After the client is bound to the service,
method calls, JNI function calls, NDK API invocation, and native code in proxy libraries may invoke the corresponding
service application initialization. IPC method through the JNI interface. For each native
We next present the detailed design of NativeGuard in method, there is one AIDL interface method implemented
four steps: (1) a brief overview of AIDL; (2) a closer look at on the service side. When the method is invoked, binder
the components and the workflow of NativeGuard; (3) how IPC code generated by the SDK copies the arguments to
JNI function calls are handled across process boundaries; the service process and calls the implementation in the end.
and (4) various technical issues concerning the NDK APIs.
Stub libraries. Calling an AIDL interface method tran-
sitions the control flow to the service application. Eventu-
5.1 AIDL Overview ally the intended native method by Java code should be in-
AIDL is an interface definition language that defines the voked. NativeGuards adds another layer of stub libraries for
interface through which IPC is performed between a client the purpose of maintaining a proxy table of JNI functions.
and a service. AIDL follows Java’s syntax. By defining the The reason for this layer is the following. JNI passes object
AIDL interface in an .aidl file and implementing neces- references to native methods as opaque references. Those
sary interface methods, Android application developers can references, however, no longer make sense when passed to
easily utilize Android’s IPC to marshall objects or perform another address space and need to be “properly translated”
remote method calls across processes. Specifically, the An- upon dereference. The proxy JNI function table redirects
droid software development kit (SDK) takes the interface JNI calls back to the client application where opaque ref-
definition and generates a stub class in Java, which extends erences could be correctly resolved. Details regarding stub
the Binder class, the core part of RPC support in Android. libraries as well as the proxy JNI function table are presented
Developers then write code to extend the stub class and pro- in Section 5.3.
vide the actual implementation of interface methods. Then
The AIDL interface for JNI and NDK API calls.
the interface is exposed to clients for IPC.
As mentioned in the previous paragraph, JNI calls in sand-
5.2 Native Code Separation boxed native libraries are redirected back to the client pro-
cess, which requires another AIDL interface for the neces-
Given an Android application’s APK package, NativeG- sary IPC. Similarly, the implementations of some NDK API
uard separates native libraries in the application and the functions cache low-level pointers to objects and manipulate
rest into two applications. In addition, it generates several them directly in native code; they also call for the IPC to
AIDL interfaces and auxiliary native libraries, and slightly
 Original Application
Launcher Activities Other Classes / Rsc

Native Libraries

Client Application Service Application

Declaration of Declaration of AIDL Impl. of AIDL Interface
Impl. of AIDL Interface AIDL Interface Interface for for Native Calls
for JNI / NDK Calls for Native Calls JNI / NDK Calls

Modified Launcher Activities Other Classes / Rsc

Stub Libraries

Proxy Native Libraries Native Libraries

Figure 2: Architecture of NativeGuard.

interact with objects in the client process. Another set of in the Zlib library calls GetFieldID to obtain the JNI iden-
AIDL interface methods are hence provided for this purpose. tifier of a field.
More details are discussed in Section 5.3 and Section 5.4, re-
JNIEXPORT void JNICALL
spectively.
Java_java_util_zip_Inflater_initIDs
We next walk through the basic process of native code iso-
(JNIEnv *env, jclass cls){
lation in NativeGuard using a native method example from
...
libjni_filtershow_filters.so, a widely-deployed native
jfieldID strmID =
library for photo editing. The example we present is image-
(*env)->GetFieldID(env, cls, ‘‘strm’’, ‘‘J’’);
FilterVibrance_nativeApplyFilter, a native method that
...
applies the vibrance effect to a photo. The first step is to ex-
}
tract the original library and replace it with a proxy library.
The proxy library contains a proxy function for each native- In the above code, GetFieldID returns the identifier of
method implementation. The second step is to write/gener- the field “strm” in the Inflater class, which can later be used
ate mandatory components shown in dashed boxes in Fig- to read from or write to the field. Note that the first two
ure 2, put them in the two new applications, build and de- parameters of a native-method implementation are special:
ploy them respectively. The following steps outline what a JNI interface pointer, and a reference to the Inflater object
happens when the user starts the instrumented application or the Inflater class in the case of static native methods,
from the device. similar to this pointer in C++ or Java. The cls bolded in
(1) When the application is launched by the user, the client the code above is the reference to the Inflater class.
application is started first, which sends out an intent. After NativeGuard’s isolation, the implementation of ini-
The service application starts and responds to the in- tIDs is migrated to the service application. Hence when in-
tent. The client is then bound to the service. voked, cls in initIDs becomes the reference to the service
(2) When the application loads the native library, it loads class and is no longer the one that it is expecting.
the proxy version of libjni_filtershow_filters.so As briefly discussed in the preceding section, NativeG-
on the client side. uard’s solution is to introduce a stub library between the
(3) When the imageFilterVibrance_nativeApplyFilter na- Java code and the real native libraries in the service appli-
tive method is invoked, the control transfers to the proxy cation. The stub library maintains a proxy JNI interface
method. The proxy method performs a function call to pointer structure in the service application, but with func-
the corresponding AIDL interface method. tion pointers to the AIDL interface methods for JNI func-
(4) When the AIDL interface method for imageFilterVi- tions. When the stub function calls the real target function
brance_nativeApplyFilter is called, the control trans- (the last step discussed in Section 5.2), it passes the proxy
fers to the service application. The service application JNI interface pointer to the corresponding native library.
loads the stub library if it is not yet loaded and performs Hence, when native code in the isolated library invokes a
a native method call to the corresponding stub function. JNI function via the proxy interface pointer, the control is
(5) The stub function takes over the control and (a) uses transferred to an AIDL interface method, which performs
dlopen to load the real library in the service process if IPC and jumps back to the client application and the real
it has not been loaded; (b) uses dlsym to find the ad- JNI function is called. Note that opaque references must
dress of imageFilterVibrance_nativeApplyFilter in be retained so that correct objects could be retrieved when
the real library; and (c) performs a function call to the JNI function calls are redirected back to the client applica-
real target function. tion. In the example above, the value of cls is mandatory
to find the field ID and thus cannot be lost. In NativeGuard,
5.3 Supporting JNI Calls one more argument is added to the AIDL interface methods
Native code may use JNI functions to manipulate Java ob- for native method calls. When a proxy method calls to the
jects or call Java methods. For instance, the following native AIDL interface (step (2) in Section 5.2), it passes in this
method initIDs extracted from class java.util.zip.Inflater reference value. The reference is kept all the way down to
the native code in the service application so that all JNI droid_runtime, a system native library in Android. Since
calls within this context could be properly handled back in our purpose is to isolate untrusted, third-party native li-
the client application. braries, system libraries are considered trusted. Hence, when
The benefit of this design is threefold. First, isolated na- a native library is isolated in the service application and tries
tive code still follows the same syntax for invoking JNI func- to modify a Bitmap object via the NDK API, its behavior
tions and thus need not be aware of the isolation. Second, cannot be predicted, because the pointer cached can only be
only references are marshalled across processes, not Java interpreted in the client application and does not point to a
objects. This brings down the overhead caused by IPC as valid object in the service application.
object marshalling is very expensive. Also it makes the solu- To support these NDK API function calls after isolation,
tion source-code free, as reference marshalling in AIDL does NativeGuard intercepts an API invocation and marshalls re-
not depend on the implementation details of objects. Last, lated objects to the service application before the real API
no global references are necessary in the proxy libraries on function is run. For instance, if a sandboxed native library
the client side, as JNI function invocations in the service ap- invokes the libjnigraphics API, NativeGuard provides a
plication always stay within the context of a native-method fake libjnigraphics in the service application, which uti-
call, where local references are valid during the period. lizes the dedicated AIDL interface to transport the Bitmap
In addition, the proxy JNI interface provides a natural object from the client before calling the real API function.
place for performing runtime type checking on the JNI. As Correspondingly, updated Bitmap objects are marshalled
we have discussed, misuse of the JNI interface by the na- back when native code finishes its work on the pixels, specif-
tive code can cause confidentiality and integrity violations. ically, when it calls AndroidBitmap_unlockPixels, the API
Therefore, NativeGuard performs checks in the proxy JNI function that indicates the end of the native modification.
interface to ensure type safety of JNI calls. The implementa- We next make a few clarifications. First, we can easily
tion of these checks follows previous JNI checking systems, marshall Java objects like the Bitmaps as long as they sup-
including Arabica [22] and Jinn [12]. We omit a detailed port the Parcelable interface, which allows the system to
description. decompose objects into primitives that can cross the process
boundary. If not, then we have to implement the Parce-
5.4 Supporting NDK API Function Calls lable protocol for the object on our own, which may or
may not be difficult, depending on the composition of the
Ideally, native libraries interact only with Java code: they
object. Second, not all NDK libraries encounter the situa-
are not dependent upon each other albeit belonging to the
tion discussed in this section. Our prototype implementa-
same Android application. In this case, it is sufficient to
tion provides support for libjnigraphics, the library we
support only the JNI interface in our framework as native
discussed earlier, and the OpenSL ES native audio library.
libraries perform computation tasks and only communicate
with the rest of the program via the JNI interface. The re-
ality, however, is different when a few special NDK libraries 5.5 Managing Native Code Permissions
are involved. The basic idea of limiting privileges of native code in Na-
The NDK provides a set of API functions for native code tiveGuard is to better use the Android permission mech-
to fulfill various tasks. Besides traditional libc support, the anism. Following the principle of least privilege (POLP),
API also includes headers of OpenGL libraries for 3D ren- native libraries are isolated in another application with only
dering, libjnigraphics headers for bitmap pixel manipula- the minimum mandatory permission set granted. We next
tion, and so on. As a simple example, native code may discuss how the POLP principle is enforced in NativeGuard.
invoke AndroidBitmap_lockPixels implemented in libjn- Based on the guideline of the NDK and how native code
igraphics to grab the lock on a Java Bitmap object and is managed under current Android framework, we infer that
acquire a pointer to the pixel buffer of the object, through native code itself seldom requires any permission. First
which direct access to pixels is supported. In fact, many of all, the NDK may only be beneficial when used with
applications and libraries provide photo filter functionalities self-contained libraries that perform CPU-intensive opera-
based on API functions in libjnigraphics, including lib- tions [8], which are not likely to access system resources or
jni_filtershow_filters.so, the example library we intro- devices protected by permissions. Second, native code is not
duced in Section 5.2. allowed to interact directly with the system API and must
It turns out that in some NDK libraries, manipulation call back to Java via the JNI interface to visit protected re-
on Java objects is directly performed via native pointers, sources [7]. In this case, permissions are enforced on the API
rather than through the JNI interface. In these cases, Java calls, not native libraries; JNI function calls do not require
objects are only “wrappers” of native data structures, which any permission either. The only circumstance under which
are allocated in native methods implemented in system na- native code does require permissions is when native code di-
tive libraries. In the above example, the underlying im- rectly accesses system resources not protected by the system
plementation of AndroidBitmap_lockPixels first calls Get- API. For instance, a native library may open and write to a
IntField to obtain the value of an integer field, specifically, file on the SD card without calling back to Java, and hence
mNativeBitmap in the Java Bitmap object, then casts the requires the WRITE_EXTERNAL_STORAGE permission itself.
integer to a SkBitmap pointer, through which the Bitmap To the best of our knowledge, there is no official document
pixels can be directly modified. By further tracing down the or previous research that sheds light on how native func-
calling sequence, we find that the Bitmap object is created tions, library calls or NDK APIs are connected to the per-
by calling a native method nativeCreate, which (1) allo- mission model. Intuitively, native code’s access to protected
cates a new SkBitmap object; (2) casts the pointer value to resources is fulfilled by system calls and the permission check
an integer; and (3) caches the integer to the mNativeBitmap is performed in the Linux kernel. But it is hard to decide
field. nativeCreate, however, is implemented in liban- whether a system call requires an Android permission as it
 AppOriginal.apk slight modifications to the launcher classes. Apktool can un-
apktool
pack an APK file into resources and smali code, a human-
readable format for the Dalvik bytecode, where the basic
AndroidManifest.xml Java Bytecode Other Resources Native Libraries information of the program, such as method names and na-
objdump tive method signatures, is available. It can also rebuild them
NDK Libs Needed into an APK file after some modifications. Second, we in-
Launcher Classes Other Classes corporate the objdump from the NDK toolchain, which can
Native Methods
Signatures dump an Android native library built by the toolchain to
reveal information regarding library dependency. The main
Code Generator
steps of the separation process are as follows.
(1) Apktool unpacks the input APK file.
ClientApp.apk ServerApp.apk
(2) The AndroidManifest.xml file is parsed to locate launcher
class(es).
Figure 3: Workflow of the Application Separator. (3) All smali files are analyzed to record signatures of native
methods.
(4) Native libraries are dumped to record the dependency
may be dependent on its parameters. As a simple example, to NDK libraries.
the system call open requires the WRITE_EXTERNAL_STORAGE (5) Based on information collected above, the code genera-
permission when opening a file on the SD card with the write tor generates extra AIDL interfaces and library code. It
access, but requires no permission when opening a private also adds mandatory smali code to the launcher class(es)
file of the application or opening a file on the SD card with for service binding.
the read-only access. Furthermore, since NativeGuard aims (6) In the end, two applications are built as the output.
to defend threats of untrusted native libraries in arbitrary NativeGuard is implemented in Java and is comprised of
Android applications from online stores, where source code about 2,000 lines of Java code and about 20 template files
of the native libraries is not available, it is even harder to for fast code generation. In addition, it incorporates apktool
find the minimum permission set efficiently solely from the 1.5.2 and objdump from the NDK Revision 8c. We choose
binary. Java as the implementation language because the package
Hence, we decide to follow a heuristic approach and by installer in Android is written in Java. Therefore, Native-
default grant no permission to the service application in Na- Guard can be incorporated into the package installer in the
tiveGuard. The approach is motivated by the observation future, which provides users a completely transparent solu-
that it is rare for legal native code to perform privileged tion for native code isolation.
operations, as it is a “bad practice” according to the NDK.
In fact, as we will present in Section 6, the heuristic works 6.2 Evaluation
with all real applications that NativeGuard has been tested We carried out a three-stage evaluation to fully test Na-
on (around 30 applications). On the other hand, the draw- tiveGuard’s functionality and performance. First, we cre-
back is that the approach does not support native code that ated an illegal native library that abuses granted permis-
requires privileged access to the devices. As a remedy, Na- sions to test the effectiveness of NativeGuard’s defense. Af-
tiveGuard also supports a configuration file through which a terwards, NativeGuard was tested on dozens of applications
developer can manually grant permissions to native libraries. in various categories that are among the most downloaded
applications in Google Play. For performance testing, it was
6. IMPLEMENTATION AND EVALUATION evaluated both on a representative benchmark suite and on
In this section, we first present the prototype implemen- a hand-crafted benchmark program. Experiments were con-
tation of NativeGuard. Then we discuss its evaluation, on ducted on a Nexus 4 smartphone running Android 4.3. All
both benchmark programs and real-world applications. performance numbers were averaged over 10 runs.
Functionality testing. We have manually created a test
6.1 Prototype Implementation native library, which directly accesses the location informa-
The thrust of this project, as we have discussed, is to de- tion of a phone without going through the Java side (assum-
sign a framework that isolates untrusted native libraries in ing the application has been granted the location-access per-
Android applications downloaded from online stores. Hence, mission). In Android, most system resources are protected
we implemented NativeGuard as an “application separator”, by privileged Java API methods, which are implemented in
which takes as input an APK package and generates two a trusted system process [7]. A typical native library has
APK files: the client and the service applications. As pre- to invoke the corresponding API method through method-
sented in Section 5, the client contains Java bytecode and invocation functions in JNI in order to access the privileged
other resources from the original application, the service iso- resource. In contrast, our test native library directly talks
lates native libraries and by default does not require any to the system process and obtains the location information
permission. In addition, NativeGuard also supports a con- without going through the Java API.
figuration file, where permissions can be manually granted The test library demonstrates that malicious native code
to the service application upon separation. can take advantage of permissions that are not really needed
Figure 3 shows the separation process in NativeGuard. to cause security violations. NativeGuard can improve this
At a high level, NativeGuard is composed of a code genera- situation. For the test native library, we used NativeGuard
tor, and two third-party tools. First, we utilize apktool [1], to isolate it into a service application with no permissions
an open-source tool for Android application reverse engi- and thus its access to the location information was denied
neering, to extract native-method information and to make due to lack of permissions.
 Benchmark Size of Data Set Overhead Buffer Size Overhead Context Switches
jpeg 20 KB 17.16% (per millisecond)
lame 177 KB 1.12% 1KB 183.13% 31.89
2585 KB 0.87% 2KB 107.49% 25.98
tiff2bw 6662 KB 7.83% 4KB 55.02% 18.51
27873 KB 2.08% 8KB 34.36% 9.81
tiff2rgba 6662 KB 3.14% 16KB 26.64% 3.96
27873 KB 0.54%
tiffdither 2223 KB 14.37% Table 3: Extreme-case runtime overheads on the
9303 KB 1.40% Zlib benchmark application.
tiffmedian 6662 KB 5.11%
27873 KB 2.32%
In general, NativeGuard shows moderate overheads on
Table 2: Runtime overheads on MiBench bench- MiBench programs. The benchmarks all utilize native li-
marks. braries to perform CPU-intensive operations, such as im-
age compression and conversion, and thus do not frequently
make context switches. The result table also confirms the
Real-world applications testing. We collected a total correlation between the overhead and the context switch in-
of 30 applications from the official Google Play store to tensity: programs on large data sets show less performance
test NativeGuard’s functionality on real applications. The overheads, as they stay longer in the service application be-
applications are collected from different categories and are fore switching back. Since native libraries in MiBench pro-
on the “top” charts of the store in November 2013. Note grams are representative candidates for the Android NDK,
that tested applications are not strictly the overall top 30 NativeGuard is promising to incur modest overhead on iso-
ones, as we intended to exercise our framework on applica- lating a majority of native libraries in popular applications.
tions providing diverse functionalities and containing differ- Another important factor to evaluate on mobile devices
ent native libraries. Our framework succeeds on 28 out of is the overhead posed on memory and storage, which are
30 applications. It fails on two applications because of the both limited resources on smartphones. Although for an
apktool, which fails either in the disassembling stage be- application with native libraries, users with NativeGuard
fore separation or in the assembling stage after separation. now have to keep two applications running simultaneously,
Applications after separation are tested manually, as exist- the increase of memory utilization turns out to be moderate:
ing automatic testing tools that generate random inputs are NativeGuard introduces only 11.81% of memory overhead on
not sufficient for our purpose. Since we want to make sure the ported MiBench application, according to data reported
the native libraries are loaded and used during testing, it is by Android’s dumpsys tool. Moreover, NativeGuard shows
much safer to just manually play with the instrumented ap- a tiny 130KB increase on the size of the application, being
plications and exercise various functionalities provided. For only 7.11% of the original.
example, some applications require signing in before using But what if the isolated library does make frequent con-
any meaningful functions. In these cases, automatic testing text switches? To further understand the performance of
frameworks are more likely to fail in exercising native code. NativeGuard in extreme cases, we carried out another set of
During our testing, we could perceive slightly longer re- hand-picked benchmark programs. The programs compress
sponse delays in some applications and use cases. For ex- a medium-sized file stored on the device using the popular
ample, photo filters may take extra time to render a pic- Zlib library. When the user presses the start button on the
ture. But in general, NativeGuard introduces acceptable user interface, the Java side of the application divides the
overhead and does not affect the functionalities delivered by file into data segments of smaller sizes and passes a data
the applications. Details regarding evaluated applications segment through a buffer to Zlib, which performs the com-
are presented in Appendix A. pression and returns the result to the Java side. Then the
Java side passes the next segment of data. Hence, when the
Performance evaluation. For a security framework uti-
Zlib library is sandboxed, the size of the buffer is strongly
lizing process isolation, the runtime overhead of NativeG-
correlated to the performance overhead, as a smaller buffer
uard depends greatly on the intensity of context switches,
results in more frequent context switches between Java and
e.g. the frequency of IPC. If isolated native libraries are
native code. We conducted experiments with different buffer
typical “good candidates” for the NDK and do not involve
sizes and the results are presented in Table 3.
lots of context switches, the overhead caused by NativeG-
As shown in the table, the runtime increase of NativeG-
uard should be small.
uard on the Zlib benchmark demonstrates the similar trend:
We first evaluated NativeGuard on MiBench [9], a free and
as the buffer size increases, the performance overhead de-
open-source benchmark suite for embedded systems. The
creases. The performance penalty can be as high as near
suite provides six categories of benchmark programs for dif-
two times when extremely intense context switch happens.
ferent purposes in real-world applications, and testing data
In summary, the experiments demonstrate that the ap-
sets of various sizes. MiBench is not Android-ready. We
proach of process isolation brings security to untrusted na-
picked several benchmarks under the Consumer category (a
tive code, and with modest overhead on most real-world ap-
category for consumer devices, like PDAs and smartphones)
plications where context switches between Java and native
and ported them to Android. Table 2 presents the results.
code are not frequent.
7. RELATED WORK 19]), application repackaging and malware detection (e.g., [30,
We next discuss related work in two categories: techniques 24]), and privilege escalation attacks (e.g., [14, 15]). Though
for sandboxing untrusted components from a trusted envi- in a different context, AdSplit and AFrame are in spirit sim-
ronment, and previous studies on Android security. ilar to our framework, as they isolate advertising libraries
into separate processes [20, 28]. To display both the ad-
Untrusted code isolation. It is always desirable to iso- vertisement and the host application on the screen after
late untrusted code to prevent uncontrolled access or mali- separation, AdSplit follows an emulation approach to al-
cious compromise to the trusted environment and there have low two activities to share the screen, while AFrame sup-
been various approaches. Language-based isolation ensures ports embedded activities. Both of them require changes to
the security of untrusted code by utilizing static types [17] the system. In comparison, NativeGuard isolates native li-
or object-capability models [16, 11], but it is tied to a spe- braries into a service application that does not interact with
cific language. Isolation based on virtual machines regu- the user, avoiding unnecessary modifications to the Android
lates untrusted code by building a safety-oriented platform framework. Moreover, a number of systems have been de-
(e.g., [3]), which is a clean solution but incurs severe perfor- signed to improve the permission system’s granularity and
mance penalty. In comparison, NativeGuard utilizes hardware- flexibility (e.g., [18, 32]). These studies increase the power
based process isolation, which has long been used in various of the permission model, but requires changes to the system.
operating systems to isolate untrusted components [4, 23]. They also risk overprompting users to make security-related
Process isolation suffers from high performance overhead decisions. By contrast, our framework reuses the current
with frequent interprocess communication, but can provide permission model, where users still receive the same infor-
flexible and robust isolation if used with clever optimiza- mation when installing applications.
tions. For instance, Codejail isolates untrusted libraries into
a jailed process and incurs acceptable overhead on libraries
that are tightly coupled with the main program [26]. 8. FUTURE WORK
With regard to sandboxing untrusted native code in for- Some parts of NativeGuard can be improved. The next
eign function interfaces, NativeGuard is similar to several step is to incorporate NativeGuard into the Android package
previous frameworks. Klinkoff et al. designed a system installer. NativeGuard is currently implemented as a com-
that sandboxes unmanaged native code in the .NET frame- mand line tool, which genereates APK packages according
work [10], but relies on a kernel add-on module to control to user commands. If integrated into the Android package
system calls in untrusted code. Robusta adopts software- installer, it would bring conveniece to end users; they can
based fault isolation (SFI) [25] and puts native libraries in download, isolate native libraries, and perform installation
Java programs into an SFI sandbox [21]. In terms of per- in a streamlined process.
formance, it compares favorably to other sandboxing frame- We also plan to explore techniques that efficiently de-
works thanks to SFI, but relies on nontrivial modification to cide the minimum permission requirement of native binaries.
the internal of a Java Virtual Machine. Arabica improves Currently our framework relies on a heuristic, which worked
Robusta and achieves JVM-portability through clever use well in our multistage evaluation, but cannot support legiti-
of the Java Virtual Machine Tool Interface (JVMTI) [22], mate libraries that do require permissions. Since native code
which, unfortunately, is not available for the Dalvik Virtual may directly access some system resources through system
Machine on Android. On the contrary, NativeGuard reuses calls, it would be a good starting point to build a permission
Android’s permission model and does not need support for map to connect system calls to permission requirements.
special interfaces or plug-ins, hence is ready to deploy on
any Android system.
9. CONCLUSIONS
Android safety and security. As the most widely-adopted
smartphone OS worldwide, Android has attracted much at- Although the Android platform has a sophisticated secu-
tention from academia in recent years. A couple of empirical rity architecture for Java code, native libraries are uncon-
studies provided more complete view of Android application trolled. Given the increasing popularity of Android devices
security and its permission model. For example, Enck et al. and insufficient research, native libraries pose pressing chal-
designed a Dalvik decompiler ded and performed analysis on lenges to the security of the Android ecosystem. In this pa-
1,100 Android applications [6]. Their work produced many per, we have proposed NativeGuard, a security framework
findings, some of which might lead to ways of exploiting that isolates native libraries into a non-privileged applica-
Andrioid. Felt et al. established a mapping between the tion. NativeGuard requires no change to the Android sys-
Android API and the permissions, and shed light on the tem, nor does it require access to an application’s source
pervasive overprivilege problem in Android applications [7]. code. It incurs modest runtime overhead on tested real-
PScout utilizes static analysis to further improve the com- world applications, in which interprocess communication is
pleteness of the mapping and reveals the state of the art in not intensive. We believe that our study is a good starting
newer Android versions [2]. Their work is a strong motiva- point for future security research on native code in Android.
tion of NativeGuard as many applications are overprivileged
with security-critical permissions, which are not needed by Acknowledgments
native libraries. Recent studies have presented various sys-
tems (e.g., TaintDroid [5] and VetDroid [29]) to detect user We thank anonymous referees of WiSec ’14 for detailed com-
privacy and information leaks, which increased the overall ments on an earlier version of this paper. This research is
security of Android, but left native libraries unmonitored. supported by US NSF grants CCF-1217710, CCF-1149211,
Much work has been performed to address various aspects and a research award from Google.
of Android security, for example, advertisements (e.g., [20,
10. REFERENCES
 [1] android-apktool. [21] J. Siefers, G. Tan, and G. Morrisett. Robusta: Taming the
https://code.google.com/p/android-apktool/. native beast of the JVM. In 17th CCS, pages 201–211, 2010.
[2] K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie. Pscout: [22] M. Sun and G. Tan. JVM-portable sandboxing of Java’s
Analyzing the android permission specification. pages native libraries. In 17th European Symposium on Research
217–228, 2012. in Computer Security (ESORICS), pages 842–858, 2012.
[3] R. S. Cox, S. D. Gribble, H. M. Levy, and J. G. Hansen. A [23] M. M. Swift, M. Annamalai, B. N. Bershad, and H. M.
safety-oriented platform for web applications. In IEEE Levy. Recovering device drivers. In USENIX Symposium on
Symposium on Security and Privacy (S&P), pages Operating Systems Design and Implementation (OSDI),
350–364, 2006. pages 1–16, 2004.
[4] J. R. Douceur, J. Elson, J. Howell, and J. R. Lorch. [24] T. Vidas and N. Christin. Sweetening android lemon
Leveraging legacy code to deploy desktop applications on markets: Measuring and combating malware in application
the web. In USENIX Symposium on Operating Systems marketplaces. In Proceedings of the Third ACM Conference
Design and Implementation (OSDI), pages 339–354, 2008. on Data and Application Security and Privacy, CODASPY
[5] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, ’13, pages 197–208, 2013.
P. McDaniel, and A. N. Sheth. Taintdroid: An [25] R. Wahbe, S. Lucco, T. Anderson, and S. Graham. Efficient
information-flow tracking system for realtime privacy software-based fault isolation. In ACM SIGOPS
monitoring on smartphones. In USENIX Symposium on Symposium on Operating Systems Principles (SOSP),
Operating Systems Design and Implementation (OSDI), pages 203–216, New York, 1993. ACM Press.
2010. [26] Y. Wu, S. Sathyanarayan, R. H. Yap, and Z. Liang.
[6] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A Codejail: Application-transparent isolation of libraries with
study of android application security. In 20th Usenix tight program interactions. In 17th European Symposium
Security Symposium, pages 21–21, 2011. on Research in Computer Security (ESORICS), pages
[7] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner. 859–876, 2012.
Android permissions demystified. In 18th CCS, pages [27] Z. Yang, M. Yang, Y. Zhang, G. Gu, P. Ning, and X. S.
627–638, 2011. Wang. Appintent: Analyzing sensitive data transmission in
[8] Google. Android ndk. http: android for privacy leakage detection. In 20th CCS, 2013.
//developer.android.com/tools/sdk/ndk/index.html. [28] X. Zhang, A. Ahlawat, and W. Du. AFrame: Isolating
[9] M. Guthaus, J. Ringenberg, D. Ernst, T. Austin, advertisements from mobile applications in Android. In
T. Mudge, and R. Brown. Mibench: A free, commercially Proceedings of the 29th Annual Computer Security
representative embedded benchmark suite. In Workload Applications Conference, 2013.
Characterization, 2001. WWC-4. 2001 IEEE International [29] Y. Zhang, M. Yang, B. Xu, Z. Yang, G. Gu, P. Ning, X. S.
Workshop on, pages 3–14, 2001. Wang, and B. Zang. Vetting undesirable behaviors in
[10] P. Klinkoff, E. Kirda, C. Kruegel, and G. Vigna. Extending android apps with permission use analysis. In 20th CCS,
.NET security to unmanaged code. Internation Journal of 2013.
Information Security, 6(6):417–428, 2007. [30] W. Zhou, X. Zhang, and X. Jiang. Appink: Watermarking
[11] A. Krishnamurthy, A. Mettler, and D. Wagner. android apps for repackaging deterrence. In 8th ACM
Fine-grained privilege separation for web applications. In Symposium on Information, Computer and
Proceedings of the 19th International Conference on World Communications Security, pages 1–12, 2013.
Wide Web (WWW ’10), pages 551–560, 2010. [31] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. Hey, you, get
[12] B. Lee, M. Hirzel, R. Grimm, B. Wiedermann, and K. S. off of my market: Detecting malicious apps in official and
McKinley. Jinn: Synthesizing a dynamic bug detector for alternative android markets. In Network and Distributed
foreign language interfaces. In PLDI, pages 36–49, 2010. System Security Symposium(NDSS), 2012.
[13] S. Liang. Java Native Interface: Programmer’s Guide and [32] Y. Zhou, X. Zhang, X. Jiang, and V. W. Freeh. Taming
Reference. Addison-Wesley Longman Publishing Co., Inc., information-stealing smartphone applications (on android).
1999. In Proceedings of the 4th International Conference on
[14] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. Chex: Statically Trust and Trustworthy Computing, pages 93–107, 2011.
vetting android apps for component hijacking
vulnerabilities. pages 229–240, 2012.
[15] T. Markmann, D. Gessner, and D. Westhoff. Quantdroid:
APPENDIX
Quantitative approach towards mitigating privilege A. EVALUATION OF APPLICATIONS
escalation on android. In IEEE International Conference
on Communication, pages 2144–2149, 2013. Detailed information about applications evaluated in Sec-
[16] A. Mettler, D. Wagner, and T. Close. Joe-E: A tion 6 is shown in Table 4. Notice that a “*” besides the
security-oriented subset of Java. In Network and version number or the size of an application indicates that
Distributed System Security Symposium(NDSS), 2010. the version or the size of that application varies with differ-
[17] G. Morrisett, D. Walker, K. Crary, and N. Glew. From ent devices, and the number shown in the table is the one
System F to typed assembly language. ACM Transactions for our testing device and system. There is no information
on Programming Languages and Systems, 21(3):527–568,
May 1999.
for native libraries in PlayKids, because apktool fails to dis-
[18] M. Nauman, S. Khan, and X. Zhang. Apex: extending assemble the application. For DJ Studio 5, we include its
android permission model and enforcement with native libraries and dependencies in the table, but apktool
user-defined runtime constraints. In 5th ACM Symposium fails to rebuild the application after disassembling. Further
on Information, Computer and Communications Security, experiments show that the failure is not resulted from the in-
2010. strumentation of NativeGuard, as apktool fails to build the
[19] P. Pearce, A. P. Felt, G. Nunez, and D. Wagner. Addroid: application even without any change after disassembling.
Privilege separation for applications and advertisers in
android. In 7th ACM Symposium on Information,
Computer and Communications Security, 2012.
[20] S. Shekhar, M. Dietz, and D. S. Wallach. AdSplit:
Separating smartphone advertising from applications. In
21th Usenix Security Symposium, 2012.
Category App Version Size Native Libraries Needed
NDK Libraries
Photography Snap Camera HDR 2.1.4 5.3M libjni eglfence.so
libjni filtershow filters.so libjnigraphics.so
libjni mosaic.so
Photo Editor by Aviary 3.1.1 10M libaviary moalite.so
libaviary native.so libjnigraphics.so
libexif extended.so
Photo Editor 1.3.13 1.9M libIUDeskImageFilter.so libjnigraphics.so
libIUDeskJpegCodec.so libjnigraphics.so
Social Snapchat 4.0.20* 7.5M* libphotoeffect.so libjnigraphics.so
ooVoo 2.0.4 21M libovmedia-v7a.so libjnigraphics.so
libGLESv2.so
Badoo - Meet New People 2.27.3* 19M libScanPay.so
Communication WhatsApp Messenger 2.11.109 11M libframeconv.so
AntiVirus Security 3.4.2.1* 9.5M* libdeng.so
Handcent SMS 5.3 6.0M libhccommon.so
libmms2gif.so
libspeex.so
Tools Brightest Flashlight Free 2.4.1 1.2M libndkmoment.so
GO Keyboard 1.9.11 5.3M libMFtInput.so
Android Terminal Emulator 1.0.53 456k libjackpal-androidterm4.so
Shopping eBay 2.5.0.31* 10M* libredlaser.so
Walgreens 4.1 18M libaviary moalite.so
libaviary native.so libjnigraphics.so
libexif extended.so
Out of Milk Shopping List 4.1.6* 8.9M* libscanditsdk-android-3.4.0.so
Games Pou 1.4.8 16M libsonic.so
Farm Story: Thanksgiving 1.9.6.3 16M libs8.so
Cartoon Camera 1.99 1.0M libgpuimage-library.so
Business Box 2.3.0* 11.3M* libleveldb.so
Call Blocker 4.2.46.20 3.9M libNqCrypto.so
Olive Office Premium (free) 1.0.89 19M libchmjni.so
libpdfjni.so libjnigraphics.so
Books & Reference Cool Reader 3.1.2-34 6.7M libcr3engine-3-1-0.so libGLESv1 CM.so
Audible for Android 1.5.3* 9M* libAAX SDK.so
Ancestry 2.2.335* 5.7M* libNativeTreeViewer.so
Education Mathway 1.0.3 13M libmonodroid.so
PlayKids 1.1.1 17M N/A N/A
Music & Audio iHeartRadio 4.10.0* 7.7M* libaacarray.so
Bandsintown Concerts 4.3.2.1 10M libdeezer.so
DJ Studio 5 5.0.8 11M libaudio-jni.so
Lifestyle AroundMe 4.2.4 5.2M libcountry-database.so

Table 4: Separated applications and their information.