2011 Frontiers of Information Technology

Enhancing Stealthiness & Efficiency of Android Trojans and Defense Possibilities (EnSEAD)
Androids Malware Attack, Stealthiness and Defense: An Improvement

Mohammad Ali, Humayun Ali and Zahid Anwar

School of Electrical Engineering and Computer Science (SEECS), National University of Sciences and Technology (NUST) Islamabad, Pakistan {10msccsmali, humayun.ali, zahid.anwar} @ seecs.edu.pk

Abstract In this work, we have studied Android Architecture from a security point of view. We have studied various defense mechanisms that are present in current Android Platform or are recently proposed. We took inspiration from Soundcomber a recent Android Trojan that steals sensitive information using various techniques. We enhanced the capabilities of Soundcomber in terms of its stealthiness and efficiency in malicious communication by identifying new covert channel and incorporating basic compression. We then developed a new Android Trojan Contact Archiver (steals user contacts) which inherits properties from Soundcomber, i.e. uses few and innocuous permissions, circumvents already-known security defenses, conveys information remotely without direct network access plus incorporates enhancements proposed by us. We also propose some defense possibilities to detect Contact Archiver covert communication. Our future work will be to block security attacks performed using our enhancements; when they are used in any Android malware. Keywords-android; security; trojan; malware; mobile phone security; covert channel

mediate the interaction between apps using security policies. Given these techniques, there is no apparent way for malware to perform malicious activities and communicate sensitive information to the master malicious server. However, [1] R. Schlegel et al. proposed and demonstrated that these security mechanisms can be evaded by developing sophisticated malwares. These malwares can collect sensitive information using least and non-malicious combination of permissions; even less than normal smartphone applications do. Plus, collected information can be communicated to master malicious server with the help of covert channels, i.e. utilizing various mechanisms present in smartphones for a different purpose than for what they are offered. By covert channels we mean mechanisms of the system used to send covert message/information that violate the security policy of Android (or any system) but seem legitimate and provide an implicit way to know what two or more applications want to convey [8]. Two major types of covert channels are Storage Channel and Timing Channel [8]. Storage channel means a shared mechanism between two processes/applications where one application is information writer and the other is information reader [8]. Timing channel means signaling of one process/application to the other process/application by modifying/changing system attributes [8]. Here we focus on using storage covert channel. In this work, we have enhanced the work of [1] R. Schlegel et al. by enhancing their Trojan, i.e. Soundcomber by finding a new technique to increase its stealthiness in communicating the collected sensitive information plus making it efficient by introducing compression of random credit card numbers with the help of old compression techniques. We developed an Android Trojan, namely Contact Archiver. It steals user contact list and sends it stealthily to master malicious server. Contact Archiver inherits some properties from Soundcomber [1]. In addition; it uses enhancements introduced by us. Rest of the paper is structured in the following way: Section II introduces the related work. Section III describes the design and architecture which is used to circumvent the security defenses; in conjunction with other capabilities. Section IV explains the implementation of Contact Archiver. Section V and Section VI evaluate the enhancements and presents conclusion respectively.
148

I.

INTRODUCTION

With the evolution in smartphone technology; it has provided users with so much ease to perform certain tasks on their smart phones instead on their computers (e.g. emailing, browsing, mBanking etc.) because smartphones have evolved as complete computing platforms, which not only support fullfledged OSes but also run very complicated applications as well. With this ease, it has also brought new challenges to the world of technology in form of security. Just like personal computers, smartphones are also prone to malwares and Trojans. A serious notice has been taken in academic and industrial circles [1] [2] [3] about these threats to smartphone platforms. Many anti-virus companies are now orienting their businesses to smartphone security in order to capture the market of securing smartphones from Trojans and viruses. A number of approaches have been implemented and proposed to avoid the installation and threats of malicious apps to smartphones. Android platform does this by running applications in separate Java virtual machines to minimize the effects of any attack and control the interaction between apps. [3] Propose a behavioral based detection of malware and [2] propose the mechanism to
978-0-7695-4625-4/11 $26.00 2011 IEEE DOI 10.1109/FIT.2011.35

II.

RELATED WORK

