# RoughDroid: Operative Scheme for Functional Android Malware Detection

Authors: Khaled Riad; Lishan Ke
Journal: Security and Communication Networks
 (2018)

---

## Abstract

There are thousands of malicious applications that invade Google Play Store every day and seem to be legal applications. These malicious applications have the ability to link the malware referred to as Dresscode created for network hacking as well as scrolling information. Since Android smartphones are indispensable, there should be an efficient and also unusual protection. Therefore, Android smartphones usually continue to be safeguarded from novel malware. In this paper, we proposeRoughDroid, a floppy analysis technique that can discover Android malware applications directly on the smartphone.RoughDroid is based on seven feature sets (FS1,FS2,…,FS7) from the XMLmanifest file of an Android application, plus three feature sets (FS8,FS9, and FS10) from the Dex file. Those feature sets pass through the Rough Set algorithm to elastically classify the Android application as either benign or malicious. The experimental results mainly consider 20 most common malware families, plus three new malware families (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) that invade Google Play Store at 2017. According to the experimental results,RoughDroid has 95.6% detection performance for the malware families at 1% false-positive rate. Finally,RoughDroid is a lightweight approach for straightly examining downloaded applications on the smartphone.


---

## Body

## 1. Introduction

The world’s most preferred mobile operating system currently is Android OS. Android surpasses Windows as the globe’s most preferred OS, yet some Android applications have been discovered to privately swipe individual details from various other applications. Recently, the GadGet Hacks website stated that, after evaluating 110,150 Android applications over a duration of 3 years, the scientists located countless sets of applications that can possibly leakage delicate phone or individual information as well as permitting unapproved applications to hack the blessed information. With numerous thousands of applications in various markets, Android OS offers riches of capability to its customers. Smart devices running Android are progressively targeted by assaulters as well as contaminated with destructive software programs [1].Google took down over 700,000 bad Android applications in 2017, that is, 70% more than in 2016 [2]. In addition to the existing malware families, three new Android malware families (Grabos,TrojanDropper.Agent.BKY, andAsiaHitGroup) invade Google Play Store at 2017 [3]. It appears that there is an urgent requirement for quitting the expansion of malware on Android markets and also smartphones. The Android platforms constantly attempt as well to supply numerous security solutions that stop the installment of malware applications, most significantly the Android authorization system. To carry out particular tasks on the Android device, such as capturing a picture, the application needs to clearly ask for consent from the individual throughout the setup procedure. Some customers thoughtlessly approve the installment agreement to unidentified applications without thoroughly reviewing it.As a result, malicious software is hardly constricted from the Android permission program in training. Opening your Android phone or tablet as much as for applications and video games outside Google’s protective walled yard likewise makes your device considerably a lot more at risk to malware. It is the cost you spend for a totally free software programs [4]. There should be a method that is able to restrict these malicious applications.


### 1.1. Motivation

To the very best of our understanding, a huge body of research study has actually examined approaches for evaluating and also discovering Android malware applications before their setup. These approaches could be approximately classified right into techniques making use of dynamic as well as static evaluation. There are some techniques that could keep track of the habits of applications at run-time, such as TaintDroid [5], DroidRanger [6], and DroidScope [7] which are techniques that could check the actions of applications at run-time. Although run-time monitoring is really reliable in determining harmful task, it experiences a substantial cost and could not be straight used for mobile devices. On the other hand, static evaluation techniques, such as Stowaway [8] and RiskRanker [9], typically generate just a tiny run-time overhead. While these methods are scalable and also reliable, they mostly improve the handcrafted discovery patterns, which are commonly not readily available for new malware circumstances. This is behind our motivation to propose a new Android malware detection scheme that makes it possible to recognize malware straight on the smartphone throughout the setup process based on Rough Set algorithm.


### 1.2. Main Contributions

In this paper, we introducedRoughDroid that is a new broad floppy analysis malware detector on smart Android phones during the installation time by introducing robust feature extraction framework. The main contributions could be summed up as follows:(i)
Effective Detection: We introduce a novel scheme (RoughDroid) for combining floppy analysis and machine learning that is capable of identifying Android malware with high accuracy and few false alarms. Also, it is independent of manually crafted detection patterns.(ii)
Various Features:RoughDroid groups numerous features from themanifest file as well asapplication’s Dex code. Those features are categorized into ten feature sets (FS1,FS2,…,FS10).(iii)
Rough-Based Detection: The proposed scheme considers theadware Android applications during the detection of malware applications. This is due to executing the detection process elastically usingRough Set algorithm that introduces flexible (not straight line) classification into benign and malware applications.(iv)
Lightweight Analysis: For efficiency, we apply linear time analysis and learning techniques that enable detecting malware on the smartphone as well as analyzing large sets of applications in a reasonable time.Finally, the experiments with 131,611 applications and 5,560 malware samples, in addition to 158 malware applications introducing three new malware families at 2017, demonstrate the efficacy of our method for directly checking downloaded applications on the smartphone.


### 1.3. Organization

The rest of this paper is organized as follows: Section2 introduces ourRoughDroid scheme with its ten feature sets and Rough Set detection algorithm. Section 3 presents the experimental evaluation ofRoughDroid by comparing it with some popular detection schemes and ten of the most common antiviruses. Section 4 introduces the related work and smooth comparison between the currently proposed Android malware detection schemes andRoughDroid. This is followed by the conclusion in Section 5.


## 1.1. Motivation

To the very best of our understanding, a huge body of research study has actually examined approaches for evaluating and also discovering Android malware applications before their setup. These approaches could be approximately classified right into techniques making use of dynamic as well as static evaluation. There are some techniques that could keep track of the habits of applications at run-time, such as TaintDroid [5], DroidRanger [6], and DroidScope [7] which are techniques that could check the actions of applications at run-time. Although run-time monitoring is really reliable in determining harmful task, it experiences a substantial cost and could not be straight used for mobile devices. On the other hand, static evaluation techniques, such as Stowaway [8] and RiskRanker [9], typically generate just a tiny run-time overhead. While these methods are scalable and also reliable, they mostly improve the handcrafted discovery patterns, which are commonly not readily available for new malware circumstances. This is behind our motivation to propose a new Android malware detection scheme that makes it possible to recognize malware straight on the smartphone throughout the setup process based on Rough Set algorithm.


## 1.2. Main Contributions

