Innovative Approach to Android Malware Detection: Prioritizing Critical Features Using Rough Set Theory

Abstract

The widespread integration of smartphones into modern society has profoundly impacted various aspects of our lives, revolutionizing communication, work, entertainment, and access to information. Among the diverse range of smartphones available, those operating on the Android platform dominate the market as the most widely adopted type. With a commanding 70% share in the global mobile operating systems market, the Android OS has played a pivotal role in the surge of malware attacks targeting the Android ecosystem in recent years. This underscores the pressing need for innovative methods to detect Android malware. In this context, our study pioneers the application of rough set theory in Android malware detection. Adopting rough set theory offers distinct advantages, including its ability to effectively select attributes and handle qualitative and quantitative features. We utilize permissions, API calls, system commands, and opcodes in conjunction with rough set theory concepts to facilitate the identification of Android malware. By leveraging a Discernibility Matrix, we assign ranks to these diverse features and subsequently calculate their reducts–streamlined subsets of attributes that enhance overall detection effectiveness while minimizing complexity. Our approach encompasses deploying various Machine Learning (ML) algorithms, such as Support Vector Machines (SVM), K-Nearest Neighbor, Random Forest, and Logistic Regression, for malware detection. The results of our experiments demonstrate an impressive overall accuracy of 97%, surpassing numerous state-of-the-art detection techniques proposed in existing literature.

1. Introduction

Smartphones, in reality, are the personal desktop computers of today’s world. With smartphones, we can do almost anything we intend to do with personal desktop computers. Smartphones have become integral to modern society, impacting various aspects of our lives. Their versatility and functionality have revolutionized how we communicate, work, entertain ourselves, and access information. In addition to being a communication device to place calls and send SMSs, smartphones are used for internet browsing, social media, emails, photography and videography, navigation, online shopping, banking, health and fitness, education and learning, personal organization, and intelligent home control. The current mobile market share is 20% higher than desktops, meaning smartphones are leading the way ahead of desktops in terms of usage [1].

Among all the types of smartphones available in the market, smartphones with the Android operating system are the most popular. The reason for the popularity is that Android is an open-source platform many manufacturers adopt. As per the report of Statcounter [2], the global market share of mobile operating systems is entirely dominated by the Android operating system with a 70% share. The high market share of the Android operating system is one of the primary reasons for many malware attacks on the Android platform over the past few years. As per the report [3], several mobile trojan subscribers were found on Google’s official app marketplace in 2022. As per the blog post by renowned antivirus firm McAfee [4], 60 Android apps with 100 million downloads were found to be spreading a new malware strain to unsuspecting users. According to the news article on TechRadar [5], a new ransomware, “Daam”, capable of hiding from antivirus software, was detected. The report on the development of new Android malware shared by Statistica [6] shows that 5.6 million Android malware samples were seen in 2020. Moreover, millions of Android malware have been detected yearly from 2016 to 2020. Hence, there is a dire need to develop Android malware detection mechanisms to see malicious applications.

Malware analysis is a technique by which we can analyze the functionality and source of malware. Malware analysis can be broadly classified into three types [7]: static analysis, dynamic analysis, and hybrid analysis. These different analysis techniques can form a detection model to classify an Android application as malicious or benign. Three types of detection models could be possible: static, dynamic, and hybrid. In static detection, features are extracted using static analysis, which is the art of malware analysis that extracts features from the application without installing or executing the application. In dynamic detection, features are extracted using dynamic analysis, performed by executing or running the application and capturing the features at run time. The hybrid detection model is based upon hybrid analysis, which extracts both static and dynamic features from the application.

In static detection methods, the standard static techniques employed for extracting static features are manifest file-based detection, API calls-based detection, and Java code-based detection methods. In the manifest file-based detection technique, features are extracted from the manifest file of the Android application. Li et al. [8] used permissions from the manifest file and achieved an accuracy of 90%. Arora et al. [9] used permissions pairs from the manifest file and achieved an overall accuracy of 95.44%. IPDroid [10] used both permissions and intents from the manifest file and achieved an accuracy of 94.73% with a Random Forest classifier.

API calls-based feature detection is based on extracting APIs to be called by Android applications. Droidmat [11] used API calls along with manifest file components to detect malicious applications with an accuracy of 97.87%. Elish et al. [12] extracted sensitive API calls invocation by the user to build a detection model. Zhang et al. [13] created association rules between API calls and achieved an accuracy of 96%.

The Java code-based detection methods use Dex files that contain Java code in Android applications for extracting features. Zhu et al. [14] converted the vital parts of Dalvik byte code into RGB images and trained the Convolution neural network to devise the malware detection system with an accuracy of 96.9%. Fang et al. [15] also converted Dex files to RGB images to do malware familial classification with a precision of 96%. The work [16] is based on eliminating code confusion and achieves an overall accuracy of 92.67%.

Contributions

In the current work, we have used permissions, API calls, system commands, and opcodes with rough set theory for Android malware detection. To the best of our knowledge, we are the first to apply rough set theory to the static features mentioned above. The rough set theory has several advantages, such as attribute selection and its ability to work with qualitative and quantitative attributes. We used a Discernibility Matrix to rank and further calculate the reduct of the above features. Ranking of features is done to highlight essential features. Reduct, a reduced feature set, is estimated to improve the overall detection rate with the most minor features. We applied several Machine Learning (ML) algorithms such as Support Vector Machines (SVM), K-Nearest Neighbor, Random Forest, and Logistic Regression for malware detection. Our results demonstrate an overall accuracy of 97%, better than many state-of-the-art detection techniques proposed in the literature. The main contributions of this paper are summarized below.

• Firstly, we performed data pre-processing, in which we eliminated co-related features and features not dependent on the class variable.
• We calculated the ranking score with the help of the discernibility concept of rough set theory to rank the features according to their importance.
• We applied an algorithm for rough set reduct computation to reduce the number of features in each category using the ranking score and discernibility concept of rough set theory.
• We further applied machine learning algorithms to evaluate the detection accuracy with the reduct calculated in the previous step.
• We compared the results of our proposed model with other state-of-the-art detection techniques, and our results highlight that the proposed model outperforms similar state-of-the-art models.

The rest of the paper is organized as follows. We discuss related work in Section 2. The detailed methodology is discussed in Section 3. Section 4 is dedicated for results and discussions, and we conclude the paper with future directions in Section 5.

2. Related Work

This section describes the work on static malware detection methods based on manifest file-based detection, API calls-based detection, and Java code-based detection. Therefore, this section is divided into three subsections: manifest file-based detection, API calls-based detection, and Java code-based detection.

2.1. Manifest File-Based Detection

In this sub-section, we review the works that have analyzed features from manifest files for Android malware detection. Grace et al. [17] established the relationship between embedded ad libraries and host apps as a significant risk factor for Android-based smart devices. Enck et al. [18] developed a lightweight certification model based on security configuration within an application to identify risky applications. A malware detection system, SIGPID, was proposed by Li et al. [8], in which three-level pruning is applied to filter out a minimal permission set that can be used for malicious app identification. Talha et al. [19] developed a client–server-based tool known as APK-auditor to detect malicious applications that maintain the Android profile database based on permission analysis.

