# Dynamic detection of mobile malware using smartphone data and machine
learning

J.S. Panman de Wit
University of Twente
&J. van der Ham
University of Twente
&D. Bucur
University of Twente

###### Abstract

Mobile malware are malicious programs that target mobile devices. They are an
increasing problem, as seen in the rise of detected mobile malware samples per
year. The number of active smartphone users is expected to grow, stressing the
importance of research on the detection of mobile malware. Detection methods
for mobile malware exist but are still limited.

In this paper, we provide an overview of the performance of machine learning
(ML) techniques to detect malware on Android, without using privileged access.
The ML-classifiers use device information such as the CPU usage, battery
usage, and memory usage for the detection of 10 subtypes of Mobile Trojans on
the Android Operating System (OS).

We use a real-life dataset containing device and malware data from 47 users
for a year (2016). We examine which features, i.e. aspects, of a device, are
most important to monitor to detect (subtypes of) Mobile Trojans. The focus of
this paper is on dynamic hardware features. Using these dynamic features we
apply state-of-the-art machine learning classifiers: Random Forest, K-Nearest
Neighbour, and AdaBoost. We show classification results on different feature
sets, making a distinction between global device features, and specific app
features. None of the measured feature sets require privileged access.

Our results show that the Random Forest classifier performs best as a general
malware classifier: across 10 subtypes of Mobile Trojans, it achieves an F1
score of 0.73 with a False Positive Rate (FPR) of 0.009 and a False Negative
Rate (FNR) of 0.380. The Random Forest, K-Nearest Neighbours, and AdaBoost
classifiers achieve F1 scores above 0.72, an FPR below 0.02 and, an FNR below
0.33, when trained separately to detect each subtype of Mobile Trojans.

##  1 Introduction

Nowadays smartphones have become an integral part of life, with people using
their phones in both their private and professional life. The number of active
smartphone users globally is expected to be 7.3 billion by 2025 [1]. The rise
in smartphone users has also led to an increase in malicious programs
targeting mobile devices, i.e. mobile malware. Criminals try to exploit
vulnerabilities on smartphones of other people for their own purposes.
Additionally, over the past years, malware authors have become less
recreational-driven and more profit-driven as they are actively searching for
sensitive, personal, and enterprise information [2].

Detection of mobile malware is becoming increasingly relevant, with machine
learning showing the most promise. In this paper we present an overview of the
performance of state-of-the-art machine learning classifiers using sensor data
on the Android mobile operating system. We show different training approaches
for each of the classifiers, showing their performance on individual and
general cases. These machine learning classifiers can be trained on a cluster
on a large dataset, resulting in a classifier. This classifier can then be
deployed on mobile phones to detect future malware based on the dynamic sensor
data similar to the dataset, i.e. dynamic analysis.

Academic work is mainly divided into dynamic analysis and static analysis of
mobile malware. Dynamic analysis refers to the analysis of malware during run-
time, i.e. while the application is running. Static analysis refers to the
analysis of malware outside run-time, e.g. by analysing the installation
package of a malware app. Dynamic analysis has advantages over static analysis
but methods are still imperfect, ineffective, and incomprehensive [3].

An important limitation is that in most studies of malware detection, virtual
environments are used, e.g. analysis on a PC, instead of real mobile devices.
An increasing trend is seen in malware that use techniques to avoid detection
in virtual environments, thereby making methods based on analysis in virtual
environments less effective than methods based on analysis on real devices
[2]. Moreover, we found that most methods are assessed with i) malware running
isolated in an emulator, and ii) malware running for a brief period. This kind
of assessment does not reflect the circumstances of a real device with for
example different applications running at the same time. Therefore, most
research does not provide a realistic assessment of detection performances of
their detection methods due to their unrealistic circumstances.

Using a dataset [4] containing data of 47 users throughout the year 2016, this
research provides valuable knowledge on detecting mobile malware on real
devices and a realistic assessment of the research’s detection methods. This
paper focuses on dynamic hardware features as our initial literature
exploration showed relatively few research compared to other types of dynamic
features (e.g. software and firmware). In this work, we compare the detection
performance of the Random Forest, K-Nearest Neighbour, and AdaBoost
classifiers. The classifier performance is assessed on 10 subtypes of Mobile
Trojans, i.e. malware showing benign behaviour but performing malicious
behaviour, as these are the most prevalent mobile malware type [5, 6].
Furthermore, we examine which features are important in detecting different
subtypes of Mobile Trojans. We find that the Random Forest and AdaBoost
classifiers have similar and better performances than the K-Nearest Neighbour.
Additionally, our initial results show that AdaBoost may be more suitable than
the other classifiers, for use cases where detection models are built with
data from one subset of users and subsequently used for protecting other
users. Additionally, we show that application-specific features are important
in detecting mobile malware. In contrast to other literature, which often
assessed detection models on devices running one or few applications in
virtual environments, we find low predictability using only global device
features.

In summary, we make the following contributions:

  * •

We use a recent real-life sensor dataset to create multiple mobile malware
detection models. Most literature is based on environments with models based
on emulator data, simulated user input, and/or short testing durations. Our
research takes a realistic approach, contributing to the body of scientific
literature on malware detection that is based on real-life data rather than
data derived from emulators and virtual environments.

  * •

Our results are based on a dataset containing data from 47 real users over a
time span of 1 year. To the authors’ best knowledge, this is one of the first
research on data from this many users over a long time period. The large user
pool and time span increases the confidence in the generalisability of the
results.

  * •

We evaluated our detection methods on a Random Forest, K-nearest neighbour and
AdaBoost classifiers with several performance metrics. AdaBoost has been
researched little in literature. We provide the performance of the classifiers
with several training and testing methods.

  * •

Performance of the classifiers is shown for seperate mobile malware types. The
results show a large difference in performance for several mobile malware
types, indicating the difficulty of detecting some mobile malware types.
Earlier research, to the best of our knowledge, did not include a comparison
of this many mobile malware types.

  * •

We briefly describe a testing method where models are trained on data of one
set of users and tested on data from another set of users. This testing method
may be useful when detection models are built with one user pool and are
subsequently used to protect another, perhaps larger, user pool.

  * •

All features included in this research do not require any privileged access.
This increases the usability of mobile applications based on our detection
methods. Additionally, we show which feature categories and which specific
features are most important in detecting different malware types.

##  2 Related works

In an early, highly cited study (Shabtai [7] from 2011), the authors designed
a behavioural malware detection framework for Android devices called
Andromaly. This used device data: touch screen, keyboard, scheduler, CPU load,
messaging, power, memory, applications, calls, processes, network, hardware,
binder, and LED. 40 benign applications and 4 self-developed malware
applications (a DOS Trojan, SMS Trojan, Spyware Trojan, and Spyware malware)
were executed. When training the detection model on data from the same mobile
device, the J48 decision tree classifier performed best; on the other hand, a
Naive Bayes classifier detected malware best in experiments in which the
testing was done on data from a new device (see the overview in Table 2).
Despite relatively high False Positive Rates with all their models, Andromaly
showed the potential of detecting malware based on dynamic features using
machine learning, compared different classifiers, trained and tested on data
collected from real devices. However, the study is relatively old, and the
malware ecosystem has since changed.

Table 1: Related work. When multiple malware classifiers are studied, the best
one is emphasized. Table 2: *

Legend: Acc accuracy, AZ Androzoo [8], bat battery, BN Bayesian Network, Cr
Crowdroid [9], cust Custom, Dr Drebin [10], DS Decision Stump, DT Decision
Tree, GBT Gradient Boosted Tree Ge Malware Genome Project [11], GM Gaussian
Mixture, histo Histogram, IR Isotonic Regression Kmeans K-means clustering,
KNN K-Nearest Neighbour, LDA Linear Discriminant Analysis, LDC Local Density
Cluster-Based Outlier Factor, loc Location, LR Logistic Regression, mem
memory, md metadata, MLP Multi-Layer Perceptron, mult Multiple datasets, NB
Naive Bayes, netw network, NN Neural Network, Om Open Malware [12], perm
permissions, PC Parzen classifier proc process PS Play Store, QDA Quadratic
Discriminant Analysis, RBF Radial Basis Function RF Random Forest, sens. act
Sensitive activities, ShD Sherlock dataset stdev standard deviation, sto
storage, SVM Support Vector Machine, SC system calls, UP user presence, VE
Virtual Environment, VS VirusShare [13], VT VirusTotal [14] Article Features
Training and testing Performance Ref Year Dynamic Static Benign Malware
Platform Classifiers Acc TPR FPR [7] 2012 various (14) - 40
4${}^{\text{cust}}$ 2 devices BN, histo, J48, Kmeans, LR, NB 0.81 0.79 0.48
[15] 2013 bat, Binder, CPU, mem, netw perm 408${}^{\text{PS}}$
1330${}^{\text{Ge,VT}}$ VE, Monkey BN, J48, LR, MLP, NB, RF 0.81 0.97 0.31
[16] 2013 Binder, CPU, mem - 408${}^{\text{PS}}$ 1130${}^{\text{Ge,VT}}$ VE,
Monkey RF, BN, NB, MLP, J48, DS, LR 1.00 - few [17] 2013 CPU, net, mem, SMS -
30${}^{\text{PS}}$ 5${}^{\text{cust}}$ 1 device NB, RF, LR, SVM - 0.99 0.00
[18] 2014 bat, CPU, mem, netw - >$2^{\text{PS}}$ 3${}^{\text{Cr}}$ 12 devices
GM-LDC $\approx$1 $\approx$1 $\approx$0 [19] 2014 bat, time, loc - -
2${}^{\text{cust}}$ 11 devices stdev $\approx$1 - $\approx$0 [20] 2016 SC,
SMS, UP md $9804^{\text{PS}}$ 2800 3 devices 1-KNN, LDA, QDC, MLP, PC, RBF -
0.97 0.00 [21] 2016 bat - - 7${}^{\text{cust}}$ 1 device NN, DT - >0.85 - [22]
2016 CPU, mem - 940${}^{\text{PS}}$ 1120${}^{\text{Ge}}$ VE, Monkey LR - 0.86
0.17 [23] 2016 CPU, mem, SC - 1709${}^{\text{PS}}$ 1523${}^{\text{Dr}}$ VE,
Monkey Kmeans-RF 0.67 0.61 0.28 [24] 2016 CPU, mem, net, sto -
1059${}^{\text{PS}}$ 1047${}^{\text{Dr}}$ VE, Monkey RF 1.00 0.82 0.01 [25]
2017 CPU, mem, net - - <5560${}^{\text{Dr}}$ VE, Monkey SVM 0.82 - - [26] 2018
CPU, net - >10 3${}^{\text{ShD}}$ 47 devices DT 1 1 <1% [27] 2018 Method
calls, Intents - 17k${}^{\text{PS, AZ}}$ 13.9k${}^{\text{mult}}$ VE, Monkey RF
0.98 0.98 - [28] 2018 Network, SMS, Files, more - - 4442${}^{\text{Dr}}$ VE,
Monkey RF, DT, KNN, SVM, NN 0.813 0.813 - [29] 2019 CPU, mem, api - -
27000${}^{\text{Om}}$ VE SVM, RF, NN 0.97 - - [30] 2019 Bat, CPU, net, proc -
3${}^{\text{ShD}}$ 3${}^{\text{ShD}}$ 47 devices IR, RF, DT, GBT, MLP, SVM, LR
1 1 <1% [31] 2020 API calls perm 11505 19620 8 devices, DynaLog NN, NB, SVM,
DT 0.95 0.98 0.09 this CPU, bat, mem, net, sto - 10${}^{\text{cust}}$
10${}^{\text{cust}}$ 47 devices RF, NB, KNN, MLP, AdaBoost 0.96 0.65 0.01

