Android-COCO: Android Malware Detection with Graph Neural Network for Byte- and Native-Code

With the popularity of Android growing exponentially, the amount of malware has significantly exploded. It is arguably one of the most viral problems on mobile platforms. Recently, various approaches have been introduced to detect Android malware, the majority of these are either based on the Manifest File features or the structural information, such as control flow graph and API calls. Among those methods, nearly all of them only consider the Java byte-code as the target to detect malicious behaviors. However, Recent research and our own statistics show that native payloads are commonly used in both benign and malicious apps. Current state-of-the-art Android static analysis tools avoid handling native method invocation. None of those tools have the capability to capture the inter-language behaviors. In this work, we explore an ensemble mechanism, which presents how the combination of byte-code and native-code analysis of Android applications can be efficiently used to cope with the advanced sophistication of Android malware. We, therefore, present a multi-layer approach that utilizes deep learning, natural language processing (NLP), as well as graph embedding techniques to handle the threats of Android malware, both from the Java byte-code and native code. After that, we design an ensemble algorithm to get the final result of malware detection system. To be specific, the first layer of our detection approach operates on the byte-code of application and the native code level, whereas the second layer focuses on the ensemble algorithm. Large-scale experiments on 100,113 samples (35,113 malware and 65,000 benign) show that only byte-code sub-system yields 99.8% accuracy and native-code sub-system yields an accuracy of 96.6%, whereas the Android-COCO method attains an accuracy of 99.86% which outperforms various related works.


I. INTRODUCTION
The mobile phone has become a necessity in our daily life. Due to its versatility, smartphone usage has grown exponentially to reach various sectors like social networks, ecommerce and banking. According to statistics on mobile OS market shares [1], Android is the world's dominant mobile operating system, leading the market with over 83% market share in comparison to iOS and Windows. Android's enormous dominance is largely a function of being open source as well as providing users with a rich store that involves millions of various applications. Further, the brisk prosperity of smartphones along with Android's huge popularity has not gone disregarded by malware authors. Rather, Android has become an attractive platform for launching thousands of malicious applications. Recently, the number of malware has increased by leaps and bounds to reach a disturbing level. Based on McAfee's report [2], the number of discovered Android malware has touched 3.5 millions in 2021, and each more there are around 300,000 new Android malware, which has led the overall mobile malware's tally to reach 25 millions.
To defend against the threat and mitigate the alarming spread of malware, several anti-virus scanners have been provided by computer security companies such as Symantec and McAfee. Many of these products use either signaturebased [3] or code matching [4] methods. Unfortunately, these techniques have proved their incapability to keep pace with the sophistication of malware. Hence, Android malware detection has been, and still is of the essence for security researchers in both industry and academia.
In recent years, various research works [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17] have been proposed to detect malware based on machine learning and deep learning techniques. The majority of these approaches use either Android application's attributes collected from the Manifest File, specifically, Permissions, Intent-filters, and Providers. Unfortunately, these approaches can be easily bypassed by certain obfuscation techniques, such as Identifier Renaming, Code Hiding, Reflection, Dead-Code Insertion or Instruction Substitution [18] 1 . All these obfuscation methods aim to alter the application's appearance but preserve its behavior, either by encrypting the values of packages and classes or embedding useless instructions to the program [19]. In a nutshell, while these Manifest-based detection approaches offer a supplementary security control to Android, they demonstrate failure against obfuscated applications. Accordingly, some approaches go one step further by considering the source code. Researchers have figured out that the high-level properties of the code, in particular, the code structure, such as the Function Call Graph (FCG) and API calls robust against obfuscation [20], [18].
Although some of aforementioned works, like Amandroid [5], flowdroid [6], yield high accuracy results, they operate solely on the DEX bytecode, which does not lead to a thorough analysis of Android applications. A recent study shows that 86% of Android applications involve native code, allowing this latter to be a reasonable threat vector [21]. That is to say, an application with a malicious embedded native code will go undetected by a layer that merely focuses on the DEX bytecode. This motivates the need for a byte-code and native-code combination approach that characterize and generalize the malicious patterns embedded in Android apps.
In this paper, we design an ensemble algorithm to combine the byte-code and native-code malware detection subsystems(or layers). In particular, we present a layered approach that blends the structural and inter-language analysis of Android applications. To this end, our approach consists of two layers, the graph-based detection layer and the ensemble layer. For the graph-based detection layer, it includes two subsystems: • Byte-code sub-system: It is based on the DEX bytecode. It first extracts the Program Dependence Graph 1 [18] considers native code as a type of obfuscation. However, we separate it from general obfuscation techniques in Android and we mention it in the following (PDG) of the Android application, and then employs an efficient graph embedding to transform the graph's main features to vectors, which is used as an input for our neural network. In an evaluation with 100,113 samples (35,113 malware and 65,000 benign), our structural-based approach is shown to be immensely efficient, as it yields an accuracy of 99.8%, which outperforms numerous existing works. • Native-code sub-system: It is based on the native code (.so files). It employs the graph embedding technique to transform the dynamic libraries (.so files) to vectors, which is then used to feed our network-based classifier.
Large scale experiments on the used datasets result in an accuracy rate of 96.66%. After the detection sub-systems, we design an ensemble algorithm as our second-layer, which combines the output of the two MLP classifiers.
• Using the ensemble algorithm, we improve the accuracy to 99.86%. In summary, our primary contributions are described as follows: • we introduce the graph embedding to Android malware detection. We present a novel approach that employs graph embedding technology to differentiate between benign and malicious applications. We encode either the Program Dependence Graph (PDG) and function call graph(FCG) into its own vector representations. The graph's embedding captures the graph topology and hence covers every layer's specific features. To the extent of our knowledge, this is the first work that consider both the byte-code and native-code to detect Android malware. • we use ensemble algorithm to combine the results of Android malware detection We present a multilayer approach that couples byte-code and native-code analysis from two different application components. The complementary strengths among the analysis of byte-code and native code's structure creates a thorough detection system.

