# ActDroid: An active learning framework for Android malware detection

Ali Muzaffar<EMAIL_ADDRESS>Hani Ragab Hassen<EMAIL_ADDRESS>Hind
Zantout<EMAIL_ADDRESS>Michael A Lones<EMAIL_ADDRESS>Heriot-Watt
University, Dubai, UAE  Heriot-Watt University, Edinburgh EH14 4AS, United
Kingdom

###### Abstract

The growing popularity of Android requires malware detection systems that can
keep up with the pace of new software being released. According to a recent
study, a new piece of malware appears online every 12 seconds. To address
this, we treat Android malware detection as a streaming data problem and
explore the use of active online learning as a means of mitigating the problem
of labelling applications in a timely and cost-effective manner. Our resulting
framework achieves accuracies of up to 96%, requires as little of 24% of the
training data to be labelled, and compensates for concept drift that occurs
between the release and labelling of an application. We also consider the
broader practicalities of online learning within Android malware detection,
and systematically explore the trade-offs between using different static,
dynamic and hybrid feature sets to classify malware.

###### keywords:

Malware detection; Android security; Machine learning; Online learning; Active
learning

##  1 Introduction

The smartphone industry has seen an exponential growth in recent years, with
Android emerging as the leading OS provider. For instance, in 2023, over 70%
of surveyed smartphone users were found to use an Android device (StatCounter,
2023). However, with this growth comes challenges. Malware is one of these
challenges, and is particularly a problem for Android because of the open
nature of the platform. As an example of this, it is commonplace for users to
download applications from unregulated third-party application repositories
where malware is common. To give an idea of the scale of this problem, it has
been estimated that a new piece of Android malware is found in online
repositories every 12 seconds (Data, 2022).

Numerous studies have shown that machine learning (ML) models perform well in
identifying malware. In two recent reviews of work in this area, we surveyed
(Muzaffar et al., 2021) and experimentally compared (Muzaffar et al., 2023a)
the merits of different ML modelling approaches for Android malware detection.
However, most studies published in this area treat malware detection as a
batch learning problem; that is, examples of malware and benign applications
are collected, and a single model is then trained to discriminate between
these two classes. This approach is unlikely to work well in practice because
Android malware changes over time, a process known as concept drift. Online
learning (OL) is a common approach to dealing with concept drift, and is based
on the idea of treating data as a stream and incrementally training an ML
model as new data becomes available. A number of previous studies have applied
OL to Android malware detection, but we argue that these previous studies did
not fully account for the practicalities of implementing OL in a real world
context.

In particular, we focus on the challenge of labelling, i.e. the process by
which applications become labelled as malware or benign. In previous work, it
has been assumed that a correct label for an application is available as soon
as the application is released. We refer to this scenario as progressive
validation. However, in practice, there is almost always a delay between
application release and the availability of a label. For instance, from our
application dataset, we estimate an average delay of 40 days between the
release of an application and the generation of a VirusTotal VirusTotal
report that can be used to reliably determine its label. We refer to this more
realistic situation as delayed progressive validation and show that it leads
to significant degradation in the accuracy of OL models due to concept drift
that occurs between the release of an application and the availability of a
label for training. In addition to the delay caused by labelling, another
important issue is its cost; for instance, VirusTotal offers only a limited
number of API calls for free, meaning that it can be impractical for a system
that processes hundreds of applications every day to acquire a label for each
application.

In this paper, we address these problems using a novel approach based around
the concept of active learning. Rather than training on all available data,
active learning models select which data samples they learn from in order to
improve their performance. In our framework, this happens in two ways: first,
a model only trains on samples for which it has low confidence; second, when a
model detects concept drift in its outputs, it retrains from scratch using a
set of recent data.Within this context, this paper makes the following
contributions:

  * •

We introduce the concept of delayed progressive validation in OL-based Android
malware detection, and demonstrate that modelling choices made in the absence
of labelling delays can be misleading when models are evaluated within this
more realistic scenario.

  * •

We introduce the concept of active learning within OL-based Android malware
detection and show that this not only compensates for the loss of accuracy due
to labelling delays but also allows models to be trained using up to 76% less
labelled data.

  * •

In order to better understand the design decisions and trade-offs within OL-
based Android malware detection systems, we systematically explore the
strengths and weaknesses of different base models and different static,
dynamic and hybrid features.

##  2 Related Work

In this section we first review past works that used ML methods to detect
Android malware, and then review works that specifically used online learning.

###  2.1 Machine learning in Android malware detection

Android malware detection based on ML has shown promising results (Muzaffar et
al., 2021, 2023a). The most common approach is to build ML models from
features derived using static analysis of the code. Although various features
can be extracted in this way, permissions and API calls have been particularly
widely used for building malware detection models. Of these, API calls appear
to be especially useful for building accurate models (Peiravian and Zhu, 2013;
Rathore et al., 2021; Ma et al., 2019). However, the number of API calls
available in recent Android releases is very large, requiring judicious
feature selection (Muzaffar et al., 2021). Other authors have found opcodes to
be a useful static feature for building accurate models (Bai et al., 2020;
Kang et al., 2016; Xiao and Yang, 2019), and the Drebin feature set (Arp et
al., 2014) has also been used to construct accurate models in past works (Li
et al., 2017; Wang et al., 2017), though our more recent results (Muzaffar et
al., 2023a) suggest that this combination of features is less relevant for
detecting contemporary Android malware.

Fewer works have used features extracted through dynamic analysis of executing
programs, largely due to the higher computational cost of carrying out dynamic
analysis. Interestingly, API call information captured through dynamic
analysis tends to be less useful than static API calls for building models
(Muzaffar et al., 2023a), possibly due to the difficulty of ensuring code
coverage during dynamic analysis. However, several studies (Hou et al., 2017;
Vinod et al., 2019; Xiao et al., 2019) report using system calls to build
models with high detection rates. Perhaps surprisingly, network-based features
have been found to lead to the most accurate models (Zulkifli et al., 2018;
Wang et al., 2016; Muzaffar et al., 2023a), with rates up to 99% reported,
although the difficulty of reliably extracting these features may limit their
practical use.

Hybrid frameworks, which combine static and dynamic analysis, are the least
prominent. Kandukuru and Sharma (2017) and Shyong et al. (2020) both combined
permissions and network traffic features, and reported accuracies of up to
99%. Given the issues surrounding network-based features, in (Muzaffar et al.,
2023a) we considered other combinations of static and dynamic features, and
found that similar levels of accuracy could be achieved by ensembling models
that use static API calls and dynamic system calls. Frameworks such as
Lindorfer et al. (2015)’s MARVIN and Saracino et al. (2018)’s MADAM have also
used market information and other metadata to construct models, leading to
detection rates of up to 98%.

