# DroidHunter: A Robust Vision-Based Detection Against Hidden Android Malware

Victoire Nganfang, Simon Queyrut, David Bromberg, Valerio Schiavoni, Djob

Mvondo, Vianney Kengne Tchendji

► To cite this version:

Victoire Nganfang, Simon Queyrut, David Bromberg, Valerio Schiavoni, Djob Mvondo, et al., Droid-Hunter: A Robust Vision-Based Detection Against Hidden Android Malware. ASIACCS 2026 - 21st ACM ASIA Conference on Computer and Communications Security, Jun 2026, Bangalore, India. 10.1145/3779208.3785386. hal-05419946

HAL Id: hal-05419946

https://hal.science/hal-05419946v1

Submitted on 8 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# DROIDHUNTER: A Robust Vision-Based Detection Against Hidden Android Malware

Victoire Nganfang

victoire.nganfang@inria.fr

Univ Rennes, CNRS, INRIA, IRISA

Rennes, France

Simon Queyrut

simon.queyrut@unine.ch

University of Neuchâtel

Neuchâtel, Switzerland

Yérom-David Bromberg

david.bromberg@inria.fr

Univ Rennes, CNRS, INRIA, IRISA

Rennes, France

Valerio Schiavoni

valerio.schiavoni@unine.ch

University of Neuchâtel

Neuchâtel, Switzerland

Djob Mvondo

bmvondod@inria.fr

Univ Rennes, CNRS, INRIA, IRISA

Rennes, France

Kengne Tchendji Vianney

vianneykengine@gmail.com

University of Dschang

Dschang, Cameroon

## ABSTRACT

Due to their large popularity, Android smartphones are often targeted by malware attacks. Several strategies exist to detect malware code. However, we show that they are insufficient when dealing with obfuscation techniques. DROIDHUNTER is our novel method for detecting Android malwares. DROIDHUNTER leverages opcodes and their parameters, transforming those into RGB images and specific encoding techniques. The generated images are then used to train two different classification models based on support vector machines, convolutional neural networks, and a vision-based transformer. We evaluate DROIDHUNTER on several datasets with up to 476,937 APKs from multiple sources. With detection rates from 98.65% to 99.94%, DROIDHUNTER overcomes nine state-of-the-art malware detection techniques, including Drebin, MaMadroid, DexRay. Moreover, DROIDHUNTER demonstrates strong resilience against hidden malware with detection rates up to 98.98%, and shows robustness on newly emerging threats, achieving an AUT of 0.89 on recent malware samples. We release our code to the research community, with instructions to reproduce our evaluation available at: https://zenodo.org/doi/10.5281/zenodo.10977166.

## KEYWORDS

Malware detection, Android, Opcode analysis, Machine learning, Convolutional neural networks, Transformer model

## 1 INTRODUCTION

Android, with a 71.43% global market share [6], is frequently targeted by cybercriminals. Malwares can compromise Android devices by accessing personal data, stealing sensitive information, or taking full control [39]. This malware proliferation poses a significant threat, prompting the need for more robust detection techniques [37]. Traditional signature-based detection methods are limited, leading to the rise of machine learning-based scanners [3, 10, 13, 42, 43, 59, 61]. Feature extraction, a key part of these approaches, aims to capture application behavior for training and testing classifiers. Choosing the optimal features for accurately modeling behavior remains a major challenge [21, 27].

Hence, recent approaches leverage opcode (OP) analysis to directly derive features from binary code, rather than using specific feature extraction methods (e.g., analyzing the application behavior via its call graph). Among these new trends, some detect malware by using image representations of their related bytecodes [27, 44].

<figure><img src="image_2.png" /><figcaption>**Figure 1:** How three classes of detectors (circles) fare on our four datasets (squares). The small text boxes indicate the average accuracies of those detectors against the connected datasets. For the sake of simplicity, we only indicate high and low accuracy average values here.</figcaption></figure>

**Obfuscation- and drift-fragile ML-based scanners.** Existing ML-based static scanners, although powerful, remain highly sensitive to code obfuscation and temporal drift [83]. Obfuscation techniques, widely used by malware developers, distort the syntactic or semantic structure of an APK without changing its behavior. Common examples include identifier renaming (methods, classes, fields), control-flow modifications (insertion of goto or junk instructions), string or resource encryption, and code reordering [17, 53, 64]. These transformations are designed to mislead detectors that rely on shallow or brittle features such as API sequences, manifest entries, or raw n-gram distributions. In addition to code-level obfuscation, certain transformations modify the structure of the APK rather than its semantics. These light packing operations [31] (e.g., Rebuild, NewAlignment, NewSignature), typically applied via automated repackaging tools perturb the binary-level structure while preserving access to the Dalvik code. Unlike strong crypto-based packers (e.g., Banggle [85], Qihoo [26]), which encrypt the entire bytecode and make static analysis methods [15] which involve examining the application's code and resources without executing it, practically impossible, light packing leaves the code accessible but disrupts structural features exploited by many detectors.

Another major challenge for ML-based malware detectors is concept drift [25], i.e., the natural evolution of malicious code over time. A detector trained on older malware families may quickly become obsolete when confronted with new threats that diverge from the original training distribution.
To assess the effect of these phenomena (i.e., obfuscation/light packing and concept drift) on state-of-the-art malware detectors, we depict in Fig. 1 the average accuracy achieved for three categories of ML-based detectors. $C_1$ are binary classifiers employing specific feature extraction methods but don't explicitly use opcodes ($C_1$={Drebin [13], MaMaDroid [61], MalBERT [66], Reveal-droid [40]}). $C_2$ are detectors that disassemble the executable of the APK to extract features from opcodes ($C_2$={Kang and al. [46]}). $C_3$ leverage opcodes through image representation and generally without disassembling the executable ($C_3$={SHERLOCK [72], R2-D2 [44], DexRay [27], ViT4Mal [69]}).

All scanners from $C_1$, $C_2$, $C_3$ are trained and tested on a baseline training dataset *DroidTrain* covering applications from 2011 to 2018 built on datasets commonly used in literature (see §4.1). To evaluate resilience to obfuscation, we construct a dedicated dataset, *DroidObPack*, obtained by repackaging applications with obfuscation [11]. This dataset applies a variety of transformations, including classical obfuscation techniques (renaming, junk code insertion, control-flow perturbation, string/resource encryption) as well as complementary light packing operations (rebuilding, re-signing, alignment) [11, 58, 68]. We further assess their robustness to concept drift using a dataset we refer to as *DroidDrift*, composed of Android applications collected between 2019 and 2024. This dataset aggregates samples from widely adopted benchmark datasets in the literature [9, 57, 80, 81], and includes a balanced mix of benign and malicious applications across diverse malware families and behaviors. Fig. 1 intuitively shows that all detectors fare well on the *DroidTrain* dataset, but handle concept drift (*DroidDrift*) rather poorly. Performance on obfuscated APKs (*DroidObPack*) is also poor except for $C_2$-type scanners. $C_3$ perform slightly better than $C_1$ (full results shown in §5).

Based on the aforementioned results, we harness the best of $C_2$ and $C_3$-type scanners and propose DROIDHUNTER, a new malware analysis approach specifically designed to resist obfuscation and light packing, while maintaining robustness under concept drift. Unlike existing ML-based detectors that fail to extract meaningful features when the code is obfuscated or lightly packed, DROIDHUNTER preserves instruction-level semantics through its pixel encoding process. This ensures that each Smali instruction translates into a consistent visual signal, thereby retaining critical behavioral information and making it robust against common obfuscation and light packing transformations. We also evaluate its robustness under concept drift, used here as a metric to assess generalization over time. DROIDHUNTER takes a bit from $C_2$ and stays true to $C_3$-type detectors overall. It disassembles the APK to extract a sequence of instructions from the Smali code. Each instruction is encoded as an RGB pixel. This produces an image-based representation that preserves instruction-level semantics and is well suited for vision-based classification (see §3.2).

We train two models tailored for image classification: (i) a Vision Transformer (ViT) model, and (ii) a convolutional neural network (CNN). The choice of the former model is inspired by the results in Alexey et al. [32], which demonstrates that ViT can learn effective representations for image recognition. The latter is based on previous studies indicating that using CNNs as automatic feature extractors yields better results for malware classification [49, 50, 74].

The features extracted by the CNN are used as input for a Support Vector Machine (SVM), which we find improves classification performance. While obfuscation and concept drift are orthogonal challenges, both significantly degrade the performance of static ML-based malware detectors. Our method addresses both challenges by learning from low-level instruction-level representations that rely less on high-level features (e.g., API calls or manifest structure), making it more resilient to both obfuscation and malware evolution. The contributions of this paper are as follows.

* We propose DROIDHUNTER, a novel approach for detecting Android malware using deep learning models designed for computer vision, trained on RGB images made from opcodes and operands of Smali code.
* We set up a dedicated testbed including two datasets: *DroidObPack* designed to evaluate robustness against obfuscation and light packing techniques, and *DroidDrift* designed to assess resilience to temporal concept drift.
* We compare DROIDHUNTER against nine state-of-the-art malware detectors across three categories ($C_1$, $C_2$ and $C_3$), releasing the implementation at: https://zenodo.org/doi/10.5281/zenodo.10977166. Our extensive evaluation shows that DROIDHUNTER consistently outperforms these approaches while maintaining robustness across datasets.
* Finally, we discuss model explainability, addressing the challenge of tracing predictions back to significant features and the risks of model opacity.

**Roadmap.** In §2, we provide details on the foundational components of the current solutions that detect malware. We describe the limitations of state-of-the-art approaches in §2.2. §3 describes the architecture of DROIDHUNTER, whereas §4 details our experimental methodology, as well as our datasets and baselines. We report on our extensive evaluation of DROIDHUNTER in §5. The model explainability analysis is reported in §6. We survey related work in §7, before concluding and outlining future work in §8.

## 2 BACKGROUND

Many malware detectors explore how to learn features directly from opcodes using ML algorithms ($C_2$-type detectors in our terminologies), and more recently, algorithms from the field of computer vision via a spatial-preserving image representation of opcodes ($C_3$-type detectors).

### 2.1 Analyzing Smali opcodes

Opcodes are symbols or alphanumeric codes that represent the low-level operations executed by a processor. Extracting opcodes from an executable allows one to characterize its behavior. In the context of Android apps, there are different tools and techniques to extract opcodes, e.g., APKTool [70]. The Smali file [90], obtained when extracting APKs, embeds human-readable mnemonics that represent opcodes, i.e., Invoke for function calling, Move for moving data, etc. There are currently up to 256 valid opcodes. Specialized disassemblers, i.e., Baksmali [87], analyze Smali files, convert binary instructions into understandable mnemonics, and reconstruct the original program structure. The opcodes can also include details regarding registers, memory addresses, and constant values [8].
<figure><img src="image_3.png" /><figcaption>Figure 2: Architecture and workflow of DROIDHUNTER.</figcaption></figure>

