RmPerm: A Tool for Android Permissions Removal

∗

Simome Aonzo, Giovanni Lagorio and Alessio Merlo

DIBRIS, University of Genoa, Italy

Keywords:

Android Security, Mobile Security, Privacy and Data Protection.

Abstract:

Android apps are generally over-privileged, i.e., they request more permissions than they actually need to

execute properly. Prior to version 6 users can install an app only by accepting

all

its requested permissions,

while newer Android versions allow users to dynamically grant/deny

groups

of permissions. Since some

them impact on users’ privacy, we argue that users should be granted control at the granularity of the single

permission. We propose a novel approach, which does not require any change to the underlying OS, allowing

users to selectively remove permissions from apps before installing them, and with a ﬁner granularity. We

developed RmPerm, an open-source tool, that implements our methodology, and we present the viability of

our approach via an empirical assessment on 81K apps, underlining that, in the worst case, up to 86% of the

apps can execute without crashing when none of the requested privacy-related permissions are granted.

1 INTRODUCTION

Apps are the main attack vector for Android devices;

therefore, they should require the minimum set of per-

missions to work properly, while satisfying the least

privilege principle to reduce the attack surface. How-

ever, apps are generally over-privileged (Felt et al.,

2011a) since developers tend to require more permis-

sions than necessary to reduce the probability that

their app crashes. Furthermore, it is worth noticing

that some permissions are particularly important for

the privacy of the user, like, for instance, those that

allow apps to proﬁle the user by accessing her con-

tacts, messages and call logs. These permissions are

called dangerous by the Android documentation, and

we argue that users should be granted more control

over them.

Android versions prior to 6, that have still an adop-

tion of 71.5% (and, 2017b), grant a very coarse-

grained control over permissions, i.e., the user can-

not remove permissions from apps, and should

grant all permissions requested by any app in or-

der to install it. Newer versions (i.e., 6 and

later) support dynamic management of groups of

permissions, but they do not allow the user to

grant/deny single permissions. To overcome these

limitations, we put forward an approach allowing to

∗

Partially supported by CINI Cybersecurity National Lab-

oratory within the project FilieraSicura funded by CISCO

Systems Inc. and Leonardo SpA

selectively remove permissions from apps that does

not require any modiﬁcation to the underlying oper-

ating system and is compatible with all Android ver-

sions. A key strength of our approach is that, when

a user decides to remove certain permissions from an

app, we can guarantee, by design, that no Java nor

any native code could ever exploit such permissions,

no matter what. The worst case scenario is a crash

of the less-privileged app, but not a privacy leak. We

have implemented our methodology in a tool,

RmPerm

(rmp, 2017), that we use to extensively assess the vi-

ability of the approach on a set of 81, 000 apps.

RmPerm is an open-source project implemented in

Java, and consists of a console application and a li-

brary. In this respect, we also implemented an app,

ApkMuzzle

(apk, 2017), using RmPerm as external li-

brary. We argue that releasing a tool like RmPerm as

open-source is a liability, as any tool that repackages

apps can subtly add malicious code. By releasing Rm-

Perm as open source we grant anyone the possibility

to verify its behavior, by inspecting the source code.

The rest of the paper is organized as follows. Sec-

tion 2 describes our methodology for permission re-

moval, while Section 3 assesses its viability and per-

formance. Section 4 sets our proposal within the cur-

rent state-of-the-art. Finally, Section 5 concludes and

points out some future work.

Aonzo, S., Lagorio, G. and Merlo, A.

RmPerm: A Tool for Android Permissions Removal.

DOI: 10.5220/0006420203190326

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4: SECRYPT, pages 319-326

ISBN: 978-989-758-259-2

319

2 PERMISSION REMOVAL

A quite direct way to remove a set of permissions P =

,..., p

} from an app A is simply to modify its

manifest, contained in the APK of A, obtaining A

′

This action has two consequences:

1. the digital signature s, for the APK of A, cannot

be reused for A

′

since its manifest, and so the re-

sulting APK, differs from the original;

2. A

′

may crash due to unexpected exceptions,

thrownby the invocation of some API method that

needs some permission p