For a recent review of previous studies, see (Muzaffar et al., 2021). There is
considerable variety in the size, age and balance of datasets used for Android
malware detection studies, and this makes comparisons based on published
results challenging. For more information about the relative importance of
different features within a consistent experimental framework, see (Muzaffar
et al., 2023a), in which we reimplemented 16 representative studies using a
large contemporary dataset.

###  2.2 Online learning in Android malware detection

Most ML approaches use batch learning, in which a single model is learnt from
a fixed data set. Online learning (OL), on the other hand, trains models
incrementally, and is used in situations where the data distribution changes
over time, a phenomenon known as concept drift (Singh et al., 2012). Concept
drift is very likely to occur in malware, since attackers continually exploit
new vulnerabilities and try to avoid novel detection techniques, including
those which use ML. This means that online learning is likely to be a more
suitable basis for building and evaluating malware detection models.

Although used considerably less than offline ML, a number of previous studies
have considered the use of OL in Android malware detection to deal with the
problem of concept drift. In one of the earliest studies, Narayanan et al.
(2016) introduced an OL based framework, called DroidOL in which they
extracted inter-procedural control-flow graphs and then used a Weisfeiler-
Lehman graph kernel to train a passive-aggressive classifier. They reported an
accuracy of 84.29%, measured using a dataset of 44,347 benign and 42,910
malicious applications collected in 2014. A year later, they published an
improved framework, CASANDRA (Narayanan et al., 2017) with a reported accuracy
of 89.29%.

A number of more recent studies have reported higher rates of malware
detection. Mirzaei et al. (2019), in their framework ANDRODET, trained
leveraging bag, LearnNSE, Hoeffding tree, stochastic gradient descent,
weighted majority algorithm and Naïve Bayes online algorithms, and reported
accuracies of up to 92.02%. They used the AMD (Polychronakis, 2017) dataset
consisting of 34,962 applications released from 2010 to 2016. Xu et al.
(2019), in their framework DroidEvolver, used a dataset of 33,294 benign and
34,722 malicious applications. DroidEvolver is notable for maintaining an
application buffer and using pseudo-labels to update the models. Every new
application that is classified is checked with the buffer to detect drifting
in the models. Xu et al. reported an F1-Score of 95.27%, which declines by
1.06% on average over five years, though a later study showed that the model
can poison itself with this process (Kan et al., 2021). Ceschin et al. (2023)
took a similar approach to DroidEvovler, by updating both the classifiers and
features when drifting is detected. Using textual attributes as features, the
authors reported accuracies of up to 99% and 89.66%, respectively, on two
different datasets.

Although past studies have reported high levels of malware discrimination,
they have not yet considered the delay between an application’s release and
the availability of a correct label, or they use pseudo-labels only to update
the models, and therefore the results may not accurately represent how the
frameworks would work in real-world scenarios and endpoints.

##  3 Experimental Framework

In this study, we introduce a new active learning OL framework for Android
malware detection. We compare it against non-active approaches to OL in both
progressive validation and delayed progressive validation scenarios, the
former to determine how well it compares against an ideal situation where
labels are always available, and the latter to determine its real benefits
over non-active approaches. Since different OL models may have different
inductive biases, to provide a fair comparison, we use five different base OL
models. We then train each of these models separately on static, dynamic and
hybrid (i.e. a combination of static and dynamic) features. We use the most
common static, dynamic and hybrid features in Android malware detection, as
reported in Muzaffar et al. (2022, 2023a).

###  3.1 Models

We use the following five OL models in our framework:

#### Passive-aggressive classifier (PA)

The passive-aggressive classifier (PA) can handle large datasets and is one of
the most commonly used OL models. PA is a linear model and tries to remain as
close to the current model at each iteration as possible. PA uses a
regularization parameter to calculate the distance between the current model
and the new model and tries to keep the distance close to zero. The classifier
remains passive if the distance is zero. Otherwise, the classifier updates its
weights in order to better classify future instances of data, referred to as
being aggressive (Crammer et al., 2006).

#### Hoeffding tree

The Hoeffding tree classifier is an online variant of standard decision tree
models. Instead of being trained once on a whole dataset, a Hoeffding tree is
incrementally updated as new instances arrive, with new splits being
introduced as necessary according to a statistical test called the Hoeffding
bound, based on a small random sample of data. This allows the tree to split
nodes without examining all the data and builds the tree incrementally while
adapting to changes. This makes Hoeffding trees more efficient than
traditional decision tree approaches while handling large datasets or streams
of data (Bifet et al., 2010).

#### Adaptive random forest

Adaptive random forest combines the strengths of random forest and OL. The
adaptive random forest creates an ensemble of decision trees and uses a
weighted average to produce the final classification prediction, similar to a
traditional random forest. Adaptive random forests, however, update their
trees in real-time as new data arrives. Adaptive random forests also monitor
the performance of their elements over time and replace a tree if its
performance drops (Gomes et al., 2017).

#### K-nearest neighbour (kNN)

This is the online variant of the traditional k-nearest neighbour model. The
online variant of kNN stores a buffer of recent instances to find the nearest
neighbours (using Euclidean distance) to make a final prediction. As the
online variant only stores a fixed number of instances, it can make
predictions more quickly and efficiently than a traditional kNN (Bifet et al.,
2010).

#### Gaussian Naïve Bayes

Gaussian Naïve Bayes uses probability distributions to predict the class of a
new instance by calculating the mean and variance of each feature of each
class. Online Gaussian Naïve Bayes updates the model with each new instance
and so is able to adapt to changes in data more efficiently than a traditional
Gaussian Naïve Bayes model (Bifet et al., 2010).

###  3.2 Drift Detection

Using fixed datasets to train models, like in traditional ML, may lead to
concept drift. OL adapts to concept drift by learning from data arriving as a
stream in real time. Drift detection methods can be used to detect drifting in
ML models. One such algorithm is Adaptive Windowing (ADWIN), which monitors
the average of a sliding window of the data, and if the average changes
significantly over time, it detects change and updates the window size
accordingly (Bifet and Gavalda, 2007). Specifically, ADWIN compares two sub-
windows using a statistical test to identify a significant difference between
them. If the distribution equality does not hold any more between the sub-
windows, ADWIN tags it as concept drift. We use ADWIN to detect concept drift
in this work.

###  3.3 Data

