1

A Systematic Study of Android Non-SDK

(Hidden) Service API Security
Yi He, Yacong Gu, Purui Su, Kun Sun, Senior Member, IEEE, Yajin Zhou, Member, IEEE,
Zhi Wang, Member, IEEE, Qi Li, Senior Member, IEEE

Abstract—Android allows apps to communicate with its system services via system service helpers so that these apps can use
various functions provided by the system services. Meanwhile, the system services rely on their service helpers to enforce security
checks for protection. Unfortunately, the security checks in the service helpers may be bypassed via directly exploiting the non-SDK
(hidden) APIs, degrading the stability and posing severe security threats such as privilege escalation, automatic function execution
arXiv:2203.09374v1 [cs.CR] 17 Mar 2022

without users’ interactions, crashes, and DoS attacks. Google has proposed various approaches to address this problem, e.g.,
case-by-case fixing the bugs or even proposing a blacklist to block all the non-SDK APIs. However, the developers can still figure out
new ways of exploiting these hidden APIs to evade the non-SDKs restrictions. In this paper, we systematically study the vulnerabilities
due to the hidden API exploitation and analyze the effectiveness of Google’s countermeasures. We aim to answer if there are still
vulnerable hidden APIs that can be exploited in newest Android 12. We develop a static analysis tool called ServiceAudit to
automatically mine the inconsistent security enforcement between service helper classes and the hidden service APIs. We apply
ServiceAudit to Android 6∼12. Our tool discovers 112 vulnerabilities in Android 6 with a higher precision than existing approaches.
Moreover, in Android 11 and 12, we identify more than 25 hidden APIs with inconsistent protections; however, only one of the
vulnerable APIs can lead to severe security problem in Android 11, and none of them work on Android 12.

1 I NTRODUCTION the sake of stability and security, Google has restricted [4]
the usages of the hidden APIs by proposing a graylist
Android has a modular binder-based inter-process commu- includes the APIs which are available now but will be
nication (IPC) architecture that allows third-party apps to disabled in future versions, and a blacklist includes the APIs
access many important functionalities of Android system which are blocked now. Unfortunately, this restriction have
services, e.g., telephony, notification, and clipboard. Nor- been broken by the developers as soon as it appears. Even
mally, apps can access these system services via the service in the newest Android 12, developers have proposed several
helper classes which encapsulate the origin service IPC APIs methods to evade the hidden APIs restriction and there are
which are hidden to the developers. As shown in Fig. 1, still some apps [12] try to exploit various blacklist hidden
these service helpers are loaded into the app’s address APIs.
space as a runtime library (framework.jar) and developers are
Exploit the System
required to only use the public APIs exposed by the Android Service via
SDK (android.jar) to build their apps. However, previous App Code Hidden APIs

work [46] shows that it is prevalent for the developers to

directly exploit the non-SDK (hidden) APIs (includes inter- Android
Framework
nal and private APIs) in framework.jar via Java reflection for Service Helpers
the requirements of developing or hacking. This may lead to
serious stability problems [11], [46] when the hidden APIs SDK API Hidden API

are changed in new Android versions but these Apps do not ... ...
adapt to the new APIs in time, as well as security problems App
due to service helpers bypassing, especially when these Process

residual APIs are not well maintained and have inconsistent Binder IPC
security enforcements [17], [33], [39]. Since Android 9, for Service
Processes System Services

H. Yi and Q. Li are with Institute for Network Sciences and Cyberspace and
Beijing National Research Center for Information Science and Technology, Ts-
inghua University, Beijing, e-mail: {heyi21@mails., qli01}@tsinghua.edu.cn Fig. 1. Developers can bypass the service helpers by exploiting the
Y. Gu and P. Su are with Institute of Software, Chinese Academy of Sciences, hidden APIs to access system services.
China 100190, e-mail: {guyangcong, supurui}@tca.iscas.ac.cn.
K. Sun is with Center for Secure Information Systems, George Ma-
son University, 4400 University Drive, Fairfax, VA 22030-4422, e-mail: The hidden API restriction is significant to Android’s
[email protected]. app development ecosystem. Since the Android framework
Y. Zhou is with Institute of Cyber Security Research, Zhejiang University, APIs change dramatically in every version, the hidden APIs
China 310058, email: [email protected]. are also involved. Only a few of the hidden APIs can be
Z. Wang is with Department of Computer Science, Florida State University,
FL 32306, email: [email protected]. promoted to permanent public APIs [46] and most of them
This paper is extended from the previous conference paper [39]. are removed in the newer versions. The hidden APIs are
 2

not stable to the developers and building apps on these analysis approaches to discover more security enforcements
temporary hidden APIs can lead to serious compatibility and significantly improved the precision. Specifically, to
issues. Moreover, some hidden APIs without proper secu- keep up with the changes of the Android framework, we
rity enforcement may be abused by malicious apps. Thus, modified ServiceAudit to support newest Android 12
Google discourages the developers to directly exploit the and tracked if vulnerable hidden APIs in an earlier Android
hidden APIs [11] and propose a blacklist to block these version can still be exploitable in newer versions.
APIs. In Android 12, there are about 495 thousand APIs in Our Findings. In Android 6, ServiceAudit has di-
the framework.jar with only 12% of them are public to the covered 112 vulnerabilities with more than 32 exploitable
developers provided in the Android SDK (android.jar), and ones. In Android 11 and 12, less than 27 vulnerabilities
over 249 thousand APIs (50%) are blocked by the hidden are reported and most of them seem to have no harm. In
APIs restriction policy. The hidden APIs can be used to ac- particular, only one of them can incur security problems
cess system resources and some of them can invoke system on Android 11 and are immediately fixed by Android 12.
service via IPC. For the hidden APIs which invoke service To understand why the vulnerabilities are eliminated, we
IPC interfaces, it is quite common for them to lack security perform case studies to check if the former vulnerable APIs
checks e.g. permission checking, input validation, and caller can still be attacked. We find that Google has successfully
authentication, and lead to inconsistent security enforce- addressed almost all of them by manually adding extra
ment. Existing works, such as Kratos [49] and AceDroid [17], checks to system service. We further study if the blacklist
have discovered these kinds of problems in the public APIs can make the hidden APIs more secure and find that the
of multiple Android SDK versions. Our previous work [39] attackers have no incentive to exploit these APIs by evading
indicates that this problem also widely exists in the hidden the hidden APIs restriction.
APIs which invokes service interfaces via IPC calls. Google
has taken measures to mitigate this problem since 2017 and 2 BACKGROUND
put most of the hidden APIs into blacklist since Android 9.
Non-SDK APIs are hidden to developers and only acces-
Nevertheless, taking the huge number of hidden APIs, it is
sible to the system code. However, developers can easily
extremely difficult for Google to eliminate this problem by
utilize these methods. Since Android 9, Google has pro-
fixing all the buggy hidden APIs. In the newest Android 12,
posed a blacklist policy to gradually limit the usages of
developers can still exploit the hidden APIs after bypass-
these APIs and prevent the knowing hidden API exploiting
ing the blacklist policy. Considering these developers can
approaches. In this section, we first introduce the concept
actually use all the APIs in the framework.jar rather than just
of the hidden APIs and service helpers. Then we illustrate
use the public API in android SDK, therefore, the vulnerable
Google’s hidden API restriction policy.
hidden APIs may still be exploitable.
In this paper, we focus on the non-SDK service API
security and the effectiveness of the hidden API blacklist 2.1 Android Hidden APIs and Service Helpers
policy in newest Android versions (e.g., Android 10 ∼ 12). Android apps are built on Android SDK (provided by
The hazards of exploiting hidden APIs has been also studied android.jar) during development and run on the Android
in previous research [33], [39], [52]. Zeinab et al. [33] study framework (provided by framework.jar) on real devices. The
the access control vulnerabilities in residual APIs that are Android SDK only contains the public APIs that are open
erratically added or removed among different Android SDK to the developers while the non-SDK APIs, aka Hidden
versions. Our previous work [39] focuses on discovering APIs, are the inaccessible [46] methods of Android frame-
inconsistent security enforcement between service helper work that do not expose to developers but are used by
classes and the service implementations. We found that the framework itself or the system apps. Android adopts a
exploiting hidden APIs can bypass all security enforcement Binder based IPC architecture and provides AIDL [6] files to
in service helpers and the attackers can perform various at- automatically generate the IPC server methods (IPC.stub)
tacks, e.g., bypassing the access control checks, sending fake and the IPC client methods (IPC.proxy). System services
identities or parameters to exploit vulnerable system ser- implement the IPC server methods and custom code need
vices, or sending duplicate requests to perform DoS attacks. to invoke these methods via the IPC client code. As a part of
Invetter [52] addresses a similar issue. However, it focuses the Android SDK, service helpers encapsulate the complex
on detecting only a narrow type of input validation. Since origin IPC client code and provide easy-to-use interfaces
during the evolution of Android framework, some of the for apps to access the IPC methods of system services,
vulnerable hidden APIs may be removed or mitigated by e.g., automatically feed in function parameters for invoking
Google via enforcing the security checks. We seek to answer the origin service APIs. To protect system services against
whether the newest Android has eventually eliminated the attacks, the corresponding service helpers also implement
exploitable inconsistent security enforcement vulnerabilities some security mechanisms to validate the requests from
in hidden service APIs. apps before issuing an IPC call to the system services.
To achieve this goal, we perform a thorough security As shown in Fig 1, normally, developers only need to
analyze on Android 10, 11, and 12, to detect if there are use the SDK APIs and access the System services via service
inconsistent security enforcement in hidden APIs and if helpers. However, once an App is installed and executed,
these APIs are blocked by blacklist. We propose a new the Android framework is loaded to the same process as
static analysis tool ServiceAudit to automatically dis- the App’ user code. Therefore the App can actually access
cover APIs without insufficient security enforcement. Com- all the framework APIs including non-SDK APIs in frame-
pared to our previous approach [39], we have adopted new work.jar via Java reflection or using a custom Android SDK
 3

App Process
Service Helper
Service Process
Parameter
Check
Parameter
Benign Use Service Helper API Identity Check
Code Check
Binder Identity System
Other No-SDK Hidden
IPC Check Service
Checks IPC API
API
Other
Bypass Security Enforcements Via Hidden API Checks
Malicious
Code
Inconsistent Checks

Fig. 2. Attackers can invoke the hidden APIs to bypass the security enforcements and sanity checks for the arguments in service helper APIs.