The STREAM framework [15], aims to enable rapid large-scale validation of
machine-learning classifiers for mobile malware. STREAM used 41 features
(listed in Table 2) collected every 5 seconds from emulators running in a so-
called ATAACK cloud. The emulator used the Android Monkey application to
simulate pseudo-random user behaviour such as input on the touchscreen. To
evaluate their detection model, the authors used six classifiers, with good
accuracy and TPR for the Bayesian Network. The training set had 408 popular
applications from the Google Play Store and 1330 malware applications from the
Malware Genome Project database [11] and the VirusTotal database [14]. The
testing set had 24 benign and 23 malware applications from the same databases.
This showed the potential of using dynamic features, although the FPR for all
classifiers was relatively high. Additionally, this research ran applications
separately for 90 seconds and made use of a virtual environment in the form of
an emulator with user-like behaviour created by the Android Monkey tool. This
lowers the confidence that the model would perform the same in real life. The
same dataset from Amos [15] was used in Alam [16] for anomaly detection with
application behaviour features: only the Binder, CPU, and memory features. The
dataset was then balanced. The Random Forest classifier had an excellent
accuracy of 99.9857% and a root MSE of 0.0183%. Only 2 false positives were
measured during this experiment. However, it is sensitive to the same
limitations as Amos [15].

Saracino [20] describes an improvement of an earlier anomaly detection model
(Dini [32]). This version includes system calls, user presence, and SMS
features, plus a static analysis of application packages. Many classifiers
were trained and tested. Their performance is not reported, but the authors
state that 1-Nearest Neighbour achieved the best classification results. To
evaluate the TPR, the detection framework has been tested against 2800 malware
applications from the Malware Genome Project, Contagio [33], and VirusShare
[13], representing the Botnet, Installer, Trojan, Ransomware, Rootkit, SMS
Trojan, and Spyware malware families. How long the different malware
applications were run is not mentioned. Also, it is unknown whether the same
device was used for the training and testing of the classifiers. The framework
achieved very good TPR and FPR, and also detected some zero-day attacks,
undetected by multiple Antivirus Software at that time. The performance was
assessed on real devices, varying the usage intensity over a period of one
week, to reflect real-life circumstances. A limitation is a requirement for
root permissions, as system calls were used as features.

In Milosevic [22], memory and CPU usage are predictive features, tracked by
running every application separately for 10 minutes in an Android emulator.
The emulator was fed with user-like input by the Monkey application. Their
optimized feature set only contained 7 features. The classification algorithm
used was linear Logistic Regression with the use of a sliding window
technique. This was validated on a set of 94 benign and 89 malware
applications.

The classifier with the highest TPR of 95.7% of malware had a relatively high
FPR of 25%; the classifier with the highest F-measure had a TPR 85.5% and an
FPR of 17.2%. This study showed the potential of using the memory and CPU
usage as features for the dynamic detection of mobile malware. However, the
detection had relatively high FPR, besides the disadvantage of using emulator
data.

More studies were based on emulation. In Ferrante [23], the features were
related to system calls, memory, and CPU usage. Benign apps were downloaded
from the Google Play store and malicious applications were collected from the
Drebin dataset [10]. The applications were run for 10 minutes in an Android
emulator and features were collected every 2 seconds. The emulator was fed
with user-input from the Monkey application. As detection models, they first
used a K-means clustering algorithm to cluster apps based on the similarity of
memory and CPU usage, then a Random Forest classifier on every cluster that
classified the applications based on their system calls. The best performing
model was the classifier with 7-means clustering and a Random Forest
classifier of 50 trees. This showed the potential of using system calls,
memory, and CPU features for malware detection. The performance is relatively
low compared to other detection methods, and the method needs root permission
as it uses system calls as features. In Canfora [24], the features are related
to CPU, memory, storage and network. The applications were run for 60 seconds
in an Android emulator. The features were used both raw and after a Discrete
Cosine Transformation. Furthermore, the authors varied the granularity of the
detection method by either taking all the features, only the global features,
or only the features of the application under analysis. The Random-Forest
classifier using global features had very good accuracy and FPR.

In Massarelli [25] the authors used the Drebin dataset for malicious
applications (but it is unknown how many malware applications were included
from the 5560 in the dataset). The features were both system-wide and
application-specific. An emulator was used for training the model, fed with
simulated user input events from the Monkey application. The classifier was an
SVM with a Radial Basis Function kernel, which had good accuracy. The exact
FPR is unknown, but the precision of the model ranges from 10% to 90%
depending on the malware family, which is low in comparison with other
methods. This also used an emulator, leading to limitations in its
applicability.

In Martin [28], multiple classifiers, including Random Forest, K-nearest
neighbour, and SVMs are assessed. They achieve an F1 score of 0.803 on a
dataset containing 4442 malicious malware samples. They use hardware features
related to network, SMS, file reads/writes. Other features included are:
services started, classes loaded, information leaks via the network, file and
SMS services, circumvented permissions, cryptographic operations, SMSs sent,
and phone calls. Their detection models are also assessed using a virtual
environment rather than devices. This is also the case for Dai [29]. They use
features related to CPU, Memory and API calls (but also software features such
as API calls, which this paper does not). Their best classifier is well-
performing with an F1-score of 0.98. Additionally, they assess their detection
model on a large dataset of more than 27.000 malicious applications.

During the writing of this paper, other authors used the SherLock dataset, but
to a much more limited extent than this research. In Memon [30], 7 classifiers
were trained for malware detection: Isotonic Regression, Random Forest,
Decision Trees, Gradient-Boosted Trees, MultiLayer Perceptron, SVM, and
Logistic Regression. The data was balanced so that 50% of the labels were
benign and 50% were malicious. Only data from Q3 2016 was studied, meaning
that only three malware types (Madware, Ransomware and Click-jacking) were
included for training and testing, with CPU, network traffic, battery, and
process features. The Gradient-Boosted Trees had the best results with an F1
score of 0.91% and an FPR of 0.09%. Their Random Forest classifier also worked
almost equally well. These make for better results than prior work, which may
be due to the limited number of malware types included.

In Wassermann [26], Decision Trees were trained as classifiers, only on
SherLock data from Q2 2016, so only three malware types (Spyware, Phishing,
Adware). The features used were network traffic and CPU-related. The label to
predict was whether the malicious app (Moriarty) was running. Their model
results in a recall of almost 100% with less than 1% FPR. This research showed
good app-detection results, although on a limited set of malware; also, the
model cannot distinguish between individual (benign or malicious) actions; it
only predicts the presence of the malware on the system.

Recent literature on dynamic malware detection (Droidcat [27] and Dl-Droid
[31]) have high performance on a large dataset containing more than 10000
malware applications. However, DroidCat focuses on software features such as
Method Calls and trained and tested their method within a virtual environment
with simulated pseudo-random user behaviour. Dl-Droid achieves a TPR of 0.95
and an FPR of 0.09, but also only including software features such as API
calls. This paper focuses on hardware features only.

Recent work by (Cai et. al. [34]) analysed 17.664 Android applications
developed throughout 2010–2017. The paper describes differences in method
calls, ICC calls and source/sink calls during static-code analysis and dynamic
analysis. One of the finding of the paper is that access to sensitive data was
almost 10x more frequent during dynamic analysis than during static analysis
(Figure 17 and Finding 8). This finding indicates that dynamic analysis may
support in capturing all sensitive data calls and could therefore help in
detecting mobile malware.

Other research assessed have also used machine learning for the dynamic
detection of mobile malware, but this literature is unclear about the feature
collection method (Ham and Choi [17]), include few malware samples (Attar
[18], Dixon [19]), or experiment on an idle phone (Caviglione [21]).