The authors in [20] developed context category ontology based on permissions to detect the potential risk of information leakage with the help of a malicious activity. A prototype ASE was developed by Song et al. [21], which applied four levels of filtering based on static analysis to detect an application as benign or malicious. DroidChain [22] is another malware detection approach that applies static analysis and a behavior chain model to detect four types of malicious behaviors, i.e., privacy leakage, SMS financial charges, malware installation, and privilege escalation. ProDroid [23] is another behavior-based malware detection model that uses the biological sequence technique and Markov chain model to match the classes and API of decompiled applications to the stored malicious behavior models. Moonsamy et al. [24] used both requested and used permissions to mine contrasting permission sets, which were further used to detect an application as benign or malware.

Idrees et al. [25] used intent filters and permissions to identify an application as benign and malicious. Wang et al.’s [26] work is based on rankings of requested permissions based on risk, and the selection of risky permission subset is made to train machine learning models. DroidRanger was developed by the authors in [27] as a malicious application detection tool using permission behavior and heuristic filtering, which also successfully discovered zero-day malware. Qiu et al. [28] did a unique work of annotating the capabilities of detected malware regarding security and privacy concerns. APIs, intents, and permissions were used in [29] to perform similarity associations with malware samples and detect malicious applications using hamming distance.

Bai et al. [30] tried to develop a fast malware detection model using multiple features such as permissions and opcode sequences. Drebin [31] is a lightweight malware detection technique that can be deployed on the smartphone. The developed method can detect malicious applications on the smartphone within ten seconds of download. Varsha et al.’s [32] work is based on selecting prominent features from various sets of static features. Mahindru et al. [33] used ten different feature selection techniques to find the best possible combination of features to detect malicious applications effectively. Firdaus et al. [34] is a genetic search-based technique, in which a genetic algorithm minimizes the number of features.

Khariwal et al. [10] proposed a novel method to find the best permissions and intents combined to detect malicious applications. PermPair [9] is another malicious application detection technique that creates permission pairs from each application and further constructed malicious and normal permissions pair graphs used for the detection mechanism. The work in [35] uniquely compared the dynamics between requested permissions and intent filters. In manilyzer [36], stress was given on using different manifest components along with requested permissions. Sanz et al. [37] developed a malware detection model based on used permissions. Li et al. [38] developed a malware detection model using multiple features both from the manifest file as well as from the source file, whereas Sato et al. [39] used multiple features from the manifest file only.

2.2. API Calls-Based Detection

Several researchers have utilized static API calls to identify Android malware. The Droidmat model [11] employed a combination of manifest file features and API calls and applied K-means and KNN algorithms for malware detection. Another study [12] examined user-triggered dependencies and sensitive APIs in malicious apps, while Zhang et al. [40] constructed dependency graphs of API calls to categorize malicious apps into Android malware families using similarity metrics. The authors of [41] introduced a model called Apposcopy, which examined control-flow and dataflow properties derived from API calls to detect malware. Wang et al. [42] focused on analyzing string features like permissions and intents, as well as structural features such as API calls and function call graphs, on detecting malicious behaviour in Android apps. Similarly, the work described in [13] involved the analysis of API calls and their call graphs for malware detection.

2.3. Java Code-Based Detection

Zhu et al. in [14] developed an image-based malware detection method that extracts important parts of Dalvik code and converts it to RGB images. Fang et al. [15] also used RGB images generated from Dex files but, apart from classifying an application as benign or malicious, did malware familial classification. The work [16] eliminated code confusion and calculated scores for every code word based on their importance, which deep learning models then used to detect malicious applications. CDGDroid [43] is another technique to detect Android malware based on control flow graphs and data flow graphs that are constructed from the code of the application with the help of program analysis techniques and later on used as features for the CNN model. Xiao et al. [44] developed a method that captures the system call sequence from the code of the application, and the captured system call sequence is used to train LSTM to detect malicious applications. To form the malware detection model, MSNDroid [45] incorporated native-layer code features and combined them with permissions and Java layer components.

To the best of our knowledge, no other work has used rough set theory to form reducts of multiple features in the area of Android malware detection.

3. The Proposed Methodology

This section describes the overall approach to classifying Android applications as malware or benign. The process is divided into four phases, as depicted in Figure 1. The first phase of the approach is the pre-processing phase, the second phase is feature ranking, the third phase is the Rough Set Reduct Computation Phase, and the fourth phase is the detection phase.

Figure 1. Proposed Methodology.

3.1. Data Pre-Processing Phase

These data pre-processing phase is more focused on the primary feature selection phase. The whole process of this phase is depicted in Figure 2.

Figure 2. Data Pre-Processing.

The figure referred to here summarizes the whole process of phase 1. The proposed technique first considers the OmniDroid Dataset [46] and Androzoo Dataset [47]. The OmniDroid dataset is the data set in which various features are extracted from an extensive collection of 22,000 APKs. The dataset consists of an equal number of benign and malicious applications, i.e., 11,000 each. An additional 8000 applications are taken from the Androzoo Data set, spreading from 2015 to 2023, making it more diverse. These 8000 apps consist of an equal number of benign and malicious applications, i.e., 4000 each. The features from these 30,000 apps were extracted with the AndroPytool [48]. The AndroPyTool extracts features from the Android application supplied as input to the tool. Specifically, the AndroPyTool extracts three types of features: pre-static features, static features, and dynamic features. This paper focuses on static features, i.e., permissions, API calls, system commands, and opcodes. The following is the description of each static feature considered in this paper.

• Permissions: Every Android application requests and requires a particular set of permissions for its functioning. The apps need these permissions to access some data or specific resources. These permissions are listed in the Android Manifest file. The OmniDroid dataset consists of 5501 unique permissions.
• API Calls: The Application Programming Interface (API) is a set of code snippets that the underlying systems use for communicating. API calls are the calls to such code snippets with some functionality that must be invoked to perform specific tasks. The dataset in consideration consists of 2128 API Calls.
• System commands: Android applications must access the kernel to perform specific tasks and services. So, the services that need to be accessed by the app are done by calling the OS routines. The calls to such kinds of OS routines are known as system commands. The OmniDroid dataset consists of 103 system commands.
• Opcodes: The Dalvik Bytecode generated by compiling the Android apps consists of instructions that need to be executed in terms of opcodes. The data set consists of 224 opcodes.

First, each of the features mentioned above are considered individually to be pre-processed. The feature correlation score is calculated for each of the separate features, i.e., permissions, API calls, system commands, and opcodes. This feature correlation score is the basis for eliminating such features that are highly correlated with the existing features. The elimination of closely interconnected attributes occurs due to their strong correlation, resulting in a high degree of linear dependence. As a result, they exert nearly identical influences on the dependent variable. Thus, in cases where two attributes exhibit significant correlation, it is feasible to omit one of them. A correlation score of 90 per cent or more is used to select one feature out of two and eliminate the other. After this round, we received 4428 permissions out of 5501 permissions, 1589 API calls out of 2128 API calls, 93 System commands out of 103 System calls, and 159 Opcodes out of 224 Opcodes.