In this paper, we introducedRoughDroid that is a new broad floppy analysis malware detector on smart Android phones during the installation time by introducing robust feature extraction framework. The main contributions could be summed up as follows:(i)
Effective Detection: We introduce a novel scheme (RoughDroid) for combining floppy analysis and machine learning that is capable of identifying Android malware with high accuracy and few false alarms. Also, it is independent of manually crafted detection patterns.(ii)
Various Features:RoughDroid groups numerous features from themanifest file as well asapplication’s Dex code. Those features are categorized into ten feature sets (FS1,FS2,…,FS10).(iii)
Rough-Based Detection: The proposed scheme considers theadware Android applications during the detection of malware applications. This is due to executing the detection process elastically usingRough Set algorithm that introduces flexible (not straight line) classification into benign and malware applications.(iv)
Lightweight Analysis: For efficiency, we apply linear time analysis and learning techniques that enable detecting malware on the smartphone as well as analyzing large sets of applications in a reasonable time.Finally, the experiments with 131,611 applications and 5,560 malware samples, in addition to 158 malware applications introducing three new malware families at 2017, demonstrate the efficacy of our method for directly checking downloaded applications on the smartphone.


## 1.3. Organization

The rest of this paper is organized as follows: Section2 introduces ourRoughDroid scheme with its ten feature sets and Rough Set detection algorithm. Section 3 presents the experimental evaluation ofRoughDroid by comparing it with some popular detection schemes and ten of the most common antiviruses. Section 4 introduces the related work and smooth comparison between the currently proposed Android malware detection schemes andRoughDroid. This is followed by the conclusion in Section 5.


## 2. RoughDroid

In this paper, we presentRoughDroid, a lightweight technique for discovering Android malware that presumes discovery patterns immediately. In addition, it allows recognizing malware straight on the smartphone.RoughDroid performs a broad floppy analysis, gathering as numerous features from anapplication’s code as well asmanifest as feasible. These features are organized in groups of strings (for instance, features API calls along with network speeches) and embedded within a combined vector space. As an example, an application sending out premium SMS messages is cast to a particular area in the vector room connected with the equivalent consent, intents, and also API calls. This geometric depiction allowsRoughDroid to recognize mixes as well as patterns of features indicative for malware automatically, by utilizing machine learning techniques.To this end, our technique utilizes a broad floppy analysis that extracts feature sets from various resources and examines these features in a meaningful vector space. This procedure is shown in Figure1 and also described as follows:(I)
Floppy Analysis:RoughDroid floppily inspects a given Android application and various feature collections from the application’smanifest and also disassembledDex code.RoughDroid inspects the application’smanifest and disassembledDex code of a given Android Application inParallel Sweep to reduce the time of analysis.(II)
Constructing Vector Space: The extracted feature sets are after that mapped to a joint vector space, where patterns and also mixes of the features could be evaluated geometrically.(III)
Rough-Based Detection: The embedding of the feature sets allows us to recognize malware utilizing effective strategies of machine learning (Rough Set algorithm).Figure 1
General overview for the proposedRoughDroid system model.


### 2.1. Floppy Analysis

As the primary step,RoughDroid carries out a lightweight floppy analysis of an offered Android application. The floppy extraction of features should run in a constricted environment and in full prompt way. The customer might avoid the recurring procedure, if the evaluation takes so long time. Appropriately, it becomes vital to pick features that can be extracted effectively. We therefore focus on themanifest in addition to the disassembledDex code of this application, which could be obtained with a parallel sweep within the application’s content. To enable an extensible as well as common evaluation, we represent all extracted features as sets of strings, such as authorizations, intents, and also API calls. Specifically, we extract the adhering ten sets of features.


#### 2.1.1. Manifest Feature Sets

It is an effective file in the Android system that defines the performance and also demands of an application to Android.AndroidManifest.xml could be located at the root of the project and has numerous various feature sets.A simple XMLmanifest file generated for an Android application tested underRoughDroid is shown in Figure 2. The presented XML file declares seven different features sets (FS1,FS2,FS3,FS4,FS5,FS6, and FS7) as follows:FS1
:Hardware Components: It has the requested hardware features by an application. The figure indicates three requested hardware features (microphone,telephony,and location.gps). An application that has access to GPS and network modules is, for instance, able to collect fine location information and send it to an attacker over the network.FS2
:Software Components: It indicates that the application utilizes or requires software features. The figure declaressip.voip that allows the application to use Session Initiation Protocol (SIP) services and do VOIP calls.FS3
:Requested Permissions: It is very important for Android security mechanisms. The figure mentions three dangerous permissions (RECORD_AUDIO,SEND_SMS, andACCESS_FINE_LOCATION) that are granted to the application during the application’s setup time by the user.FS4
:App Components: It is a set of Boolean expressions that grant some services to the application, such asallowBackup anddirectBootAware.FS5
:App Activities: It allows the application to execute a specific activity, such asdirectBootAware andhardwareAccelerated.FS6
:Intent Filters: It specifies the types of intents that an activity, service, or broadcast receiver can respond to, such asaction.MAIN andaction.EDIT.FS7
:App Services: It represents a service as one of the application’s components, such asdirectBootAware andexported.Figure 2
A simple XMLmanifest example (AndroidManifest.xml) that declares seven feature sets for an Android application.The information saved inAndroidManifest.xml file could be effectively obtained on the device by making use of theAndroid Asset Packaging Tool that allows us to extract out the previously mentioned sets of features.


#### 2.1.2. Disassembled Code Feature Sets

