Feature Selection for Android Malware Detection with Random Forest on Smartphones

To do research in the area of Android security, we'll need to gather a set of features that Android apps have to analyze. The author grouped related studies into groups based on the type of features used in their studies.

2.1 Studies based on static features

Many researchers have developed and implemented their own tools for extracting features from Android apps.  In 2019, Kapoor et al. [10] presented a method for the classification of Android applications based on permissions. The proposed system collects data from many sources. Benign samples are collected from the Google Play store while the malware samples are collected from different websites like virus share and zeltser. They have developed a Python script to extract static features (permissions) and save them in a CSV file. In 2020, Bibi et al. [11] proposed a deep learning model based on Gated Recurrent Unit GRU for the detection of malicious applications in the Android system. The proposed model can classify applications into benign, backdoor, and Trojans. The authors collected samples from AMD and Androzoo datasets. A Python script was developed to extract useful information and generate feature vectors from a manifest file. The developed script thoroughly analyses the manifest file and extracts many features like permissions, API calls, and intents. In 2020, Sirisha et al. [12] suggested a sequential neural network model in order to predict the presence of malware in Android APK files received from the web or play store. The dataset consisting of 398 APK files having 331 features was used for training the model in the proposed model. During the test, the neural network model will be tested using data from the Android play store as well as malicious sites, such as Droidbench, which includes malicious and benign APK files. The permissions were extracted from the APK file by using the Androguard tool. In 2019, Hr [13] developed a fully connected deep-learning model for detecting malicious applications. Benign data samples are collected from the Google Play store, while the malware samples are collected from the virus share repository. The Androguard tool was used for analyzing APK files to extract permissions from the application, and the random forest was used for feature selection. In 2018, Koli [14], presented the RanDroid method that uses several machine learning algorithms like random forest, naive Bayes, support vector machine, and decision tree for classifying malware applications. The RanDroid method depends on many features, such as API calls and requested permissions, along with other application features such as reflection and native code. The researchers used the Androguard static analysis tool to extract features like permissions and API calls. In 2020, Alsoghyer and Almomani [15] presented a model that deeply analyzed the extracted permissions that enabled them to differentiate ransomware from benign applications on the Android device. The important permissions are used and are comparable between ransomware and benign applications. The presented study takes a proactive approach to identifying ransomware before damaging the device. The present work used the APK tool to decompile APK files and then extract features. In 2018, Zhao et al. [16] suggested a deep neural network-based mobile Android malware detection system that employs optimized deep neural networks to learn from opcode sequences to detect malicious code. With the proposed method, the optimized CNN was trained several times on the operation code (Opcode) sequence extracted from the Android app after the de-compilation process by the APK tool. Opcodes represent specific instructions that the Android runtime executes to perform various tasks within the app. The suggested model collected data from many sources, such as Drebin for malicious applications and many Chinese app markets for benign applications. In 2019, Ma et al. [17] presented an ensemble model that detects malware applications based on the machine learning algorithms. The proposed model constructs a control flow graph from the source code after the application is de-compiled by using the flowdroid framework, then extracts API calls from the control flow graph and builds three datasets. In 2022, Kumar et al. [18] introduces a methodology for malware detection in Android applications by extracting features such as permissions, intent filters, activities, and services from the manifest file. The androguard utility is employed to disassemble the code and identify suspicious API calls from the dex code. To improve retrieval efficiency, the extracted features are serialized in feather data format. Finally, the XGBoost algorithm is utilized for effective malware detection.

In this section of the related works, it is observed that both the APK tool and the Androguard tool have been utilized in most studies for the analysis of Android apps. The APK tool is developed in the Java language used for reverse engineering Android apps. It has the capability to decode Android apps and create decompiled resources, encompassing components like the manifest and smali files. Androguard is a Python-based reverse engineering tool for Android apps, possesses the ability to decode resources and additionally perform bytecode disassembly to convert them into Java source code [19]. The APK tool lacks built-in functions or APIs for feature extraction. Researchers utilizing this tool need to develop their own programs to extract features from files extracted from Android apps. In contrast, the Androguard tool provides functions to directly extract static features from files derived from Android apps. Both the APK tool and the Androguard tool only support static features.

2.2 Studies based on dynamic features