Further, the Chi-Square test is executed to select a subset of features for each feature set. The Chi-square test is a statistical test used to determine whether there is a significant association between two categorical variables. The chi-square test works based on the following equation:

$${\chi }^2=\sum _{i=1}^n\frac{{(O_i-E_i)}^2}{E_i}$$

(1)

The formula for the Chi-square test involves several key terms and calculations, as shown in Equation (1), where ${\chi }^2$ is the Chi-square test statistic, n is the number of categories in the contingency table, $O_i$ is the observed frequency of category i, and $E_i$ is the expected frequency of category i under the null hypothesis. The sum is taken over all categories in the contingency table.

Initially, the null hypothesis assumes that the two variables, i.e., the feature variable and the class variable, do not have any association. Then, the Chi-square test is applied to those variables using Equation (1) to calculate the Chi-square test statistic value. The Chi-square distribution table maps the estimated chi-square test statistic value to the corresponding p-value. The p-value less than 0.05 means that the null hypothesis assumed is false, and the alternate hypothesis that the class variable and the feature variable are associated with each other is true. All those features in each feature set that fall in the rejection region whose p-value is less than 0.05 are selected as a new feature subset for each feature set. Choosing a p-value of less than 0.05 means the features falling in this rejection region have 95% confidence of dependency on the class variable. Hence, in the end, we got a subset of each feature space with the minimized feature set from each feature space, i.e., permissions, API calls, system commands, and opcodes’ feature space.

For the permission feature set, we achieved 206 permissions selected as a subset of permission out of 4428 permissions. For the API calls feature set, we achieved 1264 API calls selected as a subset of API calls out of 1589 API calls. For system command feature space, out of 94 system commands obtained in the previous step, we achieved a minimized feature space of 52. Similarly, for the opcodes-based feature set, which consisted of 204 opcodes from the previous step, we achieved 158 opcodes. The entire process is also summarized in the Algorithm 1.

Algorithm 1 Data Pre-Processing

1:  Input: A feature set of 22,000 APK regarding four types of features, i.e., Permissions ($f_p$), API Calls ($f_a$), System commands ($f_s$), and Opcodes ($f_o$).   2:  Output: For each of the feature set $f_p, f_a, f_s,$ and $f_o$, a minimal feature space of important features is obtained as $min\_f_p, min\_f_a, min\_f_s,$ and $min\_f_o$, respectively.   3:  for each of features set $f_i$ in feature spaces $f_p, f_a, f_s, f_o$ do   4:        set $|f_i|=N$   5:        for each of the feature $x_i$ in feature set $f_i$ do   6:              set $Truth\_val\left(x_i\right)=True$   7:        end for   8:        for each of the feature $x_i$ in feature set $f_i$ do   9:              if $Truth\_val\left(x_i\right)==True$ then 10:                    for each of the feature $x_j$ in feature set $f_i$ where $j:i+1\to N$ do 11:                          if $(correl[x_i,x_j]>0.9)$ then 12:                                $Select\left(x_i\right)$ 13:                                $Reject\left(x_j\right)$ and set $Truth\_val\left(x_j\right)=False$ 14:                          end if 15:                    end for 16:              end if 17:        end for 18:  end for 19:  for each of the features set $f_i$ in the new feature space $f_p, f_a, f_s,$ and $f_o$ obtained do 20:        for each of the feature $x_i$ in feature set $f_i$ do 21:              Apply Chi-Square Test $\left(x_i\right)$ 22:              if $p\_value\left[x_i\right]<0.05$ then 23:                    $Select\left(x_i\right)$ 24:              else 25:                    $Reject\left(x_i\right)$ 26:              end if 27:        end for 28:  end for

3.2. Feature Ranking Phase

In this phase, the ranking of minimal feature sets obtained in the previous step is performed to rank the features of each type according to their importance. Feature ranking is performed through the Discernibility Matrix concept of rough set theory. The whole process flow of this phase is depicted in Figure 3.

Figure 3. Feature Ranking Phase.

Rough set theory is a mathematical approach to data analysis and data mining. This mathematical tool is powerful in dealing with improper, imprecise, inconsistent, incomplete information, and knowledge [49,50]. The rough set theory has several advantages, such as attribute selection and its ability to work with qualitative and quantitative attributes. The critical concepts of the rough set theory used in this paper are explained below.

3.2.1. Information System

It is defined as an ordered pair, in which the first element of this ordered pair is called the universe. In our case, the universe is the set of both malicious and benign applications that are considered. We represent the ordered pair as $D=(A,F\cup \{l\left\}\right)$, where D is the data set under consideration, and A is the non-empty finite set called the universe of Android application, consisting of both the malicious and benign types. F is the non-empty set of features in the data set. In our case, these features are in terms of permissions, API calls, system commands, and opcodes. Here, l is the special attribute known as the label attribute, which stores the type of label corresponding to each application in set A. This label attribute stores whether a particular application in set A is malicious or benign. Table 1 shows an instance of the permission information system for five applications assumed as $A_1,A_2,A_3,A_4,$ and $A_5$. Here, feature attributes are the Content Provider Access, Settings App widget Provider, and JPUSH Message. These are permissions, with corresponding values such as 0 or 1 for each application $A_i$. The value 0 signifies that particular permission is not present in application $A_i$, whereas the value 1 signifies otherwise. The label column has the value BW, signifying that the particular $A_i$ is Benignware, whereas the label value MW signifies that application $A_i$ is malware, i.e., a malicious one.

Table 1. Instance of permission information system.

Application	${\mathit{P}}_1$ = CONTENT PROVIDER ACCESS	${\mathit{P}}_2$ = Settings App Widget Provider	${\mathit{P}}_3$ = JPUSH MESSAGE	Label
$A_1$	0	1	0	BW
$A_2$	1	1	0	MW
$A_3$	0	1	1	BW
$A_4$	0	0	1	BW
$A_5$	1	1	1	MW

Similarly, the information systems for API calls, system commands, and opcodes are shown in Table 2, Table 3 and Table 4, respectively. From these information systems, a Discernibility Matrix is formed. The concept of Discernibility is explained in the following section.

Table 2. Instance of API calls information system.

Application	${\mathit{AP}}_1$ = APICALL-android.view.SubMenu	${\mathit{AP}}_2$ = APICALL-android.net.RouteInfo	${\mathit{AP}}_3$ = APICALL-android.app.Activity	Label
$A_1$	0	0	0	BW
$A_2$	1	1	0	MW
$A_3$	1	1	1	MW
$A_4$	1	0	1	BW
$A_5$	1	1	1	MW

Table 3. Instance of system command information system.

Application	${\mathit{S}}_1$ = SYSTEMCOMMAND-svc	${\mathit{S}}_2$ = SYSTEMCOMMAND-stagefright	${\mathit{S}}_3$ = SYSTEMCOMMAND-nandread	Label
$A_1$	0	1	0	MW
$A_2$	1	1	0	MW
$A_3$	0	1	1	BW
$A_4$	0	0	1	BW
$A_5$	1	1	1	MW

