android malware_report.docx

36
ANDROID MALWARE ANDROID MALWARE A SEMINAR REPORT SUBMITED IN THE PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE AWARD OF BACHELOR OF ENGINEERING IN COMPUTER ENGINEERING BY: Name Roll No. 1.VISHAKHA NAYAK 110CE56 2.DEVYANI PATIL 110CE60 3.AKSHAYA SANGHAVI 110CE68 1 S.I.E.S.GST, Dept. of Computer Engineering

Upload: devyanipatil

Post on 02-Oct-2015

1 views

Category:

Documents


0 download

TRANSCRIPT

ANDROID MALWARE

ANDROID MALWARE

A

SEMINAR REPORT

SUBMITED IN THE PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE AWARD OF BACHELOR OF ENGINEERING IN COMPUTER ENGINEERING

BY:

NameRoll No.

1.VISHAKHA NAYAK 110CE56

2.DEVYANI PATIL 110CE60

3.AKSHAYA SANGHAVI 110CE68

DEPARTMENT OF COMPUTER ENGINEERING

S.I.E.S. GRADUATE SCHOOL OF TECHNOLOGY

NERUL, NAVI MUMBAI- 400 706.

UNIVERSITY OF MUMBAI

2012-2013

S.I.E.S. GRADUATE SCHOOL OF TECHNOLOGY

NERUL, NAVI MUMBAI-400 706.

DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE

This is to certify that, this is a bonafide record of Seminar Android Malware carried out by the following students of third year Computer Engineering.

Sr. No.

Name

Roll No.

Exam No.

1

VISHAKHA NAYAK

110CE56

2

DEVYANI PATIL

110CE60

3

AKSHAYA SANGHAVI

110CE68

This Seminar is carried out for the partial fulfillment of requirement for the Degree of Bachelor of Engineering (B.E) in Computer Engineering from University of Mumbai, during the academic year 2012 13.

Guide Head of Department Principal

(Mrs. Pranita Mahajan)(Computer Department) (S.I.E.S. GST)

We have examined this report as per University requirements at SIES Graduate School of Technology, Nerul, Navi Mumbai on _________________

Name: _______________Name: _______________

Sign: _________________Sign: _________________

(Examiner 1) (Examiner 2)

Acknowledgement

We would like to thankour guide of this seminar, Mrs Pranita Mahajan for the valuable guidance and advice. She inspired us greatly to work in this seminar project. Her willingness to motivate us contributed tremendously to ourseminar project. We would alsolike to thank her for guiding us in taking up the topic and understanding it. Besides, we would like to thank the authority of SIES GST for providing us with a good environment and facilities to complete this project. Also, we would like to take this opportunity to thank to the Department of Computer Engineering for helping us with the project. A Special thanks to the seminar in charge Mr. Sunil Punjabi for his efforts in organizing and managing the seminar groups. This seminar project gave us an opportunity to learn about Android operating system and Android malware.

Abstract

Over the last three years, Android has established itself as the largest-selling operating system for smartphones. The popularity and adoption of smartphones has greatly stimulated the spread of mobile malware, especially on the popular platforms such as Android. In light of their rapid growth, there is a pressing need to develop effective solutions. However, the defense capability is largely constrained by the limited understanding of these emerging mobile malware and the lack of timely access to related information.

In this paper, a brief understanding of the different kinds of application components in Android is presented and then how the different components coordinate among themselves to achieve a task is explained. The android security system is also studied. The focus is on the Android platform and aim to systematize or characterize existing Android malware. In addition, systematical characterization of these malware from various aspects, including their installation methods, activation mechanisms as well as the nature of carried malicious payloads is done. The characterization and a subsequent evolution-based study of representative families reveal that they are evolving rapidly to circumvent the detection from existing mobile anti-virus software. The results of the study of android anti-virus software clearly call for the need to better develop next-generation anti-mobile-malware solutions.

Table of Contents

I. Introduction

9

II. Malware Characterization

14

A. Malware Installation

1. Repackaging.

2. Update Attack

3. Drive-By Download

14

14

14

15

B. Activation

17

C. Malicious Payloads

1. Privilege Escalation Attack

2. Remote Control

3. Financial Charge

4. Information Collection

18

18

18

19

20

D. Permission Uses

21

III. Malware Detection

22

IV. Conclusion

23

V. References

24

Literature Survey:

