# Op2Vec: An Opcode Embedding Technique and Dataset Design for End-to-End Detection of Android Malware

Authors: Kaleem Nawaz Khan; Najeeb Ullah; Sikandar Ali; Muhammad Salman Khan; Mohammad Nauman; Anwar Ghani
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Android is one of the leading operating systems for smartphones in terms of market share and usage. Unfortunately, it is also an appealing target for attackers to compromise its security through malicious applications. To tackle this issue, domain experts and researchers are trying different techniques to stop such attacks. All the attempts of securing the Android platform are somewhat successful. However, existing detection techniques have severe shortcomings, including the cumbersome process of feature engineering. Designing representative features require expert domain knowledge. There is a need for minimizing human experts’ intervention by circumventing handcrafted feature engineering. Deep learning could be exploited by extracting deep features automatically. Previous work has shown that operational codes (opcodes) of executables provide key information to be used with deep learning models for the detection process of malicious applications. The only challenge is to feed opcodes information to deep learning models. Existing techniques use one-hot encoding to tackle the challenge. However, the one-hot encoding scheme has severe limitations. In this paper, we introduce (1) a novel technique for opcodes embedding, which we name Op2Vec, and (2) based on the learned Op2Vec, we have developed a dataset for end-to-end detection of Android malware. Introducing the end-to-end Android malware detection technique avoids expert-intensive handcrafted feature extraction and ensures automation. Some of the recent deep learning-based techniques showed significantly improved results when tested with the proposed approach and achieved an average detection accuracy of 97.47%, precision of 0.976, andF1 score of 0.979.


---

## Body

## 1. Introduction

Mobile technology has shown exponential growth in the recent past. Mobile devices are the best source to manage our day-to-day communications. These mobiles accompany us in all our movements. The use of these devices allows us to handle most of our very important activities, social networking, payments, and banking, with ease. Due to the high growth rate, mobile platforms are highly targeted and severely infected with malicious applications [1]. Attackers look for the possibility of exploiting mobile platforms through various techniques. There are cybercriminals as well as hackers, sponsored by states, doing research in order to find schemes for possible attacks against mobile platforms for their better interest. According to International Data Corporation (IDC) [2], mobiles have surpassed PCs in terms of preferred devices that can be used to access the Internet and other possible services. IDC also states that the number of mobile users will cross the 91 million mark over the coming four years.Malware is a short form used for malicious software. It is a program or software on any system that is not intentionally installed by the end-user or system administrator. There are various types of malware for different tasks and purposes [3]. The behavior of malware can range from being a very simple piece of annoyance, such as pop-up advertisements to severe actions which may be much more damaging and harmful [4], such as stealing important systems’ passwords or secret data and other more severe actions. They may be used for infecting other machines having very confidential and secret information, over the network [5].Among mobile platforms, Android is one of the most prevalent platforms for smartphones nowadays. It has seen exponential growth with a market share of 82.6% and has several millions of mobile applications in various markets [2]. It is a very rich platform in terms of the availability of various functionalities to its users. Unfortunately, it has been observed that smartphones with the Android operating system are targeted more often than any other platform by security attackers [4], and it is very severely infected by malicious software. Unlike other mobile platforms, Android allows easily installing applications from sources without clear verification, such as third-party markets, whose sole purpose is to bundle and distribute mobile applications with malwares, assisting attackers in different kind of tasks [6]. According to a report [7], the number of Android malicious applications will cross 3.8 million mark at the end of this year. Keeping this evidence in mind, there is a need for techniques and solutions to limit the production of malwares on different Android markets. Large body of research is involved to overcome the situation [8, 9]. Researchers are trying to find out smart ways for automated detection of malicious applications.Android applications can be analyzed in two ways: either performing static analysis [10] or dynamic analysis [11]. In static analysis, the application is studied in its static position. Its behaviors, i.e., code patterns, requested permissions, relationships with other applications, intent filters, and other features, are analyzed. On the other hand, in dynamic analysis, the application is studied and analyzed during its running state. Dynamic aspects, such as observation of system calls, dynamic loading of the code segment, and invocations of API calls, are analyzed. Dynamic analysis is performed mostly in a controlled environment that is named a sandbox [12]. All the relevant operations of the state of the execution are monitored, such as sending SMS messages, storage reading, and connection to remote servers.The conventional Android malware detection pipeline is to take Android applications and uses domain expertise to extract handcrafted features from a set of applications. Dynamic and static features are extracted for dynamic and static analyses, respectively. The features are then used to train machine learning algorithms to produce trained models to classify and detect Android malware. Common classifiers used for Android malware detection are support vector machine (SVM), decision tree (DT),k-nearest neighbors (KNN), random forest (RF), neural networks (NN), and k-means clustering. Recently, deep neural networks are getting attention for Android malware detection. Studies such as Droid-Sec [13], DeepDetector [14, 15], and [16] are using a deep learning approach to detect Android malware. Unlike handcrafted feature extraction for conventional machine learning algorithms, deep learning has a very strong and unique approach to automatically extract deep features and learn classification patterns.All the conventional machine learning and the deep learning techniques studied in the existing literature work well with reasonable accuracy, but the problem is that these techniques rely on engineered handcrafted features. Even the deep learning techniques are trained with handcrafted features. Features engineering is a cumbersome and a very lengthy process, which requires domain knowledge. The feature engineering process is depicted in Figure1. Domain knowledge and domain experts are required to perform brainstorming of features to decide what features to create. The created features are then tested with the experimentation model. Features are tuned where required and the complete feature engineering cycle is repeated if necessary. In most cases, malware designers are required to design the representative features. The domain experts and the available known malware designers are limited in number. That is why there is a need for making a system that can replace this lengthy and cumbersome features engineering process and incorporate end-to-end learning. The major problem is that we do not have any dataset publicly available for deep learning algorithms to learn end-to-end, i.e., extract deep features instead of designing handcrafted features. In end-to-end learning, the algorithm learns deep features instead of taking engineered features. So, the gap in the current research is to develop a dataset for end-to-end learning of Android malware and allow deep learning algorithms to be trained on the dataset and detect Android malware with minimum human expert intervention. Another problem in the existing solutions is that they use one-hot encoding to feed information to deep learning models. One-hot encoding creates severe problems and sometimes it becomes infeasible to be used with deep learning techniques. These limitations are discussed in detail in the coming sections. We need to devise an alternative that outperforms one-hot encoding.Figure 1
Features engineering process.Our first contribution concerns the development of a novel dataset for end-to-end detection of Android malware. The dataset can be used to learn useful patterns and information from the Android source code. We have not only developed the dataset but have also presented the design process and techniques involved in the dataset development. End-to-end learning minimizes human experts’ intervention in designing/developing representative features and circumventing the handcrafted feature extraction process. The second contribution of this study is learning Op2Vec. Op2Vec learning process employs a machine-learning algorithm to learn meaningful vector representations from opcodes of Android source files. All the limitations of existing embedding techniques motivated us to develop a novel encoding technique which we term “Op2Vec.” After learning Op2Vec and dataset development, we also validate the dataset by feeding it to a deep neural network. Based on the above discussions, the main contributions are summarized as follows:(1)
Op2Vec for learning opcode-vector embedding(2)
Development of a dataset for end-to-end learning based on learned Op2Vec embedding and feeding the developed dataset to deep learning models for learning patterns and insights (circumventing feature engineering)In this section, after a detailed introduction to the problem area and different techniques, the relevant background of Android malware detection and motivation for the proposed approach is discussed in Section2. Section 2 focuses on malware detection techniques along with details of machine learning models, more importantly, a brief introduction, and the working paradigm of deep learning. Moreover, in the last part of the section, the word embeddings technique, its specifications, and its relevance to our novel Op2Vec technique are discussed. In Section 3, the methods of our research and the subtasks of the proposed approach are listed along with a brief discussion; more importantly, the word embedding model, skip-gram, is presented in depth with its working fashion. Section 4 discusses the experiments performed and the results of the experiments along with a detailed analysis. This section also covers how to use the designed dataset with deep neural networks for end-to-end learning. Section 5 provides a comparison of our proposed dataset with other state-of-the-art datasets and discusses how the use of Op2Vec makes it better than existing datasets. Section 6 concludes the paper and provides further extensions in this part of the research.


## 2. Background and Motivation

### 2.1. Android Malware Analysis

Due to the severity of Android malware, there are hundreds of approaches for its detection and classification. One approach is to perform a static analysis of the Android application. In static analysis, the executable code of the Android applications is examined to determine the data flow, control, and representative pattern without running the executables. Another approach is to examine an Android application through dynamic analysis. In dynamic analysis, the execution of an application is monitored by inspecting execution behaviors. Both static and dynamic analysis studies are discussed in the next two subsections.


### 2.2. Dynamic Analysis Techniques for Android Malware

Due to the complexity of dynamic analysis, there are very few techniques for conducting dynamic analysis for Android malware detection. A very popular technique is DroidScope [17]. It is an Android malicious applications’ analysis engine, based on emulation, which performs dynamic analysis of Android applications. Its specialty is to reconstruct both OS and Java level semantics seamlessly and simultaneously. Riskranker [18] is another approach that ensures accurate and very scalable detection of zero-day Android malware. It dynamically analyzes whether a particular application exhibits dangerous behavior. Another similar technique DroidRanger [19] performs a behavioral footprinting scheme, based on requested permissions, for the detection of new samples of unseen Android malware families, and later applies a heuristics-based filtering approach for the identification of certain inherent behaviors of unseen malware application families.Android malware detection is based on system calls [20], where automatic classification is performed based on tracking system calls. DroidScribe [21] is a very recent approach that focuses on dynamic analysis, i.e., runtime behavior. This approach shows how machine learning algorithms can be used to automatically classify Android malware into different malware families by just observing their runtime behavior. It observes that, on Android systems, system calls solely do not provide sufficient semantic content to make classification; that is why it also uses a lightweight VM introspection to reconstruct interprocess communication on the Android system for effective analysis. All the discussed techniques in this section have used engineered handcrafted features which are specifically designed for dynamic analysis.


### 2.3. Static Analysis Techniques for Android Malware