We used a dataset consisting of applications downloaded from various
application stores with release dates between 31 December 2018 and 17 April
2021, described in Muzaffar et al. (2023a). In order to recreate a realistic
OL process, we used the application release dates, which were saved as
metadata. However, this was not possible for malware as those repositories do
not provide information related to release dates. There are several ways of
estimating a release date of an application, from checking the last edit in
the APK file, to the earliest timestamp in the APK file. Timestamps can also
be retrieved from Dex files (compiled Android APK code) or the manifest file.
However, according to Guerra-Manzanares and Bahsi (2022), these methods are
not as reliable as using the VirusTotal report date to estimate the release
date of the application, which provides information about when the application
was first seen online. Therefore, we used the VirusTotal report date as a
baseline to determine the release date of malware.

Figure 1: Number of benign and malware applications in the dataset per day

We grouped the applications by date and used them to train OL models. Figure 1
shows the number of benign and malware applications for each day. We tried to
simulate a real-world scenario of downloading the applications from
application stores and updating the dataset every day with newly released
applications. Hence our data stream is made up of days, and each day consists
of applications, benign or malicious, released on that day. In total we used
62,000 benign and 62,000 malware applications for static features. During
dynamic analysis some applications terminate unexpectedly; the set of
applications for which we were able to complete dynamic analysis was 53,960
benign and 53,202 malware.

###  3.4 Features

We use the following static features:

  * •

Permissions: The most commonly used static feature in the literature. The
application states the permissions used in the manifest file, making this
feature easy to extract. Permissions form the core of the Android security
system and are essentially a set of rules that provide applications with
access to different parts of the device, including hardware components.

  * •

API calls: In offline ML models, API calls have been found to be the best-
performing static feature, so it makes sense to also consider them in an OL
setting. API calls are requests made by applications to the operating system
to perform a specific task. These are used to access system-level
functionality.

  * •

Opcodes: Opcodes provide insights into low-level application behaviour and
have also been found useful in training offline models. Opcodes are machine
code instructions carried out by the CPU, such as performing arithmetic
operations and accessing memory locations.

And the following dynamic features:

  * •

System calls: The most commonly used dynamic feature in the literature. System
calls are requests made by the application to the operating system’s kernel to
perform tasks during the execution of the application.

  * •

API calls: Dynamically obtained API calls are API calls made by the
application during run-time. A prior list of API calls to be tracked is
provided to the analyzer, which then tracks them during the execution of an
application.

Finally, for our hybrid feature set, we use system calls, permissions, and
opcodes. Static API calls were excluded from our hybrid feature sets since
they undergo the most frequent changes, with additions and removals in almost
every update. Furthermore, in previous work, we found there was no significant
benefit to using these alongside dynamic features.

###  3.5 Evaluation

Evaluation of OL models differs from techniques used to evaluate traditional
offline ML models. OL models are trained as new data arrives, and are
therefore also evaluated incrementally. There are two common approaches to
doing this. The first is holdout: training sets are used to incrementally
train the classifier and holdout sets are then used periodically to test the
model. However, this presents challenges in terms of selecting the best
holdout set interval and determining how many holdout sets to use during the
evaluation process. The other approach is progressive: each individual data
item, in our case Android application, is used first to test the existing
model and then to incrementally train the model. This allows the performance
metrics to be updated incrementally, and provides a clearer picture regarding
how the model will perform in a real world scenario over time.

In this work, we use progressive evaluation, and incrementally measure the
accuracy, F1-score, precision, and the confusion matrix of each OL model.
However, the progressive evaluation process is slightly different depending
upon whether we are evaluating a model within a progressive validation
context, i.e. where it is assumed that a correct label is instantly available,
or within the more realistic delayed progressive validation context. In the
latter, each new data item is still used to test the model; however, it is not
used to incrementally train the model until a label becomes available. For a
benign application, the release date is used to determine when it is used to
test the model, and the date of its VirusTotal report is used as the date when
it becomes labelled and is used to train the model. For malware, the release
date is not normally available, and so we estimate it based on the average
period it takes for a newly released application to be assigned a VirusTotal
report. The average time it took for applications in our dataset to be
assigned a VirusTotal report was 40 days, and hence, for malware, the release
date is estimated as 40 days before the date on its VirusTotal report.

An initial seed dataset is used to train the models before incremental
learning begins. That is, all applications with a release date prior to the
date that incremental learning begins are used to train the initial model.
This seed dataset comprises 4,199 malware and 3,925 benign applications. We
also present the results of the models trained on just the initial dataset and
not updating them with new data in Appendix A.

###  3.6 Active learning Framework

Figure 2: Our active learning framework

In this section, we introduce our novel semi-supervised active learning
framework. The concept behind active learning is that a model should not train
on all data samples, but should actively select which data samples it learns
from in order to improve its performance. The idea is that, by focusing on the
most informative data samples, it can improve its learning rate and accuracy,
whilst also requiring less labelled data. In our framework, we implement this
idea by incrementally training a model only on newly released Android
applications for which the model currently has a low confidence in its
prediction, specifically when the model’s confidence is below a threshold of
80%.

The model’s confidence in a prediction is determined by using the library’s
“predict_proba” method. In PA, the confidence of prediction is measured by the
degree of separation between the predicted class and other classes. Typically
in Hoeffding trees, confidence is calculated by the number of training
instances in the leaf node of the predicted class. Confidence in adaptive RF
is determined by the fraction of trees in the ensemble that agrees with the
prediction. KNN uses a voting scheme where each nearest neighbour votes for
the prediction and the fraction of votes is used for the confidence of the
prediction. The probability from Gaussian Naïve Bayes is used as the
confidence of its prediction.

The framework architecture is depicted in Figure 2. The framework comprises
four modules: application management, automated analysis, model management,
and a database. The framework was designed with practical deployment in mind,
and uses tools we have previously built, including dataset collection tools
and static and dynamic analysis tools. The four modules are described below.

#### Application management

This module is responsible for finding and downloading Android applications.
It uses several third-party application crawler scripts to download newly
released applications, and runs these scripts as a cron job every day,
returning applications that were released in the past 24 hours. It is also
responsible for calling the VirusTotal API to obtain reports, when required.

#### Automated analysis

We use our existing tool DroidDissector (Muzaffar et al., 2023b) to carry out
static and/or dynamic analysis of each downloaded application. The tool
extracts all relevant features for a given application, and this module then
returns a feature vector which can be used in the testing or training of
models.

#### Model management

This module maintains the OL models, and is responsible for training and
evaluation, using the feature vector obtained from the automated analysis
module. The models are built using river (Montiel et al., 2021), a python OL
library. The pickle library is used to store models between sessions.

#### Database

The database stores downloaded applications; their label, if a report has been
obtained from VirusTotal; release date, actual or estimated; MD5, SHA-1 and
SHA-256 hashes; and their feature vector. The latter avoids repeated use of
the computationally-expensive automated analysis tools when the same
application is seen multiple times.

##  4 Results