Dissecting Android malware: Characterization and Evolution by Yajin Zhou and Xuxian Jiang, in IEEE Symposium on Security and Privacy (2012) [1]reveal that the malware samples have been collected and a data set of 49 families is identified in one year. This dataset helps to mitigate the malware threats and shed light on possible defenses. A study was conducted about the behaviour of android malware. The malicious apps seem to show peculiar behaviour in case of permissions as they request more permissions than the benign apps.

Amiya K. Maji, Fahad A. Arshad, Saurabh Bagchi An Empirical Study of the Robustness of Inter-component Communication in Android in IEEE journal, 2012. [2]explains how in a collaborative environment, applications share data with each other using a communication mechanism called ICC (inter-component communication).

CNN technical report [4]: This report reveals that the smartphone sales have tripled in the past three years. Thus, the adoption of smartphones has witnessed a tremendous increase in a short period of time, which also becomes the reason for prevalence of malware in these smartphones.

CNET technical news report by CNET [5]: Android has commanded the worldwide smartphone market share in the third quarter of 2012. Android's operating system is apparently the most widely used mobile operating system for smartphones.

Malicious Mobile Threats Report 2010/2011 [6]:The share of Android in malware is higher and is growing constantly.

developer.android.com [7]:The permissions related to security-enforcement are stored in file called ANdroidManifest.xml, and applications use this to share contents with each other.

INCA blog on security threat and malicious programs information [5]: Generation of malicious apps by repackaging the app code is explained. The code is just modified to steal user information like the call history, messages history and even the passwords.

Wikipedia QR codes [6]:QR codes are matrix bar codes that are optical machine-readable labels attached to items that record information related to the item. A QR code is read by an imaging device, such as a camera, and formatted until the image can be appropriately interpreted. Data is then extracted from patterns present in both horizontal and vertical components of the image.

Kaotic Neutral blog: Using QR codes to attack smartphones [7]:The QR codes can be used to hide malicious codes, which when scanned by the users smartphone, will redirect them to a malicious website and steal the user information.

I. Introduction:

In recent years, there is an explosive growth in smartphone sales and adoption. According to CNN [4] smartphone shipments have tripled in the past three years (from 40 million to about 120 million). In a very short time Google's mobile operating system (OS) Android has become the number one choice for smartphones. Googles Android contributes to almost 75% of the mobile OS market share [5]. There are three reasons for this popularity. Firstly, Android is Open Source. This open source code and permissive licensing allows the software to be freely modified and distributed by device manufacturers, wireless carriers and enthusiast developers. Secondly, Android is free. Android, since the day it was launched, has been available free of cost and Google made it clear that it will be free in future as well. The OS caught the attention of manufacturers across the world and many initially adopted it for low cost smartphones. Thirdly, Android Market created an opportunity for millions of application developers around the globe to show their skills and come up with newer applications for Android phones. Its users therefore have a wide variety of applications to choose from and can customize their phones for a personal experience.

Unfortunately, the increasing adoption of smartphones comes with the growing prevalence of mobile malware. As the most popular mobile platform, Googles Android overtook others to become the top mobile malware platform. It has been highlighted that among all mobile malware, the share of Android-based malware is higher than 46% and still growing rapidly. [6] Another recent report also alerts that there is 400 percent increase in Android-based malware since summer 2010. Given the rampant growth of Android malware, there is a pressing need to effectively mitigate or defend against them. For this, the android family is characterized based on their detailed behavior breakdown, including the installation, activation, and payloads. To cater to this, a dataset of 49 families of android malware, discovered from Aug 2010 to Sept 2011[1], have been considered. However, without an insightful understanding of the androids underlying framework and its security mechanisms, it is hard to imagine that an effective mitigation solution can be practically developed.

Android Architecture:

The Architecture of Android consists of the following:

(a) Android architecture

1. Application: Android phones usually come with some default applications such as email client, browser, calendar, SMS, maps, etc. The applications are programmed using Java.

2. Application Framework: Android developers are offered the utilization of information of access location, set alarms, device hardware, run background services, etc. Android developers also have access to the framework APIs that is also used by the core applications. Reuse of components is exercised by the application architecture design.All applications have a set of systems and services underlying them:-

Views: These are used to build applications, such as, text boxes, grids, buttons, and also a web browser that is embedded.

Content Providers: These allow applications to share their own data and to access information from other applications.

Resource Manager: This provides access to resources (non-code) such as graphics, layout files and localized strings.

Notification Manager: Custom alerts are displayed on the status bar using a notification manager.

