GENERATING SUMMERY RISK SCORES FOR MOBILE

APPLICATIONS
project report submitted in partial fulfillment of

the requirements for the award of the degree of

MASTER OF COMPUTER APPLICATIONS

Awarded By
JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY KAKINADA,
KAKINADA.
Submitted by
PERI.ALEKHYA
(16H41F0026)
Under the esteemed guidance of
Mr.SAPPA.SURESH, B.Tech,M.Tech,MISTE,

Assistant Professor ,
Department of MCA.

DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

B.V.C.INSTITUTE OF TECHNOLOGY & SCIENCE
(Approved by A.I.C.T.E, New Delhi , Accredited by NAAC &permanently Affiliated to J.N.T.U K, Kakinada)
AMALAPURAM - 533 201
2019
 DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS
B.V.C.INSTITUTE OF TECHNOLOGY & SCIENCE
(Approved by A.I.C.T.E, New Delhi , Accredited by NAAC &permanently Affiliated to J.N.T.U K, Kakinada)
AMALAPURAM – 533201

CERTIFICATE
This is to certify that the project work on “GENERATING SUMMERY RISK
SCORES FOR MOBILE APPLICATIONS” submitted Ms.PERI.ALEKHYA
(16H41F0026) is examined and adjudged as sufficient as a partial requirement for the
Master of Computer Applications at Jawaharlal Nehru Technological University
Kakinada, Kakinada is a bonafide record of the work done by her under my guidance and
supervision.

Internal Guide Head of The Department

Mr.SAPPA.SURESH,B.Tech.M.Tech,MISTE, Dr. M. PRASAD,M.Tech, MISTE, MCSI, (Ph.D.),

Assistant Professor, Associate Professor& Head,
Department of MCA. Department of MCA.

PROJECT EXTERNAL EXAMINER

 DISSERTATION CERTIFICATE

This is to certify that the entitled dissertation“GENERATING SUMMERY RISK SCORE

FOR MOBILE APPLICATIONS”submittedby Ms. PERI ALEKYA (16H41F0026)
student of Master of Computer Applications of BVC Institute of Technology &
Science, Amalapuram, permanently affiliated to Jawaharlal Nehru Technological
University Kakinada, Kakinada is hereby accepted and approved as a credible work. It
is further certified that this work has not been submitted for similar purpose anywhere
else. Her work has been found satisfactory for the partial fulfillment of the award of the
degree of MCA.

INTERNAL EXAMINER EXTERNAL EXAMINER

Head of the Department

Master of Computer Applications

Bonam Venkata Chalamayya Institute of Technology &Science

Batlapalem,Amalapuram - 533 201

 DECLARATION BY THE CANDIDATE

I, Ms. PREI . ALEKHYA hereby declare that the project work entitled “GENERATING

RISK SCORES FOR MOBILE APPLICATION”is an authenticated work carried out by me at

B.V.C Institute of Technology and Science Amalapuram ,under guidance ofMr Sappa. Suresh
,B.Tech,M.Tech,MISTE,for the partial fulfillment of the award of the degree of Master of
Computer Applications and this work has not been submitted for similar purpose anywhere
else except to BVC Institute of Technology & Science, Amalapuram permanently affiliated to
Jawaharlal Nehru Technological University Kakinada, Kakinada.

(Signature)

Date: Ms. PERI.ALEKHYA

Place: Regd.No: 16H41F0026

 ACKNOWLEDGEMENT

I would like to express my heartiest concern of words to all those people who have
helped me in various ways to complete my project.

I was highly indebted to Mr. SAPPA.SURESH, B.Tech, M.Tech, MISTE), my internal guide.
He has been a constant source of encouragement and has inspired me in completing the project
and helped me at various stages of project work

My sincere thanks to respectable Dr. M.PRASAD, M.Tech, MISTE, MCSI, (Ph.D), Associate Professor
and Head of the Department of Master of Computer Applications, for his timely suggestions and
co-operation for my project completion.

I would like to express my heartfelt gratitude to our Principal, Dr. G.M.V.PRASAD,

M.Tech, Ph.D, FIETE, FIE, MIEEE, MSEMCE, MISTE for forecasting an excellent academic environment
and support.

I would like to extend my sincere thanks to all our department faculty members,
technicians and my family members for their help in completing the project.

Ms. PERI.ALEKHYA
Regd.No:16H41F0026
ABSTRACT
ABSTRACT:

One of Android’s main defense mechanisms against malicious apps is a risk communication

mechanism which, before a user installs an app, warns the user about the permissions the app

requires, trusting that the user will make the right decision. This approach has been shown to be

ineffective as it presents the risk information of each app in a “stand-alone” fashion and in a way

that requires too much technical knowledge and time to distill useful information. We discuss the

desired properties of risk signals and relative risk scores for Android apps in order to generate

another metric that users can utilize when choosing apps. We present a technique to generate

both risk signals and risk scores that are based on heuristics. Experimental results conducted

using real-world data sets show that these methods can effectively identify malware as very

risky, are simple to understand, and easy to use.

 LIST OF FIGURES

FIGURE No. NAME OF THE FIGURE PAGE No.

Fig 2.1. Android Manifest.xml 5