In 2018, Feng et al. [20] developed an approach that depends on a dynamic analysis called EnDroid for detecting malware apps based on multiple dynamic features. For feature extraction, the authors used Droidbox and the strace tool to extract dynamic features such as network traffic, file operations, and system calls from the executing app in the emulator. Based on these features, the developed method can achieve an accuracy of 96.32%. In 2019, Esmaeili and Shahriari [21] proposed a method named PODBot for detecting mobile phone botnets that utilize both network and host-based metrics. The detection is based on application features like permissions, APIs, and network traffic analysis. Androguard and MobSF tools were used to perform analysis. In 2020, Lê et al. [22] proposed a method of machine learning to identify Android malware apps. The features that are used to train machine learning are built based on the behavior, requisite permissions, and other features of malicious applications extracted by the Dexdump tool. In 2018, Kumar et al. [23] proposed a framework for machine learning (ML) to counter mobile threats rapidly. The model depends on the network's flow-based features. The proposed model utilizes 40 time-based network traffic features derived from malicious and benign apps in real time. The Cuckoo sandbox and the Anubis sandbox are publicly available and were used to generate network traffic. In 2023, Manzil and Naik [24] introduced a novel approach for generating feature vectors by employing Huffman encoding. The experimental findings demonstrate that this innovative strategy significantly improves the effectiveness of the malware detection model. By extracting dynamic behavior patterns of malware through the utilization of system call frequencies as features, the proposed method contributes to the detection process. The performance of the model is evaluated by applying deep learning and machine learning techniques. In 2020, Mahdavifar et al. [25] introduced a simple and effective Android classification framework for malware on the basis of mining system-call dynamically observed behaviors. The authors depended on the CopperDroid virtual machine to extract dynamic features like system calls. The framework is built on a deep neural network that uses a semi-supervised technique to input behaviors that are dynamically observed and that allows the classification of the categories of malware.

2.3 Studies based on hybrid features

In 2018, Arora and Peddoju [26] introduced a hybrid system for detecting malware, named NTPDroid. This system effectively combines network traffic features and permissions extracted from applications. The approach employed the FP-Growth technique to identify prevalent patterns present in both malicious and benign datasets. The author utilize APK tool to extract static features.  Importantly, the results indicated that integrating network traffic features with permissions resulted in improved detection rates, surpassing the efficacy of using either network traffic features or permissions in isolation. In 2019, Garg and Baliyans [27] suggested an ensemble approach comprising a number of algorithms, including support vector machine, multilayer perceptron, ripple down rule learner, and rule-based classification tree. This ensemble model works concurrently to create a resilient framework capable of accurately and efficiently distinguishing between benign and malware. The author employed many tools to extract features such as the APK tool, ADB, and strace tools. The extraction process involves capturing an array of static and dynamic attributes from applications and devices, encompassing API calls, permissions, and system components, network traffic, and battery usage. Experimental outcomes demonstrated exceptional performance, with the proposed system achieving an impressive accuracy level of 98.27%.

Upon reviewing the related works, the author observed that the previous works mainly focused on the accuracy of the models or developing new methods for Android malware detection, with less attention given to the complexities associated with the extraction of features. Several of the developed models have demonstrated promising results; however, when subjected to testing on mobile devices, they may encounter challenges in acquiring features from the installed applications. This can potentially impact the overall device's performance. Therefore, the main aim of this study is to analyze Android applications and extract features from many sources to get lightweight features that achieve high accuracy with less computation on mobile devices.

Figure 2 depicts the framework of the Android malicious detection system. The system employed many types of features obtained from various sources, and many datasets (DS) are built based on a single feature category and a possible combination of two feature categories to identify the optimal feature sets suitable for devices with limited resources, such as smartphones. This approach aimed to effectively detect applications exhibiting malicious behavior while considering the constraints imposed by resource-constrained devices.

22.png

4.1 Collecting samples