II. BACKGROUND
In this section, first, we throw the lights on the architecture of Android applications and the existing android malware detection techniques. Then, we introduce the used Natural Language Processing concepts, namely the embedding techniques as well as graph neural network.

A. Android Package Kit (APK)
Android applications are deployed in the form of Application Package Kit (APK), which is a zipped file that involves the app's code in the DEX file format, native libraries, resources, assets and AndroidManifest.xml file. As for the DEX file, it involves the application's code. As mentioned earlier, Android uses Dalvik virtual machine to execute applications. Hence, it uses Dalvik bytecode instead of Java bytecode. At first, the Java source code is compiled to Java bytecode by a Java compiler, which is then compiled to Dalvik bytecode by the DEXcompiler. A DEX file contains classes definitions, each class involves one or more methods'(functions') definitions. Each method(function) comprises of one or more basic block, which involves one or multiple instructions. As for the instruction's format, it consists of a single opcode and multiple operands. In overall, Dalvik has 256 opcodes. Android applications make use of 222 opcodes as the others are reserved for future usage [22].

B. Program Dependence Graph
A Program Dependence Graph(PDG) is a graph that explicitly considers both data and control dependencies. Data dependence graph(DDG) represents the program's appropriate data flow whereas the control dependence graph (CDG) illustrates the program's control flow relationships. The combination of both dependencies covers all the program's computational parts, which leads to an efficient use when it comes to programs' optimizations. As for the graph's topology, Program Dependence Graph's nodes are represented as statements or instructions, while the edges represent both the data values and control conditions necessary to the execution of the node's operations [23]. The PDG of a program P is the union of a pair of graph: the DDG of P and the CDG of P. Note that the DDG and CDG are subgraphs of a PDG. The PDG is obtained by merging the DDG and the CDG [24].

C. Word, Sentence and Document Embedding
Adapting real life scenarios into machine learning models entails the mapping of textual inputs or scripts into numerical representation that is semantically expressive. Further, to ensure a good representation of a text input, the numerical representation should catch the linguistic sense of every word in the dataset. To be more specific, an informative numerical representation can enormously impact the performance of the model. There exists several natural language processing techniques to handle text data, such as word embedding [25], [26], sentence embedding [27], and document embedding [26].
• Word Embedding: It is a numeric vector representation, obtained by embedding semantic meanings of words from a particular corpus. Word2Vec is a technique to build such an embedding based on neural network. Word2Vec can be achieved through two techniques which employ neural network. Namely, Skip-Gram and Common Bag Of Words (CBOW). Skip-Gram learns the prediction of a target word based on its neighbors, whereas CBOW uses the context to predict a target word [25], [26]. • Sentence Embedding: It follows the same concept as word embedding. It represents a sentence with a numeric vector representation. A direct and frequently used approach for embedding sentences into a vector space is to aggregate the embedding vectors of the words forming a sentence [27]. • Document Embedding: It is an extension to Word2Vec.
Word2vec learns to represent a given word to its numeri-cal vector representation whereas Doc2Vec aims at representing a document into its numerical vector space [26].