We begin by presenting results from training standard OL models using the two
evaluation scenarios: progressive validation in section 4.1 and delayed
progressive validation in section 4.2. These then provide a baseline against
which to compare the results of our active learning framework, which are
presented in section 4.3. In Appendix A, we also give the outcomes of the
models that were just trained on the initial dataset, without being updated
with fresh data. The findings strongly emphasize the importance of updating
the OL models to sustain their performance over time.

###  4.1 Progressive Validation

We first evaluated standard OL models using the ideal progressive validation
scenario, i.e. when each new data item is assumed to immediately have a label,
and can therefore be used for both incrementally training and testing each
model. Table 1 summarises the results, showing the average metrics for the
best performing class of OL model when different feature sets are used.
Figures 3–5 plot detailed results for the 5 types of OL model when static,
dynamic and hybrid feature sets are used, highlighting how the 4 evaluation
metrics vary over the course of the online learning period.

Table 1: Summary of performance under the progressive validation scenario. For
each feature set, the mean and standard deviations of metrics of the best-
performing OL model are shown. Horizontal rules separate the static, dynamic
and hybrid feature sets.

Feature | OL Model | Accuracy | F1-Score | Precision | TPR | Drifts
---|---|---|---|---|---|---
Permissions | PA | 0.928$\pm 0.016$ | 0.932$\pm 0.015$ | 0.948$\pm 0.018$ | 0.916$\pm 0.017$ | 16
API Calls | PA | 0.971$\pm 0.007$ | 0.973$\pm 0.008$ | 0.963$\pm 0.008$ | 0.978$\pm 0.007$ | 14
Opcodes | PA | 0.952$\pm 0.029$ | 0.955$\pm 0.031$ | 0.952$\pm 0.030$ | 0.958$\pm 0.031$ | 13
System Calls | PA | 0.911$\pm 0.031$ | 0.919$\pm 0.037$ | 0.901$\pm 0.032$ | 0.932$\pm 0.042$ | 17
Dynamic API Calls | PA | 0.912$\pm 0.013$ | 0.900$\pm 0.016$ | 0.915$\pm 0.010$ | 0.889$\pm 0.025$ | 18
System Calls and Permissions | PA | 0.952$\pm 0.019$ | 0.957$\pm 0.022$ | 0.961$\pm 0.019$ | 0.952$\pm 0.025$ | 14
System Calls and Opcodes | PA | 0.958$\pm 0.027$ | 0.951$\pm 0.028$ | 0.961$\pm 0.028$ | 0.952$\pm 0.028$ | 14
Dynamic API Calls and Opcodes | PA | 0.959$\pm 0.025$ | 0.954$\pm 0.024$ | 0.955$\pm 0.024$ | 0.954$\pm 0.025$ | 15
Dynamic API Calls and Permissions | PA | 0.947$\pm 0.013$ | 0.940$\pm 0.013$ | 0.957$\pm 0.013$ | 0.924$\pm 0.015$ | 14

The best models led to a mean accuracy of about 97% across the online learning
period. In all cases, PA appears to be the most effective model, although
adaptive RFs and KNN also perform competitively in most cases. Naive Bayes
models generally perform poorly, suggesting that feature interactions are
important. In terms of feature sets, static API calls lead to the most
accurate models, which reflects similar understanding from the training of
offline models (Muzaffar et al., 2023a). The static API call models also have
the lowest variance, and this can be seen in the plots as a relatively
consistent level of accuracy throughout the online learning period.

However, it is expensive to build models from static API feature sets, since
the dimensionalities of these features sets are very large — 134,207 in our
case. During our experiments, we observed a number of frozen runs due to the
machine running low on resources. In this respect, it is also worth
considering other, cheaper, feature sets. Permissions are very easy to
extract, but performance was significantly lower with permissions-based
models. Opcode feature sets seem to be a better option, since they lead to
relatively good accuracies of around 95%, whilst being a lot lower in
dimensionality — there were 218 opcodes in our feature set.

Dynamic feature sets do not appear to lead to good models, at least when used
individually. Given that they are a lot more expensive to extract than static
features, this seems to indicate against building models from dynamic features
alone. The hybrid feature sets all lead to models with a similar level of
performance, and interestingly combining system calls with permissions leads
to models that are significantly better than those trained using either
feature alone. Given that both of these features have low dimensionality, this
combination could be practically useful, at least in terms of training effort
if not feature extraction cost.

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 3: Progressive validation results on OL models trained on static
features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 4: Progressive validation results on OL models trained on dynamic
features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 5: Progressive validation results on OL models trained on hybrid
features

###  4.2 Delayed Progressive Validation

We next consider the more realistic scenario in which labels are only
available a period of time after the date at which an application is released.
This delays the time between an application becoming available to users and
the application being available to incrementally train a malware detection
model. Table 2 summarises the results, showing the average metrics for the
best performing class of OL model when different feature sets are used.
Figures 6–8 plot detailed results for the 5 types of OL model when static,
dynamic and hybrid feature sets are used.

Table 2: Summary of performance under the delayed progressive validation
scenario. For each feature set, the mean and standard deviations of metrics of
the best-performing OL model are shown. Horizontal rules separate the static,
dynamic and hybrid feature sets.

Feature | OL Model | Accuracy | F1-Score | Precision | TPR | Drifts
---|---|---|---|---|---|---
Permissions | PA | 0.888$\pm 0.040$ | 0.890$\pm 0.039$ | 0.937$\pm 0.040$ | 0.848$\pm 0.038$ | 39
API Calls | KNN | 0.783$\pm 0.015$ | 0.830$\pm 0.069$ | 0.719$\pm 0.090$ | 0.901$\pm 0.024$ | 45
Opcodes | KNN | 0.839$\pm 0.047$ | 0.840$\pm 0.050$ | 0.892$\pm 0.042$ | 0.879$\pm 0.065$ | 34
System Calls | KNN | 0.782$\pm 0.034$ | 0.801$\pm 0.037$ | 0.802$\pm 0.038$ | 0.803$\pm 0.063$ | 52
Dynamic API Calls | KNN | 0.832$\pm 0.037$ | 0.818$\pm 0.044$ | 0.834$\pm 0.038$ | 0.802$\pm 0.059$ | 44
System Calls and Permissions | PA | 0.872$\pm 0.036$ | 0.891$\pm 0.031$ | 0.847$\pm 0.042$ | 0.941$\pm 0.026$ | 34
System Calls and Opcodes | KNN | 0.853$\pm 0.057$ | 0.860$\pm 0.053$ | 0.897$\pm 0.080$ | 0.825$\pm 0.033$ | 33
Dynamic API Calls and Opcodes | KNN | 0.832$\pm 0.077$ | 0.790$\pm 0.064$ | 0.889$\pm 0.098$ | 0.644$\pm 0.034$ | 32
Dynamic API Calls and Permissions | PA | 0.908$\pm 0.032$ | 0.902$\pm 0.034$ | 0.912$\pm 0.041$ | 0.770$\pm 0.052$ | 36