Activity Manager: It provides a common navigation back-stack and it also deals with the lifecycle of an application.

3. Libraries: Android is equipped with a set of C/C++ libraries that is used by several components of the system. These libraries are provided to the developers through the Android Application Framework.Some of the core libraries along with their functionality is shown below:-

System C Library: It is used for embedded Linux-based devices. It is an implementation of the C system Library.

Media Libraries: These libraries basically support recording of audio and video formats, playback and static image files, such as, JPG, AMR, MP3, PNG, AAC, MPEG4 and H.264.

SGL: This comprises the 2D graphics engine.

SQLite: This is a relational database engine that is accessible to all applications.

Surface Manager: it controls the access to the 2D and 3D graphics layers from various applications and to the display subsystem.

4. Android Runtime: Android has some core libraries that offer most functionality that are also available in the core libraries of the Java programming language. All android applications run in their own processes with their own instances of the DVM (Dalvik Virtual Machine). Dalvik allows a device to run several virtual machines efficiently. DVM executes files in the .dex format. The DVM is dependent on the Linux kernel for underlying functionalities such as low-level memory management and threading.

5. Linux Kernel: Android services, like process management, driver model, memory management, security and network security, of the core system depends on Linux version 2.6. The kernel also behaves as a layer of abstraction between the software stack and the hardware.

An android package consists of the compiled java code and any resource and data files required by the application.

An android application comprises of several components that use Intent messages to communicate with one another. These components are summarized below:

Activity: It is the visual interface that is utilized by the user in order to process actions.

Broadcast Receiver: This component receives and reacts to broadcast announcements/messages by initiating an Activity. It has no user interface.

Service: This component has no user interface, but runs in the background for an imprecise period of time.

Content Provider: In order for an application to make data available to other applications, it makes use of a content provider that is a type of database SQL Database).

ICC (Inter-Component Communication) mechanism [2] is based on Intents which is a mechanism for passing messages which also includes the kind/type of action to be carried out. Intent, a data container, is an abstraction for an action to be performed and forms the core of Androids IPC mechanism. An intent encapsulates action, data, component, category and extra fields in its object. The Intent messages can be either sent to a particular component or broadcast to the Android framework which will then forward the message to the appropriate component. Action strings, that specify the type of task to be preformed, help in specifying the intents. Based on the action strings, the Android system then takes a decision as to which component is best to carry out the essential task.

The AndroidManifest.xml file contains all the permissions and metadata related to the security enforcement policy. The tag indicates the components that can access it and tag is used to indicate the intents that can be resolved [7].

Android security:

Android provides two important security mechanisms that are different from traditional Unix systems, i.e., application sandboxing and permissions.

1. Sandboxing: Sandbox is an isolated environment for the execution of an application. Each app has its own sandbox which contains apps data and code. This is implemented by giving each Android application (*.apk) its own unique UID at install time that remains fixed throughout its lifetime. This is different from traditional desktop systems where a single user ID is shared among different processes. Android then, runs the app as a separate process with the assigned UID.

(b) Sandboxing.

2. Permissions: Application permissions is a Mandatory Access Control (MAC) mechanism for protecting application components and data. In its simplest form, access to each component is restricted by assigning it an access permission label; this text string need not be unique. Developers assign applications collections of permission labels of those components which the application needs to access. When a component initiates ICC (Inter-Component Communication), the reference monitor looks at the permission labels assigned to its containing application and if the target components access permission label is in that collection then it allows ICC establishment to proceed. If the label isnt in the collection, establishment is denied even if the components are in the same application.

(c) Permission model: Component As ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application 1.

II. Malware characterization:

In this section, we present a systematic characterization of existing Android malware, ranging from their installation, activation, to the carried malicious payloads.

A. Malware Installation

The existing ways Android malware use to install onto user phones are categorized and generalized into three main techniques, i.e., repackaging, update attack, and drive-by download. These techniques are not mutually exclusive as different variants of the same type may use different techniques to entice users for downloading.

1. Repackaging: Repackaging is one of the most common techniques malware authors use to piggyback malicious payloads into popular applications (or simply apps). In essence, malware authors may locate and download popular apps, disassemble them, enclose malicious payloads, and then re-assemble and submit the new apps to official and/or alternative Android Markets. Users could be vulnerable by being enticed to download and install these infected apps.

(a) Repackaged code that will shift the whole collected numbers to "zjphonecall.txt" [8]