D. Graph Embedding
Nowadays, a graph is considered to be a rich input for analysis works. It has been commonly applied in various fields. Further, feeding a machine learning model with graphs is very challenging. Here, the graph embedding comes in handy and acts as a technique that turns the graph's properties to a set of numeric vector representations to feed a particular model. The rich the graph embedding is, the good the results can be achieved. Thus, the embedding should catch all the graph's significant information, which involve its topology, vertex-tovertex relationships, and vertices.
Graph embedding can be categorized into the following two types [28]. The first one is node embedding, which is used to perform either classification or prediction tasks on vertexlevel. There exist numerous works that deal with the node embedding area, such as Deepwalk [29], Node2vec [30]and Graph Convolutional Networks (GCN) [31]. Meanwhile, the other is graph embedding, which is suitable when it comes to performing classification or prediction on a graph level. There are several techniques that can be adopted to perform graph embedding, such as Structure2Vec [32] and Graph2Vec [33].

III. MOTIVATION
As we mentioned above, there are many works in the Android Malware Detection field, however, nearly all of works are concentrating on the Android Byte-code, which includes the functional behavior writing in Java language. Currently, there are more and more Android application embeds native libraries (written in C and C++ language) in them and the trend to detect and categorize Android apps becomes significant.
Therefore, on the one hand, we need a methodology which is not only able to detect Android malware byte-code level, but also native code level.
On the other hand, since the platforms to support Android OS and its ecosystem are multiple, and many IV. SYSTEM DESIGN Our system follows the principle of Detection In-Depth [34], which is a security strategy that protects an asset by implementing multiple layers of detection to avoid a single point of failure. In our context, to defend against the Android malware threat, we placed two detection models (sub-systems) that vary in terms of focus.
To be precise, our first layer operates on the application's structural information, including byte-code sub-system and native code sub-system, whereas the second layer concentrates on the ensemble algorithm to combine the two subsystems of the first layer. The advantage of coupling two detection layers is to ensure an extensive examination of different application's components. Additionally, our multilayer approach deals merely with applications that involve native code. Regarding our system's output, an application with native code is considered to be benign only if both subsystems of the first layer prove its benignity. Otherwise, it is considered a malware. For applications without native code, the classification result is fully based on the byte-code subsystem's analysis.
We formalize our two-layer malware detection system as a binary classification problem. In the first layer, we define the graph sets, which represents the structural information of the executable files and native libraries (malware and benign), as our input, like G D (V D , E D ), where V D presents the set of graph's nodes, and E D presents the edges among those nodes and D presents the number of graph. For each graph g i (g ib and g in ), it is encoded as g i (V, X, A), where A ∈ {0, 1} m * n is the adjacency matrix and m is the number of the graph's node, The goal of the first layer of our system is to learn a mapping from the G D to Y D , f : G → Y to predict whether an executable file or a native library is malicious or not. The prediction function f can be learned by minimizing the loss function in Eq. 1. For the second layer, we use the logic gates ensemble to combine the results of two classifiers in the first layer. We will implement for formalized model in the following, where g i (g ib and g in ) in Eq. 1 is our graph embedding and f (f b and f n ) in Eq. 1 is our MLP-classifier(we use two MLP classifiers).

