2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)
Enhancing Security of Android & IOS by
Implementing Need-Based Security (NBS)
Muneer Ahmad Dar
Scientist-B,
National Institute of Electronics & Information
Technology(NIELIT), Srinagar, India.
muneer@nielit.gov.in
Abstract— The most popular S martphone platforms i.e.
Android and iOS are equipped with the built-in security
features to safeguard their end users. Android, being an Open
S ource Mobile Operating S ystem, has some security
vulnerabilities. S uch limitations are also present in iOS which
is a proprietary platform with some open source components.
In this paper we will compare in detail the security features of
Android and iOS , with the intent to integrate the need based
security (NBS ) model in Android which selectively grants
permission to access resources on a S martphone at run time.
This paper proposes the implementation of a reverse
engineering process which restricts an app’s permissions and
provides a need based mechanism to access resources. The
repackaged app with need based security will run on all
devices that were supported by the original application.
Keywords—Android; iOS; open-source; Reverse-Engineering;
app; repackaged app;
I. INT RODUCT ION
Google’s Android and Apple’s iOS, world’s two
dominant Smartphone operating systems are competing on
every front and are claiming to have more than 500,000
apps for their respective operating systems. With a deluge
of new iOS and Android apps pouring into the market every
quarter, it's important to understand how much risk these
apps bring to a common user. Researchers are trying to find
out whether one mobile operating system has an edge in
terms of user privacy over another, when it comes to
securing users’ confidential data. It has been observed that
iOS is a safer platform as compared to Android. Recent
research found that only 0.7% of all mobile malware
targeted iOS, compared to the 79% that took aim at
Android. Researchers [12, 13, 14, 24] in Android and iOS
privacy found that the Smartphone operating systems
require improvements and enhancements in order to provide
adequate level of security to novice users. Third party
frameworks have been built through direct OS
improvements. These improvements have enhanced the
user-friendliness of the current permission system but have
resulted in several usability issues.
978-1-4799-4190-2/14/$31.00 ©2014 IEEE
Javed Parvez
Assistant Professor,
Department of Computer Science,
University of Kashmir, Srinagar, India.
javed_parvez@kashmiruniversity.ac.in
A less discussed method of improving privacy is to reverse
engineer and completely disable an app’s permission,
thereby preventing the app’s access to a resource and giving
the user additional control on the access to resources, at run-
time, by selectively allowing or denying the access by the
user. Research in Smartphone privacy can be broadly
categorized into permissions removal and fine-grained
permissions control, both of which will be addressed in this
paper.
The following sections outline the limitations of the current
permission-based security framework and explore how
Android apps can be made more privacy-oriented, user-
friendly and yet secure by granting need-based permissions.
We propose the implementation of a reverse engineering
process to restrict an app’s permissions and provide need-
based permissions to access the resources. In section II we
have a detailed comparison of security features of Android
and iOS. The relevant research work carried out earlier in
this field is reviewed in section III. In section IV we
provide a more detailed architecture of proposed need-
based, security-enhancing permission system. In section V
we present a proof-of-concept implementation of the
proposed NBS system. Finally, we draw our conclusions
and identify potential future enhancements in section VI.
II. A NDROID VS IOS
Android is a Linux-based mobile operating system
which incorporates its own security framework. Unlike a
desktop operating system where a user’s various
applications run under the same UID, Android-based apps
are individually partitioned from each other. Android
applications run in distinct and individual processes under
distinct UIDs each with different group of permissions to
access different resources of the device. Android apps have
no permission to read or write each other’s files/data or
code, and sharing of data/files between applications must be
done by the programmer explicitly [4].
The permission-based security model is the core
mechanism for securing access to various data or resources
in Android operating system. Although the app permissions
are categorized into different protection levels , the
728
 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)