Learning from opcodes. Using opcodes to directly learn features from raw data rather than pre-specifying specific features to extract is not a novel approach. Numerous attempts have been made in recent years to explore this method, yielding promising results. Some studies focused on monitoring malware's evolution through analyzing opcode sequences and permutations [47]. ML techniques, e.g., logistic regression, (deep) neural networks, decision trees (DT), can automatically identify critical instruction sequences [76], and hence try to differentiate malicious from benign applications. Statistical analysis of opcode frequency distributions successfully distinguishes between malicious and non-malicious code [18], as in malicious software, opcode distributions often differ from those of benign software. Other approaches utilize n-grams over opcodes, resulting in sequences of n consecutive opcodes extracted from the code of an application, to identify patterns for detecting malwares [46]. Fig. 1, grounded in our evaluations (see §5), supports that the incorporation of opcodes (OPs) into the detection process enhances robustness against obfuscation and light packing, but does not fully address the concept drift challenge.

## 2.2 Leveraging Computer Vision

There has been increasing attention from the field of computer vision to leverage learning capabilities to analyze visual characteristics and patterns of malware to achieve more robust detection [88]. In this study, we harness both (i) Vision Transformers (ViTs) and (ii) Convolutional Neural Networks (CNNs) [55]. When CNNs are used as feature extractors only, the layer that carries the classification consists of a Support Vector Machine (SVM) [41]. SVMs have been used in the domain of malware detections [36, 54, 89].

Boundaries of existing approaches. While $C_3$ vision-based approaches are promising, Fig. 1 shows that they remain fragile in the face of advanced obfuscation techniques (e.g., packers), or concept drift [25]. These approaches do not capture enough visual and structural features of the code, nor the spatial relationships among opcodes and their parameters. Moreover, despite their strength in capturing low-level instruction patterns, opcode-based methods exhibit limited resilience against sophisticated obfuscation strategies. This shortcoming arises because these approaches primarily analyze raw opcode sequences without considering opcode parameters, thereby missing broader semantic context and subtle control flow variations. Consequently, they are vulnerable to code transformations that reorder, insert, or encrypt instructions without altering the actual program behavior. Bluntly reading opcodes and their parameters from the bytecode, without disassembling the executable of the APK, like one of the baselines we compare to (R2-D2 [44]), can yield disappointing results as shown in §5.3. DROIDHUNTER follows a different approach; it builds RGB images from frequencies of opcodes and their parameters. Doing so, DROIDHUNTER adopts a more refined strategy by combining the disassembly-based

<figure><img src="image_4.png" /><figcaption>Figure 3: Smali instruction encoding process.</figcaption></figure>

precision of $C_2$-type detectors with the learning capabilities of image-based approaches from $C_3$. It disassembles the APK and extracts complete sequences of Smali instructions, then encodes each instruction—along with its operands—into a structured visual representation. This richer encoding preserves instruction-level semantics and embeds both syntactic and contextual information, enabling the model to better capture behavioral patterns that would otherwise be distorted by obfuscation or packing. Leveraging Explainable AI (XAI), we further provide insights (see §6) that indicate DROIDHUNTER improvements over baseline vision-based methods.

## 3 DROIDHUNTER

DROIDHUNTER's detection workflow consists of a three-phase processing pipeline depicted in Fig. 2. The first phase (❶) involves extracting opcodes and their parameters from APK files. In the second phase (❷), each complete instruction is encoded as a single RGB pixel using precomputed lookup tables. Finally, the third phase (❸) classifies applications into benign and malicious classes.

### 3.1 Phase ❶ – Opcodes extraction

APK is the standard format for packaging and distributing Android applications, allowing users to easily install and run mobile apps on the Android operating system. APK files encompass several essential components [7] such as code, resources, assets, and a manifest file, all bundled together. Particularly, code is expressed in the form of binary files containing Dalvik bytecode, commonly referred to as Dex (Dalvik Executable) files executed by the Dalvik virtual machine (until Android 4.4), or Android Runtime (ART) starting from Android 5.0 (Lollipop). Dex files can be disassembled into Smali files using tools such as APKTool [4] or Baksmali [1]. Smali files represent Dalvik bytecode in a textual, human-readable format, enabling developers to better understand Android app internals. Fig. 3 depicts the opcode extraction and encoding phase. In a nutshell, Smali includes instructions, each made up of two main parts: the mnemonic (opcode) and the operands. The former
<figure><img src="image_5.png" /><figcaption>Figure 4: RGB image generation process</figcaption></figure>

represents the specific operation the virtual machine needs to perform (e.g., `invoke-virtual`, `move-result`, `if-eq`, etc.). The latter provide the values required for the operation, and can take various forms (e.g., registers, constants, method or field signatures, etc.). Currently, there are 256 possible opcodes in the Smali instruction set. Analyzing Smali opcode patterns can help researchers spot suspicious instructions or abnormal code sequences and identify specific malware signatures [75]. In DroidHunter, each instruction is individually parsed and mapped into a triplet consisting of the opcode and its two main arguments (*Op1*, *Op2*). These components are then encoded into a single RGB pixel using two frequency-based lookup tables: *Op_dict* for assigning a unique identifier to each opcode, and *Arg_dict* for assigning identifiers to operand strings. If an instruction contains only one operand, the second is set to "NONE"; if none are present, both are assigned "NONE". This uniform parsing ensures compatibility with the encoding process described in §3.2. Accordingly, the core principle of DROIDHUNTER is to comprehensively capture both temporal orderings (i.e., the order in which they are executed) and the spatial proximity of instructions (i.e., how they relate to nearby instructions) via an RGB image representation, as described next. In this phase, we focus exclusively on Dalvik bytecode extracted from APKs and represented in Smali form. Although some Android applications may include native code via NDK-based so libraries, such components are relatively rare and typically serve performance-critical purposes (e.g., gaming, cryptography, compression) rather than malicious logic. Their analysis requires different reverse-engineering tools (e.g., IDA, Ghidra) and falls outside the scope of this work. Therefore, we restrict our study to Dalvik/Smali instructions, which remain the standard target in both research and malware datasets.

## 3.2 Phase ② – Image generation.

DROIDHUNTER converts Smali files to RGB images for classifying APKs in subsequent steps. An image-based representation for Smali code facilitates the use of visual pattern analysis techniques to detect Android malwares. In contrast to previous approaches that decompose instructions into separated feature vectors, Droid-Hunter encodes each complete Smali instruction into a single RGB pixel, preserving both semantic and structural information at the instruction level. By rendering opcode sequences as visual maps, we leverage the related models innate ability to detect spatial patterns that traditional token-by-token processing might overlook [35]. To this end, DROIDHUNTER employs a 4-step process (parsing, encoding, merging, and conversion) on the Smali of an APK to determine the values for the red (R), green (G), and blue (B) channels. Fig. 4

depicts the RGB image generation phase. This approach effectively captures the spatial proximity of instructions.

**Step 1 – Parsing.** A total of *n* Smali instructions (see Fig. 4) are parsed (e.g., opcodes and its first two operands) to be categorized into three distinct sets: (i) $\mathcal{A} = \{\text{opcode}_i\}_{0 \le i \le n}$ that includes all application's opcodes, (ii) $\mathcal{B} = \{\text{operand1}_i\}_{0 \le i \le n}$ that includes all registers, and (iii) $\mathcal{C} = \{\text{operand2}_i\}_{0 \le i \le n}$ that includes all methods. Elements of $\mathcal{B}$ can be two-dimensional. For instance, if the $i^{th}$ Smali instruction is `invoke-virtual {v0, v2}, Ljava/lang/...`, the resulting operand `op1i` equals $(v0, v2)$. Registers act as temporary data holding places for values during code execution, while methods reference the java methods utilized in the Smali code.

**Step 2 – Encoding.** To transform Smali instructions into RGB images, DROIDHUNTER uses lookup tables (we give them a flexible $\Omega$ notation) that map each element $e_i \in \{\mathcal{A}|\mathcal{B}|\mathcal{C}\}$ (i.e., opcode, register, or method) to a specific color channel intensity value $p_i$ based on its frequency of occurrence $\Omega(e_i) = x_i$. For the two-dimensional objects of $\mathcal{B}$ mentioned earlier, $x_i$ is the sum of the frequency of each of the two terms divided by two, so $x_i$ is always a scalar. Note that this step is the only non-invertible (or non-injective) operation of DROIDHUNTER's preprocessing; all other transformations are strictly lossless. The lookup tables, implemented as dictionaries (*Op_dict* for $\mathcal{A}$ and *Arg_dict* for $\mathcal{B}$ and $\mathcal{C}$), are constructed once and only once on the entire APK training set (i.e., many sets of different $\mathcal{A}$, $\mathcal{B}$ and $\mathcal{C}$) before any detection is initiated during training or test/production. The fundamental concept is assigning higher pixel intensity values in the R, G, and B channels to the most frequently encountered opcodes, registers, and methods in the training set. Since set $\mathcal{B}$ and $\mathcal{C}$ can contain more than 255 unique values, DROIDHUNTER uses various normalization functions to ensure that the resulting intensity values for each color channel fall within a standard 0-255 range. For set $\mathcal{B}$, we use a linear normalization function $f_{\text{norm}}$ such as $p_i = f_{\text{norm}}(\Omega(e_i))$ with $f_{\text{norm}}(x_i) = (x_i - x_i^{\text{min}})/(x_i^{\text{max}} - x_i^{\text{min}}) * 255$ to transform frequency distributions of opcodes, and registers into an intensity value over 8 bits (as by standard practice, $x_i^{\text{max}}$ and $x_i^{\text{min}}$ are frequencies obtained on the entire APK training set to not introduce any sample bias). We observed that the number of elements was very high for the methods set, $\mathcal{C}$. We use a path encoding function as a normalization method to minimize information loss. We represented methods as a tree structure, with the root node representing the package name and subsequent nodes representing classes, methods, return types, and so forth. Each node is then assigned an integer value based on its frequency of occurrence in the set. Finally, the numerical values along a given path are aggregated to yield a single value. This value is then normalized via the linear normalization function $f_{\text{norm}}$. Following the encoding process, we obtain three 1-dimensional vector $V_{\mathcal{A},V_{\mathcal{B}},V_{\mathcal{C}}}$ from $\mathcal{A}$, $\mathcal{B}$, or $\mathcal{C}$. These triplets are directly used as RGB pixels, yielding a final list of pixels that captures the instruction stream.

**Step 3 & 4 – Merging and conversion.** Finally, the list of RGB pixels obtained from the encoding step is reorganized into a 2-dimensional square image through padding. Each pixel in this list represents a complete Smali instruction encoded via its opcode and two operands, and takes the form of a 3-tuple corresponding to the R, G, and B channels. The order of the combined vector (i.e.,
the assignment of components to the R, G, and B channels) was found to have minimal impact on performance, as our evaluation of various permutations yielded comparable results. Nevertheless, for the results presented in this study, we retained the permutation that demonstrated the best performance, specifically the original configuration $V_A, V_B, V_C$. When converted into a 24-bit RGB image (i.e., 8-bit × 3), its final size corresponds to the smallest square that can contain all pixels, specifically: image_size = [√n]×[√n], where n is the number of instructions. If the number of instructions is not a perfect square, the pixel list is padded with zero-value pixels (0, 0) until the total number of pixels reaches the required square size. The longer the Smali instruction sequence, the larger the resulting image size. Finally, the image can be downscaled to match the input requirements of any classifier.