In this section, we discuss work done in the field related to smartphone security and Trojans; in the perspective of various smartphone platforms. Three main contributions are discussed which have cardinal influence on the enhancements proposed by us. Two of them are techniques and approaches for security defense of smartphones. Their pros and cons are also discussed. And third represents Soundcomber, which evades the defenses proposed in first two. Following are three contributions: A. Behavioral detection of malware on mobile handsets [3] A. Bose, X. Hu et al. in [3] presented a novel behavioral detection framework to detect mobile worms, viruses and other Trojans. It was a replacement of signature-based solutions which were actively used in certain mobile devices. They represented malware behavior on the basis of a key observation technique. According to the key observation, an application goes through a logical ordering of actions that individually does not seem harmful but when observed as a bunch, provides a malicious picture. The authors after studying twenty five distinct families of malicious mobile malware targeting Symbian Operating System generated a data base of signatures having malicious behavior. Symbian being the most successful mobile OS of that time was targeted more than any other mobile OS. They constructed signatures at runtime by monitoring application calls and certain system events. They named it 2-staged mapping technique. They differentiated the malicious behavior of malware to that of normal applications by training a classifier based on the concept of Support Vector Machines (SVMs). They evaluated their technique on simulated and real world malware. Their technique provided more than 96% detection. They found that the time and resources required for constructing the behavior-signatures from low level API calls are acceptably low for their deployment in mobile devices. It was a valuable contribution to protect smartphones against malwares. But later, [1] showed that sophisticated malware can be built over the smartphone platform to evade such defenses. As a result, sensitive data such can be accurately identified and collected at a small cost. B. Semantically rich application-centric security in Android[2] M. Ongtang et al. [2] presented Secure Application INTeraction (SAINT), an extended framework that provides install-time permission assignment and their run-time use as mentioned by the application providers in their policy. They considered the security requirements for smartphone and integrated the existing Android operating system with their SAINT framework to overcome the shortcomings from the malware attacks. By extending the existing Android application security architecture with SAINT policies they overcome the problems in Android security architecture. According to the new and modified architecture applications provide install time policies to regulate permission assignment that protects their interfaces. Both the caller and the callee applications communication is subjected to the SAINT security policy checking. The advantage of SAINT is that, it takes policy implementation to dynamic permission checking restricting
Identify applicable sponsor/s here. If no sponsors, delete this text box. (Sponsors)

access to applications themselves, their data etc. at runtime. Further they discussed some challenges in augmenting Android architecture with SAINT framework. Saint framework provided enhanced mediation of interaction among applications; but the framework lacked in defying the interaction of applications using covert channels. Like other computing systems, smartphones contain a set of built-in covert channels, which can be leveraged to transmit a small amount of sensitive information without direct access to the Internet; which was later exploited by [1] in the form of Soundcomber Trojan. C. Soundcomber: A Stealthy and Context-Aware Sound Trojan for Smartphones [1] R. Schlegel et al. in [1] presented Soundcomber Trojan which eludes the security protections proposed in both the mechanisms explained earlier in this section. They investigated the threat posed by malwares with access to onboard sensors to illicitly grab the private information of user. This capability of malwares has grown as serious threat to collect private user data. They detailed in their paper some malwares that exploit this vulnerability, i.e. grabbing data from sensors are currently transmitting data in raw form to remote servers in the form of audio and videos. These sensory malwares may cause damage but they can be easily detected and crushed by existing protections. This is why, because they convey heavy raw data which makes them less stealthy, let them incur substantial computation and communication during processing and transmission of data. Existing protection mechanisms like proposed in [2] and [3] e.g. by denying installation of applications with access to both sensitive sensors and the network. In their contribution, they presented a sensory malware namely Soundcomber which used on-board sensor, i.e. audio sensor of the phone to excerpt a small amount of target private/sensitive information. Soundcomber do this with few and innocuous permissions and successfully beats the known security preventions. Soundcomber intelligently pulls out sensitive information such as credit card and PIN numbers with the help of context aware analysis for targeted profiles, i.e. extracting sensitive data from recordings of calls made to IVRs where the user needs to tell or type sensitive information. Soundcomber does this for both tonebased and speech-based interaction with phone menu systems/IVRs. Soundcomber steals data locally by performing efficient and stealthy extraction of information from recordings and hence with the help of this, reduces the communication overhead for transmitting stolen data. Soundcomber detects the phone number dialed by analyzing audio and observes the list of last numbers dialed. As it circumvents known security defenses, hence it delivers the sensitive information to the remote server without having direct access to the internet. They also designed and implemented a defensive architecture that blocked Soundcomber with some modifications in the Android Kernel. They also identified some new covert channels, specific to smartphones for stealthy transmission of information without having direct network access.