It is clear that the results are very different to those presented in the
previous section. Static API calls are no longer the best feature — in fact,
they are one of the worst — and Fig. 6(a) shows that this is due to a rapid
degradation in performance after the initially good performance on the seed
data. All the models show this degradation to a certain extent, suggesting
there is significant concept drift during the period between application
release and application labelling.

However, it is interesting to see that some features are more robust to this
process than others. Permissions, for example, seem to be relatively robust.
An explanation for this is that the usage of permissions stays fairly constant
over time, since there are few of these and they are concerned with the high-
level behaviour of an application. The use of API calls, on the other hand,
could change quite rapidly as attackers respond to anti-malware defence
strategies and as APIs are added and removed from Android SDK overtime, more
frequently than permissions.

Permissions also lead to the models with the highest precision; that is, if
the model says an application is malware, then it probably is. When combined
with system calls, the resulting models have the highest TPR, but a lower
precision; that is, the addition of system calls makes it more likely that
malware will be correctly identified as such, but the number of false
positives will also be higher.

In terms of model accuracy, the most effective approach appears to be
combining the permissions feature set with the dynamic API calls feature set.
This combination also showed the least degradation in accuracy during the
online learning period. However, the accuracy of the best models is
significantly lower than in the progressive validation scenario, with a loss
in mean accuracy of around 6%. PA is still the best performing model overall,
though KNN now performs better with the majority of the feature sets. Overall
it seems that when OL models are reevaluated in a more realistic scenario, the
outcomes are quite different, and observations about features and models often
do not generalise between the two.

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 6: Delayed progressive validation results on OL models trained on
static features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 7: Delayed progressive validation results on OL models trained on
dynamic features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 8: Delayed progressive validation results on OL models trained on
hybrid features

###  4.3 Active learning Framework

In this section, we report the results of our active learning framework
evaluated within the delayed progressive validation scenario. Table 3
summarises the results, showing the average metrics for the best performing
class of OL model when different feature sets are used. The table also shows
the proportion of the training data for which a model requests labels. Figures
9–11 plot detailed results for the 5 types of OL model when static, dynamic
and hybrid feature sets are used.

Table 3: Summary of performance of the active learning framework under the
delayed progressive validation scenario. For each feature set, the mean and
standard deviations of metrics of the best-performing OL model are shown.
Horizontal rules separate the static, dynamic and hybrid feature sets. The
final column indicates the proportion of labels requested.

Feature | OL Model | Accuracy | F1-Score | Precision | TPR | Labels | Drifts
---|---|---|---|---|---|---|---
Permissions | PA | 0.924$\pm 0.016$ | 0.927$\pm 0.015$ | 0.947$\pm 0.018$ | 0.908$\pm 0.017$ | 31% | 15
API Calls | PA | 0.960$\pm 0.011$ | 0.963$\pm 0.013$ | 0.961$\pm 0.015$ | 0.964$\pm 0.014$ | 34% | 12
Opcodes | PA | 0.924$\pm 0.022$ | 0.929$\pm 0.024$ | 0.923$\pm 0.022$ | 0.936$\pm 0.026$ | 32% | 12
System Calls | PA | 0.867$\pm 0.023$ | 0.882$\pm 0.027$ | 0.862$\pm 0.026$ | 0.897$\pm 0.031$ | 30% | 17
Dynamic API Calls | PA | 0.901$\pm 0.022$ | 0.897$\pm 0.026$ | 0.913$\pm 0.021$ | 0.880$\pm 0.028$ | 27% | 16
System Calls and Permissions | PA | 0.951$\pm 0.018$ | 0.947$\pm 0.021$ | 0.953$\pm 0.018$ | 0.940$\pm 0.024$ | 29% | 13
System Calls and Opcodes | RF | 0.940$\pm 0.012$ | 0.937$\pm 0.018$ | 0.935$\pm 0.016$ | 0.938$\pm 0.022$ | 28% | 12
Dynamic API Calls and Opcodes | RF | 0.953$\pm 0.013$ | 0.947$\pm 0.016$ | 0.950$\pm 0.017$ | 0.946$\pm 0.014$ | 24% | 16
Dynamic API Calls and Permissions | PA | 0.954$\pm 0.014$ | 0.936$\pm 0.013$ | 0.956$\pm 0.013$ | 0.917$\pm 0.016$ | 25% | 14

Notably, the results of the active learning framework are much more similar to
standard-trained OL models evaluated under progressive validation than those
evaluated under delayed progressive validation. The best models achieve
accuracies of about 96%, which is only 1% less than that achieved by standard-
trained OL models in a progressive validation scenario, and 5% better than
that achieved by standard-trained OL models in a delayed progressive
validation scenario. From the plots, it is clear that there is no longer a
pronounced dip in accuracy once incremental learning starts, suggesting that
active learning compensates for the concept drift that occurs between
application release and the updating of the model.

With active learning, static API calls appear to be the most effective feature
set to use, at least in terms of achieving high accuracy and low variance.
However, another consideration here is the number of labelling requests. In
this respect, static API calls are the most costly feature, with labels
requested for 34% of the training data. The lowest levels of label requests
are seen with models trained on hybrid feature sets, with the two dynamic API
call hybrid feature sets requiring labels only around 25% of the time. This is
a significant difference, and may compensate for the marginal loss in
accuracy.

In other respects, too, the results for active learning resemble those for
standard-trained OL evaluated within the progressive evaluation context.
Notably, PA is again the dominant model, and models trained on permissions
return to a baseline of around 92% accuracy.

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 9: Active learning framework results on OL models trained on static
features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 10: Active learning framework results on OL models trained on dynamic
features

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 11: Active learning framework results on OL models trained on hybrid
features

##  5 Discussion

Table 4: Overview of results.

