2
in the Android application framework or system libraries. For
example, Saint [48] implements a monitor and embeds it in Android
Activity Manager Service (AMS) to control inter-component
communication (ICC). For analyzing malware, the analyst also
needs to effectively inspect the execution of underlying system
components in addition to the target applications themselves. Take
the dynamic taint analysis (DTA) [52], a mainstream malware
analysis technique, as an example. For a DTA tool, it is necessary
to effectively monitor the sensitive information propagated via
system libraries. It requires introducing the taint tracking feature in
the underlying system components, e.g., to employ an instrumented
Dalvik virtual machine to track sensitive data [42].
However, Android has more stringent security restrictions than
desktop platforms. Particularly, to avoid privilege abuse and prevent
interference between applications, root privilege is not granted to
end users; and every application is executed within its process
sandbox. The underlying system components files are also stored
in special folders, which are non-writable for users. Unfortunately,
it poses an obstacle for deploying security enhancement approaches.
Without root privilege, it is impossible to rewrite or replace the
original system components files. This substantially hinders the
adoption of many security enhancement efforts.
To overcome the obstacle, most exiting studies employ the
following two ways. The first way (employed by TaintDroid [42]
and Saint [48]) is to integrate the Android source tree (including
the framework source code) with the security enforcement code,
and compile the modified source code into a new system image
for flashing to devices. It involves a complex series of steps, and
is at the risk of bricking devices. The second way (employed by
PatchDroid [46]) is to root the device and inject the security
enforcement code into the address space of the target application
process. It compromises system integrity, and may cause severe
hazard if the root privilege is abused [30]. In practice, it is rather
difficult for normal users to accept either approach.
It should be noted that a few attempts have been made to enforce
application-wide security features without flashing or rooting
devices. Aurasium [56] can enforce a fine-grained permission
policy on an Android device. The global offset table (GOT) of the
target application process is rewritten, so that calls to critical libc
functions can be intercepted and validated by the security
enhancement code. However, it is very difficult, if not impossible,
to enforce an in-depth security enhancement only by intercepting
calls, such as repairing a vulnerable function or analyzing the
execution of an underlying function. A recent work, Boxify [35],
proposes a novel technique to enforce privilege separation policies.
Untrusted applications are securely encapsulated in an isolated
sandbox provided by Boxify. In this way, Boxify can intercept
and mediate IPCs and system calls of the untrusted applications
without modifying the Android system. Although Boxify is more
applicable and powerful than Aurasium, its capability is still limited
to enforcing function-call-level protection policies. AppCaulk [51]
is used to prevent information leakage with taint tracking code
instrumented into target applications. Instead of actually tracking
the information flow via the underlying system library methods,
AppCaulk directly sets the taint tags of their outputs according to
a pre-generated summary. In this way, AppCaulk avoids modifying
the underlying system files. However, compared with actually
tracking the execution of methods, this summary-based approach
is not precise enough, and may introduce high false positives and
false negatives. Besides, computing the method summary is error-
prone and requires substantial human efforts.
Based on the above discussion, how to practically enforce in-
depth security enhancements in system components without
flashing or rooting devices remains an important open challenge.
In this paper, we propose a novel technique, called reference
hijacking, to take control over the reference of the target
application to the underlying system components. Specifically, we
implement a specially designed environment reset procedure,
which will be triggered when launching the target application. The
reset procedure can reconstruct a new execution environment for
the target application such that it can load the system class libraries
and native libraries from any places instead of the default folders.
Consequently, the reference of the target application to system
components can be redirected to the security-enhanced alternatives
without modifying the original protected system files. It allows us
to conveniently introduce additional security features into the
underlying system components on an unmodified and non-rooted
device. We have evaluated the technique on some prevalent off-
the-shelf devices, which involve almost all mainstream Android
versions from 2.2 to 5.0, and cover both Dalvik and the Android
RunTime (ART) environments. The evaluation results show that
this technique can work well on all tested devices, and introduces
small launch time delay (described in Section 2).
To further demonstrate the capability of our technique, we also
design and implement three prototype systems for enforcing
specific security enhancements on unmodified and non-rooted
Android devices. The first one, PatchMan, is for patching the
vulnerabilities of system components. By leveraging reference
hijacking, the patched system class libraries and native libraries
can be provided for the target application to replace the vulnerable
ones. The second one, ControlMan, is for enforcing a flexible
access control policy on inter-component communications, similar
to Saint [48]. According to a given policy, ControlMan can monitor
and invalidate the incoming and outgoing ICC communications of
the target application. The access control module is embedded in
the copies of system libraries, which will be used to replace the
original libraries for the target application via reference hijacking.
The third one, TaintMan, is for performing DTA analysis for the
target application just like TaintDroid [42]. The taint tracking
code is instrumented into both the target application and the
system libraries. With the help of reference hijacking, sensitive
information flow involving the underlying libraries can also be
effectively tracked and analyzed. The related experiments results
show that all of them are effective and efficient, and can be
directly deployed on the off-the-shelf Android devices (described
in Section 3~5 respectively).
Although in theory it is impossible to directly introduce a
comprehensive system-wide security mechanism on off-the-shelf
devices without adjusting the basic Android architecture. The
reference hijacking technique does provide a totally effective
solution to adopt in-depth security enhancements for applications
of interest. We believe that this study has made an important step
to improve the practicability of a large body of security enhancement
efforts for Android.
In summary, our two main contributions are the following.
We present reference hijacking, a practicable technique for
introducing security enhancements without flashing or rooting
Android devices. It has been shown to work well on both
Dalvik and ART runtime environments and on almost all
mainstream Android versions (2.2 to 5.0).
We develop three prototype systems to enforce specific
security enhancements based on reference hijacking, involving
patching vulnerabilities, enforcing ICC access control, and
performing DTA analysis for the target application. These
systems have been successfully deployed on popular Android
devices from different manufacturers. The related evaluation
results show that they are effective and do not introduce any
noticeable system overhead.