We implement a lightweight disassembler, which takes as input the Dalvik Executable (Dex) and providesRoughDroid with the complete information about API calls and the data utilized in the application. TheDex file contains a set of class definitions and their associated adjunct data. Table 1 introduces a simple example for theDex file that is enhanced bytecode for the Dalvik virtual machine. Every Android application has a uniqueclasses.dex file, which references any type of approaches or courses utilized within an application. Basically, any type of task, things, or piece utilized within the codebase will certainly be changed right into bytes within aDex file that could be run as an Android application.Table 1
A simple Dex file has code which is eventually performed by the Android Runtime.
(a) No. Dex File Magic Checksum SHA1-Hash Signature File Size Header Size 1 6465780A 30333800 7A44CBBB FB4AE841 0286C06A 8DF19000 3C5DE024 D07326A2 E0010000 70000000  2 00000000 02000000 9C000000 01000000 AC000000 14010000 CC000000 E4000000 EC000000 07010000  3 00000000 01000000 01000000 00000000 00000000 FFFFFFFF 00000000 57010000 00000000 01000100  4 706C6963 6174696F 6E3B0023 4C636F6D 2F627567 736E6167 2F646578 6578616D 706C652F 42756773  (b) No. Endian Constant Link Size & Offset Map Section String ID Type ID Photo ID Field ID Method ID Class Def Data Size 1 78563412 00000000 00000000 64010000 05000000 70000000 03000000 84000000 01000000 90000000  2 2C010000 2F010000 01000000 02000000 03000000 03000000 02000000 00000000 00000000 00000000  3 01000000 00000000 04000000 70100000 00000E00 063C696E 69743E00 194C616E 64726F69 642F6170  4 6E616741 70703B00 01560026 7E7E4438 7B226D69 6E2D6170 69223A32 362C2276 65727369 6F6E223AWe are mainly interested in the API calls and method calls, because they can be easily extracted from theDex file of an application, as follows:FS8
:Access to Undocumented/Hidden APIs: Applications could be limited from accessing APIs that are undocumented in the Android Software Development Kit (SDK).RoughDroid looks for the incident of these demands in theDex file, in order to get a further understanding of the behavior of an application.FS9
:Suspicious APIs: Requesting some delicate information or sources of the Android phone might result in destructive behavior. We are laying more importance to a set of such suspicious APIs:
(i)
Sensitive data (IMEI andUSIMnumbeleakage) APIs, where the Android requests are such asgetDeviceId(), getSimSerialNumber(), andgetImei();(ii)
Network communication APIs, such assetWifiEnabled() andexecHttpRequest();(iii)
Location leakage APIs, such asgetLastKnownLocation(), getLatitude(), getLongitude(), andrequestLocationUpdates();(iv)
Sending and receiving SMS/MMS messages APIs, such assendTextMessage(), SendBroadcast(), andsendDataMessage().FS10
:Restricted API calls: The Android authorization system limits accessibility to a collection of crucial API calls. Our approach looks for the event of these calls that represent a apart of theDex code, in order to get a much deeper understanding of an App’s capability. (1)VApp=FS1FS2FS3FS4FS5FS6FS7FS8FS9FS10=android.hardware.microphoneandroid.hardware.telephony⋮android.hardware.location.gpsandroid.software.sip.voip⋮android.software.backupandroid.permission.RECORD_AUDIOandroid.permission.SEND_SMS⋮android.permission.ACCESS_FINE_LOCATIONandroid:allowBackup⋮android:directBootAwareandroid:directBootAware⋮android:hardwareAcceleratedandroid.intent.action.MAINandroid.intent.action.EDIT⋮android.intent.category.LAUNCHERandroid:directBootAware⋮android:exportedAccesstoundocumented/hiddenAPIs⋮getDeviceIdgetSimSerialNumber⋮getImeiRestrictedAPIcalls⋮=10⋮11⋮101⋮10⋮01⋮100⋮11⋮01⋮01⋮01⋮


### 2.2. Vector Space Construction

A harmful task is normally shown in particular patterns as well as mixes of the extracted features. As an example, a malware application sending the fine location of a smartphone might have the permissionandroid.permission.ACCESS_FINE_LOCATION in FS3 and the hardware featureandroid.hardware.location.gps in FS1. Preferably, we would like to create Boolean expressions that catch this reliance in between features as well as returning true if a malware is found.We will need to place the extracted feature collections from an Android application (FS1,FS2,…,FS10) in a vector. In our experiments the vector space (V(App)) contains approximately 550,000 different extracted features. If the application (App) contains the feature (f), the vector space element for that feature is mapped to 1 (V(App,f)=1); otherwise, it is mapped to 0 (V(App,f)=0). A simple structure as an example of the vector space is shown in (1). Regardless of the measurement of the vector space, it is hence enough to just save the extracted features from an application for sparsely standing for the vector V(App) by using either hash tables [10] or Bloom filters [11].


### 2.3. Rough-Based Detection

Rough Set based data analysis [12–14] starts after constructing the vector space (feature table), as depicted in Section 2.2. Each row represents a specific feature obtained from a certain feature set according to a specific Android application in our scheme. The Rough system has multiple entities and stages.(i)
Feature Table: It is a pair FS=(Apps,F) where Apps is a nonempty finite set of Android applications called the universe and F is a nonempty finite set of features such that f:Apps→Vf for every f∈F. The set Vf is called the value set of f, and elements of Apps are called Android applications.(ii)
Decisions: It is the feature table in the form FS=(Apps,F∪{appf}), where Appf (not a feature in F) is the decision feature. The features of F are called conditional features or simply conditions.(iii)
Approximations: Let AppX⊆Apps:
(a)
Lower Approximation: It consists of all Android applications, which definitely belong to R_(AppX)={App∈Apps∣[App]R⊆AppX}.(b)
Upper Approximation: It contains all Android applications, which possibly belong to R¯(AppX)={App∈Apps∣[App]R∩AppX≠ϕ}.(c)
Boundary Region: The difference between the upper and lower approximations constitutes the boundary region of the Rough Set algorithm. Boundary positive and negative regions [15] are described as below. (2)BNDRAppX=R¯AppXX-R_AppXPOSRAppX=R_AppXNEGRAppX=U-R¯AppXAn Android application of the negative region NEGR(AppX) does not belong to AppX, an application of the positive region POSR(AppX) belongs to AppX, and only one application of the boundary region BNDR(AppX) belongs to AppX. Those approximation sets and regions are shown in Figure 3.(d)
Approximation Accuracy: The roughness precision of any subset AppX⊆Apps with regard to R⊆F, represented as αR(AppX), is quantified by αR(AppX)=|R_(AppX)/R¯(AppX)|, where |AppX| represents cardinality of AppX. For an empty set ϕ, we define αR(ϕ)=1. It is worth noting that 0≤αR(AppX)≤1. If αR(AppX)=1, the set AppX is crisp with respect to R. If αR(AppX)<1, AppX is tough with reference to R.Figure 3
The approximations and regions of an Android applications’ setAppX using Rough Set algorithm.


## 2.1. Floppy Analysis

As the primary step,RoughDroid carries out a lightweight floppy analysis of an offered Android application. The floppy extraction of features should run in a constricted environment and in full prompt way. The customer might avoid the recurring procedure, if the evaluation takes so long time. Appropriately, it becomes vital to pick features that can be extracted effectively. We therefore focus on themanifest in addition to the disassembledDex code of this application, which could be obtained with a parallel sweep within the application’s content. To enable an extensible as well as common evaluation, we represent all extracted features as sets of strings, such as authorizations, intents, and also API calls. Specifically, we extract the adhering ten sets of features.


### 2.1.1. Manifest Feature Sets