While we have seen a body of prior work using dynamic hardware features to
detect malware on mobile devices, important issues remain unaddressed. Most
recent papers have trained their detection model on emulators with simulated
input; this makes it difficult to extrapolate their performances with real
users and to have high confidence in how realistic the results are.
Additionally, most studies have only executed the benign and malicious
applications for a few minutes, meaning that any delayed malicious behaviour
would not be detected. Also, a limited amount of research has shown excellent
results, particularly in what regards the FPR metric. In this paper, we
address these issues and provide a more realistic picture by learning from
data gathered with real users, from a study which executed malware from
different categories, over a large time span.

##  3 Method

###  3.1 Malware data

We use the SherLock dataset [4] provided by Ben-Gurion University. This
dataset contains 10 billion data records in system logs collected from 47
Samsung Galaxy S5 devices used by 47 different volunteer users, over a period
of over one year (2016). During this year, the volunteers executed both benign
and malicious applications on their devices. The data collection agent on the
phone is based on the Funf Open Sensing framework, developed by MIT Media Lab
[35]. This framework allows for the collection of sensor data (e.g. memory
consumption or CPU usage). The authors adjusted the source code to improve
stability and reliability. Additionally they added features such as the
collection of statistics on all running applications of a smartphone.
According to the SherLock paper[4] all features can be tracked without any
root permissions. The source code of the data collection agent can be found on
GitHub [36].

The malicious applications were written by the researchers based on wild
malware. Every month a different subtype of Mobile Trojan was installed on the
devices. Each malware version resembled a subtype of Mobile Trojan with both
benign and malicious actions. In total, 11 malware versions were included,
listed in Table 3.1 with their benign behaviour, malicious behaviour (as
described by [4]), malware type, a description of their actions, and the wild
malware on which the implementation was based. Important to note is that each
time data was transmitted by the malware application, it was scrambled prior
to sending to protect the privacy of the users.

Table 3: Malware types

|  Benign behaviour |  Malicious |  |  |
---|---|---|---|---|---
behaviour |  Type |  Description |  Wild
malware |  |
1 |  Game |  Contact theft |  Spyware |  Steals, encrypts, and transmits all contact stored on device. |  SaveMe, SocialPath
2 |  Web browser |  Spyware |  Spyware |  i) Spies on location and audio, or ii) spies on web traffic and web history. |  Code4hk, xRAT
3 |  Utiliz. Widget |  Photo theft |  Spyware |  Steals photos that are taken and in storage, and takes candid photos of the user. |  Photsy, Phopsy
4 |  Sports app |  SMS bank thief |  SMS Fraud |  Captures and reports immediately on SMSs that contain codes and various keywords. |  Spy.Agent.SI
5 |  Game |  Phishing |  Phishing |  Makes fake shortcuts and notifications to login to Facebook, Gmail, and Skype. |  Xbot
6 |  Game |  Adware |  Adware |  Gathers information and places ads, popups and banners. |  -
7 |  Game |  Madware |  Hostile downloader |  Gathers private information, places shortcuts, notifications, and attempts to install new applications. |  -
8 |  Lock-screen |  Ransomware |  Ransomware |  Performs either: 1) lock screen ransomware, or 2) crypto ransomware. |  Simplocker.A, SLocker
9 |  File Manager |  Click-jacking |  Privilege
escalation |  Tricks the user to activate accessibility services to then hijack the user interface. |  Shedun (GhostPush)
10 |  - |  Device theft |  - |  - |
11 |  Music Player |  Botnet |  DOS |  Either performs: 1) DDoS attacks on command, or 2) SMS botnet activities |  Tascudap.A, Nitmo.A…
12 |  Web media |  |  |  |
player |  Recon. Infiltr. |  Other |  Maps the connected local network and searches for files and vulnerabilities. |  - |

The dataset is divided into 13 probes, namely groups of multiple sensors that
shared the same sample interval. This research uses the following probes:

  * •

the Moriarty (_Malware_) probe for malware data,

  * •

the T4 (_System_) probe for global device data, and

  * •

the Applications (_Apps_) probe for app-specific device data.

The Malware probe sensed data from the malicious application installed on the
devices. Each malware probe’s record is a log of the _action_ taken by the
user’s malware application. Each action is part of a malware _session_ : the
malware application started in either a benign or malicious session. Within a
benign session, only benign actions were performed; in a malicious session,
the malware performed both benign and malicious actions. An overview of
Malware probe’s columns, their data type, and a description is shown in Table
4. For this research, we excluded version 10 and 12 as no malicious data was
available for these versions.

Table 4: Malware probe data overview Column | Datatype | Description
---|---|---
UserId | String | User ID
UUID | Numeric | Timestamp of action
Details | String | Details of action
Action | String | Action performed
ActionType | String | Whether action is benign or malicious
SessionType | String | Whether session is benign or malicious
Version | Decimal | Version number
SessionID | Decimal | Session ID
Behavior | String | Behaviour of current session

The System probe tracked global device data every 5 seconds. Each record of
the system probe is a log of the user’s global device data at a given time,
taken from the /proc/ folder. The feature categories that were tracked are
battery, CPU, network, memory, I/O interrupts, and storage. 41 features are
used from this probe.

The App probe recorded app data every 5 seconds for each application installed
on the device. For this research, the only relevant data is the app data of
the malware application. Each record is a log of the malware app data at a
given time, taken from the /proc/ folder. 35 features are used from this
probe. For a complete overview of the features used, refer to Table 13.

The data from the three probes is integrated by joining on the userid and
timestamp fields. Not all probes had the same tracking frequency so joining on
the timestamp column can not be done with a precise join. Therefore, probe
data with a maximum of 5 seconds after the timestamp of the Malware data is
used in the joining of the data. This way we can match 83% of the Malware data
with probe data. Additionally, we apply random undersampling to rebalance the
original dataset. The original dataset contains 90% malicious records and only
10% benign records. The dataset is balanced by downsizing the number of
malicious data points per malware type until 90% of the rows are benign
actions and 10% are malicious. The malicious data points that are removed are
chosen uniformly at random. The undersampling method is applied to both the
training and testing data. We apply the resampling method on the training data
to prevent the classifiers from a bias towards the (original) majority class
(i.e. malware data). We apply the resampling method on the testing data to to
better reflect real-life circumstances and to provide more realistic
classification results. In the real world, the number of malicious actions on
a mobile phone would be relatively low compared to the number of benign
records. Lastly, we normalize any features in the dataset by scaling it
between zero and one for the KNN classifier. No data normalization is used for
AdaBoost and RF as these are tree-based classifiers. The dataset now consists
of 28821 rows, 102 columns, and is 21.4 MB.

###  3.2 Supervised learning algorithms

We train a statistical classifier able to recognize malware signatures in any
log data collected on a smartphone. The classifier is trained, cross-
validated, and tested using the dataset described above. Three training
algorithms yielded well-performing classifiers: _Random Forest_ and _K-Nearest
Neighbour_ classifiers had a good performance in our related work (see Section
2), so we include them in our study. We add the _AdaBoost_ classifier, which
is designed specifically to improve the performance of a Random Forest. All
are nonlinear classifiers, able to capture complex relationships between the
variables in the dataset. Table 5 (based on [37]) lists advantages and
disadvantages for these algorithms.

Table 5: Pros and cons of classifiers

Classifier | Pros | Cons
---|---|---
Random Forest (RF) | Can overcome overfitting | A greedy algorithm
AdaBoost | Nonlinear classification | Sensitive to imbalanced dataset
| Efficient with high-dimensional data |
K-Nearest | High precision and accuracy | Computationally expensive
Neighbours (KNN) | Nonlinear classification | Sensitive to imbalanced dataset
| No assumption of features |

###  3.3 Training, cross-validating, and testing malware classifiers

All classifiers are trained to identify a malicious action (the ActionType
column of the Malware dataset). The classifiers that are trained differ in
their input data (feature set), classification target, and test mode. Three
feature sets are assessed: Global, Apps and a combination of both. The global
feature set includes global device features from the System probe. The apps
feature set include features from the Apps probe.

Two classification targets are tried. The first classification target (all
malware) trains one general malware classifier to identify malicious actions
by any of the 10 malware types in the dataset. The second classification
target (single malware) trains one single-purpose classifier per malware type,
resulting in 10 different trained models.

Two test modes are run. Both use a percentage of the data for training, and
the remaining for testing. In the _normal holdout test mode_ , the training
and testing data is sampled at random. In the _unknown device test mode_ , the
testing data contain data of devices that are not in the training data. The
unknown device test mode is used to simulate a situation in which no data is
yet available for a certain device. In that case, a model trained on data from
other devices is a solution. Testing the models on other devices also helps to
detect the potential bias of the model on a specific device. Note that only
the testing on the test set is adjusted; the cross-validation remains the
same.

Table 6: Different configurations for the classifiers trained

| Type | Description
---|---|---
Feature set | Global | Device features (the System probe)
(complete listing in Table 13) | Apps | App-specific features (the Apps probe)
| Combined | Both Global and Apps features
Classification target | All malware | Generic classifier across malware types
| Single malware | One classifier for each malware type
Test mode | Normal holdout | Training data includes all devices
| Unknown device | Test set includes data from new devices

To train the dataset, we use 4-fold cross-validation with holdout. The
hyperparameters of each classifier are tuned using a grid search. The search
space for the hyperparameter settings are as follows. For AdaBoost, the number
of estimators is in the interval [5, 400]; for Random Forest, the number of
trees in the interval [5, 320], the maximum tree depth in [3, 320], the
maximum number of features in [3, 102]; for K-Nearest Neighbours, the number
of neighbours in [1, 61]. We also use Recursive Feature Elimination together
with cross-validation (RFCV) to find the optimal number of features for all
classifiers. RFCV requires a feature ranking, as the method recursively
eliminates the least important feature. The feature rankings are based on the
Random Forest classifier and are calculated per different experiment setup
(i.e. per classification target, per test mode, per feature set).