Table 4. Instance of opcode information system.

Application	${\mathit{O}}_1$ = OPCODE-rem-float/2addr	${\mathit{O}}_2$ = OPCODE-div-int/lit8	${\mathit{O}}_3$ = JOPCODE-sparse-switch	Label
$A_1$	1	1	0	BW
$A_2$	0	1	0	MW
$A_3$	1	0	1	MW
$A_4$	0	0	1	BW
$A_5$	0	1	1	BW

3.2.2. Discernibility Matrix

This matrix is created from the information system. The Discernibility Matrix is a symmetric $\left|A\right|X\left|A\right|$ matrix corresponding to each information system. Each entry $C_{ij}$ is defined as $\{f\in F|f\left(A_i\right)\ne f\left(A_j\right)\}$ $if$ $l\left(A_i\right)\ne l\left(A_j\right)$, $\Phi$ otherwise. Table 5, Table 6, Table 7 and Table 8 show the instances of Discernibility Matrices corresponding to information system shown in Table 1, Table 2, Table 3 and Table 4, respectively.

Table 5. Instance of permission discernibility.

	${\mathit{A}}_1$	${\mathit{A}}_2$	${\mathit{A}}_3$	${\mathit{A}}_4$	${\mathit{A}}_5$
$A_1$
$A_2$	$P_1$
$A_3$		$P_1,P_3$
$A_4$		$P_1,P_2,P_3$
$A_5$	$P_1,P_3$		$P_1$	$P_1,P_2$

Table 6. Instance of API calls discernibility.

	${\mathit{A}}_1$	${\mathit{A}}_2$	${\mathit{A}}_3$	${\mathit{A}}_4$	${\mathit{A}}_5$
$A_1$
$A_2$	$A{P}_1,A{P}_2$
$A_3$	$A{P}_1,A{P}_2,A{P}_3$
$A_4$		$A{P}_2,A{P}_3$	$A{P}_2$
$A_5$	$A{P}_1,A{P}_2,A{P}_3$			$A{P}_2$

Table 7. Instance of system call discernibility.

	${\mathit{A}}_1$	${\mathit{A}}_2$	${\mathit{A}}_3$	${\mathit{A}}_4$	${\mathit{A}}_5$
$A_1$
$A_2$
$A_3$	$S_3$	$S_1,S_3$
$A_4$	$S_2,S_3$	$S_1,S_2,S_3$
$A_5$			$S_1$	$S_1,S_2$

Table 8. Instance of opcode discernibility.

	${\mathit{A}}_1$	${\mathit{A}}_2$	${\mathit{A}}_3$	${\mathit{A}}_4$	${\mathit{A}}_5$
$A_1$
$A_2$	$O_1$
$A_3$	$O_2,O_3$
$A_4$		$O_2,O_3$	$O_1$
$A_5$		$O_3$	$O_1,O_2$

For each of the selected minimal permission set, API call feature set, system command feature set, and opcode feature set, we create the Permission Discernibility Matrix, API Call Discernibility Matrix, System Call Discernibility Matrix, and Opcode Discernibility Matrix, respectively. Algorithm 2 depicts the whole process. The algorithm creates a Discernibility Matrix for each minimal feature set obtained in the previous step and further calls the rough set ranking algorithm described in the next section.

Algorithm 2 Feature Ranking

1:  Input: Minimal feature space, i.e., $min\_f_p, min\_f_a, min\_f_s$, and $min\_f_o$ obtained as output of Algorithm 1.   2:  Output: For each of the minimal feature space, ranked minimal feature list $L_p, L_a, L_s,$ and $L_o$, respectively, sorted in decreasing order as per the importance of the features.   3:  for each of the minimized feature space $min\_f_i$ in $min\_f_p, min\_f_a, min\_f_s$, and $min\_f_o$ do   4:         create Discernibilty Matrix for $min\_f_i$.   5:  end for   6:  Let $D_p, D_a, D_s$, and $D_o$ be Discernibility Matrix corresponding to $min\_f_i$ in $min\_f_p, min\_f_a, min\_f_s$, and $min\_f_o$, respectively.   7:  for each of Discernibility Matrix $D_i$ in $D_p, D_a, D_s$, and $D_o$ do   8:         call Algorithm 3 for each $D_i$ in order to perform rough set ranking of each of the features in $D_i$   9:         Let $L_p, L_a, L_s,$ and $L_o$ be be the sorted list of important features for each of $min\_f_i$ in $min\_f_p, min\_f_a, min\_f_s,$ and $min\_f_o$, respectively 10:  end for

3.2.3. Rough Set-Based Feature Ranking

After creating each of these Discernibility Matrices, a rough set-based feature ranking methodology, summarized in Algorithm 3, is applied on each matrix to rank each of the Permission, API Call, System Command, and Opcode features separately. The algorithm takes the Discernibility Matrix as an input and initializes the weight of each feature in the corresponding minimal feature set to zero. Then, the Discernibility Matrix is traversed, and each entry in the Discernibility Matrix, which consists of one or more features, receives the updated weight of the features as per Equation (2).

$$w\left(x_k\right)=w\left(x_k\right)+\left|min\_f_i\right|/|C_{ij}|$$

(2)

In the above equation, $C_{ij}$ is the entry in the Discernibility Matrix corresponding to applications $A_i$ and $A_j$, and the entry $C_{ij}$ may contain one or more features. Hence, $|C_{ij}|$ represents the count of features in the entry. $min\_f_i$ is the minimal feature set corresponding to the Discernibility Matrix, and $\left|min\_f_i\right|$ is the count of features in the minimal feature set. $w\left(x_k\right)$ is the weight of $k^{th}$ feature in the entry $C_{ij}$, which may contain $x_1,x_2,x_3,\dots$ and $x_n$ as the features in the entry.

Algorithm 3 Rough Set Ranking

1: Input: Discernibility Matrix $D_i$ with dimensions $nXn$.   2: Output: Ranked feature list $L_i$ w.r.t $D_i$.   3: for each $x_i$ in the minimal feature space $min\_f_i$ corresponding to $D_i$ do   4:        Let $w\left(x_i\right)$ denote the weight of the feature $x_i$ and let $w\left(x_i\right)=0$.   5: end for   6: for each $i:1\to N$  do   7:        for each $j:1\to i$ do   8:               Let $C_{ij}$ be the entry in Discernibility Matrix $D_i$ containing features $x_1,x_2,x_3,\dots and$ $x_n$.   9:               for each $x_k$ in $x_1,x_2,x_3,\dots and$ $x_n$ corresponding to entry $C_{ij}$ do 10:                      update weight of every feature $x_k\in C_{ij}$ as 11:                      $w\left(x_k\right)=w\left(x_k\right)+|min\_f_i|/|C_{ij}|$ 12:               end for 13:        end for 14: end for 15: Sort every $x_i$ in the minimal feature space $min\_f_i$ w.r.t $w\left(x_i\right)$ in decreasing order of $w\left(x_i\right)$

This ranking is obtained by arranging each of these features in descending order in terms of their importance.

The Rough Set-based feature ranking embodies the following idea [49].

(1)