| Progressive Validation | Active Learning | Delayed Progressive Validation
---|---|---|---
Feature | Accuracy | TPR | Labels | Accuracy | TPR | Labels | Accuracy | TPR | Labels
Permissions | 0.928$\pm 0.016$ | 0.916$\pm 0.017$ | 100% | 0.924$\pm 0.016$ | 0.908$\pm 0.017$ | 31% | 0.888$\pm 0.040$ | 0.848$\pm 0.038$ | 100%
API Calls | 0.971$\pm 0.007$ | 0.978$\pm 0.007$ | 100% | 0.960$\pm 0.011$ | 0.964$\pm 0.014$ | 34% | 0.783$\pm 0.015$ | 0.920$\pm 0.024$ | 100%
Opcodes | 0.952$\pm 0.029$ | 0.958$\pm 0.031$ | 100% | 0.924$\pm 0.022$ | 0.936$\pm 0.026$ | 32% | 0.839$\pm 0.047$ | 0.798$\pm 0.065$ | 100%
System Calls | 0.911$\pm 0.031$ | 0.932$\pm 0.042$ | 100% | 0.867$\pm 0.023$ | 0.897$\pm 0.031$ | 30% | 0.782$\pm 0.034$ | 0.803$\pm 0.063$ | 100%
Dynamic API Calls | 0.912$\pm 0.013$ | 0.889$\pm 0.025$ | 100% | 0.901$\pm 0.022$ | 0.880$\pm 0.028$ | 27% | 0.832$\pm 0.037$ | 0.802$\pm 0.059$ | 100%
System Calls and Permissions | 0.952$\pm 0.019$ | 0.952$\pm 0.025$ | 100% | 0.951$\pm 0.018$ | 0.947$\pm 0.024$ | 29% | 0.872$\pm 0.036$ | 0.941$\pm 0.026$ | 100%
System Calls and Opcodes | 0.958$\pm 0.027$ | 0.952$\pm 0.028$ | 100% | 0.940$\pm 0.012$ | 0.938$\pm 0.022$ | 28% | 0.853$\pm 0.057$ | 0.825$\pm 0.033$ | 100%
Dynamic API Calls and Opcodes | 0.959$\pm 0.025$ | 0.954$\pm 0.025$ | 100% | 0.953$\pm 0.013$ | 0.946$\pm 0.014$ | 24% | 0.832$\pm 0.077$ | 0.714$\pm 0.034$ | 100%
Dynamic API Calls and Permissions | 0.947$\pm 0.013$ | 0.924$\pm 0.015$ | 100% | 0.954$\pm 0.014$ | 0.917$\pm 0.016$ | 25% | 0.908$\pm 0.032$ | 0.870$\pm 0.052$ | 100%

Table 4 provides a direct comparison between the models trained in the three
experimental sections. This further emphasises the fact the results for active
learning are close to the ideal baseline achieved when OL models are trained
under the assumption that labels are instantly available, even though they are
trained with a labelling delay. This is very encouraging, since it suggests
that the use of active learning overcomes the significant deficit in
performance that normally occurs when a labelling delay is introduced.

It does raise the question of where this resilience comes from, since there
are two parts to the active learning framework: the selective use of training
data, and the periodic retraining after concept drift has been detected.
Periodic retraining means that the models can offload the baggage of
historical information that is no longer relevant, and this by itself would
seem to give an advantage over standard OL. However, if this was the only
factor, then we would expect to see a periodic pattern of decline and
improvement in the performance plots, which is not evident. This suggests that
selective training (the core of active learning) is also important, and that
selective use of training data causes the models to better react to change,
since they are generally being trained on data that does not resemble that
which they have seen before (assuming such data would have higher confidence).
This is also evident in the considerably lower number of drifts detected
compared to delayed progressive validation on each model, while maintaining
similar levels to progressive validation.

We have discussed the influence of models, features and training regime, but
it is also important to reflect on the fact that there are trade-offs in the
design of any real world system. We have noted several: the time and effort
required to extract features, the time and computational resources required to
build models, and the amount of labelled data required. The best choice of
machine learning approach is, to some extent, influenced by the relative
weightings placed on these three factors.

The extraction of dynamic features requires that an application is executed
for a certain period of time within a simulator. This process took about 2-3
minutes for each of the applications in our data set, where on most days there
were up to around 400 applications released. On the machine we used, it was
generally feasible to carry out dynamic analysis of only a couple of
applications in parallel. This means that, in practice, assuming the same
computational resources, a sizeable part of each day would be required just to
extract dynamic features. This limits the practical utility of using dynamic
and hybrid feature sets for training online learning models. So, whilst there
does appear to be some benefit in terms of accuracy to using these feature
sets in certain scenarios (notably, delayed progressive validation when active
learning is not used), it may not work as a practical solution.

The time and computational resources required to build models is less of a
concern. In our experiments, most models could be incrementally updated in
seconds for each new application. Retraining from seed data following periods
of concept drift was also easily manageable using our modest computational
resources. The only real issue, as noted above, was dealing with large feature
sets, meaning in particular that – although the best feature in terms of
accuracy — building models from static API feature sets can be problematic.
However, this could potentially be addressed using a better-equipped
production environment.

From our perspective at least, obtaining labelled data is the most expensive
of these processes. Currently, with a free-to-use public license, the
VirusTotal API is limited to 500 requests per day at a rate of 4 per minute.
The reduction in labelling requests that results from using active learning is
consequently an important part of making this framework practical, and comes
as a significant benefit in addition to the improvement in accuracy. However,
it should be noted that higher limits are available for commercial licences,
so this may be less of an issue in a non-academic context.

##  6 Conclusions

The interplay between attackers and defenders means that malware is very
likely to display concept drift over time, with the underlying basis of
malware attacks changing as anti-malware products respond to these attacks.
Given this, it is perhaps surprising that most prior work on Android malware
detection has treated it as a batch learning problem rather than an online
learning problem. Those who have treated it as an online learning problem have
typically evaluated their methodologies under the assumption that the label
for an application is known immediately upon its release. In practice, this is
unlikely, and it will only become clear later on whether an application is
malware or benign.

Using a large contemporary dataset, we have shown that this labelling delay
significantly impedes the predictive performance of standard online learning
models trained to recognise malware, due to the concept drift that occurs in
the period between application release and application labelling. Models
trained and evaluated under the assumption that labels are immediately
available achieve accuracies of up to 97%. When realistic labelling delays are
introduced, the best accuracies drop to around 91%. Furthermore, observations
about the best choice of model do not remain valid when a labelling delay is
introduced.

In this paper, we have introduced a novel active learning framework, and have
shown that it largely compensates for the performance reduction observed when
realistic labelling delays are introduced, resulting in models with accuracies
of up to 96%. Importantly, it also reduces the amount of labelled data
required to train models, with only 24-34% of the training data used,
depending on the chosen model. This is important because labelling is costly.
Our framework consists of two main parts: the selective use of training data
during incremental learning, and the periodic retraining of models from seed
data when concept drift is detected in the existing model. Both of these
components appear to be important.

We also carried out an in-depth investigation of the influence of model and
feature choice within an online learning context. Of the five models we
investigated, passive-aggressive classifiers were generally the best
performing, though adaptive random forests and adaptive KNNs also performed
well. Naive Bayes performed very poorly. Of the nine feature sets we used,
measures of API call usage obtained from static analysis generally led to the
best performing models. However, the high-dimensionality of this feature set
was problematic. We observed around a 4% penalty to using the more easily
extracted, and far less numerous, permissions and opcode features.