To evaluate a classifier, we use the standard F1 score [3], namely the
harmonic mean of the Precision and Recall scores. These two metrics are
normally a trade-off of each other, and a high F1 score indicates a good
balance between these two metrics. Additionally, the training and testing
times of the classifiers are assessed.

The data is processed on a computing cluster with a Hadoop File System (HDFS)
suitable for big data. The cluster consists of 55 nodes with each 32 GB RAM
and 8-16 cores running Apache PySpark 2.2.0. The training and testing is done
with the package Spark Sklearn [38], a distributed implementation of the
machine-learning classifiers in the popular package machine-learning library
Scikit-learn [39]. Spark Sklearn is adjusted to provide and log more
information during the execution of experiments.

##  4 Results

###  4.1 Test mode normal holdout

An overview of the performances of the classifiers for classification target
all malware and test mode normal holdout is shown in Table 7. This table shows
the feature categories present in the best model, i.e. with the best
hyperparameter settings. From all models with similar performance as the best
model of that classifier (performance results that do not differ statistically
significantly (McNemar test a < 0.05 [40]), the classifier with the least
number of features is chosen, because this shows which features are relevant
for detecting specific malware types. The number of features is based on the
RFCV method described in Section 3. Table 7 shows the following:

  1. 1.

RF has the highest F1 score of 0.73 with feature set Apps and 0.72 with
feature set Combined.

  2. 2.

All classifiers have an F1 score below 0.42 with feature set Global. This
suggests that global features are less discriminative when detecting malicious
actions.

  3. 3.

RF with feature set Combined uses 10 app features (related to: App CPU, App
Memory, App Process) to detect malicious actions of malware, suggesting that
10 app features are sufficient in detecting malicious actions of mobile
malware. These 10 features are shown in Table 14. All features and their
corresponding feature category are shown in Tables 17 and 18.

  4. 4.

All classifiers have a higher FNR than FPR. This indicates that most models
incorrectly classify a malicious action as benign more often than vice versa.

Table 7: Comparison performance per classifier for classification target all
malware

Classifier | AdaBoost | Random Forest | KNN
---|---|---|---
Feature set |  Global |  Apps |  Comb. |  Global |  Apps |  Comb. |  Global |  Apps |  Comb.
Best trained model
Nr. features |  26 |  25 |  43 |  24 |  29 |  10 |  26 |  13 |  9
Accuracy |  0.922 |  0.943 |  0.945 |  0.922 |  0.958 |  0.959 |  0.897 |  0.944 |  0.946
F1 score |  0.226 |  0.595 |  0.610 |  0.422 |  0.730 |  0.722 |  0.356 |  0.674 |  0.688
FPR |  0.003 |  0.012 |  0.013 |  0.022 |  0.013 |  0.009 |  0.048 |  0.029 |  0.028
FNR |  0.868 |  0.522 |  0.502 |  0.670 |  0.346 |  0.380 |  0.674 |  0.336 |  0.320
Feature categories used
Battery |  ✓ |  |  ✓ |  ✓ |  |  |  ✓ |  |
CPU |  ✓ |  |  ✓ |  ✓ |  |  |  ✓ |  |
IO Interrupts |  |  |  |  |  |  |  |  |
Memory |  ✓ |  |  ✓ |  ✓ |  |  |  ✓ |  |
Metadata |  |  |  |  |  |  |  |  |
Network |  ✓ |  |  ✓ |  ✓ |  |  |  ✓ |  |
Storage |  |  |  |  |  |  |  |  |
Wifi |  |  |  |  |  |  |  |  |
App CPU |  |  ✓ |  ✓ |  |  ✓ |  ✓ |  |  ✓ |  ✓
App Info |  |  |  |  |  |  |  |  |
App Memory |  |  ✓ |  ✓ |  |  ✓ |  ✓ |  |  ✓ |  ✓
App Network traffic |  |  ✓ |  ✓ |  |  ✓ |  |  |  ✓ |
App Process |  |  ✓ |  ✓ |  |  ✓ |  ✓ |  |  ✓ |  ✓

Table 8 shows an overview of the performance per classifier per malware type
and feature set. Following the same reason as for Table 7, the performances
are shown for the least number of features and the best hyperparameter
settings per classifier. Table 8 shows the following:

  1. 1.

RF has the highest F1 score for 5 out of 10 malware types.

  2. 2.

KNN has the highest F1 score for 5 out of 10 malware types.

  3. 3.

AdaBoost has the highest F1 score for 4 out of 10 malware types 111Some
performance scores are the same, leading to a draw, hence to more than
expected highest F1 scores..

  4. 4.

AdaBoost has a high F1 score (>0.7) for 8 out of 10 malware types.

  5. 5.

RF has a high F1 score for 7 out of 10 malware types.

  6. 6.

KNN has a high F1 score for 7 out of 10 malware types.

  7. 7.

All classifiers have a low F1 score for malware type 4 (Spyware SMS) and 6
(Adware).

Table 8: Comparison performance per classifier for classification target
single malware and test mode normal holdout (The numerical malware types in
the first column are those listed in Table 3.1.)

| AdaBoost | Random Forest | KNN
---|---|---|---
Malware |  F1 |  FPR |  FNR |  F1 |  FPR |  FNR |  F1 |  FPR |  FNR
1 |  0.704 |  0.025 |  0.321 |  0.571 |  0.025 |  0.500 |  0.536 |  0.047 |  0.464
2 |  0.944 |  0.003 |  0.085 |  0.956 |  0.001 |  0.077 |  0.945 |  0.003 |  0.077
3 |  0.764 |  0.000 |  0.382 |  0.793 |  0.003 |  0.324 |  0.727 |  0.003 |  0.412
4 |  0.400 |  0.029 |  0.667 |  0.500 |  0.000 |  0.667 |  0.400 |  0.029 |  0.667
5 |  0.927 |  0.005 |  0.089 |  0.927 |  0.005 |  0.089 |  0.946 |  0.005 |  0.054
6 |  0.194 |  0.011 |  0.880 |  0.271 |  0.039 |  0.782 |  0.352 |  0.057 |  0.662
7 |  0.813 |  0.015 |  0.216 |  0.857 |  0.003 |  0.227 |  0.793 |  0.012 |  0.268
8 |  1.000 |  0.000 |  0.000 |  0.800 |  0.000 |  0.333 |  0.857 |  0.032 |  0.000
9 |  0.913 |  0.000 |  0.160 |  0.936 |  0.000 |  0.120 |  0.936 |  0.000 |  0.120
11 |  0.909 |  0.009 |  0.118 |  0.938 |  0.000 |  0.118 |  0.938 |  0.000 |  0.118
avg. |  0.757 |  0.010 |  0.292 |  0.755 |  0.008 |  0.324 |  0.743 |  0.019 |  0.284
stdev |  0.263 |  0.010 |  0.283 |  0.232 |  0.013 |  0.251 |  0.233 |  0.021 |  0.252

The feature categories included in the feature sets of the best models of
classifiers per malware type are shown in Table 9. Following the same reason
as for Table 7, the performances are shown for the least number of features
and the best hyperparameter settings per classifier. This shows the following:

  1. 1.

6 out of 10 malware versions are best detected using only app features.

  2. 2.

Malware version 4 (Spyware SMS) is best detected using only global features.
However, note that the F1 score for Spyware SMS is the lowest of all malware
versions.

  3. 3.

Malware version 11 (DOS) is best detected using only one global feature
regarding network traffic.

  4. 4.

Malware version 1 and 9 (Spyware contacts theft and Privilege Escalation /
Hostile downloader) is best detected using both the Apps and Global features.

  5. 5.

None of the classifier includes I/O interrupts, Storage, or Wifi features for
any of the malware versions.

Table 9: Best performing classifiers per malware type (The numerical malware
types in the first column are those listed in Table 3.1.)

Malware | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 11
---|---|---|---|---|---|---|---|---|---|---
Best trained model
Classifier | AdaBoost | KNN | RF | RF | KNN | KNN | RF | AdaBoost | RF | KNN
Feature set | Comb. | Apps | Apps | Global | Apps | Apps | Apps | Comb. | Comb. | Global
Nr. features | 49 | 8 | 5 | 28 | 7 | 11 | 9 | 14 | 10 | 1
F1 score | 0.70 | 0.94 | 0.73 | 0.50 | 0.95 | 0.35 | 0.86 | 1.00 | 0.94 | 0.94
Feature categories used
Battery | ✓ |  |  | ✓ |  |  |  |  | ✓ |
CPU | ✓ |  |  | ✓ |  |  |  |  | ✓ |
I/O Interrupts |  |  |  |  |  |  |  |  |  |
Memory | ✓ |  |  | ✓ |  |  |  |  |  |
Network traffic | ✓ |  |  | ✓ |  |  |  |  | ✓ | ✓
Storage |  |  |  |  |  |  |  |  |  |
Wifi |  |  |  |  |  |  |  |  |  |
App CPU | ✓ | ✓ | ✓ |  | ✓ | ✓ | ✓ | ✓ | ✓ |
App memory | ✓ | ✓ | ✓ |  | ✓ | ✓ | ✓ | ✓ | ✓ |
App network traffic | ✓ |  |  |  |  | ✓ |  |  |  |
App process | ✓ | ✓ | ✓ |  |  |  |  | ✓ |  |

###  4.2 Test mode unknown device

An overview of the performances of the classifiers for classification target
all malware and test mode unknown device is shown in Table 10. This table
shows high False Negative Rates (FNR) for all classifiers. Therefore, we do
not include the feature categories as in the previous sections, as little
insight can be drawn from these poorly performing models. Table 11 shows an
overview of the performance per classifier per malware type and feature set.
Comparing this Table with Table 8, we see the following:

  1. 1.

All classifiers show lower performance for 7 out of 10 malware versions
(versions 1-4 and 7-9) for test mode unknown device, compared to test mode
normal holdout.

  2. 2.

AdaBoost and RF show better performance for malware version 5 (Phishing) for
test mode unknown device, compared to test mode normal holdout.

  3. 3.

AdaBoost shows a perfect score (f1 score of 1) for detecting malware version 8
(Ransomware) for test mode unknown device. For test mode normal holdout,
AdaBoost showed a perfect score as well.

  4. 4.

AdaBoost and KNN shows a better performance for malware version 11 (DOS) for
test mode unknown device, compared to test mode normal holdout.

Table 10: Comparison performance per classifier for classification target All
malware and test mode unknown device

Classifier | AdaBoost | Random Forest | KNN
---|---|---|---
Feature set |  Global |  Apps |  Comb. |  Global |  Apps |  Comb. |  Global |  Apps |  Comb.
Best model
Nr. features |  29 |  28 |  44 |  28 |  6 |  8 |  30 |  4 |  11
Accuracy |  0.923 |  0.944 |  0.926 |  0.888 |  0.918 |  0.925 |  0.824 |  0.917 |  0.910
F1 score |  0.207 |  0.583 |  0.563 |  0.249 |  0.562 |  0.561 |  0.202 |  0.537 |  0.522
FPR |  0.005 |  0.013 |  0.042 |  0.052 |  0.057 |  0.043 |  0.126 |  0.053 |  0.061
FNR |  0.878 |  0.528 |  0.423 |  0.776 |  0.362 |  0.423 |  0.732 |  0.415 |  0.407

Table 11: Comparison performance per classifier for classification target
single malware and test mode unknown device (The numerical malware types in
the first column are those listed in Table 3.1.)

| AdaBoost | Random Forest | KNN
---|---|---|---
Malware |  F1 |  FPR |  FNR |  F1 |  FPR |  FNR |  F1 |  FPR |  FNR
1 |  0.444 |  0.028 |  0.600 |  0.364 |  0.056 |  0.600 |  0.316 |  0.153 |  0.400
2 |  0.817 |  0.015 |  0.230 |  0.861 |  0.014 |  0.164 |  0.847 |  0.027 |  0.115
3 |  0.618 |  0.013 |  0.514 |  0.712 |  0.013 |  0.400 |  0.597 |  0.080 |  0.343
4 |  0.000 |  0.028 |  1.000 |  0.000 |  0.000 |  1.000 |  0.000 |  0.000 |  1.000
5 |  0.967 |  0.000 |  0.064 |  0.978 |  0.000 |  0.043 |  0.932 |  0.000 |  0.128
6 |  0.200 |  0.056 |  0.817 |  0.245 |  0.037 |  0.802 |  0.207 |  0.134 |  0.706
7 |  0.480 |  0.027 |  0.500 |  0.583 |  0.019 |  0.417 |  0.476 |  0.015 |  0.583
8 |  1.000 |  0.000 |  0.000 |  0.000 |  0.000 |  1.000 |  0.667 |  0.032 |  0.000
9 |  0.901 |  0.037 |  0.089 |  0.889 |  0.037 |  0.111 |  0.871 |  0.022 |  0.178
11 |  0.977 |  0.000 |  0.045 |  0.930 |  0.010 |  0.091 |  0.952 |  0.000 |  0.091
avg. |  0.640 |  0.020 |  0.386 |  0.556 |  0.018 |  0.463 |  0.586 |  0.046 |  0.354
stdev |  0.352 |  0.018 |  0.353 |  0.380 |  0.019 |  0.372 |  0.330 |  0.057 |  0.322

###  4.3 Training and testing times

Table 12 shows the training and testing times per classifier. This shows that
training times of both AdaBoost and RF are significantly higher than for KNN
(an algorithm which does no training). In contrast, testing times for KNN are
significantly higher in comparison.

Table 12: Training and testing times per classifier for classification target
all malware and test mode normal holdout

Classifier | AdaBoost | Random Forest | KNN
---|---|---|---
Feature set |  Global |  Apps |  Comb. |  Global |  Apps |  Comb. |  Global |  Apps |  Comb.
Train (s) |  17 |  18 |  31 |  <1 |  30 |  10.5 |  <1 |  <1 |  <1
Test (s) |  <1 |  <1 |  <1 |  <1 |  <1 |  <1 |  2 |  3 |  8

##  5 Discussion

Below a discussion on the main findings of this research is presented. Most
related papers use a different evaluation method making direct comparison
difficult. Nevertheless, we tried ordering the findings from good to bad,
compared to existing detection methods.

#### High performance RF, KNN, AdaBoost for classification target single
malware

In this research, RF and KNN showed good results (F1 scores on average above
0.7) when separate models were trained per malware type. These findings are in
line with earlier studies that found good performances for RF [16, 17, 24] and
KNN [20] on the detection of mobile malware. None of the literature we found
examined the AdaBoost classifier, hence the good performance of AdaBoost is a
new finding.

#### AdaBoost is consistent with different test modes

All classifiers, except AdaBoost, show worse performances when tested on new
devices (test mode unknown device), than if tested on the same devices (test
mode normal holdout). Most studies do not provide information on the test
mode, thus test modes of other research cannot be compared to our study. Our
results suggest that AdaBoost may be more suitable when its purpose is to
first build a detection method with a subset of users and subsequently use
this detection method to protect other users. This approach is scalable: new
users can be protected with an already existing detection method. Otherwise,
the model needs to be retrained constantly for every new user. AdaBoost with
the Apps feature set and test mode unknown device had an F1 score of 0.583, an
FPR of 0.013, and an FNR of 0.528. The high FNR calls for improvements in
detecting malicious actions of new devices, given the better scalability of
this method. Some suggestions are given in Section 8.

#### Perfect score on Ransomware, but little data

AdaBoost showed a perfect score for malware version 8 (Ransomware). The
dataset used for training and testing contained only 170 records for malware
version 8. Given the low number of testing instances, it is hard to estimate
whether this performance is the same on larger test sets.

#### High performance RF for classification target all malware

The best RF model with classification target all malware used the Apps feature
set, containing 29 app features, and had an F1 score of 0.730, an FPR of
0.013, and an FNR of 0.346 (i.e., TPR of 0.654). Similar results (with no
statistically significant difference to the best RF model), are achieved with
the Combined feature set (F1 score of 0.722, an FPR of 0.009, and TPR of
0.620). A TPR of 0.62 is relatively low compared to other studies on the
dynamic detecting of mobile malware, which showed TPRs between 0.61 and 1 (see
Section 2 for a complete comparison). However, in contrast to [15, 22, 24],
with TPRs between 0.82 and 0.97, our study used data from real-life users
instead of virtual environments for the training and testing of detection
methods. The use of real-life data for the training of models may have led to
lower performance due to the additional noise included in our dataset (see
paragraph Overall high false-negative rate below).

Other studies using real devices for training and testing of models, based
their performance on apps running isolated for 10 minutes [15], devices in an
idle state [21] or unknown circumstances [17, 18]. One study that used real
devices under real-life circumstances for the assessment of their detection
method is [20]. In that study, the researchers created a multi-level framework
(called MADAM) that showed high performance (TPR 0.97, FPR 0.005). MADAM
requires root permissions as it used System Calls for the detection of
malware. In contrast to MADAM, we do not require any root permissions.
Furthermore, MADAM used both dynamic and static features, while we used only
dynamic features. Lastly, MADAM is a detection method consisting of multiple
architectural blocks that monitor different aspects of the device, in contrast
to this present study that does not consist of a complex architecture.

#### False-negative rate higher than false-positive rate

In this research, the FNR (undetected malicious actions) was overall higher
than the FPR (benign actions labelled as malicious). In other studies that we
examined during our literature research, the FPR is overall higher than the
FNR. This may be due to the difference in the distribution of malicious and
benign data points. In our research, the dataset contained 90% benign data
points and 10% malicious data points. As most models are biased towards the
majority class, the FNR is expected to be higher than the FPR in our case. In
other studies the distribution of malicious and benign data points used are
often 50/50 or a majority of malicious data points, resulting in equal FPRs
and FNRs, or higher FPRs than FNRs. This stresses the importance of presenting
both FPR and FNR values in research, which was not done in all examined
studies.

#### Testing times long for KNN

The testing times for KNN were more than 3 seconds for both the Apps and
Combined feature set. This is based on our experimental setup which contained
more computing power than the average smartphone. Given that in real-life,
malicious or suspicious data should be tracked and noticed near real-time,
long testing times may not be practical or feasible. Additionally long testing
times stress the battery more as long computations are needed. Therefore,
based on testing times, AdaBoost and RF may be preferable when models are
running on smartphones.

#### Low predictability on Spyware SMS and Adware

Performance scores on the detection of malware versions 4 (Spyware SMS) and 6
(Adware) were low (F1 score below 0.5). The dataset used for training and
testing contained 190 records for malware version 4. The low performance on
the detection of Spyware SMS may, therefore, be due to the small number of
training instances. The training and testing dataset contained 7940 records
for malware version 6. Therefore, the low performance is most likely not a
result of insufficient training instances, and more research is needed to find
the cause for the low performance on detecting Adware.

#### Lower F1-scores compared to other state-of-the-art dynamic malware
detectors

Our best classifier (RF) shows an F1-score of 0.73. This is lower compared to
state-of-the-art dynamic malware detectors such as Cai [27] and Saracino [20].
In [27], the performance is high, but the results are taken from malware
running in virtual environments for only 10 minutes with pseudo-random user
input from Monkey application. This may lower the confidence that the models
would perform the same when evaluated on a real device with a real user.
Additionally, Cai [27] uses non-hardware features such as Method Calls for
their detection method. Our paper focuses on hardware features only. Our lower
performance may indicate that using hardware features only result in lower
overall performance. Saracino [20] uses a combination of hardware features and
non-hardware features (System Calls) for their detection methods. As mentioned
in Section 2, System Calls require root permissions which our detection method
does require. However, still the detection method by Saracino shows a higher
performance, indicating again that a combination of hardware and non-hardware
features may increase the performance of dynamic malware detectors.

#### Overall high false-negative rate

In this research, all detection methods showed relatively high FNR (F1 score
above 0.3). This implies that a high number of malicious actions are
undetected, and may have different causes. Many features in the feature set
are influenced by many factors, as the features describe devices that are
running multiple applications simultaneously. For instance, the priority, the
CPU allocation, and the memory allocation of the malware app depend on other
applications running parallel to it. Therefore, the features in the dataset do
not solely reflect the (type of) action of the malware app, but also the state
of the device at a given moment. This may result in excessive noise in the
sensed data. Another possible cause may the fact that the influences of
malicious and benign actions on the features sensed are similar, and
indistinguishable to the classifier.

##  6 Limitations

All detection methods in this research are created using the same dataset. The
limitations caused by using this particular dataset are listed below:

  1. 1.

All devices in the dataset are Samsung Galaxy S5. Therefore, it is unknown how
the models perform when used on other devices.

  2. 2.

All malware types in the dataset were written for the purpose of this
research. This limits the findings of the research due to two reasons. First:
before the malware probe sent any data to a server, the data was scrambled to
ensure the privacy of the volunteers. It is possible that this scrambling
influenced the features analysed in the research. As a result, our detection
models may be biased towards detecting scrambling actions, limiting its
efficacy on wild malware. Second, it is unknown whether real malware executes
the same way as custom malware. Although the behaviour of custom malware is
based on wild malware, its implementation may differ. It is therefore unknown
whether similar detection performance is to be expected on wild malware.

  3. 3.

The dataset contained a low number of data points for malware versions 4 and
6. This limits the conclusions drawn from their results.

  4. 4.

The dataset did not contain any information on the creation times of the
malware apps. Therefore, the sustainability metric, as mentioned in recent
works [41][42], could not be included in the analysis. The papers argue argue
that detection methods should be evaluated by taking creation time of apps
into considerations. They argue that detection methods should be trained on
older apps (e.g. 2018) and tested on newer apps (e.g. 2019). This way
detection methods are evaluated on their ability to detect unseen behaviour
from newer apps.

The detection methods of this research share characteristics that may limit
their performance or applicability. The limitations imposed by this are listed
below:

  1. 1.

All detection methods in this research are signature-based, i.e., identify
malware based on a pattern of behaviour. In this research, the signature of a
malicious action is a record of feature values from a some given feature set.
This signature may be different for other (wild) malware types. Therefore, it
is unknown whether similar performances are achieved on other (wild) malware
types or other versions of the same malware type.

  2. 2.

All detection methods in this research use RFCV as a feature-selection method.
This method allows for feature reduction but is a greedy-search strategy, so
may be sub-optimal.

  3. 3.

All detection methods using Apps features require data collection of all
applications running. In our research, we discarded data from other
applications, as we knew which application was malicious. However, in real-
life circumstances, the malware application is unknown. Therefore, although
Apps features show better performance than Global features, they are more
resource-intensive to monitor than Global features. A suggestion for this
issue is described in 8.

##  7 Conclusion

This research showed i) what machine-learning classifier is most suitable for
detecting Mobile Trojans, and ii) which aspects of a smartphone (features),
related to hardware, are most important in detecting Mobile Trojans. The
Random Forest classifier showed the highest performance in F1-score, compared
with AdaBoost and KNN, when one model is used that is trained on many types of
Mobile Trojans. This classifier achieves an F1-score of 0.73 with an FPR of
0.009 and an FNR of 0.380. Random Forest, AdaBoost and K-Nearest Neighbour
show high performances when separate models are trained on each type of Mobile
Trojan with an average F1-score above 0.72, FPR below 0.02 and FNR below 0.33.
Additionally, on 5 malware types (Spyware, Phishing, Ransomware, Privilege
Escalation, DOS) we show high performances (F1-score above 0.963 and FNR below
0.120) making these models relevant for future detection methods that need to
detect these malware types.