A. Byte-code based Malware Detection
The first subsystem of our approach deals with the DEX bytecode. We designed our first subsystem to deal with the DEX bytecode of Android applications. Accordingly, to obtain the main features of the DEX bytecode, we need to get the execution paths that fully covers the program. Unfortunately, with traditional analysis, this could hardly be achieved. As a result, graph-based techniques have been introduced, as they produce rich data representations. Contrary to early graphbased malware detection approaches that employed control flow and function call graphs to detect obfuscated parts of the code, our approach utilizes the Program Dependence Graph (PDG), which applies both data and control analysis. To put it differently, a PDG combines an explicit representation of data and control flow relationships of an Android application, which exposes the full program structure. Although malware variants vary in terms of code appearance due to obfuscation, they share one common program structure, which can be plainly observed by analyzing their PDGs. As illustrated in Figure 1, the structural byte-code subsystem is a five-step process. After the application's disassembling, we encoded every basic block to its corresponding vector and extracted the PDG. Next, we converted the entire PDG to a numerical vector of real numbers to feed our neural network. 1) Opcode Embedding: As described in Section II-A, Android applications are developed in Java and utilize a Dalvik virtual machine to execute. That is to say, an application's source code is first compiled to Java bytecode, then translated to Dalvik bytecode and saved in DEX. In the first subsystem of our malware detection approach, our aim is to tackle the DEX bytecode using the PDG, which models both control and data flow relationships. Consequently, after the disassembling phase, we merely considered Dalvik executable files. Further, capturing the PDG's topology requires handling both control and data dependencies found in an application. To this end, we treated every basic block of an application as a node. Additionally, we considered edges to express links bridging values' definitions and their uses to ensure a broad coverage of all the application's methods. Before casting the lights on the opcode embedding phase, it is important to understand the format of a basic block, which is a series of sequential instructions that are executed consecutively with no jumps in the middle [35]. A basic block can involve one or more instructions. Each instruction is composed of two elements, opcode, and operand. Our aim is to capture the context of every instruction in a basic block. Thus, we embedded each instruction to its corresponding vector.
We used opcode as an our input to build our corpus of vectors using the Word Embedding technique. Regarding the implementation of this step, we first built a large unsupervised corpus of opcodes extracted from our datasets. To this end, we used Androguard to retrieve an application's set of opcodes. Androguard has a function AnalyzeAPK that returns three objects, precisely, an Apk object, an array of DalvikVMFormat and Analysis object. Each object has its purpose. The Apk object involves all the contextual information of an application, such as package name and permissions. As for the DalvikVM-Format, it corresponds to the DEX files in an Apk. As for the Analysis object, it provides all the details of classes, methods, and fields found in an Apk. In this context, we used the DEX object, as it provides all the details related to classes, methods, and fields. For every method in an application, we retrieved all its instructions' opcodes. Next, for mapping each opcode to a vector of real numbers, we used Word2Vec [25] model with skip-gram method. To be specific, we tried to predict each word's context given a specific opcode. As defined in Section II-C, Word2Vec is an implementation technique of word embedding technology. It employs a neural network with one hidden layer to vectorize words. To implement the Word2Vec model, we used TensorFlow library [36] which provides a rich set of features that allow users to express data computation in an easy fashion. As parameters, we set the embedding size to be 64 and the window length to 1, as we wanted to take only one word in the chain.
2) Basic Block Embedding: After mapping every instruction's opcode into a single vector. We encoded each basic block to its corresponding vector by taking the mean of all its instructions' vectorial representations. In this step, we directly averaged all opcode embedding occurred in a basic block. Assuming each basic block BB includes n-opcode and each opcode is represented by a l-dimensional vector.
The output of the basic block embedding step is one single vector that represents a node.
3) Program Dependence Graph Construction: After mapping each vector to its corresponding vectorial representation, we constructed the program dependence graph for every application in our datasets. As mentioned before, every basic block in an application constitutes a node in its program dependence graph. Accordingly, for every basic block in a method, we vectorized it by averaging of all its instructions' vectors. We extract our program dependence graph with the assistance of Androguard. Further, we built edges by bridging every basic block to its related children. To this end, we used NetworkX [37], a python library for the creation and manipulation of networks. Further, in a network, two nodes should not have the same naming. To be precise, every node in a graph should have a unique name. In the context of machine language, instructions tend to be repetitive, which may lead to disregarding many nodes. Assuming a method has 2 basic blocks with the following opcodes: B 1 = B 2 = {const, move, goto}, the graph will disregard B 2 , as the encoding of both basic blocks is identical. To avoid this obstacle, we considered two sections in a node's construction, one for the embedding vector, whereas the other for its identifier. Therefore, for every basic block, we selected its parents' details, mainly the corresponding class and method descriptions.
4) Program Dependence Graph Embedding: Consequently, after the program dependence graph's construction, we transformed the entire graph to a vector of real numbers. To this end, we used Structure2Vec [32] as a graph embedding framework. Based on the graph topology, Structure2Vec technique aggregates recursively vertex features. Then, the network generates a new embedding of features for every vertex. As shown in Algorithm 1, Structure2Vec based-network starts with an initial embedding at vertex 0 and updates the embedding at every iteration. To obtain the final vector embedding, we took the average of all iterations results. The Structure2Vec process takes two inputs, precisely, an array of nodes' embedding vectors that capture their related properties and adjacency matrix of the program dependence graph, which gives information about the graph's topology, mainly, nodes' connections. In a nutshell, Structure2Vec process is executed as follows: ) return v f Algorithm 1: PROGRAM Dependence Graph Embedding 5) Structure-based Neural Network: After the graph embedding phase, we designed a Multi-Layer Perceptron (MLP), which is a neural network with nodes as neurons with logistic activation. Our aim is to identify whether an application is benign or malicious. Thus, our detection approach is a binary classification process. Accordingly, we designed our neural network to have 64 input neurons, which is equal to the embedding size of an application's program dependence graph. As for the output, we select 2 neurons, one for the benign class, whereas the other for the malware class. Regarding the number of hidden layers, although these layers are not directly interacted with the external environment, we selected 2 hidden layers to tremendously impact the final output. In a nutshell, our neural network can be expressed as the following formula: W 1 and W 2 , represent by wi 1 , wi 2 ∈ R p , the weights of two hidden layers of our neural network. bi 1 , bi 2 ∈ R p are the offsets from the origin of the vector space. In this setting, based on the activation function's output, a program dependence graph G h can be classified as malicious if f (G h ) > 0 or benign if f (G h ) < 0.