file that contain all the internal methods of the Android users’ interactions, system service crash, or DoS attacks. To
framework [7]. Supposing the system service side’s security better understand these hazards, we use real examples from
enforcement is not as robust as the service helper [39], [52], AOSP to illustrate the root causes and exploiting methods
as shown in Fig 2, the attackers can directly use hidden APIs of these vulnerabilities.
to exploit the system services without enough protection to
bypass all the security enforcements in service helpers’ side 3.1.1 Privilege Escalation and Privilege Leakage
and perform their attacks, e.g., DoS, privilege escalation. For some service API, the access control checks are only ap-
plied on the service helpers’ side. Once the attackers exploit
2.2 Google’s Hidden APIs Restriction Policy the service API directly, they can bypass all the checks in
service helpers and perform privileged operations without
The non-SDK APIs have been used widely by the develop- corresponding permissions. We also found some system
ers [46]. Since these APIs are changed rapidly among differ- services just use values (caller identity such as uid, pid, and
ent SDk versions, using these APIs may affect the stability package name) passed by the service helpers to perform
of apps and bring in security risks to the Android system. permission checks. Attackers can forge these identities by
Google does not expect developers to directly use them and invoking the hidden service API with fake parameters, e.g.,
proposes a blacklist policy to restrict the hidden APIs usages using the system app’s uid. Thus, these services are cheated
in third-party apps since Android 9 [4]. It is impossible to by the attackers to check the permission of the system app
block all the hidden APIs immediately, considering many of rather than the attackers’ app. The detailed attacks and the
them are already used by a larger number of apps. Google corresponding vulnerable code are as follows.
divided all the hidden APIs into three parts, the whitelist Evading the Operation Permission Checks. As shown in
APIs that can be normally used, and the graylist APIs Fig 3, the service helper checks the setup in WallpaperMan-
that can be used now but will be disallowed in the future, ager.peekWallpaperBitmap() and tests if an app is authorized
and the blacklist APIs that should not be used. That is to access the wallpaper data. However, this security check
to say, some of the vulnerabilities may still be exploitable in is only performed in the service helper. A malicious app
the newest Android if they are in the whitelist or graylist. can bypass the helper and directly invoke the hidden API,
Moreover, the attacker can even evade the blacklist [12] to i.e. WallpaperManagerService.getWallpaper(). Thereby, the app
invoke all the non-SDK hidden APIs (see Section 3.3). can read the wallpaper data even if its access to the data is
disabled by the system, which incurs private data leakage.
3 P ROBLEM S TATEMENT // in service helper
public Bitmap peekWallpaperBitmap(Context context,
The hazards of exploiting hidden service APIs have been boolean returnDefault) {
reported to Google since 2017 and Google have propose if (mAppOpsManager.checkOpNoThrow(
/*check operation condition*/) {
several measures to address these issues. In this section, return null;
we first introduce the hazards and the exploitation of }
the vulnerable hidden APIs. Then we summarize Google’s // ...
// attackers can exploit getWallpaper
countermeasures and the changes of newest Android. // directly via the following hidden API
return mService.getWallpaper();
}
3.1 The Hazards of Exploiting Hidden APIs
Fig. 3. Attackers can bypass the permission checks by directly invoke
To ensure security, reliability, and efficiency of system ser- the hidden service API.
vices, both the service helpers and the system service APIs
need to enforce various security mechanisms. However, Feeding Fake Identity to Service API. Let us take the
some security mechanisms may only be implemented on function of FingerprintService.authenticate() as an example,
the system service’s side and the corresponding service the service helper class of FingerprintService, i.e., Finger-
API does not check again for these enforcements. We have printManager, is responsible for automatically collecting
identified various vulnerability types in service APIs due and passing the caller’s package name to FingerprintSer-
to inconsistent security enforcement. As shown in Fig 2, vice.authenticate() is used to authenticate a given fingerprint.
attackers can exploit these vulnerabilities in various ways As shown in Fig 4, authenticate() verifies whether the caller is
and lead to privilege escalation, function execution without allowed to use fingerprint based on received package name.
 4

In canUseFingerprint(), it evaluates whether the caller is the services (e.g., ServiceManager) are attacked and crashed, the
current user or specified by the current user profile, whether whole system will shut down and reboot.
AppOps allows the operation, and whether the caller is Feeding Illegal Parameters. The HealthService service,
currently in the foreground. However, if the caller’s package which provides health related Bluetooth service, contains
name is of KeyguardService, the caller will be always allowed a vulnerability that can be exploited by passing illegal pa-
to use the fingerprint and thus the above restrictions will rameters. The method pairs, i.e., the service helper method
be bypassed (the red line). Unfortunately, authenticate() does BluetoothHealth.registerAppConfigeraton(String name, ...) and
not verifies the authenticity of received package names. the corresponding service method do not use the same
public void authenticate(/* other parameters */,
method to validate the parameters. The helper method
String pkgName) { checks the “name” parameter to make sure it is not null,
// the pkgName is passed by the service helper whereas the service method does not. The system service
if (!canUseFingerprint(pkgName, true)) { does not use the value of “name” parameter immediately
Slog.v(TAG, "authenticate(): reject " + in the IPC method. Instead, it stores the value and uses
pkgName);
return;
it in BluetoothHealthAppConfiguration.equals(). In equals(), it
} assumes that config.getName(), which returns the value of
// .... “name”, can never be null (see Fig 6). When a malicious
} app bypasses the service helper and registers a config with
boolean canUseFingerprint(String pkgName, boolean a null value in the “name” parameter, BluetoothHealthAp-
foregroundOnly) {
pConfiguration.equals() will generate a NullPointerExcetion.
// Keyguard is always allowed
if (pkgName.equals(mKeyguardPackage))
Unfortunately, this system service method fails to handle
return true; the exception, and hence the HealthService crashes.
}
// in service helper
public boolean registerAppConfiguration(String
Fig. 4. Attackers can use fake package name to invoke the hidden name, ...) {
service API. boolean result = false;
if (!isEnabled() || !checkAppParam(name, ...))
3.1.2 Bypassing User Interaction return result;
// ...
Some Android system services may be allowed only when BluetoothHealthAppConfiguration config = new
the callers, i.e., the app requesting the system service, are BluetoothHealthAppConfiguration(name, ...);
// ...
currently active in the foreground. By exploiting the hidden }
APIs, attackers can bypass all the operations in service // in service service
public boolean equals(Object o) {
helpers and silently invoke the system services without any // ...
foreground user interactions. BluetoothHealthAppConfiguration config =
Evading the Validation of Caller’s Status. To achieve (BluetoothHealthAppConfiguration) o;
// config.getName() can never be NULL
the goal, service helpers verify callers’ status before the return mName.equals(config.getName());
callers access the services. As shown in Fig 5, Nf- }
cAdapter, which is the service helper associated with sys-
Fig. 6. The package name is not validate again in system service.
tem service NfcService, confirms a caller’s status in Nf-
cAdapter.enableForegroundDispatch(). If the caller is not cur- Sending Duplicated Requests to Exhaust System Re-
rently active in the foreground, the registration request for source. As shown in Fig 7, an app can get a no-
using NFC listeners will be rejected. Attackers can trigger tification of the clipboard changes by registering a
this bug by directly invoking the setForegroundDispatch() listener to the system service ClipboardService.
method via Java reflection and thus can invoke the NFC ClipboardManager, which is the service helper associ-
function without user’s awareness. ated with ClipboardService, only registers the service
// in service helper once to get such a listener after receiving the first re-
void enableForegroundDispatch(Activity aty, quest. After that, ClipboardManager maintains a local
/* other paramters */) {
if (!aty.isResumed()) { listener queue. Any duplicated requests of registering lis-
throw new IllegalStateException(...); teners afterward will be only added to this queue locally.
} When the clipboard changes, ClipboardService noti-
// can be invoked via hidden API
sService.setForegroundDispatch(...);
fies its helper ClipboardManager about the change, and
} ClipboardManager notifies all the listeners in its local
queue. Thereby, the system services only allocate resources
Fig. 5. Attackers can bypass the status checks in service helper.
for one request generated by the app, and can still notify the
app when there is resource update.
3.1.3 Crash the System Service and DoS Attack Normally, multiple IPC requests generated from an app
The attackers can bypass all sanity checks in service helpers can only access a system service during the app’s lifetime
and send illegal parameters to the service API. Then the and are only allowed to consume limited system resources
system service helper may crash due to unhandled excep- of memories, CPU time, and file descriptors. Therefore,
tions. Also, the attackers can send many IPC requests to if a system service accepts many duplicated requests, the
the resource creating service APIs to exhaust the system resources may be exhausted. To prevent resources from
resource and perform DoS attackers. Specifically, if the core being exhausted by duplicated requests, service helpers con-
 5

private static final int MAX_ACTIVE_LOCKS = 50;

real uid from Binder.getCallingUid() (in resolveNotificationUid
// in service helper
public void acquire() {
function). Another example is the IPC flood vulnerability.
mService.acquireMulticastLock(mBinder, tag); The root cause is that attackers create too many Binder
if (mActiveLockCount >= MAX_ACTIVE_LOCKS) { objects in the core system process and make the JNI global
mService.releaseWifiLock(mBinder) reference table overflowed. Google fixed the problem by
throw new Exception("Exceeded maximum modifying the native code and limited the number of the
number of wifi locks"); Binder objects since Android 8, but they failed to thor-
}
oughly fixed all the JNI global object leakage [42].
// ...
} Block The Hidden APIs. Google has set a blacklist filter in
Java reflection methods to block the usages of these hidden
Fig. 7. The lock count is only checked in service helper classes. APIs since Android 9 [4]. However, there are still several
strain the frequency of local requests. For resource requests, ways to bypass the blacklist restrictions [12]. If the developer
service helpers restrict the number of calls that an app can downgrades their apps’ by using older SDKs, their app can
issue. If the number of IPC calls to a target process exceeds a still use the greylist APIs in the new version because
threshold, which can be treated as abnormal or unnecessary, Google needs to keep compatible with apps using these
the following calls will be dropped locally. When duplicated APIs. To address this problem, Google Play does not allow
requests are issued to register listeners, service helpers apps with such APIs to be published now.
initiate an IPC call to the remote system service to make Restrict Every System Services API with Common En-
it only receive the first request of the app. Unfortunately, forcements. The ideal solution to mitigate this problem
these security mechanisms enabled in service helpers can be is to automatically add a common security mechanism in
easily bypassed if a malicious app directly invokes hidden every IPC entrance method of the system services dur-
APIs of the system services. As shown in Fig 7, although ing the AIDL interface generating. The system service can
the count is protected (see green line) by the service helper, obtain the identity of Apps such as uid and package
the attackers can directly invoke the acquireMulticastLock to name from the Binder and double-check the parameters
create unlimited locks and make the system crash. The root from service IPC methods. In this way, system services
causes of these attacks have been fully discussed in [42], do not need to trust the identity from the client app side
[43]. and can get real identity. For each IPC method, the sys-
tem service needs to check the permission of the calling
3.2 Google’s Countermeasures in New Android Ver- uid via checkCallingPermission(). Currently, Google
sions does not apply these common caller checks to all the IPC
An obvious way to fix these bugs is to enforce the security functions but manually added checks in many places.
check on the system services’ side. However, there are many
corner cases, where the security enforcement cannot be
easily accomplished in the services, such as the security
3.3 Evade the Hidden API Blacklist
check with specific status or parameters (see Fig 5). Attacks
exploiting these vulnerable services are constructed via Though Google has taken measures to block the Java re-
hidden APIs and thus can be prevented by blocking these flection or directly calling to the Hidden APIs. Developers
hidden APIs, which is adopted by Google. Unfortunately, or hackers have evaded the hidden API blacklist as quickly
a number of hidden APIs have already been used in many as each new Android version [9], [12] is released. Since the
apps, and hence Google has to gradually include these APIs framework code is run in the same process of user code, the
into the blacklist in several versions. Now we summarize addresses of all the Java and native methods of framework
the countermeasures adopted by Google in various versions. can be obtained by the attackers. Thus, the attackers can
void cancelNotificationInternal(String pkg, obtain the reference of the blacklist policy setting functions
String opPkg, int callingUid, int callingPid, (VMRuntime.setHiddenApiExemptions) from the app’s mem-
String tag, int id, int userId) {
// check uid, uid = Binder.getCallingUid(); ory space and just call it to remove the blacklist [9].
+ int uid = resolveNotificationUid(opPkg, The non-SDK APIs as a part of the Android framework
+ pkg, callingUid, userId);
+ if (uid == INVALID_UID) {
are widely used by other code of the framework.jar. Thus, it is
// ... inadvisable for Google to prevent the app code from calling
return; the hidden APIs by checking app identity in the system
} services’ side, e.g., disallow user app to invoke the hidden
// check package, opPkg =
component.getPackageName(); API IPC methods. As a result, Google has to implement
+ if (!Objects.equals(pkg, opPkg)) { blacklist restrictions in the framework code and run in the
// ... same process with the user app which leads to a dilemma,
+ throw new SecurityException("...");
}
the app process disallows some part of its code to access
the hidden APIs but other parts can access these APIs.
Fig. 8. Android 11’s mitigate code for the Notification vulnerability. Unfortunately, Android does not support in-app privilege
Ad-hoc bug fix. Google fixed the bugs one by one using isolation [44] and the remote services cannot distinguish
ad-hoc methods for some specific problems. As shown in whether the IPC requests are launched by the framework
Fig 8, in Android 11, Google fixed the cancel notification vul- code or app user code. Thus, the attackers can eventually
nerability by checking the real IPC callers by obtaining its break the blacklist from the memory via native code.
 6

4 I DENTIFY V ULNERABLE S ERVICE API and the corresponding service helper methods. The secu-
rity mechanisms in service helpers and the corresponding
To automatically identify the vulnerable service APIs in system services are normally implemented with different
different Android versions, we propose a new static anal- methods. Service helpers run in the same processes with
ysis tool ServiceAudit. In this section, we introduce the the third-party caller app, whereas system services run in
design of ServiceAudit. For each module, we illustrate its a separate system process. Therefore, we cannot simply
detailed design and its difference with existing approaches. compare the source code of security mechanisms in system
In particular, we highlight the methodology and technique services and their corresponding service helpers.
advancements of ServiceAudit comparing to our previ- To address these issues, we need to improve our ap-
ous approach [39]. proaches and accommodate the changes of new Android
versions. Compared to our previous approach [39], we have
rewrote the whole tool for higher precision, better perfor-
4.1 Approach Overview
mance, and more features for detecting new vulnerabilities.
ServiceAudit statically analyzes the Java bytecodes of the Also, we clarify the discrepancy between our works and
Android framework and finds out the inconsistent security existing approaches [17], [52].
mechanisms between service helpers and system services. It
operates in four steps, as shown in Fig 9. First, we extract
the full framework.jar which contains all the no-SDK hidden 4.2 Extracting Services IPC Methods
service APIs as the analysis target. Second, we extract ser- In this step, we mine out the service IPC methods and pair
vice IPC methods and classes, including both service helpers the service helper methods (which invokes the IPC.proxy
and system services. For each IPC method, we find out methods) with the corresponding system service methods
which service helper classes invoke it and then associate (IPC.stub method). Thus, we can further analyze the security
these classes with the corresponding system service class, enforcements of both sides of a IPC method.
which implements the IPC methods. Third, we build a Here we use a similar approach to our previous
method level call graph for each IPC method, which begins work [39] to extract the service IPC method pairs. For
with a service helper method and ends with the target IPC system service classes, we can identify them by analyzing
method. Then we mine security enforcement rules from the the services register invokes in com.android package.
calling paths from the call graph which indicates how a Since all services are registered in the service manager via
service helper method warps an IPC method. Thus, we can addService or publishBinderService, it is possible to
gain all the security enforcements on the service helper’s obtain these system services effectively via analyzing if the
side. For the system service method, we collect the security services have registered themselves using aforementioned
mechanisms by analyzing the methods called around the methods. Then we need to obtain the IPC methods of these
IPC.stub method. Finally, we enumerate all IPC methods system services, which can be extracted from the IPC.stub
and compare whether the security mechanisms enforced by classes. Note that some native services cannot be analyzed
service helpers are consistent with that in the corresponding and need to be manually verified in the vulnerability analy-
system service. If they are not consistent, we treat it as a sis phase.
potential vulnerability that may be exploited by attackers After this, we extract the service helper methods from
through bypassing the service helper. Specifically, we have the android package. We consider a class as a service
implemented several analysis patterns to identify different helper only when it has one or more methods that invoke an
types of security enforcements, e.g., patterns for identifying IPC method to invoke the system service. By enumerating
sanity checks, caller identity, IPC flood. After finding out all public classes in the Android SDK, we can filter out
the potential vulnerability, we need to manually evaluate the classes containing service IPC method calls which can
and confirm it since not all potential vulnerabilities can be be verified by the callee’s java class type, as a service IPC
exploited in practice. class should have implemented both IBinder interface and
It is non-trivial to identify the inconsistent security en- IInterface. Thus, we can identify which service they
forcements in hidden IPC methods of system service. There invoked by analyzing the class hierarchy via CHA [31]
are three significant challenges to achieve this. First, it is analysis to obtain the IPC class’s real type. Based on this
not easy to find out all corresponding service helper classes rule, service helper classes can be identified by enumerating
associated with the identified system services. In particular, all the fields and method invokes and verify whether the
the internal and hidden APIs [49] that can be invoked by fields or methods are from service IPC classes. If an iden-
third-party apps through Java reflection is not included in tified class is a nested class, an inner class, a local class, or
the official Android SDK. If we intend to identify all service an anonymous class, the top-level enclosing class will be
helper classes that third-party apps can access, we need treated as the service helper class.
to obtain a full version of framework.jar contains all these Finally, we associate the service helper method with the
APIs while in different Android versions the compiling system service method based on the common service IPC
of framework changes dramatically. Second, since system method they invoked, and then save the two methods as
services and the corresponding service helpers use differ- a pair for security mechanism analysis. To achieve this,
ent mechanisms to verify the parameters included in the we need to enumerate all the service helper methods to
requests, it is challenging to identify such enforced security find out the IPC client method (IPC.proxy) they used and
mechanisms accurately. Finally, it is not easy to identify and then enumerate all the service methods to find out which
compare security mechanisms in system service methods implement the IPC server side (IPC.stub). In this way, we can
 7

Service Helper
Analysis

Security Enforcements Flaws in Security

Comparing Enforcements
Android Extract
Framework Construct
Service IPC
with no-SDK Call Graph Characterize
API Methods
User Identity and Flaws in Input
Unprotected Validation
Parameters
System Service Flaws in IPC
API Analysis Rate Limit

Fig. 9. Overview of our approach.

extract a system service API to one or more system helper statements in the entry method as they can be exploited
methods that invoke it. via Binder IPC directly. Finally, for each IPC method, we
need to check the security mechanisms in the service helper
method’s call graph and invoked methods of the system
4.3 Constructing Call Graph for IPC Methods
service method.
We use context-insensitive control flow analysis to identify
security enforcements and detect vulnerabilities for each
4.4 Identifying Security Enforcements
service IPC method. The most important is to build an
effectiveness call graph with correct object types. To discover the inconsistent security enforcements between
Improvement 1: Building accurate call graphs. Rather the service helper method and system service method, we
than directly using the Soot’s full call graph, we build a first need to examine the presence of security mechanisms in
method level call graph that only focuses on the edges both system services and service helpers by extracting and
between service helper method and the IPC API to im- comparing the patterns of different security mechanisms.
prove the performance. Moreover, we employed multiple The presence of security mechanisms in system services
technologies (e.g., EdgeMiner [26]) to improve the virtual and their helper classes need to be analyzed separately
calls, implicit calls used in Android framework to correctly with different approaches since they may have various
resolve the callback methods or inherit methods. Thus, implementations for the same security mechanisms.
more security enforcements can be discovered on the calling
paths. 4.4.1 Mining New Security Mechanisms
Our method level call graph is built via breadth-first In our previous approach [39], we have labeled some of
searching on the fly. Starting from each service helper the system security mechanisms including methods for
method, we add each invoked statement into the worklist. getting user identify like getPackageName shown in Ta-
Finally, if finding a service IPC method is invoked, we save ble 1, Table ??, and methods for checking user permission,
the whole call graph chain between this method pair. In e.g., enforceCallingOrSelfPermission. However, the
this way, we can build a simplified call graph for each method set is incomplete and failed to include all the access
service IPC method which only includes the edges that are control security checks as different services may use various
useful to our analysis. Then, we perform the same approach implementations to perform security and argument check-
to build the call graph for system services’ IPC methods. ing. Hence we use the natural language processing (NLP)
Our approach is much more efficient than the Soot’s default approach to automatically discover such security checking
approach which needs to perform whole program analysis mechanisms with aliasing method names different from
as we only add limit call graph edges around the IPC the common security enforcements ??. Then we apply this
methods. approach to both service helpers and system services to new
To improve the accuracy of the call graph, we take mining new security mechanisms other than the standard
various approaches to precisely resolve the virtual invokes system security mechanisms before the vulnerability detect-
and implicit calls to get the methods that are actually ing.
called on the path. For normal dynamic dispatch, we utilize Improvement 2: Discovering more security enforcements.
CHA [31] call graph building algorithm to get a possible We propose NLP approach to mine the customize permis-
method set that may be called by the virtual invoke’s callee. sion checking functions with alias names. Thus, we can
Fortunately, the hierarchy of Android service classes is not obtain more security enforcements on the system services’
very complicated, especially for service IPC method, with side and reduce the false positives.
only one or two inherit levels. However, Android SDK con- To identify these customized security mechanisms meth-
tains many implicit calls, e.g., Binder IPC calls, Messenger, ods using synonyms names in service code, we leverage
Handler, and other callbacks such as UI OnClick events. To associate rule mining [8] analysis and word similar anal-
address this issue, we take advantage of the callback results ysis to mine out new security mechanisms keywords. A
of EdgeMiner [26]. If one of the interfaces of a class is in the similar work Invetter [52] focuses on insecure inputs that
callback set, we need to retrieve the implemented method are not properly validated by the system service. Our main
of the callback from the subclass of the interface. difference to Inverter is that we concentrate on the permis-
For each system service method associated with a service sion checking function’s method names. At the same time,
helper method, we only need to analyze all the invoke Invetter focuses on the param name to find out sensitive
 8

input parameters. And Invetter’s approach does not work checks if there are enforcements methods in the entrance
in our situation, as our analysis target is framework classes level of a system service API. Thus, our new approach
compiled from the Android source code. In our version of can detect if these parameters are validated in other sanity
framework.jar, origin names of local variables and function check functions (e.g., checkParams) in a deeper level of the
parameter names are lost due to compile optimizing. We calling path and mine more security enforcements in system
try to retrieve the local fields and parameters’ raw names services.
but only get temporary names like str1 and paramInt, We perform backward dataflow analysis to track the
only member names and method names of a class stay the parameters of service IPC methods and collect the methods
same. On the contrary, the function name of the security that use these parameters before IPC call in the call chain.
enforcements keeps unchanged after compiling. For the methods using these parameters, we also perform
Our approach does not rely on Java code’s exact param- the Stmt analysis in these methods to determine the usage
eter name so that our approach can work on any compiled of security mechanisms related methods. The detailed ap-
code, even with variable obfuscation. Notice that service proach of Stmt analysis is to enumerate each Stmt in the
helper methods perform extra security checking before the Soot method body and find out the invoked Stmt and then
IPC call, and system service may perform security check- extract the method name and parameter information. For
ing again at the IPC interface implementation methods a reference type, we obtain their real name and the Java
entrance. Around these IPC methods, we can collect a set type via the points-to analysis. We track the initialization
of methods called before or after each of the IPC methods. and assignment of each Java reference value in function
Some of them check the user’s parameters and privileges, level and regard the same references to a value as the same
which might be the actual implementation of security en- pointer. In this way, we verify if the local fields are used
forcements. By analyzing the method level callgraph, we by the user identity accessing methods and further analyze
can extract all these methods with Soot Stmt [50] analysis. if these local fields are passed to IPC methods or security
For each method of the call chain, we retrieve all the Stmt enforcement methods. This approach is also applied in the
of its method body and check if the Stmt is invoked Stmt system service methods to check if there is any security en-
or definition Stmt and then we resolve the real type and forcement. We use dataflow analysis and points-to analysis
name of these variables functions by point-to analysis. After to identify whether the parameters of IPC methods are pro-
extracting a method name list for each service IPC method, tected by sanity check functions that validate the parameters
we get a method name list collection containing the method and throw exceptions (see Section 4.4.3) in service helpers.
calls in every IPC call chain. Specifically, we manually obtain We trace the dataflow starting from the IPC methods and
keywords from the user identity accessing API in Table 1 analyze the backward dataflow of the corresponding param-
and the user identity-checking API in Table ??. And we use eters by using BackwardFlowAnalysis in Soot. Thus, we
the keywords to filter out these method name lists, which can identify all security checks for the parameters which are
do not contain the keywords and use the left items as input conveyed to the service IPC methods.
for the associate rule mining. Thus, from the mining results,
we can find other high-frequency methods that use these
4.4.3 Identifying Security Mechanisms in Service Helpers
user identity methods, and most of these high-frequency
methods directly call the user identity APIs or provide We use different patterns to identify the presence of various
arguments for user identity methods. The mining results are security mechanisms in service helpers.
shown in 2. Identifying Parameter Validation. We can capture this type
We can gain most high-frequency method names from of security enforcement mechanism by analyzing if any
the association rules mining result, which are always used exceptions will be triggered by handling illegal parame-
together with user identity APIs, and we regard them as ters. The key observation is that the Binder framework
new security mechanisms methods. All these method names of the Android system does not handle all exceptions
and the user identity APIs are used to identify security though most of them incurred by illegal parameters will
enforcements in the following analysis. be captured and handled. For example, the six most com-
mon exceptions are well handled in the system services
4.4.2 Identifying Enforcements by Backward Dataflow defined by AIDL, including BadParcelableException,
Analysis IllegalArgumentException, IllegalStateExce-
The accuracy of identifying enforcements in both server ption, NullPointerException, SecurityExcept-
helpers and system service is significant to tool precision ion, and NetworkOnMainThreadException [5]. If there
since the miss cases in server helpers can lead to false are any other exceptions, the framework will re-throw them
negatives and the miss cases in system service can increment as RuntimeExceptions. We observe that exceptions that
the false positives. We perform precisely analysis to check if are thrown by system service IPC methods and caught by
the parameters are actually checked by these enforcement the Binder framework are passed to the IPC callers through
methods. Parcel.writeException(). Thereby, the caller could
Improvement 3: Precisely tracking the IPC parameters handle these exceptions in its own process, which ensures
with dataflow analysis. By employing the dataflow analysis that the service will not crash. We find that if a parameter
for the IPC parameters, we can verify if the fake identity (see of IPC methods in the service is used out of the methods
Fig 4) and illegal parameters (see 5) are actually validated (i.e., it is used in asynchronous handler or stored for later
by the system service by further tracing the dataflow of access), it may lead to failures of handling the generated
these parameters while our previous approach [39] can only exceptions. Hence, we can identify the security mechanism
 9

of parameter validation by analyzing if illegal parameters TABLE 1

are used out of IPC methods. Methods used by service helpers to obtain caller’s identity.
To achieve this, We adopt def-use analysis [18] and
backward dataflow analysis to identify all parameter valida- Identity Type Method
tion mechanisms. The def-use analysis links each variable
Context.getPackageName()
definition with that is referred so that we can identify if a
Package Name Context.getBasePackageName()
variable, i.e., an input parameter, is referred to a validation
Context.getOpPackageName()
process. We can identify validation mechanisms if the fol-
lowing two conditions are met: (i) We check whether input Process.myUid()
parameters of a method are used in boolean expressions UID Process.getUidForPid()
or whether they are used in other methods that return Context.getUserId()
boolean values; (ii) If the parameters are indeed associated Process.myPid()
with boolean values, we further verify whether the boolean PID Process.getPids()
values are used in conditional statements that contain state- Process.getPidsForCommands()
ments with early returns or thrown exceptions. If these two Process.getGidForName()
GID
conditions are met, the method includes input parameter Process.getProcessGroup()
validation. To reduce the false positives of identifying the Process.myPpid()
validations, we use the dataflow and point-to analysis (see PPID
Process.getParentPid()
Section 4.4.2) to precisely check if the parameters are ac- TID Process.myTid()
tually checked among different procedures. If parameters UserHandle Process.myUserHandle()
stored for later access can be accessed by the classes in
the IPC methods or the fields of the outer classes, e.g.,
a parameter is accessed and included in a collection of
the field, it indicates that exceptions triggered by input service. We enumerate all IPC interfaces in the system
parameter validation indeed exist. Moreover, we identify all service returning boolean values since the interfaces that
possible asynchronous handlers such that we can accurately include the methods of evaluating system environments
find if a parameter used in an asynchronous handler will be normally return boolean values. In general, the interfaces
validated. Thereby, we can identify the parameter validation that evaluate system environments verify if a hardware
mechanism in service helpers. device, e.g., a fingerprint reader, exists before using the de-
Identifying Caller Status Validation. Caller status valida- vice, or verify if a function, e.g., accessing the wallpaper, is
tion is similar to the input parameter validation. We identify disabled before invoke the function, and then return boolean
the mechanism of caller status validation by (i) analyzing if values. We further check if the boolean statement includes
there exists APIs that return callers’ status and (ii) verifying a method of the corresponding service helper. If it is true, it
if these APIs are used in conditional statements. If these two indicates that the service helper may invoke a method in the
conditions are met, a caller status validation mechanism in system service accessing the system environment according
the service helper is identified. to the boolean results of evaluating the environment.
Identifying the Process of Passing Caller’s Identity. We Identifying the Constraint of Duplicated Requests.
identify this mechanism by searching if any method process- Service helpers adopt two mechanisms to constrain the
ing identity information is executed before the IPC method number of duplicated requests delivered to the system
of a target service. Normally, apps can provide different services according to the types of requested resources (see
types of identities. As we observed, there are seven types Fig 7) so that they prevent different resource consumption
of identity information in Android, i.e., package name, incurred by duplicated requests from apps. The first
uid (i.e., Linux user identifier), pid (i.e., Linux process mechanism is to constrain the number of requests that an
identifier), gid (i.e., Linux group identifier), tid (i.e., Linux app can issue for resource access. If the total number of
thread identifier), ppid (i.e., Linux parent process identi- requests exceeds a threshold, the subsequent requests will
fier), and UserHandle (i.e., representing a user in Android be ignored. To identify the existence of this mechanism,
that supports multiple users). Each of them can be obtained we search all methods in service helpers and locate the
by calling different methods. These user identity accessing condition statements with integral constant expressions.
methods are summarized in Table 1. Methods from the If such a condition statement is located after the entry of
associate rules mining results such as getCallingUid the corresponding service helper but before the IPC calls
and getCurrentUser are also added to the user identity to the service in the call graph, there is a high probability
accessing method set. Suppose any method included in a that the statement is used to check duplicated requests,
service helper tries to access user identity before an IPC which is similar to input parameter validation. The second
method of the call graph’s target service. In that case, mechanism is to constrain the number of duplicated
the service helper may validate the caller’s identity and requests to register listeners. Usually, a service helper
then pass the verified identity to the corresponding system method accepts a listener as its parameter, and saves the
service. listener to a local list. For example, the service helper
Identifying the System Environments Checks. We capture method, EthernetManager.addListener(Listener
this security mechanism by identifying if a service helper listener) saves the parameter listener to
invokes the corresponding system service according to the ArrayList<Listener> mListeners. If it is the first
boolean result returned by an IPC interface of the system registration request, the helper will register in the remote
 10

service via IPC.Otherwise, the service helper method only in the method pairs (i.e., the service method and the corre-
adds the request’s listener to the local list. When the service sponding service helper method) we identified in Section ??
helper receives an update from the service, it dispatches are consistent. We identify the inconsistency of security
the update to all listeners maintained in that list. We can mechanisms in these methods by leveraging the prebuild
capture this type of mechanism by identifying the code call graph and detecting their code features in the graph.
maintaining the listener lists.
4.5.1 Identifying Enforcement Inconsistency
4.4.4 Identifying Security Mechanisms in System Services Our tool can automatically perform various types of ver-
The approaches to identifying security mechanisms in ification. For the inconsistent parameter checking, we can
service helpers (see Section 4.4.3) can also be applied simply compare if a service helper verifies more parameters
to identify the security mechanisms enforced in system than that in the corresponding system service. We extract the
services. However, we cannot directly adopt it to identify parameters validated in each party of the method pair into
security mechanisms in system services because of two sets. The parameters validated in the service method are
the following difference between systems services and denoted as set S , and those in the service helper method are
service helpers. Firstly, service helpers run in the same denoted as set H . If S is not the superset of H , which means
process with the caller while system services do not. the helper checks more parameters than the service, we use
Service helpers can directly obtain the caller’s identity the dataflow analysis to check if there are parameters that
via methods in Table 1. However, system services need are checked by service helper classes but not checked by the
different APIs to obtain the information about the caller system service. In this way, we can find out the parameters
and check the caller’s properties, since they run in system of service IPC methods that are not well protected and
processes that are separated from the caller processes. For regard them as vulnerable APIs. For the vulnerabilities
instance, system services use Binder.getCallingUid() of inconsistent security enforcement, we first analyze how
and Binder.getCallingPid() to obtain the callers’ service helper classes use the service IPC methods. If an IPC
identities instead of the methods listed in Table 1. method in service helper classes is protected by security
Secondly, system services need to validate app checks, we can confirm which security enforcement this
identities and verify whether the calling app has method should implement. Then we check if the system
privileges to perform sensitive operations, which is service side also implemented the corresponding security
not required in the service helpers. Fortunately, we enforcement to verify the existence of the protection mecha-
find that system services heavily rely on the functions nism.
provided by AppOpsService to perform validation. Moreover, we utilize permission checks to reduce
For example, AppOpsService.checkPackage(int false positives of identifying the bypass vulnerabilities.
uid, String packageName) checks whether the input We filter out system service interfaces protected by
package name actually belongs to the given uid, and high-security level permissions, i.e., the signature and
AppOpsService.checkOperation(int code, int signatureOrSystem levels, since these interfaces cannot
uid, String packageName) checks whether the uid be accessed by unauthorized apps and thereby cannot be
has the privilege to perform the sensitive operation exploited. We use PScout [19] to obtain interfaces with
indicated by the code. Therefore, we can identify all security level permissions and use the information to detect
functions provided by AppOpsService and use these the vulnerable system service interfaces. Thereby, we can
functions to identify the security mechanisms in system accurately identify the service helper bypass vulnerabilities
services. These system’ default permission checks functions incurred by such vulnerable system services.
in system services are listed in Table ??. We mine extra Finally, potential vulnerabilities can be captured by com-
user identity checking methods do not use the default paring whether the security mechanisms in each method
functions via the NLP approach(see Section 4.4.1), such as pair are consistent. If they do not match, it means that the
enforceUriPermission, checkReadPermission and system service may be possibly exploited by bypassing the
enforcePermission (shown in Table 2). corresponding service helpers (more specifically, bypassing
Since the adversary intends to exploit the services that the inside security mechanisms in the helpers). Since not
do not have the same enforcements with their associated all vulnerabilities are exploitable, we manually confirm the
service helpers, it is crucial to distinguish whether dif- vulnerabilities by constructing real attacks.
ferent forms of enforcements are equivalent. To improve
the precision, we further verify the enforcements that are 4.5.2 Identifying Exploitable Vulnerability
actually applied to the same parameters of the IPC meth- As Google uses blacklist and greylist to constrain
ods, not for other purposes. By focusing on the security these hidden APIs, we need to check if third-party apps
enforcements around the IPC parameters and analyzing can actually invoke the vulnerable API. For versions after
the reference of these parameters to discover how these Android 9, we scan the blacklist to statistics how many
parameters are eventually validated (by sanity checks or vulnerabilities APIs are covered by these lists. The APIs in
permission checks), we have significantly reduced the false greylist can still be invoked by downgrading the app’s
positives. SDK version in the build configuration. However, with the
greylist and blacklist changes in every version, we
4.5 Detecting Possible Vulnerabilities. still need to run the app on the specific device to verify if
The final step is to capture the service helper bypass vul- the vulnerabilities can be triggered. To estimate how many
nerabilities by examining whether the security mechanisms vulnerable APIs can be exploited in the worst case, we need
 11

to consider if these vulnerabilities can be exploited when the TABLE 2

attacker evades the blacklist restriction and can abuse all New Security Mechanisms Methods Mining Results.
the hidden APIs.
Keywords userid, uid, pid, identity, package,
enforce, permission
5 S E R V I C E A U D I T I MPLEMENTATION Identity Access getCallingUid, getUuids, getCurrentUserId,
Methods getPackageInfoNoCheck, getCallingPid,
We implement the static analysis tool based on Soot [50] getDeviceOwnerPackageName,getUserId,
framework and the source code is open-sourced online1 . In getEffectiveUserId, getCurrentUserId,
this section, we elaborate on some technical details of the getCallingUserId, getPermissionPolicy
implementation. Identity Enforce checkOp, checkOperation,
Methods checkCallerIsSystemOrSameApp,
Extract Android SDK Jar. To analyze the no-SDK APIs, we enforceAccessPermission, checkPermission,
need to obtain a full framework.jar that contains all the code enforceChangePermission,
of the Android framework including all the service helper enforceConnectivityInternalPermission,
enforceCallingOrSelfPermission,
classes and system service implementation classes in it. A
enforceCallingPermission,
high fidelity way to obtain the classes without dead code
is to extract the framework from a live Android Image. In
Android 6 to 9, we need to extract the full SDK jar from
methods parameters, some of the generated code is failed
various Android images which use .odex and vdex for
to compile. The verification works need manual works to
the new Android Runtime (ART). Then we need to convert
read the source code and write test apps to verify in real
the .odex and .vdex to .jar files via oat2ex [14] and
devices.
dex2jar [10] tools. However, the oat2ex [14] does not work
for Android 10 to 12. To solve the problem, we build the
AOSP from source and extract the corresponding classes 6 V ULNERABILITY R ESULTS
from the compiling intermediate files distributed in different
directories. To ensure all the methods are included, we need We prototype our approach which is presented in Section ??
to manually add all the corresponding packages of system and apply it to analyze the AOSP 6.0.1. We find a large
service and service helpers in ”framework/base” directory of number of service helper bypass vulnerabilities that incur
the AOSP source code. serious security issues. In this section, we analysis the accu-
Mine extra security enforcements We use FpGrowth [40] racy and effectiveness of our static analysis tool and then
algorithm to perform associate rules mining. Our approach summarizes our findings and evaluate whether Google’s
has been illustrated in Section 4.4.1, and we implement it countermeasures work in various versions. In particular,
with the following steps: First, we extract method names we compare the detection accuracy of our approach with
from the call chain of the services IPC methods’ call graph our previous approach (Result0 ) [39] as well as other
and use it as the initial dataset for FpGrowth. Second, we existing works. Moreover, we construct real-world attacks
manually set a sensitive API list which contain the system’s to exploit a representative vulnerability existing in each
sensitive APIs shown in Table 1 and Table ??. When we build security mechanism.
the initial FpTree [40], we check and set the items in the
sensitive API list with a frequency of 1000 for two purposes:
6.1 Summary of Results
to make sure the sensitive APIs presence in each result set
and to identify the items in results are associate with which We experiment on a laptop computer with a 6-core Intel
sensitive API. And the minimum support frequency is set i7-8750H CPU and 16GB memory, running 64-bit Ubuntu
to 3 to filter out the less high-frequency items. Finally, we 18.04. The whole analysis for AOSP 6.0.1 extended SDK can
collect several lists of high-frequency items from the output be done in less than 15 minutes. We use ServiceAudit to
of FpGrowth and use some keywords such as enforce, user, check 4 Android versions range from Android 6 to Android
and check to perform word synonyms analysis to filter out 10. Unfortunately, we failed to extract the full SDK Jar
these methods with names which unlikely to be security from Android 10 and Android 11. The analysis results are
checking methods. The items remained are regarded as extra shown in Table 3. ServiceAudit can find out hundreds of
security enforcement functions. potential vulnerable APIs among various Android images.
Verify and Exploiting the Potential vulnerabilities. After To measure the accuracy and efficiency of ServiceAudit,
obtain the potential vulnerabilities, we need to verify these we manually verify all the cases in Android 6 and find
potential vulnerabilities. Traditional fuzzing tools such as out 112 true positives of 133 possible vulnerabilities (see
AFL [1] cannot use in our case as service IPC methods section 6.2). Unfortunately, we cannot thoroughly check
need to invoke via Java code or C++ code, and the method all the possible vulnerabilities in various versions due to
parameters need to be filled correctly. Customize fuzz code Android’s large codebases, which is also a limitation in
need to be generated for the fuzzing tests. We tried to parse similar works such as Invettos [52] and Kratos [49]. Not
the definition of IPC methods and generate invoking code all the detected vulnerabilities can be exploited, as some of
via Javapoet [13] for automatically test. And we obtain the them need special parameters that can not be constructed
information for the crash, soft reboot, or permission usages by third-party apps or need system-level permissions.
from Logcat. Unfortunately, due to the complicated IPC To further evaluate the effectiveness of detecting vul-
nerabilities, we construct POC apps to exploit these APIs
1. https://github.com/fripSide/ServiceAudit and find out more than 32 exploitable cases. We reported
 12

some of the vulnerabilities to Google in 2017. Several coun- many ways to check the app’s privilege. For example, for
termeasures are taken since Android 8 includes fixing the the IPC method KeyStore.getState(), we succeed in
bug case by case, adding standard permission checks, and finding Uid checking in the service helper method but failed
using a blacklist to disallow directly invoking all the IPC to identify the security enforcement in system service API
interfaces. These countermeasures can make some of the as it checks app permission via reading the authorization
previous exploitable bugs now are not vulnerable anymore. information from the ContentProvider.
We run the exploitable POC in different Android versions
and find out many of them are still vulnerable in newer TABLE 4
Android versions (see Table 5). Note that, here, we only The results of our previous work and our current work compares to
existing works.
discuss 23 bugs in section 6.4 as the 9 IPC flood bugs have
been fully discussed in [42].
Work Total Found TP Accuracy Exploitable

TABLE 3 Previous 143 32 22.4% 22

The number of classes, service helper classes, service IPC methods, Ours 133 112 84.2% 32
and possible vulnerabilities report by ServiceAudit in different Android Kratos 73 58 79.5% 8
images. Invetter 103 86 83.5% 20

Android #Service #Service #Possible Not all the vulnerabilities can be exploited and cause
#Class
Version Helper IPC API Vulnerabilities serious security problems, such as Toast.cancelToast()
6.1 (API 23) 11577 178 1826 133 can cancel other app’s Toast message via fake-id attack by
7.1 (API 25) 14705 173 1729 109 using other app’s package name. Some vulnerabilities are
8.0 (API 26) 19854 218 2270 85
hard to be exploited as they need special parameters and
special logic states. Without static analysis, it is infeasible to
9.0 (API 28) 24166 268 2611 68
verify all the IPC interfaces as there are a large number of
10.0 (API 29) 24166 285 2639 31
methods, and many of them are difficult to construct test
11.0 (API 30) 27582 317 2971 27
code. Our static analysis tool is effective in reporting the
12.0 (API 31) 30856 358 3210 25
potential vulnerabilities with detail vulnerable information
and reduce the manually verified methods number to less
than 7%. We find out at least 25 serious exploitable cases in
6.2 Tool Accuracy and Effectiveness all the reported 133 methods, and these issues are confirmed
Accuracy of static analysis. We calculate true positives (TP) by Google.
and false positives (FP) to evaluate the accuracy of our tool. Tool Performance. ServiceAudit needs about 4 to 8 min-
Unfortunately, it is impossible to evaluate the false negatives utes to finish the analysis of the whole farmework.jar. It is
as there are still zero-day bugs uncovered, and we cannot much faster than our previous approach which requires sev-
get the ground truth of all the vulnerabilities. We manually eral hours. However, if the Soot spart point-to [50] analysis
examine the source code of each system service methods is enable, our analysis needs more than one hour. Rather
and service helper methods to find out if the enforcement than using Soot’s builtin call graph and point-to analysis,
of service helper methods can be bypassed, e.g., for fake we propose partial call graph and point-to analysis that only
identify vulnerabilities, we verified whether the vulnerable focus on the service helper methods and the service IPC
API accept user identities such as userId and package name APIs and significantly reduce the analyzed classes.
as parameters and do not verify these identities in system Compared with existing approaches. Compared with
service API. If the protection can be bypassed, we count it as Kratos [49] and Invetter [52], our tool can discover more
a true positive, and otherwise, we treat it as a false positive. vulnerabilities with a higher accuracy shown in Table 4.
And for the TP cases, we also construct test apps to try The reports of Kratos are centered on fake identity
exploiting these vulnerable APIs. In all the 133 suspicious vulnerabilities, and Invetter focuses on input related
vulnerabilities, we find 112 true positives and more than vulnerabilities such as fake identity and illegal parameters.
25 exploitable serious vulnerabilities. Comparing to other Note that Kratos and Invetter support multiple Android
existing tools, our tools can detect more vulnerabilities with versions, so we choose the results of Android versions,
higher accuracy. The detailed results of each vulnerability which are closest to the Android 6.0.1 r1 used in our paper,
categorization are shown in 6.3. i.e., Kratos’s result for Android M preview (Android 6.0.0)
Tool Effectiveness. We further analyze the results of static and Invetter’s result for AOSP (6.0). Among these works,
analysis and try to understand why the false positives Invetter also can checks if the service APIs have validated
produce and the effect of exploiting the true positives. We the caller’s identity or permissions. For the vulnerability
find that most of the false-positive cases occurred due to the types which Invetter works on (input related), our tool can
inaccuracy of point-to analysis and data-flow analysis and also detect most of the vulnerabilities given in their Table-4,
failed to identify the enforcements correctly, e.g., for IPC such as Accessibility Manager Service, Input
method WallpaperService.engineShown(), we mis- Manager Service, Network Management Service,
takenly recognizing user identity checkings in its calling Audio Service. However, our tool do not support the
path. In fact, these checks are performed to protect another detection of vulnerabilities which depend on the parameter
API. And another reason is that we cannot identify all the name, e.g., CNEService and Atfwd service . Due to the
security enforcements in system services as there are too different working scopes, our tool can detect more types of
 13

by the user, and some may do not have any harm even
#Vulnerable API 80 Previous(TP) the checks are bypassed. we capture 32 vulnerabilities that
Previous(FP)
60 Ours(TP)
lead to serious security issues, e.g., privilege escalation, data
leakage, user interactions bypass, or Android system soft
40 Ours(FP) reboot, shown in Table 5. All these vulnerabilities have been
confirmed by the Android Security Team and assigned with
20 different Android Bug IDs. For the left vulnerabilities, some
are fixed in the later Android, and some can be exploited
0 but do not cause serious security problems. We do not
Fake Illegal Fake System IPC submit them to Google as AOSP 6 is out of date. We also
Identity Param Status Env Flood revisit these bugs in newer Android versions and find out
that these problems still exist. We describe the observed
Fig. 10. The results of our current work and Service Helper [39]. The vulnerabilities in the following.
number of true positives(TP) and false positives(FP) are concluded by
manually verifying. Note that, the previous static tool does not support Vulnerabilities Caused by Passing Illegal Parameter. We
IPC flooding detecting so the false positives are not given. And system identify 227 service helper methods containing parameter
environment bypass is also new vulnerabilities discovered by the current checking and exception throw stmt. In fact, only a few
tool. of these checks are used to protect the system service
exploitable vulnerabilities than Invetter such as the status API and we perform inter-procedure dataflow analysis to
checks bypass, and IPC flood. verify if the input parameters of IPC methods are really
Compared to our previous approach [39], our overall checked. Then we apply permission filtering to exclude
true positives (shown in Fig 10) have improved from 22.4% the IPC methods which require special permissions and
to 84.2% (reduced around 81% false positives) on Android difficult to exploit. Most of these methods are excluded
6, which significantly reduced the overhead of manual after the two approaches and they help to reduce to false
confirmation. The aforementioned three improvements have positive rate from 94%(48/51) to less than 20%(5/23). And
greatly contributed to the better precisions. First, our new we find 23 method pairs are inconsistent in validating the
call graphs have correctly resolved virtual calls and thus can input parameters and 18 methods of them are true posi-
find the real service implementation classes while our previ- tives could be possibly exploited. After manual verification,
ous approach may mistakenly use the parent classes as the three methods are confirmed to be vulnerable with serious
service implementation, for instance, the BaseIDevicePolicy problems, i.e., they can be exploited to crash their services.
Manager which is an abstract class do not have any security These vulnerabilities are in MediaBrowserService and
enforcements, and thus produces lots of FP. Second, we HealthService, which are incurred by failure in handling
use NLP approach (FPGrowth [40]) to mine more security exceptions.
enforcements in system service sides that are not considered Vulnerabilities Caused by Passing Fake Identities. In our
by our previous approach and reduce the FP of the fake previous approach, we find 86 inconsistent identity verifi-
identity vulnerabilities. Third, we use dataflow analysis cation, however, it relies on the manually set sensitive API
to track if the parameters checked by service helpers are list to identity security checking methods and most of the
actually passed as IPC arguments to the system service and system service API use custom checking methods which
thus reduce the FP of the illegal parameter vulnerabilities, produces lots of false positives. In our current approach,
while our previous approach only checks the existence of after performing associate rules mining, we identity more
some Exceptions. security checking methods in both service helper and sys-
tem service. We have discovered 59 inconsistent methods
and most of them are new cases missing by our previous
6.3 Vulnerabilities Summary tool. The false positive rate has reduced to less than 10%.
We further study each vulnerability type and try to check In all these reported inconsistent methods, we find 53 true
if these vulnerabilities are exploitable. We find 178 service positives that service methods receive callers’ identities
helper classes out of 11577 classes in Android 6.1. Among from the corresponding service helpers but fail to verify
these service helpers, we find 133 potential vulnerabilities: the authenticity of the received identities as the service
59 service helpers deliver the caller’s identity to the service, helpers do. We manually verify whether all of them can
which may suffer fake identity attacks. Also, we observe be exploited. Our verification shows that 10 out of the 53
that 51 methods only validate input parameters in service inconsistent method pairs can be used to launch real-world
helper methods and may suffer Illegal parameters attack, 19 attacks. The rest methods are not vulnerable to fake identity
methods that verify caller’s status and may suffer the fake attacks because those fake identities do not incur security
status attack, and 22 service methods that handle duplicated issues, such as BackupManager.dataChanged().
requests without protecting, and ten methods evaluating Among the exploitable vulnerabilities, one case is caused
system environments. by the abuse of enqueueToast() in the notification ser-
After manually verifying these potential vulnerabilities vice, which can lead to system reboot. Malicious apps will
in Android 6.1, we find 112 true positives. From these true be falsely treated as a system app via passing a fake package
positives, we further construct POC apps to find out the name “android” and thus exhausts the system resources.
vulnerabilities that can be exploited and lead to severe The other nine vulnerabilities are in the notification
problems. Note that not every case can be exploited as some service and the fingerprint service, respectively, which
may need special arguments that can not be constructed will result in privilege escalation. A real-world attack to
 14

fingerprint service is illustrated in Section 4.

Vulnerabilities Caused by Invoking IPC with Fake Status.
30

#Vulnerable API
We find that 19 service helper methods check the caller’s
status, and 13 of them are true positives. One of them lacks 20 Blacklist
the validation of the caller’s status in its corresponding Greylist
service method, i.e., NfcService. An attacker can easily
Public
bypass user interaction to access function without user 10
initiation or user permission. We show this case in Section 4
where an app can directly retrieve NFC data when it is in the
background. And some other APIs can also be exploited but 0
do not cause serious problems, such as AccessibilityMan- Android 10 Android 11 Android 12
ager’s status checking can also be bypassed which may be
exploited by attackers and interrupt other apps’ accessibility Fig. 11. The numbers of vulnerable APIs with different restriction policy.
services.
Vulnerabilities Caused by Bypassing System Envi- ShortcutService is introduced since Android 9 and it is
ronment Evaluation. We find 10 methods that evalu- not be fixed since Android 12.
ate system environment in different service helpers and Most of the Bugs are Fixed. The vulnerabilities are grad-
identify 9 possible vulnerabilities. Most service helpers ually fixed after Android 8 by adding extra security en-
only handle encapsulating the functions of system ser- forcements in the callee system service APIs’ side. We revisit
vices. Here, we only identify one vulnerable method, all the serious vulnerabilities in previous versions, such as,
i.e., WallpaperManager.isWallpaperSupported(), in set audio without permission, or stealing the Clipboard. We
evaluating system setup, which incurs data leakage used in find that Google has added security checks to almost every
WallpaperManagerService.getWallpaper(). public API in AudioService. In ClipboardService,
Vulnerabilities Caused by IPC Flooding. We identify 22 they have now validated the permission of the real callers
methods in service helpers that handle duplicated requests of the pending Intent via getIntendingUid.
and can be bypassed. These helper methods firstly check The Remained Vulnerable APIs Seems to Be Secure.
whether the current request is a duplicated one. After We have identified 27 vulnerabilities in Android 11 and
receiving duplicated requests, the methods either process two of them are eliminated in Android 12. Almost all
the requests locally (not deliver them to the services) or of these vulnerabilities seem to have no harms to be
constrain the number of the requests that can be delivered to exploited since most of them are APIs to get status,
the services. However, these methods can be easily bypassed such as getStreamVolume, hasSystemFeature. For the
by directly using the methods in the corresponding system StorageStatsService, the getCacheBytes APIs re-
services. A malicious app can directly invoke a system quires the permission PACKAGE_USAGE_STATS while a
service via IPC without any restriction. We find that a large similar API getTotalBytes can be invoked without per-
number of IPC calls would lead to Android resource exhaus- mission but with a comment of ”No permissions required”.
tion, which can further incur system reboot. And some vul- Although some other APIs in StorageStatsService are
nerabilities do not cause to reboot but can make the system not marked with no permission required, we do not re-
frozen, such as AudioManager.setStreamVolume(). If gard them as dangerous since they can only be used to
these APIs are called too many times the floating audio obtain status, e.g., isReservedSupported. For the vul-
adjusting, window will make the system frozen and have nerabilities that can bypass the system environment eval-
no response. uating, we also failed to find any dangerous one, e.g.,
startWatchingRoutes seems can only obtain the status
of the AudioRoutesInfo. In Android 11, we only find
6.4 The Effectiveness of Android Countermeasures the requestPinShortcut can incur security problems
To answer whether, there are still exploitable vulnerabili- by arbitrarily creating Icon shortcuts [15] for other apps.
ties in hidden APIs. We applied our tool to the newest Fortunately, it is fixed [16] in Android 12.
Android 11, 12 and found more than 25 vulnerabilities. To Blacklist or Greylist does no Affect the Hidden API
further understand the hazards of exploitation, we manually Security. We statistic how many vulnerabilities APIs are in
verified all these APIs on Android emulators. To estimate blacklist or greylist. As shown in Fig 11, most of these APIs
the effectiveness of Google’s countermeasures, we study are in blacklist and greylist. It reveals that the developers
how previous vulnerable APIs are fixed in newest Android need to evade the no-SDK APIs restriction to exploit the
12 and how many vulnerabilities are still exploitable in vulnerable APIs since the blacklist APIs can not be used
Android 12. Our findings are as follows. and the greylist APIs can only be used before Android 9.
Bugs are Eliminated or Emerge due to Version Changes. Considering, even if the attackers evade the hidden APIs
During the development of the Android framework, some restriction via the methods in Section 3.3, the exploited APIs
existing APIs may have been refactored or removed in have no security risk.
new versions, such as the selectTrack() method from
TvInputManagerService. We find some vulnerable APIs
have been changed and can not be exploited anymore. It
7 R ELATED W ORK
is interesting to find that the newly added APIs may also Android vulnerabilities have been extensively studied in the
be vulnerable, such as the requestPinShortcut of the literature, e.g., private data leakage [20], [24], [28], [48], [51],
 15

TABLE 5
The exploitable vulnerabilities (exclude 9 IPC flood cases) and their impacts and mitigate effectiveness in various Android versions. Google has
taken several countermeasures includes, put API in Blacklist on Android 11 (B), fix the bug (F), and API has been removed or changed (C).

Affected Frameworks
Service Name Vulnerable API Detail Mitigate
6.1 8.0 10.0 11.0
TvInputManagerService selectTrack • Select TV track with the fake uid C
setStreamVolume • • • Set volume without permission F
setRingerModeExternal • • • Modify volume settings B+F
AudioService adjustStreamVolume • • • Adjust volume B+F
setBluetoothA2dpOn • • Disable A2DP audio B+F
setBluetoothScoOn • • Disable Bluetooth SCO headset B
enqueueToast • • DoS attack with too many toast B+F
cancelToast • • • Cancel system notification B+F
NotificationManagerService setNotificationPolicy • Change notification policy B+F
getNotificationPolicy • Get notification policy B+F
setInterruptionFilter • Change notification filter B+F
IInputMethodSession displayCompletions • • • Close the input method panel B+F
DisplayManagerService releaseVirtualDisplay • • Relase the virtual display B+F
authenticate • • Start fingerprint authenticate B+F
cancelAuthentication • • Stop fingerprint authenticate B+F
FingerprintService getEnrolledFingerprints • • Get fingerprint status B+F
hasEnrolledFingerprints • • Get fingerprint status B+F
isHardwareDetected • • Get fingerprint status B+F
addSubscription • • • DoS with illegal parameter B+F
MediaBrowserService
removeSubscription • • • DoS with illegal parameter B+F
HealthService registerAppConfiguration • DoS with illegal parameter F
NfcAdapter enableForegroundDispatch • • Change NFC settings B+F
WallpaperManager getWallpaper • • Read wallpaper F
ShortcutService requestPinShortcut - - • • Create App Shortcut F

privilege escalation [22], [23], [30], [32], [35], and component system service. Invetter studies the sensitive inputs and ver-
hijacking [21], [29], [47], [54]. In this paper, we only summa- ifies if the protection of these sensitive inputs is consistent
rize and compare with the existing studies closely related to between system services methods and service helpers meth-
the service helper bypass vulnerabilities. ods. Invetter uses a machine learning approach to identify
new sensitive inputs via learning from existing parameter
names to detect if these parameters are well protected.
7.1 Android Static Analysis
Different from their approach, we discover insufficient se-
Static analysis is one of the most effective techniques to an- curity checks of the system APIs (IPC.stub) by comparing
alyze the vulnerabilities in both Android systems and apps. their security enforcements to the service helpers (IPC.proxy
There have been various studies on malware detection by clients) to mine the inconsistency. By mining new security
leveraging static analysis [34], [36], [37], library security [38], mechanisms (e.g., permission checks, status checks, sanity
repackaging detection [41], [53], component security [47], checks) instead of sensitive input, our approach support
system service security [43], [49], and permission specifica- more types of vulnerabilities other than the input related
tion [19]. Several static analysis tools [2], [3], [50] also have vulnerabilities. Invetter has reported 9 exploitable services
been developed to solve different problems. There are two in AOSP 6.0 and 11 vulnerabilities in other third-party
tools [43], [49] closely related to our work. Our study focuses ROMs. In all the 9 vulnerabilities of AOSP 6.0, 8 cases
on the security breaches incurred by bypassing service are also reported by our tool and only the CNEService
helpers, which cannot be discovered by them. Moreover, is missed. Kratos finds out that multiple execution paths
since the static analysis cannot accurately reflect the precise are leading to the same system service function with in-
situations in runtime, the analysis results are accurate. In consistent privilege requirements. Thus, malicious apps can
our paper, we automatically discover the vulnerabilities and easily escalate their privileges or even perform DoS attacks
verify the found vulnerabilities by constructing real-world by redirecting their requests to the paths with less enforced
attacks. permissions. Different from these studies only on the system
services, our work focuses on investigating the impacts of
7.2 Vulnerability Detection in System Service bypassing service helpers and studying the security mecha-
nisms in both services and service helpers. And we perform
Invetter [52] and Kratos [49] are also studying the vulner-
a systematic and comprehensive study about several types
abilities due to inconsistent security policy enforcement of
 16

of vulnerabilities due to inconsistent security enforcements identify vulnerabilities. However, without the information
of system services. in the system service helpers, the efficiency of fuzzing is
low. In the future, we can try to leverage fuzzing to improve
7.3 Android System Service Security the efficiency of identifying the vulnerabilities.
Manual Work. Our approach is mostly performed automat-
The system services security have been studied in various
ically. However, manual verification is inevitable since we
aspects [25], [27], [43], [45], [49]. Lei et al., [45] found a
need to confirm identified vulnerabilities by constructing
new kind a service hijack attack due to implicit services
PoCs, which cannot be automatic. For example, we find
and measure [27] the vulnerable Apps of different time
that passing fake IDs to some system services will not
periods in Google Play Market. Huang et al., [43] discovered
incur any security problems in the status obtain functions.
a design flaw in the concurrency control of Android system
Normally, manual work is required in verifying whether the
services. They found that Android system services often
identified vulnerabilities can indeed be exploited to launch
used the lock mechanism to protect critical sections or syn-
real-world attacks. The procedure is necessary since we can
chronized methods. However, if an application took a lock
systematically investigate the impacts of the vulnerabilities
for a long time and other system services sharing the same
by verifying if they can be exploited.
lock would freeze, then the watchdog thread would force
Android to reboot. Another related work [25] examines the
input validation in system services using fuzzing. They have 9 C ONCLUSION
identified several DoS attacks due to the lack of proper input
We systematically study the non-SDK service API secu-
validation in system services. Our work has also examined
rity and focus on the vulnerabilities of bypassing service
the input validation of system services. We also found that
helpers and corresponding countermeasures in various An-
the App identity collected by the service helper and the
droid versions. In order to discover such vulnerabilities and
parameters prepared by the developer are passed to the
demonstrate the impacts of the vulnerabilities, we develop a
service as its input which may suffer attacks. We present
methodology that automatically analyzes and compares the
an effective approach to identify the vulnerabilities. As
security mechanisms in system services with the associated
shown in Section 6.3, we systemically reveal more vulner-
service helpers in various AOSP. We study the effectiveness
abilities [42] other than the parameter validation that were
of Google’s countermeasures in different Android versions
missed by previous approaches. The existing studies [25],
and check if the vulnerable APIs are still exploitable in
[52] are also unable to discover such vulnerabilities since the
newest Android 12. In Android 6, we discovered 32 serious
vulnerabilities can only be exploited by constructing special
vulnerabilities that can be used to launch real-world attacks,
parameters. For example, the FingerprintService ser-
while in Android 12, only 25 APIs are reported as vulner-
vice can be exploited if the input parameter is set to be
able but have no harm to be exploited. The experimental
the package name of KeyguardService (see Section 4).
results reveal that Google has successfully addressed the
However, it is still challenging to construct the parameters
vulnerabilities in hidden APIs due to inconsistent security
by fuzzing to effectively find this vulnerability.
enforcements.

8 D ISCUSSION
R EFERENCES
8.1 Lessons Learned
[1] Afl: american fuzzy lop. http://lcamtuf.coredump.cx/afl/.
Our previous study reveals a large number of vulnerable [2] Androbugs. http://www.androbugs.com.
hidden service APIs (Section 6), which can lead to serious [3] Androguard. http://code.google.com/p/androguard.
security issues, e.g., privilege escalation, user interaction [4] Android 9 Restrict Hidden APIs. https://developer.
bypass, service crash, and Android system soft reboot. Since android.com/distribute/best-practices/develop/
restrictions-non-sdk-interfaces.
Google cannot prevent the attacker from exploiting the [5] Android api reference: Parcel.writeexception(). https://goo.gl/
hidden service APIs, the only way to mitigate this problem 7zuXuR.
is to eliminate all the bugs by manually adding enough [6] Android interface definition language. https://goo.gl/UFrnT3.
[7] Android sdk with internal apis. https://github.com/fripSide/
security checks in all the system service APIs. Considering
AndroidApiExtract.
the huge numbers of hidden service APIs, it is critical to use [8] Association rule mining. https://en.wikipedia.org/wiki/
static analysis tools to report such problems. \protect\@normalcr\relaxAssociation rule learning.
[9] Bypass android hidden api blacklist. https://lovesykun.cn/
archives/android-hidden-api-bypass.html.
8.2 Limitations [10] Dex2jar. https://goo.gl/skfQLl.
[11] Improving stability by reducing usage of non-sdk inter-
Detection Accuracy. Although we capture a large number of faces. https://android-developers.googleblog.com/2018/02/
vulnerabilities caused by the bypass of service helpers, we improving-stability-by-reducing-usage.html.
have to admit that there may exist more such vulnerabilities [12] It is supper easy to bypass android’s hidden
to be uncovered. The main reason is that some system api restrictions. https://www.xda-developers.com/
android-development-bypass-hidden-api-restrictions/.
services use native code with JNI though it is a small portion [13] Javapoet. https://goo.gl/nsIHR3.
of the service code on the Android system [49]. We do not [14] Oat2dex. https://github.com/testwhat/SmaliEx.
study the native code in our analysis yet, which will result [15] The shortcut api is vulnerable in android 11. https:
in false negatives. We leave the study of vulnerable system //cs.android.com/android/platform/superproject/+/\protect\
@normalcr\relaxandroid-11.0.0 r1:frameworks/base/services/
services with JNI native code incurred by bypassing service core/java/com/\protect\@normalcr\relaxandroid/server/pm/
helpers as future work. Note that, we could use fuzzing to ShortcutService.java;l=2114.
 17

[16] The shortcut vulnerability is fixed by android 12. [39] Yacong Gu, Yao Cheng, Lingyun Ying, Yemian Lu, Qi Li, and Purui
https://cs.android.com/android/platform/superproject/+/ Su. Exploiting android system services through bypassing service
\protect\@normalcr\relaxandroid-12.0.0 r1:frameworks/base/ helpers. In SecureComm 2016, pages 44–62, 2016.
services/core/java/com/\protect\@normalcr\relaxandroid/ [40] Jiawei Han, Jian Pei, and Yiwen Yin. Mining frequent patterns
server/pm/ShortcutService.java;l=2249. without candidate generation. Sigmod Record, 29:1–12, 06 2000.
[17] Yousra Aafer, Jianjun Huang, Y. Sun, X. Zhang, N. Li, and C. Tian. [41] Steve Hanna, Ling Huang, Edward Wu, Saung Li, Charles Chen,
Acedroid: Normalizing diverse android access control checks for and Dawn Song. Juxtapp: A scalable system for detecting code
inconsistency detection. In NDSS, 2018. reuse among android applications. In Proceedings of the 9th DIMVA,
[18] Alfred V Aho, Ravi Sethi, and Jeffrey D Ullman. Compilers, 2013.
Principles, Techniques, and Tools. Addison wesley, 1986. [42] Y. He, Y. Zhou, Y. Zhou, Q. Li, K. Sun, Y. Gu, and Y. Jiang. Jni
[19] Kathy Wain Yee Au, Yi Fan Zhou, Zhen Huang, and David global references are still vulnerable: Attacks and defenses. IEEE
Lie. Pscout: Analyzing the android permission specification. In Transactions on Dependable and Secure Computing, 2020.
Proceedings of the 19th CCS, 2012. [43] Heqing Huang, Sencun Zhu, Kai Chen, and Peng Liu. From
[20] Adam J. Aviv, Benjamin Sapp, Matt Blaze, and Jonathan M. Smith. system services freezing to system server shutdown in android:
Practicality of accelerometer side channels on smartphones. In All you need is a loop in an app. In Proceedings of the 22th CCS,
Proceedings of the 28th ACSAC, 2012. 2015.
[21] A. Bianchi, J. Corbetta, L. Invernizzi, Y. Fratantonio, C. Kruegel, [44] Jie Huang, Oliver Schranz, Sven Bugiel, and Michael Backes. The
and G. Vigna. What the app is that? deception and countermea- art of app compartmentalization: Compiler-based library privilege
sures in the android user interface. In In Proceedings of 36th IEEE separation on stock android. In Proceedings of the 2017 ACM
Security and Privacy, 2015. SIGSAC Conference on Computer and Communications Security, CCS
[22] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, ’17, page 1037–1049, New York, NY, USA, 2017. Association for
and Ahmad-Reza Sadeghi. Xmandroid: A new android evolution Computing Machinery.
to mitigate privilege escalation attacks. Technische Universität [45] Lingguang Lei, Yi He, Kun Sun, Jiwu Jing, Yuewu Wang, Qi Li, and
Darmstadt, Technical Report TR-2011-04, 2011. Jian Weng. Vulnerable implicit service: A revisit. In Proceedings of
[23] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, the 2017 ACM SIGSAC Conference on Computer and Communications
Ahmad-Reza Sadeghi, and Bhargava Shastry. Towards taming Security, CCS ’17, page 1051–1063, New York, NY, USA, 2017.
privilege-escalation attacks on android. In Proceedings of the 19th Association for Computing Machinery.
NDSS, 2012. [46] L. Li, T. F. Bissyandé, Y. Le Traon, and J. Klein. Accessing inacces-
[24] Liang Cai and Hao Chen. Touchlogger: Inferring keystrokes on sible android apis: An empirical study. In 2016 IEEE International
touch screen from smartphone motion. In Proceedings of the 6th Conference on Software Maintenance and Evolution (ICSME), pages
HotSec, 2011. 411–422, 2016.
[25] Chen Cao, Neng Gao, Peng Liu, and Ji Xiang. Towards analyz- [47] Long Lu, Zhichun Li, Zhenyu Wu, Wenke Lee, and Guofei Jiang.
ing the input validation vulnerabilities associated with android Chex: Statically vetting android apps for component hijacking
system services. In Proceedings of the 31st ACSAC, 2015. vulnerabilities. In Proceedings of the 19th CCS, 2012.
[26] Yinzhi Cao, Yanick Fratantonio, Antonio Bianchi, Manuel Egele, [48] Siegfried Rasthofer, Steven Arzt, and Eric Bodden. A machine-
Christopher Kruegel, Giovanni Vigna, and Yan Chen. Edgeminer: learning approach for classifying and categorizing android sources
Automatically detecting implicit control flow transitions through and sinks. In Proceedings of the 21th NDSS, 2014.
the android framework. In Proceedings of the NDSS, 2015. [49] Yuru Shao, Qi Alfred Chen, Zhuoqing Morley Mao, Jason Ott,
and Zhiyun Qian. Kratos: Discovering inconsistent security policy
[27] Huan Chang, Lingguang Lei, Kun Sun, Yuewu Wang, Jiwu Jing,
enforcement in the android framework. In Proceedings of the 23th
Yi He, and Pingjian Wang. Vulnerable service invocation and
NDSS, 2016.
countermeasures. IEEE Transactions on Dependable and Secure
[50] Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie Hendren,
Computing, 18(4):1733–1750, 2021.
Patrick Lam, and Vijay Sundaresan. Soot - a java bytecode
[28] Yao Cheng, Lingyun Ying, Sibei Jiao, Purui Su, and Dengguo Feng.
optimization framework. In Proceedings of the 1999 Conference of
Bind your phone number with caution: Automated user profiling
the Centre for Advanced Studies on Collaborative Research, CASCON
through address book matching on smartphone. In Proceedings of
’99, pages 13–. IBM Press, 1999.
the 8th ASIACCS, 2013.
[51] Zhi Xu, Kun Bai, and Sencun Zhu. Taplogger: Inferring user inputs
[29] Erika Chin, Adrienne Porter Felt, Kate Greenwood, and David
on smartphone touchscreens using on-board motion sensors. In
Wagner. Analyzing inter-application communication in android.
Proceedings of the Fifth WISEC, 2012.
In Proceedings of the 9th MobiSys, 2011.
[52] Lei Zhang, Zhemin Yang, Yuyu He, Zhenyu Zhang, Zhiyun Qian,
[30] Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Geng Hong, Yuan Zhang, and Min Yang. Invetter: Locating
Marcel Winandy. Privilege escalation attacks on android. In insecure input validations in android services. In Proceedings of
Proceedings of the 13th ISC, 2011. the 25th ACM Conference on Computer and Communications Security,
[31] J. Dean, D. Grove, and C. Chambers. Optimization of oo programs CCS, 2018.
using static class hierarchy analysis. In Proceedings of the ECOOP, [53] Wu Zhou, Yajin Zhou, Xuxian Jiang, and Peng Ning. Detecting
1995. repackaged smartphone applications in third-party android mar-
[32] Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, and ketplaces. In Proceedings of the Second CODASPY, 2012.
Dan S. Wallach. Quire: Lightweight provenance for smart phone [54] Yajin Zhou and Xuxian Jiang. Detecting passive content leaks and
operating systems. In Proceedings of the 20th USENIX Security, 2011. pollution in android applications. In Proceedings of the 20th NDSS,
[33] Zeinab El-Rewini and Yousra Aafer. Dissecting residual apis in 2013.
custom android roms. In Proceedings of the 2021 ACM SIGSAC
Conference on Computer and Communications Security, CCS ’21, page
1598–1611, New York, NY, USA, 2021. Association for Computing
Machinery.
[34] William Enck, Machigar Ongtang, and Patrick McDaniel. On
lightweight mobile phone application certification. In Proceedings
of the 16th CCS, 2009.
[35] Adrienne Porter Felt, Helen J. Wang, Alexander Moshchuk, Steven
Hanna, and Erika Chin. Permission re-delegation: Attacks and
defenses. In Proceedings of the 20th USENIX Security, 2011.
[36] Adam P Fuchs, Avik Chaudhuri, and Jeffrey S Foster. Scandroid:
Automated security certification of android. 2009.
[37] Michael Grace, Yajin Zhou, Qiang Zhang, Shihong Zou, and
Xuxian Jiang. Riskranker: Scalable and accurate zero-day android
malware detection. In Proceedings of the 10th MobiSys, 2012.
[38] Michael C. Grace, Wu Zhou, Xuxian Jiang, and Ahmad-Reza
Sadeghi. Unsafe exposure analysis of mobile in-app advertise-
ments. In Proceedings of the Fifth WISEC, 2012.