The more times an attribute appears in the discernibility, the more important is the attribute.

(2)

The shorter the entry is, the more important the attributes is in the entry.

3.3. Rough Set Reduct Computation Phase

This phase focuses on reducing the feature space so that, with as few features as possible, i.e., a reduced feature space, the classification algorithms could be applied to detect an application as benign or malicious. The reduced feature space obtained using the underlying principles of rough set theory is called reduct in rough set theory. The Discernibility Matrix and rough set feature ranking obtained in the previous phase are used to attain reducts for each of the permission, API call, system command, and opcode feature spaces. Hence, after this phase, for each feature space, i.e., permission, API call, system command, and opcode, we get a reduced feature space, which we call a reduct in rough set theory. Figure 4 depicts the current phase under discussion. Algorithm 4 describes the whole process in pseudo-code form. The algorithm first calculates the net weight $w\left(ne{t}_{ij}\right)$ of each of the entry $C_{ij}$ in the Discernibility Matrix $D_i$, containing features $x_1,x_2,x_3,\dots$ and $x_n$ by summing their individual weights $w\left(x_1\right),w\left(x_2\right),w\left(x_3\right),\dots \dots$ and $w\left(x_n\right)$, respectively. Then, all the entries $C_{ij}$ in the Discernibility Matrix $D_i$ are copied in the list $L{D}_i$, and then $L{D}_i$ is sorted as per the net weight calculated in the previous step. Initially, $Re{d}_i$ is assumed to be an empty set. For each entry $C_z$ of the sorted list $L{D}_i$ containing features $x_1,x_2,x_3,\dots \dots$ and $x_n$, we check weather the $Re{d}_i$ contains any common feature in $C_z$. If no common feature exists, we select the feature $x_i$ with maximal $w\left(x_i\right)$ in $C_z$; otherwise, we skip the entry $C_z$. The set $Re{d}_i$ is the reduct computed for $min\_f_i$.

Algorithm 4 Rough Set Reduct Computation

1: Input: Discernibility Matrix $D_i$ with dimensions $nXn$ and weight $w\left(x_i\right)$ of every feature $x_i$ in the minimal feature space $min\_f_i$ in $min\_f_p, min\_f_a, min\_f_s,$ and $min\_f_o$ corresponding to $D_i$ in $D_p, D_a, D_s$ and $D_o$.   2: Output: $Re{d}_i$ as the reduct of minimal feature space $min\_f_i$ corresponding to $D_i$   3: Let $L{D}_p, L{D}_a, L{D}_s,$ and $L{D}_o$ be the empty list corresponding to permission, API call, system command and opcode feature space.   4: for each $D_i$ in $D_p, D_a, D_s,$ and $D_o$ do   5:      Let $Re{d}_i=\Phi$ denote the empty reduct set corresponding to minimal feature space $min\_f_i$.   6:      for each $i:1\to N$ do   7:            for each $j:1\to i$ do   8:                  Let $C_{ij}$ be the entry in Discernibility Matrix $D_i$ containing features $x_1, x_2, x_3,\dots$ and $x_n$.   9:                  Let $w\left(ne{t}_{ij}\right)$ be the cumulative weight of entry $C_{ij}$ having features as $x_1, x_2, x_3,\dots$ and $x_n$. 10:                  $w\left(ne{t}_{ij}\right)=w\left(x_1\right)+w\left(x_2\right)+w\left(x_3\right)\dots \dots \dots +w\left(x_n\right)$ 11:                  $L{D}_i=append\left(C_{ij}\right)$ 12:            end for 13:      end for 14:      $Sort\left(L{D}_i\right)$ based on $w\left(net\right)$ calculated previously. 15:      for each $z:1\to |L{D}_i|$ do 16:            Let $C_z$ be the entry in List $L{D}_i$ containing features $x_1, x_2, x_3,\dots$ and $x_n$. 17:            if $C_z\cap Re{d}_i=\Phi$ then 18:                  Select attribute $x_i$ with maximal $w\left(x_i\right)$ in $C_z$ 19:                  $Re{d}_i=Re{d}_i\cup x_i$ 20:            end if 21:      end for 22: end for

Figure 4. Rough Set Reduct Computation Phase.

3.4. Detection Phase

For building our Android Malware detection system, we experimented with four machine learning algorithms, i.e., the Support Vector Machine (SVM), Random Forest, Logistic Regression, and K-nearest neighbour algorithms, to train and test the dataset. We also performed training and testing on two deep learning models, i.e., Artificial neural network (ANN) and Convolution Neural Network (CNN). Figure 5 portrays the overall purpose of the current phase, i.e., with the help of the machine learning models mentioned above and the different reducts, i.e., permission reduct, API call reduct, system call reduct, and opcode reduct calculated in the previous phase; the machine learning models are trained to build the system capable of detecting an Android application as benign or malware.

Figure 5. Detection Phase.

4. Results and Discussion

In the current section, we present the results of the evaluation carried out on the proposed malware detection approach. The code and details about data set are available at https://github.com/rahulgupta100689/Rough-Set.git, accessed on 10 January 2024.

4.1. Results of Ranking Phase

Table 9 shows the top 10 important permissions for malware detection. Similarly, the Table 10, Table 11 and Table 12 represent the top 10 important opcodes, API calls, and system calls, respectively.

Table 9. Top ten important permissions.

Rank	Permission Name	Score
1	$READ\_PHONE\_STATE$	$1.56$E9
2	$ACCESS\_WIFI\_STATE$	$1.33$E9
3	$WRITE\_EXTERNAL\_STORAGE$	$1.26$E9
4	$WAKE\_LOCK$	$1.2$E9
5	$ACCESS\_COARSE\_LOCATION$	$1.03$E9
6	$ACCESS\_NETWORK\_STATE$	$1.02$E9
7	$ACCESS\_FINE\_LOCATION$	$1.01$E9
8	$GET\_TASKS$	$9.52$E8
9	$RECEIVE\_BOOT\_COMPLETED$	$8.82$E8
10	$GET\_ACCOUNTS$	$8.4$E8

Table 10. Top ten important opcodes.

Rank	Opcode	Score
1	$OPCODE-xor-int$	$3.09$E8
2	$OPCODE-rem-float$	$3.07$E8
3	$OPCODE-rem-float/2addr$	$2.98$E8
4	$OPCODE-float-to-long$	$2.82$E8
5	$OPCODE-and-long$	$2.78$E8
6	$OPCODE-aget-short$	$2.7$E8
7	$OPCODE-iget-byte$	$2.67$E8
8	$OPCODE-aput-short$	$2.66$E8
9	$OPCODE-iget-short$	$2.65$E8
10	$OPCODE-rem-double/2addr$	$2.65$E8

Table 11. Top ten important API calls.