Features extracted using dynamic analysis were generally less useful, at least
by themselves. However, when combined with static features, they led to the
best models when non-active learning models were evaluated within a delayed
labelling context. When active learning was used, these hybrid feature
combinations required the least training data, and were the best performing
after static API calls. However, there is a considerable cost to doing dynamic
analysis, and this may limit the practical deployment of these hybrid feature
sets.

Future Android operating system updates may introduce new permissions and API
calls. As a result, future works may include dynamic feature sets to train the
online learning models. This may be using the full new feature sets or using
feature selection algorithms to select the most relevant features in
intervals. Using an ensemble of online learning models in the future can also
result in robust classifiers.

##  Appendix A Results of Standard Models

We carried out another simulation in which the OL models were only trained
with seed data and thereafter evaluated and not updated with new data. Figures
12–14 plot detailed results for the 5 types of OL model when static, dynamic,
and hybrid feature sets are used. All the models show a decline in accuracy
and F1-score after a small period initially.

Models trained using static features showed a constant decline in accuracy
with new applications. The models also showed high precision rates and low TPR
suggests that the models may be overly conservative in predicting positive
instances, resulting in a low TPR while maintaining a low false positive rate.

The performance of dynamic features was comparable to that of static features,
with a little increase in metrics midway through and a progressive decline
trend toward the end.

While hybrid features showed stable F1-scores, their accuracy significantly
dropped. The models also showed high precision rates but low TPR, which
suggested the model is extremely cautious in classifying applications as
malware.

A considerable decline in performance can be seen and proves the use of OL
helps in maintaining the performance of the models over time.

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 12: Results of OL models trained on static features with only initial
seed data and no further updates

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 13: Results of OL models trained on static features with only initial
seed data and no further updates

(a) Accuracy

(b) F1-Score

(c) Precision

(d) TPR

Figure 14: Results of OL models trained on hybrid features with only initial
seed data and no further updates

