# XMD: An expansive Hardware-telemetry based Mobile Malware Detector for
Endpoint Detection

Harshit Kumar, Biswadeep Chakraborty, Sudarshan Sharma, Saibal Mukhopadhyay
Dept. of Electrical and Computer Engineering
Georgia Institute of Technology, Atlanta, USA
{hkumar64, biswadeep<EMAIL_ADDRESS><EMAIL_ADDRESS>

###### Abstract

Hardware-based Malware Detectors (HMDs) have shown promise in detecting
malicious workloads. However, the current HMDs focus solely on the CPU core of
a System-on-Chip (SoC) and, therefore, do not exploit the full potential of
the hardware telemetry. In this paper, we propose XMD, an HMD that uses an
expansive set of telemetry channels extracted from the different subsystems of
SoC. XMD exploits the thread-level profiling power of the CPU-core telemetry,
and the global profiling power of non-core telemetry channels, to achieve
significantly better detection performance than currently used Hardware
Performance Counter (HPC) based detectors. We leverage the concept of manifold
hypothesis to analytically prove that adding non-core telemetry channels
improves the separability of the benign and malware classes, resulting in
performance gains. We train and evaluate XMD using hardware telemetries
collected from 723 benign applications and 1033 malware samples on a commodity
Android Operating System (OS)-based mobile device. XMD improves over currently
used HPC-based detectors by 32.91% for the in-distribution test data. XMD
achieves the best detection performance of 86.54% with a false positive rate
of 2.9%, compared to the detection rate of 80%, offered by the best performing
signature-based Anti-Virus(AV) on VirusTotal, on the same set of malware
samples.

###### Index Terms:

malware detection, machine learning, security, Android OS

Figure 1: Comprehensive cross-stack monitoring performed by modern Endpoint-
Detection : [Left] Software-based malware detection approaches, [Right]
Proposed XMD operating on expansive set of telemetry channels.

##  I Introduction

The previous decade has witnessed an explosive growth of malicious
applications, compromising the security of modern devices [1]. Consequently,
Endpoint Security has moved towards behavior analysis that involves continuous
monitoring of sensors across the compute stack and rigorous data analysis [2,
3]. As shown in Figure 1, behavior analysis techniques monitor the program’s
execution using semantically rich information sources like registry keys,
network endpoints, system calls, and operating system (OS) hooks. However,
malicious actors can potentially subvert such protection mechanisms by
tampering with the software telemetry [4, 5]. Moreover, such software-level
detection approaches result in significant performance overhead. Hence, there
has been a recent thrust in data-driven approaches for detecting malicious
workloads using low-level hardware telemetry, which promises low overheads and
better resilience against tampering compared to software-based telemetry [6].

The application of hardware-level telemetry, like HPC, energy telemetry
channels (e.g., Intel’s RAPL), and Dynamic Voltage and Frequency Scaling
(DVFS), towards malware detection, has recently gained interest [7, 8, 9, 6,
10, 11, 12, 13, 14, 15, 16, 17, 18]. Monitoring the hardware telemetry
provides visibility into active threats, even during the presence of anti-
evasion techniques like obfuscation [11], or cloaking in virtual machines [4].
As shown in Figure 1, HMD, along with software-level detection techniques, is
part of the commercially-deployed collaborative defense model, e.g., Endpoint
Detection and Response (EDR), that detects and contains threats [19, 4]. In
such a collaborative system, HMDs can provide an additional layer of detection
capability across the kill chains, complement other detectors, and restrict
the ability of the adversary to move in the environment without triggering
detection.

Demme et al. demonstrated the potential of using Hardware Performance Counters
(HPCs) for detecting Android malware, Linux Rootkits, and side-channel attacks
[6]. Thereafter, various methodologies were proposed for enhancing the
predictive performance [9, 14, 7, 16, 17], and to reduce the performance
overhead of HMDs [8, 10]. Additionally, efforts have been made to delve into
alternate CPU-telemetry sources [13]. However, as highlighted by prior
literature, one key drawback of using HPCs is the limited number of Hardware
Counters, which consequently restricts the behavioral profiling power of such
an approach. Botacin & Grégio recently introduced the concept of attack space
that refers to the range of possible actions or techniques an attacker can
utilize against a system [20]. The authors argued that HPCs are more fitting
for an attack space comprising of malicious workloads that exhibit
architectural side-channel effects. We concur with their thesis and further
assert that the exclusive reliance on CPU hardware telemetry only provides a
partial view of the impact of running workloads on an SoC, thereby limiting
the scope of attack space that an HPC-based HMD can cover. The CPU-telemetry-
based approach does not leverage the vast potential of comprehensive hardware
telemetry from non-core devices of the SoC (e.g., Graphics Processing Unit
(GPU), memory, buses, network). In light of this, our work seeks to boost the
detection performance of HPC-based HMDs when dealing with general-purpose
malware, by leveraging hardware telemetry from non-core devices in the SoC.

Proposed Work. Our proposed approach, XMD, addresses the limitations in
behavioral visibility inherent to HPC-based HMDs. These limitations arise
primarily due to their exclusive reliance on CPU-based telemetry. By
supplementing HPC-based telemetry with system-wide telemetry from non-core
devices of the SoC, such as the GPU, memory, buses, and network, XMD notably
improves upon the HPC-based HMDs. This system-wide telemetry data is extracted
from DVFS signatures associated with non-core devices and low-level telemetry
from select SYSFS nodes. Such an expanded telemetry set equips the ML agent
with a broader understanding of a workload’s impact on the entire SoC. This
subsequently extends the attack space that the HMD can effectively cover,
resulting in significant improvements in detection performance compared to
prior HPC-based HMDs.

Our key innovation is grounded in the theorem developed by leveraging the
concept of manifold hypothesis (Section IV). Prior works in deep learning have
used manifold hypothesis for studying the geometry of manifolds in Deep Neural
Networks (DNNs) for vision [21], audition [22], and language modeling [23,
24]. Such analytical frameworks have explained the generalization performance
of DNNs [25]. In this work, we use manifold hypothesis to show that adding
additional telemetry channels from non-core devices of the SoC increases the
solution volume [26] of the ML classifier and leads to the superior
classification performance of XMD.

To empirically validate our approach, we created a bare-metal framework to
automate the collection of hardware telemetry data using a commodity Android
mobile device (Google Pixel-3). Using this data-collection framework, we
developed the STD-Dataset which helped us empirically validate our primary
hypothesis. Welch’s t-test-based statistical analysis performed on the
collected data revealed a significant increase in the distinguishability
between benign and malicious classes as we incorporated hardware telemetry
from various non-core devices. The increased distinguishability consequently
led to an improvement in the predictive performance of ML classifiers. For
instance, the F1-score achieved by using only CPU-based telemetry (i.e., HPC
data), as in prior works, ranged from 0.66-0.76. However, by augmenting this
CPU-based telemetry with our proposed non-core telemetry channels, we
successfully elevated the predictive accuracy of the machine learning
classifier to an F1-score of 0.90-0.92. These results underscore the utility
of integrating telemetry from various non-core devices in improving the
detection performance of an HMD.

To summarize, our main contributions are as follows:

  * •

We develop a theorem using manifold hypothesis to prove that using telemetry
channels from non-core devices improves the detection performance of the HMD.

  * •

We perform empirical experiments to validate the proposed theorem. We design a
bare-metal data collection framework to collect expansive hardware telemetry
that captures a workload’s impact on different sub-systems of the SoC like
CPU, GPU, Memory, Buses, and Network. Using the collected data, we show that
using multiple telemetry channels from the different sub-systems of an SoC
results in better classification performance when compared to classifiers that
operate on the telemetry from a single sub-system, e.g., CPU-based telemetry.

##  II Background and Threat Model

###  II-A Classes of Hardware Telemetry

Thread-level Profiling : Hardware Performance Counters (HPCs).  HPCs are
dedicated physical registers in modern processors that store the count of
microarchitectural events in a CPU core during process execution. They were
originally designed to identify performance bottlenecks. To obtain counter
information from the registers, they are configured to monitor specific
hardware events of interest. HPCs can perform thread-level profiling by saving
the register values during context switches and, therefore, try to avoid
contamination due to events from other processes [27]. With the adoption of ML
techniques in security, HPCs have recently been repurposed as low-level
telemetry for identifying malicious workloads in HMDs [7, 8, 9, 6, 10, 11, 12,
14, 15, 16, 18, 28].

Two main limitations of HPC-based HMDs frequently emerge in the literature:
non-determinism and the limited number of monitorable HPC events. Non-
determinism results from measurement errors in the HPCs [27]. However, the
robustness of ML-agents, which can learn and generalize from broader patterns
and trends in the data, potentially mitigates this. The second limitation
pertains to the finite number of HPC events that can be simultaneously
monitored due to limited physical registers (for instance, the Snapdragon
Chipset in our study only accommodates four). This restriction limits the
behavioral information available, narrowing the scope of the attack space that
an HPC-based defense can cover. This constraint implies that HPC-based
defenses are best suited to handle malware with prominent architectural side-
channels, as recent works suggest [20]. Moreover, taken together, these two
limitations suggest that HPC-based HMDs which focus on a single mode of
behavioral information (CPU-telemetry) coupled with non-determinism makes it
vulnerable to attacks designed to skew the CPU telemetry measurements and
induce mis-classifications [12, 27].

System-wide Profiling: Dynamic Voltage and Frequency Scaling (DVFS).  DVFS is
an integral part of all power management systems. It reduces the power
consumption of an SoC by scaling down the voltage and frequency states of the
different sub-systems (e.g., CPU, GPU, buses, caches, and memory) based on the
targetted performance requirements of the software workloads. As a result, the
DVFS states of a sub-system capture its activity level, providing insight into
the impact of running workload on that sub-system. Security implications of
the DVFS framework have been studied both from an offensive perspective [29,
30, 31] and to create defenses [32, 13]. Since Android OS (considered in this
paper) is based on the Linux kernel, the DVFS states of the CPU and non-CPU
devices are accessible through the cpufreq, and devfreq framework [33, 34].

It should be noted that the DVFS channels (and other SYSFS nodes used in this
work) capture the global state of the device as compared to HPCs that are used
for monitoring the specific threads/processes. In mobile devices, numerous
system-level threads and user applications are simultaneously contending for
hardware resources. This makes the DVFS channels susceptible to noise arising
from such background processes. However, in the case of mobile devices, such
as the one considered in our work, Chawla et al. has empirically shown that
the foreground applications predominantly influence the DVFS states of the
device [13]. The DVFS channels provide better visibility into the impact of
running a workload on the entire SoC at the cost of additional non-determinism
compared to HPCs that capture a workload’s impact on the CPU core of the SoC.

###  II-B Threat Model

XMD is designed for multi-core mobile devices where a user interacts with a
limited set of foreground applications (1-2) at a given time. In this model,
the potential attacker can deploy malware with capabilities to manipulate
application-level activities, but they do not have root access to the system.
The XMD framework operates in kernel-land, as accessing the values of HPCs and
system-wide telemetry channels (DVFS, SYSFS) requires root privileges.
Therefore, the framework assumes the OS kernel to be secure and not
compromised, an assumption shared with commercially deployed HMDs [4]. A
compromised kernel, in fact, would undermine the process tracking capabilities
of the Endpoint Detection and Response (EDR) system and thwart the
trustworthiness of the telemetry on which the EDR relies [5]. Therefore,
ensuring kernel-integrity is out of XMD’s scope.

XMD is susceptible to collusion-based attacks where a seemingly benign,
attacker-controlled thread may tamper with system-wide telemetry channels.
Much like HPC-based HMDs, the non-determinism of the hardware telemetry could
allow a motivated attacker to mask the activities of the malicious process
amidst the noise [27]. However, XMD’s utilization of telemetry from various
non-core devices potentially provides an additional layer of defense against
attackers capable of skewing measurements from a single SoC module (such as
CPU telemetry). Additional limitations and potential solutions are further
discussed in Section VIII.

##  III Related Works and Motivation

Detection of malicious workloads using hardware telemetry has been extensively
studied in the literature [7, 8, 9, 6, 10, 11, 12, 13, 14, 15, 16, 18, 28].
Due to the variabilities in the data collection methodology, we do not
empirically compare against prior works but offer a qualitative comparison
against the surveyed works. We categorize the drawbacks of these works as
follows:

Restricted scope of hardware telemetry collection. Prior works on HMD
primarily focus on a single modality of data extracted from the CPU of the SoC
[7, 8, 9, 6, 10, 11, 12, 13, 14, 15, 16, 18, 28]. These low-level signatures
either contain thread-level behavior (e.g., HPC) or global behavior (e.g.,
CPU-DVFS). While these data-driven approaches have shown decent test accuracy
on their dataset, they do not use the telemetry sources available from the
different sub-systems of the SoC. They, therefore, do not realize the full
potential of the HMD.

Benchmarks used as benign workloads. Prior works on HMD use benchmark
applications for benign workloads [7, 8, 9, 6, 10, 13, 15, 18]. Few works use
regular benign applications (e.g., from Play Store); however, they mix these
applications with benchmark applications [12, 16]. Compared to regular benign
applications, which require interaction with the device to explore the
different threads of operation, running the benchmark application is
straightforward, easing the large-scale data collection process. These
benchmark applications are synthetic workloads designed to test a specific
functionality of the SoC and are not representative of real-world benign
applications, introducing a bias in the dataset.

Comparison against Software-based AVs. Prior works present a qualitative
comparison of how the behavior-based detection approach of HMDs can outperform
the static analysis-based detection techniques of production AV software [7,
8, 9, 6, 10, 11, 12, 13, 14, 15, 16, 18]. However, they do not present a
quantitative comparison of how the performance of their proposed HMDs compares
against the currently deployed production AV software.

##  IV Theory of XMD

We describe the hypothesis behind the design of XMD, followed by the theorem
that supports the hypothesis.

###  IV-A Intuition behind XMD

Zhou et al. questioned how low-level HPC telemetry, derived exclusively from a
SoC’s CPU, could effectively distinguish high-level behavior between benign
and malicious applications [12]. Botacin & Gr’egio further stipulated that HPC
telemetry might only encompass an attack space where malware exhibits
noticeable architectural side-channel effects [20]. We concur with this view,
noting that an over-dependence on CPU hardware telemetry might restrict the
HMD’s coverage to malware with pronounced architectural side effects. We
propose that accessing telemetry channels from different SoC sub-devices could
widen the attack space addressed by the HMD. Providing ML agents with
additional telemetry channels (e.g., low-level network telemetry) might
enhance the HMD’s detection performance, considering that malware often
communicates with its command-and-control server.

It is important to acknowledge two fundamental assumptions implicit in our
work, as well as all dynamic analysis-based approaches that rely on behavioral
signatures. Assumption 1: Different software executions affect telemetry
differently. This belief sets the groundwork for our methodology, as we
anticipate that benign and malicious applications will exhibit distinct
behaviors in telemetry data, allowing ML models to detect these variances.
Assumption 2: Malware and benign applications are inherently different in
their behavioral patterns and hence produce different signatures in telemetry
data. This leads us to our central hypothesis: An ML classifier could perform
better when utilizing a more diverse set of telemetry channels from various
SoC subsystems. This hypothesis guides the design and evaluation of XMD. In
the following section, we present the necessary background and definitions to
construct the theorem supporting our hypothesis.

###  IV-B Background and Definitions

Figure 2: 2-D visualization of Benign [green] vs. Malware [red] classification
using manifolds: (a) candidate hyperplanes that can separate the benign and
malware manifolds, (b) classification task with overlapping manifolds, (c)
solution space of the hyperplanes for case-a (easier classification problem)
and for case-b (difficult classification problem).

Manifold. Intuitively, a manifold is a topological space that is locally
Euclidean. A topological space is a set of points, with each point having its
own set of neighborhoods [35]. We have a set of features for each of the GLOBL
channels and the HPC groups. Using these feature sets, we can visualize an APK
sample as a representative point in a higher dimensional vector space. We
construct a manifold composed of a set of these representative points for each
of the benign and malware classes. Finally, we end up with a set of manifolds
for each of the benign and malware classes, for all the GLOBL channels and the
HPC groups. The representative points move around in their respective
manifolds introducing intra-class variabilities (e.g., stochasticity). We use
the notation $F^{\mu}$ with $\mu=B$ or $M$ for the benign and malware
manifolds, respectively, with each point on the manifold represented by
$\mathbf{x}^{\mu}\in F^{\mu}$.

A point on the manifold consists of the input space $\mathbf{x}^{\mu}\in
F^{\mu}$ given as
$\mathbf{x}^{\mu}(\vec{S})=\sum_{i=1}^{D+1}S_{i}\mathbf{u}_{i}^{\mu}$ where
$\mathbf{u}_{i}^{\mu}$ are a set of orthonormal bases of the $(D+1)$
dimensional linear subspace containing $F^{\mu}$, the $D+1$ components $S_{i}$
represent the coordinates of the manifold point within this subspace and are
constrained to be in the set $\vec{S}\in\mathcal{S}$. $\mathcal{S}$ denotes
the shape of the manifolds and encapsulates the affine constraint.

Separability and Hyperplanes.  The goal of the classification task is to learn
the position of the decision hyperplane between the two object manifolds. The
ability of a classifier to discriminate between two class manifolds can be
mapped to the separability of class manifolds by a linear hyperplane [36, 37].
We study the separability of the benign and malicious manifolds into separate
classes, denoted by binary labels $y^{\mu}=\pm 1$, by a linear hyperplane. As
shown in Figure 2.(a), a hyperplane is described by a weight vector
$\mathbf{w}\in\mathbb{R}^{N}$, and separates the manifolds with margin
$\kappa$ such that $y^{\mu}\mathbf{w}\cdot\mathbf{x}^{\mu}\geq\kappa$ for all
$\mu$ and $\mathbf{x}^{\mu}\in F^{\mu}$.

Solution Volume.  We use solution volume $\mathcal{V}$ as a metric to
characterize the separability of two manifolds [26]. A higher solution volume
results in better and more generalizable classification. An intuitive
representation of the solution volume is shown in Figure 2.(c). We can observe
a higher solution volume for case-a, where the benign and malware manifolds
have higher separability, than case-b, where the manifolds overlap, resulting
in lower separability and, therefore, a lower solution volume. Following
Gardner’s replica framework [26], the volume $\mathcal{V}$ of the solution
space is defined as

$\mathcal{V}=\int
d^{N}\mathbf{w}\delta\left(\|\mathbf{w}\|^{2}-N\right)\prod\limits_{\mu,\mathbf{x}^{\mu}\in
F^{\mu}}\Theta\left(y^{\mu}\mathbf{w}\cdot\mathbf{x}^{\mu}-\kappa\right)$ (1)

where $\Theta(\cdot)$ is the Heaviside function to enforce the margin
constraints in the linear separation constraint
$y^{\mu}\mathbf{w}\cdot\mathbf{x}^{\mu}\geq\kappa$, along with the delta
function to ensure $\|\mathbf{w}\|^{2}=N$.

Convex Hull and Polytopes: The convex hull of a set of points $\mathcal{S}$ is
the intersection of all half-spaces that contain $\mathcal{S}$. A half-space
is either of the two parts into which a hyperplane divides an affine space.
For example, in a two-dimensional Euclidean space, a half-space is either of
the two parts into which the space is divided by a line. A convex polytope is
an intersection of a finite number of half-spaces.

Mathematically, the convex hull is given as:
$\mathcal{CH}\left(F^{\mu}\right)=\left\\{\mathbf{x}^{\mu}(\vec{S})\mid\vec{S}\in\mathcal{CH}(\mathcal{S})\right\\}$,
where

$\mathcal{CH}(\mathcal{S})=\left\\{\sum_{i=1}^{D+1}\alpha_{i}\vec{S}_{i}\mid\vec{S}_{i}\in\mathcal{S},\alpha_{i}\geq
0,\sum_{i=1}^{D+1}\alpha_{i}=1\right\\}$ (2)

###  IV-C Theorem

Using the formal theory of linear separability of the object manifolds [37],
we perform an analytical study that supports our hypothesis presented in
Section IV-A. The theorem establishes that XMD’s superior performance stems
from a higher solution volume which arises from the fusion of information of
telemetry channels from different devices of an SoC, e.g., CPU, GPU, Network,
Memory, and Cache.

Theorem 1:  Let $\mathcal{V}_{i}$ be the solution volume corresponding to the
classification task of the benign and malware applications using the $i$-th
telemetry channel in the $N$-dimensional vector space, where the $i$-th basis
corresponds to the $i$-th telemetry channel $\forall i\in[1,N]$, and $N$ is
the total number of telemetry channels. We show that the solution volume
arising from the union of different $\mathcal{V}_{i}$s, i.e.
$\left(\bigcup_{i}\mathcal{V}_{i}\right)$, is greater than the individual
$\mathcal{V}_{i}$s considered independently.

To prove this, we assume an N-dimensional vector space, with one basis for
each of the N telemetry channels, and each $\mathcal{V}_{i}$ is an orthogonal
projection of the union of solution volumes
$\left(\bigcup_{i}\mathcal{V}_{i}\right)$ on the i-th basis. Next, we show
that the solution volume arising from $\bigcup_{i}\mathcal{V}_{i}$ is lower
bounded by the maximum solution volume $\mathcal{V}_{\max}$, where
$\mathcal{V}_{\max}$ is $\max\\{\mathcal{V}_{i}\ \ \forall i\in[1,N]\\}$ . A
higher solution volume results in better classification performance, hence,
supports our hypothesis.

###  IV-D Mathematical proof

Lemma 1:

$\displaystyle\mathcal{V}[\mathcal{CH}\left(\bigcup_{i}\mathcal{V}_{i}\right)]\geq\max\\{\mathcal{V}_{i}\\}$
(3)

Proof:  Let $\mathcal{V}_{i}$ be nonempty, convex sets. We show that
$x\in\mathcal{CH}(\bigcup_{i}\mathcal{V}_{i})$ if and only if there exist
elements $v_{i}\in\mathcal{V}_{i}$ and $\lambda_{i}\geq 0$ with
$\sum_{i}\lambda_{i}=1$ such that $x=\sum_{i}\lambda_{i}v_{i}.$ This can be
represented as

$\mathcal{CH}(\bigcup_{i}\mathcal{V}_{i})=\left\\{\sum_{i}\lambda_{i}v_{i}\mid\sum_{i}\lambda_{i}=1,\lambda_{i}\geq
0,v_{i}\in\mathcal{V}_{i}\right\\}$

Now, let us consider the solution volume $\mathcal{V}$ as a measure defined on
a vector space $\Omega$. Then we show that $\mathcal{V}(A)\leq\mathcal{V}(B)$
for all $A\subset B\in\Omega$. Let $A\subset B$, let $C=A^{c}\cap B$. Then
$A\cap C=\emptyset$ and $A\cup C=B$. Thus, $\mathcal{V}(A\cup
C)=\mathcal{V}(A)+\mathcal{V}(C)=\mathcal{V}(B)$. Therefore
$\mathcal{V}(A)\leq\mathcal{V}(B)$ for $\mathcal{V}(C)\geq 0$ by non-
negativity. Hence, the solution volume of a convex manifold $\mathbf{X}$,
given as $\mathcal{V}\\{\mathbf{X}\\}$, is a monotonic increasing measure.
Therefore,

$\displaystyle[\mathcal{V}\\{\mathcal{CH}\left(\bigcup_{i}\mathcal{V}_{i}\right)\\}]$
$\displaystyle=[\mathcal{V}\\{\mathcal{CH}\left(\mathcal{V}_{\max}\cup\mathcal{V}_{i}\backslash\mathcal{V}_{\max}\right)\\}]$
$\displaystyle\geq[\mathcal{V}_{\max}\cup\mathcal{V}_{i}\backslash\mathcal{V}_{\max}]$
$\displaystyle\geq[\mathcal{V}_{\max}]=\max\\{[\mathcal{V}_{i}]\quad\forall
i\\}$
$\displaystyle\Rightarrow\mathcal{V}[\mathcal{CH}\left(\bigcup_{i}\mathcal{V}_{i}\right)]$
$\displaystyle\geq\max\\{(\mathcal{V}_{i})\\}$ (4)

$\blacksquare$

Theorem 1:  Let $\mathcal{V}_{i}$ be the solution volume corresponding to the
telemetry channel-$i$ in the $N$-dimensional vector space where the $i$-th
basis corresponds to the $i$-th telemetry channel $\forall i\in[1,N]$, and $N$
is the total number of telemetry channels. Then,
$\mathcal{V}[\mathcal{CH}\left(\bigcup_{i}\mathcal{V}_{i}\right)]\geq\max\\{\mathcal{V}_{i}\\}\quad\forall
i\in[1,N]$ .

Short Proof: We consider a convex polytope for each of the solution volume
$\mathcal{V}_{i}$. Without loss of generality, we assume that each
$\mathcal{V}_{i}$ is an orthogonal projection of the union of the solution
volumes ($\bigcup_{i}\mathcal{V}_{i}$), which we refer to as the universal
convex polytope. The universal convex polytope is constructed by taking a
convex hull over the union of its $N$ orthogonal components $\mathcal{V}_{i}$.
From Lemma 1, we get
$\mathcal{V}[\mathcal{CH}\left(\bigcup_{i}\mathcal{V}_{i}\right)]\geq\max\\{\mathcal{V}_{i}\\}$.
$\blacksquare$

Figure 3: Creating the classifiers: (a) Feature engineering steps for GLOBL
channels, (b) feature engineering steps for the HPC groups, (c) Late stage
fusion for merging the decisions of the base detectors TABLE I: Malware
characterization using AVClass [38]

Class | #apks | Family | #apks | Family | #apks | Family | #apks
---|---|---|---|---|---|---|---
grayware | 457 | hiddad | 47 | piom | 5 | autoins | 2
adware | 159 | dnotua | 33 | blacklister | 4 | iconhider | 2
downloader | 40 | appsgeyser | 24 | marsdaemon | 4 | gamclk | 2
virus | 23 | joker | 21 | datacollector | 3 | apptrack | 1
tool | 19 | fakeapp | 15 | silentinstaller | 3 | wapron | 1
clicker | 6 | smsreg | 8 | umpay | 2 | baiduprotect | 1
rogueware | 1 | smspay | 6 | gapussin | 2 | contactscollector | 1

###  IV-E Approach for Experimental Validation

To validate the hypothesis and theorem presented in Section IV-A and IV-C
respectively, we design a robust data collection framework that collects the
two classes of telemetry (HPC and GLOBL) simultaneously and collectively
captures a workload’s impact on different sub-systems of the SoC like CPU,
GPU, memory, buses, and network (Section V). The framework incorporates
measures to reduce the datasets’ bias and prevent over-optimistic results. For
example, we devise a Logcat-based activation checker that filters out the runs
in which the application does not have sufficient runtime. For both the HPC
data logs and the GLOBL data logs, the data collection process produces multi-
variate time series data. The feature engineering choices are the same as the
ones used in prior works for DVFS [13, 32] and HPC [6, 12], and are summarized
in Figure 3.(a) and 3.(b). Using the fusion-based approach summarized in
Figure 3.(c), we demonstrate that incorporating the expansive telemetry
improves the classification performance of the fusion-based model used in XMD,
validating Theorem 1.

##  V Dataset Collection Framework

###  V-A Malware and Benign programs used

STD-DATASET: In this paper, we use a broad definition of malware, i.e., any
application that has been flagged as malicious by at least one AV on
VirusTotal [39]. The dataset consists of real-world Android benign and malware
applications. In particular, we acquired an initial dataset of 1033 samples of
malicious and 723 samples of benign Android applications. The samples were
downloaded from AndroZoo and were collected in the period from Dec 2019 to
June 2021 [40]. There are 54 malware families in the malware dataset, as
reported by the ESET-NOD32 AV engine from VirusTotal. The number of
applications and the total number of iterations is summarized in Table IV.

To gain a deeper understanding of the malware in our dataset, we employed the
AVClass tool [38] to analyze the Virustotal report generated for our malware
samples. The results of this analysis are presented in Table I. This table
classifies the malware samples into different categories, based on class and
family, and lists the number of samples that correspond to each specific class
or family. Notably, these tags are not exclusive, meaning a single sample
might be classified as both ‘grayware’ and ‘adware’. Majority of the samples
received the ‘grayware’ tag. Previous research by Chen et al. on
characterization of Android malware indicated that grayware could embody an
array of potentially harmful functionalities [41]. In our dataset, we have
observed such functionalities, as seen in categories like Redirected Promotion
Apps (hiddad), Data Collection Apps (dnotua, joker), Fake apps (fakeapp), and
Dialing/SMS-Managing Apps (smsreg, smspay) [41]. Many of these applications
may not cause detectable architectural side-channel effects, suggesting that
they could evade detection by HPC-telemetry based HMDs. Thus, our dataset
could pose a robust test for the expanded attack space covered by our proposed
method, underlining our argument that the inclusion of a wider array of
telemetry channels could improve malware detection capabilities.

###  V-B Bare-metal analysis environment

We built a host-client-based bare-metal sandbox environment to perform a
large-scale automated collection of hardware-level telemetry. The Client is a
Google Pixel 3 mobile device (running Android OS) on which the benign and
malicious samples are executed, and the host is a Linux OS-based PC that
orchestrates the data collection. During application execution, we simulate
human interaction using the Monkey tool [42] and Broadcast Events [43] to
trigger the malware payloads. We leveraged Android Debug Bridge (`adb`) [44]
for transferring data and sending commands between the host and the Client.
The Client is connected to the Internet, which is crucial for the malware to
perform essential functionalities like communicating with its command-and-
control (C2) server. Since we were using a bare-metal analysis environment, we
developed a custom checkpointing scheme to restore the Client’s OS to a clean
state between the application runs.

Environment assumptions. During data collection of the foreground application,
multiple system workloads (e.g., system_server, surfaceflinger,
servicemanager, mediaserver, etc.) were executing in the background. Some of
these workloads (e.g., system_server) were sending and receiving data packets
on the network. Since the experimental Android device has a multi-core CPU,
the processes belonging to the foreground application were context switching
in and out of the cores and migrating to different cores throughout data
collection. As indicated by prior research, this introduces measurement errors
and non-determinism [27]. While previous works have attempted to pin the
process to a core during data collection to reduce noise from measurement
errors [12, 6], we contend that this approach is not realistic. HMD is
intended to function as a real-time detector that continuously runs in the
background. Post-deployment, HMDs will profile processes subject to context
switching, resulting in inherently erroneous measurements. Therefore, during
data collection, we do not pin the target process to any particular core. We
acknowledge that this makes the problem more difficult (but realistic) and
necessitates the design of effective Machine Learning (ML) agents that can
generalize beyond the measurement errors introduced during the data-collection
process. Overall, we ensure that the data collection environment is similar to
the environments observed in a scenario where a Android user is interacting
with one foreground application with multiple system workloads running in the
background.

###  V-C Selection of Hardware Signals

TABLE II: List of collected HPC events

Group | HPC event | Reference
---|---|---
group-1 | cpu-cycles | [15]
instructions | [7, 9, 10, 11, 14, 18]
raw-bus-accesses | [6, 11]
group-2 | branch-instructions | [7, 9, 6, 10, 14, 15, 18]
branch-misses | [15, 8, 9, 14, 15, 18]
raw-mem-access | [16, 6, 11]
group-3 | cache-references | [14, 12, 18]
cache-misses | [14, 7, 8, 9, 18]
raw-crypto-spec | -
group-4 | bus-cycles | [8, 15]
raw-mem-access-rd | [6, 11]
raw-mem-access-wr | [6, 11]

TABLE III: List of collected GLOBL (DVFS & SYSFS) channels.

| Channel Number | Location | Description
---|---|---|---
D V F S | 1 | /sys/class/devfreq/5000000.qcom,kgsl-3d0/gpu_load | GPU controller
2 | /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq | CPU controller : lower cluster
3 | /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq | CPU controller : higher cluster
4 | /sys/class/devfreq/soc:qcom,cpubw/cur_freq | CPU bus bandwidth controller
5 | /sys/class/devfreq/soc:qcom,gpubw/cur_freq | GPU bus bandwidth controller
6 | /sys/class/devfreq/soc:qcom,kgsl-busmon/cur-freq | GPU bus bandwidth controller
7 | /sys/class/devfreq/soc:qcom,l3-cpu0/cur-freq | Latency controller L3 cache : lower cluster
8 | /sys/class/devfreq/soc:qcom,l3-cpu4/cur-freq | Latency controller L3 cache : higher cluster
9 | /sys/class/devfreq/soc:qcom,llccbw/cur-freq | Last level cache controller
10 | /sys/class/devfreq/soc:qcom,memlat-cpu0/cur-freq | Memory latency controller : lower cluster
11 | /sys/class/devfreq/soc:qcom,memlat-cpu4/cur-freq | Memory latency controller : higher cluster
SYS FS | 12 | /sys/class/net/tun0/statistics/rx_bytes | Network : received bytes
13 | /sys/class/net/tun0/statistics/tx_bytes | Network : transmitted bytes
14 | /sys/class/power_supply/battery/current_now | Device current
15 | /sys/class/power_supply/battery/voltage_now | Device voltage

Choice of HPC channels.  The HPC events are stated in Table II. We performed a
comprehensive literature survey to identify the performance counter events
used in prior work that resulted in the best detection performance. We
consider an additional HPC event, not used in prior work, called `raw-crypto-
spec`, which can potentially capture essential malware functionalities (SSL or
TLS handshake). The number of HPC available on the device limits the
collection of HPC events. On the Snapdragon chipset, there are four available
HPCs. However, one HPC is repurposed for monitoring memory latency, so we can
collect at most three events simultaneously. Therefore, all the HPC events are
divided into groups 1-4. Each HPC group has three events that are collected
simultaneously in a single iteration.

Choice of DVFS channels. Prior works have primarily focused on the impact of
running a workload on the CPU by monitoring the DVFS states of the CPU
controller [32, 13]; we expand on this notion by considering an expansive set
of DVFS channels that cover both the CPU and the non-CPU devices like GPU,
memory, buses, and caches. Channel-1 to Channel-11 in Table III elaborates on
the selected DVFS channels, their corresponding locations in the Linux device
tree, and the device’s signature they capture.

Choice of SYSFS channels.  To capture the low-level impact of benign or
malicious workload on Network devices, we recorded the number of bytes
transmitted and received by the device. These channels are Channel-12 and
Channel-13 in Table III. Prior works have demonstrated the efficacy of power
side channels to detect malicious workloads on x86, IoT, and embedded systems
[45, 46, 47, 48]. We collected telemetry from the `voltage_now` (Channel-14)
and `current_now` (Channel-15) sysfs nodes. While the channels and events
described earlier capture the impact of workload on a specific subsystem of
the SoC, the power channels present a global telemetry channel capturing the
impact on the entire SoC.

Overall, the combined information from the HPC, DVFS, and SYSFS channels
present a comprehensive low-level behavior over all the sub-modules of an SoC,
like the CPU, caches, GPU, memory, buses, and network.

Figure 4: Runtime for different iterations of malware and benign applications (using Logcat) TABLE IV: Details of the dataset Application | # apk |  # apk executed once (% activation) |  # apk post logcat filter (% activation) | # Files
---|---|---|---|---
GLOBL | HPC
group-1 | group-2 | group-3 | group-4
Benign | 723 | 681 (94%) | 448 (62%) | 2120 | 408 | 602 | 582 | 582
Malware | 1033 | 776 (75%) | 555 (54%) | 2143 | 577 | 637 | 578 | 499

###  V-D Methodology

Method for Running Experiments. We perform eight independent iterations of
data collection for each Android application, where a different sequence of
interactions was used for each iteration. For each iteration of data
collection, we collected all the GLOBL channels, and one group of HPC events
since the number of HPC registers limits us. Overall, each Android application
has eight iterations of data logs for the GLOBL channels and two iterations of
data logs for each HPC group. We restrict data collection for each iteration
to 40 seconds for each iteration, a decision informed by space and time
considerations.

Rationale behind 40-second execution time for ML model training and
evaluation. Recent research by Kuchler et al. has investigated the impact of
execution time on the quality of behavioral telemetry (system calls) and
subsequent classification performance of ML model [49]. Their findings
highlight that extending the data collection window from one to two minutes
marginally influences the performance of the ML classifier, with ROC-AUC
scores of 0.968 and 0.967, respectively. Therefore, the most valuable
behavioral telemetry from malware samples is collected within the first
minute; thus, extending the execution window does not necessarily yield more
meaningful features for training the ML model. Given these findings, our
methodology has been designed to collect data for 40 seconds per iteration.
Repeated across eight independent iterations for each application, this
accumulates 320 seconds of GLOBL telemetry and 80 seconds of HPC telemetry per
HPC group. This aligns our method with Kuchler et al.’s insights and ensures
ample informative behavioral telemetry is available for training the ML model.
For evaluation, we recognize that the change in the predictive performance of
the ML model due to non-core telemetry augmentation could vary across
execution time frames. To examine this, we perform sensitivity analysis using
time frame increments from 5 to 40 seconds, detailed in Section VI-D. Overall,
the chosen 40-second time frame facilitates effective training and evaluation
of the ML model, focusing on testing the central hypotheses of our study.
However, we acknowledge that our study does not include a comprehensive long-
term evaluation of 90-120s, which is a direction for future exploration
(Section VIII).

Dataset split. We divide the dataset into three splits: train (70%), trainSG
(15%), and test (15%). We train the base-classifiers for GLOBL-channels and
HPC-groups using the train split. We train the Stacked Generalization models
for the late-stage decision-fusion from base-classifiers using the trainSG
split. The final scores are reported using the test split.

Monitoring execution using Logcat : In Android OS, logs from applications are
collected in a series of circular buffers, which can be filtered and viewed
using Logcat [50]. The logs contain the timestamp of the activity, the PID,
and the description of the activity. We designed a Logcat-based activation
checker to ensure that the malware is executing in the foreground while the
hardware-telemetry logs are collected in the background. For every iteration
of data collection, we collected its corresponding logcat and used it to
calculate the execution time of the foreground application.

Figure 4 shows the distribution of the runtimes of different iterations of the
benign and malware applications, calculated using the Logcat logs. We perform
a grid search to identify the logcat-based filter’s threshold that maximizes
the classifier’s predictive performance. Therefore, for this work, the logcat-
based filter rejected all the iterations in which the foreground application
executed for less than 15 seconds. Table IV summarizes the number of files
post-filtering for the GLOBL channels and each HPC group. E.g., we observe
that 75% of malware executed in at least one of the eight iterations, and 54%
of malware cleared the logcat filter. On the other hand, benign applications
have a higher activation rate, with 95% of applications executing at least
once and 62% of applications clearing the logcat filter.

##  VI Analysis

Figure 5: F1-score for HPC-groups and GLOBL channels

In this section, we perform empirical analysis aimed at validating the
theorem. Using std-dataset, we first demonstrate that the solution volumes of
the different telemetry channels are distinct. Finally, we demonstrate that
fusing the solution volumes of the different channels results in increased
separability of the benign and malware class and improves the predictive
performance of the classifier.

###  VI-A Characterizing telemetry channels.

Prior works on HMD have reported their best results using Random Forest (RF)
classifiers; hence we only consider the RF classifiers for creating base-
classifiers for each of the GLOBL channels and the HPC groups. Figure 5
presents the classification performance of the different HPC-based classifiers
and the GLOBL-based classifiers on the std-dataset. We provide a brief
discussion highlighting the key results and takeaways.

The F1-scores for the HPC groups and CPU-telemetry channels (GLOBL channel-2
and 3) are lower than what has been reported in prior works that have used
benchmark applications labeled as benign [7, 8, 9, 6, 10, 13, 15]. Using real-
world benign applications results in a more realistic scenario than using
benchmark applications, making the classification task difficult. The HPC-
groups do not have the performance advantage over the GLOBL channels,
signifying that CPU-telemetry is insufficient to separate malicious
applications from real-world benign applications, despite the accurate
profiling power resulting from the thread-level profiling.

The GLOBL channels-12 and 13 that capture the number of transmitted and
received bytes offer significantly higher F1-score compared to the other
channels and HPC groups, demonstrating the role of communication with the C2
server in differentiating a malicious from a benign workload. Despite the
higher F1-score, relying solely on low-level telemetry from one subsystem
(e.g., network) creates a single mode of failure that can be easy to bypass
[27].

There is a wide variation in the F1-scores (0.63-0.89) of ML models using the
same learning algorithm for the different telemetry channels. This indicates
that the solution volume $\mathcal{V}$ of different telemetry channels are
distinct, potentially arising due to the different sources of information
captured by the telemetry channels.

The solution volume $\mathcal{V}$ of different telemetry channels are
distinct.

###  VI-B Validating Theorem-1: Is fusion-based model the right approach?

In the previous section, we observed that each telemetry class has strengths
and weaknesses. HPCs can offer thread-level profiling but can only profile the
CPU. GLOBL channels capture a global impact of running a workload on the SoC
but cannot identify the malicious threads. This motivates us to develop a
fusion-based approach called XMD that complements the thread-level profiling
provided by the HPCs with the global profiling provided by the GLOBL channels.

Theorem-1 in Section IV guides the design of a fusion-based model where using
multiple telemetry channels results in better solution volume than considering
a single telemetry source, e.g., the CPU-telemetry-based classifiers. We study
the impact of incorporating more telemetry channels on the distinguishability
of the benign and malware applications using Dissimilarity Scores (DS) derived
from the Welch t-test. Welch’s t-test is a statistical measure to quantify the
similarity between two populations (e.g., benign and malware) using their
average statistics. It is a type of hypothesis testing where the null
hypothesis is accepted or rejected based on the calculated t-statistic and its
corresponding p-value. The null hypothesis for this study is: “hardware
telemetry signatures of malware and benign applications have similar means.”
The t-statistics are calculated using Equation 5.

$t\text{-}statistic=\frac{\mu_{1}-\mu_{2}}{\sqrt{\frac{{s_{1}}^{2}}{N_{1}}+\frac{{s_{2}}^{2}}{N_{2}}}}$
(5)

where $\mu_{1}$ and $\mu_{2}$ are the mean of the sample under observation,
$s_{1}$ and $s_{2}$ are the variance with $N_{1}$ and $N_{2}$ being the total
number of samples. When the calculated $t-statistic>|4.5|$, we can reject the
null-hypothesis with p-value of $1$x$10^{-5}$ and confidence score of 99.999%
[51].

We perform pairwise t-test analysis on post-processed features. We use the
t-statistics to estimate a dissimilarity score (DS) given by Equation 6.

$DS=\frac{card({\\{f_{i}\ :\
t\text{-}statistic_{f_{i}}\;>\;|4.5|\\}})}{|\mathbf{F}|}$ (6)

where $card(.)$ denotes the cardinality of the set, $f_{i}$ is the $i_{th}$
component of the feature vector $\mathbf{F}$, and $|.|$ is dimension of the
corresponding vector space. Intuitively, DS calculates the fraction of
features in the feature vector where the null hypothesis is rejected, i.e.,
the telemetry of the malware and benign applications are distinguishable. A
higher DS implies more distinguishability between malware and benign samples.

Figure 6: DS score vs. Number of channels indicating increased
distinguishability between malware and benign classes as more channels are
added.

For each pair of benign and malware applications, we incorporate more
telemetry channels into the feature vector. This is followed by Principal
Component Analysis to reduce the augmented feature size to the feature size of
a single channel, eliminating the bias arising from increased feature size. We
then calculate the DS. As shown in Figure 6, we see an increasing trend in the
DS upon increasing the number of telemetry channels, indicating the increased
distinguishability of malware and benign samples. This potentially indicates
that the solution volume arising from $\bigcup_{i}\mathcal{V}_{i}$ is higher
than the solution volumes of the telemetry channels $\mathcal{V}_{i}$ when
considered independently. Next, we explore late-stage fusion-based detection
to realize the potential performance improvements of incorporating multiple
channels.

###  VI-C Approach: Late-stage fusion

TABLE V: F1-score of the fused GLOBL channels

| Fused channel
---
group
| Participating
---
Channels
| STD
---
Dataset
DVFS | 1-11 | 0.90
GLOBL | 1-15 | 0.92

TABLE VI: F1-scores of different HPC-groups before and after fusion with the
DVFS and GLOBL channels

HPC | Standalone |  | With DVFS
---
(ensemble)
| With DVFS
---
(SG)
| With GLOBL
---
(ensemble)
| With GLOBL
---
(SG)
group-1 | 0.66 | 0.89 | 0.88 | 0.93 | 0.90
group-2 | 0.71 | 0.89 | 0.84 | 0.89 | 0.92
group-3 | 0.76 | 0.90 | 0.91 | 0.93 | 0.93
group-4 | 0.67 | 0.91 | 0.90 | 0.92 | 0.93

As shown in Figure 3.(c), we consider two decision fusion approaches. In the
first approach, called ensemble, we take a majority vote of decisions of the
individual base-classifiers, each of them trained on a different telemetry
channel. The second approach is a stacked generalization approach where we
fuse the decisions of the base-classifiers using a second-stage model, which
is a logistic regression model in our case.

Fusing the decisions of the GLOBL channels.  Table V shows the F1-scores from
fusion of different base-classifiers of the GLOBL and DVFS channels. We
observe the following trends from these results: First, the F1-score obtained
after fusing the GLOBL channels has a better F1-score than the sub-group of
DVFS. Therefore, considering the impact of running a workload on all the sub-
devices of the SoC is essential. Second, F1-score from fusion is greater than
the F1-scores from each of the individual channels, which agrees with the
statistical analysis in Section VI-B and validates Theorem-1, showing fusion
of distinct solution volumes of the individual telemetry channels results in a
higher solution volume.

The performance of the fused model incorporating all the GLOBL telemetry
channels is greater than the performance of each channel independently,
validating Theorem-1.

Figure 7: ROC curve for XMD

XMD: Fusing the decisions of the GLOBL channels and HPC.  Table VI shows the
F1-score of the HPC groups when they were standalone and when used in
conjunction with the DVFS and the GLOBL channels for both the techniques of
late-stage fusion, i.e., ensemble and stacked generalization (SG). The
predictive performance of the GLOBL channels, when fused with the HPCs, is
higher than the fused GLOBL models (in Table V) or the HPC base-classifiers.
The receiver operating characteristic (ROC) curve (on the std-dataset) for the
Ensemble-fusion models is presented in Figure 7.

The HPC-GLOBL fused model exploits the thread-level profiling power of the
HPCs and the globl profiling power of GLOBL channels, resulting in a malware
detector with better predictive performance.

Figure 8: F1-score vs. Truncated Duration for three different HMDs: HPC, HPC-
DVFS, and HPC-GLOBL.

###  VI-D Impact of execution runtime

Next, we rigorously evaluate the central hypothesis of our paper by testing
the impact of execution window length on the improvement in performance
achieved from augmenting with the non-core telemetry. From our 40-second data-
collection window, we truncated the collected data by capturing the first N
seconds of hardware telemetry (referred to as ’truncated duration’ from here
on). We increased N in intervals of 5 seconds, and plotted the observed
F1-score for three different HMDs: HPC-only, HPC-DVFS ensemble, and HPC-GLOBL
ensemble, for each truncated duration in Figure 8. The vertical spread in each
bar plot accounts for consideration of all HPC-groups, with each spread
corresponding to four groups. The percentage values atop the bar plots show
the percentage increase in mean F1-score for HPC-DVFS and HPC-GLOBL HMDs over
the HPC-only HMDs.

From this plot, two key observations can be made: (1) The HPC-DVFS and HPC-
GLOBL consistently outperform the HPC-only HMDs, irrespective of the truncated
duration value. This suggests that access to non-core telemetry reliably
enhances the classifier’s predictive performance. (2) As truncated duration
increases, the percentage improvement over the HPC-only HMDs also increases.
This is due to the decreasing F1-score of the HPC-only detector, countered by
a slight increase for the fusion detectors, ultimately leading to a larger
percentage increase. This echoes recent findings that more data does not
necessarily equate to better benign vs. malware classification [49], a pattern
we also see for the HPC-telemetry. In conclusion, the consistent percentage
improvement across all truncated duration values lends strong support to our
hypothesis, indicating that augmenting with non-core telemetry channels does
indeed expand the attack space covered by the HMD and improve the predictive
performance of the ML Classifier. Moreover, it improves the ML classifier’s
predictive performance across various durations of collected data.

TABLE VII: Comparison of XMD against the prior works in HMD and Android-based
Malware Detection

Reference | Platform | Information | Performance
---|---|---|---
[11] | Android | Behavior (HPC) | 0.85 TPR, 0.05 FPR
[6] | Android | Behavior (HPC) | AUC 0.82, 0.10 FPR
[12] | x86 | Behavior (HPC) | 0.802 F1-score
[13] | Android | Behavior (CPU-DVFS) | 0.88 F1-score
[52] | Android | Static (mainfest, disassembled code) | 0.94 TPR, 0.01 FPR
[53] | Android | Static (API call graph) | 0.99 F1-score
[54] | Android | Static (package, API information) | 0.99 TPR, 0.022 FPR
[55] | Android | Behavior (sys-call, critical API, user activity) | 96.9% accuracy
Proposed | Android | Behavior (HPC, core+non-core DVFS, SYSFS) |  | HPC: 0.66-0.76 F1-score
---
XMD: 0.90-0.93 F1-score

TABLE VIII: Detection rates of XMD and signature-based Antivirus Scanners on
VirusTotal (%N.P. = Percentage of test samples on which AV scanner did not
make a prediction, %TPR = True Positive Rate, %FPR = False Positive Rate)

ensemble | XMD | AV1 | AV2 | AV3 | AV4 | AV5 | AV6 | AV7 | AV8 | AV9 | AV10
---|---|---|---|---|---|---|---|---|---|---|---
TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P. | TPR | %N.P.
group-1 | 84.13 (FPR = 3.70) | 83.87 | 0 | 82.76 | 6.4 | 66.12 | 0 | 59.64 | 8.1 | 53.44 | 6.4 | 53.22 | 0 | 35.48 | 0 | 32.25 | 0 | 30.50 | 4.8 | 27.42 | 0
group-2 | 87.83 (FPR = 6.89) | 80.22 | 3.2 | 81.93 | 11.7 | 53.76 | 1.1 | 60.60 | 11.7 | 57.47 | 7.5 | 52.17 | 2.1 | 35.10 | 0 | 38.46 | 3.2 | 23.19 | 10.6 | 23.65 | 1.1
group-3 | 86.54 (FPR = 2.90) | 80.00 | 0 | 79.74 | 7.1 | 68.23 | 0 | 48.05 | 9.4 | 65.00 | 5.9 | 42.86 | 1.2 | 43.53 | 0 | 40.00 | 0 | 30.48 | 3.5 | 34.11 | 0
group-4 | 85.71 (FPR = 5.23) | 83.56 | 0 | 76.81 | 5.5 | 69.86 | 0 | 54.54 | 9.6 | 48.48 | 9.6 | 64.28 | 4.1 | 41.09 | 0 | 34.78 | 1.4 | 23.88 | 8.2 | 29.17 | 1.4

Evaluating Time-to-Detection. Detecting malware involves several stages:
profiling the foreground application, performing feature engineering on the
collected data, and inference using the ML classifier (malware or benign).
Decisions regarding profiling duration depend on the specific use-case. As
illustrated in Figure 8, the HPC-GLOBL classifier’s F1 score incrementally
improves with increased execution time. Hence, the trade-off between early
detection and reliable detection needs careful consideration. The next stage
is feature engineering, which took 0.28s for a 40-second HPC time series and
1.12s for a GLOBL multivariate time series in our tests. The longer time for
GLOBL telemetry can be attributed to the computation of the spectrogram as one
of its feature engineering step. Finally, we evaluated the ML models’
inference time. The random forest model used in this study exhibited a mean
inference time of 0.64s over 100 iterations. The processing and inference
stages thus require less time than the profiling stage. The overall time to
detect malware depends on the profiling time chosen, striking a balance
between detection performance and speed. This decision ultimately depends on
the use-case. Furthermore, feature engineering and ML inference times can be
reduced through GPU offloading, as seen in commercial HMDs [4], or by using
hardware accelerators, as prior works suggest [8, 10, 56].

##  VII Comparison with Prior Works

In this section, we compare XMD against prior works in HMD [11, 6, 12, 13],
software-based Android Malware Detectors [52, 53, 54, 55], and static-analysis
based Antivirus (AV) engines available on VirusTotal. These comparisons help
us appreciate the efficacy of XMD in the context of existing solutions, while
also guiding us in understanding its place in a system of collaborative
detectors.

Comparison with prior HMD. We initially compare XMD with selected works in the
HMD domain as shown in the first four rows of Table VII. Notably, these works
utilize HPC-telemetry as the behavioral signature, adopting a dynamic
analysis-based approach [11, 6, 12]. One also exploits CPU-DVFS as the
hardware telemetry candidate [13]. XMD outperforms these, though it’s crucial
to mention that the predictive performance of HPC-only and CPU-DVFS-only
classifiers on our dataset (last row of Table VII) is less than what these
papers report. This discrepancy could be due to the use of benchmark
applications as benigns, which may introduce bias and artificially inflate the
F1-score. Additionally, our selection of malware apps influences the F1-score,
as the selection process is not standardized.

Comparison with prior software-based Android Malware Detectors. Next, we
compare XMD with specialized Android malware detectors that leverage unique
information in the Android ecosystem, such as the manifest file, disassembled
code, and call graphs [52, 53, 54] (next four rows in Table VII). We also
report a dynamic analysis-based approach that extracts behavioral information
like sys-call, critical API, and user activity [55]. All the specialized
approaches exhibit high detection performance, surpassing hardware-telemetry
based approaches, including XMD. Each of these detectors, while effective, can
be bypassed using specific techniques; e.g., obfuscation can bypass static
analysis-based approaches. As such, a blend of detectors working on different
information modalities may provide the highest security guarantees, much like
the ones used in current EDR frameworks [2].

Comparison with Signature-based AVs on VirusTotal. Finally, we compared XMD
against the software-based AV vendors on VT that use signature-based
approaches for malware detection. These included ESET-NOD32, Ikarus, K7GW,
Microsoft, CAT-Quickheal, Fortinet, Avira, Cyren, Kaspersky, and Lionic
(labelled as AV 1-10 in Table VIII). Since VT’s AV engines are signature-
based, they only classify malware samples they’ve previously encountered. The
AV engine does not make a prediction on the samples it has not been trained on
(called zero-day malware). We only considered vendors that provided decisions
for at least 85% of the samples in our test dataset. As shown in Table VIII,
while the best detection performance among the AVs on the test data for
group-3 is around 80%, XMD achieves a detection rate of 86.54% with a false
positive rate of 2.9%. The table also includes a %N.P. value for each AV,
indicating the percentage of test samples (zero-day) the AV did not make a
prediction for.

Limitations of comparison against prior works. A direct comparison with any
prior dynamic analysis-based approach is challenging due to the costly
execution of samples on the bare-metal framework, non-disclosure of malware
and benign samples’ hashes in prior works, and the incompatibility of older,
released samples with the newer OS in our framework. Therefore, we cannot
provide a direct comparison and just report the numbers that were reported in
the respective works.

XMD outperforms previous CPU-telemetry-based HMDs and signature-base AVs on
VirusTotal; it trails specialized Android-based detectors.

##  VIII Discussion, Limitations, and Future Work

Non-determinism in Hardware Telemetry.  Recent works have identified failure
scenarios in HMDs due to the non-determinism in the HPC-based telemetry
arising from interrupt-skid and overcounting of instructions [27, 12]. These
proof-of-concept attacks are aimed at skewing the CPU telemetry measurements.
Since XMD relies on a diverset set of core and un-core telemetry channels, it
is potentially robust to such proof-of-concept attacks that tamper with the
CPU telemetry measurements. Future works will explore the XMD’s resilience
against collusion-based attacks that tamper with the hardware telemetry.

Non-Core Telemetry Limitations and Extension to Desktop Devices. The
utilization of system-wide telemetry channels to monitor non-core devices
poses a risk, as it leaves the defense susceptible to user-land bad actors.
These actors can craft collusion-based attacks, injecting noise into the
telemetry channels. A potential remedy is the adoption of non-core performance
counters that offer process-level tracking of non-core devices. These
counters, currently employed by hardware vendor profiling frameworks, monitor
diverse activities such as traffic to storage and network devices, memory
access patterns like DRAM and cache load stalls, GPU and CPU usage in profiled
applications [57]. Repurposing these tools’ drivers can enhance deployed HMDs’
detection performance [4]. While the HPC-events for CPUs are generally
standardized across platforms, the availability of uncore-counters is
inconsistent, absent on client-side PCs but present on select server-class
platforms. Hence, there’s a call for an industry-wide initiative to integrate
uncore telemetry into existing HMD frameworks. As our study concentrates on
mobile devices, extending our approach to desktop devices requires a
comparable process-level tracking solution for non-core telemetry. This is due
to the potential masking of individual process behaviors by concurrent
foreground applications in desktop environments when using system-level
profiling. Thus, the extension of XMD to desktop devices is reserved for
future development and exploration.

Data-Collection Environment Limitations. Despite our efforts to make our data-
collection environment realistic for mobile devices, there are corner cases
that we haven’t addressed. We employ the Monkey tool for Android application
interactions, which uses stateless interactions, differing from real user
inputs. An improved approach for simulating user interface interactions is to
use a state-based model like Droidbot [58]. However, in our setup, Droidbot
exhibited unpredictable crashes, necessitating human intervention. Future work
could explore better methods for simulating human interactions for extensive
telemetry collection. Our study’s analysis is confined to a single Google
Pixel 3 mobile device, limiting the scope regarding SoC chipsets and mobile
devices. Nevertheless, the theorems and empirical observations in our work are
not dependent on a specific architecture or platform and could potentially
extend to other mobile devices. We plan to empirically verify our proposed
theorems on different mobile device platforms in future work. While we have
outlined our environment collection assumptions—involving a user interacting
with one foreground application while multiple system-level workloads run in
the background (in Section V-B)—a more rigorous set of environment assumptions
can be tested to robustly evaluate our proposed hypothesis. These could
include distinct user profiles, scenarios with multiple apps, background apps,
or extended execution time. In the scope of this study, a comprehensive long-
term evaluation was not conducted, a limitation we acknowledge. The
exploration of these aspects, including the potential impact of a long-term
evaluation on the system’s performance, is reserved for future investigations.

Dataset Size: A Comparison with Software-based Approaches. We must highlight
the relatively small size of our dataset, especially when compared to static
analysis-based datasets like MAMADroid [53] and DREBIN [52]. Static analysis
techniques offer notable scalability as they do not require malware execution.
Nevertheless, their susceptibility to evasion via simple obfuscation is a
significant disadvantage. In comparison with other software-based, dynamic-
analysis methods, our dataset remains modest in size [55]. Techniques like
syscall-based malware detectors, used in behavioral analysis, employ
virtualized sandboxes to improve scalability in data collection. However, HMDs
require data collection on bare-metal devices, since virtual machines
potentially introduce errors [12], and there are limited HPC events that can
be accessed from within a virtual machine. As a result, scalabiltiy of data-
collection is a major limitation in the design of any HMD. Thus, our dataset
size aligns with those considered in previous HMD studies [12, 11, 6].

Choice of fusing information from multiple telemetry channels. We have used a
late-stage fusion approach to incorporate the power of multiple telemetry
channels. However, an intermediate fusion-based approach can potentially
result in better detection performance at the cost of increased complexity,
e.g., an approach that exploits the interaction between the different
telemetry channels. We leave the exploration of such novel ML agents as future
work.

Future Work. Future work will extend across several dimensions. We aim to
probe XMD’s resilience against more complex, collusion-based attacks that
interfere with hardware telemetry. Furthermore, the development and
exploration of XMD for desktop devices will be undertaken, requiring the
devising of a process-level tracking solution for non-core telemetry. We also
plan to improve our data collection environment, by seeking better methods to
simulate human interactions and by testing our hypotheses across various
mobile device platforms and under a more comprehensive set of environment
assumptions. Lastly, we plan to investigate the potential of novel machine
learning agents capable of exploiting interactions between different telemetry
channels for more efficient malware detection.

##  IX Conclusion

In this paper, we propose XMD, a hardware-based malware detector that uses the
expansive set of hardware telemetries from the different sub-systems of an SoC
used in a mobile device. We develop a theorem that leverages the Replica
Theory of object manifolds to establish the performance gains expected from
incorporating the expansive set of telemetry channels. We evaluate XMD using a
dataset containing the expansive hardware telemetry of malware and benign
applications collected from a commodity smartphone. Our findings suggest that
XMD outperforms the current CPU-telemetry-based malware detectors (HPC-based
and CPU-DVFS-based). We also show that XMD provides better detection
performance than the commercial AV software on VirusTotal with acceptable
false-positive rates; however XMD trails in performance when compared to
specialized Android malware detectors. Since XMD relies on a different
modality of information when compared to software-based detectors, XMD can
complement other software-based detection approaches in a collaborative
defense system.

## References

  * [1] “Threat Intelligence Reports,” https://www.fireeye.com/current-threats/threat-intelligence-reports.html.
  * [2] “Microsoft Defender for Endpoint,” https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide.
  * [3] R. Vinayakumar, M. Alazab, K. P. Soman, P. Poornachandran, and S. Venkatraman, “Robust intelligent malware detection using deep learning,” _IEEE Access_ , vol. 7, pp. 46 717–46 738, 2019.
  * [4] “Detect Ransomware and other Advanced Threats with Intel Threat Detection Technology,” https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/threat-detection-technology-solution-brief.pdf.
  * [5] G. Karantzas and C. Patsakis, “An empirical assessment of Endpoint Detection and Response Systems against Advanced Persistent Threats Attack Vectors,” _Journal of Cybersecurity and Privacy_ , 2021. [Online]. Available: https://doi.org/10.3390%2Fjcp1030021
  * [6] J. Demme, M. Maycock, J. Schmitz, A. Tang, A. Waksman, S. Sethumadhavan, and S. Stolfo, “On the feasibility of online malware detection with performance counters,” in _Proceedings of the 40th Annual International Symposium on Computer Architecture_ , ser. ISCA ’13. New York, NY, USA: Association for Computing Machinery, 2013, p. 559–570. [Online]. Available: https://doi.org/10.1145/2485922.2485970
  * [7] A. P. Kuruvila, S. Kundu, and K. Basu, “Analyzing the efficiency of machine learning classifiers in hardware-based malware detectors,” in _2020 IEEE Computer Society Annual Symposium on VLSI (ISVLSI)_ , 2020, pp. 452–457.
  * [8] S. Tannirkulam Chandrasekaran, A. P. Kuruvila, K. Basu, and A. Sanyal, “Real-time hardware-based malware and micro-architectural attack detection utilizing cmos reservoir computing,” _IEEE Transactions on Circuits and Systems II: Express Briefs_ , vol. 69, no. 2, pp. 349–353, 2022.
  * [9] S. P. Kadiyala, P. Jadhav, S.-K. Lam, and T. Srikanthan, “Hardware performance counter-based fine-grained malware detection,” _ACM Trans. Embed. Comput. Syst._ , 2020. [Online]. Available: https://doi.org/10.1145/3403943
  * [10] N. Patel, A. Sasan, and H. Homayoun, “Analyzing hardware based malware detectors,” in _2017 54th ACM/EDAC/IEEE Design Automation Conference (DAC)_ , 2017, pp. 1–6.
  * [11] M. Kazdagli, V. J. Reddi, and M. Tiwari, “Quantifying and improving the efficiency of hardware-based mobile malware detectors,” in _2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)_ , 2016, pp. 1–13.
  * [12] B. Zhou, A. Gupta, R. Jahanshahi, M. Egele, and A. Joshi, “Hardware performance counters can detect malware: Myth or fact?” in _Proceedings of the 2018 on Asia Conference on Computer and Communications Security_. Association for Computing Machinery. [Online]. Available: https://doi.org/10.1145/3196494.3196515
  * [13] N. Chawla, A. Singh, H. Kumar, M. Kar, and S. Mukhopadhyay, “Securing IoT devices using dynamic power management: Machine learning approach,” _IEEE Internet of Things Journal_ , vol. 8, no. 22, pp. 16 379–16 394, 2021.
  * [14] P. Cronin and C. Yang, “Lowering the barrier to online malware detection through low frequency sampling of HPCs,” in _2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST)_ , 2018, pp. 177–180.
  * [15] A. P. Kuruvila, X. Meng, S. Kundu, G. Pandey, and K. Basu, “Explainable machine learning for intrusion detection via hardware performance counters,” _IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems_ , 2022.
  * [16] K. N. Khasawneh, M. Ozsoy, C. Donovick, N. Abu-Ghazaleh, and D. Ponomarev, “EnsembleHMD: Accurate hardware malware detectors with specialized ensemble classifiers,” _IEEE Transactions on Dependable and Secure Computing_ , vol. 17, no. 3, pp. 620–633, 2020.
  * [17] H. Kumar, N. Chawla, and S. Mukhopadhyay, “Towards improving the trustworthiness of hardware based malware detector using online uncertainty estimation,” in _2021 58th ACM/IEEE Design Automation Conference (DAC)_ , 2021, pp. 961–966.
  * [18] M. Alam, S. Bhattacharya, S. Dutta, S. Sinha, D. Mukhopadhyay, and A. Chattopadhyay, “Ratafia: Ransomware analysis using time and frequency informed autoencoders,” in _2019 IEEE International Symposium on Hardware Oriented Security and Trust (HOST)_ , 2019, pp. 218–227.
  * [19] “Qualcomm Mobile Security,” https://www.qualcomm.com/products/features/mobile-security/snapdragon-malware-protection.
  * [20] M. Botacin and A. Grégio, “Why we need a theory of maliciousness: Hardware performance counters in security,” in _Information Security: 25th International Conference, ISC 2022, Bali, Indonesia, December 18–22, 2022, Proceedings_. Berlin, Heidelberg: Springer-Verlag, 2022, p. 381–389. [Online]. Available: https://doi.org/10.1007/978-3-031-22390-7_22
  * [21] U. Cohen, S. Chung, D. D. Lee, and H. Sompolinsky, “Separability and geometry of object manifolds in deep neural networks,” _Nature communications_ , vol. 11, no. 1, pp. 1–13, 2020.
  * [22] C. Stephenson, J. Feather, S. Padhy, O. Elibol, H. Tang, J. McDermott, and S. Chung, “Untangling in invariant speech recognition,” _Advances in neural information processing systems_ , vol. 32, 2019.
  * [23] J. Mamou, H. Le, M. Del Rio, C. Stephenson, H. Tang, Y. Kim, and S. Chung, “Emergence of separable manifolds in deep language representations,” _arXiv preprint arXiv:2006.01095_ , 2020.
  * [24] M. Alleman, J. Mamou, M. A. Del Rio, H. Tang, Y. Kim, and S. Chung, “Syntactic perturbations reveal representational correlates of hierarchical phrase structure in pretrained language models,” _arXiv preprint arXiv:2104.07578_ , 2021.
  * [25] C. Stephenson, S. Padhy, A. Ganesh, Y. Hui, H. Tang, and S. Chung, “On the geometry of generalization and memorization in deep neural networks,” _arXiv preprint arXiv:2105.14602_.
  * [26] E. Gardner, “The space of interactions in neural network models,” _Journal of physics A: Mathematical and general_ , vol. 21, no. 1, p. 257, 1988.
  * [27] S. Das, J. Werner, M. Antonakakis, M. Polychronakis, and F. Monrose, “Sok: The challenges, pitfalls, and perils of using hardware performance counters for security,” in _2019 IEEE Symposium on Security and Privacy (SP)_ , 2019, pp. 20–38.
  * [28] M. Botacin, L. Galante, F. Ceschin, P. C. Santos, L. Carro, P. de Geus, A. Grégio, and M. A. Z. Alves, “The av says: Your hardware definitions were updated!” in _2019 14th International Symposium on Reconfigurable Communication-centric Systems-on-Chip (ReCoSoC)_ , 2019, pp. 27–34.
  * [29] A. Tang, S. Sethumadhavan, and S. Stolfo, “CLKSCREW: Exposing the perils of Security-Oblivious energy management,” in _26th USENIX Security Symposium (USENIX Security 17)_ , Aug. 2017. [Online]. Available: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
  * [30] K. Murdock, D. Oswald, F. D. Garcia, J. Van Bulck, D. Gruss, and F. Piessens, “Plundervolt: Software-based fault injection attacks against intel sgx,” in _2020 IEEE Symposium on Security and Privacy (SP)_ , 2020, pp. 1466–1482.
  * [31] H. Kumar, N. Chawla, and S. Mukhopadhyay, “BiasP: A DVFS based exploit to undermine resource allocation fairness in linux platforms,” in _Proceedings of the ACM/IEEE International Symposium on Low Power Electronics and Design_ , ser. ISLPED ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 223–228. [Online]. Available: https://doi.org/10.1145/3370748.3406549
  * [32] N. Chawla, A. Singh, M. Kar, and S. Mukhopadhyay, “Application inference using machine learning based side channel analysis,” in _International Joint Conference on Neural Networks_ , 2019.
  * [33] “CPU performance scaling,” https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html.
  * [34] “Device performance scaling,” https://www.kernel.org/doc/html/latest/driver-api/devfreq.html.
  * [35] Y. Ma and Y. Fu, _Manifold learning theory and applications_. CRC press Boca Raton, 2012, vol. 434.
  * [36] J. J. DiCarlo and D. D. Cox, “Untangling invariant object recognition,” _Trends in cognitive sciences_ , vol. 11, no. 8, pp. 333–341, 2007.
  * [37] S. Chung, D. D. Lee, and H. Sompolinsky, “Classification and geometry of general perceptual manifolds,” _Physical Review X_ , vol. 8, no. 3, p. 031003, 2018.
  * [38] S. Sebastián and J. Caballero, “Avclass2: Massive malware tag extraction from av labels,” in _Annual Computer Security Applications Conference_ , ser. ACSAC ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 42–53. [Online]. Available: https://doi.org/10.1145/3427228.3427261
  * [39] L. Li, D. Li, T. F. Bissyandé, J. Klein, Y. Le Traon, D. Lo, and L. Cavallaro, “Understanding android app piggybacking: A systematic study of malicious code grafting,” _IEEE Transactions on Information Forensics and Security_ , vol. 12, no. 6, 2017.
  * [40] K. Allix, T. F. Bissyandé, J. Klein, and Y. Le Traon, “Androzoo: Collecting millions of android apps for the research community,” in _Proceedings of the 13th International Conference on Mining Software Repositories_ , ser. MSR ’16. New York, NY, USA: ACM, 2016, pp. 468–471. [Online]. Available: http://doi.acm.org/10.1145/2901739.2903508
  * [41] S. Chen, L. Fan, C. Gao, F. Song, and Y. Liu, “Peeking into the gray area of mobile world: An empirical study of unlabeled android apps,” in _2021 IEEE 32nd International Symposium on Software Reliability Engineering (ISSRE)_ , 2021, pp. 579–590.
  * [42] “Android Monkey,” https://developer.android.com/studio/test/other-testing-tools/monkey.
  * [43] Y. Zhou and X. Jiang, “Dissecting android malware: Characterization and evolution,” in _2012 IEEE Symposium on Security and Privacy_ , 2012, pp. 95–109.
  * [44] “Android Debug Bridge,” https://developer.android.com/studio/command-line/adb.
  * [45] J. Hernandez Jimenez and K. Goseva-Popstojanova, “Malware detection using power consumption and network traffic data,” in _2019 2nd International Conference on Data Intelligence and Security (ICDIS)_ , 2019, pp. 53–59.
  * [46] R. Bridges, J. Hernández Jiménez, J. Nichols, K. Goseva-Popstojanova, and S. Prowell, “Towards malware detection via cpu power consumption: Data collection design and analytics,” in _2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications_ , 2018, pp. 1680–1684.
  * [47] S. S. Clark, B. Ransford, A. Rahmati, S. Guineau, J. Sorber, W. Xu, and K. Fu, “WattsUpDoc: Power side channels to nonintrusively discover untargeted malware on embedded medical devices,” in _2013 USENIX Workshop on Health Information Technologies (HealthTech 13)_. Washington, D.C.: USENIX Association, Aug. 2013. [Online]. Available: https://www.usenix.org/conference/healthtech13/workshop-program/presentation/clark
  * [48] F. Ding, H. Li, F. Luo, H. Hu, L. Cheng, H. Xiao, and R. Ge, “DeepPower: Non-intrusive and deep learning-based detection of IoT malware using power side channels,” in _Proceedings of the 15th ACM Asia Conference on Computer and Communications Security_ , ser. ASIA CCS ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 33–46. [Online]. Available: https://doi.org/10.1145/3320269.3384727
  * [49] A. Küchler, A. Mantovani, Y. Han, L. Bilge, and D. Balzarotti, “Does every second count? time-based evolution of malware behavior in sandboxes,” 01 2021.
  * [50] “Logcat,” https://developer.android.com/studio/command-line/logcat.
  * [51] T. Schneider and A. Moradi, “Leakage assessment methodology,” _Cryptographic Hardware and Embedded Systems_ , 2015.
  * [52] D. Arp, M. Spreitzenbarth, M. Hübner, H. Gascon, and K. Rieck, “Drebin: Effective and explainable detection of android malware in your pocket,” 02 2014.
  * [53] L. Onwuzurike, E. Mariconti, P. Andriotis, E. De Cristofaro, G. Ross, and G. Stringhini, “Mamadroid: Detecting android malware by building markov chains of behavioral models (extended version),” 2017. [Online]. Available: https://arxiv.org/abs/1711.07477
  * [54] “Droidapiminer: Mining api-level features for robust malware detection in android,” in _Security and Privacy in Communication Networks - 9th International ICST Conference, SecureComm 2013, Revised Selected Papers_ , ser. Lecture Notes of the Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering, LNICST, T. Zia, A. Zomaya, V. Varadharajan, and M. Mao, Eds. Springer Verlag, 2013, pp. 86–103.
  * [55] A. Saracino, D. Sgandurra, G. Dini, and F. Martinelli, “Madam: Effective and efficient behavior-based android malware detection and prevention,” _IEEE Transactions on Dependable and Secure Computing_ , vol. 15, no. 1, pp. 83–97, 2018.
  * [56] M. Ozsoy, C. Donovick, I. Gorelik, N. Abu-Ghazaleh, and D. Ponomarev, “Malware-aware processors: A framework for efficient online malware detection,” in _2015 IEEE 21st International Symposium on High Performance Computer Architecture (HPCA)_ , 2015, pp. 651–661.
  * [57] “Fix performance bottlenecks with Intel VTune Profiler,” https://www.intel.com/content/www/us/en/developer/tools/oneapi/vtune-profiler.html#gs.ug2nh3.
  * [58] Y. Li, Z. Yang, Y. Guo, and X. Chen, “Droidbot: a lightweight ui-guided test input generator for android,” in _2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C)_ , 2017, pp. 23–26.