Rank	API Call	Score
1	$APICALL-android.app.ActionBar$	$2.2$E8
2	$APICALL-android.widget.PopupWindow$	$2.2$E8
3	$APICALL-android.widget.BaseAdapter$	$2.17$E8
4	$APICALL-android.view.ScaleGestureDetector$	$2.15$E8
5	$APICALL-android.widget.CheckBox$	$2.12$E8
6	$APICALL-android.widget.AbsListView$	$2.1$E8
7	$APICALL-android.widget.ListPopupWindow$	$2.1$E8
8	$APICALL-android.content.res.XmlResourceParser$	$2.1$E8
9	$APICALL-android.graphics.Path$	$2.09$E8
10	$APICALL-android.webkit.MimeTypeMap$	$2.09$E8

Table 12. Top ten important system commands.

Rank	System Command	Score
1	$SYSTEMCOMMAND-top$	$4.27$E8
2	$SYSTEMCOMMAND-id$	$3.75$E8
3	$SYSTEMCOMMAND-start$	$3.7$E8
4	$SYSTEMCOMMAND-service$	$3.58$E8
5	$SYSTEMCOMMAND-gzip$	$3.54$E8
6	$SYSTEMCOMMAND-date$	$3.44$E8
7	$SYSTEMCOMMAND-log$	$3.17$E8
8	$SYSTEMCOMMAND-stop$	$3.1$E8
9	$SYSTEMCOMMAND-mv$	$3.06$E8
10	$SYSTEMCOMMAND-input$	$3.02$E8

4.2. Detection Results with Individual Features

Table 13 shows the results of four sets of permissions, i.e., all permissions in the data set, reduced permissions obtained after applying correlation feature elimination as permission correlation, permission chi as a set of permissions obtained after applying chi-square test on permission correlation, and finally permission reduct as the reduced permission feature set obtained after applying rough set reduct on permission chi. All four permission sets are used to train all six classifiers, i.e., Support Vector Machines (SVM), K-nearest neighbours, Random Forest, Logistic regression, ANN, and CNN. The results indicate that, for each type of classifier, as the feature set is changed from all permissions to permission correlation then to permission chi and finally to permission reduct, the accuracy increases. This means that reduct feature sets are the best for building malware detection systems.

Table 13. Detection results based on permission.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	All Permissions	78	78	79	78
	Permissions Correlation	79	78	79	78
	Permissions Chi	79	79	79	79
	Permissions Reduct	80	79	79	80
K-Nearest Neighbor	All Permissions	77	77	79	78
	Permission Correlation	78	78	79	78
	Permissions Chi	80	81	78	80
	Permissions Reduct	82	81	82	79
Random Forest	All Permissions	82	84	80	82
	Permissions Correlation	82	84	80	82
	Permissions Chi	83	82	80	81
	Permissions Reduct	83	84	80	81
ANN	All Permissions	76	76	76	77
	Permission Correlation	78	78	79	78
	Permissions Chi	79	79	78	79
	Permissions Reduct	80	80	80	79
CNN	All Permissions	77	77	79	78
	Permission Correlation	78	78	79	78
	Permissions Chi	79	80	79	79
	Permissions Reduct	81	80	81	79
Logistic Regression	All Permissions	79	79	77	78
	Permissions Correlation	79	79	77	78
	Permissions Chi	79	80	78	79
	Permissions Reduct	80	80	77	79

Likewise, Table 14, Table 15 and Table 16 summarize the results for the three types of features, i.e., opcode feature, API call feature, and system command feature, respectively. The same phenomenon is observed in these three tables as was observed in Table 13, i.e., for each type of classifier, as the feature set is changed from all feature to feature correlation then to feature chi and finally to feature reduct, the accuracy increases, and training and testing time gets reduced drastically.

Table 14. Detection results based on opcode.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	All Opcodes	80	88	82	82
	Opcodes Correlation	80	75	87	82
	Opcodes Chi	81	75	87	81
	Opcodes Reduct	81	79	89	81
K-Nearest Neighbor	All Opcodes	84.50	86	83	84
	Opcodes Correlation	85	86	83	84
	Opcodes Chi	85	85	83	84
	Opcodes Reduct	85	85	83	84
Random Forest	All Opcodes	86	88	85	87
	Opcodes Correlation	86.80	88	86	87
	Opcode Chi	87	88	86	87
	Opcode Reduct	87	88	86	87
ANN	All Opcodes	78	77	86	81
	Opcodes Correlation	79	77	85	82
	Opcodes Chi	80	73	82	80
	Opcodes Reduct	79	73	83	78
CNN	All Opcodes	79	75	83	82
	Opcodes Correlation	80	74	85	80
	Opcodes Chi	80	74	84	78
	Opcodes Reduct	79	74	84	78
Logistic Regression	All Opcodes	79	76	86	81
	Opcodes Correlation	80	76	86	81
	Opcodes Chi	80	75	84	79
	Opcodes Reduct	80	74	85	79

Table 15. Detection results based on API calls.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	All API calls	84	83	88	85
	API calls Correlation	85	83	88	85
	API calls Chi	85	83	88	86
	API calls Reduct	86	85	89	83
K-Nearest Neighbor	All API calls	85	86	85	85
	API Calls Correlation	85.70	87	85	86
	API Calls Chi	86	87	85	86
	API Calls Reduct	86	87	84	86
Random Forest	All API Calls	88	90	88	90
	API Calls Correlation	89	88	90	88
	API Calls Chi	89	90	88	89
	API Calls Reduct	90	90	88	89
ANN	All API Calls	83	82	86	83
	API Calls Correlation	83	82	86	83
	API Calls Chi	83	82	86	83
	API Calls Reduct	84	81	86	83
CNN	All API Calls	84	82	87	84
	API Calls Correlation	84	82	87	84
	API Calls Chi	84	82	87	84
	API Calls Reduct	85	82	87	84
Logistic Regression	All API Calls	85	83	88	85
	API Calls Correlation	85	83	88	85
	API Calls Chi	85	83	88	85
	API Calls Reduct	86	83	88	85

Table 16. Detection results based on system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	All Sys cmd	62	59	86	70
	Sys cmd Correlation	62.50	59	86	70
	Sys cmd Chi	62.80	59	86	70
	Sys cmd Reduct	63	59	86	70
K-Nearest Neighbor	All Sys cmd	79	77	82	80
	Sys cmd Correlation	79	77	82	80
	Sys cmd Chi	79	77	83	80
	Sys cmd Reduct	79	77	83	80
Random Forest	All Sys cmd	82	81	85	83
	Sys cmd Correlation	82	81	86	83
	Sys cmd Chi	83	82	86	83
	Sys cmd Reduct	83	82	86	83
ANN	All Sys cmd	63	59	80	68
	Sys cmd Correlation	63	60	80	68
	Sys cmd Chi	64	60	81	70
	Sys cmd Reduct	64	60	81	71
CNN	All Sys cmd	64	60	81	70
	Sys Cmd Correlation	65	60	81	70
	Sys cmd Chi	65	62	82	70
	Sys cmd Reduct	65	61	82	71
Logistic Regression	All Sys cmd	65	61	82	70
	Sys cmd Correlation	65.13	61	82	70
	Sys cmd Chi	65.98	62	83	71
	Sys cmd Reduct	66	62	83	71