Vision models generally require input images to be normalized to standard ranges (typically 0 to 255 for RGB channels). Likewise, resizing or padding images to obtain a square shape is a common preprocessing step in computer vision and remains the standard approach adopted in influential vision-based malware detection research [79]. Non-square inputs appear mainly in object detection, segmentation, or video models where spatial ratios matter [19]. When extracting opcodes and their operands, we keep the same (sequential/spatial) order as in the original APK. Concretely, if an opcode appears before another, it means that the instruction of the target opcode appeared before in the APK instructions. During the image generation process, each pixel is generated from each opcode following the same order and placed in a square matrix. Thus, two horizontal/vertical near pixels means that their origin opcode instructions were near to each other in the APK code. The latter shows that there is a correlation between the pixel spatial proximities and the opcode proximities in the initial APK code.

## 3.3 Phase ③ – Classification

DROIDHUNTER supports two visualization-based classification models: (i) the ViT, and (ii) the CNN+SVM combination. Fig. 5 depicts the classification phase workflow.

Once the images are generated, they are resized to expedite the computations required for processing, optimize resource utilization, and facilitate the training of classification models like ViT-B/16, that have been pretrained on datasets containing images of a specific size, i.e., 224 × 224. The image dataset is split into a training set and a test set. The training set is used to train the classification models, while the test set is used to evaluate their performance on unseen data. This split validates how well the models can generalize to new data and avoid over-fitting.

**DROIDHUNTER-ViT.** DROIDHUNTER resizes input images to a 224 × 224 image which is the input size for the ViT-B/16 model. The ViT model used is the ViT-B/16 model from Alexey et al. [32], consisting of 12 stacked Transformer encoders with 12 attention heads each and an additional linear classification layer ("MLP head", Multi-Layer Perceptron head in Fig. 5) applied to the output vectors of the last Transformer encoder to predict class labels, resulting in a binary classifier (benign or malicious).

**DROIDHUNTER-CNN+SVM.** DROIDHUNTER also supports a CNN+SVM combination that consists of several layers: convolutional, pooling, batch normalization, dense, and dropout layers.

<figure><img src="image_6.png" /><figcaption>Figure 5: The classification pipeline.</figcaption></figure>

<table><caption>Table 1: Statistical analysis on the distribution of the number of opcodes of the benign and malicious APKs.</caption><thead><tr><th></th><th>Mean</th><th>Std. dev.</th><th>Covariance</th><th>Correlation</th></tr></thead><tbody><tr><td>Benign</td><td>5.0 × 10<sup>6</sup></td><td>4.2 × 10<sup>6</sup></td><td rowspan="2">6.4 × 10<sup>11</sup></td><td rowspan="2">4.0 × 10<sup>-2</sup></td></tr><tr><td>Malware</td><td>3.8 × 10<sup>6</sup></td><td>1.5 × 10<sup>6</sup></td></tr></tbody></table>

It uses convolutional filters, rectified linear unit (ReLU) activations, and dropout layers to enhance binary classification accuracy. Unlike the DROIDHUNTER-ViT model, the images used with this CNN model have not been resized, and retain their original size of [√n] × [√n], where n is the number of instructions. The model is trained using the Adam optimizer [48] and binary cross-entropy loss, with accuracy as the evaluation metric. Additionally, a separate model is created to extract features from the last convolutional layer, which is then used to train an SVM classifier with a linear kernel and a fixed C value of 0.2. The CNN passes through layers that analyze the image and detect specific patterns and structures. These features are then provided to an SVM classification algorithm. It uses these features to create a model that separates the data into benign and malicious classes using an optimal hyperplane, defining a boundary between the two classes. For each new image, the CNN extracts its features and sends it to the SVM to predict its class. To avoid bias related to the size of features in our scheme, we conducted in-depth statistical studies to analyze the distribution of opcodes in benign and malware APKs in the ground truth datasets (i.e., *DroidTrain*) as shown later in §4.1. We report mean, variance, covariance, and correlation in Table 1.

Benign APKs have a 32% higher mean and a 180% higher standard deviation compared to malicious APKs. This difference in the distribution of opcodes suggests a notable variation in the structure and behavior of benign and malicious APKs. A covariance of 6.4 × 10¹¹ in opcode distribution between benign and malwares suggests a similar variation between the opcode distributions in malicious and benign APKs. We observe a low correlation coefficient, indicating a weak linear correlation between the opcodes of the two categories. We observe a low correlation coefficient, indicating a weak linear relationship between the opcode distributions of the two categories. This suggests that the model does not primarily rely on opcode distribution as a distinguishing feature for malware detection.

**Robustness against Obfuscated, Packed Malware, and Concept Drift.** A key goal of DROIDHUNTER is to guarantee robustness against code-level obfuscation and light packing. Many existing static detectors rely on syntactic or form-based features such as manifest entries, API names, or opcode frequency distributions,
which can be easily meddled with by malware developers. In contrast, as presented previously, DROIDHUNTER encodes each complete Smali instruction (opcode and operands) into a structured RGB pixel. This representation captures instructions' semantics, reducing DROIDHUNTER's sensitivity to obfuscation. Incorporating operands into the encoding is especially important, as it preserves meaningful instructions such as method invocations even when obfuscation techniques are applied, such as identifier renaming, redundant control-flow jumps insertion, or string/resource encryption. Consequently, while such transformations can distort the code structure, the encoded images produced by DROIDHUNTER continue to reflect the underlying execution logic (see §5.3). Likewise, light packing operations such as rebuilding, re-signing, or alignment affect only the external binary structure of the APKs, but do not alter the extracted instructions. Since DROIDHUNTER directly operates on this instruction-level representation, it is robust against obfuscation and light packing. DROIDHUNTER design is inherently robust to concept drift as it is based on opcodes and operands which are mostly invariant in the different versions of Android [2, 56], making our design robust to past, and future APKs. Supporting new opcodes will be straightforward with new API releases.

# 4 EXPERIMENTAL SETUP

This section describes the experimental setup used to evaluate DROIDHUNTER's performance.

## 4.1 Dataset collection

We collected a *DroidTrain* dataset composed of 137,703 benign and 28,843 malicious applications discovered between 2011 and 2018, from: (i) Drebin [13] (samples from 2011 to 2013), (ii) Contagio [5] (samples from 2011 to 2018), and (iii) a dataset of 200 ransomwares manually certified by Androzoo [9] (samples from 2014 to 2018). The dataset has been prepared to ensure a balanced representation of different malware families and harmless apps.

To evaluate DROIDHUNTER under adversarial transformations, we constructed the *DroidObPack*₁ and *DroidObPack*₂ datasets by combining code obfuscation with light packing techniques. For the obfuscation part, we relied on the Obfuscapk framework [11], which implements well-known transformations such as MethodRename, ClassRename, FieldRename, insertion of Goto or junk instructions, as well as StringEncryption and ResourceEncryption. These transformations alter the syntactic structure of the code while preserving runtime behavior. In addition, and following practices reported in prior work [52, 58, 68], we adopted a *HOST-GUEST* repackaging model to simulate light packing operations. In this model, a benign APK ("HOST") is used to encapsulate a malicious payload ("GUEST"). The resulting repackaged APK is rebuilt, re-signed, realigned, and in some cases reordered at the resource level. These transformations perturb the binary structure of the APK and its signature metadata, thereby mimicking the effects of light packing. Importantly, unlike strong crypto-based packers (e.g., Bangcle, Qihoo), which encrypt the bytecode and render static analysis infeasible, these lighter transformations preserve access to the Dalvik code while disrupting structural features exploited by many static detectors.

<figure><img src="image_7.png" /><figcaption>**Figure 6:** Cumulative Distribution Function (CDF) of the total OPs found in the APKs for the three datasets *DroidObPack*₁, *DroidObPack*₂, and *DroidDrift*.</figcaption></figure>

The combination of obfuscation (Obfuscapk) and light packing (*HOST-GUEST* model with rebuilding, re-signing, realignment, resource reordering) produced two adversarial datasets: *DroidObPack*₁ and *DroidObPack*₂, each containing 24,196 malware samples. No benign applications were included, since the purpose of these datasets is not to evaluate malware-vs-benign classification, but to isolate the effect of obfuscation and repackaging transformations on detection performance. All generated APKs were executed in an Android Studio emulator to validate functional correctness, and ART execution logs were compared before and after transformation to ensure runtime integrity.

Finally, to evaluate robustness to the concept drift, we collected *DroidDrift*, containing benign and malicious samples from 2019 to 2024 (from Androzoo), enabling evaluation on recent malware families unseen during training. This more recent dataset extension enables us to test DROIDHUNTER's ability to spot new threats, and keep up to date with new techniques used by malware developers. Table 2 summarizes all datasets, their sizes, sources, transformation status, and the estimated proportion of hidden samples (lower bound estimated with APKiD [12]). SHA-256 checksums were used to prevent duplication or overlap.

We provide additional insights on the three datasets in Fig. 6. We report the cumulative distribution function (CDF%) over the total opcodes (OPs) found in the APKs for each of them. We observe the following. The *DroidObPack*₁ embeds two main classes of APKs, where roughly 60% of the APKs has at most 300k OPs, and the remaining ones at most 3M of OPs. In *DroidObPack*₂, we recognize three different categories of APKs (in terms of OPs), with at most 300k OPs, 3M OPs, and a small tail of APKs with up to 4M OPs. Instead, the distribution of the OPs in the APKs of *DroidDrift* is more homogeneous as they emerge from a natural source of data whereas *DroidObPack*₁ and *DroidObPack*₂ are packed APKs. Importantly, the number of samples in each dataset is consistent with widely used benchmarks in the Android malware detection literature, and therefore provides a representative basis for evaluating the robustness of a new detection model such as DROIDHUNTER.

## 4.2 Baselines

In our evaluation of DROIDHUNTER, we analyzed nine baselines grouped into three categories: C₁, C₂, and C₃. These categories respectively represent whether the preprocessing: (i) neither disassembles the Dex nor uses opcodes, (ii) disassembles the Dex and
<table><caption>Table 2: Summary of datasets used in this study. The “Hidden” column indicates whether the dataset was artificially transformed through code obfuscation (via Obfuscapk) and complementary light repackaging operations. For naturally collected datasets, the proportion of samples using such techniques was estimated with APKiD.</caption><thead><tr><th>Dataset</th><th>Source(s)</th><th>Years</th><th>Malware</th><th>Benign</th><th>Hidden</th><th>Hidden (%)</th></tr></thead><tbody><tr><td>DroidTrain</td><td>Drebin [13], Contagio [5], Androzoo [9]</td><td>2011–2018</td><td>28,843</td><td>137,703</td><td>No</td><td>0%</td></tr><tr><td>DroidObPack<sub>1</sub></td><td>DroidTrain + light repackaging</td><td>–</td><td>24,196</td><td>0</td><td>Yes</td><td>100%</td></tr><tr><td>DroidObPack<sub>2</sub></td><td>DroidTrain + code obfuscation</td><td>–</td><td>24,196</td><td>0</td><td>Yes</td><td>100%</td></tr><tr><td>DroidDrift</td><td>Androzoo [9]</td><td>2019–2024</td><td>42,477</td><td>219,522</td><td>No</td><td>5%</td></tr></tbody></table>