Numerous resources provide Android app samples specifically intended for research purposes. For the present study, 500 samples of malware were gathered from diverse databases, namely Drebin (https://www.sec.tu-bs.de/~danarp/drebin/), CICMalDroid 2020 (https://www.unb.ca/cic/datasets/maldroid-2020.html), the Android Botnet dataset (https://www.unb.ca/cic/datasets/android-botnet.html), and Malware Bazaar (https://bazaar.abuse.ch/browse/tag/apk/). For benign apps, this study collects samples from Google Play (https://play.google.com/store/apps), and the AndroZoo databases (https://androzoo.uni.lu/).

4.2 SDHFE tool

Most researchers analyze Android applications for security purposes to determine whether the application is malware or benign. Therefore, researchers are looking for a tool that helps them analyze mobile applications and extract the essential features. Many reverse engineering tools on the market can perform static and dynamic analyses of Android APK files. Still, no supporting tools that offer three fundamental analyses (static, dynamic, and hybrid) and have the capability to automatically extract features from a bulk of APK files without the need for human intervention during the analysis process. This paper presents the development of the SDHFE tool, a comprehensive solution offering three distinct analysis modes. The SDHFE tool is a lightweight and automated tool, developed using shell script programming. It relies on essential libraries like AXMLPrinter and Baksmali. This tool is designed to the extraction of features and enable the analysis of a large number of APK files within a short time frame without the need for human intervention. Figure 3 shows the general mechanism of the SDHFE tool.

3.png

Figure 3. Overview of the SDHFE tool's organizational structure

4.3 Feature set extraction

This study involves the analysis of 1000 Android apps, which are evenly distributed between malware and benign applications. Our emphasis centers on permissions, intents, API calls, system calls, and possible combinations of two feature categories. The analysis is conducted using the SDHFE tool.

4.3.1 Feature sets extracted from the manifest file

Permissions and intent filters are important features in the Android manifest file that govern access to devise resources and define how the application interacts with other components. However, these features are susceptible to exploitation by malicious applications. For instance, the android. permission.SEND_SMS permission is commonly utilized in benign applications for sending and receiving SMS messages, it can be maliciously employed to send unauthorized premium-rate messages or utilized in phishing attacks, where deceptive SMS messages containing malicious links or requests for sensitive information are sent. Another exploit involves a malicious app registering itself to receive the "android.intent.action.PHONE_STATE" intent, enabling it to eavesdrop on phone conversations. This unauthorized access grants the app the ability to obtain call-related information, such as phone numbers, call durations, and even the audio content of the calls. Figure 4 illustrates the pseudocode algorithm for extracting permissions and intents, as well as generating profiles for applications by the SDHFE tool.

34.png

Figure 4. Generating profiles for APK files based on permissions and intents

The process of analyzing and extracting features from a manifest file is relatively fast and lightweight as the manifest file is typically small. Figure 5 depicts the steps of deriving features from an app using the SDHFE tool, which involves parsing the structured XML data present within the manifest file, resulting in the retrieval of crucial information.

4.png

Figure 5. Process of sample analysis and feature extraction from the manifest file

4.3.2 Feature sets extracted from the source code

Source code analysis provides deep insight into the inner workings of an Android application. By examining the source code, security analysts can understand how the app functions, accesses sensitive data, communicates with external services, and handles user inputs. The most important features in the source code are API calls. Malicious applications often incorporate API calls that enable unauthorized access to sensitive information or smartphone resources. A malicious app can exploit a certain API call to perform some action without user consent, such as getDeviceId(), getSubscriberId(), and getNetworkOperator(), from the telephony manager class. These APIs provide access to sensitive device information of the user and can lead to privacy breaches and unauthorized data collection. Another prominent API call that malware app developers frequently used is the sendTextMessage() method. This API is intended for sending SMS messages programmatically, but its misuse can lead to various malicious activities. The SDHFE tool plays a crucial role in identifying and extracting these API calls from the source code. Figure 6 provides an illustrative pseudocode algorithm that outlines the process of extracting API calls and generating profiles for applications using the SDHFE tool.

Extracting features from the source code (classes.dex file) after converting it into smali files demands more time and computational resources compared to extracting features from manifest files. This conversion process involves creating multiple folders and smali files that mirror the package structure of the Android application. The number of folders and smali files created varies based on the complexity and size of the Android application. The procedure of extracting API calls from a class.dex by the SDHFE tool is depicted in Figure 7.

6.png

Figure 6. Generating profiles for APK files based on API calls

7.png

8.png

4.4 Preparing dataset

For each feature set discussed in the preceding section, a feature vector is generated for every application using a Python program specifically developed by the author for this purpose. This program is responsible for producing a file in the Comma-Separated Values (CSV) format, wherein the feature names are arranged as columns and their respective values are recorded as rows. To accomplish this, the program employs a one-dimensional array to store the names of the columns. During execution, the Python program compares the elements of the array with each line of the application's profile. If a feature name is found within the profile, the corresponding value in the array is replaced with 1 in the case of the feature type belonging to (permission, intent, API call). However, if the feature type corresponds to system calls, the value in the array is replaced with its frequency call. Conversely, if a feature name does not match, the value is replaced with 0. Subsequently, the feature vector of the application is appended to the CSV file. This process is repeated for all applications.

4.5 Mutual information

For feature selection, we employed the mutual information feature selection algorithm. The mutual information between feature F and class C can be employed to quantify their level of relevance.

$M I(F, C)=\sum_{f_i} \sum_{c_j} p\left(F=f_i, C=c_j\right) * \log \frac{p\left(F=f_i, C=c_j\right)}{p\left(F=f_i\right) * p\left(C=c_j\right)}$                         (1)

where, P(C = cj) is the frequency count of class C with value cj, P(F = fi) is the frequency count of feature F with value fi, and P(F = fi, C = cj) is the frequency count of F with value fi in class cj. The values of the class are 0 or 1, where 0 indicates a benign sample and 1 indicates a malware sample. And feature values (boolean for permissions, intents, and API; frequency count for system calls). The mutual information is a non-negative value ranging between 0 and 1. A mutual information value of 1 indicates a strong correlation between the feature and the class, while a value of 0 signifies no correlation between the feature and the class.

The findings of this study can be categorized into two parts. The initial part primarily centers on examining the time and complexity necessary to extract each specific type of feature. The process of extracting features from the Manifest file generally entails parsing the XML structure and retrieving significant information. This procedure is typically lightweight and computationally efficient due to the Manifest file's small size and uncomplicated nature. While extracting features from source code requires converting the class.dex file into smali files. This process demands more time due to the following reasons:

1. Smali files contain low-level bytecode representations of the app's source code. Decompiling and analyzing bytecode is inherently more complex and resource-intensive than parsing structured XML data.
2. Extracting features from multiple smali files requires additional processing time and computational resources.

Figures 5 and 7 also confirm that the process of extracting features from the source code is more complicated than from the manifest file. The obtained results in Table 3 as well support the fact that the permission and intent features from the manifest file need less time than API calls from the source code. The computational effort required for analyzing system calls can vary based on factors such as app execution duration, the number of system calls made, and the complexity of the interactions. Profiling dynamic features (system calls) can potentially be more computationally intensive than compared to profiling static features due to the reasons mentioned in Section 4.3.3.

The second part of the study focuses on machine learning models. Actually, the author evaluate each model by many metrics including accuracy, precision, recall, and F1 score. The accuracy provides an overall measure of correct predictions across all classes. The recall emphasizes the ability to capture positive instances; this metric is useful when missing positive cases has serious consequences, minimizing false negatives. Precision focuses on the accuracy of positive predictions, minimizing false positives. F1 scores strike a balance between precision and recall. In this study, the positive class represents malware samples, and the negative class represents benign samples. The accuracy of the overall model is very important. However, it needs to check the value of other metrics, especially recall, which focuses on the rate of detecting malware samples. During experiments, certain models demonstrated 100% accuracy during the training phase. Nevertheless, their performance in the testing phase was less reliable, particularly in detecting malware samples. For example, models 8 and 9 exhibited lower recall scores in the testing phase, which means these models produce a lower true positive rate. Model 7, which was trained using APIs and intents features, attained a notably lower average score. Similarly, models 2, 8 and 9, trained on intents and the combination of (permissions and system calls) and (API calls and system calls) respectively, also exhibited comparatively lower performance. This is an indicator of a weak relationship between features. Some models got acceptable average test scores, such as models 1, 6, and 10. However, based on the results presented in Table 5, it is evident that model 5, which combines permissions and intents, achieved notably higher average scores during the testing phase.

Another metric called AUC-ROC curve was utilized to visually represent the performance of all models on a single curve. Figure 15 demonstrates that models 5 and 6 achieved higher AUC scores, which are 99%, indicating superior performance. However, considering the results in Table 3, the feature extraction process for model 5 requires less time compared to model 6. Actually, permissions and intents are closely related. An app might require specific permissions to perform certain actions triggered by intents. For example, the Banking Trojan application is appeared as a legitimate banking application for users but is designed to steal sensitive user information, such as login credentials and financial data. This example will illustrate how the permissions with intents feature sets might be strongly related. The malicious app requests permission to access SMS (android.permissions.RECEIVE_SMS) and contacts (android.permissions.READ_CONTACTS). The app registers an intent filter to intercept incoming SMS messages containing keywords related to banking transactions or authentication codes. It uses intercepted SMS data to extract sensitive information and send it to a remote server.

Overall, model 5, which combines permissions and intents, is the optimal feature set based on the majority of criteria employed in this study for real-time malware detection on smartphones. However, like any other machine learning model, this model can have weaknesses. The possible weakness of this model appears when both malware and benign apps utilize similar permissions and intents. This might increase the risk of false positives and false negatives, flagging benign apps as malware and flagging malware as benign.