Fig 2.2. Most Frequently Used Permissions 7

Fig 4.1. DFD Symbols 14

Fig 4.2. Level 0 DFD diagram 14

Fig 4.3. Level 1 DFD diagram 16

Fig 4.4. Use Case Diagram symbols 17

Fig 4.5. Use Case Diagram 18

Fig 4.6. Class Diagram 19

Fig 4.7. Sequence Diagram 20

Fig 4.8. Activity Diagram 22

Fig 4.9. Collaboration Diagram 23

Fig 5.1. Skeleton of Android 28

Fig 7.1 Splash Screen 43

Fig 7.2 Main Page 43

Fig 7.3 Help Page 44

Fig 7.4 Internet not connected 44

Fig 7.5 Opens Play Store 45

Fig 7.6 Installing app from Play Store 45

Fig 7.7 Accepting the permissions while installing 46

Fig 7.8 Blocking the app 46

Fig 7.9 Installed App Names 47

Fig 7.10 Risk Score of an App 47

Fig 7.11 Information about the permission 48

Fig 7.12 Unblock an App 48

 LIST OF TABLES

TABLE No. NAME OF THE TABLE PAGE No.

Tab 2.1. List of Critical Permissions 8

Tab 4.1. Table for Storing the App names 24
Tab 4.2. Table when we unblock the application 25
Tab 6.1. Table Information about Positive test cases 41
Tab 6.2. Table Information about Negative test cases 42
 LIST OF ABBREVIATIONS

DFD -- Dataflow Diagrams

UML -- Unified Modeling Language

XML -- Extensible Mark-up Language

OS -- Operating System

UI -- User Interface

IDE -- Integrated Development Environment

SDK -- Software Development Kit

ADT -- Android Development Tools

 TABLE OF CONTENTS

Contents Page No.

CERTIFICATE

ACKNOWLEDGEMENT

ABSTRACT

LIST OF FIGURES

LIST OF TABLES

LIST OF ABBREVIATIONS

Chapter 1 : INTRODUCTION
1.1 Introduction 1
1.2 Motivation 2
1.3 Objective of the Thesis 2
1.4. Organization of Thesis 3

Chapter 2: LITERATURE SURVEY 4

2.1 Basic concepts

2.1.1Activity 4
2.1.2 Broadcast Receiver 4
2.1.3 Service 4
2.1.4 Content Provider 5
2.1.5 Intents 5
2.1.6.AndroidManifest.xml 5
2.1.7 Views 6
2.1.8 Notification 6
2.2 Related work 6
2.2.1 Permissions and Usefulness 6
2.2.2 Risk Score Generation 7

Chapter 3: PROPOSED WORK & ANALYSIS 10

3.1 Proposed Work & Analysis 10
 3.2 Feasibility Study 10
3.2.1 Economy Feasibility 10
3.2.2 Technical Feasibility 10
3.2.3 Operational Feasibility 11

Chapter 4: DESIGN 12
4.1 System Design 12
4.2 Data Flow Diagrams 13
4.2.1 DFD Symbols 13
4.2.2 Context Level Diagrams 14
4.2.3 Detailed Level Diagram 15
4.3 UML Diagrams 17
4.3.1. Use Case Diagram 17
4.3.2. Class Diagram 19
4.3.3. Sequence Diagram 19
4.3.4. Activity Diagram 21
4.3.5. Collaboration Diagram 23
4.4 Database Design 24

4.4.1 what is SQLite 24

Chapter 5: IMPLEMENTATION 27

5.1 Software Requirements 27

5.2 Hardware Requirements 28

5.3 Technologies used 28

5.3.1 What is android ? 28

 5.3.2 Framework of Android 29

5.3.2.1 Skeleton of Android 29

5.3.3 About Android Framework 29

5.4 Coding 31

Chapter 6: TESTING 38

6.1 Testing Objectives 38

6.1.1 White-box and black-box testing 38

6.2 Test Cases 40

6.2.1 positive Test Cases 40

6.2.2 Negative Test Cases 42

Chapter 7: RESULTS 43

Chapter 8: CONCLUSIONS 49

Chapter 9: FUTURE SCOPE 50

Chapter 10: BIBILIOGRAPHY 51

 CHAPTER 1

INTRODUCTION

1.1 Introduction:

Android platformhasemergedasoneof the fastest growing operating systems.Everyday more than

1 billion new android devices are activated worldwide From Google play 1.5 billion downloads a

month.Such a wide user base,coupled with easy of developing and distributing

applications,makes Android an attractive target for malicious developers that seek personal gain

while costing user’s money and invading user’s privacy.

As mobile devices are becoming ubiquitous,and they provide access to personal and

sensitive information such as phone numbers,contact lists,geolocationand SMS messages,making

their security an especially important challenge.Compared to desktop and laptop

computers,mobile devices have a different paradigm for installing new applications.For

traditional personal computers, a typical user installs relatively few applications,most of which

are from reputable vendors,with niche applicationsincreasinglybeing replaced by web-based or

cloud services.For mobile devices,one often downloads and uses many applications(or apps)

with limited functionality from multiple unknown vendors.Therefore,the defense against

malicious applications must depend to a large degree on decisions made by users.An important

part of malware defense on mobile devices is to communicate the risk of installing an app to