It is an effective file in the Android system that defines the performance and also demands of an application to Android.AndroidManifest.xml could be located at the root of the project and has numerous various feature sets.A simple XMLmanifest file generated for an Android application tested underRoughDroid is shown in Figure 2. The presented XML file declares seven different features sets (FS1,FS2,FS3,FS4,FS5,FS6, and FS7) as follows:FS1
:Hardware Components: It has the requested hardware features by an application. The figure indicates three requested hardware features (microphone,telephony,and location.gps). An application that has access to GPS and network modules is, for instance, able to collect fine location information and send it to an attacker over the network.FS2
:Software Components: It indicates that the application utilizes or requires software features. The figure declaressip.voip that allows the application to use Session Initiation Protocol (SIP) services and do VOIP calls.FS3
:Requested Permissions: It is very important for Android security mechanisms. The figure mentions three dangerous permissions (RECORD_AUDIO,SEND_SMS, andACCESS_FINE_LOCATION) that are granted to the application during the application’s setup time by the user.FS4
:App Components: It is a set of Boolean expressions that grant some services to the application, such asallowBackup anddirectBootAware.FS5
:App Activities: It allows the application to execute a specific activity, such asdirectBootAware andhardwareAccelerated.FS6
:Intent Filters: It specifies the types of intents that an activity, service, or broadcast receiver can respond to, such asaction.MAIN andaction.EDIT.FS7
:App Services: It represents a service as one of the application’s components, such asdirectBootAware andexported.Figure 2
A simple XMLmanifest example (AndroidManifest.xml) that declares seven feature sets for an Android application.The information saved inAndroidManifest.xml file could be effectively obtained on the device by making use of theAndroid Asset Packaging Tool that allows us to extract out the previously mentioned sets of features.


### 2.1.2. Disassembled Code Feature Sets

We implement a lightweight disassembler, which takes as input the Dalvik Executable (Dex) and providesRoughDroid with the complete information about API calls and the data utilized in the application. TheDex file contains a set of class definitions and their associated adjunct data. Table 1 introduces a simple example for theDex file that is enhanced bytecode for the Dalvik virtual machine. Every Android application has a uniqueclasses.dex file, which references any type of approaches or courses utilized within an application. Basically, any type of task, things, or piece utilized within the codebase will certainly be changed right into bytes within aDex file that could be run as an Android application.Table 1
A simple Dex file has code which is eventually performed by the Android Runtime.
(a) No. Dex File Magic Checksum SHA1-Hash Signature File Size Header Size 1 6465780A 30333800 7A44CBBB FB4AE841 0286C06A 8DF19000 3C5DE024 D07326A2 E0010000 70000000  2 00000000 02000000 9C000000 01000000 AC000000 14010000 CC000000 E4000000 EC000000 07010000  3 00000000 01000000 01000000 00000000 00000000 FFFFFFFF 00000000 57010000 00000000 01000100  4 706C6963 6174696F 6E3B0023 4C636F6D 2F627567 736E6167 2F646578 6578616D 706C652F 42756773  (b) No. Endian Constant Link Size & Offset Map Section String ID Type ID Photo ID Field ID Method ID Class Def Data Size 1 78563412 00000000 00000000 64010000 05000000 70000000 03000000 84000000 01000000 90000000  2 2C010000 2F010000 01000000 02000000 03000000 03000000 02000000 00000000 00000000 00000000  3 01000000 00000000 04000000 70100000 00000E00 063C696E 69743E00 194C616E 64726F69 642F6170  4 6E616741 70703B00 01560026 7E7E4438 7B226D69 6E2D6170 69223A32 362C2276 65727369 6F6E223AWe are mainly interested in the API calls and method calls, because they can be easily extracted from theDex file of an application, as follows:FS8
:Access to Undocumented/Hidden APIs: Applications could be limited from accessing APIs that are undocumented in the Android Software Development Kit (SDK).RoughDroid looks for the incident of these demands in theDex file, in order to get a further understanding of the behavior of an application.FS9
:Suspicious APIs: Requesting some delicate information or sources of the Android phone might result in destructive behavior. We are laying more importance to a set of such suspicious APIs:
(i)
Sensitive data (IMEI andUSIMnumbeleakage) APIs, where the Android requests are such asgetDeviceId(), getSimSerialNumber(), andgetImei();(ii)
Network communication APIs, such assetWifiEnabled() andexecHttpRequest();(iii)
Location leakage APIs, such asgetLastKnownLocation(), getLatitude(), getLongitude(), andrequestLocationUpdates();(iv)
Sending and receiving SMS/MMS messages APIs, such assendTextMessage(), SendBroadcast(), andsendDataMessage().FS10
:Restricted API calls: The Android authorization system limits accessibility to a collection of crucial API calls. Our approach looks for the event of these calls that represent a apart of theDex code, in order to get a much deeper understanding of an App’s capability. (1)VApp=FS1FS2FS3FS4FS5FS6FS7FS8FS9FS10=android.hardware.microphoneandroid.hardware.telephony⋮android.hardware.location.gpsandroid.software.sip.voip⋮android.software.backupandroid.permission.RECORD_AUDIOandroid.permission.SEND_SMS⋮android.permission.ACCESS_FINE_LOCATIONandroid:allowBackup⋮android:directBootAwareandroid:directBootAware⋮android:hardwareAcceleratedandroid.intent.action.MAINandroid.intent.action.EDIT⋮android.intent.category.LAUNCHERandroid:directBootAware⋮android:exportedAccesstoundocumented/hiddenAPIs⋮getDeviceIdgetSimSerialNumber⋮getImeiRestrictedAPIcalls⋮=10⋮11⋮101⋮10⋮01⋮100⋮11⋮01⋮01⋮01⋮


## 2.1.1. Manifest Feature Sets