B. Native-code based Malware Detection
Nowadays, several Android malware detectors make use of static analysis techniques. They operate only at the bytecode level, which enables malicious payloads embedded in native code to go invisible as a type of obfuscation technique. As a result, to achieve complete analysis of Android applications, we need a second subsystem that operates on the native code level. In this section, we discuss the structural native-code malware detection subsystem which deals with the native code of Android applications. As illustrated in Figure 1, our second subsystem is a four-step process. 1) FCG Extraction: As a first step, we disassembled Android applications and extracted function call graph based on Angr [38], a python framework for analyzing binaries.
2) Function Embedding: As a second step, to catch the function call graph topology, we need to consider each function as a node. Normally, a function can involve one or more basic blocks. Each basic block can contain one or more Dalvik instructions. Therefore, our target is to consider every instruction in a function. To this end, we utilized the SIF [39] network to compute the function embedding by using the sequence of instructions vectors generated by the Word2Vec method.
Input: Instruction embedding v i : i ∈ I, a set of instructions, parameter α and estimated probabilities p(i) : i ∈ I of the instruction. Output: Form a matrix X whose columns are v f : f ∈ F , and let v be its singular vector Based on natural language processing (NLP), given the discourse vector c f , the probability of an instruction which is emitted from the function f is modeled by, wherec f = βc 0 + (1 − β)c f , c 0 ⊥ c f , where α and β are scalar hyperparameters, and Zc f = i∈f exp(<c f , v i >) is the normalizing constant.
The function embedding will be defined as the max likelihood estimate for the vector c f that generated it. By the model (3), the likehood for the function is (4) Let denote the log likelihood of function f as follows: After gradient computation and Taylor expansion, we get the maximum likelihood estimator forc f on the unit sphere is: That is the max likelihood estimate is a weighted average of the vectors of the instructions in one function. To estimate c f , we computed the first principal component of c f for a set of functions as the direction of c 0 . We present our simple function embedding method in Algorithm 2.
3) Function Call Graph Embedding: After getting every function's vector, we converted the graph's nodes and edges into vector space to feed our neural network-based classifier. To this end, similarly to program dependence graph embedding, we used Structure2Vec as an embedding framework. Algorithm 1 describes our function call graph embedding. 4) Native Code Malware detection: After the graph embedding step, we designed our multi-layer perceptron (MLP). Similarly to structural malware detection, our approach is a binary classification process. Thus, in our work, we followed the JN-SAF [40] methodology and label all the native libraries included in the following malware families (Boqx, Droidkungfu, Gumen, Lotoor, Ogel, Slembunk, Updtkiller, and Vikinghorde) as malware. For benign samples, we use all labeled native libraries like the JN-SAF [40].