149

Since our main inspiration comes from the abovediscussed contributions especially Soundcomber as we have used the same architecture for our Trojan too. We studied some literature related to using TCP/IP communication protocol and its certain mechanisms e.g. re-transmission of packets when they are dropped [4], network latency [5] etc. used in covert communication or used to establish a covert channel between two covert transceivers to get an in-depth understanding of different possibilities to exchange desired information covertly and to remain undetected and in our further work on Android platform security we plan to exploit Android IPC mechanisms in something similar way. S. K. Indumathi et al. in [4] discusses about packet re-transmission being used as a covert channel between two network nodes. Their technique requires the two nodes to be agreed upon some kind of hashing algorithm, and storing some known hash value in an IP Header field. In their technique the actual sender i.e. sender of the covert information is the one receiving the IP packets. And the actual receiver i.e. receiver of the covert information is the one sending the IP packets. Whenever any covert message sender wants to send covert information/message it keeps its respective hash and drops the packet with the same hash value in its IP Header. On re-transmission, the packet sender (covert message receiver) considers the corresponding message against the hash value sent as covert message to be communicated. In another contribution [7], they eliminate steganography in TCP/IP traffic using active warden agent through using signal fidelity. According to [6], active warden agent may increase network latency. As opposed to this passive warden agent provides greater help in detection of covert information sent in different header field and at different layers especially transport and network layers through monitoring timestamps, ISN, and IP ID [6]. III. DESIGN AND ARCHITECTURE

hence this data sent to app2 is sent out to the master server through the Internet. App1 did not have access to Internet, but it had access to the sensitive information. So app1 sent information to app2 and app2 had Internet permission and hence sent it out. This scheme looks good but framework (SAINT) proposed by [2] can block such inter-process communications on the basis of policies provided by providers of apps. In the example given above; lets think of a policy that the browser is not to receive data from any app which is accessing any sensitive resources. A. How Soundcomber did it?: Soundcomber used a modified version of Plan B, i.e. having two apps, but communicating in a different way. Architecture used by soundcomber is as follows (fig-01) in [1]:
FIGURE I. DESIGN OF SOUNDCOMBER

There are two apps in this architecture, namely soundcomber app and deliverer app. Soundcomber collects the sensitive information (voice/credit card nos./contacts) and sends it to the deliverer app through a covert channel. Soundcomber app uses four (04) different kinds of covert channels to share information with deliverer app. Four of them are as follows: 1. 2. 3. 4. Vibration Settings Volume Settings Screen Brightness Settings File Locks

There are two possible architectural ways of performing malicious activity similar to that of a Trojan, i.e. stealing information and sending it out to a malicious master server. a. Plan A There is only one app on the Android phone. This app grabs the sensitive information and sends it to the master server. The problem with this architecture is that the user can observe during the installation of an app that it is going to access both the sensitive data plus internet, e.g. an app wanting permission to both the contact list and internet. Hence the user can reject its installation. Also if the user ignores it, it is proposed in recent proposals [3] that a reference monitor could deny installation of such apps, i.e. apps asking for both mic/contacts access and other dangerous permissions. b. Plan B To overcome the issues of Plan A, lets examine the scenario when there are two apps, i.e. app1 and app2. App1 grabs the sensitive data and sends that data to App 2, detectably, through any legitimate method, e.g. IPC or common files etc. App2 is a general normal app e.g. a web browser and

The covert channel using vibration settings, volume settings and screen brightness settings makes use of levels of settings provided by Android phone, e.g. volume can be divided into 10 different levels, each level representing different intensity of volumes. Now soundcomber app changes these levels to transmit bits of information to the deliverer app, as deliverer app is observing the changes in volume settings. Hence information is exchanged this way between these two apps. The same logic is used in case of the other two methods, i.e. using vibration and screen brightness settings. File locks covert channel bit different than others. In this method, there are a number of files. File locks are used between apps to synchronize the write and read of data on a separate file.

150