It is an effective file in the Android system that defines the performance and also demands of an application to Android.AndroidManifest.xml could be located at the root of the project and has numerous various feature sets.A simple XMLmanifest file generated for an Android application tested underRoughDroid is shown in Figure 2. The presented XML file declares seven different features sets (FS1,FS2,FS3,FS4,FS5,FS6, and FS7) as follows:FS1
:Hardware Components: It has the requested hardware features by an application. The figure indicates three requested hardware features (microphone,telephony,and location.gps). An application that has access to GPS and network modules is, for instance, able to collect fine location information and send it to an attacker over the network.FS2
:Software Components: It indicates that the application utilizes or requires software features. The figure declaressip.voip that allows the application to use Session Initiation Protocol (SIP) services and do VOIP calls.FS3
:Requested Permissions: It is very important for Android security mechanisms. The figure mentions three dangerous permissions (RECORD_AUDIO,SEND_SMS, andACCESS_FINE_LOCATION) that are granted to the application during the application’s setup time by the user.FS4
:App Components: It is a set of Boolean expressions that grant some services to the application, such asallowBackup anddirectBootAware.FS5
:App Activities: It allows the application to execute a specific activity, such asdirectBootAware andhardwareAccelerated.FS6
:Intent Filters: It specifies the types of intents that an activity, service, or broadcast receiver can respond to, such asaction.MAIN andaction.EDIT.FS7
:App Services: It represents a service as one of the application’s components, such asdirectBootAware andexported.Figure 2
A simple XMLmanifest example (AndroidManifest.xml) that declares seven feature sets for an Android application.The information saved inAndroidManifest.xml file could be effectively obtained on the device by making use of theAndroid Asset Packaging Tool that allows us to extract out the previously mentioned sets of features.


## 2.1.2. Disassembled Code Feature Sets

We implement a lightweight disassembler, which takes as input the Dalvik Executable (Dex) and providesRoughDroid with the complete information about API calls and the data utilized in the application. TheDex file contains a set of class definitions and their associated adjunct data. Table 1 introduces a simple example for theDex file that is enhanced bytecode for the Dalvik virtual machine. Every Android application has a uniqueclasses.dex file, which references any type of approaches or courses utilized within an application. Basically, any type of task, things, or piece utilized within the codebase will certainly be changed right into bytes within aDex file that could be run as an Android application.Table 1
A simple Dex file has code which is eventually performed by the Android Runtime.
(a) No. Dex File Magic Checksum SHA1-Hash Signature File Size Header Size 1 6465780A 30333800 7A44CBBB FB4AE841 0286C06A 8DF19000 3C5DE024 D07326A2 E0010000 70000000  2 00000000 02000000 9C000000 01000000 AC000000 14010000 CC000000 E4000000 EC000000 07010000  3 00000000 01000000 01000000 00000000 00000000 FFFFFFFF 00000000 57010000 00000000 01000100  4 706C6963 6174696F 6E3B0023 4C636F6D 2F627567 736E6167 2F646578 6578616D 706C652F 42756773  (b) No. Endian Constant Link Size & Offset Map Section String ID Type ID Photo ID Field ID Method ID Class Def Data Size 1 78563412 00000000 00000000 64010000 05000000 70000000 03000000 84000000 01000000 90000000  2 2C010000 2F010000 01000000 02000000 03000000 03000000 02000000 00000000 00000000 00000000  3 01000000 00000000 04000000 70100000 00000E00 063C696E 69743E00 194C616E 64726F69 642F6170  4 6E616741 70703B00 01560026 7E7E4438 7B226D69 6E2D6170 69223A32 362C2276 65727369 6F6E223AWe are mainly interested in the API calls and method calls, because they can be easily extracted from theDex file of an application, as follows:FS8
:Access to Undocumented/Hidden APIs: Applications could be limited from accessing APIs that are undocumented in the Android Software Development Kit (SDK).RoughDroid looks for the incident of these demands in theDex file, in order to get a further understanding of the behavior of an application.FS9
:Suspicious APIs: Requesting some delicate information or sources of the Android phone might result in destructive behavior. We are laying more importance to a set of such suspicious APIs:
(i)
Sensitive data (IMEI andUSIMnumbeleakage) APIs, where the Android requests are such asgetDeviceId(), getSimSerialNumber(), andgetImei();(ii)
Network communication APIs, such assetWifiEnabled() andexecHttpRequest();(iii)
Location leakage APIs, such asgetLastKnownLocation(), getLatitude(), getLongitude(), andrequestLocationUpdates();(iv)
Sending and receiving SMS/MMS messages APIs, such assendTextMessage(), SendBroadcast(), andsendDataMessage().FS10
:Restricted API calls: The Android authorization system limits accessibility to a collection of crucial API calls. Our approach looks for the event of these calls that represent a apart of theDex code, in order to get a much deeper understanding of an App’s capability. (1)VApp=FS1FS2FS3FS4FS5FS6FS7FS8FS9FS10=android.hardware.microphoneandroid.hardware.telephony⋮android.hardware.location.gpsandroid.software.sip.voip⋮android.software.backupandroid.permission.RECORD_AUDIOandroid.permission.SEND_SMS⋮android.permission.ACCESS_FINE_LOCATIONandroid:allowBackup⋮android:directBootAwareandroid:directBootAware⋮android:hardwareAcceleratedandroid.intent.action.MAINandroid.intent.action.EDIT⋮android.intent.category.LAUNCHERandroid:directBootAware⋮android:exportedAccesstoundocumented/hiddenAPIs⋮getDeviceIdgetSimSerialNumber⋮getImeiRestrictedAPIcalls⋮=10⋮11⋮101⋮10⋮01⋮100⋮11⋮01⋮01⋮01⋮


## 2.2. Vector Space Construction

A harmful task is normally shown in particular patterns as well as mixes of the extracted features. As an example, a malware application sending the fine location of a smartphone might have the permissionandroid.permission.ACCESS_FINE_LOCATION in FS3 and the hardware featureandroid.hardware.location.gps in FS1. Preferably, we would like to create Boolean expressions that catch this reliance in between features as well as returning true if a malware is found.We will need to place the extracted feature collections from an Android application (FS1,FS2,…,FS10) in a vector. In our experiments the vector space (V(App)) contains approximately 550,000 different extracted features. If the application (App) contains the feature (f), the vector space element for that feature is mapped to 1 (V(App,f)=1); otherwise, it is mapped to 0 (V(App,f)=0). A simple structure as an example of the vector space is shown in (1). Regardless of the measurement of the vector space, it is hence enough to just save the extracted features from an application for sparsely standing for the vector V(App) by using either hash tables [10] or Bloom filters [11].


## 2.3. Rough-Based Detection