2. Update Attack: Instead of enclosing the payload as a whole, it only includes an update component that will fetch or download the malicious payloads at runtime. There are four malware families, i.e., BaseBridge, DroidKungFuUpdate, AnserverBot, and Plankton that adopt this attack. When a BaseBridge-infected app runs, it will check whether an update dialogue needs to be displayed. If yes, by essentially saying that a new version is available, the user will be offered to install the updated version. The new version is actually stored in the host app as a resource or asset file. If the user accepts, an updated version with the malicious payload will then be installed. The DroidKungFuUpdate malware is similar to BaseBridge. But instead of carrying or enclosing the updated version inside the original app, it chooses to remotely download a new version from network. The previous two update attacks require user approval to download and install new versions. The next two malware, i.e., AnserverBot and Plankton, advance the update attack by stealthily upgrading certain components in the host apps not the entire app. As a result, it does not require user approval. In particular, Plankton directly fetches and runs a jar file maintained in a remote server while AnserverBot retrieves a public (encrypted) blog entry, which contains the actual payloads for update.

3. Drive-by Download: The third technique applies the traditional drive-by download attacks to mobile space. Though they are not directly exploiting mobile browser vulnerabilities, they are essentially enticing users to download interesting or feature-rich apps. Four such malware families exist i.e. GGTracker, Jifake, Zitmo and Spitmo. The GGTracker malware starts from its in-app advertisements. In particular, when a user clicks a special advertisement link, it will redirect the user to a malicious website, which claims to be analyzing the battery usage of users phone and will redirect the user to one fake Android Market to download an app claimed to improve battery efficiency. Unfortunately, the downloaded app is not one that focuses on improving the efficiency of battery, but a malware that will subscribe to a premium-rate service without users knowledge. Similarly, the Jifake malware is downloaded when users are redirected to the malicious website. However, it uses malicious QR code [9], which when scanned will redirect the user to another URL containing the Jifake malware. This malware itself is the repackaged mobile ICQ client, which sends several SMS messages to a premium-rate number [10s]. The last two Spitmo and ZitMo are ported versions of nefarious PC malware, i.e., SpyEye and Zeus. They are designed to steal users sensitive banking information. They work in a similar manner: when a user is doing online banking with a comprised PC, the user will be redirected to download a particular smartphone app, which is claimed to better protect online banking activities. However, the downloaded app is actually a malware, which can collect and send mTANs or SMS messages to a remote server. These two malware families rely on the comprised desktop browsers to launch the attack.

B. Activation

In this malware are categorized according to their activation. It uses system-wide Android events. Malware register themselves for such events and after registeration , for notification they depend upon the built-in automated event notification system.

Among all available system events, BOOT_COMPLETED is the most interested one to existing Android malware. This particular event occurs when the system completes its booting process which is a perfect timing for malware to start its background services.there are some 29 malware families listen to this event. For instance, Geinimi (SHA1: 179e1c69ceaf2a98fdca1817a3f3f1fa28236b13) listens to this event to bootstrap the background service com.geinimi.AdService.

Second is SMS_RECEIVED event, there are some 21 malware families according to study which listens to it. This is also reasonable as many malware will be keen in intercepting or responding incoming SMS messages. As an example, zSone listens to this SMS_RECEIVED event and intercepts or removes all SMS message from particular originating numbers such as 10086 and 10010.

There are certain malware registers for a variety of events. For example, AnserverBot registers for callbacks from 10 different events. The registration for more number of events e allows the malware to reliably or quickly launch the carried payloads. In addition, there are some malware samples directly hijack the entry activity of the host apps, which will be triggered when the user clicks the app icon on the home screen or an intent with action ACTION_MAIN is received by the app.

C. Malicious Payload

Malware are characterized according to payload they carry. Such payload functionality are categories as: privilege escalation, remote control, nancial charges, and personal information stealing.

1) Privilege Escalation-

The Android platform is a complicated system that consists of not only the Linux kernel, but also the entire Android framework with more than 90 open-source libraries included, such as WebKit, SQLite, and OpenSSL. The complexity naturally introduces software vulnerabilities that can be potentially exploited for privilege escalation.

