Malware Detection in Android App Using Static and Dynamic Analysis
Malware Detection in Android App Using Static and Dynamic Analysis
A PROJECT REPORT ON
Prof.N.V. Kapade
CERTIFICATE
is a bonafide work carried out by Students under the supervision of Prof. N. V. Kapade
and it is submitted towards the partial fulfillment of the requirement of Bachelor of En-
gineering (Computer Engineering).
Is successfully completed by
at
iii
Abstract
Smartphones and mobile tablets are fast becoming necessary in daily life. Android
has been the most popular mobile operating system since 2012. However, due to the
open nature of Android, immeasurable malwares are hidden in a large number of kindly
apps in Android markets that dangerously pressure Android security. Deep learning is a
new area of machine learning research that has gained increasing detect in artificial in-
telligence. In this study, we propose to connect the features from the static analysis with
features from dynamic analysis of Android apps and differentiate malware using deep
learning techniques. We execute an Online deep-learning-based Android malware detec-
tion engine (DroidDetector) that can automatically identify whether an app is a malware
or not. With thousands of Android apps, we systematically test DroidDetector and do
an in depth analysis on the features that deep learning basically exploit to differentiate
malware. The results show that deep learning is suitable for differential Android malware
and especially useful with the availability of more training data. DroidDetector can get
96.76 percent detection accuracy, which outperforms traditional machine learning tech-
niques. An estimation of ten popular anti-virus softwares demonstrates the importance
of advancing our capabilities in Android malware finding.
iv
Acknowledgment
It is our immense pleasure to work on this project Malware Detection in Android
App Using Static and Dynamic Analysis. It is only the blessing of my divine master
which has prompted and mentally equipped us to undergo the study of this project.
We would like to thank Dr.Arunkumar Dwivedi, Principal, LoGMIEER College of
Engineering for giving me such an opportunity to develop practical knowledge about
subject. We are also thankful to Prof K. V.Ugale, Head of Computer Engineering
Department for his valuable encouragement at every phase of our seminar work and
completion.
We offer our sincere thanks to my guide Prof.N.V. Kapade, who very affectionately
encourages us to work on the subject and gave his valuable guidance time to time. While
preparing this project We are very much thankful to his.
We are also grateful to entire staff of Computer Engineering Department for their kind
co-operation which helped me in successful completion of project.
v
Contents
Certificate ii
Abstract iv
Acknowledgment v
Index vi
List of Figures xi
List of Abbreviations xv
1 Synopsis 1
1.1 Project Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Project Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Internal Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Technical Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Goals and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.8 Relevant mathematics associated with the Project . . . . . . . . . . . . . 6
1.8.1 System Description . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8.2 Mathematical Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.9 Names of Conferences/Journals where papers can be published . . . . . . 8
1.10 Review of Conference /Journal Papers Supporting Project Idea . . . . . 9
1.11 Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.12 Plan of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.13 Plan of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Technical keywords 18
2.1 Area Of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Technical Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
vi
3 Introduction 21
3.1 Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Project Plan 35
5.1 Project Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Reconciled Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Project Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Risk Management w.r.t. NP Hard Analysis . . . . . . . . . . . . . . . . . 39
5.3.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.3 Overview Of Risk Mitigation,Monitoring,Management . . . . . . . 42
5.3.4 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.5 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.6 Task Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
vii
5.4.1 Management Reporting And Communication . . . . . . . . . . . . 47
5.4.2 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Design 68
7.1 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.1 Internal Data Structure . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.2 Global data Structure . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.3 Temporary data Structure . . . . . . . . . . . . . . . . . . . . . . 77
8 Project Implementation 78
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2 Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
viii
8.2.1 Java: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2.2 NetBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2.3 Android OS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.4 Android Environment . . . . . . . . . . . . . . . . . . . . . . . . 89
8.3 Methodologies/Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.3.1 Algorithm Steps: . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.3.2 Mathematical Model . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.4 Verication and Validation for Acceptance: . . . . . . . . . . . . . . . . . 96
9 Software Testing 99
9.1 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.1.1 Types Of Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.2 Testing Methodologies: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.3 User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . 103
9.2.4 Output Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2.5 Validation Checking . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3 Verication and Validation for Acceptance: . . . . . . . . . . . . . . . . . 105
10 Result 109
10.1 Analysis Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.2 Flow Of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
References 125
ix
Annexure B 128
Annexure C 134
Annexure D 138
Annexure E 140
Annexure F 141
x
List of Figures
1.1 Restricted Boltzmann Machines(RBM) . . . . . . . . . . . . . . . . . . . 7
xi
10.7 searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
xii
List of Tables
1.1 literature survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Time-Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 TimeLine Table for Project . . . . . . . . . . . . . . . . . . . . . . . . . 17
xiii
12.5 Test Case For Malware: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.6 Test Case For UI: User Registration: . . . . . . . . . . . . . . . . . . . . 146
xiv
List of Abbreviations
DBN: Deep Belief Networks
RBM: Restricted Boltzmann Machines
PRIM: Patient Rule Induction Method
xv
CHAPTER 1
SYNOPSIS
CHAPTER 1. SYNOPSIS
of a deep learning model has two phases, the unsupervised pretraining phase and super-
vised back-propagation phases. In the pre-training phase, the DBN is hierarchically built
by stacking a number of Restricted Boltzmann Machines (RBM), with the deep neural
network regarded as a latent variable model, which is bene?cial for gradually evolving
high-level representations. In the back-propagation phase, the pre-trained DBN is ?ne
tuned with labeled samples in a supervised manner. The deep learning model uses the
same app set in both phases of the training process. In this way, the deep learning model
is completely built.
We implement the Android malware detection engine Droid Detector based on the
deep learning model, Droid Detector has been open online for user testing and can au-
tomatically detect whether a submitted app is a malware or not. Once the .apk file of
an app is submitted, Droid Detector checks its integrity and determines whether it is a
complete, correct, and legitimate Android application. Next, Droid Detector executes a
static analysis to obtain the permissions and sensitive APIs that are used by this app.
Then, Droid Detector executes a dynamic analysis by installing and running this app in
DroidBox for a fixed period of time. In this way, Droid Detector identifies the dynamic
behaviors that are being performed. We have completely automated the static and dy-
namic analyses of DroidDetector. The detection results, including detailed information
from the integrity check and both analyses, are then reported to the users. Since the
new types of apps are constantly emerging, we have designed two crawler modules. One
is used for crawling benign apps from the Google Play Store and the other is used for
crawling malware from well-known malware. Using this strategy, we expect Droid De-
tector to keep pace with the evolution of Android malware. To validate the ability of
the deep learning model to detect Android malware and make an in-depth analysis on
the features that deep learning essentially exploits to characterize malware, we conducted
experiments on three public app sets. One benign app set was randomly crawled from the
Google Play Store. Although there might be a few malicious apps hidden among them,
we regard all of them as benign apps. Another two malicious app sets were respectively
collected from the Contagio Community.
In the next part of the study, we mixed together an equal number of malicious and
benign apps. In doing so, we obtained a training set and a test set, either of which
included malicious and benign randomly selected apps. The following experiments were
1.6 Abstract
Smartphones and mobile tablets are fast becoming necessary in daily life. Android
has been the most popular mobile operating system since 2012. However, due to the
open nature of Android, immeasurable malwares are hidden in a large number of kindly
apps in Android markets that dangerously pressure Android security. Deep learning is a
new area of machine learning research that has gained increasing detect in artificial in-
telligence. In this study, we propose to connect the features from the static analysis with
features from dynamic analysis of Android apps and differentiate malware using deep
learning techniques. We execute an Online deep-learning-based Android malware detec-
tion engine (DroidDetector) that can automatically identify whether an app is a malware
or not. With thousands of Android apps, we systematically test DroidDetector and do
an in depth analysis on the features that deep learning basically exploit to differentiate
malware. The results show that deep learning is suitable for differential Android malware
and especially useful with the availability of more training data. DroidDetector can get
96.76 percent detection accuracy, which outperforms traditional machine learning tech-
niques. An estimation of ten popular anti-virus softwares demonstrates the importance
of advancing our capabilities in Android malware finding.
F1=RBM Initialization We can increase the modeling capacity of the Boltzmann Ma-
chine (BM). A graphical depiction of an RBM is shown below
where W represents the weights connecting hidden and visible units and b,c are the
offsets of the visible and hidden layers respectively.
we are done with all layers of the DBN training, we use back-propagation to fine-
tune model. We can think of it as if we forget about the DBN model and we just
keep the same network but we pleasure it as a mlp (with the same units and the
same connections among them) and we use the weights we got in the training of
the DBN for mlp. Now, we use back-propagation to fine-tune wer model.
2. When we follow the steps declare above and we fine-tune a mlp using back-propagation,
we can use a conformation set for hyper-parameter selection. So, its the same as
training a mlp.
3. In fact, unsupervised pre-training is especially useful when we have very few marker
data. It puts parameters in the right regime and we can use very few marker exam-
ples to fine-tune it. However, it is possible to over t and we can use regularization
methods to avoid it. Another exciting issue is that, unsupervised pre-training is a
regularize itself. It forces the weights of the model to be close to the weights that
represent the data.
Sf= Greedy Scheme(),Training(),Generate(),Error(),Iterative operation().
Ct= bigO(n)
Cs= bigO(m)
Pn= 1
1.11 Explanation
1. DroidMiner: automatic Mining and classification of Fine-grained Malicious
Behaviors in Android Applications.
Android app finding approaches rely on yourself selected detection heuristics, fea-
tures, and models. In this paper, we explain a new, corresponding method, called Droid-
Miner, which uses static analysis to automatically mine malicious program reason from
known Android malware, abstracts this reason into a sequence of threat modalities, and
then seeks out these threat modality patterns in other unknown Android apps
A new technique will be introduced to detect malware. This technique detects mal-
ware in android function through machine learning classifier by using both static and
dynamic analysis. This technique does not rely on malware name for static analysis but
instead android permission model is used. Under dynamic analysis, system identify trac-
ing is performed. Using both static and dynamic techniques along with machine learning
provides all in one answer for malware detection. The technique used by us is tested on
various benign samples collected from authorized android market (Google Play Store)
and on various malicious applications.
market places.
TECHNICAL KEYWORDS
CHAPTER 2. TECHNICAL KEYWORDS
• Java
Java is a programming language. It was first developed by James Gosling at Sun
Microsystems, which is now a part of Oracle Corporation. It was released in 1995
as a part of Sun Microsystems Java platform. The language has developed much
of its syntax from C and C++. Java applications are usually compiled to bytecode
class ?le that can run on any Java Virtual Machine (JVM). Java is currently one of
the most popular programming languages being used. It has about 10 million users.
• NetBeans 8.2
The project belongs to the field of Android Applications and it can be used for Protection
and Security purpose.
INTRODUCTION
CHAPTER 3. INTRODUCTION
3.1 Need
Android market, such as the Google Play Store and other third-party markets, play
an important role in the popularity of Android devices. However ,the closeness of Android
makes these markets hot targets for malware attacks and causes in finite instances of
malware being hidden behind a large number of benign apps that seriously threatens
users’ security and privacy.
Today, the main countermeasure to defense against malware on Android platforms
is a risk communication mechanism that informs users about the permissions required
before installing each app. This mechanism is rather ineffective, as it presents permissions
in a stand-alone fashion, thus requiring too much technical knowledge for a user to be
able to differentiate malware from benign apps. A better characterization of Android
malware would achieve a better accuracy in their detection. Deep learning is a new area
of machine learning investigation that imitates the way the human brain works and has
gained increasing work in the field of artificial intelligence.
We first extracted a total of 192 features from static and dynamic app analysis and
then apply the deep learning technique to distinguish malware from benign apps.
attain 96.76 detection accuracy, which outperforms traditional machine learning method.
An evaluation of ten famous anti-virus softwares demonstrates the urgency of advancing
our capabilities in Android malware detection.
In this project, our contributions include: We describe our development of a deep-
–learning-based Android malware detection engine (Droid Detector) that has been put
online for user testing and can automatically detect whether an app is a malware or
not. We crawl 20000 apps from the Google Play Store and collect 1760 malwares from
the well-known Contagion Community and Genome Project With these real-world apps,
we thoroughly test DroidDetector and execute an in-depth analysis on the features that
deep learning basically exploits to characterize malware using association rule mining
techniques. We conduct experiments on ten popular anti-virus software and reveal that
they are extremely vulnerable to packet operation. In the light of our analyses, we reason
that deep learning is a promising technique for Android malware detection.
monitor a mixture of app actions such as information leaks, network and le in-
put/output, cryptography operation like, Short Message Services (SMS), and mo-
bile phone calls. In this study, we ran the apps inside DroidBox for a time period
to obtain the executed app actions (i.e., dynamic behaviors) of each app. In this
phase, we monitored a total of 13 app actions. For example, action send net is the
action that sends data over the network, action phone calls is the action that sorts a
phone call, and action send sms is the action that sends SMS messages. In this way,
we achieve a total of 192 features for each app through static and dynamic analyses.
• Deep learning:
Deep learning models with a deep architecture change that condition. In practical
use, a deep learning model can be constructed with different deep architectures,
e.g., Deep Belief Networks (DBN) and property neural networks. For this paper, we
chose DBN architecture to build our deep learning model and characterize Android
apps. The construction of a deep learning model has two phases, the un-supervised
pre-training phase and supervised back-propagation phases.
• DBN:
The DBN is hierarchically built by stacking a number of Restricted Boltzmann
Machines (RBM), with the deep neural network respect as a latent variable model,
which is beneficial for gradually evolving high-level representations. In the back-
propagation phase, the pre-trained DBN is ne-tuned with labeled samples in a
supervised manner. The deep learning model uses the same app set in both segment
of the training process.
• Droid Detector :
We implemented the Android malware detection engine DroidDetector based on
the deep learning model, as shown in Fig. DroidDetector has been open online for
user testing and can automatically detect whether a submitted app is a malware or
not. Once the .apk file of an app is submitted, DroidDetector checks its integrity
and determines whether it is a complete, correct, and legitimate Android applica-
tion. Next, DroidDetector executes a static analysis to obtain the permissions and
sensitive APIs that are used by this app. Then, DroidDetector executes a dynamic
analysis by installing and running this app in DroidBox for a fixed period of time. In
this way, DroidDetector identifies the dynamic behaviors that are being performed.
• Malware:
Android malware is malicious software that is specifically built to attack mobile
phone or smartphone systems. These types of malware rely on develop a particular
operating systems (OS) and mobile phone software technology, and represent a
important part of malware attacks in today’s computing world, where mobile phones
are increasingly common.
them from malicious User. This activity takes place when user enters the Login
details. In Authentication we authenticate the User by matching the Entered ID
and Password with the saved ID and Password in the Database.
3. Sample Database:
Sample Database contains Password, User name, and Account details.
4. Static Analysis: Required permissions and sensitive APIs are extracted through
the static analysis. static analyses to characterize Android malware and extract
features from each app.
5. Dynamic Analysis:
Dynamic analysis app analyses and then applied the deep learning technique. dy-
namic analysis of Android apps and learn the difference between malware and be-
nign apps automatically.
6. Deep learning:
Deep learning is a capable technique for Android malware detection. deep learning
model has two phases, the unsupervised pre-training phase and supervised back-
propagation phases.
7. DBN:
The DBN is hierarchically built by stacking a number of Restricted Boltzmann Ma-
chines (RBM), which is bene?cial for gradually evolving high-level representations.
The pre-trained DBN is ?ne-tuned with marker samples in a supervised manner.
8. Droid Detector :
Droid Detector has been open online for user testing and can automatically identify
whether a submitted app is a malware or not. Once the .apk file of an app is sub-
mitted, Droid Detector checks its integrity and determines whether it is a complete,
correct, and legitimate Android application.
9. Malware:
Android malware is malicious software that is specifically built to attack mobile
phone or smartphone systems. These types of malware rely on develop a particular
operating systems (OS) and mobile phone software technology, and represent a
important part of malware attacks in today’s computing world, where mobile phones
are increasingly common.
4.4 Outcome
The Output from the computer is required to mainly create an efficient method of
communication within the company primarily among the project leader and his team
members, in other words, the administrator and the clients. The output of VPN is the
system which allows the project leader to manage his clients in terms of creating new
clients and assigning new projects to them, maintaining a record of the project validity
and providing folder level access to each client on the user side depending on the projects
allotted to him. After completion of a project, a new project may be assigned to the
client. User authentication procedures are maintained at the initial stages itself. A new
user may be created by the administrator himself or a user can himself register as a
new user but the task of assigning projects and validating a new user rests with the
administrator only.
The application starts running when it is executed for the first time. The server
has to be started and then the internet explorer in used as the browser. The project
will run on the local area network so the server machine will serve as the administra-
tor while the other connected systems can act as the clients. The developed system is
highly user friendly and can be easily understood by anyone using it even for the first time.
4.5 Applications
The application that will be developed is going to be useful to the police force. We
could say that the intended audience for the application are the various types of police
forces.
• It provide security to mobile user.
• Security of the Android platform.
• Android markets and smartphones.
• It is also used in business, as well as commercial purpose.
PROJECT PLAN
CHAPTER 5. PROJECT PLAN
Waterfall Model is also called as the Linear Sequential Life Cycle Model. This model
followed in the sequential order and so we move to next step of development of software.
• Requirements
This is the first phase of the development in which all requirements are gathered
and documented.Requirements are:
- Android device.
- Google PlayStore.
• System Models
In system design and analysis phase all gathered requirements whether the require-
ments are valid or not.
- Deep learning model
- Machine learning model
- Automatic static analysis
- Automatic dynamic analysis
- Crawler
• Implementation
In implementation phase all development works are performed and development
components are handed over to the testing. Implementation consist of:
-UML Diagrams
- DFD Level 0
- DFD Level 1
- DFD Level 2
• Testing
Once the development completed, testing phase starts. In this phase we test the
each unit and also make sure that the developed components are working as per
expected.
-Black box and White box testing.
-GUI testing.
-Validation testing.
-Scenario based testing.
• Verification
Once the testing is completed and make sure that there is no bug and issue, then
project is deployed.
-Customers feedback.
-Customers satisfaction.
• Maintenance
In maintenance phase we can maintain the developed software product.
-Hand manual.
-User Guide.
It is the most frequently used technique for evaluating the effectiveness of the pro-
posed system. More commonly known as cost/benefit analysis. It determines the benefits
savings that are expected from the proposed system compare them with costs. The sys-
tem is economically feasible since it would not entail additional hardware, thereby savings
on the costs the manpower involved.
In economical feasibility study we do some calculations as follow.
-To calculate the efforts, time and KLOC we use the COCOMO i.e. Cost Constructing
Model.
-Types of COCOMO.
1.For beginners (design phase)
2.COCOMO 1.2 (coding phase)
3.COCOMO 2.0(after completing all phases)
We develop software of organic category. For this category COCOMO providing following:
SOFTWARE REQUIREMENT
SPECIFICATION
CHAPTER 6. SOFTWARE REQUIREMENT SPECIFICATION
6.1 Introduction
Asoftware requirements specification (SRS) is a description of a software system to
be developed, laying out functional and non-functional requirements, and may include a
set of use cases that describe interactions the users will have with the software.
To validate the ability of the deep learning model to detect Android malware and
make an in-depth analysis on the features that deep learning essentially exploits to char-
acterize malware, we conducted experiments on three public app sets. One benign app set
was randomly crawled from the Google Play Store, which contains a large-scale of 20000
apps. Although there might be a few malicious apps hidden among them, we regard all
of them as benign apps. Another two malicious app sets were respectively collected from
the Contagio Community (there are only about 400 apps at present, as we have accumu-
lated for two years, 500 malicious apps are collected)and Genome Project(including1260
malicious apps). So,the total number of malicious apps is 1760 while there are 20000
benign apps.
Product perspective
Android market, such as the Google Play Store and another third-party markets,
play an important role in the popularity of Android devices. However ,the closeness of
Android makes these markets hot targets for malware attacks and causes infinite instances
of malware being hidden behind a large number of benign apps that seriously threatens
users’ security and privacy.
Today, the main countermeasure to defense against malware on Android platforms is a
risk communication mechanism that inform users about the permissions required before
installing each app. This mechanism is rather ineffective, as it presents permissions in
a stand-alone fashion, thus requiring too much technical knowledge for a user to be
able to differentiate malware from benign apps. A better characterization of Android
malware would achieve a better accuracy in their detection. Deep learning is a new area
of machine learning investigation that imitates the way the human brain works and has
gained increasing work in the field of artificial intelligence.
We first extracted a total of 192 features from static and dynamic app analysis and then
apply the deep learning technique to distinguish malware from benign apps.
6.2.2 Use-cases
A use-case diagram shows a set of use cases and actors and their relationships. These
diagrams are used to shows the static use case view of system. Use case diagrams are
more important in developing the behavior of system. Use case diagram represent a set
of use cases and actors and their relationships.
Use case diagrams describe a user action Online submitted app, App integrity check-
ing. Dynamic Analysis takes Android APK, Droid Box sandbox, Dynamic behavior ac-
tions. . Then static analysis 1 takes Required permission(),Readable file(),AndroidManifest
.xml() actions as well as static analysis 2 takes Sensitive API(), Disassembled files(),
classes.dex() actions. Then Crawled take Newly crawled malware to static analysis.
Then Deep learning Pre-trained() and Back propagation for ?ne-tuning() action takes
place and checks app Malware or not. Then DBN takes action RBM initialization(),
CD-k Sampling(), Updating parameter(), RBM Assessment() functions.
In above DFD level 0 views the user uses Deep Belief Networks (DBN) for graphical
model implement with Static Analysis and Dynamic Analysis.
In above DFD level 1 shows that in Static Analysis AndroidManifest .xml and classes
file is a parser that required some permissions and can be modify,read by readable file.
By Disassembled files we can know which API function is called that are sensitive API.
Dynamic Analysis using droidbox we can install and run each app. In dynamic behavior
obtain executed actions of app. Deep Belief Networks (DBN) first initialize Restricted
Boltzmann Machines (RBM), training CD-K Sampling. Contrastive Divergence (CD-k),
generate Updating Parameters, The RBM Communications Assessment.
In above DFD level 2 shows that in Static Analysis AndroidManifest .xml and classes
file is a parser that required some permissions and can be modify,read by readable file.
By Disassembled files we can know which API function is called that are sensitive API.
Crawler 1 and Crawler 2 provide Newly Crawler Malware and Google PlayStore for
Android App Malware detection. Dynamic Analysis using droidbox we can install and
run each app. In dynamic behavior obtain executed actions of app. Crawler 1 and
Crawler 2 checks positive feature set and negative feature set, Then control goes to
Deep Learning model, Deep Belief Networks (DBN) first initialize Restricted Boltzmann
Machines (RBM), training CD-K Sampling. Contrastive Divergence (CD-k), generate
Updating Parameters, The RBM Communications Assessment.
A Class diagram describes the structure of a system that shows the User class that
perform the Automatic static analysis(), Automatic dynamic analysis(),Deep learning
model(),Online submitted app(),App integrity checking() functions. Then static analysis
1 perform Required permission(),Readable file(),AndroidManifest .xml() as well as static
analysis 2 perform Sensitive API(), Disassembled ?les(), classes.dex() functions. After
• Simple: Java was designed to be easy for the Professional programmer to learn and
to use effectively. If you are an experienced C++ programmer, learning Java will
be even easier. Because Java inherits the C/C++ syntax and many of the object
oriented features of C++. Most of the confusing concepts from C++ are either left
out of Java or implemented in a cleaner, more approachable manner. In Java there
are a small number of clearly defined ways to accomplish a given task.
• Admin
Admin will authorize Users and view the documents uploaded. Admin will scan for
droid (malware) documents and send the alert to corresponding users and show the
ratio of droid affected files and the total files. Admin can view all the transactions
and the attackers for corresponding files. And also admin can block the user who
spreads the droid documents. Admin views the number of droid affected documents
and droid free documents in chart.
DESIGN
CHAPTER 7. DESIGN
app may require the same permissions and are thus indistinguishable via this permission-
based mechanism. In general, permission-based approaches are developed primarily for
risk assessment rather than malware detection.
Disadvantages
• Malware attacks and causes countless instances of malware being hidden behind a
large number of being apps that seriously threatens users security and privacy.
deep learning model for classification. The detection results, including detailed informa-
tion from the integrity check and both analyses, are then reported to the users. Since the
new types of apps are constantly emerging, This system designed two crawler modules.
One is used for crawling benign apps from the Google Play Store and the other is used
for crawling malware from well-known malware sources (e.g., Contagio and Genome).
Using this strategy, we expect DroidDetector to keep pace with the evolution of Android
malware.).
To validate the ability of the deep learning model to detect Android malware and
make an in-depth analysis on the features that deep learning essentially exploits to
char-acterize malware, we conducted experiments on three public app sets. One benign
app set was randomly crawled from the Google Play Store, which contains a large-s-
cale of 20000 apps. Although there might be a few malicious apps hidden among them,
and regard all of them as benign apps. Another two malicious app sets were respec-
tively collected from the Contagio Community (there are only about 400 apps at present,
as we have accumu-lated for two years, 500 malicious apps are collected)and Genome
Project(including1260 malicious apps). So, the total number of malicious apps is 1760
while there are 20000 benign apps.
In the static phase, we uncompress the .apk le with the 7-Zip tool and then focus
on parsing the two les AndroidManifest.xml classes.dex. By analyze the Android Man-
ifest.xml file with the tool AXML-Printer2 and the parser TinyXml, we can find the
permissions necessary by the app. For example, android permission of call, phone is
the permission obtain for an app to make a phone call and, camera is the permission
required for an app to access the camera. In this we looked for a total of 120 permissions.
By parsing the classes.dex file with the disassembler baksmali, we know that which API
functions are called. For ex. chmod is a sensitive API that might be used for changing
users permissions on les and Content Resolver delete is a sensitive API that might be
used for deleting user messages or contacts. In this step, we looking for a total of 59
sensitive API functions.
In the dynamic phase, then install and run each app in DroidBox. DroidBox is an
Android application sandbox that extends Taint Droid which can execute a dynamic taint
analysis with system hooking at the application framework level and examine a variety
of app actions such as information escape, network and file input/output, cryptography
operations, Short Message Services (SMS), and mobile phone calls. In this paper, we
run the apps inside DroidBox for a period of time to find the executed app actions (i.e.,
dynamic behaviors) of each app. In this phase and monitored a total of 13 app actions.
For instance, action send net is the action that sends data over the network, action phone
calls is the action that makes a phone call, and action send sms is the action that sends
SMS messages. In this way, we achieve a total of 192 features for each app by static and
dynamic analyses. In this important factor that each feature is binary, representing that
when a feature occurs in an app, its feature value is 1; otherwise, its feature value is 0.
In addition, all the tools (i.e., 7-Zip, AXMLPrinter2, TinyXml, baksmali, and DroidBox)
In this system implemented that the Android malware detection engine DroidDetec–
tor based on the deep learning DroidDetector has been open online for user testing and
can automatically detect whether a submitted app is a malware or not. Once the .apk le
of an app is submitted, DroidDetector checks its integrity and determines whether it is
a complete, correct, and legitimate Android application. Next, DroidDetector executes
a static analysis to obtain the permissions and sensitive API that are used by this app.
Then, DroidDetector executes a dynamic analysis by installing and running this app in
DroidBox for a xed period of time. In this way, DroidDetector identi es the dynamic be-
haviors that are being performed. In this a completely automated the static and dy-namic
analyses of DroidDetector. Once the total 192 binary features described in Section 2 have
been collected, they are input in the deep learning model for classi cation. The detection
results, including detailed information from the integrity check and both analy-ses, are
then reported to the users. Since the new types of apps are constantly emerging, and
designed two crawler modules. One is used for crawling benign apps from the Google
Play Store and the other is used for crawling malware from well-known malware sources
(e.g., Contagio and Genome).
Using this strategy, we expect DroidDetector to keep pace with the evolution of
Android malware apps are constantly emerging; we have designed two crawler modules.
One is used for crawling benign apps from the Google Play Store and the other is used
for crawling malware from well-known malware sources (e.g., Contagio and Genome).
Using this strategy, we expect DroidDetector to keep pace with the evolution of An–
droid malware. 4 Evaluation To validate the ability of the deep learning model to detect
Android malware and make an in-depth analysis on the features that deep learning ef-
fectively utilize to differentiate malware, we conducted experiments on three public app
sets. One benign app set was randomly crawled from the Google Play Store, which con-
tains a large-scale of 20000 apps. Although there might be a few malicious apps hidden
among them, we regard all of them as benign apps. Another two malicious app sets were
respectively collected from the Contagio Community.
Traditional machine learning models that have less than three layers of computation
units are considered to have shallow architectures. Fortunately, deep learning models with
a deep architecture change that situation. In practical use, a deep learning model can be
constructed with different deep architectures e.g., Deep Belief Networks (DBN) and con-
volutional neural networks. For this study, we chose DBN architecture to construct our
deep learning model and characterize Android apps. The construction of a deep learning
model has two phases, the unsupervised pre-training phase and supervised back-prop-
agation phases. In the pre-training phase, the DBN is hierarchically built by stacking
a number of Restricted Boltzmann Machines (RBM), with the deep neural network re-
garded as a latent variable model, which is beneficial for gradually evolving high-level
representations. In the back-propagation phase, the pre-trained DBN is finetuned with
labeled samples in a supervised manner. The deep learning model uses the same app set
in both phases of the training process. In this way, the deep learning model is completely
built.
module design.
Input design is the process of converting the user created input into a computer-
based format. The goal of the input design is to make the data entry logical and
free from errors. The error is in the input are controlled by the input design.
The application has been developed in user-friendly manner. The forms have been
designed in such a way during the processing the cursor is placed in the position
where must be entered. The user is also provided with in an option to select an
appropriate input from various alternatives related to the field in certain cases.
Validations are required for each data entered. Whenever a user enters an erroneous
data, error message is displayed and the user can move on to the subsequent pages
after completing all the entries in the current page.
• Output Design
The Output from the computer is required to mainly create an efficient method
of communication within the company primarily among the project leader and his
team members, in other words, the administrator and the clients. The output
of VPN is the system which allows the project leader to manage his clients in
terms of creating new clients and assigning new projects to them, maintaining a
record of the project validity and providing folder level access to each client on
the user side depending on the projects allotted to him. After completion of a
project, a new project may be assigned to the client. User authentication procedures
are maintained at the initial stages itself. A new user may be created by the
administrator himself or a user can himself register as a new user but the task of
assigning projects and validating a new user rests with the administrator only.
The application starts running when it is executed for the first time. The server has
to be started and then the internet explorer in used as the browser. The project will
run on the local area network so the server machine will serve as the administrator
while the other connected systems can act as the clients. The developed system is
highly user friendly and can be easily understood by anyone using it even for the
first time.
PROJECT IMPLEMENTATION
CHAPTER 8. PROJECT IMPLEMENTATION
8.1 Introduction
To implement a system successfully, a large number of inter-related tasks need to be
carried out in an appropriate sequence. Utilising a well-proven implementation method-
ology and enlisting professional advice can help but often it is the number of tasks,
poor planning and inadequate resounding that causes problems with an implementation
project, rather than any of the tasks being particularly difficult. Similarly with the cul-
tural issues it is often the lack of adequate consultation and two-way communication that
inhibits achievement of the desired results.
8.2.1 Java:
Java is a general-purpose computer programming language that is concurrent, class
based, object-oriented, and specically designed to have as few implementation dependen
cies as possible. It is intended to let application developers write once, run anywhere
(WORA), meaning that compiled Java code can run on all platforms that support Java
without the need for recompilation. Java applications are typically compiled to bytecode
that can run on any Java virtual machine (JVM) regardless of computer architecture. As
of 2016, Java is one of the most popular programming languages in use, particularly for
client-server web applications, with a reported 9 million developers. Java was originally
developed by James Gosling at Sun Microsystems (which has since been acquired by
Oracle Corporation) and released in 1995 as a core component of Sun Microsystems Java
platform. The language derives much of its syntax from C and C++, but it has fewer
low-level facilities than either of them.The original and reference implementation Java
compilers, virtual machines, and class libraries were originally released by Sun under
proprietary licences. As of May 2007, in compliance with the specications of the Java
Community Process, Sun relicensed most of its Java technologies under the GNU General
Public License. Others have also developed alternative implementations of these Sun
technologies, such as the GNU Compiler for Java (bytecode compiler), GNU Classpath
(standard libraries), and IcedTea-Web (browser plugin for applets).
The latest version is Java 8 Update 121 which is the only version currently supported
for free by Oracle, although earlier versions are supported both by Oracle and other
companies on a commercial basis.
James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java lan guage
project in June 1991. Java was originally designed for interactive television, but it was
too advanced for the digital cable television industry at the time.The language was ini-
tially called Oak after an oak tree that stood outside Goslings oce. Later the project went
by the name Green and was nally renamed Java, from Java coee. Gosling de signed Java
with a C/C++-style syntax that system and application programmers would nd familiar.
• Principles: There were ve primary goals in the creation of the Java language:
1. It must be simple, object-oriented, and familiar
2. It must be robust and secure.
3. It must be architecture-neutral and portable.
4. It must execute with high performance.
5. It must be interpreted, threaded, and dynamic.
• Class libraries: The Java Class Library is the standard library, developed to
support application development in Java. It is controlled by Sun Microsystems in
cooperation with others through the Java Community Process program. Companies
or individuals participating in this process can inuence the design and development
of the APIs. This process has been a subject of controversy. The class library
contains features such as: 1. IO/NIO
2. Networking
3. Reection
4. Concurrency
5. Generics
6. Scripting/Compiler
7. Functional Programming (Lambda, Streaming)
8. Collection libraries that implement data structures such as lists, dictionaries,
trees, sets, queues and double-ended queue, or stacks
9. XML Processing (Parsing, Transforming, Validating) libraries
Features of Java:
There is given many features of java. They are also known as java buzzwords. The Java
Features given below are simple and easy to understand.
1. Simple
2. Object-Oriented
3. Portable
4. Platform independent
5. Secured
6. Robust
7. Architecture neutral
8. Dynamic
9. Interpreted
10. High Performance
11. Multi-threaded
12. Distributed
• Simple: syntax is based on C++ (so easier for programmers to learn it after
C++).removed many confusing and/or rarely-used features e.g., explicit pointers,
operator over loading etc. No need to remove unreferenced objects because there is
Automatic Garbage Collection in java.
which a program runs. There are two types of platforms software-based and hard-
ware based. Java provides software-based platform.The Java platform diers from
most other platforms in the sense that it is a software-based platform that runs on
the top of other hardware-based platforms. It has two components:
1. Runtime Environment
2. API(Application Programming Interface)
• Java code can be run on multiple platforms e.g. Windows, Linux, Sun Solaris,
Mac/OS etc. Java code is compiled by the compiler and converted into bytecode.
This bytecode is a platform-independent code because it can be run on multiple
platforms i.e. Write Once and Run Anywhere(WORA).
• Secured: Java is secured because:
1. No explicit pointer
2. Java Programs run inside virtual machine sandbox
3. Classloader:adds security by separating the package for the classes of the local
le system from those that are imported from network sources.
4. Bytecode Verier: checks the code fragments for illegal code that can violate
access right to objects.
5. Security Manager: determines what resources a class can access such as reading
and writing to the local disk.
• Robust: Robust simply means strong. Java uses strong memory management.
There are lack of pointers that avoids security problem. There is automatic garbage
collection in java. There is exception handling and type checking mechanism in java.
All these points makes java robust.
8.2.2 NetBean
NetBeans IDE is a modular, standards-based integrated development environment
(IDE), written in the Java programming language. The NetBeans project consists of
a full-featured open source IDE written in the Java programming language and a rich
client application platform, which can be used as a generic framework to build any kind
of application.
NetBeans IDE 8.2 provides out-of-the-box code analyzers and editors for working
with the latest Java 8 technologies-Java SE 8, Java SE Embedded 8, and Java ME Em-
bedded 8. The IDE also has a range of new tools for HTML5/JavaScript, in particular for
Node.js, KnockoutJS, and AngularJS; enhancements that further improve its support for
Maven and Java EE with PrimeFaces; and improvements to PHP and C/C++ support.
Feature of NetBean
• ECMAScript 6 and Experimental ECMAScript 7 Support
- New hexa, binary, and octal literals
- Source editor support
- Code completion for generators
• Node.js Enhancements
- Grunt and Gulp Task Runners
- Support for Node.js 4.0 and newer
- Return statement in global context
touchscreen devices, Google has further developed Android TV for televisions, Android
Auto for cars, and Android Wear for wrist watches, each with a specialized user interface.
Variants of Android are also used on notebooks, game consoles, digital cameras, and other
electronics.
Initially developed by Android Inc., which Google bought in 2005, Android was
unveiled in 2007, along with the founding of the Open Handset Alliance a consortium
of hardware, software, and telecommunication companies devoted to advancing open
standards for mobile devices. Beginning with the first commercial Android device in
September 2008, the operating system has gone through multiple major releases, with
the current version being 7.0 ”Nougat”, released in August 2016. Android applications
(”apps”) can be downloaded from the Google Play store, which features over 2.7 million
apps as of February 2017. In September 2015, Android had 1.4 billion monthly active
users, and it has the largest installed base of any operating system. Androids underlying
kernel is based on Linux, but it has been customized to suit Googles directions. There
is no support for the GNU libraries and it does not have a native X Windows system.
Inside the Linux kernel are found drivers for the display, camera, ash memory, keypad,
WiFi and audio. The Linux kernel serves as an abstraction between the hardware and the
rest of the software on the phone. It also takes care of core system services like security,
memory management, process management and the network stack.
Features of Android:
• Multitasking: Multitasking of applications, with unique handling of memory al-
location, is available.
• Video calling: Android does not support native video calling, but some hand-
sets have a customized version of the operating system that supports it, either via
the UMTS network (like the Samsung Galaxy S) or over IP. Video calling through
Google Talk is available in Android 2.3.4 (Gingerbread) and later. Gingerbread
allows Nexus S to place Internet calls with a SIP account. This allows for enhanced
VoIP dialing to other SIP accounts and even phone numbers. Skype 2.1 oers video
calling in Android 2.3, including front camera support. Users with the Google+
Android app can video chat with other Google+ users through Hangouts.
• Bluetooth: Supports voice dialing and sending contacts between phones, playing
music, sending les (OPP), accessing the phone book (PBAP), A2DP and AVRCP.
Keyboard, mouse and joystick (HID) support is available in Android 3.1+, and in
earlier versions through manufacturer customizations and third-party applications.
• Java support: While most Android applications are written in Java, there is no
Java Virtual Machine in the platform and Java byte code is not executed. Java
classes are compiled into Dalvik executables and run on using Android Runtime
or in Dalvik in older versions, a specialized virtual machine designed specically for
Android and optimized for battery-powered mobile devices with limited memory
and CPU. J2ME support can be provided via third-party applications.
App Components App components are the essential building blocks of an Android app.
Each component is a different point through which the system can enter your app. Not
all components are actual entry points for the user and some depend on each other, but
each one exists as its own entity and plays a specific roleeach one is a unique building
block that helps define your app’s overall behavior.
There are four different types of app components. Each type serves a distinct purpose
and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of app components:
• Activities: An activity represents a single screen with a user interface. For exam-
ple, an email app might have one activity that shows a list of new emails, another
activity to compose an email, and another activity for reading emails. Although
the activities work together to form a cohesive user experience in the email app,
each one is independent of the others. As such, a different app can start any one
of these activities (if the email app allows it). For example, a camera app can start
the activity in the email app that composes new mail, in order for the user to share
a picture. An activity is implemented as a subclass of Activity and you can learn
more about it in the Activities developer guide.
• Content providers: A content provider manages a shared set of app data. You
can store the data in the file system, an SQLite database, on the web, or any other
persistent storage location your app can access. Through the content provider,
other apps can query or even modify the data (if the content provider allows it).
For example, the Android system provides a content provider that manages the
user’s contact information. As such, any app with the proper permissions can
query part of the content provider (such as Contacts Contract. Data) to read and
write information about a particular person.
Content providers are also useful for reading and writing data that is private to
your app and not shared. For example, the Note Pad sample app uses a content
provider to save notes. A content provider is implemented as a subclass of Content
Provider and must implement a standard set of APIs that enable other apps to
perform transactions. For more information, see the Content Providers developer
guide.
A unique aspect of the Android system design is that any app can start another
apps component. For example, if you want the user to capture a photo with the
device camera, there’s probably another app that does that and your app can use
it, instead of developing an activity to capture a photo yourself. You don’t need to
incorporate or even link to the code from the camera app. Instead, you can simply
start the activity in the camera app that captures a photo. When complete, the
photo is even returned to your app so you can use it. To the user, it seems as if the
camera is actually a part of your app.
When the system starts a component, it starts the process for that app (if it’s
not already running) and instantiates the classes needed for the component. For
example, if your app starts the activity in the camera app that captures a photo,
that activity runs in the process that belongs to the camera app, not in your app’s
process. Therefore, unlike apps on most other systems, Android apps don’t have a
single entry point (there’s no main() function, for example).
Because the system runs each app in a separate process with file permissions that
restrict access to other apps, your app cannot directly activate a component from
another app. The Android system, however, can. So, to activate a component in
another app, you must deliver a message to the system that specifies your intent to
start a particular component. The system then activates the component for you.
8.3 Methodologies/Algorithm
Step 2: Conduct static and dynamic analyses to extract features from each app.
Step 3: The static phase, we uncompress the .apk file with the 7-Zip tool and then
focus on parsing AndroidManifest.xml and classes.dex.
Step 4: By parsing the Android Manifest.xml file with the tool AXML-Printer2 and
the parser TinyXml.
Step 6: The disassemble baksmali, we can know which API functions are
called(chmod) by parsing classes.dex
Step 7: Chmod is a sensitive API that might be used for changing users permissions on
files.
Step 9: In future set each feature are denoted in binary, indicating that
if (feature occurs in an app.)
feature value is 1;
else
feature value is 0.
F1=RBM Initialization We can increase the modeling capacity of the Boltzmann Ma-
chine (BM). A graphical depiction of an RBM is shown below
where W represents the weights connecting hidden and visible units and b,c are the
offsets of the visible and hidden layers respectively.
Ct= bigO(n)
Cs= bigO(m)
Pn= 1
SOFTWARE TESTING
CHAPTER 9. SOFTWARE TESTING
• Integration testing
Integration tests are designed to test integrated software components to determine
if they actually run as one program. Testing is event driven and is more concerned
with the basic outcome of screens or fields. Integration tests demonstrate that al-
though the components were individually satisfaction, as shown by successfully unit
testing, the combination of components is correct and consistent. Integration test-
ing is specifically aimed at exposing the problems that arise from the combination
of components.
• Functional test
Functional tests provide systematic demonstrations that functions tested are avail-
able as specified by the business and technical requirements, system documentation,
and user manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.
• System Test
System testing ensures that the entire integrated software system meets require-
ments. It tests a configuration to ensure known and predictable results. An exam-
ple of system testing is the configuration oriented system integration test. System
testing is based on process descriptions and flows, emphasizing pre-driven process
links and integration points.
2. Bottom-up Integration
This method begins the construction and testing with the modules at the lowest
level in the program structure. Since the modules are integrated from the bottom up,
processing required for modules subordinate to a given level is always available and the
need for stubs is eliminated. The bottom up integration strategy may be implemented
with the following steps:
• The low-level modules are combined into clusters into clusters that perform a spe-
cific Software sub-function.
• A driver (i.e.) the control program for testing is written to coordinate test case
input and output.
• The cluster is tested.
• Drivers are removed and clusters are combined moving upward in the program
structure
The bottom up approaches tests each module individually and then each module is
module is integrated with a main module and tested for functionality.
• Text Field:
The text field can contain only the number of characters lesser than or equal to
its size. The text fields are alphanumeric in some tables and alphabetic in other
tables. Incorrect entry always flashes and error message.
• Numeric Field:
The numeric field can contain only numbers from 0 to 9. An entry of any character
flashes an error messages. The individual modules are checked for accuracy and
what it has to perform. Each module is subjected to test run along with sample
data. The individually tested modules are integrated into a single system. Testing
involves executing the real data information is used in the program the existence of
any program defect is inferred from the output. The testing should be planned so
that all the requirements are individually tested. A successful test is one that gives
out the defects for the inappropriate data and produces and output revealing the
errors in the system.
RESULT
CHAPTER 10. RESULT
Admin will authorize Users and view the documents uploaded. Admin will scan for
droid (malware) documents and send the alert to corresponding users and show the ratio
of droid affected files and the total files. Admin can view all the transactions and the
attackers for corresponding files. And also admin can block the user who spreads the
droid documents. Admin views the number of droid affected documents and droid free
documents in chart.
User has to register and get authorized by the admin to login, and then the user will
upload the documents with the digital sign, and share the uploaded file to other users.
The user will search for documents by giving the keyword based on the contents, and
downloads the related documents. The user will also verify the uploaded documents from
the data integrity attacker and recover if it is not safe (attacked).
11.1.1 Java:
Java JDK for Windows
1. Goto Java SE download site @
http://www.oracle.com/technetwork/java/javase/downloads/index.html.
2. Look for the latest Java SE Development Kit 8uxx
3. Check Accept License Agreement.
4. Choose the JDK for your operating system, e.g., Windows x64 (for 64-bit Win dows
OS) or Windows x86 (for 32-bit Windows OS).As soon as you click to download le , a
pop-up window will appear asking for either save or run le.
5. Select Save File or Save to save the le to a location on your local hard drive. You can
save it to your Desktop or some other le folder. Remember this location so you can nd it
later!
6. Once the le is saved, use your Windows Explorer to nd and run the program by
double-clicking in it. Depending on your version of Windows and security settings you
may get a security popup as shown below. Click on Run to continue.
7. This next screen lists all of the possible JDK options that can be installed. Since we
will be covering the basics of Java in this course, you can just accept the defaults and
simply click on the Next button to continue. There is no need to make any changes on
this screen.
8. The next screen will display a simple progress bar while the JDK les are being in-
stalled. This process could take anywhere from seconds to minutes, depending on the
speed of your computer.
9. When the JDK is nished installing, the installation program will install the JRE les.
The screen above will allow you to choose the directory where the JRE will be located.
We recommend that you allow the les to install in the default directory, as shown below.
10. Once you choose the Next button, the installation will display another progress bar.
This will show the progress of the installation of the JRE les.
11. The next screen will simply show the progress of your JRE installation. In this rst
step, the installation program will automatically download additional les from the Oracle
Here you go friends now Android Studio will successfully installed on your windows pc.
Deep learning is a new part of machine learning research. In this paper, we extracted
a total of 192 features from both static and dynamic analyses of Android apps and char-
acterized malware using a DBN-based deep learning model. We designed DroidDetector
and evaluated it with 20000 benign apps crawled from the Google Play Store and 1760
malwares collected from the well-known Contagio Community and Genome Project. The
results show that using DroidDetector with a deep learning model can achieve a supe-
rior accuracy under different conditions, significantly outperforming traditional machine
learning techniques. At present, DroidDetector has been deployed online for user testing.
Moreover, we delved deeper into the features that deep learning exploits to characterize
Android malware using association rule mining techniques. The evaluation of ten popular
anti-virus softwares indicates that it is a matter of urgency to make changes in Android
malware detection.
Much more work is necessary. First, more ne-grained features should be extracted
to characterize Android apps. A more comprehensive and ne-grained set of features can
cover more aspects of Android malware and thus lead to a better characterization and
detection of malware. In addition to the 192 total features in this paper, we may also
add the semantic based features introduced in and types of features presented in to the
feature set. In addition, richer discrete features rather than binary features can be used
in establishing the deep learning model. For example, if one sensitive API function is
called twice or one dynamic behavior occurs twice, we can set their corresponding feature
values as 2 (i.e., discrete values) instead of 1 (i.e., binary values). And second, more app
data (i.e., more types of malicious and benign samples)should be collected for training the
deep learning model. More types of training samples could lead to a better optimization
of the deep learning model, and thereby achieve a superior accuracy in real world Android
malware detection.
REFERENCES
[1] Y. Zhou, Q. Zhang, S. Zou, and X. Jiang. Riskranker: scalable and accurate zero-day
android malware detection. In Proc. of the 10th MobiSys, 2012.
[2] A. Reina, A. Fattori, and L. Cavallaro. A system call-centric analysis and stimula-
tion technique to automatically reconstruct android malware behaviors. In Proc. of
European Workshop on System Security (EUROSEC),April 2013.
[3] R. Pandita, X. Xiao, W. Yang, W. Enck, and T. Xie, Whyper: Towards automating
risk assessment of mobile applications, in Proceedings of the 22nd USENIX Security
Symposium (USENIX Security), 2013, pp. 527542.
[4] Z. Fang, W. Han, and Y. Li, Permission based Android security: Issues and coun-
termeasures, Computers Security, vol. 43, pp. 205218, 2014.
[5] Wen Liu. Mutiple classifier system based android malware detection. In Machine
Learning and Cybernetics (ICMLC), 2013 International Conference on, volume 01,
pages 57-62, July 2013. doi: 10.1109/ICMLC.2013.6890444.
[6] Mark A. Davenport, Richard G. Baraniuk, and Clayton D. Scott. Tuning support
vector machines for minimax and neyman-pearson classification. IEEE Transactions
on Pattern Analysis and Machine Intelligence, 32(10), 2010.
[7] Su, X., Chuah, M., Tan, G.”Smartphone dual defense protection framework: De-
tecting malicious applications in android markets” in: Mobile Ad-hoc and Sensor
Networks (MSN), 2012 Eighth International Conference on, pp. 153-160 (2012).
[8] L. Xie, X. Zhang, J.-P. Seifert, and S. Zhu. pBMDS: A Behavior-based Malware
Detection System for Cellphone Devices. In Proceedings of the 3rd ACM conference
on Wireless Network Security, WiSec ’10, 2010.
[9] S. Zhao, X. Li, G. Xu, L. Zhang, and Z. Feng, ”Attack tree based android malware
detection with hybrid analysis,” in Proceedings of the IEEE 13th International Con-
ference on Trust, Security and Privacy in Computing and Communications (Trust-
Com), 2014.
[10] A. Mylonas, A. Kastania, and D. Gritzalis, Delegate the smartphone user? Security
awareness in smartphone platforms, Computers Security, vol. 34, pp. 47-66, 2013.
[12] Y. Zhou and X. Jiang, Dissecting Android malware: Characterization and evolution,
in Proceedings of the 33rd IEEE Symposium on Security and Privacy (Oakland),
2012, pp. 95109.
[13] Y. Bengio, Learning deep architectures for ai, Foundations and Trends in Machine
Learning, vol. 2, no. 1, pp. 1127, 2009.
2) How your application and your project are used in real life?
Answer:
• Provide security in android application.
• Protect Android devices.
In the dynamic phase, install and run each app in DroidBox is an Android applica-
tion sandbox that extends TaintDroid , which can execute a dynamic taint analysis with
system hooking at the application framework level and monitor a variety of app actions
such as information leaks, network and file input/output, cryptography operations, Short
Message Services and mobile phone calls. In this study, we ran the apps inside Droid-
Box for a period of time to obtain the executed app actions of each app. For instance,
action sendnet is the action that sends data over the network, action phone calls is the
action that makes a phone call, and action sendsms is the action that sends SMS messages.
Google provides Android Studio for the Windows, Mac OS X, and Linux platforms.
You can download this software from the Android Studio homepage. (Youll also nd the
traditional SDKs, with Android Studios command-line tools, available from the Down-
loads page.)
1. Goto https://developer.android.com/studio/index.html
2. Click on DOWNLOAD ANDROID STUDIO FOR WINDOWS green color button.
3. Now check on I have read and agree with above terms and conditions . Then click on
DOWNLOAD ANDROID STUDIO FOR WINDOWS Sky blue color button.
4. Now your download will begun. Your downloaded le will be approximately 1.09 GB
in size because its contain both Android Studio and Android SDK in it with the latest
version of android Marshmallow 6.0 .
5. Double click on le or Run as administrator. Wait for 1-2 minutes for verifying installer
loading.
6. Press Yes on User account control pop up box.
7. Now you will be able to see Android studio setup welcome wizard.
8. Check on Android Studio, Android SDK, Android virtual device then click on Next
button.
9. Click on I Agree button.
10. Now set conguration settings ( Set android studio + android sdk folder path here.You
can set custom folder and path here. )
11. Click on Install button.
12. After all the procedure android studio with android sdk manger will begun to install.
Here you go friends now Android Studio will successfully installed on your windows pc.