Rough Set based data analysis [12–14] starts after constructing the vector space (feature table), as depicted in Section 2.2. Each row represents a specific feature obtained from a certain feature set according to a specific Android application in our scheme. The Rough system has multiple entities and stages.(i)
Feature Table: It is a pair FS=(Apps,F) where Apps is a nonempty finite set of Android applications called the universe and F is a nonempty finite set of features such that f:Apps→Vf for every f∈F. The set Vf is called the value set of f, and elements of Apps are called Android applications.(ii)
Decisions: It is the feature table in the form FS=(Apps,F∪{appf}), where Appf (not a feature in F) is the decision feature. The features of F are called conditional features or simply conditions.(iii)
Approximations: Let AppX⊆Apps:
(a)
Lower Approximation: It consists of all Android applications, which definitely belong to R_(AppX)={App∈Apps∣[App]R⊆AppX}.(b)
Upper Approximation: It contains all Android applications, which possibly belong to R¯(AppX)={App∈Apps∣[App]R∩AppX≠ϕ}.(c)
Boundary Region: The difference between the upper and lower approximations constitutes the boundary region of the Rough Set algorithm. Boundary positive and negative regions [15] are described as below. (2)BNDRAppX=R¯AppXX-R_AppXPOSRAppX=R_AppXNEGRAppX=U-R¯AppXAn Android application of the negative region NEGR(AppX) does not belong to AppX, an application of the positive region POSR(AppX) belongs to AppX, and only one application of the boundary region BNDR(AppX) belongs to AppX. Those approximation sets and regions are shown in Figure 3.(d)
Approximation Accuracy: The roughness precision of any subset AppX⊆Apps with regard to R⊆F, represented as αR(AppX), is quantified by αR(AppX)=|R_(AppX)/R¯(AppX)|, where |AppX| represents cardinality of AppX. For an empty set ϕ, we define αR(ϕ)=1. It is worth noting that 0≤αR(AppX)≤1. If αR(AppX)=1, the set AppX is crisp with respect to R. If αR(AppX)<1, AppX is tough with reference to R.Figure 3
The approximations and regions of an Android applications’ setAppX using Rough Set algorithm.


## 3. Evaluation

After providingRoughDroid thoroughly, we currently continue to an empirical assessment of its efficiency. In order to do so, we first describe the used dataset and then run some experiments to evaluate the detection performance.


### 3.1. Considered Data Sets

Our experiments are executed based on a dataset of genuine Android applications and also actual malware. We are utilizing Drebin dataset [1], it comprises 131,611 software samples collected from other tools, including Google Play Store, both Chinese and Russian Markets, and also Android sites. Additionally, it Includes 5,560 malware applications, from 179 distinct malware families, for example,FakeInstaller, DroidKungFu, Plankton, Opfake, GingerMaster, BaseBridge, Iconosys, Kmin, FakeDoc, Geinimi, Adrd, DroidDream, Linux/Lotoor, GoldDream, MobileTx, FakeRun, SendPay, Gappusin, Imlog,andSMSreg.In addition, we have also considered 158 Android applications introducing three new malware families (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) that invade Google Play Store at 2017. It should be mentioned that the adware applications are considered in our dataset.


### 3.2. Performance Analysis

OurRoughDroid does not need initial training in advance, which is one of its basic advantages.RoughDroid analyzes each application in a broad floppy way and grab a great collection of features categorized in ten feature sets (FS1,FS2,…,FS10). It should be mentioned that the results are obtained from the average of 25 trials using the same environmental conditions. We introduce our analysis based on comparingRoughDroid’s results with the results obtained from related approaches and ten popular antivirus scanners, finally employingRoughDroid to find the detection rate for the most popular malware families.


#### 3.2.1. RoughDroid and Related Approaches

We initially contrast the efficiency ofRoughDroid versus associated static methods for the discovery of Android malware. Specifically, we think about Drebin [1], RCP [16], Peng et al. [17], and SigPID [18]. The outcomes of these experiments are displayed in Figure 4 as ROC curve.RoughDroid outperforms the four previously mentioned approaches by detecting 95.6% of the malware applications at a false-positive rate (FPR) equal to 1%.Figure 4
RoughDroid performance analysis ROC curve comparison with three approaches.Also, according to the statistical measures introduced in Table2, theAsymptotic Probability of the five schemes is much smaller than 0.05; thus we can conclude that all schemes are effective. In addition, the area under the curve ofRoughDroid is 0.95633, which is closer to 1.0; hence,RoughDroid is the best scheme in successfully detecting the malware of an Android application. The excellent efficiency ofRoughDroid arises from the various feature sets that are used to design the malicious activity of an application.Table 2
Statistical measures forRoughDroid and four other schemes.
Scheme Area Std. Error Asymptotic Prob. 95% LCL 95% UCL RCP [16] 0.52123 0.08965 5.63972E-5 0.43983 0.62718  Peng et al. [17] 0.08182 0.85211 4.941212E-5 0.51643 0.73156  SigPID 0.91364 0.07131 4.72643E-4 0.57846 0.87653  Drebin [1] 0.93521 0.06344 3.66257E-4 0.66972 0.91842  RoughDroid 0.95633 0.04577 2.48984E-6 0.79892 0.97833


#### 3.2.2. RoughDroid and Popular AV Scanners

RoughDroid reveals a much better efficiency compared to related approaches ([1, 16–18]). We likewise contrast it with ten picked antivirus scanners on the considered dataset. It should be mentioned that we consider FPR=1%, which we assume to be adequately low enough for practical scenarios.Experimental results are displayed in Table3. The best antivirus detects over 90% of malware applications. OurRoughDroid also provides best performance with detection rate of 95.6%.Table 3
Detection rates ofRoughDroid in comparison with Drebin, SigPID, and ten anti-virus scanners.
RoughDroid Drebin [1] SigPID [18] Anti-V1 Anti-V2 Anti-V3 Anti-V4 Anti-V5 Anti-V6 Anti-V7 Anti-V8 Anti-V9 Anti-V10 Detection Rate 95.60% 93.90% 91.22% 96.41% 93.71% 84.66% 84.54% 78.38% 64.16% 48.50% 48.34% 9.84% 3.99%


#### 3.2.3. Detecting Malware Families

When evaluating the detection efficiency of an approach, the equilibrium of malware family members in the dataset is very important. If the number of applications of a particular malware family members is little great compared to various other families, the detection result might mostly depend on these families. An unreal solution to this problem is to make use of the same number of applications for each malware family.We are laying more stress on 20 (FakeInstaller, DroidKungFu, Plankton, Opfake, GingerMaster, BaseBridge, Iconosys, Kmin, FakeDoc, Geinimi, Adrd, DroidDream, Linux/Lotoor, GoldDream, MobileTx, FakeRun, SendPay, Gappusin, Imlog, andSMSreg) top common malware families, plus the new three (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) malware families that invade Google Play Store at 2017.We perform three more experiments, by restricting the variety of applications for a certain family in the test set. In the first experiment, we offer no applications of the family. In the second experiment, we place 10 arbitrarily picked applications of the family back right into the test set. Finally, in the third experiment, we use 20 arbitrarily picked applications of the family back right into the test set. The consequences of these three experiments are shown in Figure5.RoughDroid can reliably detect all households with a typical precision of 95.6% at FPR=1%. The figure also shows that five (Kmin, MobileTx, FakeRun, Grabos, andAsiaHitGroup) families are perfectly detected.Figure 5
RoughDroid detection rate for 23 malware families based on three different number of applications for each family.


