Using Network Traffic to Remotely Identify the
Type of Applications Executing on Mobile Devices
Lanier Watkins, Cherita Corbett, Benjamin Salazar, and Kevin Fairbanks
Johns Hopkins University Applied Physics Laboratory
Laurel, MD USA
Abstract—In an effort to ultimately develop a network-based
mobile device resource monitor, we demonstrate the feasibility of
remotely detecting the types of applications (i.e., CPU intensive,
I/O intensive or non-CPU intensive) actively executing on a
mobile device. The distinguishing characteristic of this method is
its uncanny ability to remotely infer the types of applications
executing on a mobile device when there is no native network
traffic being generated from it. To do this, we inconspicuously
solicit network traffic from the mobile device by pinging it. Then
we capture the timestamps of the ICMP replies, calculate the
average inter-packet spacing, and finally use a Neural-Fuzzy
Classifier (NFC) that has been previously trained on CPU
intensive, I/O intensive, and non-CPU intensive correlated
network traffic to discern between the three application types.
The NFC acts as a dynamic threshold by grouping the training
patterns into clusters and uses these clusters to create
membership functions to separate future patterns of each type.
We evaluate several Android and Apple devices, and we show
that our approach is feasible for Android mobile devices. The key
to this method is CPU throttling (when the on-demand governor
is used), which scales the CPU performance according to the
needs of the presently executing applications in an effort to save
power. We exploit CPU throttling to extract embedded delays
from solicited ICMP network traffic. Our results show that our
method is at least 95% effective in remotely detecting the types of
applications executing on Android mobile device.
Keywords—Android, mobile devices,
forensics, application fingerprinting
security,
network
I. INTRODUCTION
Enterprises have recognized that mobile devices are here to
stay, so they must determine new and better methods of
managing their security; otherwise, mobile device security
concerns will overwhelm the security staff and thus leave little
or no time to address the security concerns of the rest of the
enterprise network. This paper investigates the feasibility of
developing a network-based mobile device resource monitor
by empirically demonstrating that the type of application
executing on a mobile device can be inferred by simply
pinging the device. Such a network-based tool can be used to
ascertain initial information about a mobile device that is
actively connected to the network, but is not natively
generating any network traffic. In such a scenario, host-based
methods would normally be used to provide detailed
information about the processes executing on a remote device,
but since a precedent of circumventing anti-virus software has
been set [1], it is conceivable that any information garnered
for any host-based tool may be spoofed.
In [2], it was shown that the passive inference of CPU usage
William H. Robinson
Vanderbilt University
Nashville, TN
in wireline general-purpose nodes can be used to create a
resource monitor. In this paper the authors venture to extend
this logic to the realm of mobile devices. The key here is the
extraction of delays embedded into network traffic due to CPU
throttling. Specifically, when the on-demand governor is used,
Android based mobile devices throttle the CPU in an attempt
to lower power consumption [3]. This gives us a direct
relationship between the state of hardware (i.e., CPU) and the
applications running on the device. We demonstrate that this
relationship is detectable in network traffic generated from
Android devices. In our case, we analyze ICMP network
traffic which we solicit from the mobile device by pinging it.
The capability to remotely infer the type of application
executing on a mobile device has many applications. For
instance, this capability can be used as an initial step in
application white/black listing for specific situations where the
mobile device produces no network traffic. This fills a
monitoring void which cannot be filled by a traditional
intrusion detection system (IDS) like Snort or a web proxy
like Squid (because there is no natively generated network
traffic). A host-based system like Mobile device managers
(MDMs) could functionally fill this void; however, as stated
previously, a precedent of circumventing anti-virus software
has been set, so it is conceivable that host-based monitoring
tools may be ineffective. Also, their maintenance can be time
consuming since each device must have software installed on
it and constantly updated and patched. Another application of
this capability could be to develop an anomaly detection tool
which learns the application usage pattern of users and alerts
when this pattern changes. Again, this tool would be most
effective in situations where the mobile device is executing
applications that produce no native network traffic. Such a
tool could determine when a user’s mobile device executes
more or less of a specific type of application over a certain
time period which may indicate anomalous behavior.
The contributions of our work are three-fold: (1) the method
is network-based and thus does not require any software to be
installed on each mobile device, (2) we evaluate mobile
devices from multiple vendors and identify specific and
exploitable vendor traits, and (3) the method can be used to
remotely identify the types of applications (i.e., CPU
intensive, I/O intensive or non-CPU intensive) executing on
mobile devices.
Our paper is organized into the following sections. In
Section II we list the assumptions used and the limitations of
our work. In Section III, we discuss related works. In Section
IV, we discuss the categories of applications that we consider
in this paper. While in Section V, we briefly discuss the power
management differences between Android and Apple iOS
based devices, and Section VI mentions the high-level
architecture of the Android operating system (OS). In Section
VII, we illustrate the restricted modes of operation for
Android devices that would mesh well with our method. In
Section VIII, the experimental setup and procedures used in
this paper are detailed in the experimental evaluation. Finally,
in Section IX we summarize the paper and mention future
work.
II. ASSUMPTIONS AND LIMITATIONS
The intent of this paper is to provide the details of information
leakage that exists within Android-based mobile devices.
These devices can be continuously monitored to obtain
information about the applications executing on them when it
is not natively generating any network traffic. In an effort to
focus on the core details of this method, several assumptions
were made. We assumed that: (1) only one application was
executing on the mobile device at a time, (2) there was
excellent WiFi signal strength, (3) there was no user
interaction, (4) there are only three broad types of applications
(Section IV), and (5) pinging the mobile devices do not
negatively affect the network or the mobile device. The key
challenge addressed in our work (i.e., remotely determining
the processes executing on a mobile device when no native
traffic is being generated) is non-trivial; thus, these
assumptions were made to allow the core details of this
method to be demonstrable.
Also, we have investigated the inability of our method to
extract information from the network traffic of Apple iOS
devices. The primary reason our method does not work for
Apple devices is the lack of the use of CPU throttling in these
devices; however, there may be some other way to extract
similar information from these devices. We will further
investigate Apple devices in future work. This limitation is
countered by the overwhelming market share of Android
devices.
III. RELATED WORK
To our knowledge, there is very little directly related work
(i.e., remote CPU load inference in mobile devices). The
previous work in remote CPU load and memory load inference
in wireline networks is the best recent sources of related
works. The only other works remotely related to identifying
non-network traffic generating applications executing on
mobile devices would be MDMs. In reality, these works are
only tangentially related, because they are host-based as
opposed to the network-based nature of our method.
A. Passive Inference of CPU and Memory Load
Previous work [2][5] developed a method that correlates
network traffic with the state of the hardware that generated
the network traffic. In short, network traffic inter-packet
spacing (IPS) was used to measure the delays induced into
network traffic due to heavy node CPU or memory utilization.
In the previous work, the hardware states were binary, either
available or unavailable CPU or memory. Similarly, in this
paper we detect CPU states (i.e., speed), but as related to the
type of application executing on the device. Also, empirical
data from the passive inference related work suggests that the
origins of the delays induced into network traffic were excess
context switching for heavy CPU utilization and excessive
paging for heavy memory utilization. Whereas in this body of
work, the delays have their origin in CPU throttling and the
preemption of processes that access the secure digital (SD)
card.
B. Mobile Device Management (MDM) Software
There are several MDM vendors such as Airwatch [6],
Good [7], and MobileIron [8] that are attempting to capitalize
on the adoption of mobile devices for normal business usage.
Even security companies such as Symantec [9] are entering
the realm of mobile device management.
These solutions generally function by installing a
proprietary application on the device that communicates with
the MDM server(s). This architecture allows a MDM to
install profiles on a device as well as provide web based
management portals that are used to remotely access the
device for monitoring, management, configuring, application
inventory, or even remote wiping. The
main
difference
between these vendors is the range of mobile devices
supported. For instance, Airwatch supports Blackberry and
Good does not. Symantec differentiates itself by leveraging its
experience in the security realm.
These host-based MDM solutions provide remote access
into mobile devices; however, they carry with them the down
side of host-based tools. For instance, software is required to
be downloaded onto each device. This creates a maintenance
issue as well as a security issue because each device will need
to download the most current version of the MDM application
for updates. If the MDM application is compromised, then
compliance with the policy and thereby overall security of the
device and any data sent to it cannot be guaranteed. It is
entirely possible to compromise a flaw in the MDM
application and install unauthorized and potentially dangerous
applications through unapproved channels. These issues can
be mitigated by using a purely network-based method;
unfortunately, to our knowledge, none exist. Currently, our
method does not provide the functionality of the abovementioned MDMs, but we believe that our method is a step in
the right direction.
IV. TYPES OF APPLICATIONS
An application can generally be categorized by the resource
that is its limiting factor. For example, a CPU intensive
application is limited by the speed at which calculations can
be completed. I/O intensive applications are limited by the
speed at which data can be transferred to and from the source
media, for our work this is the SD card. In theory, the CPU
does have a role in an I/O process, namely setting up DMA
and parsing large files into smaller blocks for copying data.
Non-CPU intensive applications are characterized by the fact
that they require little CPU time. Finally, a memory intensive
application is limited by the amount and speed of memory that
is available for the process to use. In Android based mobile
devices, memory is a very important resource, and when this
resource is sparse all non-essential applications will be killed
to correct this problem [10]. Therefore, we will not focus
specifically on memory intensive applications. In fact, in this
paper we only consider scenarios where there is only one
application executing on the mobile device so as to avoid low
memory situations affecting the behavior of the device and
thus our experiments. This is another scenario that we will
further investigate in future work.
There are many applications that fall into these three
categories, (i.e., CPU intensive, non-CPU intensive and IO
intensive) but to demonstrate the capabilities of our method,
we chose to only investigate 6 applications. This method is
feasible because the applications in each of these categories
use the resources in a mobile device in different ways. CPU
intensive application have assembly language instructions that
create processes that heavily utilize the CPU, while non-CPU
intensive applications have instructions that create processes
that require significantly less CPU time. Finally, I/O intensive
applications have instructions that create processes that
continuously require I/O resources. Each of these types of
applications affect the mobile device’s schedulers (i.e., CPU
and I/O), CPU and main memory (we do not consider memory
intensive applications) in a different way. The CPU scheduler
in the Android devices of interest is the current Linux 2.6
scheduler, the completely fair scheduler (CFS) [11]. It ensures
that each process uses the resources in the mobile device as
fairly as possible relative to the priority of the process. Since
I/O intensive processes typically spend a lot of time waiting
on I/O resources, the CFS scheduler gives them a higher
priority. The I/O scheduler in the Android devices of interest
is the Noop scheduler which is a simple first-in first-out queue
with request merging ability. This I/O scheduler is best for
flash based devices [12]. CPU intensive applications will fill
the scheduler with processes that require CPU time while nonCPU intensive applications will have very few processes
waiting on the CPU. In contrast, I/O intensive applications
will have processes in the CPU scheduler that cannot even
access the CPU until after they gain access to I/O resources.
For I/O intensive processes, delays due to waiting on
processes to release I/O resources dominates even CPU
throttling when the device has an external (i.e., removable) SD
Card.
In our experiments, 6 applications from Google Play were
used. The ZArchiver and AppMgr III are I/O intensive
applications. The ZArchiver application among other things
allows a user to zip up directories on the SD card, and the
AppMgr III among other things allows a user to move
applications from internal memory to the SD card. The Star
Wars Angry Birds and Temple Run 2 games are both CPU
intensive applications. Finally, the Android Music player and
the Adobe PDF reader are both non-CPU intensive
applications.
V. MOBILE DEVICE POWER MANAGEMENT
One of the most important resources in a mobile device is its
battery life (i.e., power). Therefore, one of the most important
activities within a mobile device is its power management
system. We consider the power management system of the
Android (largest market share) 2.2.x and above OS and the
Apple 4.2.x and above iOS (most popular) [17].
The underlying theme of the Android OS 2.2.x is that the
CPU should use no power if it is doing no work. The
Android’s power management system is mostly equivalent to
the Linux power management system. Specifically, our main
power save functionality of interest is CPU scaling or CPU
throttling. This power-saving functionality lowers power
consumption by throttling the CPU relative to the needs of the
device. There are several mechanisms that facilitate this
process. First there is a governor that determines the CPU
needs of the executing application. Then there is a driver that
moves the current CPU frequency to the desired value [3].
This can be referred to as CPU throttling or CPU frequency
scaling. General techniques for CPU frequency scaling can be
found in [18]. In an Android device, CPU throttling is based
on the needs of the foreground process and all running
background processes. The number of processes allowed to
execute in the background depends on the amount of free
memory in the mobile device, and the order in which
processes are killed (to free up memory) depends on the
relative priority of the process [10]. The default governor used
in most Android devices is called the on-demand governor.
This is the governor used in the experiments in this paper.
There are several important variables that support this
governor. The maximum allowed CPU speed is stored in a
variable called CPUmax. The minimum allowed CPU speed is
stored in a variable called CPUmin. There is a variable called
up_threshold which contains the maximum CPU load
percentage allowable before the governor scales the CPU load
up to the next level, and finally the sampling_rate variable
contains the rate at which the governor samples the present
CPU load. All of these variables [12] are used by the ondemand governor to manage the CPU speed such that the
impact to the power source is minimized. Specifically, the ondemand governor keeps the CPU speed at CPUmin when the
mobile device is not executing any user-space applications,
and as soon as the smallest user-space application is run, it
immediately forces the CPU speed to CPUmax then it
immediately starts to drop the CPU speed until just before
up_threshold CPU load is exceeded. In other words, the ondemand governor scales the current CPU speed such that the
up_threshold CPU load for the current CPU speed is never
exceeded. This occurs until CPUmax is reached. Because of
this, we define the CPU speed for CPU intensive and nonCPU intensive by the below equations 1 and 2 respectively.
The CPU speed for I/O intensive applications is defined
empirically in Section VII. Essentially, these applications have
an average CPU speed very close to that of CPU intensive
applications.
CPU Intensive >= (up_threshold) x (CPUmax)
Non-CPU Intensive < CPU Intensive
(1)
(2)
The Apple iOS works a little differently; part of its
approach to power management includes only allowing seven
applications to run in the background. Other applications are
Mode 0: Idle
- Display: On/Off
- CPU: CPUmin
- Wireless: On
Mode 1: User Interaction
- Display: On
- CPU: > CPUmin, <= CPUmax
- Wireless: On
Mode 2: Active
- Display: On/Off
- CPU: > CPUmin, <= CPUmax
- Wireless: On
Figure 1. Mobile device modes
paused if pushed to the background, and optimized such that
large processing jobs are spread out as much as possible [13].
To our knowledge, iOS 4.2.x and above does not support CPU
throttling nor does it support multi-tasking for third party
applications; therefore, we do not expect to be able to
immediately extract information from iOS 4.2.x network
traffic.
VI. THE ANDROID OPERATING SYSTEM AND
NETWORK TRAFFIC
The Android operating system (OS) is a software stack of
different layers. Of primary importance to us is the kernel
layer which is essentially Linux 2.6. Having said that, a brief
discussion of the mechanisms that are responsible for causing
the detectable delays in the network traffic IPS are as follows:
(1) when the mobile device receives an ICMP request an
interrupt is created, and the process that has access to the CPU
is preempted, its context is stored, and the interrupt is handled,
(2) then the ICMP requests are responded to with ICMP
replies by kernel-space assembly language subroutines, (3)
finally these subroutines are processed faster or slower based
on the speed at which the CPU was at while handling the
preempted process. The mobile device’s current CPU speed
affects the IPS of the network traffic emitted (i.e., ICMP
replies) from the device while CPU intensive or non-CPU
intensive applications are executing on the device. When I/O
intensive applications are executing on the device, its
processes can delay the kernel-space generated ICMP replies.
We believe that this delay results from the time it takes to
preempt I/O processes that have use of the CPU and are
accessing the SD Card. Our empirical data supports the above
mentioned theory. Specifically, the IPS of ICMP replies
emitted from an Android device running a non-CPU intensive
application is much larger than the IPS of ICMP replies from
the same device running a CPU intensive application. Further,
the IPS of ICMP replies emitted from an Android device
running an I/O intensive application can be even larger than
the IPS of ICMP replies from the same device running a nonCPU intensive application if the I/O processes access an
external SD Card. Because of this observable behavior, we are
able to remotely identify types of applications running on
mobile Android devices.
VII. ANDROID MOBILE DEVICE MODES OF
OPERATION
To address the challenge of remotely determining the
processes executing on a mobile device when no native traffic
is being generated, we discuss the mobile device in terms of a
restricted model with only three modes of operation (i.e.,
Mode 0, Mode 1 or Mode 2). Figure 1 illustrates these 3
modes of operation. Naturally the device could start off in any
of the 3 modes, but for clarity of explanation we will discuss
the modes in order. In Mode 0, the device would either have
its display turned on or off, its CPU would be in the CPU min
state, and its wireless adapter would be turned on. Real world
examples of this mode would be situations where the device is
charging or idle. From here the device could move into Mode
1 or Mode 2. In Mode 1, the device’s display is on, its CPU
can be at CPUmin, CPUmax, or somewhere between, and its
wireless adapter is turned on. Most importantly, the user
interacts with the device’s screen such that the device is
disturbed in some way, either engaging its gyroscope or
activating and using an application. The effect of engaging the
gyroscope, or starting an application or interacting with the
screen results in sharp spikes in the CPU speed (i.e., CPU
moving from CPUmin to CPUmax and then back down). On the
other-hand, the effect of a user interacting with a CPU
intensive application is negligible, because this type of
application forces the CPU to be in the CPUmax state anyway.
Finally, in Mode 2 the device’s display may either be on or
off, its CPU can be at CPUmin, CPUmax, or somewhere
between, and its wireless adapter is turned on. In this mode the
device may execute an application with its display on and over
time its display may shut off, but the application continues to
execute. Real world examples are music players, video
players, unattended games, CPU benchmarks, or virus
scanners. In this paper we only consider Modes 0 and 2.
Investigating the effects of the user’s interaction on the
average IPS of the network traffic emitted from the mobile
device is out of the scope of this paper, because our goal in
this paper is to simply demonstrate the feasibility of our
method. We will consider the effects of user interaction on the
average IPS of mobile device network traffic in future work.
VIII. EXPERIMENTAL EVALUATION
Our experimental procedure is broken up into three parts. In
Part I, we use benchmark apps to test the premise of our idea.
That is, can we remotely observe a difference in the average
IPS when the CPU speed is near CPUmin versus being near
CPUmax.We also test the applicability of this idea to Apple iOS
systems. In Part II, we measure locally on the mobile device
the CPU speeds of the 6 applications we have chosen to
classify. In Part III, we apply the Neural Fuzzy Classifier
(NFC) [14] to remotely classify the 6 applications.
A. Part I: Feasibility Analysis
In Part I, our goal is to investigate if we can remotely infer the
CPU speed of mobile devices by analyzing network traffic.
We do this by testing to see if we can discern nearly idle
mobile devices (i.e., CPU speed = CPUmin) from heavily
loaded mobile devices (i.e., CPU speed = CPU max). We
examine the robustness of the method by testing across 4
Figure 2. Experimental Set-Up (Part I and III)
Figure 4. Kyros Android Tablet Experiments.
Figure 3. Nexus S Google Phone Experiments.
Figure 5. iPhone 3G Experiments.
devices:
850 MHz Apple iPhone 3GS,
1 GHz Apple iPad I,
1 GHz Google Nexus S smartphone, and
800 MHz Colby Kyros tablet.
Both Apple products use the Apple iOS 4.x OS, the Nexus
S smartphone uses Android 4.1.x, and the Colby Kyros tablet
uses the Android 2.2.x OS. The CPU Benchmark application
[15] is used to create a heavy CPU load on Android devices,
and the Linpak application [16] was used to create a heavy
CPU load on Apple devices. A Dell Latitude D600 laptop is
used to ping the mobile devices as well as to monitor network
traffic. We use the standard ping application (i.e., ping –i 0.1
<ipaddress>) to induce network packets (i.e., ICMP replies)
from the mobile devices. The tcpdump application is used to
collect the ICMP replies with timestamps. Each wireless
device connects to an 802.11g (54 Mbps) wireless access point
(AP) that has a built in 100 Mbps switch. The laptop connects
to the wireless router via Ethernet. Figure 2 illustrates the
setup. For each device while it is heavily loaded and while it is
nearly idle, we (a) ping the device 100 times from the monitor
node, (b) collect the resulting 100 ICMP reply timestamps,
and (c) calculate the average inter-packet spacing (IPS). We
repeat this procedure 100 times; thus the result is 100
experiments for each case (i.e., 200 experiments, 100 for
nearly idle case and 100 for heavily loaded case).
In Figures 3 and 4 it is clear that Android devices executing
CPU intensive applications can be discerned from a nearly idle
CPU, while Figure 5 illustrates that no such separation can be
achieved for the iPhone device. The same behavior is
exhibited for the iPad and to save space we omitted it. The
main reason for the difference is the absence of CPU
throttling in Apple devices. When an Android device is not
executing any applications, its CPU frequency is forced to a
low state. Conversely, when an Android device is executing a
CPU intensive application its CPU frequency is forced to a
high state. When an interrupt occurs to respond to an ICMP
request, the CPU or non-CPU intensive processes get
preempted and the kernel-space subroutines that send ICMP
replies get executed at the existing CPU speed of the
preempted process. This is evidenced by the IPS of network
traffic incident from the mobile device being smaller when the
device is executing CPU intensive applications and larger
when the device is executing non-CPU intensive applications.
The behavior occurs consistently, thus a correlation is
assumed. For these two types of processes, there is a small
delay due to context switching, but based on empirical
evidence, CPU throttling is the dominate effect (thus the
inverse relationship between network traffic IPS and CPU
speed).
B. Part II: Effects of User Applications on CPU Speed
In Part II, we quantitatively measure the mobile device’s
CPU speed locally while it executes a user application. This
provides ground-truth to verify our results when we classify
the applications using our remote technique in Part III. Rather
than using the benchmarking applications above, we have
chosen 6 user applications from Google Play. The ZArchiver
and AppMgr III are I/O intensive applications. The ZArchiver
application allows a user to zip up directories on the SD card,
and the AppMgr III allows a user to move applications from
internal memory to the SD card. The Star Wars Angry Birds
and Temple Run 2 games are both CPU intensive applications.
Figure 6. Experimental Setup (Part II)
Table 1. CPU Speed Comparison for 6 HTC Applications
User Applications
CPU Speed
Min
Max
Average
NonCPU
Intensive
Adobe Reader
245MHz
1GHz
260MHz
Music Player
245MHz
245MHz
245MHz
CPU
Intensive
Angry Birds
1GHz
1GHz
1GHz
Temple Run
1GHz
1GHz
1GHz
ZArchiver
245MHz
1GHz
935MHz
AppMgr III
245MHz
1GHz
858MHz
I/O
Intensive
Figure 7. HTC PDF Of CPU Speeds
Figure 8. HTC Experiments Dataset #1.
Finally, the Android Music player and the Adobe PDF
reader are both non-CPU intensive applications. A 1 GHz
Android-based HTC Incredible S is used for these
experiments. The HTC uses the on-demand governor, and its
CPUmin = 245 MHz, CPUmax = 1 GHz, up_threshold is 95%
and the sample_rate is 2 microseconds. Per equation 1, we
define CPU intensive applications as requiring a CPU speed of
950 MHz or greater. Similarly, applications which require a
CPU speed less than 950 MHz are considered non-CPU
intensive. In this setup we connect the HTC via the mirco
USB port directly to the Dell laptop which is running the
Android SDK (See Figure 6). The laptop allows us to capture
the current CPU frequency of the mobile device using the adb
shell to access the cpuinfo_cur_freq file. We execute an ash
shell script that allows us to extract the current CPU speed
every second. We capture the CPU speed every second for 1
minute while the HTC is executing each of the 6 applications,
and we calculate the min, max, and average CPU speed. Also
note that we observed the CPU speed while the HTC was
being pinged and while there was no pinging, and there was
no noticeable difference in the average CPU speed.
The results are shown in Table 1 and Figure 7. These results
confirm that CPU intensive applications actually cause the
mobile device’s CPU speed to jump to CPUmax, and between
CPUmax and CPUmin for non-CPU intensive applications. Also,
in Figure 7 the PDF shows the majority of the values for CPU
intensive applications to be at the smaller end of the graph
while the non-CPU intensive values are at the larger end of the
graph. Surprisingly, the average CPU speed for I/O intensive
applications is close to that of CPU intensive applications, so
naturally, its values will appear at both ends of the graph in
Figure 7.
C. Part III: Remotely Identifying User Application Type
In Part III, we demonstrate that our method is capable of
remotely discerning between three different types of
applications: CPU intensive, I/O intensive, and non-CPU
intensive. We apply our method to the six user apps described
in Part II. We continue to use the HTC Incredible S
smartphone, but we also add in the Google Nexus S
smartphone for these experiments. We use the same
experimental setup depicted in Part I (Figure 2). We use the
monitor node to ping the mobile device 100 times while it
executes one of the six user apps. We capture the 100 ICMP
replies and calculate the average IPS. To be clear, we perform
each experiment 100 times for each application. Then we use
the first 300 experiments (50 experiments per application) to
train a Neural-Fuzzy Classifier (NFC). The NFC creates fuzzy
membership functions which bind the training sets such that
the root mean squared error (RMSE) of the correctly classified
training patterns is a minimum. We then used the NFC to
identify the remaining 300 experiments (i.e., 50 experiments
per application).
Figures 8 and 9 plots (Log was used so all data would fit on
axis) the average IPS across all experiments for HTC and
Figures 8 and 9 yield the same information for the Nexus,
where experiments 1-50 were used for training and 51-100
were used for testing. Table 2 lists the average IPS for the
experiments in Figures 8, 9, 11 and 12 (i.e., the average of the
average IPS) for HTC and Nexus. Note the different average
IPS behavior of the I/O applications in the HTC and Nexus.
We believe this is primarily due to the fact that the HTC has
an external SD Card and the Nexus has an internal SD Card
which means that the access times for these two storage
devices would be different.
Figure 9. HTC Experiments Dataset #2
Figure 11. Nexus Experiments Dataset #1
Figure 10. HTC PDF of IPS
Figure 12. Nexus Experiments Dataset #2
Table 2. Average IPS for Applications
Adobe Reader
HTC
Average IPS
1.9 ms
Nexus
Average IPS
3.2 ms
Music Player
1.9 ms
3.2 ms
Angry Birds
1.7 ms
1.9 ms
Temple Run
1.6 ms
1.8 ms
Zarchiver
4.0 ms
2.9 ms
AppMgr III
5.6 ms
2.6 ms
User Applications
Non-CPU
Intensive
CPU
Intensive
I/O
Intensive
The I/O intensive applications on the Nexus do not experience
the long delay due to external SD Card access time, but there
is a contribution from accessing the internal SD Card coupled
with CPU use. It is beyond the scope of this paper to attempt
to decouple these delay contributors, but suffice it to say that
the average IPS behavior is still discernible from the other 2
categories, and thus enough for the purpose of discussion.
Further, Figure 10 illustrates the probability density function
(PDF) of the average inter-packet spacing of the ICMP replies
of these 6 applications for the HTC and Figure 13 lists the
same information for the Nexus. It is clear from the HTC PDF
that the applications with the tails dominate the average IPS
and the sharp spikes at different IPS values, are responsible for
patterns from each category being separable from each other.
The Nexus PDF shows that the high peaks at different IPS
values are the reasons for distinction. Table 3 shows the
NFC’s confusion matrix for classifying the 300 test patterns
from the 6 applications into the 3 categories for application
type for the HTC. Table 4 displays this same information for
the Nexus. These results yield 95% correct classification for
the HTC and 93% correct classification for the Nexus.
Figure 13. Nexus PDF of IPS
Our results suggest that we are able to remotely discern
different categories of applications executing on Androidbased mobile devices. This is due to the fact that each
category of application uses the mobile device’s resources in
different ways. Comparatively speaking, when the device is
executing CPU intensive applications the device sends
network traffic fast, when the device is executing non-CPU
intensive applications the device sends network traffic slower
than the previous case. The primary reason being CPU
throttling, but for I/O intensive applications the primary cause
of delay in network traffic is preempting processes that are
accessing the external SD card. Further, this hypothesis is
even stronger when the data in Table 2 are considered which
suggests that the significant delay in network traffic is absent
when a devices accesses an internal SD Card instead of an
external SD Card. Again, it is beyond the scope of this paper
to discern the contributions of CPU use and internal SD Card
access. It is sufficient for our purposes to note that with or
without the device accessing an external SD card the
effectiveness of our method persist. We will consider
rigorously investigating the effects of I/O intensive
applications on network traffic IPS in future work.
IX. SUMMARY AND FUTURE WORK
We have demonstrated the ability to remotely discern three
different application types running on mobile devices over a
WiFi network. The method is robust and novel. We hope to
continue to enhance the method by implementing the future
work.
As future work, we would like to consider the effect that the
memory size of the mobile device has on the number of
applications that can run in the background and thus on
network traffic. We would also like to consider the effects of
the user’s interaction with the device on the average IPS of
network traffic emitted from the mobile. Further, we would
like to rigorously investigate the effects of I/O intensive
applications on the network traffic IPS of mobile devices with
and without external SD cards. Also, we would like to
determine the impact that continuously pinging the mobile
device has on the device itself and the network. Most
importantly, we would like to look closer at Apple devices and
determine if there is an alternative to using CPU throttling to
glean information from network traffic regarding the internal
state of these devices. Finally, we would like to extend the
capabilities of our method to include the identification of
individual applications, malware included.
Table 3. NFC Confusion Matrix For 6 HTC Applications
Actual Class
Predicted Class
NonCPU CPU
IO
NonCPU
CPU
97
11
3
89
0
IO
2
0
98
0
Table 4. NFC Confusion Matrix For 6 Nexus Applications
Actual Class
Predicted Class
NonCPU CPU
IO
NonCPU
CPU
98
0
0
92
2
IO
12
0
88
8
REFERENCES
[1]
SANS Computer Forensics Website 2013:
http://computer-forensics.sans.org/blog/2012/04/09/is-anti-virus-reallydead-a-real-world-simulation-created-for-forensic-data-yieldssurprising-results
[2]
L. Watkins, W. H. Robinson, and R. A. Beyah, "A passive solution to
the CPU resource discovery problem in cluster grid networks," IEEE
Transactions on Parallel and Distributed Systems, vol. 22, pp. 20002007, 2011.
[3] Texas Instruments Embedded Processors Wiki Website, Accessed
Novermber 2011: http://processors.wiki.ti.com/index.php/TI-AndroidGingerBread-2.3.4-DevKit-2.1_PortingGuides
[4]
J. Hildenbrand, “Android 101: Save battery power by keeping wifi
alive”,
Android
Central,
September
2,
2011:
http://www.androidcentral.com/android-101-save-battery-keeping-wifialive
[5]
L. Watkins, W. H. Robinson, R. A. Beyah, “A Passive Solution to the
Memory Resource Discovery Problem in Grid Computing.” In IEEE
Transactions on Network and Service Management (TNSM), December
2010.
Airwatch Website Accessed February 2013:
http://www.air-watch.com/solutions/mobile-device-management
[6]
[7]
Good Website Accessed February 2013:
http://www1.good.com/products/mobile-manager
[8]
Mobile Iron Website Accessed February 2013:
http://www.mobileiron.com
[9]
Symantec Website Accessed February 2013:
http://www.symantec.com/mobile-device-security
[10] Android Developer’s Blogspot Website Accessed February 2013:
http://android-developers.blogspot.com/2010/04/multitasking-androidway.html?m=1
[11] IBM Developers Website Accessed February 2013:
http://www.ibm.com/developerworks/library/l-completely-fairscheduler/
[12] XDA Developers Website Accessed February 2013:
http://forum.xda-developers.com/showthread.php?t=1496777
[13] K. German, “Apple iOS 4 Review”, CNET.com, June 21, 2010:
http://reviews.cnet.com/8301-19512_7-20008259-233.html
[14] Matlab Central Website Accessed February 2013:
http://www.mathworks.com/matlabcentral/fileexchange/29043-neurofuzzy-classifier
[15] Google Play App Website Accessed February 2013:
https://play.google.com/store
[16] iPhone App Website Accessed March 2011:
http://linpack-benchmark.appspot.com/
[17] International Business Times Website Accessed February 2013:
http://www.ibtimes.com/android-market-share-nears-52-percent-appleiphone-still-most-popular-device-us-723349
[18] V. Venkatachalam and M. Franz, "Power reduction techniques for
microprocessor systems," ACM Computing Surveys, vol. 37, pp. 195 237, 2005.