Multiple dynamic hardware feature sets are examined in this research, making a
distinction between global device features and features related to an
application. When using one model for the detection of multiple types of
Mobile Trojans, 10 app features related to the memory usage, process
information, and CPU usage of the app, are sufficient for detecting malicious
actions. Additionally, app features, in general, showed the best performance
for detecting 7 out of 10 malware versions, compared to global device
features.

Recent related work performed their research in lab-like environments with
models based on emulators, simulated user input, and/or short testing
durations. To create models that can detect mobile malware threats in real
life, we need models assessed on data of real devices rather than data of lab-
like environments. This research tried to fill this gap by using data of real
devices gathered over multiple years with malware based on real malware.

##  8 Future work

Some suggestion for future research are listed below:

  1. 1.

Focus on improving False Negative Rates as this research’s detection methods
show relatively high FNR. As Random Forest and AdaBoost showed relative high
performance, other (boosted) ensemble classifiers can be examined such as
GradientBoosting [43].

  2. 2.

Improve the performance of detection methods on new devices and device models
if new data becomes available.

  3. 3.

Improve dynamic detection methods by analysing real wild malware samples to
improve the efficacy of the methods on the detection of real malware to
overcome the limitation imposed by the use of self-written malware.

  4. 4.

Increase the sample size to improve the efficacy and applicability of the
methods. This research analysed 10 different samples of Mobile Trojans.

  5. 5.