extracts features from opcodes, or (iii) uses opcodes (mostly without disassembling the Dex) to create an image representation that preserves spatial information.

**Scanner categories and the information they retain.** The preprocessing of C₂ and C₃ detectors (before they enter any ML model) happen to rely exclusively on the Dex executable, as we did not encounter detectors that utilize both the OPs and resource or manifest files simultaneously. Choosing to classify APKs based on OPs, rather than higher-level code, does not affect the amount of information available for detection. This is because the conversion from high-level code to byte or assembly is a deterministic process performed by a compiler. While the number of assembly instructions may vary due to the expansion of high-level constructs like loops and function calls, the resulting assembly code still contains all the information necessary to execute the program's logic and functionality accurately. On the other hand, the C₁ and C₂ detectors inherently lose information by selecting expert-chosen features from their respective input files, unlike C₃, which feeds a direct, one-to-one encoded image representation of the Dex file to a classifier. In the latter case, the information loss is governed by a downscaling parameter for computational purposes. This makes C₃ preprocessors richer in information by design.

As an example, the preprocessing from Kang and al. [46] reduces a disassembled Dex to a vector of term-frequencies (it is therefore a C₂). The loss of detailed information and context can be measured by considering a text (in our case, a Smali file). Let's denote the text as a sequence of words w₁, w₂, ..., wₙ, where wᵢ is the i-th word in the text. We can represent the text as a probability distribution over the possible words, where the probability of each word is given by its frequency in the text. To capture the order of the words in the text, we can then write its entropy as a sum of conditional entropies: $H(\text{text}) = \sum_{i=1}^{n} H(w_i | w_1, w_2, ..., w_{i-1})$ where $H(w_i | w_1, ..., w_{i-1})$ is the conditional entropy of the i-th word given the previous words. Since a term-frequency list only captures the probability distribution of the words, we can write the entropy of the list as: $H(\text{list}) = H(w_1) + H(w_2) + ... + H(w_m)$ ($m \le n$) where $H(w_i)$ is the entropy of the i-th word. The data processing inequality tells us that the conditional entropy of a variable given others is always less than or equal to its own entropy: $H(w_i | w_1, ..., w_{i-1}) \le H(w_i)$. Thus, $H(\text{text}) \ge H(\text{list})$. It indicates that exact (or quasi-exact in the case of DROIDHUNTER) mappings, such as those between Smali code and images produced by a C₃, preserve more richer information.

Drebin [13] is a well-known reference in the field of Android malware detection. It uses static analysis to extract fundamental characteristics of applications, e.g. permissions and protected API

calls (thus categorized as C₁). These features are then encoded using a binary representation to indicate their presence or absence. A linear SVM is applied to classify applications as malicious or benign based on these encoded features. Drebin is recognized as one of the most effective ML-based approaches [24]. We reimplemented Drebin based on the reference article. Additionally, we extended Drebin to incorporate two other classic ML algorithms: Random Forest and KNN. Our reimplementation of Drebin also brings together a larger set of features than the original Drebin, including sources and sinks [67], and a larger number of protected API calls [14].

**MaMaDroid** [61] checks all the calls made in the application using static analysis, then represents these calls abstractly by keeping only the method package names, placing it into the category C₁ as well. MaMaDroid uses this information to create Markov chains that calculate the probability that one method will be called by another. These probabilities are used to create a feature vector, used to train three classification models: Random Forest, KNN and SVM.

**MalBERTv2** [66] is a binary classifier for detecting Android malware, built on a pre-trained BERT model. It performs static analysis by extracting keywords from application manifest files only. Thus, it is categorized as C₁. The feature generator pre-tokens the manifest files to train the tokenizer.

**Revealdroid** [40] is another static analysis approach categorized in C₁, as it relies on semantic features extracted from interprocedural control-flow graphs. It focuses on robust malware detection across obfuscation techniques.

**Kang and al.** [46] extracts characteristic patterns from disassembled n-gram opcodes in Android applications to detect malware. This makes it a candidate in category C₂. They use automatic classification algorithms such as SVM, Random Forest, DT and KNN to train its model. As for Drebin, we re-implemented it based on the details given in the reference paper.

**SHERLOCK** [72] is a self-supervised malware detection approach categorized in C₃, leveraging Vision Transformers (ViT) for analyzing APK files. Unlike traditional methods, SHERLOCK uses visual representations of APKs, transforming them into image-like feature maps that can be processed by ViTs. This innovative approach allows the model to capture complex patterns and hierarchical structures in the APK files, improving detection performance, especially in the context of obfuscated and polymorphic malware. With self-supervised learning, SHERLOCK can learn rich feature representations from large amounts of unlabeled data, which makes it valuable for scenarios with limited labeled samples.

**ViT4Mal** [69] uses a lightweight Vision Transformer (ViT) to detect malware on an edge device, and is hence categorized as C₃.
It converts executable binary code into images to learn malware characteristics, and then uses a custom ViT to detect malware.

**DexRay** [27] reads the bytecode of the APK Dex files into gray-scale images and feeds them to a 1-dimensional CNN model ($C_3$).

**R2-D2** [44] also reads opcode instructions as the blunt bytecode of the APK Dex but as RGB ($C_3$).

# 5 EVALUATION

We conduct an extensive evaluation of DROIDHUNTER. The goal of the evaluation is to answer the following research questions:

* **RQ1 - Performance with known APKs:** How does DROIDHUNTER compare against our baselines on the training set? (§5.2)

* **RQ2 - Performance with hidden malware APKs:** How does DROIDHUNTER compare against our baselines obfuscated-packing malicious APKs? (§5.3)

* **RQ3 - Concept drift robustness:** How does DROIDHUNTER compare against our baselines on latest malicious APKs? (§5.4)

* **RQ4 - Time efficiency of DROIDHUNTER:** How does DROIDHUNTER compare against our baselines regarding feature extraction and inference times? (§5.5)

## 5.1 Testbed and implementation details

For our evaluation, we use a server that has a 24-core Intel Xeon Gold 5220R CPU, 768 GB of RAM, 480 GB SSD, and 4x Nvidia Quadro RTX 8000 GPU with 48 GB memory. We leverage the PyTorch v2.1.2 library [62] to perform model training for all the considered approaches. We perform cross-validation with 80% for the training, 10% for the validation, and 10% for the test. This split is commonly adopted in prior malware detection studies, as it balances the availability of sufficient training data with unbiased validation and test evaluation. We release our code and training details: https://zenodo.org/doi/10.5281/zenodo.10977166.

## 5.2 Performance with known APKs

We begin by comparing DROIDHUNTER against our baselines on the training dataset *DroidTrain* (§4.1). Table 3 reports the accuracy, precision, recall, and F1 scores.

Kang et al. achieves the worst accuracy, followed by ViT4Mal. Overall, DROIDHUNTER is on par with the baseline approaches and the CNN+SVM model performs slightly better than the ViT. Drebin (SVM and RandomForest) and MalBERT have slightly better results (≤ 2% difference). When considering the training dataset, DROIDHUNTER is on par with the state-of-the-art approaches.

**Answer to RQ1:** DROIDHUNTER performs well on the training dataset, achieving ≤ 2% of the state-of-the-art approaches.

## 5.3 Dealing with hidden malware APKs

Obfuscation is a widespread strategy among malware developers to hinder detection by static analysis. Techniques such as identifier renaming, insertion of junk or control-flow altering instructions (e.g., goto), and string or resource encryption alter the syntactic structure of the code while preserving runtime behavior. These transformations distort the structural and semantic patterns on which many detectors rely, thereby reducing their effectiveness.

<table><caption>Table 3: Accuracy, F1-Score, precision and recall (%) obtained on the *DroidTrain* dataset (benign and malware variants).</caption><thead><tr><th></th><th></th><th>Accuracy (%)</th><th>F1-Score</th><th>Precision</th><th>Recall</th></tr></thead><tbody><tr><td rowspan="4">Drebin</td><td>KNN(k=1)</td><td>97.82</td><td>97.25</td><td>98.32</td><td>97.55</td></tr><tr><td>KNN(k=3)</td><td>95.23</td><td>98.12</td><td>97.17</td><td>98.86</td></tr><tr><td>Random Forest</td><td>96.23</td><td>98.21</td><td>98.91</td><td>98.15</td></tr><tr><td>SVM</td><td>98.75</td><td>98.43</td><td>98.02</td><td>98.95</td></tr><tr><td rowspan="4">MaMaDroid</td><td>KNN(k=1)</td><td>97.10</td><td>97.01</td><td>98.41</td><td>98.88</td></tr><tr><td>KNN(k=3)</td><td>97.22</td><td>97.24</td><td>98.20</td><td>98.11</td></tr><tr><td>Random Forest</td><td>98.15</td><td>98.20</td><td>98.29</td><td>98.29</td></tr><tr><td>SVM</td><td>98.35</td><td>98.66</td><td>98.94</td><td>97.90</td></tr><tr><td>MalBERT</td><td>BERT</td><td>99.10</td><td>98.12</td><td>99.41</td><td>99.29</td></tr><tr><td>Revealdroid</td><td>Linear SVC</td><td>64.29</td><td>79.20</td><td>70.73</td><td>80.75</td></tr><tr><td rowspan="4">Kang and al. (N == 3)</td><td>SVM</td><td>92.46</td><td>92.31</td><td>100</td><td>100</td></tr><tr><td>Random Forest</td><td>97.90</td><td>89.31</td><td>87.50</td><td>93.33</td></tr><tr><td>Decision Tree</td><td>95.67</td><td>88.02</td><td>98.02</td><td>94.41</td></tr><tr><td>KNN</td><td>91.94</td><td>75.26</td><td>95.19</td><td>85.19</td></tr><tr><td rowspan="4">Kang and al. (N == 4)</td><td>SVM</td><td>81.90</td><td>99.02</td><td>77.00</td><td>85.88</td></tr><tr><td>Random Forest</td><td>89.66</td><td>86.45</td><td>97.45</td><td>99.75</td></tr><tr><td>Decision Tree</td><td>87.90</td><td>87.22</td><td>87.69</td><td>87.25</td></tr><tr><td>KNN</td><td>90.90</td><td>88.98</td><td>100</td><td>94.89</td></tr><tr><td>ViT4Mal</td><td>ViT</td><td>91.78</td><td>89.73</td><td>88.06</td><td>90.15</td></tr><tr><td>R2-D2</td><td>CNN</td><td>87.77</td><td>87.67</td><td>88.51</td><td>86.80</td></tr><tr><td>DexRay</td><td>CNN</td><td>81.70</td><td>80.47</td><td>86.25</td><td>75.42</td></tr><tr><td rowspan="2">SHERLOCK</td><td>ViT</td><td>68.52</td><td>76.41</td><td>91.25</td><td>60.14</td></tr><tr><td>CNN + SVM</td><td>99.97</td><td>98.84</td><td>99.56</td><td>99.94</td></tr><tr><td>DROIDHUNTER</td><td>ViT</td><td>99.08</td><td>98.65</td><td>98.75</td><td>99.18</td></tr></tbody></table>