## 3.1. Considered Data Sets

Our experiments are executed based on a dataset of genuine Android applications and also actual malware. We are utilizing Drebin dataset [1], it comprises 131,611 software samples collected from other tools, including Google Play Store, both Chinese and Russian Markets, and also Android sites. Additionally, it Includes 5,560 malware applications, from 179 distinct malware families, for example,FakeInstaller, DroidKungFu, Plankton, Opfake, GingerMaster, BaseBridge, Iconosys, Kmin, FakeDoc, Geinimi, Adrd, DroidDream, Linux/Lotoor, GoldDream, MobileTx, FakeRun, SendPay, Gappusin, Imlog,andSMSreg.In addition, we have also considered 158 Android applications introducing three new malware families (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) that invade Google Play Store at 2017. It should be mentioned that the adware applications are considered in our dataset.


## 3.2. Performance Analysis

OurRoughDroid does not need initial training in advance, which is one of its basic advantages.RoughDroid analyzes each application in a broad floppy way and grab a great collection of features categorized in ten feature sets (FS1,FS2,…,FS10). It should be mentioned that the results are obtained from the average of 25 trials using the same environmental conditions. We introduce our analysis based on comparingRoughDroid’s results with the results obtained from related approaches and ten popular antivirus scanners, finally employingRoughDroid to find the detection rate for the most popular malware families.


### 3.2.1. RoughDroid and Related Approaches

We initially contrast the efficiency ofRoughDroid versus associated static methods for the discovery of Android malware. Specifically, we think about Drebin [1], RCP [16], Peng et al. [17], and SigPID [18]. The outcomes of these experiments are displayed in Figure 4 as ROC curve.RoughDroid outperforms the four previously mentioned approaches by detecting 95.6% of the malware applications at a false-positive rate (FPR) equal to 1%.Figure 4
RoughDroid performance analysis ROC curve comparison with three approaches.Also, according to the statistical measures introduced in Table2, theAsymptotic Probability of the five schemes is much smaller than 0.05; thus we can conclude that all schemes are effective. In addition, the area under the curve ofRoughDroid is 0.95633, which is closer to 1.0; hence,RoughDroid is the best scheme in successfully detecting the malware of an Android application. The excellent efficiency ofRoughDroid arises from the various feature sets that are used to design the malicious activity of an application.Table 2
Statistical measures forRoughDroid and four other schemes.
Scheme Area Std. Error Asymptotic Prob. 95% LCL 95% UCL RCP [16] 0.52123 0.08965 5.63972E-5 0.43983 0.62718  Peng et al. [17] 0.08182 0.85211 4.941212E-5 0.51643 0.73156  SigPID 0.91364 0.07131 4.72643E-4 0.57846 0.87653  Drebin [1] 0.93521 0.06344 3.66257E-4 0.66972 0.91842  RoughDroid 0.95633 0.04577 2.48984E-6 0.79892 0.97833


### 3.2.2. RoughDroid and Popular AV Scanners

RoughDroid reveals a much better efficiency compared to related approaches ([1, 16–18]). We likewise contrast it with ten picked antivirus scanners on the considered dataset. It should be mentioned that we consider FPR=1%, which we assume to be adequately low enough for practical scenarios.Experimental results are displayed in Table3. The best antivirus detects over 90% of malware applications. OurRoughDroid also provides best performance with detection rate of 95.6%.Table 3
Detection rates ofRoughDroid in comparison with Drebin, SigPID, and ten anti-virus scanners.
RoughDroid Drebin [1] SigPID [18] Anti-V1 Anti-V2 Anti-V3 Anti-V4 Anti-V5 Anti-V6 Anti-V7 Anti-V8 Anti-V9 Anti-V10 Detection Rate 95.60% 93.90% 91.22% 96.41% 93.71% 84.66% 84.54% 78.38% 64.16% 48.50% 48.34% 9.84% 3.99%


### 3.2.3. Detecting Malware Families

When evaluating the detection efficiency of an approach, the equilibrium of malware family members in the dataset is very important. If the number of applications of a particular malware family members is little great compared to various other families, the detection result might mostly depend on these families. An unreal solution to this problem is to make use of the same number of applications for each malware family.We are laying more stress on 20 (FakeInstaller, DroidKungFu, Plankton, Opfake, GingerMaster, BaseBridge, Iconosys, Kmin, FakeDoc, Geinimi, Adrd, DroidDream, Linux/Lotoor, GoldDream, MobileTx, FakeRun, SendPay, Gappusin, Imlog, andSMSreg) top common malware families, plus the new three (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) malware families that invade Google Play Store at 2017.We perform three more experiments, by restricting the variety of applications for a certain family in the test set. In the first experiment, we offer no applications of the family. In the second experiment, we place 10 arbitrarily picked applications of the family back right into the test set. Finally, in the third experiment, we use 20 arbitrarily picked applications of the family back right into the test set. The consequences of these three experiments are shown in Figure5.RoughDroid can reliably detect all households with a typical precision of 95.6% at FPR=1%. The figure also shows that five (Kmin, MobileTx, FakeRun, Grabos, andAsiaHitGroup) families are perfectly detected.Figure 5
RoughDroid detection rate for 23 malware families based on three different number of applications for each family.


## 3.2.1. RoughDroid and Related Approaches

We initially contrast the efficiency ofRoughDroid versus associated static methods for the discovery of Android malware. Specifically, we think about Drebin [1], RCP [16], Peng et al. [17], and SigPID [18]. The outcomes of these experiments are displayed in Figure 4 as ROC curve.RoughDroid outperforms the four previously mentioned approaches by detecting 95.6% of the malware applications at a false-positive rate (FPR) equal to 1%.Figure 4
RoughDroid performance analysis ROC curve comparison with three approaches.Also, according to the statistical measures introduced in Table2, theAsymptotic Probability of the five schemes is much smaller than 0.05; thus we can conclude that all schemes are effective. In addition, the area under the curve ofRoughDroid is 0.95633, which is closer to 1.0; hence,RoughDroid is the best scheme in successfully detecting the malware of an Android application. The excellent efficiency ofRoughDroid arises from the various feature sets that are used to design the malicious activity of an application.Table 2
Statistical measures forRoughDroid and four other schemes.
Scheme Area Std. Error Asymptotic Prob. 95% LCL 95% UCL RCP [16] 0.52123 0.08965 5.63972E-5 0.43983 0.62718  Peng et al. [17] 0.08182 0.85211 4.941212E-5 0.51643 0.73156  SigPID 0.91364 0.07131 4.72643E-4 0.57846 0.87653  Drebin [1] 0.93521 0.06344 3.66257E-4 0.66972 0.91842  RoughDroid 0.95633 0.04577 2.48984E-6 0.79892 0.97833