Overall, there are a small number of platform-level vulnerabilities that are being actively exploited in the wild. The top three exploits are exploid, RATC (or RageAgainstTheCage),and Zimperlich. According to study there are among 463 of malware samples embed at least one root exploit. These exploits are actually used shows that many earlier malware simply copy exactly same the publicly available root exploits without any modication.They dont even remove the original debug output strings or change the le names of associated root exploits example, DroidDream contains the exploid le name exactly the same as the publicly available one. However, things have been changed recently. There are some malware for example; DroidKungFu does not directly embed these root exploits. Instead it rst encrypts

these root exploits and then stores them as a resource or asset

le. At runtime, it dynamically uncovers these encrypted root exploits and then executes them properly, because of this technique their detection is very challenging.

2) Remote Control -

According to study there are 1,172 samples turning the infected phones into bots for remote control. Specically, there are 1,171 samples that use the HTTP-based web traffic to receive bot commands from their C&C servers. There are some malware families attempt to be stealthy by encrypting the URLs of remote C&C servers as well as their communication with C&C servers.

For example, Pjapps uses its own encoding scheme to encrypt the C&C server addresses.One of its samples (SH1: 663e8eb52c7b4a14e2873b1551748587018661b3) encodes its C&C server mobilemeego91.com into 2maodb3ialke8mdeme3gkos9g1icaofm. DroidKungFu3 employs the standard AES encryption scheme and uses the key to hide its C&C servers. Geinimi similarly applies DES encryption scheme (with the key 0x0102030405060708) to encrypt its communication to the remote C&C server.

Most C&C servers are registered in domains controlled by attackers themselves.

However, study also shows that there are some cases where the C&C servers are hosted in public clouds. For instance, the Plankton spyware dynamically fetches and runs its payload from a server hosted on the Amazon cloud. Most recently, attackers are even turning to public blog servers as their C&C servers. AnserverBot is one example that uses two popular public blog services, i.e., Sina and Baidu, as its C&C servers to retrieve the latest payloads and new C&C URLs .

3) Financial Charge :

In this Premium-rate services will be activated in unauthorized way by sending SMS messages. On Android, there is a permission-guarded function sendTextMessage that allows for sending an SMS message in the background without users awareness. . According to study, there are 55 samples which falling in 7 different families that send SMS messages to the premium-rate numbers hardcoded in the infected apps.

Moreover, there are some malware which do not use hard-code premium-rate numbers. Instead, they have the exible capability of remote control to push down the numbers at runtime. There are 13 such malware families. Apparently, these malware families are more stealthy than earlier ones because the destination number will not be known by simply analyzing the infected apps.

Besides these premium-rate numbers, some malware also leverage the same functionality by sending SMS messages to other phone numbers. Though less serious than previous ones, they still result in certain nancial charges especially when the user does not have an unlimited messaging plan.

For example, DogWars sends SMS messages to all the contacts in the phone without users awareness. Other malware may also make background phone calls. With the same remote control capability, the destination number can be provided from a remote C&C server, as shown in Geinimi.

4) Information Collection:

In addition to the above payloads, malware are actively harvesting various information on the infected phones, including SMS messages, phone numbers as well as user accounts. In particular, there are 13 malware families in our dataset that collect SMS messages, 15 families gather phone numbers, and 3 families obtain and upload the information about user accounts. For example, SndApps collects users email addresses and sends them to a remote server. FakeNetflix gathers users Netix accounts and passwords by providing a fake but seeming identical Netix UI. We consider the collection of users SMS messages is a highly suspicious behavior. The user credential may be included in SMS messages. For example, both Zitmo (the Zeus version on Android) and Spitmo (the SpyEpy version on Android) attempt to intercept SMS verication messages and then upload them to a remote server. If successful, the attacker may use them to generate fraudulent transactions on behalf of infected users.

D. Permission Uses

For Android apps without root exploits, their capabilities are strictly constrained by the permissions users grant to them

Studies show that, INTERNET, READ_PHONE_STATE, ACCESS_NETWORK_STATE, and WRITE_EXTERNAL_STORAGE permissions are widely requested in both malicious and benign apps.

The first two are typically needed to allow for the embedded ad libraries to function properly. But malicious apps clearly tend to request more frequently on the SMS-related permissions, such as READ_SMS, WRITE_SMS, RECEIVE_SMS, and SEND_SMS.

Many of the malicious apps also request the RECEIVE_BOOT_COMPLETED permission. This could be due to the fact that malware is more likely to run background services without users intervention. This permission allows an application to receive action_boot_completed that is broadcast after the system finishes booting.

ALLOW_NETWORK_STATE is needed for accessing Connectivity Manager(mainly for monitoring network connections in general).