users,and enable the user to make informed decisions about whether to choose and install

specific apps.

So, the concept of risk scoring functions was proposed. Such a function assigns to each app

a numerical score,which indicates how risky the app is.This approach presents “comparative”
risk information,i.e. each app’s riskis presented in a way so that it can be easily compared to

other apps.

1.2 Motivation:

Oneof Android’s main defense mechanisms against malicious apps is a risk communication

mechanism which, before auser installs an app, warns the user about the permissions the app

requires, trusting that the user will make the right decision. Thisapproach has been shown to be

ineffective as it presents the risk information of each app in a “stand-alone” fashion and in a way

thatrequires too much technical knowledge and time to distill useful information.The desired

properties of risk signals andrelative risk scores for Android apps are discussed in order to

generate another metric that users can utilize when choosing apps.

Objective of Thesis:

The main purposeof this application is to evaluate the risk of mobile applications.Forthis, the

Risk Score is generated for every application, based on the permissions requested by the app and

also provide description forevery permission, the app request.

When user installing any application from Google Play website orother third party

websites exist,e.g., Amazon Appstore,Getjar,SlideMe Market, etc. a message will be displayed

with “package name of the installing application and verify it from Risk app”.

We are implementing this application as android application as it will be very helpful when a

person choosing an application to install.

The Risk Score function is used to compare several different applications and understand a

relative risk of installing one application versus another.Andalso to improve risk communication

for android apps.

1.4 Organization of Thesis:

The rest of the thesis is organized in the following manner:

Chapter 2-Deals with Literature Survey .Here some basic concepts of ANDROID are described.

Chapter 3-Contains the proposed work and analysis.

Chapter 4-Gives the detailed description of Modules using UML Diagrams.

Chapter5-Gives the Implementation details,which the hardwareand software requirements,

description of the Technologies used.

Chapter 6-Deals with the Debugging process of the proposed system.

Chapter 7-The results of the implemented modules along with the respective

screen shots are provided.

Chapter 8-The Conclusions of the current application is provided.

Chapter 9-The enhancement work for the future research is given.

Chapter 10- The References, Text Books, Web Sites for this work are given.
 CHAPTER 2

LITERATURE SERVEY

2.1 Basic Concepts:

The basic components of an Android application include Activity, Broadcast Receiver,

Service, andContent Provider. Each of these which when used for any application has to be

declared in theAndroidManifest.xml. The user interface of the component is determined by the

Views. For theCommunication among these basic components we use Intents and Intent filters

which play crucial role during app development.

2.1.1Activity:

An Activity is fundamentally an object that has a lifecycle. An Activity is a chunk of code

that does some work; if necessary, that work can include displaying a UI to the user. It doesn't

have to, though -some Activities never display UIs. Such as dial the phone, take a photo, send an

email, or view a map.

2.1.2 Broadcast Receiver:

Broadcast Receiver is yet another type of component that can receive and respond to any

broadcastannouncements.

2.1.3Service:

A Service is a body of code that runs in the background. It can run in its own process, or in

thecontext of another application's process, depending on its needs. Other components "bind" to

aService and invoke methods on it via remote procedure calls. An example of a Service is a

mediaplayer; even when the user quits the media-selection UI, she probably still intends for her

music tokeep playing. A Service keeps the music going even when the UI has completed.
2.1.4Content Provider:

Content Provider is a data storehouse that provides access to data on the device; the

classic example is the Content Provider that's used to access the user's list of contacts. Our

application can access data that other applications have exposed via a Content Provider.

2.1.5Intents:

Intent is a simple message object that represents an "intention" to do something. For

example, if ourapplication wants to display a web page, it expresses its "Intent" to view the URI

by creating an Intentinstance and handing it off to the system. The system locates some other

piece of code (in this case,the Browser) that knows how to handle that Intent, and runs it. Intents

can also be used to broadcastinteresting events (such as a notification) system-wide. There are

two types of intents namelyimplicit and explicit intents. Implicit intents have no specified

component where as Explicit intents do specify the component.

2.1.6AndroidManifest.xml:

AndroidManifest.xml file is the control file that tells the system what to do with all the

top-levelcomponents (specifically activities, services, intent receivers, and content providers

described the below) we have created. For instance, this is the "glue" that actually specifies which

Intents our Activitiesreceive.

 Fig 2.1: AndroidManifest.xml

2.1.7Views:

A View is an object that knows how to draw itself to the screen. Android user interfaces