Examine whether time series analysis may improve the detection methods. This
research’s detection methods analyse dynamic features by individually
assessing these values, without considering these value prior in time.
Therefore, the absolute values of features are analysed. With time series
analysis, relative values can be used which may improve the detection methods,
as is suggested by the results of [22].

  6. 6.

Optimize the resource requirements of detection methods using App features. As
described in Section 5, monitoring App features of all applications installed
on a device is resource-intensive. Research to decrease these resource
requirements is needed. A suggestion may be to only monitor applications that
require sensitive permissions, e.g. access to SD card or access to contacts,
as was implemented in the framework of [20].

  7. 7.

Improve proposed detection methods by taking sustainability as an additional
metric for detectors. Recent works [41][42] have argued that detection methods
should be evaluated by taking creation time of apps into considerations. They
argue that detection methods should be trained on older apps (e.g. 2018) and
tested on newer apps (e.g. 2019). This way detection methods are evaluated on
their ability to detect unseen behaviour from newer apps. The malware
applications of our research did not contain information on the creation time,
hence this could not be evaluated.

##  9 Acknowledgements

The authors would like to thank the Ben-Gurion University, for providing this
research’s dataset.

## References

  * [1] Dea.  Smartphone subscriptions worldwide 2016-2026.  2021\.  Accessed at: 2021-07.
  * [2] Kimberly Tam, Ali Feizollah, Nor Badrul Anuar, Rosli Salleh, and Lorenzo Cavallaro.  The evolution of Android malware and Android analysis techniques.  ACM Computing Surveys (CSUR), 49(4):76, 2017.
  * [3] Ping Yan and Zheng Yan.  A survey on dynamic mobile malware detection.  Software Quality Journal, pages 1–29, 2017.
  * [4] Yisroel Mirsky, Asaf Shabtai, Lior Rokach, Bracha Shapira, and Yuval Elovici.  Sherlock vs moriarty: A smartphone dataset for cybersecurity research.  In Proceedings of the 2016 ACM workshop on Artificial intelligence and security, pages 1–12. ACM, 2016.
  * [5] Google.  Android security 2016 year in review.  Technical report.  Accessed at: 2017-11.
  * [6] Kaspersky.  It threat evolution q1 2017.  Technical report.  Accessed at: 2017-11.
  * [7] Asaf Shabtai, Uri Kanonov, Yuval Elovici, Chanan Glezer, and Yael Weiss.  Andromaly: a behavioral malware detection framework for Android devices.  Journal of Intelligent Information Systems, 38(1):161–190, 2012\.
  * [8] Kevin Allix, Tegawendé F Bissyandé, Jacques Klein, and Yves Le Traon.  Androzoo: Collecting millions of Android apps for the research community.  In 2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR), pages 468–471. IEEE, 2016.
  * [9] Iker Burguera, Urko Zurutuza, and Simin Nadjm-Tehrani.  Crowdroid: behavior-based malware detection system for Android.  In Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices, pages 15–26. ACM, 2011.
  * [10] Daniel Arp, Michael Spreitzenbarth, Malte Hubner, Hugo Gascon, Konrad Rieck, and CERT Siemens.  DREBIN: Effective and explainable detection of Android malware in your pocket.  In NDSS, 2014.
  * [11] Malware genome project.  Accessed at: 2017-10.
  * [12] Open malware dataset.  Technical report.
  * [13] Virusshare.  Accessed at: 2017-10.
  * [14] Virustotal database.  Unaccessible at: 2017-10.
  * [15] B. Amos, H. Turner, and J. White.  Applying machine learning classifiers to dynamic Android malware detection at scale.  In 2013 9th International Wireless Communications and Mobile Computing Conference (IWCMC), pages 1666–1671, July 2013.
  * [16] M. S. Alam and S. T. Vuong.  Random Forest Classification for Detecting Android Malware.  In 2013 IEEE International Conference on Green Computing and Communications and IEEE Internet of Things and IEEE Cyber, Physical and Social Computing, pages 663–669, August 2013.
  * [17] Hyo-Sik Ham and Mi-Jung Choi.  Analysis of Android malware detection performance using machine learning classifiers.  In ICT Convergence (ICTC), 2013 International Conference on, pages 490–495. IEEE, 2013.
  * [18] A. E. Attar, R. Khatoun, and M. Lemercier.  A Gaussian mixture model for dynamic detection of abnormal behavior in smartphone applications.  In 2014 Global Information Infrastructure and Networking Symposium (GIIS), pages 1–6, September 2014.
  * [19] Bryan Dixon, Shivakant Mishra, and Jeannette Pepin.  Time and location power based malicious code detection techniques for smartphones.  In Network Computing and Applications (NCA), 2014 IEEE 13th International Symposium on, pages 261–268. IEEE, 2014.
  * [20] Andrea Saracino, Daniele Sgandurra, Gianluca Dini, and Fabio Martinelli.  MADAM: Effective and efficient behavior-based Android malware detection and prevention.  IEEE Transactions on Dependable and Secure Computing, 2016.
  * [21] L. Caviglione, M. Gaggero, J. F. Lalande, W. Mazurczyk, and M. Urbanski.  Seeing the Unseen: Revealing Mobile Malware Hidden Communications via Energy Consumption and Artificial Intelligence.  IEEE Transactions on Information Forensics and Security, 11(4):799–810, April 2016.
  * [22] Jelena Milosevic, Alberto Ferrante, and Miroslaw Malek.  Malaware: Effective and efficient run-time mobile malware detector.  In Dependable, Autonomic and Secure Computing, 14th Intl Conf on Pervasive Intelligence and Computing, 2nd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech), 2016 IEEE 14th Intl C, pages 270–277. IEEE, 2016.
  * [23] Alberto Ferrante, Eric Medvet, Francesco Mercaldo, Jelena Milosevic, and Corrado Aaron Visaggio.  Spotting the malicious moment: Characterizing malware behavior using dynamic features.  In Availability, Reliability and Security (ARES), 2016 11th International Conference on, pages 372–381. IEEE, 2016.
  * [24] Gerardo Canfora, Eric Medvet, Francesco Mercaldo, and Corrado Aaron Visaggio.  Acquiring and analyzing app metrics for effective mobile malware detection.  In Proceedings of the 2016 ACM on International Workshop on Security And Privacy Analytics, pages 50–57. ACM, 2016.
  * [25] L. Massarelli, L. Aniello, C. Ciccotelli, L. Querzoni, D. Ucci, and R. Baldoni.  Android malware family classification based on resource consumption over time.  In 2017 12th International Conference on Malicious and Unwanted Software (MALWARE), pages 31–38, 2017.
  * [26] Sarah Wassermann and Pedro Casas.  Bigmomal: Big data analytics for mobile malware detection.  In Proceedings of the 2018 Workshop on Traffic Measurements for Cybersecurity, pages 33–39. ACM, 2018.
  * [27] Haipeng Cai, Na Meng, Barbara Ryder, and Daphne Yao.  Droidcat: Effective Android malware detection and categorization via app-level profiling.  IEEE Transactions on Information Forensics and Security, 14(6):1455–1470, 2018.
  * [28] Alejandro Martín, Víctor Rodríguez-Fernández, and David Camacho.  CANDYMAN: Classifying Android malware families by modelling dynamic traces with markov chains.  Engineering Applications of Artificial Intelligence, 74:121–133, 2018.
  * [29] Yusheng Dai, Hui Li, Yekui Qian, Ruipeng Yang, and Min Zheng.  Smash: a malware detection method based on multi-feature ensemble learning.  IEEE Access, 7:112588–112597, 2019.
  * [30] L U Memon, N Z Bawany, and J A Shamsi.  A comparison of machine learning techniques for Android malware detection using apache spark.  Journal of Engineering Science and Technology, 14(3):1572–1586, 2019.
  * [31] Mohammed K Alzaylaee, Suleiman Y Yerima, and Sakir Sezer.  DL-Droid: Deep learning based Android malware detection using real devices.  Computers & Security, 89:101663, 2020.
  * [32] Gianluca Dini, Fabio Martinelli, Andrea Saracino, and Daniele Sgandurra.  MADAM: a multi-level anomaly detector for Android malware.  Computer network security, pages 240–253, 2012.
  * [33] Contagio.  Accessed at: 2017-10.
  * [34] Haipeng Cai and Barbara G Ryder.  A longitudinal study of application structure and behaviors in android.  IEEE Transactions on Software Engineering, 2020.
  * [35] Google funf framework.  Accessed at: 2020-05.
  * [36] Github sherlock.  Accessed at: 2020-05.
  * [37] Sumeet Dua and Xian Du.  Data mining and machine learning in cybersecurity.  CRC press, 2016.
  * [38] Auto-scaling sci-kit learn with apache spark.  Technical report.  Accessed at: 2018-07.
  * [39] F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Passos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay.  Scikit-learn: Machine learning in Python.  Journal of Machine Learning Research, 12:2825–2830, 2011.
  * [40] Thomas G Dietterich.  Approximate statistical tests for comparing supervised classification learning algorithms.  Neural computation, 10(7):1895–1923, 1998.
  * [41] HAIPENG CAI.  Assessing and improving malware detection sustainability through app evolution studies.  2019\.
  * [42] Lucky Onwuzurike, Enrico Mariconti, Panagiotis Andriotis, Emiliano De Cristofaro, Gordon Ross, and Gianluca Stringhini.  MaMaDroid: Detecting Android malware by building Markov chains of behavioral models (extended version).  ACM Transactions on Privacy and Security (TOPS), 22(2):1–34, 2019\.
  * [43] Jerome H Friedman.  Greedy function approximation: a gradient boosting machine.  Annals of statistics, pages 1189–1232, 2001.