## 3.2.2. RoughDroid and Popular AV Scanners

RoughDroid reveals a much better efficiency compared to related approaches ([1, 16–18]). We likewise contrast it with ten picked antivirus scanners on the considered dataset. It should be mentioned that we consider FPR=1%, which we assume to be adequately low enough for practical scenarios.Experimental results are displayed in Table3. The best antivirus detects over 90% of malware applications. OurRoughDroid also provides best performance with detection rate of 95.6%.Table 3
Detection rates ofRoughDroid in comparison with Drebin, SigPID, and ten anti-virus scanners.
RoughDroid Drebin [1] SigPID [18] Anti-V1 Anti-V2 Anti-V3 Anti-V4 Anti-V5 Anti-V6 Anti-V7 Anti-V8 Anti-V9 Anti-V10 Detection Rate 95.60% 93.90% 91.22% 96.41% 93.71% 84.66% 84.54% 78.38% 64.16% 48.50% 48.34% 9.84% 3.99%


## 3.2.3. Detecting Malware Families

When evaluating the detection efficiency of an approach, the equilibrium of malware family members in the dataset is very important. If the number of applications of a particular malware family members is little great compared to various other families, the detection result might mostly depend on these families. An unreal solution to this problem is to make use of the same number of applications for each malware family.We are laying more stress on 20 (FakeInstaller, DroidKungFu, Plankton, Opfake, GingerMaster, BaseBridge, Iconosys, Kmin, FakeDoc, Geinimi, Adrd, DroidDream, Linux/Lotoor, GoldDream, MobileTx, FakeRun, SendPay, Gappusin, Imlog, andSMSreg) top common malware families, plus the new three (Grabos, TrojanDropper.Agent.BKY, andAsiaHitGroup) malware families that invade Google Play Store at 2017.We perform three more experiments, by restricting the variety of applications for a certain family in the test set. In the first experiment, we offer no applications of the family. In the second experiment, we place 10 arbitrarily picked applications of the family back right into the test set. Finally, in the third experiment, we use 20 arbitrarily picked applications of the family back right into the test set. The consequences of these three experiments are shown in Figure5.RoughDroid can reliably detect all households with a typical precision of 95.6% at FPR=1%. The figure also shows that five (Kmin, MobileTx, FakeRun, Grabos, andAsiaHitGroup) families are perfectly detected.Figure 5
RoughDroid detection rate for 23 malware families based on three different number of applications for each family.


## 4. Related Work and Discussion

To the best of our knowledge, Android malware detection and classification have a wide research area in the last decade. It has three basic categories, based on the detection technique, that is, static analysis, dynamic analysis, and machine learning analysis. Several methods have been proposed for statically analyzing an Android application, such as [8, 9, 18, 19]. Also, there are some contributions based on dynamic analysis, such as [5–7, 20, 21]. Regarding realizing the data placement considering both the energy consumption in private cloud and the cost for renting the public cloud services, the authors in [22] have proposed a cost- and energy-aware data placement method, for privacy-aware applications over big data in hybrid cloud.Furthermore, the detection techniques [16, 17, 23, 24] are based on machine learning. The authors in [25] propose a new bio-key production algorithm called FVHS, which unites the benefits of the biometrics authentication and user-key authentication. Also, in [26] the authors suggest a new scheme named FREDP (File Remotely keyed Encryption and Data Protection). This strategy entails interaction between one of the clouds that are personal and a terminal. The authors in [27] propose a new identity-based blind signature scheme based on number theorem research unit lattice.The authors in [28, 29] are proposing a new access control for cloud infrastructure as a service. Also, a trust based access control model is proposed in [30]. In addition, cryptographic access control scheme is introduced in [31]. Also, the authors in [32] propose a new space metric optimization pushed deep-learning frame for age-invariant facial recognition. A complete review for Blockchain and intrusion detection is available in [33]. Reference [34] introduced JFCGuard for detecting juice filming charging attack and [35] enhanced network capacity. A privacy-preserving scheme based on location is introduced in [36].Due to the sparsity of big rating data in E-commerce, both similar friends and similar product items may be absent from the user-product purchase network, which leads to a big challenge to the recommendation of appropriate product items to the target user. The authors in [37] propose a structural balance theory-based recommendation scheme. Also, protecting users’ privacy is challenging when IBM releases its own data to Amazon. In addition, the recommendation efficiency and scalability are often low when the user-service quality data of Amazon and IBM are updated frequently. Thus, the authors in [38] have proposed a privacy-preserving and scalable service recommendation approach based on distributed locality-sensitive hashing.Based on deep learning, [39] proposed a novel finger vein recognition algorithm. For social networks, [40] introduced a measure for social influence. An early detection scheme for IP traffic is introduced in [41]. A new instant encrypted transmission is proposed in [42]. Based on trusted routing, a sensitive analysis of attack-pattern is proposed in [43]. Finally, [44] presents a new scheme M-SSE that achieves both forward and backward security based on a multicloud technique.


## 5. Conclusion

This paper introducedRoughDroid that is a new broad floppy analysis malware detector on smart Android phones during the installation time by introducing robust feature extraction framework.RoughDroid performs a broad floppy analysis, gathering numerous features from an application’sDex code as well asmanifest file. It is based on ten feature sets (FS1,FS2,…,FS10). It then uses the Rough Set algorithm to check the behavior of an Android application. The experimental results showed thatRoughDroid is detecting 95.6% of the malware applications at a FPR=1%, which means thatRoughDroid outperforms the well-known detection approaches (Drebin [1], RCP [16], Peng et al. [17], and SigPID [18]). Also,RoughDroid is compared with the ten most popular antivirus scanners and proved efficiency in practical scenarios. Finally,RoughDroid is able to perfectly detect five (Kmin, MobileTx, FakeRun, Grabos, andAsiaHitGroup) malware families.



---

*Source: 8087303-2018-09-20.xml*