arecomprised of trees of Views. If we want to perform some custom graphical technique (as we

might ifwe're writing a game, or building some unusual new user interface widget) then we would

create aView.

2.1.8 Notification:

A Notification is a small icon that appears in the status bar. Users can interact with this

icon to receiveinformation. The most well-known notifications are SMS messages, call history,

and voicemail, butapplications can create their own. Notifications are the strongly-preferred

mechanism for alerting the user of something that needs their attention.

2.2 Related Work:

2.2.1 Permissions and Usefulness:

When users are installing any android applications from PlayStore or from other third party

vendors the apprequest the permissions e.g.,READ_CONTACTS,SEND_SMS,

FINE_LOCATION etc. to accept.Acceptingthe permissions without having any knowledge

sometimes takes our personal information from our mobile and send to others.For this we are

providing the information about the permissions an app requests i.e.what it does if we accept the

permission.This permission information is gathered from the android forums.The information

says what type of apps request this permission and also numerical risk(Malware)if we accept the

permission.The user can understand the permissions and can take the right decision.

2.2.2 Risk Score Generation

We have collected two data sets from Google Play spaced one year apart. The data sets were

collected by crawling the Google Play app store, starting with the topapps in each category and

then following all the links to other apps on each page. Market2011, the first data set, consists of

157,856 apps available on Google Play in February 2011. Market2012, the second data set,

consists of 324,658 apps, and has been collected in February 2012. For each app, we have the

application meta-information consisting of the developer name, its category and the set of

permissions

that the app requests. We assume that apps in these two data sets are mostly benign.

We leverage the Market2011 data set for our model generation and testing, and use Market2012

data set for validation and market evolution analysis.

Malware data set. Our malware data set consists of 808 unique .apk files that are known

to be malicious. We obtained this data set from the authors Y.Zhou and X.jiang. For each

malware sample, we extract the permissions requested using the AndroidManifest.xml file

present inside the package file. For these malicious apps we do not have their category

information.
 The frequencies of the most frequently requested permissions in the three data sets are

presented in Fig.2.1. There are 26 permissions in this figure, which include the top 20 for all

three data sets. Clearly, for every permission, the percentage of malware apps is significantly

higher than those in the two market data sets. For some permission, the difference is quite

striking. This shows a trend that proportionally more applications are requesting sensitive

permissions.

The below graph is used to understand the approximate Malware available in an

permission by examining previous apps that has already used this permission and understanding

that if an app contains some risk,how much percentile of malware it contains.

The top 20 most used permissions in all three data sets as a percent
of apps that request those permissions.Due to overlap,we must
 show 26 permissions to cover the 20 most used in all data sets

Fig:2.2 Most Frequently Used Permissions

From Android’s list of permissions, we choose 26 permissions that we call critical

permissions. They are listed in Table 1. These 26 permissions were chosen because we believe

they are critical for the security and privacy of end users. These permissions allow an app to

either infringe upon privacy, or cause monetary loss or other kinds of damage.
 Table 2.1 List of critical permissions

The Risk Score of an app is generated based on the critical permissions requested by the

app.we get the risk(Malware)of the critical permissions from Table 2.1 and display the average

of all critical permissions requested by the app as Risk Score.

CHAPTER 3

PROPOSED WORK & ANALYSIS

3.1 Proposed work & Analysis:

This concept consists of the advanced feature to the existing system, like “Generating the Risk

Score for every installing application”.The semantic meaning is very simple and easy to

understand.

3.2 Feasibility Study:

In the existing systemAndroid’s main defense mechanisms against malicious apps is a risk

communication mechanism which warns the user about the permissions an app requires before

the app is installed by the user, trusting that the user will make the right decision. The specific

approach used in Android has been shown to be ineffective at informing users about potential

risks.

3.2.1 Economic Feasibility

A system can be developed technically and that will be used if installed must still be a

good investment for the organization. In the economic feasibility, the development cost in

creating the system is evaluated against the ultimate benefit derived from the new systems.

Financial benefits must equal or exceed the costs.

The system is economically feasible. It does not require any addition hardware or software. There

is nominal expenditure and economic feasibility for certain.

3.2.2Technical Feasibility:

There are number of technical issues which are generally raised during the feasibility stage of the

investigation. They are as follows:

 Does the necessary technology exist to do what is suggested?

 Can the system be upgraded if developed?

  Are there technical guarantees of accuracy, reliability, and ease of access?

The system is developed in Eclipse IDE which is an effective platform to develop a software

project especially when it is required a User Friendly system.So we can say the system is

technically feasible.

3.2.3 Operational Feasibility:

Proposed projects are beneficial only if they can be turned out into information system.

That will meet the organization’s operating requirements. Operational feasibility aspects of the

project are to be taken as an important part of the project implementation. Some of the important

issues raised are to test the operational feasibility of a project includes the following: -

 Is there sufficient support for the management from the users?

 Will the system be used and work properly if it is being developed and implemented?

 Will there be any resistance from the user that will undermine the possible application

benefits?

This system is targeted to be in accordance with the above-mentioned issues. Beforehand,

the management issues and user requirements have been taken into consideration. So there is

no question of resistance from the users that can undermine the possible application benefits.

The well-planned design would ensure the optimal utilization of the computer resources and

would help in the improvement of performance status.

CHAPTER 4

DESIGN

4.1 System Design:

The most creative and challenging phase of the life cycle is system design. The term

designdescribes a final system and the process by which it is developed. It refers to the technical

specifications that will be applied in implementations. The design may be defined as “the process

of applying various techniques and principles for the purposeof defining a device, a process or a

system with sufficient details to permit its physical realization”.

The project contains the following main modules:

Generating parental control:

This module is for accessing the system facilities.

Application blocking:

The application blocking module is for blocking the installed application and verifies it from our

risk scoreapplication.

Permission generating:

This module isfor generating the information about the permissions and getting list of

permissions which the installed app requests.

Risk calculation:

This moduleis for calculating the risk score of the application based on the permissions requested

by the app.

4.2 Data Flow Diagrams:

A data flow diagram is graphical tool used to describe and analyze movement of data

through a system. These are the central tool and the basis from which the other components are
developed. The transformation of data from input to output, through processed, may be described

logically and independently of physical components associated with the system. These are

known as the logical data flow diagrams. The physical data flow diagrams show the actual

implements and movement of data between people, departments and workstations.

4.2.1 DFD SYMBOLS:

In the DFD, there are four symbols

1. A square defines a source (originator) or destination of system data.

2. An arrow identifies data flow. It is the pipeline through which the information flows

3. A circle or a bubble represents a process that transforms incoming data flow into outgoing

data flows.

4. An open rectangle is a data store, data at rest or a temporary repository of data.

Process that transforms data flow

Process that transforms data flow

Data flow

Data Store
Fig 4.1: DFD symbols

The development of DFD’S is done in several levels. Each process in lower level

diagrams can be broken down into a more detailed DFD in the next level.

4.2.2Context Level Diagram:

The top-level diagram is often called context diagram(also known as Level-0).

It consists of a single process node, which plays vital role in studying the current

system.

Level 0:

User Connect User

Connect

Play Store

Fig:4.2 Level 0 DFD diagram

4.2.3 Detailed Level Diagram:

 This level explains each process of the system in a detailed manner. In first detailed level

DFD (Generation of individual fields): how data flows through individual process/fields in it are

shown.

In second detailed level DFD (generation of detailed process of the individual fields): how

data flows through the system to form a detailed description of the individual processes.

Level 1:
 User Open Play Store

Install
App
User

Get
Install App installation Application
Notification

Store
Unblock Block
InstalledApp

Application Verify Install App Database

itself

Generate Verified &

Accepted

Risks Permission
Score Information

Fig 4.3: Level 1 DFD Diagram

4.3 Unified Modeling Language Diagrams:

Diagram is the graphical presentation of a set of elements, most often rendered as a

connected graph of vertices (things) and arcs (relationships).

In theory, a diagram may contain any combination of things and relationships.

4.3.1 Use case Diagram:

Use case diagrams model the functionality of system using actors and use cases. It displays the

relationship among actors and use cases. A use case is a set of scenarios that describing an

interaction between a user and a system. The two main components of a use case diagram are use

cases and actors.

Figure 4.4: UseCase diagram symbols

 A use case diagram shows a set of use cases and actors and their relationships. Usecase

diagrams address the static use case view of a system. These diagrams are especially
 important in organizing and modeling the behaviors

Open App

Click PlayStore Button

Internet Availability

Valid

Open PlayStore

download process

Store into database

User Device
Block the App

Click Package names

apps display

permissions display

permission information

Generate Risk

Unblock App

Exit
 Figure 4.5: Usecase diagram

4.3.2 Class Diagram:

In software engineering a class diagram in the Unified Modeling Language (UML) is a

type of static structure diagram that describes the structure of a system by showing the system's

classes, their attributes, operations (or) methods and the relationships between the classes.

The class diagram is the main building block in object oriented modeling. It is used both

for general conceptual modeling of the systematic of the application, and for detailed modeling

translating the models into programming code.

Figure 4.6: Class diagram

4.3.3 Sequence Diagrams:

A sequence diagram is an interaction diagram that emphasizes the time-ordering of

messages. A sequence diagram shows interaction among objects as a two dimensional chart. The

objects participating in the interaction are shown at the top of the chart as boxes attached to a

vertical dashed line. A sequence diagram shows only the behavioral aspects.
User Device

1.Open application

2.Click PlayStore button

3.Validate SdCard

4.Validate Internet

5.Validate PlayStore

6.Open PlayStore

7.Download App

8.Store into Database

9.Block Application

10.Click application button

11.Display list of Application

12.Click the Application

13.Display Permissions

14.Click the Permissions

15.Information about Permission

16.Generate Risk

17.User want to continue

18.Unblock App

19.Exit

Figure 4.7: Sequence diagram

4.3.4 Activity Diagram:

Activity diagram is another important diagram in UML to describe dynamic aspects of

system.

Activity diagram is basically a flow chart to represent the flow from one activity to

another activity. The activity can be described as an operation of the system.

The process flows in the system are captured in the activity diagram similar to a state diagram

an activity diagram also consists of activities, action, transitions

 Initial and final states and guard conditions

 Processes involving different use case are show in work flows.

 Open the App

Click the
Button

is sdcard,
internet
availability

yes
Open
PlayStore

Download&store the
App in Database

Block the App

Click Package
Names no

Display list of
apps

Click on any
app

Display
permission

Information about
permission

Risk
Generation

Unblock App

Exit

Fig 4.8:Activity diagram

4.3.5 Collaboration Diagram:

UML Collaboration diagrams (intension diagrams) illustrate the relationship and

interaction between software objects. They require use cases, system operation contracts, and

domain model to already exist. The collaboration diagram illustrates messages being sent

between classes and objects (instances). A diagram is created for each system operation that

relates to the current development cycle (iteration).

When creating collaboration diagrams,patterns are used to justify relationships.Patterns

are best principles for assigning responsibilities to objects.There are two main types of patterns

used for assigning responsibilities which are evaluative patterns and driving patterns.

3: Validate SdCard
4: Validate Internet
5: Validate PlayStore
1: Open application 8: Store into Database
2: Click PlayStore button 9: Block Application
7: Download App 18: Unblock App
10: Click application button
12: Click the Application
14: Click the Permissions
17: User want to continue
19: Exit
User Device

6: Open PlayStore
11: Display list of Application
13: Display Permissions
15: Information about Permission
16: Generate Risk

Figure4.9: Collaboration diagram

4.4 DATABASE DESIGN

1.1.1 4.4.1 What is SQLite?

SQLite is an Open Source database. SQLite supports standard relational database features like

SQL syntax, transactions and prepared statements. The database requires limited memory at

runtime (approx. 250 KByte) which makes it a good candidate from being embedded into

other runtimes.

SQLite supports the data types TEXT (similar to String in java), INTEGER (similar to

long in Java) and REAL (similar to double in Java). All other types must be converted into

one of these fields before getting saved in the database. SQLite itself does not validate if the

types written to the columns are actually of the defined type, e.g. you can write an integer into

a string column and vice versa.

The data base is created with two columns i.e. row id, p_name. The installing

application package name is stored in the database.The stored data is used for blocking the

installing application.When user press the Unblock button in the application the stored

package name in the database will be deleted.

Table to store the installing app names:

Table 4.1 Table for storing the app names

Table when userunblock the application:

Table 4.2 Table when user unblock the application

 CHAPTER 5

IMPLEMENTATION

Introduction:

Implementation is the stage of the project when the theoretical design is turned out into a

working system. Thus it can be considered to be the most critical stage in achieving a successful

new system and in giving the user, confidence that the new system will work and be effective.

The implementation stage involves careful planning, investigation of the existing system

and it’s constraints on implementation, designing of methods to achieve changeover and

evaluation of changeover methods.

The project is implemented by accessing simultaneously from more than one system and more

than one window in one system. The application is implemented in the Internet Information

Services 5.0 web server under the Windows XP and accessed from various clients.

5.1. Software Requirements:

The software used for the development of the project is:

OPERATING SYSTEM : Windows XP

ENVIRONMENT : Eclipse

LANGUAGE : Java,Xml

DATABASE : SQLite

5.2Minimal Hardware Requirements:

The hardware used for the development of the project is:

PROCESSOR : PENTIUM IV

RAM : 512MB RAM

HARD DISK : 2 GB

5.3 Technologies Used:

5.3.1: what is android?

The first truly opened comprehensive platform for mobile devices, all of the software to run a

mobile phone but without the proprietary obstacles that have hindered mobile innovation.

 Linux OS kernel

 Java programming

 Open source libraries: MySQL, Web Kit, OpenGL

WHYANDROID:

 A simple and powerful SDK

 No licensing, distribution, or development fees

 Development over many platforms

 Linux, Mac OS, windows

 Excellent documentation

 Thriving developer community

 For us Job opportunity

5.3.2 Framework of Android:

5.3.2.1SKELETON OF ANDROID:

The skeleton of Android framework and its constituents are shown in the following
 Figure5.1: Skeleton of Android

5.3.3About Android Framework:

Applications Layer:

The next layer is the application framework. This includes the programs that manage the

phone's basicfunctions like resource allocation, telephone applications, switching between

processes or programsand keeping track of the phone's physical location. Application developers

have full access toAndroid's application framework. This allows them to take advantage of

Android's processing Capabilities and support features when building an Android application. We

can think of theapplication framework as a set of basic tools with which a developer can build

much more complex tools.

Libraries Layer:

The next layer contains the native libraries of Android. These shared libraries are all

written in C or C++, compiled for the particular hardware architecture used by the phone and

preinstalled by the Phone vendor.

Android Runtime Layer:

Android Runtime layer includes DalvikVirtual Machine (DVM) and a set of core java

libraries.

Every Android app gets its own instance of DVM. Dalvik has been written so that a

device can runmultiple virtual machines efficiently and it executes files with .dex (dalvik

executable format) extension optimized for minimum memory.

Applications frame work Layer:

Android ships with a set of core applications including an email client, SMS

program,calendar, maps, Browser, contacts, and others. All applications are built using the Java.

Each of the application aim Set performing a specific task that it is actually intended to do.

5.4 Coding:

MainActivity:

packagecom.example.project;

importjava.util.ArrayList;

importandroid.app.Activity;

public class MainActivity extends Activity {

database dbase;

Cursor c;

final Context ctx = this;

protected String path;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

Button store = (Button) findViewById(R.id.playstore);

Button apppack = (Button) findViewById(R.id.Pname);

finalListView lv=(ListView)findViewById(R.id.list1);

Button btnfrhelp=(Button)findViewById(R.id.butnforhelp);

startService(new Intent(MainActivity.this,BlockingService.class));

store.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View arg0) {

// TODO Auto-generated method stub

ConnectivityManager connectivity = (ConnectivityManager) ctx

.getSystemService(Context.CONNECTIVITY_SERVICE);

if (connectivity != null) {

NetworkInfo[] info = connectivity.getAllNetworkInfo();

if (info != null)

for (int i = 0; i <info.length; i++)

if (info[i].getState() == NetworkInfo.State.CONNECTED) {

Uri uri = Uri.parse("https://play.google.com/store/apps/details?id=my packagename");

Intent myAppLinkToMarket = new Intent(Intent.ACTION_VIEW, uri);

startActivity(myAppLinkToMarket); return;

Toast.makeText(MainActivity.this, "Internet not connected",1111).show();

return;

}
});

apppack.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View arg0) {

// TODO Auto-generated method stub

startActivity(new Intent(MainActivity.this,NamesActivity.class));

});