##  10 Appendix

Table 13: All features in different feature sets (for the meaning of each
feature, see the documentation of the original dataset [4])

Global | Apps | Combined
---|---|---
userid | userid | Global plus Apps
uuid | uuid |
version | applicationname |
traffic_mobilerxbytes | cpu_usage |
traffic_mobilerxpackets | packagename |
traffic_mobiletxbytes | packageuid |
traffic_mobiletxpackets | uidrxbytes |
traffic_totalrxbytes | uidrxpackets |
traffic_totalrxpackets | uidtxbytes |
traffic_totaltxbytes | uidtxpackets |
traffic_totaltxpackets | cguest_time |
traffic_totalwifirxbytes | cmaj_flt |
traffic_totalwifirxpackets | cstime |
traffic_totalwifitxbytes | cutime |
traffic_totalwifitxpackets | dalvikprivatedirty |
traffic_timestamp | dalvikpss |
battery_charge_type | dalvikshareddirty |
battery_current_avg | guest_time |
battery_health | importance |
battery_icon_small | importancereasoncode |
battery_invalid_charger | importancereasonpid |
battery_level | lru |
battery_online | nativeprivatedirty |
battery_plugged | nativepss |
battery_present | nativeshareddirty |
battery_scale | num_threads |
battery_status | otherprivatedirty |
battery_technology | otherpss |
battery_temperature | othershareddirty |
battery_timestamp | pgid |
battery_voltage | pid |
cpuhertz | ppid |
cpu_0 | priority |
cpu_1 | rss |
cpu_2 | rsslim |
cpu_3 | sid |
total_cpu | start_time |
totalmemory_freesize | state |
totalmemory_max_size | stime |
totalmemory_total_size | tcomm |
totalmemory_used_size | utime |

Table 14: Features included in best performing Random Forest models
(classification target: all malware), ordered by decreasing feature importance
(for the meaning of each feature, see the documentation of the original
dataset [4])

Global | Apps | Combined
---|---|---
traffic_mobilerxbytes | cpu_usage_mor_app | dalvikprivatedirty_mor_app
traffic_mobiletxbytes | uidrxbytes_mor_app | dalvikpss_mor_app
traffic_mobiletxpackets | uidrxpackets_mor_app | importance_mor_app
traffic_totalrxbytes | uidtxbytes_mor_app | num_threads_mor_app
traffic_totalrxpackets | uidtxpackets_mor_app | otherprivatedirty_mor_app
traffic_totaltxbytes | cmaj_flt_mor_app | otherpss_mor_app
traffic_totaltxpackets | cstime_mor_app | rss_mor_app
traffic_totalwifirxbytes | dalvikprivatedirty_mor_app | stime_mor_app
traffic_totalwifitxbytes | dalvikpss_mor_app | utime_mor_app
traffic_totalwifitxpackets | dalvikshareddirty_mor_app | vsize_mor_app
battery_current_avg | importance_mor_app |
battery_icon_small | importancereasonpid_mor_app |
battery_level | lru_mor_app |
battery_temperature | nativeprivatedirty_mor_app |
battery_voltage | nativepss_mor_app |
cpu_0 | nativeshareddirty_mor_app |
cpu_1 | num_threads_mor_app |
cpu_2 | otherprivatedirty_mor_app |
cpu_3 | otherpss_mor_app |
total_cpu | othershareddirty_mor_app |
totalmemory_freesize | pgid_mor_app |
totalmemory_max_size | pid_mor_app |
totalmemory_total_size | ppid_mor_app |
totalmemory_used_size | priority_mor_app |
| rss_mor_app |
| start_time_mor_app |
| stime_mor_app |
| utime_mor_app |
| vsize_mor_app |

Table 15: Features included in best performing AdaBoost models (classification
target = all malware) ordered per feature importance (for the meaning of each
feature, see the documentation of the original dataset [4])