allocation of these permission-based protection levels of
various resources/files is left to the programmer’s will and
his/her own understanding. This feature of giving more
liberty to the programmers may facilitate attacks by
malicious software and increase the number of
vulnerabilities in the security framework of the Android OS.
During the installation process of an application which can
be downloaded from the Google or any other market place
on the web the user is prompted by the Android framework
to accept a list of mandatory permissions required for the
successful installation of the app; the user may allow the
permissions or can deny all of the permissions in order to
install the application successfully or to abort the
installation.
The installation process prompts the user with a screen
listing all the mandatory permissions required to access the
various resources needed by the app to complete the
installation successfully. These permission requests are
defined in an important XML File called
AndroidManifest.xml. However, this security framework
has a few drawbacks [3]:
A user cannot use a policy of pick and choose i.e.
the user cannot selectively grant few permissions, while
rejecting others in order to install the app. Among the
list of permissions an app might call for a fishy
permission to access some resource among the other licit
permissions. The app will still be able to confirm the
successful, though insecure, installation.
Often, the novice users of the app cannot judge the
appropriateness and legitimacy of permissions for the
app they are installing. In some cases it may be well
understood, for example when a game app requests the
privilege to access the contacts in a Smartphone or to
access internet.
The Functionality of the app, which is imagined to
be possible with more number of appropriate
permissions, can still be attained with smaller number of
permissions or even with none at all.
In iOS, there is no mechanism of explicit permissions.
Thus, the user is not able to restrict the actions that an app
can perform. The application does not list what permissions
the application requests and the user has no control over the
permissions. All the apps have full access to all the iOS
device resources and can use these resources without the
permission of the user. Hence, after the installation of an
application on the Smartphone, it can execute any operation
under the pretext of executing an actual action. Chin et al.
[18] chose to test 30 Android users as well as 30 iOS users,
they noticed that Android users had more free apps than iOS
users downloaded from the market. Furthermore, around 20
% of Android users revealed that they always consider the
list of permissions when installing apps, and additional 40
% stated that they sometimes considered permissions while
installing the app. On the other hand Felt et al. [19] found
978-1-4799-4190-2/14/$31.00 ©2014 IEEE
that only 17 % of Android users pay attention to the list of
permissions during the installation of the app.
King [22] explicitly compared 13 Android and 11 iOS users
to find out their privacy concerns and expectations. This
study hypothesized that the review process by Apple causes
iOS users to be more inclined to trust the apps. However,
King and Kelley et al [21] discovered that Android users
often believe that Google reviews apps with regard to
permissions and malicious behavior. As a result no
substantial difference between platforms could be found
from this standpoint. Both Android and iOS users who
believed that the apps are pre-reviewed by their
corresponding OS provider, they felt safe when using apps.
Since Apple and Google chose vastly different ways of
notifying users of apps' usage of resources, some differences
in privacy concerns and privacy awareness have become
evident during the study among the users. iOS users were
mostly unaware of resource usage by the apps. In contrast,
Android users were aware of the list of resources and
permissions which is always shown during the installation;
although the majority of the end users felt that they do not
understand what the permissions mean. This feeling is
confirmed by other researchers [21, 19, 23]. Furthermore,
Android users are more concerned about privacy and more
privacy-aware than iOS users. iOS users thought that their
apps needed access to more resources , and were more
comfortable with resource sharing.
Based on the above comparison of the two Smartphone
operating systems, we can summarize the resilience and
vulnerability of Android and iOS with respect to various
attacks in the table below.
TABLE I. RESISTANCE OF ANDROID AND IOS AGAINST VARIOUS ATTACKS.
Resistance against Google Android Apple iO S
Malware Attacks 25% 100%
Web Based attacks 100% 100%
Social Engineering 0% 0%
Attacks
Resource/Service 50% 75%
Attacks
Data Loss 25% 50%
Data Integrity Attacks 25% 50%
III. EXIST ING RESEARCH W ORK
The number of permissions asked by the Android apps is
increasing. Pridgen & Wallach [6] researched with a sample
of 114,000 apps and it was found that the number of
permissions required by apps is increasing, and therefore,
posing a secrecy risk to Android users. The widespread use
of advertising in the apps is one of the main reasons for the
increase of permissions, suggested by Shekhar, Dietz &
Wallach [7], which requires the use of additional resources
and permissions in order to fulfill the need of data collection
and analysis. Studies by Felt et al. [8] and Kelley et al. [9]
729
 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)