C. Ensemble mechanism
After getting the outputs of two multi-layer perception(MLP), we have designed an ensemble algorithm to combine the two MLP's results during the training and testing step. The weight of two MLP are trained at the training step.

V. EVALUATION
In this section, we evaluate the performance of our layered Android malware detection approach. We apply and check our proposed model against two public malware datasets, namely DREBIN [13] and AMD [41], and one self-collected malware dataset based on VirusTotal [42] API. As for the benign samples, we used AndroZoo [43].   [41]. • AndroZoo-Malware: Besides aforementioned malware datasets to evaluate the classification issue, we also consider AndroZoo as malware source in order to solve the biased datasets issues (mentioned by TESSERACT [44]), both from the temporal and spatial biases. Following the guideline of TESSERACT, we select malware and spatial biases. Following the guideline of TESSERACT, we select malware and benign samples ratio with 10% and 90% (to solve spatial bias), both for the training and testing. In addition, we select our samples from 2017.12.30 to 2019.12.30 (to solve temporal bias). Additionally, we also use VirusTotal to prepare our dataset. But we set our threshold as follows: p 2 = 0 for benign and p ≥ 4 for malware. In total, we find out 5,000 malware samples. • AndroZoo-Benign: A huge collection of Android application gathered from various sources. It involves more than 10 millions applications [43]. We used VirusTotal [42] to scan applications with over 70 antivirus scanners. Additionally, we used a threshold of 4 scanners to label samples. That is, if more than 4 scanners mark an application as malware, we labeled it a malicious. Otherwise, it is considered benign. Our scanning process resulted in 65,000 benign applications. All in all, our dataset can be summarized as Table I, which includes 35,110 malware and 65,000 benign samples.

B. Structural-based Classifier Evaluation
In our structural classifier, we evaluated our malware detection system with the following parameters. We set our batch size to 1. This means, we have trained and tested our classifier with only one program dependence graph in each step. Also, we set our epochs to 30 to achieve optimal training. Further, the used datasets were randomly split into 70% training and 30% testing. In the same manner, as the first layer, we concentrated on the accuracy, precision, recall, F1. As shown in Table II, our testing experiments yield an accuracy of more than 99% on both datasets. This indicates the efficiency of the vectorial representation of the program dependence graph on identifying the structural malicious patterns in an application. Meanwhile, other metrics, such as recall, F1 are also producing significant results. Figure 2 presents the ROC characteristic of our structural-based classifier.
We can see from the Table II that the results for the Ensemble is same with Byte-code based method. The reason is that we did not find any benign applications(byte-code) which hides their malicious behaviors into the native code, but the byte-code level act as benign(this result is same with the [45]) . At the same time, we also find that most applications which act as malware at native code, have multiple native code libraries, but only one or two of them act malicious behaviors. Taking into account that no previous related work has been done on the Drebin dataset, we extracted native libraries from the AMD dataset only. As a result, we obtained 16,387 .so files including seven different architectures namely ARM64, ARM32v7, MIPS, MIPS-r2, X86, X64. Further, all the native libraries that belong to the following families: Boqx, Droidkungfu, Gumen, Lotoor, Ogel, Slembunk, Updtkiller, and Vikinghorde, are considered as malicious native libraries. Moreover, 1,191 of native libraries has ARM architecture. The rest of the architectures has been skipped, as they involve a small number of native libraries. In this experiment, we split our dataset into 70%training data and 30% testing data.
As shown in Table II, Our second classifier achieves an accuracy of 96.6%. Compared to the structural layer, the performance has dropped. This could be linked to the used dataset's size, as we could not get enough information from previous related works.
To contrast with our method, we get 96.6% AUC with the Drebin method and 89.85% with Droidmat on our mixed dataset. Additionally, Adagio gets a lower AUC value, around 87.39%. 3

C. Features Processing and Training Overhead
All work was done on Euklid, a SUSE Linux server with 128Gb RAM's size. Table III illustrates the training time of both structural and inter-language classifiers. We can see that our inter-language MLP is trained much faster than our structural MLP. Regarding features processing, taking a look at Table III, it is seen that FCG extraction is nearly three times faster than the PDG's construction. This is related to the number of nodes a graph may involve. A PDG may contain more than 60,000 nodes, which requires a large amount of hardware and time.