B. How Contact Archiver enhances Soundcomber Architecture?: Enhancement in Stealthiness to Architrecture through the addition of new covert channel Our contribution to the architecture of soundcomber in the respect of stealthiness is the identification of a new covert channel, i.e. exchanging information using file permissions. We implemented this covert channel in Contact Archiver Trojan (which comprises a collector app and a deliverer app). Method of file permissions as a covert channel uses one file for synchronization. Both of the apps (collector and deliverer apps) continuously monitor the presence of this file (either created or deleted). Collector app only continues its work if private file (which is used to synchronize) is deleted. Initially private is not created hence collector app can collect data. After its done collecting the data, it writes file permissions on 10 different files. Permissions are written to files in a way that permissions contain bits of data to be transmitted. After writing permissions, collector app finally creates private file. Deliverer app wakes up as soon as private file is created. Deliverer app then reads the permissions of those 10 files; i.e. it is receiving information through file permissions from collector app. After deliverer app is done reading permissions, it converts it into the meaningful information and then transmits it to master server; remembering that collector app had access to sensitive resource and deliverer app has access to the internet. Hence information is shared and transmitted to master server this way using the file permissions methods as covert channel. Algorithm for using file permission as covert channel can be seen in section IV (Implementation). Enhancement in Efficiency of Architrecture using basic compression Since information to be transmitted is like credit card numbers (CCN), pins or contact number etc. In case of CCN and pins; both of them are totally random. Hence according to Shannon Limit Theorem, it is not possible to compress CCN. In case of contact numbers; we dont have probabilities associated to them; hence there is no probability distribution available for them. If we calculate probability distribution for contact numbers belonging to Islamabad; it would produce inefficient results for numbers that belong to Lahore. If we calculate probability distribution for contact numbers of more than one city; then it would not be efficient if all the contact numbers to be transmitted are from only one city. Hence sensitive information to be transmitted cannot be compressed. But still there is a way to compress these numbers, a little bit to reduce the transmission overhead. If 4 bits are used for each number from 0-9, then credit card number would require 4*16=64bits/CCN and a contact number (in Pakistan) would require 9*4=36 bits/number. But if we convert 16 digits of CCN directly to its binary representation then it can be represented in 54 bits, hence 10 bits of compression is achieved. Similarly in case of contact numbers, 6 bits of compressions is achieved. So credit card numbers would require 54bits/CCN and for phone numbers, it becomes 30bits/number.

IV.

IMPLEMENTATION

Android applications are primarily written in Java and compiled into a custom byte-code (DEX). Each application executes in a separate Dalvik virtual machine (DVM) interpreter instance running as a unique user identity. From the perspective of the underlying Linux system, applications are ostensibly isolated. This design minimizes the effects of a compromise, e.g., an exploited buffer overflow is restricted to the application and its data. Development of Contact Archiver Trojan is done in Eclipse IDE with Android Development Tools (ADT) Plugin. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. Android Development Tools (ADT) is a plugin for the Eclipse IDE that is designed to give a powerful, integrated environment in which to build Android applications. ADT extends the capabilities of Eclipse to allow quick set-up of new Android projects, create an application UI, add components based on the Android Framework API, debug applications using the Android SDK tools, and even export signed (or unsigned) APKs in order to distribute the application. Developing in Eclipse with ADT is highly recommended and is the fastest way to get started. With the guided project setup it provides, as well as tools integration, custom XML editors, and debug output pane, ADT gives an incredible boost in developing Android applications. Installing and configuring the Android programming development environment step by step can be found on [9]. Development of Contact Archiver Trojan is done on a machine having specs: Core i5 2.4 GHz machine with 2GB of RAM. It has been developed for and deployed on Android AVD 2.31. As Contact Archiver Trojan comprises of two parts/apps, i.e. Collector App and Deliverer App; the collector app performs its function according to the following algorithm:
FIGURE II. COLLECTOR APP ALGO

1. Get contact list. 2. Take a list. contact from the contact

3. Wait until private file exists (file doesnt exist at this stage). 4. Convert the contact number to a 30bit number. 5. Take 3 bits from the number and set file permission as r,w,x [Continue this until bit or file exhaustion]. 6. Create private file. Meanwhile, deliverer app is continuously monitoring the presence of private file. As soon as private file is created by

151

collector app, deliverer app wakes up and performs according p to the following algorithm:
FIGURE III. DELIVERER APP ALGO L

1.

Wait if exist.

private

file

doesnt

2.