suggested that most of the users have a limited which lists the permissions of the app. The permissions are
understanding of the permissions system – that is the thoroughly checked and unwanted permissions are
permissions system may not be effective in providing removed. For example, let us examine the DialKashmir app
adequate user privacy to a novice user. Felt et al. then put available on Google Play which gives all the details of
forth several recommendations and upgrades for improving Tourist places in Kashmir and contact details of important
the base Android OS, including depicting to the users the places like universities, government offices etc. The main
risks of allowing all the permissions to the resources . Kern permission this app may require is the INTERNET. If it
& Sametinger [10] took a different approach and includes MANAGE_ACCOUNTS which is the permission
recommended the implementation of individual permissions that allows the app to retrieve the user account information
control on a per app basis. This means that each app would from the phone, our system will remove those unwanted
have each of their permissions explicitly listed and the user permissions. After the removal of unwanted permissions
would be offered a choice of either denying or allowing the from the AndroidManifest.xml file, the second important
permission requests. In their research, Kern & Sametinger step that our system takes is to check the code in detail and
also suggested the use of extensions to the OS and third force the app to get the permission of the user at run time.
party apps in order to minutely control an app’s Researchers found that many end users have a poor
permissions, and developed their own app which allows a understanding of the Android permissions system [8] i.e. the
user to grant or deny a request as it occurs. Quang Do, permissions system may be insufficient in providing
Martini, B., Choo, K.-K.R [1] suggested the app adequate user privacy in the hands of a novice user [9]. In
permissions or resource removal in order to increase the order to give more authority to these novice users, our NBS
user privacy. They modified the app so that the permissions system provides a second level of security system by
are first selected and then removed. Generally this means an providing full details of the resources the app is accessing
app’s source code was required or the app is decompiled, and getting the permission of the user at run time to allow
modified to remove these unwanted permission requests and the access to that resource.
then recompiled with less permission. Some researchers
[15] found that while it is possible to modify and remove
permissions manually from an app via the manifest file, it
generally resulted in an app crashing at some point during
the process of de-compilation and recompilation. Berthome
et al. [16] proposed a combination of two apps, comprising
(1) the Security Monitor, a third party app installed onto the
device, and (2) the Security Reporter, which would be
injected into a decompiled target app. The injected app is
able to monitor the targeted app and can then report to the
Security Monitor with log details of the resources requested
by the app. Juanru, Dawu & Yuhao [17] used a similar
approach of decompiling Android apps to help them in their
Android malware research. Xu, Saïdi & Anderson [18]
developed a solution called Aurasium that has the ability to
automatically repackage the Android apps to have
sandboxing and security policy enforcement abilities in
order to enhance user privacy. They also identified that the
limitations of the existing research on user privacy is that
most research being done on Android requires major
modifications to the OS, resulting in usability issues. Our
research which is the implementation of Need based
security (NBS), which provides the run time permissions to
the user based on his needs is a relatively new but effective
approach as it does not require modifications to the OS
which may result in usability issues .

IV. PROPOSED NBS SYST EM.

The Need-Based Security (NBS) system designed to
enhance the privacy of the user at run time is shown in the
figure below. The main advantage of the proposed NBS
system is that the user is informed about the authorized and
unauthorized access of the resources at run time. The NBS
system decompiles the APK file which includes several files
particularly the most important file AndroidManifest.xml
Fig 1. Architecture of NBS System
The main advantage of our NBS system is that it does not
require any major modifications to the Operating System,
resulting in usability issues. Permissions removal and
getting permission approvals at run time is a relatively new

978-1-4799-4190-2/14/$31.00 ©2014 IEEE 730

 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)
but promising approach as it does not require modifications
to the Android OS.
V. IMPLEMENT AT ION OF NBS SYST EM.
A. Reverse Engineering.
Each Android app, after compilation is packaged in a single
file that includes the application code (.dex files) and
resources and is well known as the Android Application
Package (APK) file. The application package files with the
name given by the programmer must have .apk extension.
AndroidManifest.xml is one of the most important files in
the Android project structure. It contains all necessary
information about the App. Once an application is launched,
the first file the Android system seeks is the Manifest file. It
actually works as a roadmap to ensure that each application
can function properly in the Android system. In order to
implement the need based security, we have to extract the
various components of the APK file.
Fig 2. Contents of the APK file.
The files listed below are needed for the extraction of
various files in the .apk file and are downloaded from the
web.
apktool1.4.1.tar
apktool-install-windows-r04-brut1.tar
classes_dex2jar.src
jd-gui-0.3.5.windows
SignApk.
.
De-compilation and Recompilation: In order to get the
higher level code file and AndroidManifest.xml of our
sample app named NBS_Muneer.apk we have to type in the
command prompt “apktool if NBS_Muneer.apk” and then
type “apktool d NBS_Muneer.apk path_output”.
After the implementation of NBS system and removal of
unwanted permissions, we need to recompile the modified
files to repackage them to a modified APK file with NBS
system in place. We use the command “apktool b
path_recompile.apk” and a folder “build” is created in the
decompiled path. The .apk file will reside on the same
path. Still the app won’t work and when we try to push it
into system, the ROM will be stuck in BOOTLOOP XD, As
such we need to use signapk.jar and type “java –jar
signapk.jar certificate.pem key.pk8 your_repackaged_apk”.
978-1-4799-4190-2/14/$31.00 ©2014 IEEE
As we have to deal with the higher level code not the lower
level code, type the commands “jar xvf NBS_Muneer.apk
xxx.dex “ and “d2j-dex2jar xxx.dex” and we have xxx-
dex2jar file. Using dex2jar type in the following command:
“jar xvf xxx-dex2jar.jar”. We found two folders generated;
one with top level package name and other one is Android.
Now using Java Decompiler we can open the .class file just
extracted and it’s the original java code.
B. Removal of Unwanted Permissions.
Before a permission request is to be removed, it must be
determined that the permission is not required by the app
and can be removed. When selecting a permission to
remove or block, it must not affect the major functions of an
app. For example, social networking apps require Internet
access in order to function; as such the “INTERNET”
permission is required. Testing an app without Internet
access can be done simply by disabling all Internet
connections. The aim, therefore, is to remove dangerous
permissions from an app that should not be required. As
such, the permissions that are most commonly requested by
apps but not necessarily required are considered for
removal. In order to determine what permissions are
requested by each app, the app is first decompiled based on
the domain of the app and accordingly the permissions can
be removed if needed. The first step is for the user to
determine whether the app requires this permission. The
second step determines whether the app actually requires
this permission in order to function. For example, a
mapping app will require location resources such as the
GPS system in order to function. A note keeping app, on the
other hand, has no obvious need for such information. The
next two steps will determine whether the permission is
harmless and feasible to be removed from the app . For
example, many app permissions allow an app to access
sensitive information such as contact information, phone
logs, IMEI numbers, and SMS. A user may choose to
expressly disallow a particular permission even when the
app has well defined justifications. The feasibility of
removing an app’s permission is considered. Some app may
be so heavily integrated with a certain resource that the app
may not run without it.
Fig 3. Example of AndroidManifest.xml with Permissions.
C. Getting Permission approvals at Runtime.
In the previous sections we discussed the techniques for
improving user privacy by repackaging the .APK file and
we tried to identify the permissions which are of no actual
use to the app and may increase the security-related
731
 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)