D. Robustness of Structural-Based Approach
With the fruits of neural networks are unquestionable, recent researches have demonstrated that they fail to exhibit robustness against adversarial inputs. Adversarial samples are usually generated from tweaking the regular inputs through small and calculated perturbations to prompt the model to intentionally output wrong classifications.
1) Crafting Adversarial Malware Inputs: In Android malware detection, the aim of adversarial inputs is to cause the classifier to change its output based on the attackers' goals. Further, our structural-based approach depends on feeding the neural network with an application's program dependence graph embedding. Hence, our primary target is to craft malicious embedding vectors to dupe the model into misclassifying inputs. Generally, when it comes to crafting a malicious graph, there exist several techniques to construct adversarial samples, namely, N-strongest nodes [46] which is based on selecting and injecting nodes with biggest impacts on the adjacent nodes till the misclassification is achieved. Another commonly used technique is Random Node Injection [46], this latter is based on the random injection of nodes into a graph. In our work, to obtain crafted malicious inputs, we used the Gradient-based approach.
2) Gradient-Based Approach: Our adversarial attack focuses on increasing the misclassification rate. As mentioned in the previous sections, we feed the structural-based neural network with the program dependence graph embedding, which is represented as a numeric vector that can be manipulated to obtain the desired output. To this end, our work involves calculating the gradient as well as adding the appropriate perturbations, which results in a 4 steps process: 1) We calculated the gradient through the following loss expression: where X is the program dependence graph embedding vector, W 1 and W 2 are the network weights, B 1 and B 2 are the network offsets, and Y is the label. In a neural network, the gradient is usually used as an optimization algorithm to minimize the cost with respect to weights for better adjustments. Since our objective is to craft malicious malware samples, we need to construct embedding vectors such that the loss is maximized. In this case, instead of weights, we calculated the gradient by taking the partial derivative of the loss function with respect to X, which is the program dependence graph embedding vector.
2) We took the gradient sign to know which way to follow to maximize the loss, either by increasing or decreasing the embedding vector. 3) In this step, we multiplied the gradient sign by epsilon , which is a small value constant to make sure that our    3) Model Robustness Evaluation: With our neural network has yielded high accuracy on the used datasets, their accuracy drops slightly in the presence of adversarial perturbations to test samples. As shown in Figure ??, as the test set grows in size, the accuracy on the adversarial inputs moves closer to the accuracy achieved on normal test samples. Our experiment involves 4 testing stages, each with different dataset sizes. We selected 100, 500, 1000 and 2000 as size metrics to show the difference in the accuracy's behavior on both normal and adversarial samples. With 100 samples, the accuracy drops by nearly 17% Next, the accuracy rate increases proportionally to the size of the dataset. At stage 4, with 2000 samples as a test set, for both datasets, the drop rate has reached 1%, which proves that our neural network is robust against the crafted adversarial samples.

VI. RELATED WORKS
Over the recent years, the detection of Android malware has been under the spotlight of security researchers. Besides the traditional methods such as signature-based and code matching methods, a huge amount of work has been invested into proposing various Android malware detection using machine learning techniques. In the following, we first discuss related works on the structural detection of Android malware using graphs. Next, we proceed to present techniques specifically related to inter-language analysis of Android applications.