## References

  * Arp et al. (2014) Arp, D., Spreitzenbarth, M., Hübner, M., Gascon, H., Rieck, K., 2014.  Drebin: Effective and Explainable Detection of Android Malware in Your Pocket, in: Network and Distributed System Security Symposium (NDSS).  doi:10.14722/ndss.2014.23247.
  * Bai et al. (2020) Bai, H., Xie, N., Di, X., Ye, Q., 2020.  FAMD: A fast multifeature android malware detection framework, design, and implementation.  IEEE Access 8, 194729–194740.  doi:10.1109/ACCESS.2020.3033026.
  * Bifet and Gavalda (2007) Bifet, A., Gavalda, R., 2007\.  Learning from time-changing data with adaptive windowing, in: Proceedings of the 2007 SIAM international conference on data mining, SIAM. pp. 443–448.
  * Bifet et al. (2010) Bifet, A., Holmes, G., Kirkby, R., Pfahringer, B., 2010\.  MOA: massive online analysis.  J. Mach. Learn. Res. 11, 1601–1604.  URL: http://portal.acm.org/citation.cfm?id=1859903.
  * Ceschin et al. (2023) Ceschin, F., Botacin, M., Gomes, H.M., Pinagé, F., Oliveira, L.S., Grégio, A., 2023\.  Fast & furious: On the modelling of malware detection as an evolving data stream.  Expert Systems with Applications 212, 118590.
  * Crammer et al. (2006) Crammer, K., Dekel, O., Keshet, J., Shalev-Shwartz, S., Singer, Y., 2006.  Online passive aggressive algorithms .
  * Data (2022) Data, G., 2022.  G data mobile security report: Conflict in ukraine causes decline in malicious android apps.
  * Gomes et al. (2017) Gomes, H.M., Bifet, A., Read, J., Barddal, J.P., Enembreck, F., Pfharinger, B., Holmes, G., Abdessalem, T., 2017\.  Adaptive random forests for evolving data stream classification.  Machine Learning 106, 1469–1495.
  * Guerra-Manzanares and Bahsi (2022) Guerra-Manzanares, A., Bahsi, H., 2022\.  On the relativity of time: Implications and challenges of data drift on long-term effective android malware detection.  Computers & Security 122, 102835\.
  * Hou et al. (2017) Hou, S., Ye, Y., Song, Y., Abdulhayoglu, M., 2017.  Hin droid: An intelligent Android Malware detection system based on structured heterogeneous information network.  Proceedings of the ACM SIGKDD International Conference on Knowledge Discovery and Data Mining Part F1296, 1507–1516.  doi:10.1145/3097983.3098026.
  * Kan et al. (2021) Kan, Z., Pendlebury, F., Pierazzi, F., Cavallaro, L., 2021\.  Investigating labelless drift adaptation for malware detection, in: Proceedings of the 14th ACM Workshop on Artificial Intelligence and Security, pp. 123–134.
  * Kandukuru and Sharma (2017) Kandukuru, S., Sharma, R.M., 2017\.  Android malicious application detection using permission vector and network traffic analysis, in: 2017 2nd International Conference for Convergence in Technology (I2CT), pp. 1126–1132.  doi:10.1109/I2CT.2017.8226303.
  * Kang et al. (2016) Kang, B.J., Yerima, S.Y., McLaughlin, K., Sezer, S., 2016\.  N-opcode analysis for android malware classification and categorization.  2016 International Conference on Cyber Security and Protection of Digital Services, Cyber Security 2016 , 13–14doi:10.1109/CyberSecPODS.2016.7502343.
  * Li et al. (2017) Li, D., Wang, Z., Li, L., Wang, Z., Wang, Y., Xue, Y., 2017.  FgDetector: Fine-Grained Android Malware Detection.  Proceedings - 2017 IEEE 2nd International Conference on Data Science in Cyberspace, DSC 2017 , 311–318doi:10.1109/DSC.2017.13.
  * Lindorfer et al. (2015) Lindorfer, M., Neugschwandtner, M., Platzer, C., 2015.  MARVIN: Efficient and Comprehensive Mobile App Classification through Static and Dynamic Analysis.  Proceedings - International Computer Software and Applications Conference 2, 422–433.  doi:10.1109/COMPSAC.2015.103.
  * Ma et al. (2019) Ma, Z., Ge, H., Liu, Y., Zhao, M., Ma, J., 2019.  A Combination Method for Android Malware Detection Based on Control Flow Graphs and Machine Learning Algorithms.  IEEE Access 7, 21235–21245.  doi:10.1109/ACCESS.2019.2896003.
  * Mirzaei et al. (2019) Mirzaei, O., de Fuentes, J.M., Tapiador, J., Gonzalez-Manzano, L., 2019\.  ANDRODET: An adaptive Android obfuscation detector.  Future Generation Computer Systems 90, 240–261.  doi:10.1016/j.future.2018.07.066.
  * Montiel et al. (2021) Montiel, J., Halford, M., Mastelini, S.M., Bolmier, G., Sourty, R., Vaysse, R., Zouitine, A., Gomes, H.M., Read, J., Abdessalem, T., et al., 2021\.  River: machine learning for streaming data in python .
  * Muzaffar et al. (2022) Muzaffar, A., Hassen, H.R., Lones, M.A., Zantout, H., 2022\.  An in-depth review of machine learning based android malware detection.  Computers & Security , 102833.
  * Muzaffar et al. (2023a) Muzaffar, A., Hassen, H.R., Zantout, H., Lones, M.A., 2023a.  A comprehensive investigation of feature and model importance in android malware detection.  URL: https://arxiv.org/abs/2301.12778, doi:10.48550/ARXIV.2301.12778.
  * Muzaffar et al. (2023b) Muzaffar, A., Hassen, H.R., Zantout, H., Lones, M.A., 2023b.  Droiddissector: A static and dynamic analysis tool for android malware detection.  arXiv:2308.04170.
  * Muzaffar et al. (2021) Muzaffar, A., Ragab Hassen, H., Lones, M.A., Zantout, H., 2021\.  Android malware detection using api calls: A comparison of feature selection and machine learning models, in: International Conference on Applied CyberSecurity, Springer. pp. 3–12.
  * Narayanan et al. (2017) Narayanan, A., Chandramohan, M., Chen, L., Liu, Y., 2017.  Context-Aware, Adaptive, and Scalable Android Malware Detection Through Online Learning.  IEEE Transactions on Emerging Topics in Computational Intelligence 1, 157–175.  doi:10.1109/tetci.2017.2699220, arXiv:1706.00947.
  * Narayanan et al. (2016) Narayanan, A., Yang, L., Chen, L., Jinliang, L., 2016\.  Adaptive and scalable Android malware detection through online learning.  Proceedings of the International Joint Conference on Neural Networks 2016-Octob, 2484–2491.  doi:10.1109/IJCNN.2016.7727508, arXiv:arXiv:1606.07150v2.
  * Peiravian and Zhu (2013) Peiravian, N., Zhu, X., 2013\.  Machine Learning for Android Malware Detection Using Permission and API Calls, in: 2013 IEEE 25th International Conference on Tools with Artificial Intelligence, IEEE. pp. 300–305.  URL: http://ieeexplore.ieee.org/document/6735264/, doi:10.1109/ICTAI.2013.53.
  * Polychronakis (2017) Polychronakis, Michalis; Meier, M., 2017.  [Lecture Notes in Computer Science] Detection of Intrusions and Malware, and Vulnerability Assessment Volume 10327 —— Deep Ground Truth Analysis of Current Android Malware. volume 10.1007/978-3-319-60876-1.  URL: http://gen.lib.rus.ec/scimag/index.php?s=10.1007/978-3-319-60876-1_12, doi:10.1007/978-3-319-60876-1_12.
  * Rathore et al. (2021) Rathore, H., Sahay, S.K., Rajvanshi, R., Sewak, M., 2021\.  Identification of Significant Permissions for Efficient Android Malware Detection. volume 355.  Springer International Publishing.  URL: http://dx.doi.org/10.1007/978-3-030-68737-3{_}3, doi:10.1007/978-3-030-68737-3_3.
  * Saracino et al. (2018) Saracino, A., Sgandurra, D., Dini, G., Martinelli, F., 2018\.  MADAM: Effective and Efficient Behavior-based Android Malware Detection and Prevention.  IEEE Transactions on Dependable and Secure Computing 15, 83–97.  doi:10.1109/TDSC.2016.2536605.
  * Shyong et al. (2020) Shyong, Y.C., Jeng, T.H., Chen, Y.M., 2020.  Combining Static Permissions and Dynamic Packet Analysis to Improve Android Malware Detection , 75–81doi:10.1109/iccci49374.2020.9145994.
  * Singh et al. (2012) Singh, A., Walenstein, A., Lakhotia, A., 2012.  Tracking concept drift in malware families, in: Proceedings of the 5th ACM workshop on Security and artificial intelligence, pp. 81–92.
  * StatCounter (2023) StatCounter, 2023.  Mobile operating system market share worldwide.  URL: http://gs.statcounter.com/os-market-share/mobile/worldwide. [Online; Accessed: January 16, 2023].
  * Vinod et al. (2019) Vinod, P., Zemmari, A., Conti, M., 2019.  A machine learning based approach to detect malicious android apps using discriminant system calls.  Future Generation Computer Systems 94, 333–350.  URL: https://doi.org/10.1016/j.future.2018.11.021, doi:10.1016/j.future.2018.11.021.
  * (33) VirusTotal, .  Virustotal.  https://www.virustotal.com.  [Online accessed January 10, 2023].
  * Wang et al. (2016) Wang, S., Chen, Z., Zhang, L., Yan, Q., Yang, B., Peng, L., Jia, Z., 2016.  TrafficAV: An effective and explainable detection of mobile malware behavior using network traffic.  2016 IEEE/ACM 24th International Symposium on Quality of Service, IWQoS 2016 doi:10.1109/IWQoS.2016.7590446.
  * Wang et al. (2017) Wang, X., Zhang, D., Su, X., Li, W., 2017.  Mlifdect: Android malware detection based on parallel machine learning and information fusion.  Security and Communication Networks 2017\.  doi:10.1155/2017/6451260.
  * Xiao and Yang (2019) Xiao, X., Yang, S., 2019.  An image-inspired and cnn-based android malware detection approach, in: 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), IEEE. pp. 1259–1261.
  * Xiao et al. (2019) Xiao, X., Zhang, S., Mercaldo, F., Hu, G., Sangaiah, A.K., 2019.  Android malware detection based on system call sequences and LSTM.  Multimedia Tools and Applications 78, 3979–3999.  doi:10.1007/s11042-017-5104-0.
  * Xu et al. (2019) Xu, K., Li, Y., Deng, R., Chen, K., Xu, J., 2019.  Droidevolver: Self-evolving android malware detection system, in: 2019 IEEE European Symposium on Security and Privacy (EuroS&P), IEEE. pp. 47–62.
  * Zulkifli et al. (2018) Zulkifli, A., Hamid, I.R.A., Shah, W.M., Abdullah, Z., 2018\.  Android malware detection based on network traffic using decision tree algorithm.  Advances in Intelligent Systems and Computing 700, 485–494.  doi:10.1007/978-3-319-72550-5_46.