vulnerability of the app. In this section, we move further by
giving more control to the user by allowing the user to
decide at run time whether the permission may be granted
or not. Whenever the app is trying to access any of the
resources for which the permissions are already granted a
second level of permission is incorporated wherein the
dialog box will appear and inform the user that the app is
about to access the resource. For example if the app is trying
to read the contacts, or, trying to read the
EXTERNAL_STORAGE, trying to send the SMS or trying
to access the IMEI number, the user will come to know and
if the user grants permission, only then the resource can be
accessed.
In order to implement the permission approvals at run time,
a thorough understanding of the code is required. For
example if our app is trying to modify the file for which the
approval is already granted by the user at the time of
installation we have to identify the block of code which is
trying to access the file and enclose that block of code with
the condition that if the user approves, only then the file
should be accessed.
Fig 4. Screen shot of run time permission approval
VI. CONCLUSIONS & FUT URE W ORK
We attempted to perform a detailed security comparison of
world’s leading Smartphone operating systems with the
intention to find out if one of them has an edge over the
other. After comparing, our research came to the conclusion
that the novice users are not aware of the permissions they
have granted at the time of installation particularly of the
978-1-4799-4190-2/14/$31.00 ©2014 IEEE
Android Users. We removed the dangerous permissions
from the app based on their functionality and then our
research provided the second level of security to the users,
without modifying the underlying structure of Android
operating system.
All the research undertaken in this paper on permissions
removal and run time permission approval was
implemented manually. Therefore future research
recommendations include automating the process. By using
heuristic methods, it may be possible to locate the block of
source code where permissions resources are used
automatically. The de-compilation of APK file,
modification of source code and recompilation of the
modified APK file could then be completely autonomous.
This leads onto further research work that could be
undertaken where this automated system with NBS
capabilities would be implemented in an Android device.
This would result in a self-contained, autonomous NBS
system that could enhance the privacy of apps on the device.
As a proof of concept, we have implemented our NBS
system on Android apps; but the same concept may be
implemented on iOS based apps as well.
REFERENCES
[1]. Quang Do; Martini, B.; Choo, K.-K.R., "Enhancing User Privacy on
Android Mobile Devices via Permissions Removal," System
Sciences (HICSS), 2014 47th Hawaii International Conference on ,
vol., no., pp.5070,5079, 6-9 Jan. 2014.
[2]. A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev
& C. Glezer, “Google Android: A Comprehensive Security
Assessment”, IEEE Security & Privacy Magazine, vol. 8,no. 2,
2012, pp. 35-44.
[3]. National Security Agency, “SELinux,” January 2009.
http://www.nsa.gov/research/selinux/.
[4]. E. Konstantinou and S. Wolthusen. Metamorphic virus: Analysis and
detection. Technical report, Information Security Group at Royal
Holloway, University of London, 2009.
[5]. Rafael Fedler, Marcel Kulicke and Julian Sch¨utte 2013 IEEE 8th
International Conference on Malicious and Unwanted Software:
“T he Americas” (MALWARE)
[6]. T . Book, A. Pridgen & DS. Wallach, “Longitudinal Analysis of
Android Ad Library Permissions”, arXiv preprint arXiv:1303.0857,
2013.
[7]. S. Shekhar, M. Dietz & D.S. Wallach, “Adsplit:Separating
smartphone advertising from application”,CoRR, abs/1202.4030,
2013.
[8]. A.P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin & D.Wagner,
“Android permissions: User attention, comprehension, and
behavior”, SOUPS 2012, p. 3.
[9]. P.G. Kelley, S. Consolvo, L.F. Cranor, J. Jung, N. Sadeh & D.
Wetherall, “A Conundrum of Permissions: Installing Applications
on an Android Smartphone”, Financial Cryptography and Data
Security 2012, pp. 68-79.
[10]. M. Kern, & J. Sametinger, “Permission T racking in Android”,
UBICOMM 2012, pp. 148-155.
[11]. S. Bugiel, S. Heuser & AR. Sadeghi, “myT unes: Semantically
Linked and User-Centric Fine-Grained Privacy Control on Android”,
T echnical Report T UD-CS- 2012-0226, Center for Advanced
Security Research Darmstadt (CASED), 2012.
732
 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT)