Static analysis is relatively simple and scalable. There are several techniques that use static analysis for Android malware detection. A set of static features is designed using domain expertise. The features are then utilized for the detection of Android malware. An approach, DroidAPIMiner [22], statically mines API-level features for the robust detection of malware on Android systems. It aims to provide a lightweight and robust classifier in order to evade Android malware installation. Another similar technique Droidminer [23] uses a behavioral graph to embed abstract malware program logic into a sequence of threat patterns and then applies machine learning techniques to identify and label elements of the graph that match already extracted threat modalities. A semantic-based technique [24] is responsible for the classification of Android malware through dependency graphs. It extracts a dependency graph, i.e., a weighted contextual API graph, as program semantics for the construction of feature sets. Another study reveals that malicious application treats sensitive data differently from benign applications. This feature is used to design a useful technique [25] for the identification of malware applications. Benign Android applications are mined for their data flow from sensitive sources, and then, these flows are compared against those, found in malicious applications, to detect similarities.DREBIN [26] is a lightweight method for Android malware detection. It enables the identification of malware applications on smartphones directly. It extracts as many features of an Android application as possible, and later, the extracted features are embedded into a joint vector space in such a fashion that typical patterns, which are indicative of malicious applications, can be automatically detected and can be used to explain decision making. DREBIN has shown an effective rate of detection of malicious applications on its own dataset. They have designed a dataset and a support vector machine (SVM) classifier is used for training on the same dataset.A model presented in [27] is an n-grams-based technique. Sequential features, based on n-grams, are extracted from files’ content. It determines patterns of sequential n-grams and then calculates statistics for the extracted pattern, and in the last, the classifier is trained to classify malware in different malware families. They have studied three classifiers for this task, i.e., SVM, C4.5, and multilayer perceptron. A method proposed in [28] uses three metrics, the weighted sum of permissions’ subset, a set that consists of a combination of permissions, and a specific subset of system calls’ occurrence. An approach based on permissions’ combination is studied in [29]. This scheme uses permission information present in the manifest of an Android application. These permissions’ combinations are frequently requested by malicious applications and rarely requested by benign applications. Based on the permissions combinations, rules are generated in order to make classification of applications as benign or malicious. This model is then used for the classification of unknown applications.An Android applications classification technique [30] and others [31] use bytecode for detection purposes. The bytecode of an application contains the accurate behavior of an application, which can provide enough information about the application’s intentions. Similarly, malicious applications tend to have the same pattern of bytecodes which makes them unique and differentiates them from benign applications.Android file’s opcodes are considered the source of information for malware detection. A technique that uses opcodes as features for the identification of malware applications is studied in [32]. This method is based on state-of-the-art classifiers applied to the frequencies of opcode n-grams. Similarly, a very popular study [33] presents a detection mechanism based on features, such as sequences of opcodes combined with machine learning algorithms. As an initial input feature, it collects all the possible k-grams in a given set of applications. To determine key relevant features, a selection algorithm is applied and a classifier is trained based upon selected features. Another opcode-related study [34] applies static analysis over opcode distribution. In this particular experiment, Android executables are disassembled statically, and the opcodes’ frequency distribution is extracted. These distribution patterns are then compared with nonmalicious executables’ distributions. It is noticed that there is a significant difference between these distributions. This feature can be effectively applied to differentiate malware and benign Android applications. The exploitation of opcodes for malware detection is currently a hot topic for Android malware detection problems.


### 2.4. Representative Handcrafted Features for Malware Detection

After the extensive study of both dynamic and static analysis of Android malware, it is concluded that dynamic and static analyses use a separate set of features for malware analysis. Features and their importance can be studied and justified using domain knowledge and expertise from the computer security domain. Each approach considers different types of features and tries to justify their importance and relevance to the problem; there is no standard solution or set of features. The different categories of the features are classified in Table1.Table 1
Features set for Android malware analysis.
Features for dynamic Android malware analysisBehavioral footprintingDalvik instruction tracesSystem callsAPI-level activity and information leakageHeuristic-based filteringSensitive data handlingRun time behaviorFeatures for static Android malware analysisBehavioral graphAPI-level featuresWeighted contextual API dependency graphControl flow transitionPermissionsOpcode patternsOpcode frequency histogramManifest and creator informationInformation flowContext, time, and connection-based network featuresStatistical featuresN-gram sequential featuresWeighted sum of permissionsInternet component call graphSignature-based features


### 2.5. Machine Learning Algorithms for Malware Detection

Once the feature engineering and extraction step is performed, the next step is usually to apply machine learning algorithms, such as random forest, decision tree, SVM, Bayesian classifiers, KNN, andk-means clustering, for malware detection and classification. Each algorithm deals with the extracted features differently and tries to learn useful patterns. The parameters of algorithms are tuned considering the nature of features. Studies such as [35] and [36] demonstrate the use of machine learning algorithms for automatic Android malware detection.(1)yk=∑iwki.xi,(2)En=12∑kynk−tnk2where;ynk=ykxn,w,(3)∂En∂wji=ynj−tnjxni.


### 2.6. Deep Neural Networks and Deep Learning

Deep learning or end-to-end learning is a paradigm of machine learning but is very practical [37]. It achieves great flexibility and power by learning to express the world in the form of a nested hierarchy of concepts, such that each complex concept is defined in terms of very simpler concepts. Concepts that are more abstract are defined in relation to less abstract concepts. This concept of end-to-end learning is not new but was there for decades. But recently with very strong hype, end-to-end learning is getting extraordinary attention. The more prominent contribution of end-to-end learning is automatic features engineering [38–41]. This property makes it unique and more powerful than all other existing machine learning techniques.Convolutional Neural Network (CNN) is an example of a deep neural network; it tries to learn low-level concepts or features such as edges and may be lines in starting layers, then parts and pieces of objects, and then the high-level representation of the objects [42]. The general problem-solving approach of deep learning is different than conventional machine learning algorithms. These algorithms first divide the problem into subproblems, and then after solving all the subproblems, the results are compiled in a collective form. This is not the case in deep learning because it is end-to-end learning; i.e., just input the raw data and the classification results are collected as output. CNNs have multiple hidden layers where convolution operation is performed, a few dense layers near the end of the network, and an output and input layer. The input data is fed to the input layer along with random initial weights. The output is received from the output layer. All the calculations are performed in hidden layers. Equation (2) is the error function known as mean squared error, where y is the predicted output and t is the target output or may be named as a label. We can also consider y as linear combinations of the given inputs as presented in equation (1), where yk is the output, wki is the weight, and xi is the input. After prediction, the error is calculated using equation (2), ynk is the predicted output while tnk is the ground truth. This error function is for some input n, and all possible outputs or labels k. The term x is a particular input having weight w. The calculated error is then backpropagated to hidden layers and weights are updated accordingly. This process is continued till the weights are optimized enough, and the value of the error function is converged. Equation (3) is the error function gradient considering some weight wji. This gradient is used in the backpropagation process.


### 2.7. Deep Learning-Based Analysis for Android Malware

There are a number of deep learning-based methods for Android malware detection. One of the methods is Droid-Sec [13]. It uses 200 different dynamic and static features with deep neural networks for malware detection. DeepDetector [14] is another approach, where eight different sets of features are considered to be used with deep neural networks. A multimodal deep learning method is proposed in [15]. The technique uses opcode features and method API features with deep neural networks. Another approach [16] extracts a sequence of API method calls and manually categorizes the dangerous APIs. The categorized API sequences are used to train deep neural networks. In [43], the authors use five different sets of features to perform classification using deep learning. Droiddetector [35] is considering three sets of features, i.e., required permission, sensitive API, and dynamic behavior, with deep neural networks.


### 2.8. Motivation for the Proposed Approach

Deep learning methods are popular because of deep feature extraction. All the existing deep learning-based techniques discussed in Section2.7 have used handcrafted features for automated Android malware detection as depicted in Figure 2. These techniques do not exploit the deep feature extraction nature of deep learning methods but rather use engineered handcrafted features. To hand-design, an effective feature is a lengthy process. This approach is very costly and lengthy and requires intensive domain knowledge and expertise as already discussed in Section 1. There is a need for making this feature extraction process automatic and reduce human experts’ intervention. Aiming at new applications, deep learning enables the acquisition of new effective feature representations from the available dataset for training. The major difference between deep learning and conventional methods is that deep learning automatically learns features from big data, instead of adopting handcrafted features as shown in Figure 3, which mainly depends on prior knowledge of designers and is highly impossible to take the advantage of big data.Figure 2
Conventional model for Android app classification.Figure 3
Proposed classification pipeline.Recent studies, such as [32, 33] and [34], offer solid justification that opcodes distribution and sequences provide important information to differentiate a malware from a trusted Android application. The problem is how to feed the opcodes information to deep neural networks as deep neural networks only work with numerical data. Another problem for Android application classification and malware detection is that there are only a limited number of datasets. The latest publicly available dataset is Drebin [26]. Drebin and all other existing datasets have Android apks structured directories and have such a format that they cannot be used to perform automatic malware detection using deep learning models [44].First, we need to develop an opcode embedding technique to feed the opcodes to deep neural networks. One solution is one-hot encoding [45–47]. But this solution has shortcomings; i.e., one-hot encoding leads to inefficiency for high-dimensional input data and it does not capture the semantic relationship. There are extensive studies [48–49] that strengthen the concept that the vector embedding technique outperforms the conventional one-hot encoding solution. This motivates us to develop a vector embedding technique for opcodes which we name “Op2Vec.” And secondly, based on the learned vector embeddings, we develop a dataset that will be used for the end-to-end detection of Android malware.


### 2.9. Word Embeddings

Word embedding is a technique used for embedding words into vectors. It does this task in such a fashion that the syntactic and semantic relationships between words are always preserved. Word2Vec is one of the very important subtasks for most of the applications of natural language processing (NLP). Word embedding is the collective name for a set of feature learning and language modeling techniques in the field of NLP where words and phrases from the available vocabulary are mapped to vectors of real numbers. Our work is inspired by TWEET2VEC [46], ATTACK2VEC [50], and ASM2VEC [51] where the authors have applied a word embedding technique to encode tweets, attacks, and assembly language functions into vectors. Word embedding is considered a very recent version of these embeddings which are relatively dense and have low dimensionality [52], which is very efficient in terms of computation. Get motivated from all these studies we are applying the Word2Vec to opcodes which we name Op2Vec, to learn vectors for opcodes. There are two common word embedding models, i.e., continuous bag-of-words (CBOW) and the skip-gram model. Because of the two severe limitations of CBOW [53], i.e., ignoring the order of words and ignoring the semantics of words, we will be considering the skip-gram model for our solution.