INTERNET permission allows applications to open network sockets.

CHANGE_WIFI_STATE is also a commonly asked permission by malicious apps. That is mainly because the Exploid root exploit requires certain hot plug events such as changing the WIFI state, which is related to this permission.

It is also noticed that malicious apps tend to request more permissions than benign ones. The average number of permissions requested by malicious apps is 11 while the average number requested by benign apps is 4. Among the top 20 permissions, 9 of them are requested by malicious apps on average while 3 of them on average are requested by benign apps[1].

III. Malware Detection

The rapid growth and evolution of recent Android malware pose significant challenges for their detection. Researchers from the North Carolina State University have attempted to measure the effectiveness of existing mobile anti-virus software. Four representative mobile anti-virus software were chosen, i.e., AVG Antivirus Free v2.9 (or AVG), Lookout Security & Antivirus v6.9 (or Lookout), Norton Mobile Security Lite v2.5.0.379 (Norton), and TrendMicro Mobile Security Personal Edition v2.0.0.1294 (TrendMicro) downloaded from the official android market. Each of them is installed on a on a separate Nexus One phone running Android version 2.3.7. Before running the security app, they updated it with the latest virus database. In the test, they applied the default setting and enabled the real-time protection. After that, a script is created that iterates each app in the dataset and then installs it on the phone. There is wait period of 30 seconds for the detection result before trying the next app. If detected, these anti-virus software will pop up an alert window, which will be recorded by our script. After the first iteration, there is a second-round scanning of those samples that are not detected in the first round. In the second round, there is a wait period of 60 seconds to make sure that there is enough time for these security software to scan the malware.

From this study it is seen that certain anti virus apps detect only certain families or only some malware of certain families. Thus, results vary and no particular app detects all malware families. Certain malware families are not detected by none of the antivirus apps. This may be because these malware are relatively new. Therefore, existing mobile anti-virus companies may not get a chance to obtain a copy of these samples or extract their signatures. From another perspective, this does imply that they are still taking traditional approaches to have a signature database that represents known malware samples. As a result, if the sample is not available, it is very likely that it will not be detected.

IV. Conclusion

The various methods by which Android apps are infected with malware have been studied in detail. We have seen the ingenious methods using which the infected apps are installed. A large volume of new apps are created on a daily basis. Therefore, a joint effort involving all parties in the ecosystem is needed to spot and discourage malicious apps like creating a centralized market place. The coarse grained Android permission model can possibly be expanded to include additional context information and to better facilitate users to male sound and informed decisions. Unique runtime environment, with limited resources and battery prove to be a hindrance in the deployment of sophisticated detection technique. Rapid development and increased sophistication are posing significant challenges for their detection. Studies show that the best case detection by mobile antivirus is 79.6% and worst case is only 20.2%. Thus, these results call for the need to develop better next generation anti mobile malware solutions.

References

[1] Yajin Zhou, Xuxian Jiang Dissecting Android Malware: Characterization and Evolution in 2012 IEEE Symposium on Security and Privacy.

[2] Amiya K. Maji, Fahad A. Arshad, Saurabh Bagchi An Empirical Study of the Robustness of Inter-component Communication in Android

[3] Ariel Haneyy, Erika Chin, David Wagner, Adrienne Porter Felt, Elizabeth Hay, Serge Egelman Android Permissions: User Attention, Comprehension, and Behavior.

[4] (2011) Smartphone Shipments Tripled Since 08. Dumb Phones Are Flat. http://tech.fortune.cnn.com/2011/11/01/smartphone-shipments-tripled-since-08-dumb-phones-areflat.

[5] (2012) Android beats iOS 5-to-1 in Q3 smartfone market share. http://news.cnet.com/8301-1035_3-57544131-94/android-beats-ios-5-to-1-in-q3-smartphone-market-share.

[6] Malicious Mobile Threats Report 2010/2011. http://www.juniper.net/us/en/company/press-center/press-releases/2011/pr 2011 05 10-09 00.html.

[7] developer.android.com

[8] Repackaged application leaks your smartphone information http://en-erteam.nprotect.com/2011/07/material-repackaged-fastracing-game_8549.html

[9] QR code. http://en.wikipedia.org/wiki/QR code.

[10] Using QR tags to Attack SmartPhones http://kaoticoneutral.blogspot.com/2011/09/using-qr-tags-toattack-smartphones 10.html.

7

S.I.E.S.GST, Dept. of Computer Engineering