btnfrhelp.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View arg0) {

// TODO Auto-generated method stub

startActivity(new Intent(MainActivity.this,HelpActivity.class));

});

@Override

protected void onDestroy() {

// TODO Auto-generated method stub

super.onDestroy();

stopService(new Intent(MainActivity.this,BlockingService.class));

}
VerificationActivity

packagecom.example.project;

importjava.util.ArrayList;

importandroid.R.string;

importandroid.widget.AdapterView.OnItemClickListener;

importandroid.widget.ArrayAdapter;

importandroid.widget.ListView;

importandroid.widget.TextView;

importandroid.widget.Toast;

public class VerificationActivity extends Activity implements OnItemClickListener {

ListView lv;

ArrayList<String>pNames;

permissioninfoperInfo;

TextViewtv,tvs;

String pack;

TextViewtvRiskAvg;

int positions;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_verification);

tvRiskAvg= (TextView)findViewById(R.id.txtveri_avgrisk);

perInfo= new permissioninfo();

perInfo.setData();

perInfo.setPos();

perInfo.setRiskpermissiondata();

perInfo.setCriticalpermissionData();

perInfo.setRiskpermissionPos();

lv= (ListView)findViewById(R.id.lvp);

tv= (TextView)findViewById(R.id.tvp);

tvs= (TextView)findViewById(R.id.tvs);