In addition to these code-level transformations, we also consider light packing as a complementary form of structural perturbation. Unlike strong crypto-based packers (e.g., Bangcle, Qihoo), which encrypts the Dalvik bytecode and makes static analysis infeasible, light packing—introduced here through Obfuscapk’s Rebuild, Re-signing, Alignment operations and our HOST-GUEST repackaging model—leaves the bytecode accessible but modifies the binary layout and signature metadata. Such operations do not hide the code, but they disrupt static features (e.g., manifest fields, resource ordering) that are often critical for classical detectors.

We aim to evaluate detectors’ robustness against obfuscation. To this aim, we empirically evaluate the robustness by leveraging the models trained on *DroidTrain* and testing them on the adversarial datasets *DroidObPack*<sub>1</sub> and *DroidObPack*<sub>2</sub>, both composed of malicious APKs transformed through the combination of Obfuscapk obfuscation and light repackaging (§4.1).
<table><caption>**Table 4:** Accuracies of models trained with *DroidTrain* and tested with datasets *DroidObPack*<sub>1</sub> and *DroidObPack*<sub>2</sub>. Improvement in accuracy (%) over best baseline in parentheses.</caption><thead><tr><th></th><th>DroidObPack<sub>1</sub></th><th>DroidObPack<sub>2</sub></th></tr></thead><tbody><tr><td><strong>Drebin</strong></td><td></td><td></td></tr><tr><td>KNN (k=1)</td><td>0.00</td><td>0.12</td></tr><tr><td>KNN (k=3)</td><td>1.33</td><td>3.25</td></tr><tr><td>Random Forest</td><td>15.95</td><td>16.54</td></tr><tr><td>SVM</td><td>10.23</td><td>12.02</td></tr><tr><td><strong>MaMaDroid</strong></td><td></td><td></td></tr><tr><td>KNN (k=1)</td><td>8.03</td><td>1.66</td></tr><tr><td>KNN (k=3)</td><td>9.89</td><td>2.55</td></tr><tr><td>Random Forest</td><td>43.21</td><td>1.10</td></tr><tr><td>SVM</td><td>54.35</td><td>37.84</td></tr><tr><td><strong>MalBERT</strong></td><td></td><td></td></tr><tr><td>BERT</td><td>17.52</td><td>32.18</td></tr><tr><td><strong>Revealdroid</strong></td><td></td><td></td></tr><tr><td>LINEAR SVC</td><td>57.51</td><td>57.02</td></tr><tr><td><strong>Kang et al. (N=3)</strong></td><td></td><td></td></tr><tr><td>SVM</td><td>84.06</td><td>83.20</td></tr><tr><td>Random Forest</td><td>91.09</td><td>92.93</td></tr><tr><td>Decision Tree</td><td>95.06</td><td>91.20</td></tr><tr><td>KNN</td><td>71.13</td><td>76.01</td></tr><tr><td><strong>Kang et al. (N=4)</strong></td><td></td><td></td></tr><tr><td>SVM</td><td>88.64</td><td>86.87</td></tr><tr><td>Random Forest</td><td>94.02</td><td>94.75</td></tr><tr><td>Decision Tree</td><td>95.13</td><td>94.09</td></tr><tr><td>KNN</td><td>92.07</td><td>92.28</td></tr><tr><td><strong>ViT4Mal</strong></td><td></td><td></td></tr><tr><td>ViT</td><td>12.77</td><td>81.01</td></tr><tr><td><strong>R2-D2</strong></td><td></td><td></td></tr><tr><td>CNN</td><td>65.42</td><td>77.69</td></tr><tr><td><strong>DexRay</strong></td><td></td><td></td></tr><tr><td>CNN</td><td>56.56</td><td>71.46</td></tr><tr><td><strong>SHERLOCK</strong></td><td></td><td></td></tr><tr><td>ViT</td><td>26.42</td><td>44.10</td></tr><tr><td><strong>DROIDHUNTER</strong></td><td></td><td></td></tr><tr><td>ViT</td><td>98.98 (↑3.85)</td><td>98.76 (↑4.01)</td></tr><tr><td>CNN + SVM</td><td>98.20 (↑3.07)</td><td>98.51 (↑3.76)</td></tr></tbody></table>

Table 4 reports the accuracies of each detector on the considered datasets. Most baseline approaches collapse under obfuscation and light packing, with Drebin showing near-zero detection, MaMaDroid dropping below 55%, and even vision-based detectors such as SHERLOCK and DexRay struggle to generalize. The best baseline, Kang et al., achieves up to 95.13% accuracy, but still falls behind DROIDHUNTER. DROIDHUNTER achieves up to 98.98% accuracy (ViT model), outperforming the strongest baseline by up to 4.01%.

These results highlight that DROIDHUNTER preserves meaningful features even under obfuscation compared to the others. To explain and complement the previous claims, we illustrate in Fig. 7 how obfuscation and light packing transformations affect the features extracted by each detectors. Concretely, feature-based approaches relying on manifest entries or API calls lose discriminative power once these elements are renamed, encrypted, or redirected, as their structural and semantic meaning becomes distorted. In particular, N-gram based methods and API-sequence models rely on the distributions of instruction sequences, i.e., the frequency and ordering

of opcode or API patterns. Such reliance makes them especially vulnerable to low-level transformations such as redundant instruction insertion, control-flow alterations, or junk code, which perturb these distributions without affecting the underlying program semantics. Similarly, vision-based classifiers that encode applications at the byte or binary level remain sensitive to such perturbations, as they capture superficial statistical patterns rather than deeper instruction-level semantics. As outlined in §3.3, DROIDHUNTER addresses these limitations by encoding both opcodes and their arguments into structured pixels, ensuring that each instruction remains distinguishable even after transformations. This design preserves behavioral signals and provides stronger resilience to obfuscation and light packing. We analyse and validate this observation on several obfuscated malwares such as 42b0d3052a617d..., f11f862f6962bf... (APKs in *DroidObPack*<sub>1</sub>), that use Renaming and StringEncryption as obfuscation techniques from Obfuscapk.

**Answer to RQ2:** Most baseline approaches perform poorly on obfuscated or lightly packed malwares. Instead, DROIDHUNTER performs the best with up to 98.98% accuracy, outperforming the best baseline approach (Kang et al.) by up to 4.01%.

## 5.4 Robustness to concept drift

Concept drift is a major challenge in Android malware detection, as malicious behaviors evolve over time and extensively reduce the effectiveness of static machine learning models. To assess this degradation, we use the *DroidDrift* dataset (§4.1), which contains benign and malicious APKs collected between 2019 and 2024 and is strictly disjoint from the training set. This setting enables us to study how models trained on older samples (*DroidTrain*, covering 2011–2018) behave when exposed to more recent malware families. Inspired by the model ageing methodology proposed in Tesseract [63], we train each detector once on *DroidTrain*, then evaluate it chronologically on yearly subsets of *DroidDrift*. This allows us to monitor the decay of detection performance over time. We do not evaluate retraining performance as it is a solution to concept drift [77] and not a way to measure it.

As illustrated in Fig. 8, all detectors experience a decrease in accuracy as the test data becomes more recent, though the rate of degradation varies. Detectors such as Drebin, N-gram models or MaMaDroid show a rapid decline after 2020, indicating they fail to generalize once malware behavior diverges from the original training distribution. In contrast, DROIDHUNTER maintains substantially higher accuracy across all years, which demonstrates a slower degradation and an overall stronger resilience to evolving malware patterns. To summarize temporal robustness quantitatively, we compute for each model the Area Under the Time-decay Curve (AUT) of its accuracy and its average rank across the yearly subsets. A higher AUT corresponds to more stable performance over time, while a lower average rank indicates consistent superiority over competing approaches. As shown in Table 5, DROIDHUNTER-ViT achieves an AUT of 0.89 with an average rank of 1.50, outperforming all baseline detectors. DROIDHUNTER-CNN+SVM obtains comparable values.
<figure><img src="image_8.png" /><figcaption>Figure 8: Temporal performance decay of detectors evaluated on the *DroidDrift* dataset (2019 to 2024).</figcaption></figure>

<table><caption>Table 5: Concept drift evaluation with datasets *DroidDrift*. The best should have an AUT of 1 and the lowest rank.</caption><thead><tr><th></th><th>AUT</th><th>Avg. rank</th><th>w.r.t accuracy</th></tr></thead><tbody><tr><td><strong>Drebin</strong></td><td></td><td></td><td></td></tr><tr><td>Random Forest</td><td>0.49</td><td>5.83</td><td></td></tr><tr><td><strong>MaMaDroid</strong></td><td></td><td></td><td></td></tr><tr><td>SVM</td><td>0.42</td><td>7.67</td><td></td></tr><tr><td><strong>MalBERT</strong></td><td></td><td></td><td></td></tr><tr><td>BERT</td><td>0.53</td><td>3.92</td><td></td></tr><tr><td><strong>RevealDroid</strong></td><td></td><td></td><td></td></tr><tr><td>LINEAR SVC</td><td>0.03</td><td>10.29</td><td></td></tr><tr><td><strong>Kang et al. (N=4)</strong></td><td></td><td></td><td></td></tr><tr><td>Decision Tree</td><td>0.76</td><td>4.17</td><td></td></tr><tr><td><strong>ViT4Mal</strong></td><td></td><td></td><td></td></tr><tr><td>ViT</td><td>0.76</td><td>3.00</td><td></td></tr><tr><td><strong>R2-D2</strong></td><td></td><td></td><td></td></tr><tr><td>CNN</td><td>0.79</td><td>4.00</td><td></td></tr><tr><td><strong>DexRay</strong></td><td></td><td></td><td></td></tr><tr><td>CNN</td><td>0.73</td><td>6.66</td><td></td></tr><tr><td><strong>SHERLOCK</strong></td><td></td><td></td><td></td></tr><tr><td>ViT</td><td>0.53</td><td>6.50</td><td></td></tr><tr><td><strong>DROIDHUNTER</strong></td><td></td><td></td><td></td></tr><tr><td>ViT</td><td>0.89</td><td>1.50</td><td></td></tr><tr><td>CNN + SVM</td><td>0.87</td><td>1.50</td><td></td></tr></tbody></table>