r Read file permissions respectively from 1 to 10 as r,w,x (r read, write, execute) and store them as bits. t Convert these 30 bits to a number and the number to a str ring (which is a contact number).
r Transmit contact number to master server.

Archiver were done on a simple computer having specifications: Core i5 2.4 GHz machine with 2GB of RAM. It z has been deployed on Android AVD 2.31. In our opinion, no d matter how powerful is the machine, it can only aid in developing the app using Eclipse. However, once it is E developed and deployed, it dep pends only on the capabilities of AVD or Android Phone on which it is installed. Hence performance evaluated of the new Trojan on an AVD is similar to doing it on an Android Sma artphone having similar specs to that of AVD.
mbers were saved in the contact Real world telephone num list of AVD. Number of conta transferred in given time is acts the important measurement of performance for covert channels, p which is bandwidth bits/secon from Archiver App to the nd; Deliverer App. 30-bit (4-by yte) messages were exchanged through the channel between the respective apps to measure bandwidth (provided with that no error occurs). n

3.

4.

5.

Delete private file.

ntact Archiver that An online demo of the working of Con shows the permissions used by Contact Arch hiver Apps, which are very less than any general app on the An ndroid Phone (e.g. web browser which even uses GPS of the smartphone) and e newly identified covert channel of file permis ssions is explained and available on: http://daudhumayun.webs.com/Android/covertChannelFile Permissions.pps) Demo of stealing the contact list of the us is given. Firstly ser contact list of the Android Phone (on AVD is shown; then D) Contact Archiver is triggered. The scenario given to the code was that: Contact Archiver is triggered with the push of button on collector app. In real world scenario, con ntact Archiver can be triggered when a new contact is added or when smartphone r has just booted or on timely basis (this could be done by using d Android system level broadcasts). Afte collector was er triggered, it performed its operation as expla ained earlier in this section. Malicious Master Server was setup on same machine using IIS 7.5. At the step 4 of Deliverer App, it delivered contact list to the master server. And hence re eceived contact list on the master server, shown through browser of machine.

B. Experiment Results It achieved the bandwidth of 692.5 bps to transmit to the master server (with only 10 files involved in the covert 0 channel); which is pretty acc ceptable if seen from both the computational overhead and time taken point of view. The t bandwidth achieved by file permissions covert channel is greater than any of the covert channels used by Soundcomber (Table-01). If this covert chann used in Soundcomber along nel with its operation of extracting credit card number from and IVR call; then it could be sho own that it would be practical, pleasingly fast; computationall feasible and less time taking ly than any other covert channels used by soundcomber for large data transfers.
TABLE I.
Trojan & Channel Name:

COMPARISON OF SOUNCOMBER AND CONTACT ARCHIVER COVERT CHANNELS IN TERMS OF BANDWITH N

Soundcombers Channel with Highest Bandwidth: File Locking Channe el
Contact Archivers Channel with Highest Bandwidth: File Permissions Channel

Bandwidth:

685 bps

692.5 bps

Following graph shows the amount of compression achieved as the content (cont tact numbers to be transferred) increases:
GRAPH I. COMPRESSION ACHIEVED AS NUMBER OF CONTACTS C INCREASE

V.

ULTS EVALUATION AND RESU

No. of bits of compression

This section evaluates the performan nce and overhead incurred by enhancements introduced by Contact Archiver. Important thing to be tested was computatio onal overhead and time taken by the Contact Archiver when it performed its n operations of stealing, sharing and transmit tting the sensitive information. Evaluation study is aimed at assessing the efficiency and performance of covert channel used by Archiver l and Deliverer app to share contacts and also purpose served by basic compression. We also evaluate the effe on performance ect by increasing number of files involved in covert channel i transmission. A. Experiment Settings ed Experiment was designed which studie covert channel. Development of Contact Archiver Trojan an experimentation nd of enhancements made to Soundcomber in th form of Contact he

600

600 400 200 0 7 10

Num mber of Contacts

300 180

42

60

30

50

100

152

We also evaluated the impact on bandwidth if number of files involved in the covert channel is increased from 10 to greater values. Table-2 elaborates on the resultant change in bandwidth.
TABLE II. CHANGE IN BANDWIDTH OF COVERT CHANNEL BY INCREASING NUMBER OF FILES INVOLVED IN COMMUNICATION No. of Files Bandwidth:

10
692.5 bps

20
1250 bps

30
1807.5 bps