## 2.1. Android Malware Analysis

Due to the severity of Android malware, there are hundreds of approaches for its detection and classification. One approach is to perform a static analysis of the Android application. In static analysis, the executable code of the Android applications is examined to determine the data flow, control, and representative pattern without running the executables. Another approach is to examine an Android application through dynamic analysis. In dynamic analysis, the execution of an application is monitored by inspecting execution behaviors. Both static and dynamic analysis studies are discussed in the next two subsections.


## 2.2. Dynamic Analysis Techniques for Android Malware

Due to the complexity of dynamic analysis, there are very few techniques for conducting dynamic analysis for Android malware detection. A very popular technique is DroidScope [17]. It is an Android malicious applications’ analysis engine, based on emulation, which performs dynamic analysis of Android applications. Its specialty is to reconstruct both OS and Java level semantics seamlessly and simultaneously. Riskranker [18] is another approach that ensures accurate and very scalable detection of zero-day Android malware. It dynamically analyzes whether a particular application exhibits dangerous behavior. Another similar technique DroidRanger [19] performs a behavioral footprinting scheme, based on requested permissions, for the detection of new samples of unseen Android malware families, and later applies a heuristics-based filtering approach for the identification of certain inherent behaviors of unseen malware application families.Android malware detection is based on system calls [20], where automatic classification is performed based on tracking system calls. DroidScribe [21] is a very recent approach that focuses on dynamic analysis, i.e., runtime behavior. This approach shows how machine learning algorithms can be used to automatically classify Android malware into different malware families by just observing their runtime behavior. It observes that, on Android systems, system calls solely do not provide sufficient semantic content to make classification; that is why it also uses a lightweight VM introspection to reconstruct interprocess communication on the Android system for effective analysis. All the discussed techniques in this section have used engineered handcrafted features which are specifically designed for dynamic analysis.


## 2.3. Static Analysis Techniques for Android Malware

Static analysis is relatively simple and scalable. There are several techniques that use static analysis for Android malware detection. A set of static features is designed using domain expertise. The features are then utilized for the detection of Android malware. An approach, DroidAPIMiner [22], statically mines API-level features for the robust detection of malware on Android systems. It aims to provide a lightweight and robust classifier in order to evade Android malware installation. Another similar technique Droidminer [23] uses a behavioral graph to embed abstract malware program logic into a sequence of threat patterns and then applies machine learning techniques to identify and label elements of the graph that match already extracted threat modalities. A semantic-based technique [24] is responsible for the classification of Android malware through dependency graphs. It extracts a dependency graph, i.e., a weighted contextual API graph, as program semantics for the construction of feature sets. Another study reveals that malicious application treats sensitive data differently from benign applications. This feature is used to design a useful technique [25] for the identification of malware applications. Benign Android applications are mined for their data flow from sensitive sources, and then, these flows are compared against those, found in malicious applications, to detect similarities.DREBIN [26] is a lightweight method for Android malware detection. It enables the identification of malware applications on smartphones directly. It extracts as many features of an Android application as possible, and later, the extracted features are embedded into a joint vector space in such a fashion that typical patterns, which are indicative of malicious applications, can be automatically detected and can be used to explain decision making. DREBIN has shown an effective rate of detection of malicious applications on its own dataset. They have designed a dataset and a support vector machine (SVM) classifier is used for training on the same dataset.A model presented in [27] is an n-grams-based technique. Sequential features, based on n-grams, are extracted from files’ content. It determines patterns of sequential n-grams and then calculates statistics for the extracted pattern, and in the last, the classifier is trained to classify malware in different malware families. They have studied three classifiers for this task, i.e., SVM, C4.5, and multilayer perceptron. A method proposed in [28] uses three metrics, the weighted sum of permissions’ subset, a set that consists of a combination of permissions, and a specific subset of system calls’ occurrence. An approach based on permissions’ combination is studied in [29]. This scheme uses permission information present in the manifest of an Android application. These permissions’ combinations are frequently requested by malicious applications and rarely requested by benign applications. Based on the permissions combinations, rules are generated in order to make classification of applications as benign or malicious. This model is then used for the classification of unknown applications.An Android applications classification technique [30] and others [31] use bytecode for detection purposes. The bytecode of an application contains the accurate behavior of an application, which can provide enough information about the application’s intentions. Similarly, malicious applications tend to have the same pattern of bytecodes which makes them unique and differentiates them from benign applications.Android file’s opcodes are considered the source of information for malware detection. A technique that uses opcodes as features for the identification of malware applications is studied in [32]. This method is based on state-of-the-art classifiers applied to the frequencies of opcode n-grams. Similarly, a very popular study [33] presents a detection mechanism based on features, such as sequences of opcodes combined with machine learning algorithms. As an initial input feature, it collects all the possible k-grams in a given set of applications. To determine key relevant features, a selection algorithm is applied and a classifier is trained based upon selected features. Another opcode-related study [34] applies static analysis over opcode distribution. In this particular experiment, Android executables are disassembled statically, and the opcodes’ frequency distribution is extracted. These distribution patterns are then compared with nonmalicious executables’ distributions. It is noticed that there is a significant difference between these distributions. This feature can be effectively applied to differentiate malware and benign Android applications. The exploitation of opcodes for malware detection is currently a hot topic for Android malware detection problems.


## 2.4. Representative Handcrafted Features for Malware Detection

After the extensive study of both dynamic and static analysis of Android malware, it is concluded that dynamic and static analyses use a separate set of features for malware analysis. Features and their importance can be studied and justified using domain knowledge and expertise from the computer security domain. Each approach considers different types of features and tries to justify their importance and relevance to the problem; there is no standard solution or set of features. The different categories of the features are classified in Table1.Table 1
Features set for Android malware analysis.
Features for dynamic Android malware analysisBehavioral footprintingDalvik instruction tracesSystem callsAPI-level activity and information leakageHeuristic-based filteringSensitive data handlingRun time behaviorFeatures for static Android malware analysisBehavioral graphAPI-level featuresWeighted contextual API dependency graphControl flow transitionPermissionsOpcode patternsOpcode frequency histogramManifest and creator informationInformation flowContext, time, and connection-based network featuresStatistical featuresN-gram sequential featuresWeighted sum of permissionsInternet component call graphSignature-based features


## 2.5. Machine Learning Algorithms for Malware Detection

Once the feature engineering and extraction step is performed, the next step is usually to apply machine learning algorithms, such as random forest, decision tree, SVM, Bayesian classifiers, KNN, andk-means clustering, for malware detection and classification. Each algorithm deals with the extracted features differently and tries to learn useful patterns. The parameters of algorithms are tuned considering the nature of features. Studies such as [35] and [36] demonstrate the use of machine learning algorithms for automatic Android malware detection.(1)yk=∑iwki.xi,(2)En=12∑kynk−tnk2where;ynk=ykxn,w,(3)∂En∂wji=ynj−tnjxni.


## 2.6. Deep Neural Networks and Deep Learning

Deep learning or end-to-end learning is a paradigm of machine learning but is very practical [37]. It achieves great flexibility and power by learning to express the world in the form of a nested hierarchy of concepts, such that each complex concept is defined in terms of very simpler concepts. Concepts that are more abstract are defined in relation to less abstract concepts. This concept of end-to-end learning is not new but was there for decades. But recently with very strong hype, end-to-end learning is getting extraordinary attention. The more prominent contribution of end-to-end learning is automatic features engineering [38–41]. This property makes it unique and more powerful than all other existing machine learning techniques.Convolutional Neural Network (CNN) is an example of a deep neural network; it tries to learn low-level concepts or features such as edges and may be lines in starting layers, then parts and pieces of objects, and then the high-level representation of the objects [42]. The general problem-solving approach of deep learning is different than conventional machine learning algorithms. These algorithms first divide the problem into subproblems, and then after solving all the subproblems, the results are compiled in a collective form. This is not the case in deep learning because it is end-to-end learning; i.e., just input the raw data and the classification results are collected as output. CNNs have multiple hidden layers where convolution operation is performed, a few dense layers near the end of the network, and an output and input layer. The input data is fed to the input layer along with random initial weights. The output is received from the output layer. All the calculations are performed in hidden layers. Equation (2) is the error function known as mean squared error, where y is the predicted output and t is the target output or may be named as a label. We can also consider y as linear combinations of the given inputs as presented in equation (1), where yk is the output, wki is the weight, and xi is the input. After prediction, the error is calculated using equation (2), ynk is the predicted output while tnk is the ground truth. This error function is for some input n, and all possible outputs or labels k. The term x is a particular input having weight w. The calculated error is then backpropagated to hidden layers and weights are updated accordingly. This process is continued till the weights are optimized enough, and the value of the error function is converged. Equation (3) is the error function gradient considering some weight wji. This gradient is used in the backpropagation process.


## 2.7. Deep Learning-Based Analysis for Android Malware

There are a number of deep learning-based methods for Android malware detection. One of the methods is Droid-Sec [13]. It uses 200 different dynamic and static features with deep neural networks for malware detection. DeepDetector [14] is another approach, where eight different sets of features are considered to be used with deep neural networks. A multimodal deep learning method is proposed in [15]. The technique uses opcode features and method API features with deep neural networks. Another approach [16] extracts a sequence of API method calls and manually categorizes the dangerous APIs. The categorized API sequences are used to train deep neural networks. In [43], the authors use five different sets of features to perform classification using deep learning. Droiddetector [35] is considering three sets of features, i.e., required permission, sensitive API, and dynamic behavior, with deep neural networks.


## 2.8. Motivation for the Proposed Approach