to run. Indeed, prior to

Android 6, an app asking for the set of permis-

sions P gets installed only if the user grants the

whole set P, so apps could assume to be granted

all asked permissions.

Since the signature s has been produced using an

unknown secret key, we have no choice but to sign A

′

with another (secret) key. The only user visible effect

is that Android will consider A and A

′

two different

apps; however, since they have the same name, only

one of them can be installed at any time. We do

not consider this a problem; in some sense they are

different: A

′

is probably safer than A! To avoid that A

′

crashes because of an unexpected exception, due to a

missing permission p, we carry out a customization

to all invocations of API methods that need the

permission p. This, in turn, means that we need a

mapping between permissions and the API methods

that require such permissions. Surprisingly, this map-

ping is not provided by the ofﬁcial documentation.

However, we were able to obtain the mapping from

the Androguard Project (and, 2017a).

@CustomMethodClass

public class CustomMethods {

@MethodPermission(

permission="android.permission.INTERNET",

defClass="java.net.URL")

public static InputStream openStream(URL u)

{ return new FakeInputStream(); }

@AuxiliaryClass

public static class FakeInputStream

extends InputStream {

@Override

public int read() throws IOException

{ return 0; }

}

Figure 1: Example of method redirection.

Using Dexlib2 (dex, 2017) we have implemented

RmPerm, a tool to redirect selected API method in-

vocations to our own alternative implementations.

Custom methods typically just return some fake data

to the app, to let it proceed. Consider, for in-

stance, the method

execute

, declared in

org.apache

.http.impl.client.DefaultHttpClient

: it needs the

INTERNET

permission and returns a

org.apache.http

.HttpResponse

; in this case, we cannot just remove

the invocation or return a

null

reference, because that

would likely make the app crash. In such cases we

must mock a “reasonable” return value. In the gen-

eral case, when we want to redirect the invocation

for an instance method m of class C, with the signa-

ture T

m(T

,...,T

), we deﬁne a new static method

m(C,T

,...,T

), deﬁned in a class X that we add

to the APK. The ﬁrst parameter, of type C, plays

the role of the receiver of the corresponding instance

method. This kind of setup is similar to C# extension

methods. Then, we rewrite all the invocations of the

form e

.m(e

,...,e

), where e

has static typeC, with

X.m(e

,...,e

)

To make writing custom replacement meth-

ods as easy as possible, our tool reads a DEX

ﬁle and searches for classes and methods that

are annotated with Java custom annotations,

that we have deﬁned:

@CustomMethodClass

@MethodPermission

and

@AuxiliaryClass

. The

annotation

@CustomMethodClass

simply marks

classes that contain replacement methods; this is

simply an optimization to avoid to process each

and every method of the input ﬁle. The annotation

@MethodPermission(p, defClass)

indicates the

involved permission

and the deﬁning class (in the

Android API)

defClass

. Finally,

@AuxiliaryClass

marks the classes that must be copied into the

repackaged app, because they are needed by the

custom methods. For instance, Fig. 1 shows class

CustomMethods

, which contains a redirection for

method

openStream

deﬁned in class

java.net.URL

3 EXPERIMENTAL

ASSESSMENT

To assess the effectiveness and efﬁciency of the pro-

posed methodology, we have carried out an empiri-

cal assessment by executing RmPerm on a dataset of

81,000 APKs randomly downloaded from three dif-

ferent markets, namely Google Play (70,000 APKs),

As an optimization, RmPerm can automatically remove

the invocations of

void

methods, when such methods do

not have an explicit custom replacement.

Here, to make the explanation simpler, we use a source-

like syntax but, of course, we work directly at DEX byte-

code level.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

320

WRITE_EXTERNAL_STORAGE

READ_PHONE_STATE

GET_ACCOUNTS

ACCESS_COARSE_LOCATION

READ_EXTERNAL_STORAGE

ACCESS_FINE_LOCATION

CAMERA

READ_CONTACTS

RECORD_AUDIO

CALL_PHONE

WRITE_CONTACTS

RECEIVE_SMS

SEND_SMS

READ_SMS

READ_CALENDAR

WRITE_CALENDAR

PROCESS_OUTGOING_CALLS

READ_CALL_LOG

WRITE_CALL_LOG

RECEIVE_MMS

RECEIVE_WAP_PUSH

USE_SIP

BODY_SENSORS

ADD_VOICEMAIL

App %

Figure 2: Distribution of dangerous permissions in the dataset.

Aptoide (5,500 APKs) and Uptodown (5,500

APKs).

Since we could not conceivably choose, for each

app of the dataset, a different set of permissions to re-

move, we have decided to assess the worst-case sce-

nario, that is, to remove all dangerous permissions

from each app A, producing a new app A

′

; then, we

have checked whether the less-privileged app A

′

could

be installed and execute properly. This process is de-

tailed below.

Dangerous permissions refer to the Android clas-

siﬁcation (req, 2017); there currently are 24 danger-

ous permissions. They are strictly related to the user’s

privacy as they allow app to access storage, camera,

GPS coordinates, user’s calendar and contacts, just to

cite a few.

We extracted all permissions requested by the apps in

our dataset by systematically parsing the app manifest

ﬁle, that contains all permissions required by an app.

Fig. 2 shows the distribution of dangerous permis-

sions in the dataset. Intuitively, the x-axis shows the

24 permissions ordered accordinglyto their frequency

on the dataset. The y-axis indicates the percentage of

apps requesting the permission. Fig. 3 plots the top

24 permissions requested by apps in the same way.

Testing RmPerm. A single automated test, for each

app A, runs as follow:

1. RmPerm gets the APK of app A, and builds up a

new app A

′

that does not require any dangerous

permission.

2. A

′

is installed on an actual Android device.

3. If this step fails, the original A is installed, in order

to verify whether the failure is due to the modiﬁ-

cation carried out by RmPerm or it is independent

from the permission removal.

4. If the installation of A

′

has been successful, its

behavior is tested by generating a stream of 512

pseudo-random user events with Monkey (mon,

2017), seeded by a random number n. Using dif-

ferent seed values leads to generate distinct se-

quences of user events. If A

′

fails, this can be due

either to the removalof permissions or to the pres-

ence of bugs in the original app A.

5. To ascertain this, we stimulate A with the same

stream of events, generated by seeding Monkey

with the same seed n.

Through previous steps, we can empirically as-

sess whether the removal of dangerous permissions

through RmPerm leads to failures. We carried out the

RmPerm: A Tool for Android Permissions Removal

321

100

INTERNET

ACCESS_NETWORK_STATE

*WRITE_EXTERNAL_STORAGE

ACCESS_WIFI_STATE

WAKE_LOCK

*READ_PHONE_STATE

VIBRATE

c2dm.RECEIVE

*GET_ACCOUNTS

*ACCESS_COARSE_LOCATION

*READ_EXTERNAL_STORAGE

*ACCESS_FINE_LOCATION

vending.BILLING

RECEIVE_BOOT_COMPLETED

*CAMERA

GET_TASKS

*READ_CONTACTS

SYSTEM_ALERT_WINDOW

*RECORD_AUDIO

gsf.READ_GSERVICES

USE_CREDENTIALS

WRITE_SETTINGS

SET_WALLPAPER

*CALL_PHONE

App %

Figure 3: Top 24 requested permissions in the dataset. Dangerous permissions are labeled with*.

Table 1: RmPerm: Performance and size statistics.

#Permissions SizeRatio Exec. time[s] Test results

AppName original new ∆ APK DEX PC Tablet Inst. Monkey

AdobeReader 6 3 3 1.16 1.00 5.70 27.41

CandyCrushSaga 10 8 2 1.08 0.99 6.17 30.83

Facebook 48 33 15 1.03 0.94 4.04 27.73

Instagram 25 17 8 1.19 1.01 7.13 30.15

LedFlashLight 9 8 1 1.06 1.00 6.60 27.47

MGuard 35 33 2 0.97 1.00 8.46 32.57 X n. a.

Shazam 20 13 7 1.04 1.00 7.25 35.49 X

Skype 45 33 12 1.13 1.00 11.49 44.82

Snapchat 15 7 8 1.07 1.00 5.14 25.17

Spotify 23 19 4 1.11 1.00 8.49 35.50 X

SwiftKey 14 11 3 1.18 1.00 9.62 31.90 X

Telegram 32 21 11 1.12 1.00 5.94 23.94 X

Twitter 31 22 9 1.45 1.00 8.76 28.19

Viber 56 41 15 1.21 1.00 7.65 29.35

Whatsapp 50 38 12 1.45 1.00 7.38 26.95 X

... ... ... ... ... ... ... ... ... ...

Average 6.8 4.9 2.1 1.1 1.1 3.9 27.1

Std deviation 5.9 4.4 2.4 0.2 3.1 3.3 9.8

SECRYPT 2017 - 14th International Conference on Security and Cryptography

322

(a) PC.

(b) Tablet.

Figure 4: Time required to repackage an app.

experimental assessment on a Dell XPS 9530 (Ubuntu

16.04, Intel i7-4712HQ @ 2.30GHz, 16GB RAM),

as well as on two Asus Z170CG (Android 5.0.2, In-

tel Atom x3-C3200 @ 900MHz, 1GB RAM) that we

used to install and (automatically) stimulate the apps.

Our results indicate that on 81,000 samples,

2,358 repackaged apps failed in step 2; that is, they

could not be installed successfully. Among these, 572

failed the step 3 too; this means that the correspond-

ing original APKs were already broken in some way.

Therefore, we discarded them and we considered a

new set, consisting of the original samples except for

the already broken APKs; that is, 81,000 − 572 =

80,428 apps. On this set, the 98% = 78,642/80,428

of repackaged apps have been successfully installed.

Then, we stimulated the installed apps according

to step 4. Among these, 66,051 were repackaged

and stimulated without crashes, while 14,377 (=

80,428 − 66, 051) failed and required further analy-

sis. Therefore, we applied step 5 to such apps obtain-

ing that 3,633 original apps crashed, thereby proving

that the same problems affected the original app, too.

For this reason, we also discarded these APKs. Sum-

ming up, the 86% = 66,051/76,795 of working apps

have been successfully modiﬁed, installed and exe-

cuted properly after removing all dangerous permis-

sions.

Discussion on Global Statistics. We analyzed the

average values for the whole dataset in terms of per-

mission removal, size of APKs and DEX after repack-

aging, as well as the time required for the whole pro-

cess. To this aim, Table 1 summarizes global and

some per-app statistics; the database containing all the

data can be freely downloaded (sql, 2017). Regard-

ing permissions, removing dangerous ones has led to

the removal, on average, of 38% of all app permis-

sions, as original apps have on average 6.8 permis-

sions while repackaged ones have 4.9, with a large

standard deviation value in both cases.

Repackaging phase does not alter the size of the

APKs signiﬁcantly; on average, repackaged APKs are

smaller by a factor of 1.1, with a standard deviation of

0.2. Modiﬁed DEX ﬁles are smaller on average, with

a factor of 1.1 and a large standard deviation of 3.1.

This is due to the fact that, when removing a set of

permissions P, we also remove all invocations to

void

API methods, requiring some permission p ∈ P, for

which we do not have explicitly deﬁned a redirection.

Furthermore, the size of the original manifest ﬁle is

decreased, but the size of DEXs is increased due to

the addition of custom classes/methods.

RmPerm Performance. We have measured the

time needed to remove all dangerous permissions

from an app, in two different use cases: when Rm-

Perm is running on a PC, and when RmPerm is run-

ning on an Android device. We have measured the

running time on all APKs of our sample set when run-

ning on the PC, while we have randomly picked 1,000

apps when RmPerm was run on the Android device.

Indeed, we were only interested to check whether run-

ning RmPerm on an Android device was practical and

if the running time was still linear in the size of the

DEX ﬁle. Fig. 4 shows the performance results: the

DEX size, say s, is generally a sensible parameter for

predicting the running time t; indeed, as shown by the

ﬁtted curve, t(s) is roughly a linear function. How-

ever, there are cases where a relatively small DEX

ﬁle is contained in a large APK; for instance, this is

the case for apps containing graphical/multimedia re-

sources, like games. In these cases, the time to copy

the resources from the original APK into the new one

may prevail the time needed to process and rewrite

the bytecode. This is the reason for the jitters in both

graphs. Results have been positive in both regards:

RmPerm: A Tool for Android Permissions Removal

323

while obviously slower, running RmPerm on the de-

vice requires less than 30 seconds on average, and the

times are still linear in the size of the DEX ﬁle, even

though the slope is less steep and there is a constant

cost, presumably due to the start-up time of RmPerm

on Android.

4 RELATED WORK

As shown by previous work (Felt et al., 2011b;

Felt et al., 2011a) , many Android apps are over-

privileged, that is, they request more permissions than

they actually need, thereby making the built-in per-

mission system rather inadequate to protect the users

and their privacy. To address these concerns, some

authors have proposed to enrich the built-in security

framework, by modifying the underlying operating

system, and requiring changes to the app sources, in

order to exploit the new features.

One of the top problems related to Android permis-

sions is the fact that, up to Android 6, the protection

offered by the system was an all-or-nothing choice

at installation time, when the user was asked to ac-

cept all permissions requested by the app, or to abort

the installation altogether. Moreover, with the current

permissions management, if an app requests a dan-

gerous permission, belonging to a certain permission

group, and the user agrees on its usage, then the user is

actually agreeing on accepting all permissions of the

same group. That is, any subsequent update of the app

can request, and be silently granted, any other permis-

sion belonging to an accepted group. Clearly, a ﬁne-

grained control was needed. For this reason, many

proposals, including ours, tackle the built-in permis-

sion system directly. Apex (Nauman et al., 2010) is

a policy enforcement framework that allows users to

selectively grant permissions to apps, as well as im-

pose constraints on the usage of resources. This im-

plementation requires some changes to the Android

code base so, while we share a similar goal, the strik-

ing difference is that we require no changes to the un-

derlying system.

Some work addresses privacy concerns directly:

AppFence (Hornyack et al., 2011) retroﬁts the An-

droid operating system to protect private data from

being exﬁltrated, by replacing shadow data, in place

of data that the user wants to keep private, and

by blocking network transmissions that contain data

the user marked for on-device use only. Mock-

Droid (Beresford et al., 2011) modiﬁes the Android

operating system to allow users to

mock

the app’s ac-

cesses to a resources . We use a similar

trick

to avoid

that apps crash due to unexpected exceptions, once

we have removed some of their permissions. How-

ever, we repackage apps and leave the operating sys-

tem untouched. Finally, TISSA (Zhou et al., 2011) is

a privacy-mode implementation in Android. All the

above proposals allow to run unmodiﬁed apps more

safely, at the cost of modifying the underlying An-

droid operating system, which severely hampers the

widespread adoption of these solutions.

Other proposals (Xu et al., 2012; Jeon et al., 2012;

Davis et al., 2012; Backes et al., 2013; Davis and

Chen, 2013; Reddy et al., 2011) bypass the need to

modify the underlying operating system by repackag-

ing arbitrary apps to attach user-level sandboxing and

policy enforcement code. These proposals, like ours,

use static analysis to identify the usage of API meth-

ods and instrument the bytecode to control the access

to these invocations. However, with the exception

of (Jeon et al., 2012), discussed below, all of these

do not remove permissions from the manifest of the

original app A, when creating the repackaged app A

′

;

thus, the underlying OS process that runs A

′

retains all

permissions of the original app A. This means that in-

complete/ﬂawed implementations of bytecode rewrit-

ing can lead to bypassing access control mechanisms,

e.g., by using Java reﬂection and/or native code (Hao

et al., 2013).

Dr. Android (Jeon et al., 2012) is a tool that uses byte-

code rewriting to replace Android permissions with

a speciﬁed set of ﬁne-grained versions, that are ac-

cessed through a separate service, called Mr. Hide.

In this case bytecode rewriting is adopted for replac-

ing API calls, used by the original app, with interpro-

cess communication primitives to query Mr. Hide ser-

vice. These primitives are rather expensive, so there

is a signiﬁcant slowdown on API invocations. With

our approach, instead, API invocations are “short-

circuited” or removed altogether, making repackaged

apps slightly faster than the original.

Finally, Boxify (Backes et al., 2015) has introduced a

concept of app sandboxing on stock Android, based

on app virtualization and process-based privilege sep-

aration. While this approach eliminates the need to

repackage apps, it requires a lot of additional code

(about 12 K lines of Java code, plus 3.5 K LoC of

C/C++, according to the paper), which should be care-

fully audited

. On the contrary, our approach simply

requires to customize 57 trivial Java methods. More-

over, Boxify requires the presence of a fully privi-

leged controller process, called Broker, which is an

attractive target for privilege escalation attacks.

Authors promised to make the source code available, but

at the time of writing, more than a year later, it is still un-

available.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

324

5 CONCLUSION AND FUTURE

WORK

We have presented a novel approach, and its sup-

porting tool, to enable Android users to better pro-

tect their privacy by selectively removing permissions

from any app, on any Android version. Indeed, our

approach, which removes permissions from the set

requested by an app by rewriting its APK, does not

require any modiﬁcation to the underlying operating

system and is thus compatible with all versions and

hardware architectures. The core idea is to remove

the (user-selected) permissions from the app mani-

fest, while redirecting API invocations, which need

those removed permissions, to custom methods that

return properly-crafted objects. These redirections,

that we introduce by rewriting the DEX bytecode,

aim at avoiding the throwing of (unexpected) secu-

rity exceptions at runtime, which would make the

app crash. We have implemented this approach in an

open-source tool, RmPerm, that we have used to as-

sess the effectiveness of our idea on a set of 81,000

real-world samples. The experimental results have

been encouraging; indeed, we have blindly removed,

from these apps, all dangerous permissions obtain-

ing that 86% of these rewritten apps can be installed

and executed without crashing. We plan to run more

ﬁne-grained tests to assess which subsets of danger-

ous permissions are more problematic. Obviously,

we could not expect a 100% success-rate: some apps

do need some of the permissions they request. How-

ever, as we expected, the majority of them can be run

equally ﬁne with a strict subset of the permissions

they originally requested. By using RmPerm, users

can freely decide where to draw the “privacyline” and

can run virtually any app without disclosing more per-

sonal information than they want to.

A limitation of our current implementation is that

apps using anti-tampering techniques can detect that

they have been rewritten. However, our experiments

indicate that, for the time being, Android apps very

seldom adopt anti-tampering techniques. Another

limitation is that RmPerm currently redirectsonly “di-

rect” API invocations, that is, we do not even try to

redirect API invocations executed through the use of

Java reﬂection or native code. We are considering

how to extend our approach to intercept those reﬂec-

tive invocations too; however, this limitation is not

severe as it may sound. With our approach, no Java

nor any native code could ever exploit a removed per-

mission, no matter what, since involved permission

requests are actually removed from the app manifest.

As remarked, the worst case scenario is a crash of the

less-privileged app, but not a privacy leak.

Android 6 has introduced the possibility of both in-

stalling apps without granting all requested permis-

sions at once, and toggling permissions at a later

time. So, the usefulness of RmPerm could appear

as dramatically reduced through the growing adop-

tion of the latest Android versions. However,

RmPerm offers a ﬁner grained permission selection,

which is unavailable in the Android user interface.

In fact, Android 6 allows the user to only grant/-

deny

groups

of permissions. For instance, because the

user-level permission group contacts consists of the

set of permissions

READ_CONTACTS

WRITE_CONTACTS

and

GET_ACCOUNTS

, an user cannot grant an app the

ability to read his/her contacts, without granting the

ability to write them too. While, by using RmPerm,

such a policy is easily enforceable.

REFERENCES

(2017a). Androguard permission mapping. https://github.

com/androguard. Accessed 2017-06-02.

(2017b). Android: distribution of market shares at

march 2017. https://developer.android.com/about/

dashboards/index.html. Accessed 2017-06-02.

(2017). Apkmuzzle app. https://play.google.com/

store/apps/details?id=it.saonzo.apkmuzzle.

(2017). dexlib2. https://github.com/JesusFreke/ smali/tree/-

master/dexlib2. Accessed 2017-06-02.

(2017). Empirical assessment with rmperm. https://github.

com/CSecLab/BatchRmPerm/tree/master/dbDump.

Accessed 2017-06-02.

(2017). Monkey. https://developer.android.com/studio/test/

monkey.html. Accessed 2017-06-02.

(2017). Requesting permissions. https://developer. an-

droid.com/guide/topics/permissions/requesting.html.

Accessed 2017-06-02.

(2017). Rmperm tool. https://github.com/CSecLab/ Rm-

Perm. Accessed 2017-06-02.

Backes, M., Bugiel, S., Hammer, C., Schranz, O., and von

Styp-Rekowsky, P. (2015). Boxify: Full-ﬂedged App

Sandboxing for Stock Android. In 24th USENIX Se-

curity Symposium.

Backes, M., Gerling, S., Hammer, C., Maffei, M., and von

Styp-Rekowsky, P. (2013). AppGuard – enforcing

user requirements on Android apps. In International

Conference on Tools and Algorithms for the Construc-

tion and Analysis of Systems. Springer.

Beresford, A. R., Rice, A., Skehin, N., and Sohan, R.

(2011). Mockdroid: trading privacy for application

functionality on smartphones. In Proceedings of the

12th workshop on mobile computing systems and ap-

plications. ACM.

Davis, B. and Chen, H. (2013). Retroskeleton: retroﬁtting

Android apps. In Proceeding of the 11th annual inter-

national conference on Mobile systems, applications,

and services, pages 181–192. ACM.

RmPerm: A Tool for Android Permissions Removal

325

Davis, B., Sanders, B., Khodaverdian, A., and Chen, H.

(2012). I-ARM-Droid: A rewriting framework for in-

app reference monitors for Android applications. Mo-

bile Security Technologies, 2012(2):17.

Felt, A. P., Chin, E., Hanna, S., Song, D., and Wagner, D.

(2011a). Android permissions demystiﬁed. In Pro-

ceedings of the 18th ACM conference on Computer

and communications security, pages 627–638. ACM.

Felt, A. P., Greenwood, K., and Wagner, D. (2011b). The

effectiveness of application permissions. In Proceed-

ings of the 2nd USENIX conference on Web applica-

tion development, pages 7–7.

Hao, H., Singh, V., and Du, W. (2013). On the effectiveness

of api-level access control using bytecode rewriting

in android. In Proceedings of the 8th ACM SIGSAC

symposium on Information, computer and communi-

cations security, pages 25–36. ACM.

Hornyack, P., Han, S., Jung, J., Schechter, S., and Wether-

all, D. (2011). These aren’t the droids you’re looking

for: retroﬁtting Android to protect data from impe-

rious applications. In Proceedings of the 18th ACM

conference on Computer and communications secu-

rity, pages 639–652. ACM.

Jeon, J., Micinski, K. K., Vaughan, J. A., Fogel, A., Reddy,

N., Foster, J. S., and Millstein, T. (2012). Dr. An-

droid and Mr. Hide: ﬁne-grained permissions in An-

droid applications. In Proceedings of the second ACM

workshop on Security and privacy in smartphones and

mobile devices, pages 3–14. ACM.

Nauman, M., Khan, S., and Zhang, X. (2010). Apex: ex-

tending Android permission model and enforcement

with user-deﬁned runtime constraints. In Proceedings

of the 5th ACM Symposium on Information, Computer

and Communications Security. ACM.

Reddy, N., Jeon, J., Vaughan, J., Millstein, T., and Foster,

J. (2011). Application-centric security policies on un-

modiﬁed android. UCLA Computer Science Depart-

ment, Tech. Rep, 110017.

Xu, R., Saïdi, H., and Anderson, R. (2012). Aurasium:

Practical policy enforcement for Android applica-

tions. In Presented as part of the 21st USENIX Se-

curity Symposium (USENIX Security 12), pages 539–

552.

Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. W. (2011).

Taming information-stealing smartphone applications

(on Android). In International conference on Trust

and trustworthy computing, pages 93–107. Springer.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

326