<table><caption>Figure 7: Illustration of static detectors weaknesses regarding obfuscation and light packing transformations.</caption><thead><tr><th colspan="3">RAW_DEX MODULE (Modified payload, encrypted strings, renamed classes)</th></tr></thead><tbody><tr><td>MaMaDroid</td><td>→ Expects the full name "android.telephony.SmsManager" but sees "La/b/c;->a" → unrecognized → incorrect graph.</td><td></td></tr><tr><td>RevealDroid</td><td>→ Static invariant APIs → Indirect API (La/b/c) unrecognized; → Encrypted strings → no detectable signal</td><td></td></tr><tr><td>DexRay / Sherlock</td><td>→ Generates global representations (image or hash) → different hash/signature → No matching with known malware database</td><td></td></tr><tr><td>ViT4Mal / R2-D2</td><td>→ Complete image of the dex → Represents .dex as a 2D image (bytes = pixels) → Obfuscation changes the visual pattern → noise</td><td></td></tr></tbody><thead><tr><th colspan="3">SMALI MODULE (Dalvik instruction after decompilation)</th></tr></thead><tbody><tr><td>Ngram</td><td>→ Analyzes invoke-virtual, const-string sequences; → Injects goto; → Frequency changes; → Analysis does not consider arguments → loss of meaning</td><td></td></tr><tr><td>DroidHunter</td><td>→ Reads opcode + arguments even if renamed → (invoke-direct, v0, Lx/y/z;->a) → (goto, NONE, .ibl_12) → Encodes in (R,G,B) → pixel → still usable image → Entire small → RGB image → ViT model retains behavioral information</td><td></td></tr></tbody><thead><tr><th>Approach</th><th>Robustness Against Hidden Apks</th><th>Reason for Reduced Detection with Hidden Apks</th></tr></thead><tbody><tr><td>Drebin</td><td>Very Low</td><td>Relies on AndroidManifest.xml and permissions which are renamed/encrypted. Manifest analysis fails. Loses semantic features.</td></tr><tr><td>MaMaDroid</td><td>Low</td><td>API-call graph is built from explicit API names; renamed APIs break transitions and distort the graph.</td></tr><tr><td>RevealDroid</td><td>Medium</td><td>Uses categorized API usage and reflection features; still sensitive to renamed or encrypted API names and strings.</td></tr><tr><td>MalBERT</td><td>Low</td><td>Textual tokens ("La/b/c") unknown → noisy embeddings</td></tr><tr><td>N-gram</td><td>Medium</td><td>Only relies on opcode frequency sequences; obfuscators insert goto/nop/junk which overshadows the original signal. No arguments captured. weak semantics.</td></tr><tr><td>ViT4Mal</td><td>Low</td><td>Vision Transformer on dex image; obfuscation introduces binary noise and junk bytes</td></tr><tr><td>R2D2</td><td>Medium</td><td>Uses dynamic execution + CNN; can observe real behavior at runtime even if code is obfuscated, but requires heavy sandboxing/emulation.</td></tr><tr><td>SherLock</td><td>Medium</td><td>Signature/hash changes completely after code transformation; hash matching fails.</td></tr><tr><td>DexRay</td><td>Medium</td><td>Represents raw bytecode as image; obfuscation alters byte patterns → visual features no longer match.</td></tr><tr><td>DroidHunter</td><td>Good</td><td>Works directly at the small opcode + argument level; still sees invoke-direct, goto, sput, etc. and preserves behavior even under obfuscation or Packing.</td></tr></tbody></table>

<figure><img src="image_9.png" /><figcaption>Figure 9: Feature extraction times for the 10 malware detection systems from the 3 scanner categories.</figcaption></figure>

Answer to RQ3: DROIDHUNTER largely outperforms the best baseline approaches when evaluated on *DroidDrift* - composed of recent malwares (2019 to 2024) from Androzoo, showing DROIDHUNTER's better robustness against concept drift.

## 5.5 Time efficiency of DROIDHUNTER

To evaluate the time efficiency of DROIDHUNTER, we performed evaluations on the *DroidDrift* dataset. We compute and compare

feature extraction and class prediction times for all models described in §4.2. We report our results in Fig. 9.

DROIDHUNTER has generally good performance, with an average feature extraction time of 13.66 s and median of 11.00 s, indicating stability in extraction times. Since C₃-type detectors perform little to no preprocessing on the input samples, their feature extraction time is, as expected, among the lowest of the studied baselines. In
<figure><img src="image_10.png" /><figcaption>Figure 10: Inference times for the 10 malware detection systems from the three scanner categories considered here.</figcaption></figure>

contrast, DROIDHUNTER has the longest feature extraction time due to its disassembly step, alongside the C₂-type N-gram approach.

We also compare the performance of inference time in Fig. 10. DROIDHUNTER-CNN+SVM has a median inference time of 62.24 ms. We did not find noticeable differences between DROIDHUNTER and its counterparts showing competitive performance with relatively stable prediction times and a restricted range.

Answer to RQ4: The evaluation of DROIDHUNTER on new data revealed average feature extraction times of 13.66 s, with a median of 11.00 s. While DROIDHUNTER did not achieve the fastest times, it demonstrated stability in feature extraction and moderate dispersion in prediction times.

## 5.6 Channel perturbations and its impact

We perform an ablation study to analyze the impact of each RGB channel (Opcode, op1, and op2 - see §3) on the performance of DROIDHUNTER. Concretely, for each channel, we disable it (i.e., setting its value to 0), and generate images with the two remaining channels. We then compare the performance of each corresponding model with DROIDHUNTER (the three channels active). We perform this evaluation on a subset of our dataset *DroidTrain*. In this subset, we test the different models on a sample composed of 74% obfuscated and packed malwares. Overall, we observe that compared to DROIDHUNTER, removing one channel decreases the accuracy by up to 7.38% (R channel: Opcode) on the entire dataset, and by up to 7.12% on the obfuscated/packed malwares (B channel: op2). DROIDHUNTER achieves 99.79% and 98.49% accuracies on the entire dataset and obfuscated/packed malwares, respectively. Concretely, disabling the R, G, and B channel drops performance by 7.38%, 6.18%, and 6.57% respectively, on the entire dataset; and by 4.75%, 5.72%, and 7.12% respectively on the obfuscated/packed malwares. We can therefore deduce that the different channels add enough semantic to DROIDHUNTER to improve its performance.

## 6 MODEL EXPLAINABILITY

Research shift toward ML-oriented solutions introduced a new challenge: explainability (XAI) [34]. This term refers to the difficulty in tracing a prediction back to the important features. The lack of transparency in ML models' decision process can lead to various potential hazards, including biased outcomes, inaccurate predictions, and vulnerabilities that could be exploited by malicious actors across a wide range of real-world applications [20]. Additionally,

<table><caption>Table 6: Average Euclidian Distance of GIST descriptors for thee vision-based scanners, trained with *DroidTrain*, evaluated over *DroidPack*<sub>1</sub>, *DroidPack*<sub>2</sub> and *DroidDrift*. The distances percentages below 0.1 is shown in the < 0.1 column.</caption><thead><tr><th rowspan="2"></th><th colspan="2">DroidPack<sub>1</sub></th><th colspan="2">DroidPacked<sub>2</sub></th><th colspan="2">DroidDrift</th></tr><tr><th>AED</th><th>&lt; 0.1</th><th>AED</th><th>&lt; 0.1</th><th>AED</th><th>&lt; 0.1</th></tr></thead><tbody><tr><th>R2 - D2<sub>CNN</sub></th><td>0.572</td><td>11.1%</td><td>0.559</td><td>0.62%</td><td>0.577</td><td>2.66%</td></tr><tr><th>DexRay<sub>CNN</sub></th><td>0.571</td><td>7.72%</td><td>0.480</td><td>17.3%</td><td>0.659</td><td>3.09%</td></tr><tr><th colspan="7" style="text-align: left; font-weight: bold;">DROIDHUNTER</th></tr><tr><th>CNN +SVM</th><td>0.168</td><td>51.9%</td><td>0.172</td><td>49.4%</td><td>0.288</td><td>37.9%</td></tr><tr><th>ViT</th><td>0.209</td><td>9.74%</td><td>0.210</td><td>9.56%</td><td>0.511</td><td>23.9%</td></tr></tbody></table>

explainability has been positively linked to adversarial robustness in several recent studies [16, 38].

**AED of CAMs.** Few contributions explore XAI in the context of malware detection, and among those, almost none investigate image-based detectors; even fewer tackle Android platforms. Notable exceptions include recent work [45] that uses Grad-CAM [71] to assess the consistency of predictions within each class of detected malware using features (GIST descriptors [60]) extracted from Class Activation Mappings (CAMs). Better scores in this study were linked to better discrimination performance among similar models. As an exploratory investigation, we apply this method to our vision-based detectors. However, using this tool, we could not achieve satisfactory separation of our tested models. Consequently, we employ a gradient-free approach for baseline models: Ablation-CAM [29]. An ablation-based CAM is an activated and resized weighted sum of the final convolutional layer activations of a model evaluated on a single input sample. Besides, the DROIDHUNTER-ViT classifier is based on a different genus than other models considered in this study, so we employ another state-of-the-art method, which relies on attention-based relevance maps [22].

**Evaluation.** By running inferences on each sample of available evaluation datasets, we collect the CAMs for three scanners trained on *DroidTrain* used in this study that rely on image inputs, namely: DexRay, R2-D2, DROIDHUNTER using a CNN and DROIDHUNTER using a ViT. We compute the GIST descriptors [60] of each model's heatmaps, then determine the Average Euclidian Distance (AED) between them. When the AED is small, the model is overall more certain of its decisions during inference, and as it focuses its attention on consistent areas of interest on the input image sample. We note that AED score does not discriminate between correct and misclassifying inferences; it also does not provide a measure of the proficiency of the model, but rather a hint at the reliability of its behavior over a sample pool.

We present the results in Table 6. Alongside the AED, we tally the number of samples falling within distances smaller than 0.1 under "< 0.1" columns, expressing these quantities as percentages relative to the total sample count. These percentages provide insights into the distribution and variety of samples being analyzed. Compared to prior studies [45], our results are obtained on a 6× larger pool of samples and over samples specifically designed to evade detection. Table 6 shows that, across all evaluated datasets, the ViT and CNN from DROIDHUNTER perform significantly better than the compared baselines (lower overall AED). However, the descriptors of the ViT are not always better concentrated than
those of other baselines; when this is the case, its AED outclassed
its counterparts. We note that this concentration of descriptors
can vary greatly across the evaluation sets (by over twofold from
*DroidObPack1* and *DroidObPack2* to *DroidDrift*).

While these results indicate a general superiority in explainabil-
ity for DROIDHUNTER, which gives them an advantage in the cited
study's comparative selection framework [45], the exact benefit
of delivering consistent CAMs and the possible interpretations of
such maps remain to be assessed in future work. When paired with
the straightforward classification performances (§5), we believe
these metrics provide an encouraging incentive to use our detector
on the grounds of better consistency in interpretability, which is
increasingly emphasized in both ML research and industry [20].

7 RELATED WORK

We survey related work into three categories: machine learning,
deep learning, and computer vision methods.

**Machine learning methods.** Detection of Android malwares is an extensively explored field. Drebin [13] trains an SVM that focuses on static features of APKs (e.g. component names, permissions, intents, and APIs). HinDroid [43] uses static analysis and meta-paths to build a heterogeneous network reflecting associations between applications and system API calls, identifying malicious apps. MaMaDroid [61] extracts API calls via static analysis based on classes, packages, or families, then builds a Markov chain from the API sequence for ML classification. RevealDroid [40] identifies malwares and its family using lightweight features like Android API usage at the package and method levels, resolving APIs triggered by reflection and native binaries. It outperforms approaches using complex program analysis or large feature sets, handling obfuscated APKs effectively. Previous research [73] tests feature selection methods on Android app files to identify the most representative sets, aligning with C₁ classification. N-gram analysis [46] automates feature extraction but is ineffective against packed malwares (see §5). Other C₂ studies used opcode category sequences as features with Maximal Frequent Patterns [28, 51]. Yuxin and Siyi [30] generated opcodes from Windows PE files and used opcode N-gram. Earlier work [33] selected opcode subsets based on information gain. While DROIDHUNTER represents all instructions' frequencies, the other methods alter the granularity of opcode perception. We find that the baseline ([46]) most representative, as frequency analysis is foundational for much of the cited research.