Deep learning methods are popular because of deep feature extraction. All the existing deep learning-based techniques discussed in Section2.7 have used handcrafted features for automated Android malware detection as depicted in Figure 2. These techniques do not exploit the deep feature extraction nature of deep learning methods but rather use engineered handcrafted features. To hand-design, an effective feature is a lengthy process. This approach is very costly and lengthy and requires intensive domain knowledge and expertise as already discussed in Section 1. There is a need for making this feature extraction process automatic and reduce human experts’ intervention. Aiming at new applications, deep learning enables the acquisition of new effective feature representations from the available dataset for training. The major difference between deep learning and conventional methods is that deep learning automatically learns features from big data, instead of adopting handcrafted features as shown in Figure 3, which mainly depends on prior knowledge of designers and is highly impossible to take the advantage of big data.Figure 2
Conventional model for Android app classification.Figure 3
Proposed classification pipeline.Recent studies, such as [32, 33] and [34], offer solid justification that opcodes distribution and sequences provide important information to differentiate a malware from a trusted Android application. The problem is how to feed the opcodes information to deep neural networks as deep neural networks only work with numerical data. Another problem for Android application classification and malware detection is that there are only a limited number of datasets. The latest publicly available dataset is Drebin [26]. Drebin and all other existing datasets have Android apks structured directories and have such a format that they cannot be used to perform automatic malware detection using deep learning models [44].First, we need to develop an opcode embedding technique to feed the opcodes to deep neural networks. One solution is one-hot encoding [45–47]. But this solution has shortcomings; i.e., one-hot encoding leads to inefficiency for high-dimensional input data and it does not capture the semantic relationship. There are extensive studies [48–49] that strengthen the concept that the vector embedding technique outperforms the conventional one-hot encoding solution. This motivates us to develop a vector embedding technique for opcodes which we name “Op2Vec.” And secondly, based on the learned vector embeddings, we develop a dataset that will be used for the end-to-end detection of Android malware.


## 2.9. Word Embeddings

Word embedding is a technique used for embedding words into vectors. It does this task in such a fashion that the syntactic and semantic relationships between words are always preserved. Word2Vec is one of the very important subtasks for most of the applications of natural language processing (NLP). Word embedding is the collective name for a set of feature learning and language modeling techniques in the field of NLP where words and phrases from the available vocabulary are mapped to vectors of real numbers. Our work is inspired by TWEET2VEC [46], ATTACK2VEC [50], and ASM2VEC [51] where the authors have applied a word embedding technique to encode tweets, attacks, and assembly language functions into vectors. Word embedding is considered a very recent version of these embeddings which are relatively dense and have low dimensionality [52], which is very efficient in terms of computation. Get motivated from all these studies we are applying the Word2Vec to opcodes which we name Op2Vec, to learn vectors for opcodes. There are two common word embedding models, i.e., continuous bag-of-words (CBOW) and the skip-gram model. Because of the two severe limitations of CBOW [53], i.e., ignoring the order of words and ignoring the semantics of words, we will be considering the skip-gram model for our solution.


## 3. Proposed Methodology

In this section, we present details of the Op2Vec learning process and the designed dataset. The dataset consists of opcode sequences of Android applications. Initially, the dataset contains 28,570 Android applications. More applications can be easily added in the future to confirm the robustness of the proposed technique. The dataset design process consists of five phases. A pictorial view of all the steps involved in the proposed design process is shown in Figure4. After the collection of Android apks from different online Android Play Stores, the first phase is the extraction of Dalvik Executable (.dex) files from apks. The second phase is the extraction of instructions from executable files. All the instructions are processed and only opcode sequences are extracted. In the third phase, opcode sequences of different files are combined to learn Op2Vec, i.e., opcode embeddings. In the very last stage, for every single file, opcodes are replaced by their corresponding vectors, learned in phase four to finalize the dataset. The final step is to feed the dataset to deep neural networks to ensure its validation for end-to-end learning.Figure 4
Stepwise workflow of Op2Vec model and dataset design.


### 3.1. Collection of Benign Applications