friendly plus it allows a great deal of usability in all respects, but security of users information is a great concern and increasing day by day as for one security loop hole, there comes a defense mechanism but another security hole requires a newer defense mechanism and this will go on until Android platform becomes secure in all respects. Future work may also include identifying more covert channels and/or enhancing Android Trojans in other respects and then developing defense architecture against them. VII. DISCUSSION AND CONCLUSION This research work has revealed that security is a primary and extremely important aspect in smartphones technology and still there are new avenues that need to be explored both in terms of identifying security loop holes in the architecture of Android and also securing them through wide and effective security defense mechanisms. Another important aspect that has come to the view is that, a lot of work has been done to block malwares in android phones through a number of different techniques, but almost no work is done in defining mechanisms/frameworks, policies and implementing them to block covert channels. No matter that Android platform is user friendly and developer friendly plus its allows a great deal of usability in all respects but security of users information is a great concern and increasing day by day as for one security loop hole, there comes a defense mechanism but another security hole requires a newer defense mechanism and this will go on until android platform becomes secure in all respects. REFERENCES
[1] [2] R. Schlegel et al., Soundcomber: A Stealthy and Context-Aware Sound Trojan for Smartphones, in NDSS, February 2011. M. Ongtang, S. E. McLaughlin, W. Enck, and P. D. Mc-Daniel, Semantically rich application-centric security in android, in ACSAC, pp. 340349. IEEE Computer Society, 2009. A. Bose, X. Hu, K. G. Shin, and T. Park, Behavioral detection of malware on mobile handsets, in MobiSys 08: Proceeding of the 6th international conference on Mobile systems, applications, and services, pp. 225238, New York, NY, USA, 2008. ACM. S. K. Indumathi et al., Towards Designing A Stealthy Communication Channel For Hidden Information, in International Journal of Engineering Science and Technology (IJEST), Vol. 3 No. 5, May 2011. ISSN: 0975-5462. D. Hintz. Covert Channels in TCP and IP Headers [Online]. Available: http://guh.nu/projects/cc/covertchan.ppt/ Steven J. Murdoch et al., Embedding Covert Channel Into TCP/IP, Draft for Information Hiding Workshop 2005 proceedings (Revision 1159: July 29, 2005). Gina Fisk et al., Eliminating Steganography in Internet Traffic with Active Wardens. Chapter 8, A Guideline on Covert Channels, Department of Defense Trusted Computer System Evaluation Criteria, 1985 S. Shin, M. Garoche. Building "Helloworld" Android Application Step by Step [Online]. Available: http://www.javapassion.com/

Ideally, by increasing number of files in our file permission covert channel, the bandwidth should also increase proportionally and with the same rate but it does not. The main reason behind this is that, setting file permission introduces a little processing overhead, each time bits are transferred covertly. This processing overhead increases constantly as we increase number of files to transfer bits. We would suggest an intelligent decision on the number of files to use for bits transference keeping in view the performance, bandwidth needs, and last but not the least stealthiness of the Trojan. VI. DEFENSE POSSIBILITIES

As future work, we propose our defense architecture for Android platform, since the defense mechanism provided by soundcomber in order to block its malicious activities is just limited to soundcomber only; their defense architecture cannot block Contact Archiver kind of Trojans from stealing information. Hence there is a need of blocking covert channels so as to block this class of Android Trojans. We propose to block the covert channel of file permissions by limiting the rights of apps by restricting them to do not delete files of other apps, i.e. an app can delete only its files and not files of any other app. Hence this can effectively stop the covert channel through file permissions. Other covert channels used by soundcomber can also be blocked by limiting the usage of respective settings, i.e. apps which are changing volume, vibration or screen brightness settings speedily should be stopped and marked as malicious. Future work includes the implementation of above explained defense architecture by modifying the kernel of Android OS to include such mechanisms or reference monitors to implement these defense mechanisms. Another aspect needs to be explored is to transmit the stolen data as efficiently as possible using a compression technique (may be a hybrid technique) either to transmit contact list, credit card number or any other random numbers. This research work has revealed that still security is a primary and extremely important aspect in smartphones technology and still there are new avenues that need to be explored both in terms of identifying security loop holes in the architecture of Android and also securing them through wide and effective security defense mechanisms. No matter that Android platform is user friendly and developer

[3]

[4]

[5]

[6]

[7] [8] [9]

153