Table 13 shows that the Random Forest classifier with the permission reduct feature attains a maximum accuracy of 83% and emerges as the best performing model. Similarly, for Table 14, Table 15 and Table 16, the best models are Random Forest with opcode reduct having an accuracy of 87%, Random Forest with API calls reduct having an accuracy of 90%, and Random Forest with system command reduct having an accuracy of 83%. Among all the models mentioned in the above four tables, Random Forest with API calls reduct emerges as the best model.

4.3. Detection Results with Combinations of Two Features

Table 17 shows that Random Forest emerges as the best algorithm in terms of accuracy, precision, recall, and F1-score for permissions and opcodes reduct as the feature set.

Table 17. Detection results based on permissions and opcodes.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permission + Opcode Reduct	85	86	83	84
K-Nearest Neighbor	Permission + Opcode Reduct	87	88	86	86
Random Forest	Permission + Opcode Reduct	90	92	88	90
ANN	Permission + Opcode Reduct	82	83	82	82
CNN	Permission + Opcode Reduct	83	84	82	83
Logistic Regression	Permission + Opcode Reduct	84	85	83	84

Table 18 shows results of permission and API calls reduct as feature set used by SVM, K-nearest neighbour, Random Forest, and Logistic regression. Random Forest emerges as the best, with an accuracy of 92%.

Table 18. Detection results based on permissions and API calls.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permission + API calls Reduct	87	87	85	87
K-Nearest Neighbor	Permission + API calls Reduct	88	88	87	88
Random Forest	Permission + API calls Reduct	92	92	90	91
ANN	Permission + API calls Reduct	85	84	84	84
CNN	Permission + API calls Reduct	86	85	85	85
Logistic Regression	Permission + API calls Reduct	87	86	86	86

Table 19 shows that Random Forest with an accuracy of 88% is proved to be the best detection model among all the other three detection models using permissions and system command reduct as the feature set.

Table 19. Detection results based on permissions and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permission + Sys Cmd Reduct	83	84	81	83
K-Nearest Neighbor	Permission + Sys Cmd Reduct	84	84	84	84
Random Forest	Permission + Sys Cmd Reduct	88	91	85	88
ANN	Permissions + Sys Cmd Reduct	80	82	79	81
CNN	Permissions + Sys Cmd Reduct	81	83	80	82
Logistic Regression	Permission + Sys Cmd Reduct	82	84	81	83

Table 20 shows that the detection model with classifier as Random Forest and feature set as a combination of opcodes reduct and API calls reduct outperforms the other three detection models with an accuracy of 93%.

Table 20. Detection results based on opcodes and API calls.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Opcode + API call Reduct	88	88	86	88
K-Nearest Neighbor	Opcode + API call Reduct	90	89	88	89
Random Forest	Opcode + API call Reduct	93	93	92	93
ANN	Opcode + API call Reduct	86	85	85	86
CNN	Opcode + API call Reduct	87	86	86	87
Logistic Regression	Opcode + API call Reduct	88	87	87	88

Table 21 shows the detection results of the models that used opcode reduct and system command reduct as the feature set. The Random Forest classifier performed best with an accuracy of 90%.

Table 21. Detection results based on opcodes and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Opcode + Sys Cmd Reduct	84	85	82	84
K-Nearest Neighbor	Opcode + Sys Cmd Reduct	85	87	85	86
Random Forest	Opcode + Sys Cmd Reduct	90	90	88	89
ANN	Opcode + Sys Cmd Reduct	81	83	84	83
CNN	Opcode + Sys Cmd Reduct	82	84	85	84
Logistic Regression	Opcode + Sys Cmd Reduct	83	85	86	85

Table 22 shows that the detection model formed with the help of Random Forest as the classifier and API calls reduct and system command reduct as the feature set attains an accuracy of 91%, which is best among all the models in the table.

Table 22. Detection results based on API calls and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	API Call + Sys Cmd Reduct	85	86	84	86
K-Nearest Neighbor	API Call + Sys Cmd Reduct	86	88	86	87
Random Forest	API Call + Sys Cmd Reduct	91	91	88	90
ANN	API Call + Sys Cmd Reduct	82	84	86	83
CNN	API Call + Sys Cmd Reduct	83	85	87	84
Logistic Regression	API Call + Sys Cmd Reduct	84	86	88	85

4.4. Detection Results with Combinations of Three Features

Table 23 shows that when permission reduct, opcode reduct, and system command reduct are combined to form a single feature set, that feature set, when used with Random Forest, gives the highest accuracy of 95%.

Table 23. Detection results based on permissions, API calls, and opcodes.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	permissions + API Call + opcode + Reduct	90	90	88	89
K-Nearest Neighbor	permissions + API Call + opcode + Reduct	92	91	90	91
Random Forest	permissions + API Call + opcode + Reduct	95	94	93	95
ANN	permissions + API Call + opcode + Reduct	88	89	89	88
CNN	permissions + API Call + opcode + Reduct	90	91	90	91
Logistic Regression	permissions + API Call + opcode + Reduct	90	89	89	90

Table 24 shows that when permission reduct, opcode reduct, and system command reduct are combined to form a single feature set, that feature set, when used with Random Forest, gives the highest accuracy of 93%.

Table 24. Detection results based on permissions, API calls, and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permissions + API Call + Sys Cmd + Reduct	86	87	85	87
K-Nearest Neighbor	Permissions + API Call + Sys Cmd + Reduct	87	89	87	88
Random Forest	Permissions + API Call + Sys Cmd + Reduct	93	92	90	92
ANN	Permissions + API Call + Sys Cmd + Reduct	84	85	84	84
CNN	Permissions + API Call + Sys Cmd + Reduct	85	87	87	85
Logistic Regression	Permissions + API Call + Sys Cmd + Reduct	85	87	88	86

Table 25 shows that when permission reduct, opcode reduct, and system command reduct are combined to form a single feature set, that feature set, when used with Random Forest, gives the highest accuracy of 93%.

Table 25. Detection results based on permissions, opcodes, and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permission + Opcode + Sys Cmd + Reduct	86	87	83	85
K-Nearest Neighbor	Permission + Opcode + Sys Cmd + Reduct	87	87	86	87
Random Forest	Permission + Opcode + Sys Cmd + Reduct	93	92	89	91
ANN	Permission + Opcode + Sys Cmd + Reduct	84	86	86	86
CNN	Permission + Opcode + Sys Cmd + Reduct	84	86	86	86
Logistic Regression	Permission + Opcode + Sys Cmd + Reduct	84	86	86	86

Table 26 shows combining the opcodes, API calls, and system command reducts and applying all four classifiers the detection model with the Random Forest as the classifier is best among all, with an accuracy of 94%.

Table 26. Detection results based on opcodes, API calls, and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Opcode + API Call + Sys Cmd Reduct	90	91	88	90
K-Nearest Neighbor	Opcode + API Call + Sys Cmd Reduct	92	90	90	91
Random Forest	Opcode + API Call + Sys Cmd Reduct	94	94	93	94
ANN	Opcode + API Call + Sys Cmd Reduct	87	87	86	87
CNN	Opcode + API Call + Sys Cmd Reduct	88	88	87	88
Logistic Regression	Opcode + API Call + Sys Cmd Reduct	89	88	88	89