Global | Apps | Combined
---|---|---
totalmemory_total_size | rss_mor_app | rss_mor_app
totalmemory_used_size | utime_mor_app | utime_mor_app
battery_voltage | otherprivatedirty_mor_app | dalvikpss_mor_app
battery_temperature | dalvikprivatedirty_mor_app | otherprivatedirty_mor_app
traffic_totaltxbytes | importance_mor_app | importance_mor_app
total_cpu | otherpss_mor_app | otherpss_mor_app
totalmemory_freesize | dalvikpss_mor_app | dalvikprivatedirty_mor_app
traffic_totalrxbytes | num_threads_mor_app | num_threads_mor_app
battery_level | vsize_mor_app | vsize_mor_app
cpu_0 | stime_mor_app | stime_mor_app
traffic_totaltxpackets | dalvikshareddirty_mor_app | traffic_totalrxbytes
cpu_2 | cpu_usage_mor_app | dalvikshareddirty_mor_app
cpu_3 | uidtxbytes_mor_app | totalmemory_used_size
traffic_totalwifitxbytes | othershareddirty_mor_app | cpu_usage_mor_app
battery_current_avg | start_time_mor_app | othershareddirty_mor_app
traffic_totalrxpackets | pid_mor_app | total_cpu
cpu_1 | uidrxbytes_mor_app | uidtxbytes_mor_app
traffic_mobilerxbytes | pgid_mor_app | totalmemory_freesize
traffic_totalwifirxbytes | lru_mor_app | traffic_totaltxbytes
traffic_mobiletxbytes | uidtxpackets_mor_app | start_time_mor_app
totalmemory_max_size | ppid_mor_app | battery_voltage
traffic_totalwifitxpackets | nativeprivatedirty_mor_app | totalmemory_total_size
battery_icon_small | priority_mor_app | battery_temperature
traffic_mobiletxpackets | uidrxpackets_mor_app | pid_mor_app
traffic_totalwifirxpackets | cstime_mor_app | uidrxbytes_mor_app
traffic_mobilerxpackets |  | ppid_mor_app
|  | battery_level
|  | cpu_0
|  | totalmemory_max_size
|  | traffic_totalwifitxbytes
|  | traffic_totaltxpackets
|  | cpu_2
|  | cpu_3
|  | lru_mor_app
|  | uidtxpackets_mor_app
|  | nativeprivatedirty_mor_app
|  | priority_mor_app
|  | cpu_1
|  | traffic_totalrxpackets
|  | pgid_mor_app
|  | traffic_mobiletxbytes
|  | cstime_mor_app
|  | traffic_totalwifirxbytes

Table 16: Features included in best performing KNN models (classification
target = all malware) ordered per feature importance (for the meaning of each
feature, see the documentation of the original dataset [4])

Global | Apps | Combined
---|---|---
totalmemory_total_size | rss_mor_app | rss_mor_app
totalmemory_used_size | utime_mor_app | utime_mor_app
battery_voltage | otherprivatedirty_mor_app | dalvikpss_mor_app
battery_temperature | dalvikprivatedirty_mor_app | otherprivatedirty_mor_app
traffic_totaltxbytes | importance_mor_app | importance_mor_app
total_cpu | otherpss_mor_app | otherpss_mor_app
totalmemory_freesize | dalvikpss_mor_app | dalvikprivatedirty_mor_app
traffic_totalrxbytes | num_threads_mor_app | num_threads_mor_app
battery_level | vsize_mor_app | vsize_mor_app
cpu_0 | stime_mor_app |
traffic_totaltxpackets | dalvikshareddirty_mor_app |
cpu_2 | cpu_usage_mor_app |
cpu_3 | uidtxbytes_mor_app |
traffic_totalwifitxbytes |  |
battery_current_avg |  |
traffic_totalrxpackets |  |
cpu_1 |  |
traffic_mobilerxbytes |  |
traffic_totalwifirxbytes |  |
traffic_mobiletxbytes |  |
totalmemory_max_size |  |
traffic_totalwifitxpackets |  |
battery_icon_small |  |
traffic_mobiletxpackets |  |
traffic_totalwifirxpackets |  |
traffic_mobilerxpackets |  |

Table 17: All features and their feature category (part 1 of 2; for the
meaning of each feature, see the documentation of the original dataset [4])

Feature | Category
---|---
cguest_time | App_CPU
cpu_usage | App_CPU
cstime | App_CPU
cutime | App_CPU
guest_time | App_CPU
Itrealvalue | App_CPU
nice | App_CPU
num_threads | App_CPU
priority | App_CPU
Processor | App_CPU
rt_priority | App_CPU
stime | App_CPU
utime | App_CPU
packagename | App_Info
packageuid | App_Info
version_code | App_Info
version_name | App_Info
cmaj_flt | App_Memory
cminflt | App_Memory
dalvikprivatedirty | App_Memory
dalvikpss | App_Memory
dalvikshareddirty | App_Memory
lru | App_Memory
majflt | App_Memory
minflt | App_Memory
nativeprivatedirty | App_Memory
nativepss | App_Memory
nativeshareddirty | App_Memory
otherprivatedirty | App_Memory
otherpss | App_Memory
othershareddirty | App_Memory
rss | App_Memory
rsslim | App_Memory
vsize | App_Memory
uidrxbytes | App_Network
uidrxpackets | App_Network
uidtxbytes | App_Network
uidtxpackets | App_Network
endcode | App_Process
exit_signal | App_Process
Flags | App_Process
importance | App_Process
importancereasoncode | App_Process
importancereasonpid | App_Process
pgid | App_Process
pid | App_Process

Feature | Category
---|---
ppid | App_Process
sid | App_Process
start_time | App_Process
startcode | App_Process
state | App_Process
tcomm | App_Process
tgpid | App_Process
Wchan | App_Process
battery_charge_type | Battery
battery_current_avg | Battery
battery_health | Battery
battery_icon_small | Battery
battery_invalid_charger | Battery
battery_level | Battery
battery_online | Battery
battery_plugged | Battery
battery_present | Battery
battery_scale | Battery
battery_status | Battery
battery_technology | Battery
battery_temperature | Battery
battery_timestamp | Battery
battery_voltage | Battery
btime | CPU
cpu_0 | CPU
cpu_1 | CPU
cpu_2 | CPU
cpu_3 | CPU
cpuhertz | CPU
ctxt | CPU
processes | CPU
procs_blocked | CPU
procs_running | CPU
tot_idle | CPU
tot_iowait | CPU
tot_irq | CPU
tot_nice | CPU
tot_softirq | CPU
tot_system | CPU
tot_user | CPU
total_cpu | CPU
companion_cpu0 | IO Interrupts
companion_sum_cpu123 | IO Interrupts
cpu123_intr_prs | IO Interrupts
cypress_touchkey_cpu0 | IO Interrupts
cypress_touchkey_sum_cpu123 | IO Interrupts

Table 18: All features and their feature category (part 2 of 2, for the
meaning of each feature, see the documentation of the original dataset [4])

Feature | Category
---|---
flip_cover_cpu0 | IO Interrupts
flip_cover_sum_cpu123 | IO Interrupts
function_call_interrupts_cpu0 | IO Interrupts
function_call_interrupts_sum_cpu123 | IO Interrupts
home_key_cpu0 | IO Interrupts
home_key_sum_cpu123 | IO Interrupts
msmgpio_cpu0 | IO Interrupts
msmgpio_sum_cpu123 | IO Interrupts
pn547_cpu0 | IO Interrupts
pn547_sum_cpu123 | IO Interrupts
sec_headset_detect_cpu0 | IO Interrupts
sec_headset_detect_sum_cpu123 | IO Interrupts
slimbus_cpu0 | IO Interrupts
slimbus_sum_cpu123 | IO Interrupts
synaptics_rmi4_i2c_cpu0 | IO Interrupts
synaptics_rmi4_i2c_sum_cpu123 | IO Interrupts
volume_down_cpu0 | IO Interrupts
volume_down_sum_cpu123 | IO Interrupts
volume_up_cpu0 | IO Interrupts
volume_up_sum_cpu123 | IO Interrupts
wcd9xxx_cpu0 | IO Interrupts
wcd9xxx_sum_cpu123 | IO Interrupts
active | Memory
active_anon | Memory
active_file | Memory
anonpages | Memory
buffers | Memory
cached | Memory
commitlimit | Memory
committed_as | Memory
dirty | Memory
highfree | Memory
hightotal | Memory
inactive | Memory
inactive_anon | Memory
inactive_file | Memory
kernelstack | Memory
lowfree | Memory
lowtotal | Memory
mapped | Memory
Memfree | Memory
memtotal | Memory
mlocked | Memory
pagetables | Memory
shmem | Memory
slab | Memory

Feature | Category
---|---
sreclaimable | Memory
sunreclaim | Memory
swapcached | Memory
swapfree | Memory
swaptotal | Memory
totalmemory_freesize | Memory
totalmemory_max_size | Memory
totalmemory_total_size | Memory
totalmemory_used_size | Memory
unevictable | Memory
vmallocchunk | Memory
vmalloctotal | Memory
vmallocused | Memory
writeback | Memory
applicationname | Metadata
sherlock_version | Metadata
userid | Metadata
uuid | Metadata
traffic_mobilerxpackets | Network
traffic_mobiletxbytes | Network
traffic_mobiletxpackets | Network
traffic_timestamp | Network
traffic_totalrxbytes | Network
traffic_totalrxpackets | Network
traffic_totaltxbytes | Network
traffic_totaltxpackets | Network
traffic_totalwifirxbytes | Network
traffic_totalwifirxpackets | Network
traffic_totalwifitxbytes | Network
traffic_totalwifitxpackets | Network
external_availableblocks | Storage
external_availablebytes | Storage
external_blockcount | Storage
external_blocksize | Storage
external_freeblocks | Storage
external_freebytes | Storage
external_totalbytes | Storage
internal_availableblocks | Storage
internal_availablebytes | Storage
internal_blockcount | Storage
internal_blocksize | Storage
internal_freeblocks | Storage
internal_freebytes | Storage
internal_totalbytes | Storage
connectedwifi_level | Wifi
connectedwifi_ssid | Wifi