**Deep learning methods.** Droid-Sec [86] exploits Deep Belief Networks (DBNs) to classify Android malwares on pre-computed features. DroidDeep [78] extended the approach using a significantly larger number of features (from 200 to over 30,000) compared to the previous work. The latter studies can be categorized as C₁-type schemes. Tinydroid [23], on the other hand, employs an instruction simplification technique to build a lightweight static machine learning detection model. Similar to DROIDHUNTER, it extracts opcodes from all Dex files in an Android app, then constructs simplified symbolic instructions using N-grams.

**Computer vision methods.** R2-D2 [44] and DexRay [27] leverage the classes.dex file presented as bytecode to map the APK to an image. Authors in a similar work [84] chunk the raw binary file into pixels, which doesn't guarantee that a pixel aligns with a

single instruction. We specifically design the encoding so that one
pixel always corresponds to one logical Smali instruction. Their
dataset [82] (11K APKs) is 40× smaller than ours, and there is no con-
cept drift evaluation. DROIDHUNTER distinguishes itself by integrat-
ing a unique preprocessing algorithm to generate image samples
that are subsequently sent as input into the classifier. Malware de-
tection techniques have yet to extensively explore attention-based
mechanisms, despite their prominence in LLMs. MalBERTv2 [66],
an Android malware binary classifier, builds on MalBERT [65] by
leveraging larger training datasets with pre-computed features.
However, its inference process remains unchanged, classifying it
as a C₁-type detector. SHERLOCK [72] uses self-supervised learn-
ing on image representations of Dex files to extract features for
malware detection, making it a C₃-type detector.

8 CONCLUSION AND FUTURE WORK

In this paper, we presented DROIDHUNTER, a novel malware detection mechanism, which operates by encoding APKs opcodes and their operands with frequency-based lookup tables into an RGB image. We thoroughly evaluated DROIDHUNTER and compared it against nine state-of-the-art approaches on several datasets. The evaluation demonstrates that DROIDHUNTER achieves competitive performance on known malwares, while clearly outperforming existing approaches on obfuscated and lightly packed malicious APKs by up to 4,01%. It is much more resistant to concept drift (over 47% less drop in accuracy). We also assess the quality of our proposed scheme under the lens of the AED showing DROIDHUNTER better explainability. We intend to extend the malware classes considered in our work by including banking, trojans, and spyware families, for example. Furthermore, we want to improve DROIDHUNTER design to protect against adversarial examples, for a more robust and resilient model. We also plan to further enhance explainability by including heatmaps to code-level semantics. Finally, despite the fact that DNNs (e.g., MLP) performance is limited on complex nonlinear patterns and long-range dependencies, we envision exploring their performance on flattened inputs to capture the real benefits of vision-based models.

REFERENCES

[1] 2009. An assembler for Android's dex format. http://code.google.com/p/smali/.

[2] 2017. Android O and DEX 38: Dalvik O for Dynamic Invocation. https://www.pnfsoftware.com/blog/android-o-and-dex-version-38-new-dalvik--to-support-dynamic-invocation/.

[3] 2018. Combating Potentially Harmful Applications with Machine Learning at Google: Datasets and Models. https://android-developers.googleblog.com/2018/11/combating-potentially-harmful.html.

[4] 2020. Apttool—a tool for reverse engineering android apk files.

[5] Contagio malware dump. https://contagiodump.blogspot.com/2023/02/malware-arsenal-used-by-ember-bear-aka.html.

[6] 2024. Mobile Operating System Market Share Worldwide. https://gs.statcounter.com/os-market-share/mobile/worldwide

[7] 2025. Application fundamentals. https://developer.android.com/guide/components/fundamentals.

[8] 2025. Dalvik bytecode format. https://source.android.com/docs/core/runtime/dalvik-bytecode.

[9] Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. 2016. AndroZoo: collecting millions of Android apps for the research community. In *Proceedings of the 13th International Conference on Mining Software Repositories, MSR*, Miryung Kim, Romain Robbes, and Christian Bird (Eds.). ACM, 468–471.

[10] M. Alzaylaee, S. Yerima, and S. Sezer. 2020. DL-Droid: Deep learning based android malware detection using real devices. *Comput. Secur.* 20 (2020).

[11] Simone Aonzo, Gabriel Claudiu Georgiu, Luca Verderame, and Alessio Merlo. 2020. Obfuscapk: An open-source black-box obfuscation tool for Android apps.
SoftwareX 11 (2020), 100403. https://doi.org/10.1016/j.softx.2020.100403

[12] APKID Team. 2018. APKID: Android Application Package Inspection and Detection. https://github.com/rednaga/APKID. Accessed: 2025-08-08.

[13] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, and K. Rieck. 2014. DREBIN: Effective and Explainable Detection of Android Malware in Your Pocket. In *NDSS'14*.

[14] M. Backes, S. Bugiel, E. Derr, P. McDaniel, D. Octeau, and S. Weisgerber. 2016. On Demystifying the Android Application Framework: Re-Visiting Android Permission Specification Analysis. In *USENIX Security'16*.

[15] Khaled Bakour, H Murat Unver, and Razan Ghanem. 2018. The android malware static analysis: techniques, limitations, and open challenges. In *2018 3rd International Conference on Computer Science and Engineering (UBMK).* Ieee, 586-593.

[16] R. Bernhard, P. Moëlic, M. Mermillod, Y. Bourrier, R. Cohendet, M. Solinas, and M. Reyboz. 2021. Impact of Spatial Frequency Based Constraints on Adversarial Robustness. In *IJCNN'21*.

[17] Rati Bhan, Parvez Faruki, and Rajendra Pamula. 2023. Detection of sensitive malicious android functionalities using inter-component control-flow analysis. *IEEE Access* (2023).

[18] D. Bilar. 2007. Opcode s as predictor for malware. *Int. J. Electron. Secur. Digit. Forensics* '07 (2007).

[19] Alexey Bochkovskiy, Chien-Yao Wang, and Hong-Yuan Mark Liao. 2020. Yolov4: Optimal speed and accuracy of object detection. *arXiv preprint arXiv:2004.10934* (2020).

[20] N. Burkart and M. Huber. 2021. A Survey on the Explainability of Supervised Machine Learning. *J. Artif. Intell. Res.* '21 (2021).

[21] G. Canfora, A. Lorenzo, E. Medvet, F. Mercaldo, and C. Visaggio. 2015. Effectiveness of Opcode ngrams for Detection of Multi Family Android Malware. In *ARES'15*.

[22] H. Chefer, S. Gur, and L. Wolf. 2021. Generic Attention-model Explainability for Interpreting Bi-Modal and Encoder-Decoder Transformers. In *ICCV'21*.

[23] T. Chen, Q. Mao, Y. Yang, M. Lv, and J. Zhu. 2018. TinyDroid: A Lightweight and Efficient Model for Android Malware Detection and Classification. *Mob. Inf. Syst.* '18 (2018).

[24] X. Chen, C. Li, D. Wang, S. Wen, J. Zhang, S. Nepal, Y. Xiang, and K. Ren. 2019. Android HIV: A study of repackaging malware for evading machine-learning detection. *IEEE Transactions on Information Forensics and Security* '19 (2019).

[25] Y. Chen, Z. Ding, and D. Wagner. 2023. Continuous Learning for Android Malware Detection. In *USENIX Security* '23.

[26] Helei Cui, Yajin Zhou, Cong Wang, Qi Li, and Kui Ren. 2018. Towards privacy-preserving malware detection systems for android. In *2018 IEEE 24th International Conference on Parallel and Distributed Systems (ICPADS)*. IEEE, 545-552.

[27] N. Daoudi, J. Samhi, A. Kabore, K. Allix, T. Bissyandé, and J. Klein. 2021. DexRay: A Simple, yet Effective Deep Learning Approach to Android Malware Detection Based on Image Representation of Bytecode. In *Deployable Machine Learning for Security Defense* '21.

[28] H. Darabian, A. Dehghantanha, S. Hashemi, S. Homayoun, and K. Choo. 2020. An opcode-based technique for polymorphic Internet of Things malware detection. *Concurr. Comput. Pract. Exp.* '20 (2020).

[29] S. Desai and H. Ramaswamy. 2020. Ablation-CAM: Visual Explanations for Deep Convolutional Network via Gradient-free Localization. In *WACV* '20.

[30] Y. Ding and S. Zhu. 2019. Malware detection based on deep learning algorithm. *Neural Comput. Appl.* '19 (2019).

[31] S. Dong, M. Li, W. Diao, X. Liu, J. Liu, Z. Li, F. Xu, K. Chen, X. Wang, and K. Zhang. 2018. Understanding Android Obfuscation Techniques: A Large-Scale Investigation in the Wild. In *SecureComm* '18.

[32] A. Dosovitskiy, L. Beyer, A. Kolesnikov, D. Weissenborn, X. Zhai, T. Unterthiner, M. Dehghani, M. Minderer, G. Heigold, S. Gelly, J. Uszkoreit, and N. Housby. 2021. An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale. In *ICLR* '21.

[33] E. Dovom, A. Azmoodeh, A. Dehghantanha, D. Newton, R. Parizi, and H. Karimpour. 2019. Fuzzy pattern tree for edge malware detection and categorization in IoT. *J. Syst. Archit.* '19 (2019).

[34] R. Dwivedi, D. Dave, H. Naik, S. Singhal, O. Rana, P. Patel, B. Qian, Z. Wen, T. Shah, G. Morgan, and R. Ranjan. 2023. Explainable AI (XAI): Core Ideas, Techniques, and Solutions. *ACM Comput. Surv.* '23 (2023).

[35] Sayna Ebrahimi, Sercan Arik, Tomas Pfister, and Yihe Dong. 2023. LANISTR: Multimodal Learning from Structured and Unstructured Data. *arXiv* (2023). https://arxiv.org/abs/2305.16556 NeurIPS 2023 conference submission.

[36] A. Elkhawas and N. Abdelbaki. 2018. Malware detection using opcode trigram sequence with SVM. In *SoftCOM* '18.

[37] J. Engelen and H. Hoos. 2020. A survey on semi-supervised learning. *Mach. Learn.* '20 (2020).

[38] C. Etmann, S. Lunz, P. Maass, and C. Schönlieb. 2021. On the Connection Between Adversarial Robustness and Saliency Map Interpretability. In *ICML* '19.

[39] P. Faruki, A. Bharmal, V. Laxmi, V. Ganmoor, M. Gaur, M. Conti, and M. Rajarajan. 2015. Android Security: A Survey of Issues, Malware Penetration, and Defenses. *IEEE Commun. Surv. Tutorials* '15 (2015).

[40] Joshua Garcia, Mahmoud Hammad, and Sam Malek. 2018. Lightweight, Obfuscation-Resilient Detection and Family Identification of Android Malware. *ACM Transactions on Software Engineering and Methodology* '26, 3 (jan 2018), 1-29. https://doi.org/10.1145/3162625

[41] N. Gordini and V. Veglio. 2017. Customers churn prediction and marketing retention strategies. An application of support vector machines based on the AUC parameter-selection technique in B2B e-commerce industry. *Industrial Marketing Management* '17 (2017).