4.5. Detection Results with Combinations of all Four Features

Table 27 shows that all the feature set reducts, i.e., permissions, opcodes, API calls, and system commands reducts, used together with Random Forest emerge as the best classifier, with an accuracy of 97%.

Table 27. Detection results based on permissions, opcodes, API calls, and system commands.

Classifier	Feature Set Used	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
SVM	Permissions + Opcode + API Call + Sys Cmd Reduct	92	91	90	91
K-Nearest Neighbor	Permissions + Opcode + API Call + Sys Cmd Reduct	93	93	92	92
Random Forest	Permissions + Opcode + API Call + Sys Cmd Reduct	97	95	95	95
ANN	Permissions + Opcode + API Call + Sys Cmd Reduct	89	88	87	89
CNN	Permissions + Opcode + API Call + Sys Cmd Reduct	90	89	88	89
Logistic Regression	Permissions + Opcode + API Call + Sys Cmd Reduct	91	90	89	91

4.6. Discussion and Findings

In this subsection, we summarize the reasoning behind the detection results achieved from the proposed model. The proposed model gives us the highest accuracy of 97% with all four features. We observe that the detection accuracy significantly improves when we combine all four types of features for detection. The reason behind this observation is that different categories of features capture different behavioral aspect of malicious application. Hence, combining different types of features gives us wholesome characteristics of a malicious application under consideration. Therefore, increasing the number of features in combinations helps to improve the overall accuracy.

Secondly, we observed that API calls give us better results as compared to other features individually. Malicious software developers might try to avoid being detected by obscuring their code. Nevertheless, concealing the need for specific API calls is challenging. Identifying these calls can aid in the identification of malware that is intentionally concealed. Hence, results with API calls are better when compared to other features.

Thirdly, Random Forest gives us the better results when compared to other classifiers. The reason lies in the fact that Random Forest is a technique that employs a collection of decision trees to formulate predictions. This method of ensembling is beneficial for mitigating the variance and overfitting risks inherent in individual decision trees. Through the consolidation of predictions from numerous trees, there is a consistent enhancement in overall performance.

Fourthly, we can combine two types of feature sets out of permissions, opcodes, API calls, and system commands in six ways. We experimented on all these six combinations and observed that opcodes and API calls combinations give the highest accuracy among all the six types of combinations. The reason seems to be obvious from the fact that opcodes constitute low-level instructions executed by a processor. In the realm of Android malware detection, scrutinizing the sequence of opcodes within an app’s code can unveil discernible patterns suggestive of malicious behavior. Simultaneously, examining the app’s API calls offers insights into its conduct. Specific API calls may serve as markers for malicious activities, and analyzing their patterns can assist in identifying malware. Consequently, the amalgamation of opcodes and API examines a more detailed perspective on an app’s behavior at the code level. This approach proves advantageous for pinpointing nuanced and sophisticated malware that may employ obfuscation techniques. In contrast, permissions offer a higher-level overview based on declared capabilities, potentially offering less specificity.

Similarly, we combined all these four features in the group of three. The total number of combinations possible are four. Experimenting with all these four combination establishes that combining permissions, opcodes, and API calls is best among them. The reason seem to be that permissions offer insights into an app’s officially declared capabilities. Integrating permissions with opcodes and API calls enhances our comprehension of an app’s intended functionality and the possibility of misuse. Specific combinations of permissions can act as early indicators of potential issues, even before delving into the details of code execution. While opcodes and API calls provide a granular view of an app’s behavior at the code level, incorporating permissions into the analysis contributes to a broader context, fostering a more comprehensive understanding of an app’s intentions and the associated risks.

4.7. Comparison with Other Related Work

We conducted a thorough comparison between the detection outcomes achieved by our suggested approach and those of other studies found in the existing literature regarding the detection of Android malware. We implemented several other state-of-the-art techniques on our data sets and to facilitate this comparison; we present a concise summary of the findings in Table 28, which encompasses the results obtained by various works that have utilized certain or all components of the manifest file for detection purposes. By examining these results, it becomes evident that our proposed methodology surpasses all of the aforementioned related works in terms of detection accuracy, signifying its superior performance in comparison to existing approaches.

Table 28. Comparison of proposed model with related works.

Detection Technique	Feature Set Used	Detection Accuracy	No. of Applications	Feature Ranking Method	Feature Selection Method (%)
SIGPID [8]	Permissions	92	5494 malicious & 310,926 benign apps	Negative rate & support	Sequential Forward Selection (SFS) & Principal Component Analysis (PCA).
PermPair [9]	Permissions	94.60	5993 benign & 7533 malicious applications	Ranked Permission-pairs	Not Used
Alazab et al. [51]	Permissions and API Calls	94.22	14,172 Benign & 13,719 Malicious Application	No ranking done	Not used
Urooj et al. [52]	Permissions, API Calls and other manifest components	96.40	50,000 Benign & 50,000 Malicious Applications	No ranking done	Not used
Zhu et al. [53]	Permissions, API Calls and hardware components	96	1061 Benign & 2126 Malicious Applications	No ranking done	Not used
Firdaus et al. [34]	Java Code and Permissions	94.20	5555 Malicious & 550 Begin	No Ranking Done	Genetic Search
DREBIN [31]	Manifest File Components & Dis ambled Java code	95	123,452 benign & 5560 malicious applications	no ranking done	Not used
Proposed Approach	Permissions, Opcode, API Calls, and System Calls	97	15,000 benign & 15,000 malicious	Rough Set based Ranking	Rough Set Reduct

4.8. Limitations

The work performed in this research paper is based on static analysis. Static Android malware analysis has shortcomings, such as not capturing the run time behavior of applications like data leakage and network communications. Due to obfuscation techniques employed by malware writers, static analysis may not be able to capture the true intention of the code. With these limitations in the picture, static analysis may miss the malicious behaviour of Android applications, which may show its actual hostile conduct at run time.

Additionally, the current proposed model is an off-device model, and hence it can not be installed on smartphones for real-time detection.

5. Conclusions and Future Scope

In this work, we have proposed a novel Android malware detection model based on rough set theory. We have considered the combination of four static features, namely, permissions, opcodes, API calls, and system commands. Initially, a data pre-processing stage was executed, during which correlated features, as well as features that exhibited no dependence on the class variable, were eliminated. A ranking score was computed to establish the significance of each feature by employing the concept of Discernibility Matrices from rough set theory. Subsequently, an algorithm for computing rough set reducts was employed to reduce the number of features within each category based on the ranking score and the Discernibility Matrix concept of rough set theory. Following this reduction step, machine learning algorithms were applied to assess the detection accuracy using the calculated reducts. To gauge the effectiveness of the proposed model, a comparison was drawn against other advanced detection techniques. The results of this comparison underscored the superior performance of the proposed model over other state-of-the-art models in the field.

In our future work, we will try to work on the limitations of static analysis, i.e, we will be using dynamic analysis techniques along with static analysis techniques to build hybrid malware detection methods. Currently, the proposed model is an off-device model, and hence it can not be installed on smartphones for real-time detection. In future, we will propose a client–server-based model to integrate in smartphones.