A. Android Malware Detection
Drebin [13] presents a broad static analysis to detect the Android malware. It evaluates 123,453 applications and 5,560 malware samples. Drebin detects 94% of the malware with few false alarms and requires 10 seconds for an analysis on average.
In-the-lab and In-the-wild validation [47] presents several machine learning classifier that only on a set of features build from applications' CFGs. It shows that in the lab the performance outperforms existing machine learing-based approaches. Meanwhile, in the wild scenarios the performance gap, especially F-measure dropping from over 0.9 in the lab to below 0.1.
Mamadroid [48] presents an Android malware detection system that relies on app behavior. It builds a behavior model, in the form of a Markov chain, from the sequence of abstracted API calls performed by an app, and uses it to extract features and perform classification. By evaluating on a dataset of 8.5 K benign and 35.5K malicious apps, Mamadroid shows that it not only effectively detects malware(with up to 99% F-malware), but also that the model built by the system keeps its detection capabilities for long periods of time (on average, 86% and 75% F-measure, respectively, one and two years after training).
CWLK [12] presents a method to enrich the feature space of a graph kernel that inherently captures structural information with contextual information.It applies the feature-enrichment idea on a state-of-the-art graph kernel, namely, Weisfeiler-Lehman Kernel(WLK) to obtain the Contextual Weisfeiler-Lehman Kernel(CWLK). CWLK evaluates with more than 50,000 Android apps, and outperforms two graph-kernels and three malware detection techniques by more than 5.27% and 4.87% F-measure, respectively, while maintaining high efficiency.
CDGDroid [11] uses the semantics graph representations, that is, control flow graph(CFG), data flow graph(DFG), and their possible combinations, as the features to characterise Android applications. It encodes the graphs in to matrics, and use them to train the classification model via Convolutional Neural Network(CNN). In more detail, given a CFG(or DFG) g, CDGDroid encodes it into a matrix A with size 222*222(total opcodes number in the Android Dalvik-bytecode list) as follows: for each edge (n1,n2) ∈ g.E, CDGDroid add the element A[op(n 1 )][op(n 2 )] by 1, where A is initialized as a zero matrix with size 222*222 and op(n) returns the opcode of the node n.

B. Structural Detection of Android Malware
Recently, building an obfuscation-resilient Android malware detection has become an urgent demand. Accordingly, many structural approaches have been proposed to identify malicious patterns via control flow graphs or call graphs. For example, Gascon et al. [10] present a method for malware detection based on efficient embedding of function call graphs with an explicit feature map inspired by a linear-time graph kernel. They conducted experiments on 12,158 malware samples, achieving an accuracy of 89%.
Additionally, Ma et al. [49] present an approach of Android malware classification based on supervised learning on the network properties of control flow graphs. Their evaluation was performed on 10010 benign applications and 10,683 malicious applications, attaining 98.98% detection precision with high accuracy. In our approach, we differentiated ourselves from previous works by employing the PDG which considers the composition of both functions and data entirely. Also, we utilized the graph embedding technique to transform nodes and edges into vector space while preserving their properties. Moreover, the accuracy score of our structure-based neural network was above 99% on both datasets.

C. Inter-language Analysis of Android Malware
With nearly all detection approaches focusing on the Manifest attributes as well as the bytecode level of Android applications, malware authors employ various obfuscations techniques on the native code level to create malware variants. In other words, the native code has become a potential threat vector that can go overlooked by existing detection systems. Consequently, Several methods have been proposed to operate on the interlanguage side of Android applications. For example, Alam et al. [50] present DroidNative, an Android malware detector that operates on both native and bytecode level by using specific control flow patterns to reduce the effect of obfuscations and provides automation. Additionally, Wei et al. [51] present a new approach to conduct inter-language dataflow analysis of Android apps and build an analysis framework, called JN-SAF to compute flow and context-sensitive inter-language points-to information in an efficient way.

VII. LIMITATIONS
Any Android malware detection work is immensely proportional to the quality and quantity of the used dataset. In our work, with the process of collecting benign samples is direct, gathering sophisticated Android malware is a demanding task that entails technical efforts. Apart from that, the main limitation of our layered approach is the training phase of our structural layer which employs graph embedding. As we use program dependence graph, the majority of the extracted graphs have a huge amount of nodes which demand a largesize main memory (RAM). Unfortunately, with a RAM of 128 Gb, the process of extracting a graph with more than 90,000 nodes gets killed. Consequently, we disregarded any graph with more than 90,000 total of nodes. Moreover, in terms of robustness evaluation, we had no adequate time to largely assess the robustness of the inter-language layer using adversarial attacks.
VIII. CONCLUSION AND FUTURE WORK In this paper, we presented an approach that employs the principle of detection in depth. To be specific, our method blends two detection techniques that handle different aspects of an Android application. Our structure-based layer focuses on the structural side of an Android application, specifically the code's properties and their relationships, whereas the interlanguage layer acts on the native code level. Further, the use of graph embedding technique is shown to be efficient, as it led us to achieve high performance. As far as we know, this is a first work to combine both byte-code (DEX file) and nativecode (SO file) in Android malware detection. Hence, adapting this technique to other areas, such as desktop malware and phishing detection seems to be an interesting avenue for future research.