Benign applications are those applications that are solely designed for harmless and smooth fulfillment of user requirements. The main objective of these applications is to meet the user requirements. Some Android benign applications are free and others are paid, available in online markets. Because of DRM restrictions, we have mostly collected free Android applications for our dataset. Around 16,240 free benign Android applications are downloaded from Amazon Appstore, SlideME, 1Mobile Market, and Google Play. A script (https://github.com/KaleemFAST/playstore-scraper-php.git) is designed to download applications from all the available sources.


### 3.2. Collection of Malicious Applications

Android applications are solely designed to meet the developer's interests at the cost of harming the application’s users. A malicious payload is part of the application that carries malicious behavior. There are two main objectives [54] that mostly encourage the design of malicious applications: (1) without the user intention, triggering the malicious payload execution again and again for maximum benefit, and (2) escape from detection in order to have maximum life till the fulfillment of interests. We have collected around 12,330 malicious applications of different malware families, i.e., Androidbox, AnserverBot, and 12 other families.


### 3.3. Dex Files Extraction

The Android APK consists of files, classes.dex, resources.arsc, AndroidManifest.xml, subfolders, lib, assets, res, and META-INF. The file structure of the Android apk is depicted in Figure4 step 1. All the files and folders have the necessary information regarding apk file. We are interested in the Dalvik Executable file, i.e., classes.dex. We extract this file from apk using a tool, named apktool (https://ibotpeaches.github.io). Apktool is a reverse engineering tool for Android apks. A script (https://github.com/KaleemFAST/Android%20End2End%20dataset%20design.git) is designed, and each apk file is unzipped through apktool. All the extracted classes.dex files are collected.


### 3.4. Opcodes Extraction

Dex file is the executable file for Android applications. The structure of the dex file is depicted in Figure4 step 1. We have used a tool dedexer (https://sourceforge.net/projects/dedexer/), i.e., a disassembler tool for Android dex file. We get a dex.log file that produces all the necessary information of different portions of the dex file. Using the information given in the dex.log file, the desired code section of the dex file is filtered. From the code section of the dex file, all the opcode sequences are extracted to another file. This process is repeated for all the collected dex files. Now, we have files containing opcode sequences of dex files.


### 3.5. Need for Opcode Embeddings

Opcodes representation is in textual form, i.e., 05,e2, 03, 87, etc. There are two severe and main problems with this type of representation. (1) We can see the order relationship among these opcodes; i.e., 05 is greater than 03. In reality, there is no such relationship; i.e., opcodes are not comparable with each other and thus are not ordered [55]. If we feed this data to the deep neural network in this form, the network may consider this relation as a feature (because of the feature engineering nature of deep neural networks), this reduces accuracy, and the learning process may be misled [56]. A technique is needed that should change this representation in such a fashion that assists the learning process and preserves the opcodes identity but still breaks the unnecessary ordering. (2) Deep neural networks do not work with textual/categorical data directly; rather, we have to change or encode its representation to numeric values.The conventional encoding technique used is one-hot encoding [45–47]. This encoding technique has the following limitations:(1)
In some scenarios, one-hot encoding may be useful where the number of categorical variables is limited [45, 47]. But when the variables are not limited, it becomes very expensive and leads to inefficiency in most cases [49, 57]. In our case, we have 255 different opcodes so for each opcode xi if embedded into one-hot encoding, it will have size xi ∈ [0, 1]255×1, and for example, if a single file has 300000 opcodes, it will have 30000 vectors of dimensions 255 × 1. This data will exponentially grow if the number of files exceeds 50,000 figures, i.e., 50,000 × 300,000 vectors of dimensions 255 × 1. Training deep learning models on high-dimensional data having no spatial structure causes a major computational problem. It implies a network with an input layer of a very huge size, which greatly increases the number of weights, often making the training infeasible [58].(2)
It does not capture morphological resemblance between categories, and it also ignores the semantic relationship between the input categories [57]. This can be very useful for deep learning models to learn deep features from opcodes arrangement in Android source files [59].(4)pwc,j=wO,c|wI=yc,j=expuc,j∑j′=1Vexpuj′.We definitely need to have an opcode embedding technique that overcomes all the above issues.


### 3.6. Opcode Embeddings Using Skip-Gram Model

From the previous section, it is clear that we need an opcode embedding technique. That is why we have introduced Op2Vec to get rid of all the listed issues. We have applied the skip-gram word embeddings technique for opcodes encoding. Skip-gram model [48] is a very prominent model in NLP that is used for Word2Vec. The words are embedded into vectors with the intuition that model needs to learn very similar and almost identical vectors for words having similar contexts. The complete architecture of the skip-gram is shown in Figure 5. Window size is selected based on the problem's nature. The input to the network is a one-hot vector that represents the input word and the output is also the number of one-hot vectors considering window size. While evaluating the trained network on a word given as input, the vectors that are obtained as output are probability distributions for nearby words, where from nearby words, we mean words lying inside the window selected for a particular vocabulary file given for training. The weights W in Figure 5, which are learned at the input layer, are the embedded representations of all the words in the vocabulary file. These probabilities are calculated using equation (4). In equation (4), wO and wI represent the output and input vectors, respectively. V represents the length of the vector. y is a training instance and u is any given vector. In plain English, this equation states the prediction probability of a particular jth word of the cth panel, which equals cth output word, i.e., the actual value of the output vector index, conditioned on wI. This equation decides the index value for a particular word in the output vector.Figure 5
Skip-gram model.We have used the skip-gram to learn Op2Vec. Skip-gram uses word sequences, so for Op2Vec, words are analogous to opcodes. We applied this concept with the intuition that opcodes that appear in the same context must have similar vector representations. Word2Vec is an analogy to Op2Vec, i.e., learning Op2Vec, and encodes opcodes in such a manner that opcodes having similar semantics are assigned nearly identical vector representations.


## 3.1. Collection of Benign Applications

Benign applications are those applications that are solely designed for harmless and smooth fulfillment of user requirements. The main objective of these applications is to meet the user requirements. Some Android benign applications are free and others are paid, available in online markets. Because of DRM restrictions, we have mostly collected free Android applications for our dataset. Around 16,240 free benign Android applications are downloaded from Amazon Appstore, SlideME, 1Mobile Market, and Google Play. A script (https://github.com/KaleemFAST/playstore-scraper-php.git) is designed to download applications from all the available sources.


## 3.2. Collection of Malicious Applications

Android applications are solely designed to meet the developer's interests at the cost of harming the application’s users. A malicious payload is part of the application that carries malicious behavior. There are two main objectives [54] that mostly encourage the design of malicious applications: (1) without the user intention, triggering the malicious payload execution again and again for maximum benefit, and (2) escape from detection in order to have maximum life till the fulfillment of interests. We have collected around 12,330 malicious applications of different malware families, i.e., Androidbox, AnserverBot, and 12 other families.


## 3.3. Dex Files Extraction

The Android APK consists of files, classes.dex, resources.arsc, AndroidManifest.xml, subfolders, lib, assets, res, and META-INF. The file structure of the Android apk is depicted in Figure4 step 1. All the files and folders have the necessary information regarding apk file. We are interested in the Dalvik Executable file, i.e., classes.dex. We extract this file from apk using a tool, named apktool (https://ibotpeaches.github.io). Apktool is a reverse engineering tool for Android apks. A script (https://github.com/KaleemFAST/Android%20End2End%20dataset%20design.git) is designed, and each apk file is unzipped through apktool. All the extracted classes.dex files are collected.


## 3.4. Opcodes Extraction

Dex file is the executable file for Android applications. The structure of the dex file is depicted in Figure4 step 1. We have used a tool dedexer (https://sourceforge.net/projects/dedexer/), i.e., a disassembler tool for Android dex file. We get a dex.log file that produces all the necessary information of different portions of the dex file. Using the information given in the dex.log file, the desired code section of the dex file is filtered. From the code section of the dex file, all the opcode sequences are extracted to another file. This process is repeated for all the collected dex files. Now, we have files containing opcode sequences of dex files.


## 3.5. Need for Opcode Embeddings

Opcodes representation is in textual form, i.e., 05,e2, 03, 87, etc. There are two severe and main problems with this type of representation. (1) We can see the order relationship among these opcodes; i.e., 05 is greater than 03. In reality, there is no such relationship; i.e., opcodes are not comparable with each other and thus are not ordered [55]. If we feed this data to the deep neural network in this form, the network may consider this relation as a feature (because of the feature engineering nature of deep neural networks), this reduces accuracy, and the learning process may be misled [56]. A technique is needed that should change this representation in such a fashion that assists the learning process and preserves the opcodes identity but still breaks the unnecessary ordering. (2) Deep neural networks do not work with textual/categorical data directly; rather, we have to change or encode its representation to numeric values.The conventional encoding technique used is one-hot encoding [45–47]. This encoding technique has the following limitations:(1)
In some scenarios, one-hot encoding may be useful where the number of categorical variables is limited [45, 47]. But when the variables are not limited, it becomes very expensive and leads to inefficiency in most cases [49, 57]. In our case, we have 255 different opcodes so for each opcode xi if embedded into one-hot encoding, it will have size xi ∈ [0, 1]255×1, and for example, if a single file has 300000 opcodes, it will have 30000 vectors of dimensions 255 × 1. This data will exponentially grow if the number of files exceeds 50,000 figures, i.e., 50,000 × 300,000 vectors of dimensions 255 × 1. Training deep learning models on high-dimensional data having no spatial structure causes a major computational problem. It implies a network with an input layer of a very huge size, which greatly increases the number of weights, often making the training infeasible [58].(2)
It does not capture morphological resemblance between categories, and it also ignores the semantic relationship between the input categories [57]. This can be very useful for deep learning models to learn deep features from opcodes arrangement in Android source files [59].(4)pwc,j=wO,c|wI=yc,j=expuc,j∑j′=1Vexpuj′.We definitely need to have an opcode embedding technique that overcomes all the above issues.


## 3.6. Opcode Embeddings Using Skip-Gram Model

From the previous section, it is clear that we need an opcode embedding technique. That is why we have introduced Op2Vec to get rid of all the listed issues. We have applied the skip-gram word embeddings technique for opcodes encoding. Skip-gram model [48] is a very prominent model in NLP that is used for Word2Vec. The words are embedded into vectors with the intuition that model needs to learn very similar and almost identical vectors for words having similar contexts. The complete architecture of the skip-gram is shown in Figure 5. Window size is selected based on the problem's nature. The input to the network is a one-hot vector that represents the input word and the output is also the number of one-hot vectors considering window size. While evaluating the trained network on a word given as input, the vectors that are obtained as output are probability distributions for nearby words, where from nearby words, we mean words lying inside the window selected for a particular vocabulary file given for training. The weights W in Figure 5, which are learned at the input layer, are the embedded representations of all the words in the vocabulary file. These probabilities are calculated using equation (4). In equation (4), wO and wI represent the output and input vectors, respectively. V represents the length of the vector. y is a training instance and u is any given vector. In plain English, this equation states the prediction probability of a particular jth word of the cth panel, which equals cth output word, i.e., the actual value of the output vector index, conditioned on wI. This equation decides the index value for a particular word in the output vector.Figure 5
Skip-gram model.We have used the skip-gram to learn Op2Vec. Skip-gram uses word sequences, so for Op2Vec, words are analogous to opcodes. We applied this concept with the intuition that opcodes that appear in the same context must have similar vector representations. Word2Vec is an analogy to Op2Vec, i.e., learning Op2Vec, and encodes opcodes in such a manner that opcodes having similar semantics are assigned nearly identical vector representations.


## 4. Experimental Setup and Results

There are three main experiments that are carried out to justify the efficacy of the proposed approach. One is learning Op2Vec. The second one is the dataset development based on the learned Op2Vec, i.e., opcode embeddings for end-to-end learning of Android malware. And the third experiment is to feed the designed dataset to deep neural networks to validate the claim that the dataset can be used for the deep learning-based analysis of Android malware. In Figure4, the gray boxes and cubes from left to right depict the Op2Vec learning process. The skip-gram model takes input and uses the GPU facility to learn Op2Vec. This Op2Vec will be used with deep learning models to perform end-to-end learning for Android malware detection and classify Android apps as benign 0 or malicious 1.


### 4.1. Op2Vec: Learning Opcode Embeddings

Words analogy to opcodes is considered in order to apply the word embeddings technique to opcode embeddings. The same steps and process of the skip-gram model, used for word embeddings in Section3.6, are applied for opcodes. After the learning phase, opcodes are encoded into vector representations. This process consists of four subtasks which are listed as follows.


#### 4.1.1. Preprocessing Phase

In the preprocessing phase, we consider 5,000 Android applications’ dex files, 3,000 benign and 2,000 Malicious files out of the total 16,240 benign Android applications, and 12,330 malware files, respectively, for the development of vocabulary files to train our model. All the opcodes are collected into a single file. Now, this file is considered a vocabulary file for the learning phase. This vocabulary file has to be fed to the Op2Vec model for training. At the very start, we are not able to feed the opcodes directly to the neural network. The reason is that opcodes are represented in hexadecimal notations, i.e., strings; that is why we binarize this input with a one-hot encoding technique. As there are a total of 255 opcodes, so the length of the one-hot input vector is 255 × 1. For a particular opcode 0a, the one-hot vector is depicted in Figure 5. For 0a, the corresponding entry in the vector is fixed as 1 and all the other 254 entries are zeros. The output of this model network is a vector of the same size. It should also have 255 components. Every entry of the resultant output vector is the probability of an opcode selected randomly in the vicinity of the input opcode.


#### 4.1.2. Parameters Setting for Training Phase

Op2Vec embeddings are learned using the skip-gram model. It is a neural network-based model having all the hidden, input, and output layers. All neurons in the hidden layers are without the activation functions, but all the neurons in the output layer use the softmax. Softmax is a type of regression used for multiclass classification. In softmax, for a given inputX, a designed hypothesis tries to estimate Py=k|x, which is the probability for each value of k=1,…,K. This value of k denotes the label of a particular class, so essentially the function gives us the probability of a particular input being in any class k. The network is trained on pairs of opcodes. The input vector is the one-hot representation of the input opcode. The output, which is also in the form of a one-hot vector, is all the opcodes inside the window except the input opcode, and we call it training output opcodes.For computational simplicity and better visual representation, we trained our network for opcode vectors having two dimensions. We already know that the input vector size is 255 and we have selected the dimensions count as 2, so the representation of the hidden layer weight matrix is going to be in the form of a matrix with 255 columns and 2 rows. The ultimate goal of this setup is to learn the weight matrix. The output vectors are thrown out once we are done with learning. The network is trained to do the task, i.e., given any specific opcode in the middle of the opcodes sequence, and randomly pick one opcode from the vicinity, and the model tells us the probability for every opcode in the vocabulary to be that opcode we have selected randomly. The vicinity or nearby term is used because the skip-gram model uses the window as a parameter in its algorithm; typically, the window size parameter is set to 5 as recommended in the original documentation of the skip-gram. Window size 5 means 5 opcodes ahead and 5 opcodes behind the central opcode. We have hyperparameter, i.e., window size. For our problem, we fixed this hyperparameter to its default value as 5.


#### 4.1.3. Training Phase

In the training phase of learning Op2Vec, the vocabulary file designed in Section4.1.1 is used as input to the neural network. A sliding window of size 5 is adjusted to slide through all the opcodes in the vocabulary file till the end of the file. The neural network tries to optimize its weight matrix after each iteration to adjust the probabilities at the output layer for the opcodes of the same context and semantics.In Figure6(a), a sliding window of size 2 is shown, i.e., two opcodes before the central opcode and two opcodes after the central one. For instance, 5 opcodes in a row are selected, and the opcode colored black is the input opcode for the network. After feeding this setup, the network tries to learn patterns in the form of statistical information of the number of occurrences of each pair, i.e., central opcode with any other opcode in the mentioned window. In this particular case where opcode If-it is the central opcode, the pairs are (If-lt, If-le), (If-lt, If-ge), (If-lt, If-gt), and (If-lt, If-eqz). Let us say the pair (If-lt, If-ge) occurred more frequently in the given vocabulary file, so when the learning phase is finished and we input the opcode If-lt to the network, it shows the high probability for the opcode If-ge in the output vector. The window is slid further to repeat this process for all opcodes in the vocabulary. This sliding procedure is depicted in Figures 6(b) and 6(c).Figure 6
Sliding window over vocabulary opcodes.
(a)(b)(c)


#### 4.1.4. Learning Op2Vec

The input vector size is 255 × 1. The weight matrix for the first hidden layer is of size 2 × 255 as shown in Figure5. The output of the hidden layer is a vector of 2 × 1. This vector is going to be input for the next layer, i.e., the output layer, where the weight matrices for this layer are of size 255 × 2. The output vectors of the network are of size 255 × 1, i.e., which is the probability distribution of all distinct 255 opcodes. The softmax is applied to the output of each neuron in order to get the values to sum up to 1. The columns of the learned weight matrix at the first hidden layer are the vector representations of all the 255 opcodes. After the network is trained, when we evaluate the network on a given input opcode, the output vector represents the probability distribution, i.e., a list of values in the form of floating points, not in the form of a one-hot vector that we obtain in the training phase.


### 4.2. Op2Vec Results: Learned Opcode Embeddings

After completion of the learning process, the weight matrix is divided into vectors to get the vector representation of all the 255 opcodes. The values range of all the vectors is in the interval [−1, 1]. For some very common opcodes, the learned vectors are listed in Table2. These are two-dimensional vectors. It can be seen that the same categories of opcodes are represented by nearly identical vectors. Few of these vectors are plotted in Figure 7. Op2Vec has fixed all the issues of conventional one-hot encoding, discussed in Section 3.5, as follows:(1)
It is very clear from Figure7 that the Op2Vec model learned vectors are depicted in such a manner that opcodes, having similar semantics, are represented by almost identical vectors. It is also depicted that opcodes, semantically different, are very apart from each other. If we look at Figure 7, we can clearly see that all the conditional statements If-lt, If-le, If-eqz, If-ne, If-ge, and If-gt are positioned very near in the space; this reveals that semantics are preserved in this sort of learning. Similarly, arithmetic opcodes Mul-int, Sub-lg, Div-int, Div-lg, and Add-lg are separately clustered. Because of the semantic similarity, they are almost identical. Same patterns can be observed for the rest of the opcode categories. So the results reveal the fact that Op2Vec has learned embeddings effectively and semantic relationships among opcodes are preserved. Intuitively, this is a very useful insight for deep learning models to learn deep features from opcodes arrangement in the Android source file. Introducing this relationship among opcodes will enhance the malware detection learning process [48, 49, 60], which is a contribution to automatic malware detection.(2)
The size of a single one-hot vector is 255 × 1. Table2 shows that Op2Vec embeddings have reduced the 255 × 1 size of one-hot vectors to 2 × 1, which significantly decreases computationally complexity [58].(3)
Op2Vec embeddings have also fixed the limitation of ordering between originally extracted opcodes as there is no such real order in the generated vector representation.Table 2
Learned Op2Vec: the learned vectors.
OpcodeX-axis valueY-axis valueIf-ne−0.2729177368−0.0875072266If-lt−0.3726633597−0.017922292If-ge−0.6149268202−0.0044448727If-gt−0.6818177649−0.3873034379If-le−0.30768272620.1643184456If-eqz−0.25917927410.2236180313Mul-int0.21149856940.3691054416Sub-lg0.12620996950.1640332061Div-int0.1447551711−0.0522292025Add-lg−0.0497673974−0.2025787514Div-lg0.1181362618−0.0835916175Iput-wide0.3703214875−0.0470563225Iput-byte0.3919335594−0.0879191859Iput-char0.462135628−0.3112477693Invoke-static−0.278561079−0.3259538566Invoke-super−0.6331899455−0.4750899485Invoke-virtual−0.5944988213−0.5101055075New-array0.03895570980.6073178184Filled-new-array−0.09662432530.5125404323New-instance0.07622538550.4074241374Figure 7
Learned opcode embeddings.


### 4.3. Development of the End-to-End Learning Dataset

Now, when the Op2Vec embeddings are successfully learned, we can generate the proposed dataset that can be efficiently used for end-to-end learning analysis of Android malware. All the files generated in Section3.4 are accessed one by one, and the opcodes are replaced by their corresponding vector representation learned in Section 4.2. Thus, the dataset is developed, and we claim that this is the first-ever attempt to develop a dataset that will be used for end-to-end detection of Android malware using deep neural networks.


### 4.4. Feed the Developed Dataset to Deep Learning Models

The claimed hypothesis that the dataset can be effectively used for end-to-end learning is validated by feeding the dataset to the CNN, i.e., a deep neural network/end-to-end learning model. Each file in the dataset has two-dimensional vectors corresponding to each opcode in the original dex file. So each file has two columns and a number of rows. For the network, we consider our input frame consists of two channels as each vector is of two dimensional. Each benign file is assigned a label as 0 whereas each malicious file is labeled as 1. The network’s setup is all set to process the available files for end-to-end learning.


## 4.1. Op2Vec: Learning Opcode Embeddings

Words analogy to opcodes is considered in order to apply the word embeddings technique to opcode embeddings. The same steps and process of the skip-gram model, used for word embeddings in Section3.6, are applied for opcodes. After the learning phase, opcodes are encoded into vector representations. This process consists of four subtasks which are listed as follows.


### 4.1.1. Preprocessing Phase

In the preprocessing phase, we consider 5,000 Android applications’ dex files, 3,000 benign and 2,000 Malicious files out of the total 16,240 benign Android applications, and 12,330 malware files, respectively, for the development of vocabulary files to train our model. All the opcodes are collected into a single file. Now, this file is considered a vocabulary file for the learning phase. This vocabulary file has to be fed to the Op2Vec model for training. At the very start, we are not able to feed the opcodes directly to the neural network. The reason is that opcodes are represented in hexadecimal notations, i.e., strings; that is why we binarize this input with a one-hot encoding technique. As there are a total of 255 opcodes, so the length of the one-hot input vector is 255 × 1. For a particular opcode 0a, the one-hot vector is depicted in Figure 5. For 0a, the corresponding entry in the vector is fixed as 1 and all the other 254 entries are zeros. The output of this model network is a vector of the same size. It should also have 255 components. Every entry of the resultant output vector is the probability of an opcode selected randomly in the vicinity of the input opcode.


### 4.1.2. Parameters Setting for Training Phase

Op2Vec embeddings are learned using the skip-gram model. It is a neural network-based model having all the hidden, input, and output layers. All neurons in the hidden layers are without the activation functions, but all the neurons in the output layer use the softmax. Softmax is a type of regression used for multiclass classification. In softmax, for a given inputX, a designed hypothesis tries to estimate Py=k|x, which is the probability for each value of k=1,…,K. This value of k denotes the label of a particular class, so essentially the function gives us the probability of a particular input being in any class k. The network is trained on pairs of opcodes. The input vector is the one-hot representation of the input opcode. The output, which is also in the form of a one-hot vector, is all the opcodes inside the window except the input opcode, and we call it training output opcodes.For computational simplicity and better visual representation, we trained our network for opcode vectors having two dimensions. We already know that the input vector size is 255 and we have selected the dimensions count as 2, so the representation of the hidden layer weight matrix is going to be in the form of a matrix with 255 columns and 2 rows. The ultimate goal of this setup is to learn the weight matrix. The output vectors are thrown out once we are done with learning. The network is trained to do the task, i.e., given any specific opcode in the middle of the opcodes sequence, and randomly pick one opcode from the vicinity, and the model tells us the probability for every opcode in the vocabulary to be that opcode we have selected randomly. The vicinity or nearby term is used because the skip-gram model uses the window as a parameter in its algorithm; typically, the window size parameter is set to 5 as recommended in the original documentation of the skip-gram. Window size 5 means 5 opcodes ahead and 5 opcodes behind the central opcode. We have hyperparameter, i.e., window size. For our problem, we fixed this hyperparameter to its default value as 5.


### 4.1.3. Training Phase

In the training phase of learning Op2Vec, the vocabulary file designed in Section4.1.1 is used as input to the neural network. A sliding window of size 5 is adjusted to slide through all the opcodes in the vocabulary file till the end of the file. The neural network tries to optimize its weight matrix after each iteration to adjust the probabilities at the output layer for the opcodes of the same context and semantics.In Figure6(a), a sliding window of size 2 is shown, i.e., two opcodes before the central opcode and two opcodes after the central one. For instance, 5 opcodes in a row are selected, and the opcode colored black is the input opcode for the network. After feeding this setup, the network tries to learn patterns in the form of statistical information of the number of occurrences of each pair, i.e., central opcode with any other opcode in the mentioned window. In this particular case where opcode If-it is the central opcode, the pairs are (If-lt, If-le), (If-lt, If-ge), (If-lt, If-gt), and (If-lt, If-eqz). Let us say the pair (If-lt, If-ge) occurred more frequently in the given vocabulary file, so when the learning phase is finished and we input the opcode If-lt to the network, it shows the high probability for the opcode If-ge in the output vector. The window is slid further to repeat this process for all opcodes in the vocabulary. This sliding procedure is depicted in Figures 6(b) and 6(c).Figure 6
Sliding window over vocabulary opcodes.
(a)(b)(c)


### 4.1.4. Learning Op2Vec

The input vector size is 255 × 1. The weight matrix for the first hidden layer is of size 2 × 255 as shown in Figure5. The output of the hidden layer is a vector of 2 × 1. This vector is going to be input for the next layer, i.e., the output layer, where the weight matrices for this layer are of size 255 × 2. The output vectors of the network are of size 255 × 1, i.e., which is the probability distribution of all distinct 255 opcodes. The softmax is applied to the output of each neuron in order to get the values to sum up to 1. The columns of the learned weight matrix at the first hidden layer are the vector representations of all the 255 opcodes. After the network is trained, when we evaluate the network on a given input opcode, the output vector represents the probability distribution, i.e., a list of values in the form of floating points, not in the form of a one-hot vector that we obtain in the training phase.


## 4.1.1. Preprocessing Phase

In the preprocessing phase, we consider 5,000 Android applications’ dex files, 3,000 benign and 2,000 Malicious files out of the total 16,240 benign Android applications, and 12,330 malware files, respectively, for the development of vocabulary files to train our model. All the opcodes are collected into a single file. Now, this file is considered a vocabulary file for the learning phase. This vocabulary file has to be fed to the Op2Vec model for training. At the very start, we are not able to feed the opcodes directly to the neural network. The reason is that opcodes are represented in hexadecimal notations, i.e., strings; that is why we binarize this input with a one-hot encoding technique. As there are a total of 255 opcodes, so the length of the one-hot input vector is 255 × 1. For a particular opcode 0a, the one-hot vector is depicted in Figure 5. For 0a, the corresponding entry in the vector is fixed as 1 and all the other 254 entries are zeros. The output of this model network is a vector of the same size. It should also have 255 components. Every entry of the resultant output vector is the probability of an opcode selected randomly in the vicinity of the input opcode.


## 4.1.2. Parameters Setting for Training Phase

Op2Vec embeddings are learned using the skip-gram model. It is a neural network-based model having all the hidden, input, and output layers. All neurons in the hidden layers are without the activation functions, but all the neurons in the output layer use the softmax. Softmax is a type of regression used for multiclass classification. In softmax, for a given inputX, a designed hypothesis tries to estimate Py=k|x, which is the probability for each value of k=1,…,K. This value of k denotes the label of a particular class, so essentially the function gives us the probability of a particular input being in any class k. The network is trained on pairs of opcodes. The input vector is the one-hot representation of the input opcode. The output, which is also in the form of a one-hot vector, is all the opcodes inside the window except the input opcode, and we call it training output opcodes.For computational simplicity and better visual representation, we trained our network for opcode vectors having two dimensions. We already know that the input vector size is 255 and we have selected the dimensions count as 2, so the representation of the hidden layer weight matrix is going to be in the form of a matrix with 255 columns and 2 rows. The ultimate goal of this setup is to learn the weight matrix. The output vectors are thrown out once we are done with learning. The network is trained to do the task, i.e., given any specific opcode in the middle of the opcodes sequence, and randomly pick one opcode from the vicinity, and the model tells us the probability for every opcode in the vocabulary to be that opcode we have selected randomly. The vicinity or nearby term is used because the skip-gram model uses the window as a parameter in its algorithm; typically, the window size parameter is set to 5 as recommended in the original documentation of the skip-gram. Window size 5 means 5 opcodes ahead and 5 opcodes behind the central opcode. We have hyperparameter, i.e., window size. For our problem, we fixed this hyperparameter to its default value as 5.


## 4.1.3. Training Phase

In the training phase of learning Op2Vec, the vocabulary file designed in Section4.1.1 is used as input to the neural network. A sliding window of size 5 is adjusted to slide through all the opcodes in the vocabulary file till the end of the file. The neural network tries to optimize its weight matrix after each iteration to adjust the probabilities at the output layer for the opcodes of the same context and semantics.In Figure6(a), a sliding window of size 2 is shown, i.e., two opcodes before the central opcode and two opcodes after the central one. For instance, 5 opcodes in a row are selected, and the opcode colored black is the input opcode for the network. After feeding this setup, the network tries to learn patterns in the form of statistical information of the number of occurrences of each pair, i.e., central opcode with any other opcode in the mentioned window. In this particular case where opcode If-it is the central opcode, the pairs are (If-lt, If-le), (If-lt, If-ge), (If-lt, If-gt), and (If-lt, If-eqz). Let us say the pair (If-lt, If-ge) occurred more frequently in the given vocabulary file, so when the learning phase is finished and we input the opcode If-lt to the network, it shows the high probability for the opcode If-ge in the output vector. The window is slid further to repeat this process for all opcodes in the vocabulary. This sliding procedure is depicted in Figures 6(b) and 6(c).Figure 6
Sliding window over vocabulary opcodes.
(a)(b)(c)


## 4.1.4. Learning Op2Vec

The input vector size is 255 × 1. The weight matrix for the first hidden layer is of size 2 × 255 as shown in Figure5. The output of the hidden layer is a vector of 2 × 1. This vector is going to be input for the next layer, i.e., the output layer, where the weight matrices for this layer are of size 255 × 2. The output vectors of the network are of size 255 × 1, i.e., which is the probability distribution of all distinct 255 opcodes. The softmax is applied to the output of each neuron in order to get the values to sum up to 1. The columns of the learned weight matrix at the first hidden layer are the vector representations of all the 255 opcodes. After the network is trained, when we evaluate the network on a given input opcode, the output vector represents the probability distribution, i.e., a list of values in the form of floating points, not in the form of a one-hot vector that we obtain in the training phase.


## 4.2. Op2Vec Results: Learned Opcode Embeddings

After completion of the learning process, the weight matrix is divided into vectors to get the vector representation of all the 255 opcodes. The values range of all the vectors is in the interval [−1, 1]. For some very common opcodes, the learned vectors are listed in Table2. These are two-dimensional vectors. It can be seen that the same categories of opcodes are represented by nearly identical vectors. Few of these vectors are plotted in Figure 7. Op2Vec has fixed all the issues of conventional one-hot encoding, discussed in Section 3.5, as follows:(1)
It is very clear from Figure7 that the Op2Vec model learned vectors are depicted in such a manner that opcodes, having similar semantics, are represented by almost identical vectors. It is also depicted that opcodes, semantically different, are very apart from each other. If we look at Figure 7, we can clearly see that all the conditional statements If-lt, If-le, If-eqz, If-ne, If-ge, and If-gt are positioned very near in the space; this reveals that semantics are preserved in this sort of learning. Similarly, arithmetic opcodes Mul-int, Sub-lg, Div-int, Div-lg, and Add-lg are separately clustered. Because of the semantic similarity, they are almost identical. Same patterns can be observed for the rest of the opcode categories. So the results reveal the fact that Op2Vec has learned embeddings effectively and semantic relationships among opcodes are preserved. Intuitively, this is a very useful insight for deep learning models to learn deep features from opcodes arrangement in the Android source file. Introducing this relationship among opcodes will enhance the malware detection learning process [48, 49, 60], which is a contribution to automatic malware detection.(2)
The size of a single one-hot vector is 255 × 1. Table2 shows that Op2Vec embeddings have reduced the 255 × 1 size of one-hot vectors to 2 × 1, which significantly decreases computationally complexity [58].(3)
Op2Vec embeddings have also fixed the limitation of ordering between originally extracted opcodes as there is no such real order in the generated vector representation.Table 2
Learned Op2Vec: the learned vectors.
OpcodeX-axis valueY-axis valueIf-ne−0.2729177368−0.0875072266If-lt−0.3726633597−0.017922292If-ge−0.6149268202−0.0044448727If-gt−0.6818177649−0.3873034379If-le−0.30768272620.1643184456If-eqz−0.25917927410.2236180313Mul-int0.21149856940.3691054416Sub-lg0.12620996950.1640332061Div-int0.1447551711−0.0522292025Add-lg−0.0497673974−0.2025787514Div-lg0.1181362618−0.0835916175Iput-wide0.3703214875−0.0470563225Iput-byte0.3919335594−0.0879191859Iput-char0.462135628−0.3112477693Invoke-static−0.278561079−0.3259538566Invoke-super−0.6331899455−0.4750899485Invoke-virtual−0.5944988213−0.5101055075New-array0.03895570980.6073178184Filled-new-array−0.09662432530.5125404323New-instance0.07622538550.4074241374Figure 7
Learned opcode embeddings.


## 4.3. Development of the End-to-End Learning Dataset

Now, when the Op2Vec embeddings are successfully learned, we can generate the proposed dataset that can be efficiently used for end-to-end learning analysis of Android malware. All the files generated in Section3.4 are accessed one by one, and the opcodes are replaced by their corresponding vector representation learned in Section 4.2. Thus, the dataset is developed, and we claim that this is the first-ever attempt to develop a dataset that will be used for end-to-end detection of Android malware using deep neural networks.


## 4.4. Feed the Developed Dataset to Deep Learning Models

The claimed hypothesis that the dataset can be effectively used for end-to-end learning is validated by feeding the dataset to the CNN, i.e., a deep neural network/end-to-end learning model. Each file in the dataset has two-dimensional vectors corresponding to each opcode in the original dex file. So each file has two columns and a number of rows. For the network, we consider our input frame consists of two channels as each vector is of two dimensional. Each benign file is assigned a label as 0 whereas each malicious file is labeled as 1. The network’s setup is all set to process the available files for end-to-end learning.


## 5. Comparison with Existing Datasets

This section draws a comparison among our designed Op2Vec dataset and six other very popular datasets in the malware analysis literature. The comparison is based on the following two parameters.


### 5.1. Features (Handcrafted or Deep Features)

One of the fundamental limitations of all other available datasets is handcrafted feature extraction which are employed for characterizing malware behavior. Our Op2Vec does not require handcrafted features. The datasets can be fed directly to the deep neural network for learning deep features.


### 5.2. Feeding Information to the Deep Neural Network (One-Hot Encoding or Vector Embedding)

All the listed datasets and techniques have used one-hot encoding to feed the Android source code information to the classifiers. One-hot encoding has limitations that are discussed in Section3.5. We have proposed Op2Vec which has fixed all the limitations and outperforms one-hot encoding as discussed in Section 4.2.Drebin [26] has used a script for the automated extraction of different handcrafted features. The features are embedded in the one-hot encoding of the form xi ∈ [0, 1]545000×1. SVM classifier is trained to classify applications based on their representative feature vectors. Another dataset that is used in [61]. A total of 42 handcrafted features of size xi ∈ [0, 1]42×1 are extracted to use with LSTM. Similarly, the authors in [62] have used a dataset where 34,570 handcrafted features are extracted. This feature set is reduced to 413 using a feature selection technique. The input feature vector for the classifier is of size xi ∈ [0, 1]413×1. Both [63, 65] have used 323 and 1,058 features, respectively, for machine learning classifiers. Their input feature vectors are xi ∈ [0, 1]323×1 and xi ∈ [0, 1]1058×1, respectively. There are a number of datasets available for Android malware analysis and these datasets are only a collection of malicious Android applications. VirusShare [64] is one of the examples of such datasets. VirusShare has a total of 107,888 malicious Android applications. Different studies have used this dataset to learn insights into Android malware. A total of 482 features are considered and a feature vector of size xi ∈ [0, 1]482×1 has been used to feed information to machine learning classifiers.All the discussed datasets have a format that cannot be used to perform automatic malware detection using deep learning models. Most of these studies extract features from datasets, and these features are used with deep learning algorithms. Deep learning models have a very strong property, i.e., automatic deep feature extraction. They do not need handcrafted features; rather, raw data is sufficient for the training and learning process. Our proposed dataset is designed to exploit deep learning models for deep features. We have designed a dataset that can be fed directly to deep learning models. Unlike other datasets, no handcrafted features are required. The input encoded vector size isxi ∈ [−1, 1]2×1, which has very few dimensions in comparison with other existing dataset techniques.From Table3, it is clear that in terms of features extraction and embedding technique our Op2Vec dataset is far better and adaptable as compared to the other datasets. Performing the Op2Vec type embedding technique can reduce dimensions up to 2 × 1. Adopting this dataset will allow learning deep features without extraction of handcrafted features and with less computational complexity. The rest of Table 3 shows the files count in all the three datasets, malicious and benign files count, feature extraction method, and encoding techniques for features to be fed to machine learning and deep learning algorithms.Table 3
Comparisons with existing datasets.
DatasetFiles countMaliciousBenignFeature extractionFeatures setFeature vectorDrebin [26]129,013123,4535,560Handcrafted545,000xi ∈ [0, 1]545000×1Vinayakumar et al. [61]22961,609687Handcrafted42xi ∈ [0, 1]42×1Wang et al. [62]23,00013,00010,000Handcrafted34,570xi ∈ [0, 1]413×1Zhu et al. [63]11,0008,0003,000Handcrafted323xi ∈ [0, 1]323×1VirusShare [64]107,888None107,888Handcrafted482xi ∈ [0, 1]482×1Hou et al. [65]5,0002,5002,500Handcrafted1,058xi ∈ [0, 1]1058×1AndroZoo [66]3,182,5901,162,1502,020,440Handcrafted50,000xi ∈ [0, 1]50000×1Op2Vec dataset28,57012,33016,240AutomatedDeep featuresxi ∈ [−1, 1]2×1In order to demonstrate the significance of the proposed approach, some of the recent opcode-based deep learning techniques such as [67–72] are trained and tested with the Op2Vec dataset. For a fair comparison, the same experimental setup is used for the experiments with Op2Vec. It can be seen in Table 4 that the performance of the existing techniques significantly improves by incorporating Op2Vec embeddings. All the listed approaches achieve an average accuracy of 97.47%, where the highest accuracy is achieved with the setup suggested in [71]. It is evident from the results that Op2Vec which incorporates the semantic relationship of opcodes and deep features enhances the performance of deep learning techniques to detect Android malware.Table 4
Performance enhancement of existing opcode-based techniques.
Reference (Year)FeaturesDeep learning techniqueDatasetReported results (Acc) (%)Results with Op2Vec (acc) (%)Parildi et al. (2021) [67]OpcodesVirusShare and native Win7 appsRNN and LSTM9596.83Ren et al. (2020) [68]OpcodesGoogle Play store and VirusShareDNNs95.897.1Niu et al. (2020) [69]OpcodesVirusShare, Androzoo, and Pea PodsLSTM9798.77Pekta and Acarman (2020) [70]OpcodesAndrozoo, Argus group, and GooglePlayRNN and91.4296Zhang et al. (2018) [71]OpcodesMicrosoft in Kaggle 2015 and Benign appsResNet98.298.63McLaughlin et al. (2017) [72]OpcodesGenome project, McAfee LabsCNN9597.53


## 5.1. Features (Handcrafted or Deep Features)

One of the fundamental limitations of all other available datasets is handcrafted feature extraction which are employed for characterizing malware behavior. Our Op2Vec does not require handcrafted features. The datasets can be fed directly to the deep neural network for learning deep features.


## 5.2. Feeding Information to the Deep Neural Network (One-Hot Encoding or Vector Embedding)

All the listed datasets and techniques have used one-hot encoding to feed the Android source code information to the classifiers. One-hot encoding has limitations that are discussed in Section3.5. We have proposed Op2Vec which has fixed all the limitations and outperforms one-hot encoding as discussed in Section 4.2.Drebin [26] has used a script for the automated extraction of different handcrafted features. The features are embedded in the one-hot encoding of the form xi ∈ [0, 1]545000×1. SVM classifier is trained to classify applications based on their representative feature vectors. Another dataset that is used in [61]. A total of 42 handcrafted features of size xi ∈ [0, 1]42×1 are extracted to use with LSTM. Similarly, the authors in [62] have used a dataset where 34,570 handcrafted features are extracted. This feature set is reduced to 413 using a feature selection technique. The input feature vector for the classifier is of size xi ∈ [0, 1]413×1. Both [63, 65] have used 323 and 1,058 features, respectively, for machine learning classifiers. Their input feature vectors are xi ∈ [0, 1]323×1 and xi ∈ [0, 1]1058×1, respectively. There are a number of datasets available for Android malware analysis and these datasets are only a collection of malicious Android applications. VirusShare [64] is one of the examples of such datasets. VirusShare has a total of 107,888 malicious Android applications. Different studies have used this dataset to learn insights into Android malware. A total of 482 features are considered and a feature vector of size xi ∈ [0, 1]482×1 has been used to feed information to machine learning classifiers.All the discussed datasets have a format that cannot be used to perform automatic malware detection using deep learning models. Most of these studies extract features from datasets, and these features are used with deep learning algorithms. Deep learning models have a very strong property, i.e., automatic deep feature extraction. They do not need handcrafted features; rather, raw data is sufficient for the training and learning process. Our proposed dataset is designed to exploit deep learning models for deep features. We have designed a dataset that can be fed directly to deep learning models. Unlike other datasets, no handcrafted features are required. The input encoded vector size isxi ∈ [−1, 1]2×1, which has very few dimensions in comparison with other existing dataset techniques.From Table3, it is clear that in terms of features extraction and embedding technique our Op2Vec dataset is far better and adaptable as compared to the other datasets. Performing the Op2Vec type embedding technique can reduce dimensions up to 2 × 1. Adopting this dataset will allow learning deep features without extraction of handcrafted features and with less computational complexity. The rest of Table 3 shows the files count in all the three datasets, malicious and benign files count, feature extraction method, and encoding techniques for features to be fed to machine learning and deep learning algorithms.Table 3
Comparisons with existing datasets.
DatasetFiles countMaliciousBenignFeature extractionFeatures setFeature vectorDrebin [26]129,013123,4535,560Handcrafted545,000xi ∈ [0, 1]545000×1Vinayakumar et al. [61]22961,609687Handcrafted42xi ∈ [0, 1]42×1Wang et al. [62]23,00013,00010,000Handcrafted34,570xi ∈ [0, 1]413×1Zhu et al. [63]11,0008,0003,000Handcrafted323xi ∈ [0, 1]323×1VirusShare [64]107,888None107,888Handcrafted482xi ∈ [0, 1]482×1Hou et al. [65]5,0002,5002,500Handcrafted1,058xi ∈ [0, 1]1058×1AndroZoo [66]3,182,5901,162,1502,020,440Handcrafted50,000xi ∈ [0, 1]50000×1Op2Vec dataset28,57012,33016,240AutomatedDeep featuresxi ∈ [−1, 1]2×1In order to demonstrate the significance of the proposed approach, some of the recent opcode-based deep learning techniques such as [67–72] are trained and tested with the Op2Vec dataset. For a fair comparison, the same experimental setup is used for the experiments with Op2Vec. It can be seen in Table 4 that the performance of the existing techniques significantly improves by incorporating Op2Vec embeddings. All the listed approaches achieve an average accuracy of 97.47%, where the highest accuracy is achieved with the setup suggested in [71]. It is evident from the results that Op2Vec which incorporates the semantic relationship of opcodes and deep features enhances the performance of deep learning techniques to detect Android malware.Table 4
Performance enhancement of existing opcode-based techniques.
Reference (Year)FeaturesDeep learning techniqueDatasetReported results (Acc) (%)Results with Op2Vec (acc) (%)Parildi et al. (2021) [67]OpcodesVirusShare and native Win7 appsRNN and LSTM9596.83Ren et al. (2020) [68]OpcodesGoogle Play store and VirusShareDNNs95.897.1Niu et al. (2020) [69]OpcodesVirusShare, Androzoo, and Pea PodsLSTM9798.77Pekta and Acarman (2020) [70]OpcodesAndrozoo, Argus group, and GooglePlayRNN and91.4296Zhang et al. (2018) [71]OpcodesMicrosoft in Kaggle 2015 and Benign appsResNet98.298.63McLaughlin et al. (2017) [72]OpcodesGenome project, McAfee LabsCNN9597.53


## 6. Conclusion and Extensions

Previous work has shown that opcodes of executables have potential information. Opcodes can be considered as features in order to make discrimination between malware and benign Android applications. But these features are very hard to extract or notify. The handcrafted features or information extraction process is very expensive in terms of cost and time. In order to automate the process and effectively identify potential information and extract deep features, end-to-end learning is a perfect solution. This study concerns the learning of Op2Vec and the development of a novel dataset for end-to-end detection of Android malware. Op2Vec learning process employs a machine-learning algorithm to learn meaningful vector representations from opcodes of Android source files. The designed opcode embedding technique is used to develop a dataset for end-to-end detection of Android malware. The dataset will be used to learn useful patterns and information from the Android source code. We have not only developed the dataset but have also presented the design process and techniques involved in the dataset development. To the best of our knowledge, we believe this is the first state-of-the-art dataset for end-to-end Android malware detection. The product dataset of this research will be made openly available for further research concerning Android malware detection. Not only the dataset but also the designed process of the dataset will be made public so that in the future, new Android application files can be added to the dataset. This will make our technique robust to deal with newly emerging Android malware.The proposed technique is one of the static Android malware analysis techniques. The limitation of this technique is that it may not capture the dynamic aspects of malware analysis. One of the future directions can be to combine the Dalvik instruction traces technique with the proposed approach to fix this limitation.



---

*Source: 3710968-2022-05-19.xml*