[12]. AR. Beresford, A. Rice, N. Skehin & R. Sohan, “MockDroid:

trading privacy for application functionality on smartphones”,
HotMobile 2011, pp. 49-54.
[13]. P. Hornyack, S. Han, J. Jung, S. Schechter & D.Wetherall, “T hese
aren't the droids you're looking for: retrofitting android to protect
data from imperious applications”, ACM CCS 2011, pp. 639-652.
[14]. W. Enck, P. Gilbert, BG. Chun, L.P. Cox, J. Jung, P. McDaniel &
AN. Sheth, “ TaintDroid: an information-flow tracking system for
realtime privacy monitoring on smartphones”, 9th USENIX
conference on Operating systems design and implementation, 2012,
pp. 1-6.
[15]. J. Helfer & T . Lin, 2012, “Giving the User Control over Android
Permissions”,http://css.csail.mit.edu/6.858/2012/projects/helfer-
ty12.pdf,accessed 25 March 2013.
[16]. P. Berthome, T . Fecherolle, N. Guilloteau & JF. Lalande,
“ Repackaging Android Applications for Auditing Access to Private
Data”, ARES 2012, pp. 388-396.
[17]. L. Juanru, G. Dawu & L. Yuhao, “Android Malware Forensics:
Reconstruction of Malicious Events”, ICDCSW 2012, pp. 552-558.
[18]. Chin, E., Felt, A. P., Sekar, V., and Wagner, D.Measuring user
confidence in smartphone security and privacy. In SOUPS (2012 ).

[19]. Felt, A. P., Ha, E., Egelman, S., Haney, A., Chin, E.,and Wagner, D.
Android permissions: User attention, comprehension, and behavior.
In SOUPS (2012).
[20]. Karrer, K., Glaser, C., Clemens, C., and Bruder, C.Technikanit •at
erfassen { der Fragebogen T A-EG. In 8. Berliner Werkstatt Mensch-
Maschine-Systeme. (2009).
[21]. Kelley, P. G., Consolvo, S., Cranor, L. F., Jung, J.,Sadeh, N., and
Wetherall, D. A conundrum of permissions: Installing applications
on an android smartphone. In USEC Workshop (2012).
[22]. ] King, J. How Come I'm Allowing Strangers to Go T hrough My
Phone?: Smart Phones and Privacy Expectations. under review,
2012.
[23]. Lin, J., Sadeh, N., Amini, S., Lindqvist , J., Hong, J. I., and Zhang, J.
Expectation and purpose: understanding users' mental models of
mobile app privacy through crowdsourcing. In ACM UbiComp
(2012).
[24]. Y. Zhou, X. Zhang, X. Jiang & V. Freeh, “T aming information-
stealing smartphone applications (on Android)”, T RUST 2011, pp.
93-107.
[25]. R. Xu, H. Saïdi & R. Anderso, 'Aurasium: Practical policy
enforcement for android applications', 21st USENIX conference on
Security symposium, 2012, pp. 27-27.

978-1-4799-4190-2/14/$31.00 ©2014 IEEE 733