[42] S. Hou, A. Saas, L. Chen, Y. Ye, and T. Bourlai. 2017. Deep Neural Networks for Automatic Android Malware Detection. In *ASONAM* '17.

[43] S. Hou, Y. Ye, Y. Song, and M. Abdulhayoglu. 2017. HinDroid: An Intelligent Android Malware Detection System Based on Structured Heterogeneous Information Network. In *KDD* '17.

[44] T. Huang and H. Kao. 2018. R2-D2: ColoR-inspired Convolutional Neural Network (CNN)-based Android Malware Detections. In *IEEE BigData* '18.

[45] G. Iadarola, F. Martinelli, F. Mercaldo, and A. Santone. 2021. Towards an interpretable deep learning model for mobile malware detection and family identification. *Comput. Secur.* '21 (2021).

[46] B. Kang, S. Yerima, K. McLaughlin, and S. Sezer. 2016. N-opcode analysis for android malware classification and categorization. In *Cyber Security* '16.

[47] M. Karim, A. Walenstein, A. Lakhotia, and L. Parida. 2005. Malware phylogeny generation using permutations of code. *J. Comput. Virol.* '05 (2005).

[48] D. Kingma and J. Ba. 2015. Adam: A Method for Stochastic Optimization. In *ICLR* '15.

[49] G. Kumar and P. Bhatia. 2014. A detailed review of feature extraction in image processing systems. In *ICACCTech* '14.

[50] S. Lad, A. Adamuthe, et al. 2020. Malware classification with improved convolutional neural network model. *Int. J. Comput. Netw. Inf. Secur.* '20 (2020).

[51] H. Lee, S. Kim, D. Baek, D. Kim, and D. Hwang. 2023. Robust IoT Malware Detection and Classification Using Opcode Category Features on Machine Learning. *IEEE Access* '23 (2023).

[52] M. Leslous, V. Tong, J. Lalande, and T. Genet. 2017. Gpfinder: tracking the invisible in android malware. In *MALWARE* '17.

[53] Kevin Lewi and David J Wu. 2016. Order-revealing encryption: New constructions, applications, and lower bounds. In *Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security*. 1167-1178.

[54] W. Li, J. Ge, and G. Dai. 2015. Detecting Malware for Android Platform: An SVM-Based Approach. In *CSCloud* '15.

[55] Z. Li, F. Liu, W. Yang, S. Peng, and J. Zhou. 2022. A Survey of Convolutional Neural Networks: Analysis, Applications, and Prospects. *IEEE Trans. Neural Networks Learn. Syst.* '22 (2022).

[56] Mario Linares-Vásquez, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, and Denys Poshyvanyk. 2014. How do API changes trigger stack overflow discussions? a study on the Android SDK. In *Proceedings of the 22nd International Conference on Program Comprehension* (Hyderabad, India) (ICPC 2014). Association for Computing Machinery, New York, NY, USA, 83-94. https://doi.org/10.1145/2597008.2597155

[57] Samaneh Mahdavifar, Andi Fitriah Abdul Kadir, Rasool Fatemi, Dima Alhadidi, and Ali A. Ghorbani. 2020. Dynamic Android Malware Category Classification using Semi-Supervised Deep Learning. In *IEEE Intl Conf on Dependable, Autonomic and Secure Computing, Intl Conf on Pervasive Intelligence and Computing, Intl Conf on Cloud and Big Data Computing, Intl Conf on Cyber Science and Technology Congress, DASC/PiCom/CBDCom/CyberSciTech 2020, Calgary, AB, Canada, August 17-22, 2020*. IEEE, 515-522. https://doi.org/10.1109/DASC-PiCom-CBDCom-CyberSciTech49142.2020.00094

[58] D. Maiorca, D. Ariu, I. Corona, M. Aresu, and G. Giacinto. 2015. Stealth attacks: An extended insight into the obfuscation effects on android malware. *Computers & Security* '15 (2015).

[59] N. McLaughlin, J. Rincón, B. Kang, S. Yerima, P. Miller, S. Sezer, Y. Safaei, E. Trickel, Z. Zhao, A. Doupé, and G. Ahn. 2017. Deep Android Malware Detection. In *CODASPY* '17.

[60] A. Oliva and A. Torralba. 2001. Modeling the Shape of the Scene: A Holistic Representation of the Spatial Envelope. *Int. J. Comput. Vis.* '01 (2001).

[61] L. Onwuzurike, E. Mariconti, P. Andriotis, E. Cristofaro, G. Ross, and G. Stringhini. 2019. Mamadroid: Detecting android malware by building markov chains of behavioral models (extended version). *ACM TOPS* '19 (2019).

[62] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga, et al. 2019. Pytorch: An imperative style, high-performance deep learning library. *NeurIPS* '19 (2019).

[63] Fearugus Pendlebury*, Fabio Pierazzi*, Roberto Jordaney, Johannes Kinder, and Lorenzo Cavallaro. 2019. TESSERACT: Eliminating Experimental Bias in Malware Classification across Space and Time. In *28th USENIX Security Symposium*. USENIX Association, Santa Clara, CA. USENIX Sec.

[64] Mila Dalla Preda and Federico Maggi. 2017. Testing android malware detectors against code obfuscation: a systematization of knowledge and unified methodology. *Journal of Computer Virology and Hacking Techniques* 13, 3 (2017), 209-232.

[65] A. Rahali and M. Akhloufi. 2021. MalBERT: Malware Detection using Bidirectional Encoder Representations from Transformers. In *SMC* '21.
[66] A. Rahali and M. Akhloufi. 2023. MalBERTv2: Code Aware BERT-Based Model for Malware Identification. Big Data Cogn. Comput.'23 (2023).

[67] Siegfried Rasthofer, Steven Arzt, and Eric Bodden. 2014. A machine-learning approach for classifying and categorizing android sources and sinks. In *NDSS, Vol. 14*.

[68] V. Rastogi, Y. Chen, and X. Jiang. 2014. Catch Me If You Can: Evaluating Android Anti-Malware Against Transformation Attacks. *IEEE Trans. Inf. Forensics Secur.* '14' (2014).

[69] A. Ravi, V. Chaturvedi, and M. Shafique. 2023. ViT4Mal: Lightweight Vision Transformer for Malware Detection on Edge Devices. *ACM Trans. Embed. Comput. Syst.* '23 (2023).

[70] H. Rawal and C. Parekh. 2017. Android Internal Analysis of APK by Droid_Safe & APK Tool. *International Journal of Advanced Research in Computer Science* '17 (2017).

[71] R. Selvaraju, M. Cogswell, A. Das, R. Vedantam, D. Parikh, and D. Batra. 2017. Grad-CAM: Visual Explanations from Deep Networks via Gradient-Based Localization. In *ICCV* '17.

[72] Sachith Seneviratne, Ridwan Shariffdeen, Sanka Rasnayaka, and Nuran Kasthuri-arachchi. 2022. Self-Supervised Vision Transformers for Malware Detection. *IEEE Access* 10 (2022), 103121–103135. https://doi.org/10.1109/ACCESS.2022.3206445

[73] A. Shabtai, U. Kanonov, and Y. Elovici. 2009. Detection, Alert and Response to Malicious Behavior in Mobile Devices: Knowledge-Based Approach. In *RAID* '09.

[74] F. Shaheen, B. Verma, and M. Asafuddoula. 2016. Impact of automatic feature extraction in deep learning architecture. In *DICTA* '16.

[75] G. Sharma, M. Mabrishi, K. Hiran, and R. Doshi. 2020. Reverse Engineering for potential Malware detection. Android APK Smali to Java. *Journal of Information Assurance & Security* '20 (2020).

[76] M. Siddiqui, M. Wang, and J. Lee. 2008. A survey of data mining techniques for malware detection using file features. In *Southeast Regional Conf.* '08.

[77] Anshuman Singh, Andrew Walenstein, and Arun Lakhotia. 2012. Tracking concept drift in malware families. In *Proceedings of the 5th ACM Workshop on Security and Artificial Intelligence* (Raleigh, North Carolina, USA) (AISec '12). Association for Computing Machinery, New York, NY, USA, 81–92. https://doi.org/10.1145/2381896.2381910

[78] X. Su, W. Shi, X. Qu, Y. Zheng, and X. Liu. 2020. DroidDeep: using Deep Belief Network to characterize and detect android malware. *Soft Comput.* '20 (2020).

[79] Danish Vasan, Mamoun Alazab, Sobia Wassan, Babak Safaei, and Zheng Qin. 2020. Image-Based malware classification using ensemble of CNN architectures (IMCEC). *Comput. Secur.* 92 (2020), 101748. https://doi.org/10.1016/J.COSE.2020.101748

[80] Valérie Viet Triem Tong, Cédric Herzog, Tomás Concepción Miranda, Pierre Graux, Jean-François Lalande, and Pierre Wilke. 2019. Isolating malicious code in Android malware in the wild. In *14th International Conference on Malicious and Unwanted Software (MALCON 2019)*. IEEE Computer society, Nantucket, United States. https://hal-centralesupelec.archives-ouvertes.fr/hal-02288116

[81] Haoyu Wang, Junjun Si, Hao Li, and Yao Guo. 2019. RmvDroid: towards a reliable Android malware dataset with app metadata. In *Proceedings of the 16th International Conference on Mining Software Repositories, MSR 2019, 26-27 May 2019, Montreal, Canada*, Margaret-Anne D. Storey, Bram Adams, and Sonia Haiduc (Eds.). IEEE / ACM, 404–408. https://doi.org/10.1109/MSR.2019.00067

[82] F. Wei, Y. Li, S. Roy, X. Ou, and W. Zhou. 2019. Deep Ground Truth Analysis of Current Android Malware. In *DIMVA* '19.

[83] Q. Wu, X. Zhu, and B. Liu. 2021. A Survey of Android Malware Static Detection Technology Based on Machine Learning. *Mob. Inf. Syst.* '21' (2021).

[84] X. Xiao. 2019. An Image-Inspired and CNN-Based Android Malware Detection Approach. In *ASE* '19.

[85] Rowland Yu. 2014. Android packers: facing the challenges, building solutions. In *Proceedings of the 24th Virus Bulletin International Conference*.

[86] Z. Yuan, Y. Lu, Z. Wang, and Y. Xue. 2014. Droid-Sec: deep learning in android malware detection. In *SIGCOMM* '14.

[87] X. Zhang, F. Breitinger, and I. Baggili. 2017. Rapid Android parser for investigating DEX files (RAPID). *Digital Investigation* '17 (2017).

[88] J. Zhao, R. Masood, and S. Seneviratne. 2021. A review of computer vision methods in network security. *IEEE Communications Surveys & Tutorials* (2021).

[89] M. Zhao, F. Ge, T. Zhang, and Z. Yuan. 2011. AntiMalDroid: An Efficient SVM-Based Malware Detection Framework for Android. In *ICICA* '11.

[90] M. Ziadia, J. Fattahi, M. Mejri, and E. Pricop. 2020. Smali+: An Operational Semantics for Low-Level Code Generated from Reverse Engineering Android Applications. *Inf.* '20 (2020).