Intent in= getIntent();

pNames= in.getStringArrayListExtra("p");

pack= in.getExtras().getString("n");

positions= in.getExtras().getInt("pos");

if(pNames.size()==0){

tvs.setText("No Permission !");

else{

double r=0.0;

int count= 0;

for(int i=0;i<pNames.size();i++){

int pos1= perInfo.riskpermissionListPos.indexOf(pNames.get(i));

if(pos1==-1){

else{
count++;

r=r+perInfo.criticalRisKper.get(pos1);

if(count==0){

tvRiskAvg.setText("NO RISK IN THIS APP");

else{

doubleavgRisk= r/count;

tvRiskAvg.setText(""+avgRisk);

//Toast.makeText(VerificationActivity.this, ""+avgRisk, Toast.LENGTH_LONG).show();

ArrayAdapter<String>adptr= new ArrayAdapter<String>(VerificationActivity.this,

android.R.layout.simple_list_item_1, pNames);

lv.setAdapter(adptr);

lv.setOnItemClickListener(this);

@Override

public void onItemClick(AdapterView<?> parent, View view, int position,

long id) {

// TODO Auto-generated method stub

String n= pNames.get(position);

Log.d("sizes", perInfo.getPos());

intpos= perInfo.riskpermissionListPos.indexOf(n);

intposn= perInfo.permissionListPos.indexOf(n);

//Toast.makeText(VerificationActivity.this, "simple"+pos, Toast.LENGTH_LONG).show();

String pinfo;

double d;

if (posn==-1) {

tv.setText("This permission is asked by the apps like this one.For more information about the

permission you can check in android forum");

tvs.setText("No Risk Found");

else if(pos==-1){

pos= perInfo.permissionListPos.indexOf(n);

pinfo= perInfo.permissionList.get(pos);

tv.setText(pinfo);

tvs.setText("No Risk Found");

else{

pinfo= perInfo.riskpermissionList.get(pos);

d= perInfo.criticalRisKper.get(pos);

tv.setText(pinfo);

tvs.setText(""+d+"% risk");
}

public void onDisable(View v){

databasedb= new database(VerificationActivity.this);

db.init();

Cursor c= db.getValue();

c.moveToPosition(positions);

String id= c.getString(0);

db.deleteOne(id);

Toast.makeText(VerificationActivity.this, "Successfully Unblocked",

Toast.LENGTH_LONG).show();

finish();

CHAPTER 6

TESTING

6.1 Testing Objectives

 To make sure whether system meets user requirements or not.

 To make sure that during the operation, incorrect input, processing and output will

be detected.
  To see that when correct inputs are fed to the system the outputs are correct.

 To verify that the controls incorporated in the same system as intended.

6.1.1 White-box and black-box testing

White box and black box testing are terms used to describe the point of view a test engineer

takes when designing test cases. Black box ,being an external view of the test object and white

box being an internal view. Software testing is partly intuitive, but largely systematic. Good

testing involves much more than just running the program a few times to see whether it works.

Thorough analysis of the program under test, backed by a broad knowledge of testing techniques

and tools are prerequisites to systematic testing. Software Testing is the process of executing

software in a controlled manner; in order to answer the question “Does this software behave as

specified?” Software testing is used in association with Verification and Validation. Verification

is the checking of or testing of items, including software, for conformance and consistency with

an associated specification. Software testing is just one kind of verification, which also uses

techniques as reviews, inspections, walk-through. Validation is the process of checking what has

been specified is what the user actually wanted.

 Validation: Are we doing the right job?

 Verification: Are we doing the job right?

In order to achieve consistency in the Testing style, it is imperative to have and follow a set of

testing principles. This enhances the efficiency of testing within SQA team members and thus

contributes to increased productivity. The purpose of this document is to provide overview of the

testing, plus the techniques.

At SDEI, 3 levels of software testing is done at various SDLC phases

 Unit Testing: in which each unit (basic component) of the software is tested to verify that

the detailed design for the unit has been correctly implemented

 Integration testing: in which progressively larger groups of tested software components

corresponding to elements of the architectural design are integrated and tested until the

software works as a whole.

 System testing: in which the software is integrated to the overall product and tested to

show that all requirements are met

A further level of testing is also done, in accordance with requirements:

 Acceptance testing: upon which the acceptance of the complete software is based. The

clients often do this.

 Regression testing: is used to refer the repetition of the earlier successful tests to ensure

that changes made in the software have not introduced new bugs/side effects.

6.2Test Cases:

 To make sure whether system meets user requirements or not.

 To make sure that during the operation, incorrect input, processing and output will be

detected.

 To see that when correct inputs are fed to the system the outputs are correct.

 To verify that the controls incorporated in the same system as intended.

6.2.1Positive Test Cases:

  Positive testing determines the application works as expected. If an error is

encountered during positive testing, the test fails.

 The positive flow of the functionality must be considered

 Correctly opening the Googleplaystore.

 Must have the positive perception to verify whether the requirements are justified.

Examples of positive test cases:

T.C.No Description Expected value Actual value Result

Open the Opens

Go to the main page. Pass
1 Application main page

2 Click on Help button Opens Help

Pass
Go to Help page page

3 Opens Google
Click on Google play
Pass
Play store
To go to Google Go to Google playstore

playstore

After installation Toast Toast message

Choosing any app Pass
4 message must display displayed
 The installed app doesn't Installed App is
Blocking the app Pass
5 open not opening

The installed app Package name

Click on Package
package name must of installed app Pass
6
Names in Risk app
display. displayed

The permissions List of

Select the Package requested by the app permissions Pass

7
must display displayed

Risk &
The Risk &Information
Select the permission
8
of permission will Pass
permission information
display
displayed

The installed app must Installed app

Click on Unblock pass
9 open opened

Table 6.1:Table information about Positive test cases

6.2.2 Negative Test Cases:

 Negative testing ensures the application can gracefully handle invalid input or

unexpected user behavior.

 For example, if a user tries to open Google playstore when internet is not connected.

“Internet is not connected” message will display.

  The purpose of negative testing is to detect such situations and prevent applications from

crashing.

 Also, negative testing helps you improve the quality of your application and find its weak
points.

Example for Negative Test cases:

T.C.No Description Expected value Actual value Result

Internet not
Google Play must not Internet
connected
1 Internet not connected open and Toast message not
message
must display connected
displayed

Table 6.2:Table information about Negative test cases

CHAPTER 7

RESULTS
 Figure 7.1: Splash Screen

Figure 7.2: Main Page

 Figure 7.3: Help Page

7.4 Internet not connected

Figure 7.5:Opens PlayStore
 Figure 7.6:Installing app from Play Store

Figure 7.7: Accepting the permissions while installing

 Figure 7.8: Blocking the app

Figure 7.9: Installed AppNames

Figure 7.10:Risk Score of an App

7.11 Information about the permission

 Figure 7.12: Unblock an app

CHAPTER 8

CONCLUSION

The “Generating Summary Risk Scores for Mobile Applications”will effectively communicate

the risk of an application to users,and propose a method to rate the risk.This method is tested on

large real-world data sets showed this method can effectively identify malware as very risky.

The application is very useful to the user while choosing an app to install.By seeing the risk in

one app he can choose another similar app containing less risk than previous one.
 CHAPTER 9

FUTURE SCOPE

A risk score for Android applications based on the permissions they request is

generated.While the focus of this work is on the permissions,the idea of generating a risk score

can be extended to account for other features such as source code,developer information,user

reviews,privacy policies and various other attributes related to app.

CHAPTER 10

BIBILIOGRAPHY

REFERENCES

Books Referred:

 E. Chin, A.P. Felt, V. Sekar, and D. Wagner, “Measuring UserConfidence in Smartphone

Security and Privacy,” Proc. Eighth

 Symp. Usable Privacy and Security, (SOUPS ’12), article 1, 2012.Jerome (J. F.) DiMarzio,

Android - A Programmer’s guide, Tata McGraw-Hill Education.

 Y. Zhou and X. Jiang, “Dissecting Android Malware: Characterization and volution,”

Proc. 33rd IEEE Symp. Security and Privacy,May 2012.

 Mark L.Murphy,Thebusycoder's guide to Android development, CommonsWare.

 Reto Meier, Professional Android 2 Application Development.

Websites Referred:

 www.google.com

 Stackoverflow.com
 [Online] chengalva.com

 [Online] developers.android.com

 tamilcube.com

 Android Forums