Android App Watcher: A look into Android
Antivirus Security
Jonathan Lally; ID 12211753
School of Computing
Dublin City University
Dublin, Ireland
Email: jonathan.lally6@mail.dcu.ie
Abstract—This paper presents two experiments. The first
begins by outlining how a behavioral based malware detection
system for Android could be implemented, however it concludes
that without a special class of privileges specifically for antivirus
programs in Android, a behavioral malware detection system
could not be built. The second experiment places nine of the
most frequently downloaded Android antivirus applications in an
environment with twenty malicious programs and compares them
on malware detection rate, speed of scan, depth of scan, size of the
application on the hard disk, and features which each program
provides. Full results of this experiment are available online, but
this paper includes a summary of the more important results.
It was found that although ESET and Dr. Web provided the
highest rates of detection, both lacked most of the extra features
the majority of the other antivirus programs supplied. ESET
also held the largest amount of hard drive space, however Dr.
Web held the least. Avast was found to have the widest range of
features at no extra cost, but only held a 95% malware detection
rate. Both experiments point to the need for Android to introduce
more security for the detection of malware.
Index Terms—Smartphone, Android, Operating System, Security, Malware, Antivirus, Trojan
A blog about the construction paper is available from [79].
I. I NTRODUCTION
Computers continue to grow, evolve and adapt to users
everyday needs. This is not only limited to the internal memory
capacity and power, but extends also to the external size of
each unit. From the mainframe to the desktop, to the laptop
to the netbook, the evolutionary chain is quite evident and
the next link in the progression is the mobile phone. From
the European Commission Statistics Department, Eurostat, it
has been revealed that in 2009 in Europe, for every 100
people there were 125 mobile communication devices [47].
This demonstrates the popularity of mobile devices. Further
statistics show that by the end of 2013, 1.4 billion smartphones
will be in use, of which Google’s Android mobile platform
will account for 57 percent of the market share, followed by
Apple’s iOS with 21 percent [81]. Reasons for this include that
mobile devices allow users all the benefits of a home computer
in their pocket [51], as well as transparently extending online
services such as email to the users hand [46]. As over half
of all smartphones on the market use Android, this paper will
investigate the Android platform.
In the world of computing once there is financial and or
sensitive data flowing on a network there will be attempts to
intercept these transactions, and with online financial services
from banking to shopping to social media sites, there is a
constant cyber-threat looming which hopes to profit from
unsuspecting users [108]. In 2013 the largest distributed denial
of service (DDOS) attack ever recorded was executed against
Spamhaus [112], who were receiving over 300 billion bits of
traffic per second [103, 110]. This was the result of an attacker
creating a bot-net of zombie slave devices, which had become
infected unknown to their users [91]. These zombies were then
used to make large data requests from servers but specified that
the responding data should be sent to the victim, Spamhaus
[91]. This demonstrates the ability of a single attacker to
generate the largest amount of traffic ever recorded for their
own malicious intents.
Following this, the security organisation RSA was successfully attacked losing some internal data [107]. In the blog post,
the author believes the perpetrator was part of a particular
format of an attack which has become know as an Advanced
Persistent Threat (APT)[107]. An APT attack is defined in
Mandiant [87].
The author of this paper contends that the severity of these
described attacks demonstrates the lengths to which cybercriminals are willing to go to achieve their ends, and when
security giants such as RSA, who created and maintain the
most globally used public key encryption system currently
used [106], are unable to mitigate these attacks unscathed,
the intelligent and advanced nature of these intrusions can
truly be appreciated. However, these attacks are not just
limited to organisations and governments, or even standard
servers and computers for that matter. They extend to mobile
devices, particularly Android [77, 89]. This paper delves into
the concept of Android malware and explores a means of
identifying a Trojan’s presence on a mobile device. This
study then proceeds to investigate popular antivirus programs
currently on the market for Android, by placing each in a
sand boxed environment with a number of known malicious
programs and comparing the findings of each.
II. L ITERATURE R EVIEW
A. Smartphone Security
Smartphones are mini, pocket sized computers which have
been adopted into general use by the public due to their
powerful nature, such as their ability to act as a highly effective
personal digital assistant [102]. They provide not only the
basic features of mobile phones such as calling and SMS
(Short Messaging Service) services, but also include features
such as an email client, web browser, global positioning
system (GPS), online and home computer synchronisation
abilities, and games, as well as organiser orientated tools such
as a calendar, contacts, note taker and voice recorder [34].
With the addition of its Internet capabilities and tools such as
voice recognition, for example with Google Now and Apple’s
Siri, a person can vocally ask their mobile phone questions
and receive search engine results [24, 58]. All of these services
combine to create a very powerful and portable device. There
are many smartphone Operating Systems (OSs) available on
the market today including Google’s Android [54], Nokia’s
Symbian [121], RIM’s Blackberry [104], Microsoft’s Windows
Mobile [90] and Apple’s iOS [25].
1) Private Information on the Device: Enck, Ongtang, and
McDaniel [46] argue that many of these powerful features
require personal data to function, which, if the device was to
be compromised would reveal intimate details of the user’s
personal life. For instance, if the phone itself was stolen and
was signed into a social networking site at the time of its theft,
such as Facebook or LinkedIn, intimate details of the user’s
life could be in jeopardy. In the paper by Jeon et al. [69]
they suggest the sensitive information which could be leaked
in the event of the mobile device becoming insecure would
be data which is both stored on the device and transmitted
out of it. This includes, but is not limited to the address book
contents which would include contact’s phone numbers, home
and / or work addresses and email addresses among other
details; calling history; GPS location information such as the
user’s home address and most visited places; e-mail client data
revealing all emails and attachments to and from the user,
contact’s email addresses and the user’s calendar schedule;
web browser information such as data in the web log, browsing
history, Internet Cache, stored browser passwords; SMS (Short
Message Service) messages to and or from the user; MMS
(Multimedia Message Service) messages to and from the user;
and media files such as personal voice and video recordings as
well as images [69]. Further to this, user installed applications
could retain further information about the user. e.g. Personal
financial data could be stored on Banking or online shopping
applications [2, 30].
2) Lines of Attack: One of the tantalizing features of
smartphones are their variety of communication modalities
[69]. Most smartphones are able to connect to other devices
in a variety of ways such as: a Wireless 802.11 connection
(Wifi) which connects via a wireless network access point
(AP); a GPS satellite connection; a mobile network (MN),
e.g. 3G, which connects via a mobile base station (BS) which
also provides the calling, SMS and MMS services; a bluetooth
connection which allows direct communication to other computer devices; personal computer (PC) synchronisation which
allows a connection to a PC using a direct wire such as a USB
connection [69]. Nevertheless, the author of this paper takes
the view that a strength can double as a weakness, and in this
case that weakness manifests itself as multiple points of entry
for malicious users and applications.
To purely inhibit a victim from a wireless Internet connection, DOS and DDOS attacks, as described earlier, can be
performed against the BP and AP which the victim’s device
relies on for wireless Internet communication [92]. Further
to this, the GPS is vulnerable to both jamming and spoofing
attacks [97]. The paper by Nighswander et al. [97] goes on
to describe a number of attacks to which GPS could also
be at risk. However, a usually more favored methodology by
attackers is to use these channels as entry points for attacks
such as Trojans and malware [132]. In the paper by Jeon et al.
[69] they list the following vulnerabilities which can render a
mobile device useless or be abused by attackers:
• Source code implementation errors can cause a system
crash, or be abused by attackers. Particularly if they go
unnoticed they can lead to zero day attacks [82]
• User unawareness of environment threats: the user can
install applications from untrusted sources; the user can
connect to untrustworthy APs and/or websites; the user
can connect to an unsafe device via bluetooth; the user
can have unsafe configuration settings, for instance, bluetooth always enabled and accepting all connections [131];
the user can fall prey to social engineering attacks; the
physical mobile device can be lost by the user or stolen
by a malicious party
• Traffic to and from the AP can be corrupted, blocked or
modified by sniffing, spoofing or eavesdropping [69]
• If any of the external objects which the mobile device
is connected to are insecure, such as the AP, the device
itself is at risk [69]
3) Smartphone Malware: From the above, the many pathways which can be abused by attackers has been demonstrated,
but how often are they actually abused? According to the
McAfee Labs [89], they had captured only 792 unique mobile
device malware families in 2011, but since then this has risen
exponentially to 50,926 samples. This growth is predominantly
in Android with new malware presenting itself everyday [89].
Kaspersky Labs [77] found that 99.9% of new mobile threats
target Android. It is for both this reason and the widespread
use of Android as stated earlier that this paper will concentrate
on Android.
B. Android Architecture
Android is a software stack for mobile devices, built with
the Linux 2.6 kernel at its bottom layer. It is maintained by
Google and the Open Handset Alliance (OHA) [101]. The
OHA is a consortium of 84 companies including Google,
HTC, Intel, LG, Motorola, Nvidia, Samsung and T-Mobile
with the goal of implementing open standards for mobile
devices [22, 101]. Android’s success could be attributed to its
open source nature, allowing it to be more widely understood
and bugs spotted and fixed quickly. New functionalities can
be added faster by experts in the area and it is easily ported to
new hardware devices, even extending to devices other than
smartphones such as tablets [51].
Fig. 1.
Android Architecture [51]
Android OS is in fact a software stack composed of three
primary layers which are composed of the Linux kernel at the
bottom, the middleware, and the Applications Layer at the top
[22].
From Fig 1 it is evident that each layer is kept encapsulated and therefore completely independent of the layers
surrounding it. To gain accesses to the features of the next
layer, function calls which are specified in interfaces are used
[32]. The bottom layer is the Linux kernel. This is the actual
OS and provides all the low level functionalities required by
the device such as memory management, process management,
network stack management and security as well as providing
the abstraction layer between the software and the actual
hardware [33, 51].
Applications for Android are primarily written in the Java
language, with a little XML for format and abstraction [32,
51]. Applications and widgets are at the top level of the stack.
These applications range from the core applications which
come as standard upon Android’s installation such as SMS,
email client, calendar and browser, to applications developed
by third parties and distributed via Android market places such
as the official market place: Google Play [32, 51, 57]. The next
part of the Application layer is the Application Framework [32,
51]. This is the schema which implements the structure of all
applications. It is composed of many components, but one of
the most important is the Activity Manager which manages
the life cycles of all active programs. Other components
which it provides include a Resource Manager, a GPS device
Location Manager, a Notification Manager for background
alerts such as the arrival of a new SMS message or email,
as well as managing content provider objects [32, 51]. A
content provider object is a group of data which needs to be
shared between applications, such as contacts [32, 51]. The
Application Framework allows for easy reuse of components.
Android developers can write and add their own components
to this layer [32, 33].
The next layer contains the native Android libraries. These
libraries are for use by all applications, core and third party
alike [32, 101]. They are written in C and C++ but are hardware specific so they are compiled by the hardware developer.
This is why each hardware company has its own version
of Android on it’s devices [32, 101]. However, the libraries
provide a standard Java interface which allows all Android
applications to function independently of the hardware and
grants the platform its portability [32, 101]. Examples of
some of the libraries include: the Surface Manager which
controls the screen display; an array of media codecs for
playing and recording video and audio; 2D and 3D graphics
engines for creating and rendering the graphical user interface
(GUI), a SQL database for relational data storage; and finally
the WebKit library for powering a browser. Using the Native
Development Toolkit, developers can create and add their own
libraries [32, 101].
On the same level as the libraries is the Runtime Environment [32, 95]. This consists of core libraries for Android
to function, and the Dalvik Virtual Machine (VM), which
is similar to a Java runtime environment [32, 95]. When an
Android application is written, it’s Java ’jar’ and ’class’, and
XML files are compiled into an ’apk’ file, which is an installer
package. When this apk file is installed the executable code
is compiled into the ’dex’ format, which can be read by the
Dalvik VM. Dalvik was purpose built for Android, written
by Google and is optimised for both running on Linux and
low memory usage making it the perfect process runtime
environment [32, 95]. It makes use of Linux’s security module
for both process security and isolation, made easier by the
fact that each process receives its own VM. This provides
Android’s sandboxing feature ensuring the systems safety from
each application [32, 95].
C. Android Security
One of the big differences between Android security and
common commercial OS security is that Android operates on
a mutually distrusting software basis, in which no program, or
user can trust any other program or user [71]. The architecture
of Android reflects this principle. It ensures each layer is
secure from the next with only interfaces and prepared component functions providing inter-layer communication [32, 51].
Each component within these layers are again kept separate,
unaware of each others presence. In the application layer,
given the Dalvik VM and the fact that every application is
placed in its own process, this guarantees the isolation of
each application, as the default Linux process confinement
measures are in place. Within each layer exists similar safety
walls [32, 95]. The importance of this segregation is to
confine any unwanted outbreaks, be they malware or internal
errors, sandboxing them from the rest of the system. For
example, the exploit outlined by ISE [68] which attacked the
Android Browser application could only affect the browser,
and files which the browser has access to. The other Android
components were left unmodified and intact ISE [68].
However, sometimes components within processes need
to communicate with components within other processes or
retrieve access to resources available on the device, and this
could present a gap in security as it involves leaving the
sandboxed area [46]. So when components do partake in inter
process communication (IPC) there are a number of security
measures in place which form Android’s Security Model.
Android employs a Mandatory Access Control (MAC) model
[46]. In this way applications, or for that matter any component attempting to access any system resource, including
hardware, files, Content Providers or other components must
have the expressed permission of that resource to complete
the transaction [46]. This is accomplished by treating every
application as a separate user. As such it allocates each newly
installed program with a user identity (UID) [71, 127], as
well as providing it with certain permissions which express
every resource that the application has access to. The user
must expressively grant these permissions by agreeing to them
at the time of installation [71, 127]. For instance, to receive
access to the device’s saved contacts, the permission can be
entered in the application’s manifest file as follows:
<uses-permission android:name=
"android.permissions.READ_CONTACTS" />
This is referred to as a permission label. There are many
permission labels and developers can even add and create
their own [10, 63, 71]. Most permission labels are not unique
and are used by multiple programs, as multiple programs
would need access to device resources such as contacts [10,
63, 71]. To implement this MAC system, when a component
attempts to access a resource the reference monitor, located
in the Application Framework layer, checks its permission
labels to ensure it has the required permission before allowing
the transaction [10, 63, 71]. If the required permissions are
not present, the communication is denied, even if the wanted
resource is in the same process [46]. In the Android [17]
documentation they request that developers keep their required
permissions to execute to the absolute minimum, to promote
process isolation.
If the developers of an application desires complete secrecy
from other applications, it can specify itself as a private
component by setting the ’export’ attribute in its manifest
file to false [46]. This prevents it from being used by other
processes. If it has to allow access to itself by others, but
it wishes to strengthen its own security, it can take matters
into its own hands by using the ’checkPermission’ function
which Android provides [46]. By using checkPermission, the
component being called can check for specific permission
labels which the caller retains, and can reject the request if
the caller is not up to the callee’s standards [12, 46].
Often developers will release programs which they hope
to work in conjunction with each other [17, 46]. To allow
for easier communication between components of the same
developer, a ’signature’ permission label was added to the
Android MAC model [17, 46]. The idea is that once an
application allows access to one of its components, it cannot
be sure that access to it will be restricted to the intended
set of applications only. To prevent applications which hope
to misuse its services and steal its sensitive information the
’signature’ permissions was introduced [17, 46]. It only grants
access to the callee application if the caller has the same
developer as the callee. For instance, system features such as
the telephony API, which were created by Google and should
only be accessed by Google applications, have the ’signature’
permission in their manifest file ensuring that only a Google
application could use this feature [17, 46].
As earlier stated, each application is treated as a user, and as
such, upon creation it is allocated its own storage directory on
internal storage, comparable to a users home directory [71].
It uses this area for storing its code and data. By keeping
its sensitive data in here the hardware prevents access by any
other processes. The Android documentation recommends this
for the safe keeping of private data [17, 32, 71]. In addition
to this, only the UID of the application which wrote a file
can access it [32]. However, external data is not so safe
[17]. Any data saved to an external drive, such as an SD
card, is world readable and writable [17]. This is why most
programs avoid writing any data to external memory. In the
author of this paper’s opinion, although many programs could
store non-sensitive data on the external storage device, many
developers feel the need for taking extra security measures by
only utilizing internal storage.
Given this strong inbuilt security, the Open-Source Programs Manager for Google suggests that antivirus is not
needed for Android and other similar mobile OSs due to their
architecture and MAC style security structure [42]. This blog
post asserts that due to the sandboxed nature of the OS, viruses
cannot spread like conventional computer viruses. In the author
of this paper’s view, this post does not address the issue of
an infected program or its detection, and from sections 2 and
3 from the A. Smartphone Security section above, as well as
section E. Trojans below, the existence of Android malware is
evident.
D. Android Logs
Android has a System Log, and a log for each program
[45]. As programs execute they update both logs with informative information as to their actions [14]. The System
Log gets updated with debug information ranging from minor
background information to system traces of internal errors
as an application executes [14]. The application log consists
of helpful messages that the application developer included
in their program’s output, usually for both control flow and
debugging information [14]. The logs can be examined using
the Android Logcat utility [9]. There is also an Event Log
which documents all system events [5]. These range from
Activity Manager state changes to system watchdog updates.
This again is examinable via the Android Logcat utility [9,
45].
The Logcat utility can be used via the Android Debug
Bridge (ADB), which requires a connection from the device to
a computer [9, 14]. As the device is connected to a computer,
the computer is given special privileges which grant it root
access. Alternatively, the Logcat utility can be run directly
on the device and parameters can be passed by the querying
program to limit the output to a subset of wanted data [9, 14].
E. Trojans
This paper has discussed the large amount of malware targeting Android, and the physical means by which the malware
reach the victim devices. However the origin of most malware
has not been exposed. As with all Trojan malware, they are
predominantly attached to popular, easily obtainable programs
which users download from Android Market places [132].
Although many of these markets employ Trojan detection for
all applications on them, such as Google Play [111], there
are many accounts of malware slipping by these detection
methods such as the well known Trojan DroidDream [85]. To
evade detection, simple workarounds can be deployed, such
as the method employed by the Trojan ’Extension.A’, which
simply DES encrypts the malicious part of it’s code thereby
escaping detection [124]. Once installed, it decrypts and runs
the malicious code. This Trojan can execute a range of commands on the victim via a command server, or SMS command
[124]. For the purpose of this article spyware goals refers
to the opening an Internet connection and sending the IMEI,
IMSI identification numbers, phone number, Android version
and SDK version, phone model, call logs, contacts, wifi and
GPS location and SMS logs to a server controlled by the
attackers. Extension.A achieves the spyware goals, but can also
make, receive, and intercept phone calls and SMS messages
[124]. The Trojan ’Plankton’ employs a different detectionevading technique, which also allows it the use of dynamic
payloads [70]. Upon download the Trojan can wait for long
periods of time before any malicious activity takes place.
Once activated, it sends device information, such as Android
version, and the privileges of its host program on the device,
to its command server [70]. A specially tailored payload can
then be sent to the device for background execution. This
means that it can be attached to a wide range of applications
[70]. The payload is written in Dalvik bytecode allowing
it to be dynamically loaded into memory and therefore it
evades most static signature detection schemes. However, the
payloads do not attempt to gain root, they are only spyware
orientated, collecting information such as browser bookmarks,
phone log entries and device accounts. It can also remove on
screen shortcuts to assist hiding Jiang2011Security. BadNews
is another Trojan which poses as an advertising network, but
constantly prompts the user to download and install malicious
applications, sometimes suggesting that they are updates for
programs the user may have [105]. BadNews avoids malware
detection in a similar way to Plankton, as all malicious code
is downloaded separately. However, most malware originates
from third party Android markets [114].
Once on the victim device, most malware share similar
goals. There are a number of passive attacking Trojans which
try to achieve the spyware goals only, such as ’Android.Tetus’
[118], ’Android.Exprespam’ [115], ’Android.Uranico’ [119],
’Chuli.A’ [74], and ’Android.Sumzand’ [116]. Each tries to
go undetected by quietly executing in the background. Android.Sumzand in particular targets non-technical users by
attaching to a program which claims to turn the user’s phone
screen into a solar pad for charging the phone [120]. Android.SMSSend [94] achieves the spyware goals, but transfers
the results via SMS. Only the contacts are sent to a server.
The passive malware TRacer [78] achieves the spyware goals
as well as adding call recording, browser history and emails
to the captured data list. A difference here is that it can
issue commands via the server or via SMS messages which it
then hides. It also has the ability to remain hidden from the
Installed Apps and Task Manager Android menus allowing
it to be invisible on the phone [78]. Android.Uracto [62]
and SpamSoldier [61] accomplishes the spyware goals, but
also uses the victim to spread. The victim device sends SMS
messages to all of their contacts advertising what are usually
costly programs, but for free. However, these programs contain
the Trojan itself [61]. Versions of Android.Uracto attempt to
indulge the victim to sign up to fraudulent services [62].
The Trojan SMSSilence.C is an active attacking Trojan,
targeting SMS messages specifically by setting the phone to
silent every time a message is received, thus obfuscating its
arrival and therefore avoids the user’s immediate attention,
and forwarding the message onto its command server [26].
The silent sending and receiving of SMS messages can be
very profitable as large costs can apply to premium numbers,
and if all the premium number responses are hidden, the
user many not notice the occurrence. Android.FakeMart.A
implements this scheme [49]. An active attacking SMS orientated banking Trojan is Spy.AndroidOS.Citmo (Carberpin-the-Mobile) [73]. Citmo targets online banking in Russia
by attempting to intercept mobile Transaction Authentication
Numbers (mTANs). It works in conjunction with its PC
counterpart Spy.Win32.Carberp.ugu which implements a man
in the middle attack by posing as the user’s bank, and then
instructing the user to download the malicious Citmo application [73]. Using both malwares, fund transfers can be made
using Carberp and authenticated using Citmo [73]. This will be
directly very costly to the victim. SMS.AndroidOS.FakeInst.a
can not only send and hide SMS messages, it can also generate
shortcuts to malicious sites on the Home screen, and prompt
notifications to install malicious software [125]. To make
matters worse, FakeInst uses the Google GCM to act as
the command server, meaning it uses Google servers for its
attack [125]. Android.Stels achieves the spyware goals, but
also can send and hide SMS messages, make phone calls,
and it can download and install other applications [113]. This
makes it an incredibly versatile Trojan, capable of a range
of malicious acts, including the installation of other malware.
Obad.a can also perform all these actions, but in addition
can also execute any Linux commands, and can also activate
the host’s bluetooth and transmit itself to neighboring devices
through it [126].
But there are also Trojans reminiscent of regular Desktops malware. FakeJobOffer.A is downloaded as a Bollywood
video, but once the device is rebooted it prompts the user
that they have been offered a job, but they must deposit
money into the company account before they can receive the
job (citeAsrar2013Android. Android.Tascudap simply adds the
host device to a DDOS zombie network [117].
However, most Trojan’s require the host application to be
launched to execute. DroidDream Light (DDL), a descendant
of DroidDream, is very capable in its ability to activate [83].
Once the phone state is changed, such as when a call comes
in, an intent is fired. This intent wakes DDL allowing the
spyware goals to be achieved. As well as this: information
about installed packages is returned to the command server;
it has the ability to change to a different command server; it
can download and prompt the installation of applications; and
it can update itself [83, 86].
On that note, there are also Trojans which only use the
Android device as a stepping stone to their true target. Once installed and activated, Android/Ssucl Spy achieves the spyware
goals, and then downloads an autorun.exe onto the device’s
SD card, which contains the exploit Backdoor.MSIL.Ssucl.a
for Windows [35]. In this way, if the SD card is inserted
into a windows PC, the PC will be exploited. There was also
a Trojan discovered, named LuckyCat.A after its inventors
who are part of an APT team named LuckCat [122]. This
team is as described in the Introduction of this paper, and are
believed to have intended this application to target employees
of specific organisations who bring their mobile phones into
their corporate environment, providing a weak point in the
company network, thus revealing the ongoing operations of
that organisation [122]. The Trojan has full access to the
device’s storage and can open and transmit to its master
server over an Internet connection. A remote shell was being
implemented at the time of the Trojan’s discovery [122].
F. Signature Attack
A highly dangerous attack discovered by Bluebox Security
[48] unearths a way of adding code to already existing
installation files without modifying that file’s cryptographic
signature. Upon download, every installation file’s signature
is examined to ensure that the code has not been modified
and therefore the application can be trusted [48]. However
the new exploit, which affects all Android versions since
version 1.6, allows attackers to attach malicious code to
trustworthy applications undetected and therefore piggyback
their way onto an unsuspecting victim device [48]. If applied
to an application with superior privileges, such as the device
manufacturer’s firmware update, the Trojan would have all
privileges on the device, and therefore unrestricted access to
all data, including passwords, and remote control abilities on
the device [48]. Google has since released a patch to fix the
problem [53], but it demonstrates how the most scrupulous
users can fall victim to malware attacks.
G. Antivirus
Antivirus software attempts to apprehend, isolate and delete
malware in the same environment as itself [100]. To investigate
programs as to their true intent, there are a few different
techniques.
Signature scanning is the most commonly used technique
for detecting malware [72]. The signature of a malware is
the bytecode which its code forms [60]. This bytecode is
compared to the bytecode of all other executables on the
system, and if any matches occur, that program is malicious
[36, 60, 72, 100]. All signatures are stored on a server which
antivirus vendors maintain and update as new signatures are
discovered. This is very useful for static malware, but allows
a gap between the malwares release and its discovery [36, 60,
72, 100].
Heuristic scanning understands the regular actions of a type
of program, and if a program of that type takes any actions
outside its expected scope, it is flagged as malicious [36, 60,
72], e.g. if a calendar program attempted to open and write to
another executable.
Integrity checking is a technique where every program on
the system is hashed upon it’s installation [36, 60, 72]. All the
programs are routinely re-hashed to ensure no changes have
been made. If a change has occurred the program is suspected
of having malware attached to it [36, 60, 72]. This is useful
for executables but unusable on consistently growing data files
[36, 60, 72].
Behavioral based or activity monitoring techniques watch
all programs in execution and if they make any suspicious
actions, such as modifying the boot sector, they are flagged
as malicious [36, 60, 72]. They have a database of actions
commonly performed by malware [36, 60, 72]. Experiment
One below attempts to build a behavioral based system for
Android.
Many antivirus programs would use signature scanning as
well as other detection techniques such as Cisco [37].
III. T HE E XPERIMENTS
From section B. Android Architecture of the Literature
Review above, it can be seen that once one initiates the
installation of an Android application, they are served with
the permissions which it requires during execution and if
they are not granted, the program will cease installation.
Although, again from the same section above, it is explained
that Google encourages Android developers to keep their
required permissions to a minimum., in the author’s experience
this is not always adhered to. A popular Android application is
the third party Flashlight application [65]. Its only function is
to turn on the camera’s flashlight enabling it to act as a torch.
This application boasts that it has over ten million installations.
However, among its permissions are the following: User’s
approximate network location and precise GPS location, full
network access, Phone Calls which allow it to monitor the
phone status, call history and phone identity, and System Tools
including modifying system settings [66]. In the author of this
paper’s view, as Google Play automatically checks if updates
have been released for applications on the device [56], the
request for Wifi access seems unnecessary, the user location
permissions again seems needless and knowing the identity
of the phone seems inexplicable for a flashlight. Finally, as
it already has permissions for taking pictures, videos and
controlling the device flash [66], its ability to modify system
settings seems avoidable. Given the existence of applications
such as this which seem to have access beyond their basic
needs, the Android MAC model may be subject to abuse, and
there is room for Trojans to thrive on uninformed users by
attaching themselves to programs such as this.
This paper consists of two experiments. The first will
attempt to establish if it is possible to create a non-root,
lightweight application inspector which, when given an installed application on the device, would watch the targeted
program and construct a time line of the application’s actions.
From this the user can see if it is carrying out any suspicious
behavior. From sections B. Android Architecture and C. Android Security above, it is apparent that due to the sandboxing
nature of Android, the inspection of another program could
prove to be outside of the ability of a non-root application
and there-in lies the experiment. Behavioral antivirus programs
have been suggested before such as Burguera, Zurutuza, and
Nadjm-Tehrani [31], however they have required root privileges. This application is named the ’App Watcher’ by the
author. There are two goals of the App Watcher. The first is to
create the time line of the target which could indicate possible
Trojan-like behavior. The second goal is to accomplish the
first with the constraint that it does not have any super user
privileges. It will not require an external desktop computer
(PC), and it will not require the Android device to be rooted.
It can be easily installed on an Android device as acquired
straight from its manufacturer. This hopes to introduce a more
forensic style approach which could be utilized by antivirus
programs.
The second experiment will pick twenty of the most recent
Android Trojans and place them in an Android environment.
From here a variety of well known commercial antivirus
products will be placed in the environment and compared
and contrasted on several key aspects including the amount
of malware detected.
IV. M ETHODOLOGY: E XPERIMENT O NE , A PP WATCHER
Although Android is capable of operating on different hardware devices such as tablets and netbooks [27], Experiments
One will be conducted using an Android 4.2 mobile phone
environment, emulated on a virtual machine.
To create a minimal permission, non-root program to produce the time line of actions performed by a specified application (target), the following approaches will be utilized:
• It is hoped to examine The System Log, target’s Application Log and Event Log to attempt to extract relevant
information regarding the target
• It is hoped to monitor the Internet connection to gather
information on the data being transferred in and out of
the target
• The Activity Manager [3] will be used to retrieve basic
information about the target such as its UID
• It is intended to use utilities such as ’getApplicationInfo’
from the Package Manager [12] to retrieve helpful information about the target
• The files containing sensitive data which are opened by
the target will be observed using the FileObserver [6]
•
•
utility
It is planned to investigate the use of built in Android
Debugging utilities on the target
It is planned to exploit Intents broadcasting nature
A. Exploring the Logs
From D. Android Logs above, we know that by watching
the System Log, Event Log and the target’s Application Log
the majority of the time line can be created as most of the
target’s activities will be documented in these. These three
logs can be monitored by using the Logcat utility described
in the same section of the Literature Review above. By using
the Runtime [16] library the following code can be used to
read the Application log [9, 14, 50]:
Process p =
Runtime.getRuntime().exec(‘‘logcat -’’);
BufferedReader in = new BufferedReader(
new InputStreamReader(p.getInputStream()));
StringBuilder log = new StringBuilder();
String line;
while ((line = in.readLine()) != null) {
log.append(line);
}
By searching the output of these logs and restricting the search
to the target’s UID, the relevant data can be extracted.
B. Monitoring the Internet Connection
Watching the traffic to and from the target would provide
valuable intelligence as to it’s intent. However, given the
Android sandboxing schema, this is suspected to be a very
hard obstacle to study. Further to this, a secure channel could
be used to transfer the communications of the target such as
HTTP over SSL/TLS rendering the traffic unreadable in any
circumstance. In a less powerful style, the inbuilt Android
TrafficStats [19] class can be used to gather statistics as to
the amount of traffic to and from the device, and the target.
The target can be specified using the ’getUidRxBytes’ function
[19].
C. File Observer
The FileObserver watches a specified file, and if that file
is opened, the FileObserver alerts its application of this fact
[6]. Adding to this, if the file observer is pointed at a folder,
it notifies the application if any of the folder’s contents
are accessed [6]. The FileObserver will be pointed at files
containing sensitive data and can add files which the target
accesses to its final time line.
D. Intents
Whenever an application begins IPC (from section C. Android Security of the Literature Review above), it will make a
request for a component capable of carrying out the necessary
action [7, 8, 32]. This request is called an intent. When a
component is capable of an activity, e.g. browsing the web, it
is registered with the OS of being capable of this ability [7, 8,
32]. Whenever another process needs that ability, the intent is
given to the component that is capable of executing the task.
However, the caller many not know the wanted component for
executing the query, so it sends the intent to a broadcasting
unit for the desired ability, and all components able for the
job are alerted, and the ones capable of executing the query
specified in the intent respond [7, 8, 32]. By registering for all
broadcasting abilities, the App Watcher can be notified some
of the time when the target steps outside of its own process,
thus adding data to the time line.
C. Activity Manager
Although the Activity Manager utility could be used to
provide useful information such as the UID of an application
once it’s name had been provided, and it’s subclass RunningTaskInfo [15] provided some vague information such as the
starting time of the target and its services, no functions which
would provide further information into the actual target’s
activities could be provided as evidenced in the Android
Documentation [3].
D. Debugger Tools
V. R ESULTS : E XPERIMENT O NE
Unfortunately, using the methods as described above within
the time constraints allowed, some of these methods could
not be accomplished without the allowance of root privileges.
It would appear that the remaining methods provided an
insufficient amount of data to decide upon an application’s
malicious intent, and due to the problems outlined below, the
study was ceased. Seemingly, if the App Watcher were to
ignore its second goal and allow root privileges, it could have
succeeded.
A. Logs
Since Android 4.1 was introduced, developers have been unable to access any of the logs, other than their own Application
Log [55]. This was due to third party developers revealing
sensitive data in the logs. However, if root privileges were
enabled for the application, then it would have the required
access, but this would clash with the original specifications of
the App Watcher [55]. Further to this, in an Android group
conversation [20] one of the developers apologised because
this change regarding log access was not documented. This
removed the primary information bank which was hoped to
be exploited to examine the target.
B. Monitoring the Internet Traffic
It was found that the Android model would not allow a third
party application to monitor the Internet traffic to and from the
device. This is due to a restriction on third party applications
accessing the Access Point settings since Android version 4.0
[13, 59]. But this could be achieved if the App Watcher had
root privileges. Also, a proxy through which all Internet traffic
could be observed was blocked to third party applications [18],
although mitmproxy project [93] claims applications can step
around such a proxy in any case. However, setting up a proxy
has been accomplished via the use of root privileges by some
commercial applications [21, 23] and many online sources
describe a method of using a computer proxy by connecting
the device to a PC and rooting the device [44, 64, 96, 98].
The TrafficStats [19] class acted as expected, however as
it could only provide quantities of data sent to and from the
target, and there was no way of knowing exactly what data
was being transferred. This suggested little about the user’s
privacy being violated, and therefore was not particularly
useful without further information.
As foreseen, these tools were not plausible to use on other
programs [4].
VI. C ONCLUSION : E XPERIMENT O NE
After the flaws in the primary methods of investigation of
the target were exposed (see Experiment One Results) this
author decided to cease the study as App Watcher could
not gather enough information about the target. Although
all Android packages [11] were investigated, no alternative
methods within the goal parameters of this study were found.
However, it would appear in each case that root privileges
and / or the use of a PC could be viable avenues to explore.
Although this could be viewed as a limitation, it could also
prompt the introduction of a new suite of permissions available
only to an antivirus user group, allowing them to operate with
their required privileges. It should be noted that this could
impose a security risk, as it is in essence creating a back-door
for antivirus programs to use. However, if exploited it could
provide a malicious program with the tools and permissions for
the theft and modification of all data. As such, strict measures
would have to be implemented to ensure only trusted programs
could gain access to this group.
If the App Watcher approach were performed enough times
in a substantial amount of different environments, malicious
patterns could be established and therefore a fully automated
system could be implemented. This could supply a secondary
behavioral based mechanism to supplement the already established inspection of execution code for known signatures, and
help thwart zero day malware attacks for which no signature
exists.
The prospect of providing further sandboxing abilities to
users to deal with the excessive privileges problem has drawn
some public attention. There is evidence to suggest that
Android 4.3 has implemented the groundwork for blocking
specific privileges which an application requests, but the
Android developers have not made this privilege blocking
ability available to users yet [1]. CyanogenMod, an alternative
Android aftermarket firmware distributor [40], had a similar
capability in a previous release, however this resulted in the
applications crashing when they tried to use the newly blocked
privilege, and sometimes the entire device crashed [67]. An
interesting project suggested by CyanogenMod to provide the
wanted privacy to users is to create impostors for privileged
entities [67], e.g. a fake Contacts file, which would include
limited false contacts. This would be given to an untrusted
application instead of the real file, thus prevent the application
from crashing as it would think it had been granted access
[67]. This would allow users to install their wanted application,
but still retain their own private information if they somewhat
distrust the application [67].
VII. M ETHODOLOGY: E XPERIMENT T WO
Experiment Two was conducted on a Samsung Galaxy Ace
S5830 (SGA) [109]. However, as Samsung decided to cease
the release of versions of Android past Android Gingerbread
[128], a CyanogenMod version of Android 4.2 [41] was
installed on the device. This allowed the experiment to be
performed on the latest version of Android at the time this experiment was conducted. Use of this device proved to be faster
and more reliable than an Android VM. In Experiment Two
twenty malware programs were placed on the Android device.
Ten antivirus programs (AVPs) were sequentially installed and
executed on the device. Their results were compared across a
number of dimensions.
A. The Environment
To ensure the exact same environmental circumstances were
in place for each AVP, two base system images were created.
The first image was of a fresh new installation of Android
4.2. This is referred to as the Blank Image. The second was
taken after all twenty malware programs were installed on the
Blank Image, and no AVP was present. This shall be referred
to as the Malware Image. To allow the taking and loading
of system images ClockworkMod [38] was installed on the
device. A side effect of the use of system images was that
it requires the device to be rooted [129], however this could
only benefit malware, and not the AVPs as they do not require
root.
B. Kiy Issues (KI)
The AVPs were compared on the following key issues (KI):
• Amount of Malware detected
• Items scanned, e.g. Applications, Settings, Files saved in
real time, SMS messages and SD card
• Time taken by an Application scan, and a Full System
and SD card scan, performed with a stopwatch
• Size of AVP on disk, retrievable from the Android
’Application Info’ menu
• Anti-Theft Features, Backup Features, Safe Browsing
Features and Call and SMS blocking features
• Any extra or intuitive features were noted
C. Methodology Steps
First the environment was set up by unlocking the bootloader. This was accomplished by flashing the device with a
SGA stock firmware image of Android Gingerbread (2.3). To
achieve this, Odin version 4.38 was used. Then, a ClockworkMod [129] installer was placed on the SD card and ClockworkMod was installed by using the bootloader’s Recovery
Mode. Next, the CyanogenMod Android 4.2 for SGA OS was
placed on the SD card along with Google Core packages [52].
Again, both were installed through the bootloader’s Recovery
Mode option ’Install update from SD card’. This resulted in the
SGA running CyanogenMod’s Android 4.2 (Jelly Bean). The
factory reset option was then applied, again from Recovery
Mode. A Google Account was created for the device to allow
applications from Google Play to be downloaded to it later, and
all software which need updating on the device was updated.
In view of the dangerous nature of the malware which was
about to be put on the device, at this point the Wifi AP which
the device was connected to, was told to block the device, and
the Wifi on the device was switched off and all its connection
details to the AP were deleted. No SIM card was placed in
the phone or bluetooth devices placed within range of it. This
resulted in a completely sandboxed environment. A system
image of the device, called Blank Image, was taken using
ClockworkMod purely for backup purposes.
The twenty malicious softwares, described in E. Trojans above, installed on the phone are as follows: Android.Stels, DroidDream Light, Spy.AndroidOS.Citmo.A, Android.FakeMart.A, Extension.A, TRacer, Plankton, SpamSoldier, Android.Tascudap, Android.Uranico, FakeJobOffer.A, SMS.AndroidOS.FakeInst.a, Android.Tetus, SMSSilence.C, Android.Exprespam, Android.SMSSend, BadNews,
Android.Sumzand, Android/Ssucl Spy and Android.Uracto.
These were downloaded from Contagio Mobile Malware
Mini Dump [39]. The SGA was connected to a computer, and
each malware was installed on the phone using the ADB. This
is when the Malware Image was created, providing an identical
environment for each AVP to operate from.
The AVPs from Google Play were desired, however that
would require an Internet connection on the device and pose
a security risk. A further complication was that Google Play
will not allow the download of installation files to any device
other than the phone which it is intended to be installed
on. However, when provided with account details, Real APK
Leecher [130] emulates an Android device across an Internet
connection to Google Play, using the provided details. It allows
the installer file to be downloaded to a PC. In this way each
AVP installer was downloaded. Each was then installed onto
the Blank Image using an ADB connection, where it could be
granted an Internet connection to ensure it was the most up to
date version.
The Malware Image was loaded onto the device and the
first AVP was installed and executed. An Application scan
was performed. The results and time were recorded. Next the
full scan of all storage was performed. At this point the full
KI were examined and a backup system image of the AVP
with the malware was created. The Malware Image was again
loaded onto the device, and the next AVP was installed. This
was repeated for each AVP.
The AVPs which this experiment investigated were: AVG
Antivirus Security Free [29]; Lookout Security and Antivirus
[84]; Avast Mobile Security and Antivirus [28]; TrustGo
Antivirus & Mobile Security [123]; Norton Security Antivirus
[99]; McAfee Antivirus & Security [88]; Dr.Web Anti-virus
[43]; Kaspersky Mobile Security Lite [76]; Kaspersky Mobile
Security [75].
VIII. R ESULTS : E XPERIMENT T WO1
AVG
Lookout
Avast
TrustGo
Norton
McAfee
ESET
Dr. Web
Kaspersky L
Kaspersky F
App
Scan
Time
01:18
00:39
00:46
N/a
01:43
00:24
00:21*
00:45
N/a
02:34
Full
Scan
Time
01:35
10:56
01:22
01:21
04:30
15:49
00:55*
4:19
N/a
18:01
Size on
Disk
(MB)
21.50
8.89
9.39e
5.78
13.54e
15.21
43.38
3.02*
3.66
7.73
Num.
Malware
Detected
18/20
19/20
19/20
20/20*
17/20
18/20
20/20*
20/20*
17/20
19/20
TABLE I
AVP OVERVIEW
Extension.A Plankton
AVG
Lookout
Avast
TrustGo
Norton
McAfee
ESET
Dr. Web
Kaspersky L
Kaspersky F
x
TRacer
SMS
Silence.C
BadNews
x
x
x
x
x
x
x
x
x
x
Lock
Wipe
v
F
v
v
Fs
v
v
F
F
F
v
F
v
v
Fs
v
v
F
F
F
Sound
Alarm
v
v
v
v
Fs
SIM
Lock
v
Fs
v
F
F
F
TABLE III
A NIT-T HEFT F EATURES
App
AVG
Lookout
Avast
TrustGo
Norton
McAfee
ESET
Dr. Web
Kaspersky L
Kaspersky F
Contacts
SMS
Call
History
Media
c
Fc
c
Fc
Fc
Fc
Fc
c
c
Fc
sd
Fc
c
c
c
Fc
c
F
x
TABLE IV
DATA BACKUP F EATURES
x
TABLE II
U NDETECTED M ALWARE
It should be noted that both McAfee and Kaspersky F
request full system administrator privileges, while all the
others only request a selection of privileges.
From Table I, Kaspersky Mobile Security Lite (Kaspersky
L) only uses a Cloud Scan, which means that as the user
installs an application, its signature is uploaded to a Kaspersky
server and scanned. No conventional memory scan is available.
Due to this, it was decided to also examine Kaspersky Mobile
Security Full (Kaspersky F). Further to this, Kaspersky F
prompts the user every time it detects malware asking if it
1 Legend for all Tables:
e = Expands as extra features are installed
∗ = Most optimum result for this column
x = Undetected
v = Supported
F = Only the fully paid version supports the feature
s = Remote control via SMS is also supported
sd = Backed up onto the device SD card
c = Backed up onto an online cloud server
AVG
Lookout
Avast
TrustGo
Norton
McAfee
ESET
Dr. Web
Kaspersky L
Kaspersky F
GPS
Locate
v
v
v
v
Fs
v
v
F
F
F
should be removed and pauses all scanning until it is granted
a response, so this should be taken into account when reading
its times above. It should be noted that Kaspersky F yielded
a higher detection rate than Kaspersky L.
The highest detection rates were netted by TrustGo, ESET
and Dr. Web who each detected 100% of the malware.
However, TrustGo also detected a false positive, Google Play
Services. Dr. Web consumed the least amount of memory
as well as its 100% detection rate, but has a relatively high
full system scan time. ESET holded the record as fastest for
both scanning times, but also consumed the largest amount of
memory, being more than twice that of AVG, the next largest
AVP.
It is also worth noting that excluding Kaspersky L, each
AVP can scan applications, SMS messages, files saved in real
time and all system storage including an SD card. However,
Lookout requires the full version in order to scan files saved
in real time. A nice feature of AVG is that it scans for insecure
settings, such as the device being rooted.
In all cases, a total of five malware evaded detection by
some AVPs. Table II is a table specifying which AVPs did
not detect the specified malware. From Table II it is clear that
TRacer evaded detection most often, which may be due to the
Firewall
AVG
Lookout
Avast
TrustGo
Norton
McAfee
ESET
Dr. Web
Kaspersky L
Kaspersky F
v
F
v
v
F
v
F
F
Parental
Schedule
Number
Controls
Scan
Blocking
v
F
v
v
v
v
F
F
v
F
F
v
F
F
v
Filter
Outgoing
Calls
v
F
TABLE V
M ISCELLANEOUS F EATURES
fact that it is the most recent malware in this experiment. To
see a more detailed results table of all malware, see Lally [80].
Each of the anti-theft features in Table III are performed
via a computer remotely. Avast and the paid version of Norton
require an external package to be installed to support all antitheft features, using more memory.
From Table IV, Avast allows the widest range of data to be
backed up, McAfee the next.
In the Table V, Number Blocking is the blocking of incoming calls and SMS messages from specific numbers.
A. Other Features
AVG employs a power settings menu to examine the most
power consuming processes, and options to restrict their power
consumption.
The paid version of Lookout allows the user to view the
personal data each application has access to.
Avast allows the user to set a maximum MN download
limit per month, shows the amount of data each application
downloaded on the MN and Wifi for each month, and allows a
MN maximum download limit per month for each application
to be set. It has a Task Manager to kill processes, and allows
the user to view Android privileges and what applications have
access to each.
TrustGo also allows an upper bounds on MN data per month
to be set, and also gives a breakdown of application MN data
usage. It gives an application battery usage breakdown and
again, a view of privileges and each application which has
that privilege.
McAfee allows the creation of profiles, where each profile
only has access to a subset of applications on the device. ESET
shows a list of device privileges and the applications which
have access to that privilege.
IX. E XPERIMENT T WO C ONCLUSION
There are many AVPs available with an array of tools at
their disposal. There is no one specific optimum AVP, however
each has their own appeal depending on the user’s intent. A
subset do appear better than others. For the highest malware
detection rate, TrustGo, ESET and Dr. Web provided the best
results, while if one were looking for the AVP with the widest
array of features with budget constraints, Avast yielded the
most optimum results. For a lightweight malware scanner with
little other functionality, Dr. Web would stand out. If high
detection rates and fast scans are desired when there are no
memory constraints, ESET would be advisable. In this authors
opinion, Kaspersky L provided too poor a malware detection
rate to use, and its inability to scan already installed programs
seems dangerous, but Kaspersky F’s prompting every time
malware was encountered was distracting as it prevented other
activities from being performed in the foreground. It should
be noted that McAfee did a more in depth SD card scan, as
it managed to locate each malware twice, the ones installed
on the device, and the ones installed on the backup Malware
Image stored on the SD card. Optimal antivirus programs
for Android will therefore be dependent on the needs and
preferences of the user. It should be noted that whenever an
AVP did not detect a Trojan, it is likely that that Trojan was
not present in it’s signature database, and could potentially
have be detected by a secondary behavioral based malware
detector, such as Experiment One’s the App Watcher.
ACKNOWLEDGEMENTS
I would like to thank: my supervisor Renaat Verbruggen,
who gave constant useful feedback on this project; my parents
and my sister for both funding and constantly encouraging me
in my life’s education; and my two cats for their companionship over many late nights composing this paper.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
Amadeo, R. Apps Ops: Android 4.3’s Hidden App Permissions
Manager, Control Permissions For Individual Apps! 2013. URL: http:
//www.androidpolice.com/2013/07/25/app-ops-android-4-3s-hiddenapp- permission- manager- control- permissions- for- individual- apps/
(visited on 08/19/2013).
Amazon. Amazon App for Android. 2013. URL: https://www.amazon.
com/gp/anywhere/sms/android (visited on 07/18/2013).
Android. Android Documentation: ActivityManager. 2013. URL: http:
//developer.android.com/reference/android/app/ActivityManager.html
(visited on 07/30/2013).
Android. Android Documentation: Debugging. 2013. URL: http : / /
developer.android.com/tools/debugging/index.html#tips (visited on
07/31/2013).
Android. Android Documentation: EventLog. 2013. URL: http : / /
developer.android.com/reference/android/util/EventLog.html (visited
on 07/29/2013).
Android. Android Documentation: FileObserver. 2013. URL: http :
/ / developer. android . com / reference / android / os / FileObserver. html
(visited on 07/31/2013).
Android. Android Documentation: Intent. 2013. URL: http://developer.
android . com / reference / android / content / Intent . html (visited on
07/31/2013).
Android. Android Documentation: Intents and Intent Filters. 2013.
URL : http://developer.android.com/guide/components/intents- filters.
html (visited on 07/31/2013).
Android. Android Documentation: logcat. 2013. URL: http : / /
developer.android.com/tools/help/logcat.html (visited on 07/29/2013).
Android. Android Documentation: Manifest.permission. 2013. URL:
http://developer.android.com/reference/android/Manifest.permission.
html (visited on 07/26/2013).
Android. Android Documentation: Package Index. 2013. URL: http:
/ / developer . android . com / reference / packages . html (visited on
07/31/2013).
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
Android. Android Documentation: PackageManager. 2013. URL:
http : / / developer . android . com / reference / android / content / pm /
PackageManager.html (visited on 07/27/2013).
Android. Android Documentation: Permissions, Write APN Settings.
2013. URL: http://developer.android.com/reference/android/Manifest.
permission.html#WRITE APN SETTINGS (visited on 07/31/2013).
Android. Android Documentation: Reading and Writting Logs. 2013.
URL: http : / / developer . android . com / tools / debugging / debugging log.html (visited on 07/29/2013).
Android. Android Documentation: RunningTaskInfo. 2013. URL: http:
/ / developer. android . com / reference / android / app / ActivityManager.
RunningTaskInfo.html (visited on 07/31/2013).
Android. Android Documentation: Runtime. 2013. URL: http : / /
developer. android . com / reference / java / lang / Runtime . html (visited
on 08/01/2013).
Android. Android Documentation: Security Tips. 2013. URL:
developer. android . com / training / articles / security - tips . html (visited
on 07/27/2013).
Android. Android Documentation: Settings.Global. 2013. URL: http:
//developer.android.com/reference/android/provider/Settings.Global.
html#HTTP PROXY (visited on 08/27/2013).
Android. Android Documentation: TrafficStats. 2013. URL: http : / /
developer . android . com / reference / android / net / TrafficStats . html
(visited on 07/30/2013).
Android. READ LOGS permission is not granted to 3rd party applications in Jelly Bean (api 16). 2012. URL: https://groups.google.
com/forum/?fromgroups=#!topic/android- developers/6U4A5irWang
(visited on 07/31/2013).
Android-Arts. Packet Sniffer. 2013. URL: https://sites.google.com/
site/androidarts/packet-sniffer (visited on 07/31/2013).
Android Developers. “What is android?” In: ht tp://developer. android. com/guide/basics/what-is-android. html 2 (2011).
Android Open Source Project. Debugging with TcpDump and other
Tools. 2013. URL: http : / / www . kandroid . org / online - pdk / guide /
tcpdump.html (visited on 07/31/2013).
Apple. Siri. 2013. URL: http://www.apple.com/ios/siri/ (visited on
07/18/2013).
Apple. What is iOS: iOS Home Page. 2013. URL: http://www.apple.
com/uk/ios/what-is/ (visited on 07/18/2013).
Asrar, I. Fake Vertu App Infects Korean and Japanese Android Users.
2013. URL: https : / / blogs . mcafee . com / consumer / fake - vertu - app infects-korean-and-japanese-android-users (visited on 08/17/2013).
ASUS. Eee Pad Transformer TF101. 2013. URL: http://www.asus.
com/Tablets Mobile/Eee Pad Transformer TF101/.
Avast. Google Play: Avast Mobile Security and Antivirus. 2013. URL:
https://play.google.com/store/apps/details?id=com.avast.android.
mobilesecurity&hl=en (visited on 08/19/2013).
AVG. Google Play: AVG AntiVirus Security - FREE. 2013. URL: https:
//play.google.com/store/apps/details?id=com.antivirus&hl=en (visited
on 08/19/2013).
BOI. Bank of Ireland Mobile Banking. 2013. URL: https://play.google.
com/store/apps/details?id=com.bankofireland.mobilebanking&hl=en
(visited on 07/18/2013).
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. ACM. 2011, pp. 15–26.
Ed Burnette. Hello, Android: introducing Google’s mobile development platform. Pragmatic Bookshelf, 2009.
Burnette E. How Android Works: The Big Picture. 2008. URL: http:
/ / www . zdnet . com / blog / burnette / how - android - works - the - big picture/515 (visited on 07/20/2013).
Andrew Charlesworth. “The ascent of smartphone”. In: Engineering
& technology 4.3 (2009), pp. 32–33.
Chebyshev, V. Mobile Attacks! 2013. URL: http : / / www. securelist .
com/en/blog/805/Mobile attacks (visited on 08/17/2013).
Sha Sha Chu et al. How Anti-Virus Software Works. 2013. URL: http:
//www-cs-faculty.stanford.edu/∼eroberts/cs181/projects/viruses/antivirus.html (visited on 08/22/2013).
Cisco. Cisco IronPort Sophos Anti-Virus Technology. 2013. URL: http:
//www.cisco.com/en/US/prod/vpndevc/ps10128/ps10154/anti virus
index.html (visited on 08/22/2013).
ClockworkMod. ClockworkMod Homepage. 2013. URL: http://www.
clockworkmod.com/ (visited on 08/10/2013).
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
[64]
[65]
Contagio. Contagio Mobile Malware Mini Dump Home. 2013. URL:
http://contagiominidump.blogspot.ie/ (visited on 08/19/2013).
CyanogenMod. About CyanogenMod. 2013. URL: http : / / www .
cyanogenmod.org/about (visited on 08/19/2013).
CyanogenMod. CyanogenMod Homepage. 2013. URL: http://www.
cyanogenmod.org/ (visited on 08/10/2013).
DiBona, C. Blog Entry about Open Source Security. 2011. URL:
https : / / plus . google . com / +cdibona / posts / ZqPvFwdDLPv (visited
on 07/26/2013).
Dr. Web. Google Play: Dr.Web Anti-virus. 2013. URL: https://play.
google . com / store / apps / details ? id = com . drweb . pro (visited on
08/19/2013).
Dusty. Introduction to Pen-testing Android Applications Part 1. 2012.
URL : http://penturalabs.wordpress.com/2012/06/07/introduction- topen-testing-android-applications-part-1/ (visited on 07/31/2013).
eLinux. Android Logging System. 2012. URL: http : / / elinux . org /
Android Logging System (visited on 07/29/2013).
William Enck, Machigar Ongtang, and Patrick McDaniel. “Understanding android security”. In: Security & Privacy, IEEE 7.1 (2009),
pp. 50–57.
EuroStat. Telecommunication Statistics. 2012. URL: http : / / epp .
eurostat . ec . europa . eu / statistics explained / index . php /
Telecommunication statistics (visited on 07/11/2013).
Forristal, J. Uncovering Android Master Key that makes 99Vulnerable.
2013. URL: http://bluebox.com/corporate- blog/bluebox- uncoversandroid-master-key/ (visited on 08/19/2013).
FortiGuard Center. Virus: Android/Fakemart.A!tr. 2012. URL: http :
//www.fortiguard.com/encyclopedia/virus/#id=4117117 (visited on
08/17/2013).
Gabor. Reading Log Programatically. 2011. URL: http : / / www .
helloandroid.com/tutorials/reading- logs- programatically (visited on
07/30/2013).
Nisarg Gandhewar and Rahila Sheikh. “Google Android: An emerging software platform for mobile devices”. In: International Journal
on Computer Science and Engineering 1.1 (2010), pp. 12–17.
GApps. Download Latest Google Apps (GApps) for Your Android
Device. 2013. URL: http : / / androidlegend . com / gapps/ (visited on
08/19/2013).
Goodin, D. Google Patches Critical Android Threat as Working
Exploit is Unleashed. 2013. URL: http : / / arstechnica . com / security /
2013/07/google-patches-critical-android-threat-as-working-exploitis-unleashed/ (visited on 08/19/2013).
Google. Android Home Page. 2013. URL: www.android.com (visited
on 07/18/2013).
Google. Google I/O Conference. 2012. URL: http : / / www. youtube .
com/watch?feature=player embedded&v=WDDgoxvQsrQ#t=1369s
(visited on 07/30/2013).
Google. Google Play Help: Update Apps on your Device. 2013. URL:
https://support.google.com/googleplay/answer/113412?hl=en (visited
on 07/29/2013).
Google. Google Play Home Page. 2013. URL: https://play.google.
com/store?hl=en (visited on 07/20/2013).
Google. Google Search for Android. 2013. URL: http://www.google.
com/mobile/search/ (visited on 07/18/2013).
Google. WRITE APN SETTINGS not available on Ice Cream Sandwich. 2012. URL: http://code.google.com/p/android/issues/detail?id=
24227 (visited on 07/31/2013).
Michael Gregg. Build Your Own Security Lab: A Field Guide for
Network Testing. Wiley. com, 2008.
Halliday, D. Security Alert: SpamSoldier. 2013. URL: https://blog.
lookout.com/blog/2012/12/17/security-alert-spamsoldier/ (visited on
08/17/2013).
Hamada, J. Android.Uracto Used to Trick Mothers, Anime Fans,
Gamers, and More. 2013. URL: http://www.symantec.com/connect/
blogs/androiduracto- used- trick- mothers- anime- fans- gamers- andmore (visited on 08/17/2013).
Huang, J. Android IPC Mechanism. 2012. URL: http : / / www .
slideshare.net/jserv/android-ipc-mechanism (visited on 07/26/2013).
InfoNation. Intercepting Android HTTPS Connection. 2012. URL:
2013-07-31 (visited on 07/31/2013).
Intellectual Flame Co., Ltd. Fliashlight Description. 2013. URL: https:
/ / play. google . com / store / apps / details ? id = com . intellectualflame .
ledflashlight.washer&hl=en (visited on 07/29/2013).
[66]
[67]
[68]
[69]
[70]
[71]
[72]
[73]
[74]
[75]
[76]
[77]
[78]
[79]
[80]
[81]
[82]
[83]
[84]
[85]
[86]
[87]
[88]
[89]
[90]
[91]
Intellectual Flame Co., Ltd. Flightlight App Information: Installation
Information. Tech. rep. 2013.
Ion, F. How CyanogenMod’s Founder is giving Android users their
Privacy Back. 2013. URL: http://arstechnica.com/gadgets/2013/06/
how- cyanogenmods- founder- is- giving- android- users- their- privacyback/ (visited on 07/31/2013).
ISE. Exploiting Android. 2008. URL: http://securityevaluators.com/
content/case-studies/android/ (visited on 07/26/2013).
Woongryul Jeon et al. “A practical analysis of smartphone security”.
In: Human Interface and the Management of Information. Interacting
with Information. Springer, 2011, pp. 311–320.
Jiang, X. Security Alert: New Stealthy Android Spyware – Plankton –
Found in Official Android Market. 2011. URL: http://www.csc.ncsu.
edu/faculty/jiang/Plankton/ (visited on 08/16/2013).
Johnson, R. Android Security Model. 2011. URL: http : / / www. cs .
sunysb.edu/∼rob/teaching/cse409-fa11/notes/09-19-alin-tomescu.pdf
(visited on 07/26/2013).
Sunita Kanaujiya, SP Tripathi, and NC Sharma. “Improving Speed
of the Signature Scanner using BMH Algorithm”. In: International
Journal of Computer Applications 11.4 (2010).
Kaspersky. Carberp-in-the-Mobile. 2013. URL: http://www.securelist.
com/en/blog/208194045/ (visited on 08/17/2013).
Kaspersky. Chuli.A. 2013. URL: https : / / www. securelist . com / en /
blog/208194186/Android Trojan Found in Targeted Attack (visited
on 08/16/2013).
Kaspersky. Google Play: Kaspersky Mobile Security. 2013. URL:
https : / / play. google . com / store / apps / details ? id = com . kms & hl = en
(visited on 08/19/2013).
Kaspersky. Google Play: Kaspersky Mobile Security Lite. 2013. URL:
https://play.google.com/store/apps/details?id=com.kms.free (visited
on 08/19/2013).
Kaspersky Labs. IT Threat Evolution: Q1 2013. 2013. URL: http :
//www.securelist.com/en/analysis/204792292/IT Threat Evolution
Q1 2013#12 (visited on 07/10/2013).
Killer Mobile. TRacer v.7.0 Manual. 2011. URL: http://killermobile.
com/manuals/TRa.pdf (visited on 08/17/2013).
Jonathan Lally. App Watcher. 2013. URL: http : / / appwatcherdcu .
blogspot.ie/ (visited on 08/29/2013).
Jonathan Lally. Project Results. 2013. URL: http://www.redbrick.dcu.
ie/∼banjo/AVPresults.ods (visited on 08/23/2013).
H. Leonard. There Will Soon Be One Smartphone For Every Five
People In The World. 2013. URL: http://www.businessinsider.com/15billion-smartphones-in-the-world-22013-2 (visited on 08/01/2013).
Elias Levy. “Approaching zero [attack trends]”. In: Security & Privacy, IEEE 2.4 (2004), pp. 65–66.
Lookout. DroidDreamLight, New Malware from the Developers of
DroidDream. 2011. URL: https://blog.lookout.com/blog/2011/05/30/
security- alert- droiddreamlight- new- malware- from- the- developersof-droiddream/ (visited on 08/16/2013).
Lookout. Google Play: Lookout Security Antivirus. 2013. URL: https:
//play.google.com/store/apps/details?id=com.lookout&hl=en (visited
on 08/19/2013).
Lookout. Security Alert: DroidDream Malware Found in Official
Android Market. 2011. URL: https://blog.lookout.com/blog/2011/
03 / 01 / security - alert - malware - found - in - official - android - market droiddream/ (visited on 08/06/2013).
Lookout. Security ALert: New DroidDream Light Variant Published
to Android Market. 2011. URL: https://blog.lookout.com/blog/2011/
07 / 08 / security - alert - new - droiddream - light - variant - published - to android-market/ (visited on 08/16/2013).
Mandiant. Mandiant APT1 Report. 2012. URL: http : / / intelreport .
mandiant.com/ (visited on 07/10/2013).
McAfee. Google Play: McAfee Antivirus Security. 2013. URL: https:
//play.google.com/store/apps/details?id=com.wsandroid.suite&hl=en
(visited on 08/19/2013).
McAfee Labs. McAfee Threats Report: First Quarter 2013. 2013.
URL: http : / / www. mcafee . com / us / resources / reports / rp - quarterly threat-q1-2013.pdf (visited on 07/10/2013).
Microsoft. The Smartphone Reinvented Around You: Windows Mobile
Home Page. 2013. URL: http : / / www . windowsphone . com / en - us
(visited on 07/18/2013).
Jelena Mirkovic and Peter Reiher. “A taxonomy of DDoS attack
and DDoS defense mechanisms”. In: ACM SIGCOMM Computer
Communication Review 34.2 (2004), pp. 39–53.
[92]
[93]
[94]
[95]
[96]
[97]
[98]
[99]
[100]
[101]
[102]
[103]
[104]
[105]
[106]
[107]
[108]
[109]
[110]
[111]
[112]
[113]
[114]
[115]
[116]
[117]
Jelena Mirkovic et al. Internet Denial of Service: Attack and Defense
Mechanisms (Radia Perlman Computer Networking and Security).
Prentice Hall PTR, 2004.
mitmproxy project. Android. 2013. URL: http://mitmproxy.org/doc/
certinstall/android.html (visited on 07/31/2013).
mobiVIGIL. AndroidS M SSend. 2013. URL: https : / / mobivigil .
techmahindra.com/ShowAdvisoryFile.php?File=Android SMSSend.
pdf (visited on 08/17/2013).
Muppala, J. Android Overview. 2012. URL: http : / / tinyurl . com /
muppalaandroidoverview2 (visited on 07/19/2013).
MyHowTo. Intercepting and Decrypting SSL Communications between Android Phone and 3rd Party Server. 2011. URL: http : / /
www . myhowto . org / java / 81 - intercepting - and - decrypting - ssl communications - between - android - phone - and - 3rd - party - server/
(visited on 07/31/2013).
Tyler Nighswander et al. “GPS software attacks”. In: Proceedings of
the 2012 ACM conference on Computer and communications security.
ACM. 2012, pp. 450–461.
Nilesh K. Interception Android Native Application. 2012. URL: 2012.
(visited on 07/31/2013).
Norton. Google Play: Norton Security Antivirus. 2013. URL: https://
play.google.com/store/apps/details?id=com.symantec.mobilesecurity
(visited on 08/19/2013).
Jon Oberheide, Evan Cooke, and Farnam Jahanian. “CloudAV: NVersion Antivirus in the Network Cloud.” In: USENIX Security
Symposium. 2008, pp. 91–106.
Open Handset Alliance. Android overview. 2011. URL: http://www.
openhandsetalliance.com (visited on 07/11/2013).
Yangil Park and Jengchung V Chen. “Acceptance and adoption of the
innovative use of smartphone”. In: Industrial Management & Data
Systems 107.9 (2007), pp. 1349–1365.
Prince M. The DDoS That Knocked Spamhaus Offline (And How We
Mitigated It). 2013. URL: http://blog.cloudflare.com/the- ddos- thatknocked-spamhaus-offline-and-ho (visited on 07/11/2013).
RIM. Blackberry from Research In Motion Limited Home Page. 2013.
URL : http://www.rim.com/index na.shtml (visited on 07/18/2013).
Rogers, M. The Bearer of BadNews. 2013. URL: https://blog.lookout.
com/blog/2013/04/19/the-bearer-of-badnews-malware-google-play/
(visited on 08/17/2013).
Margaret Rouse. RSA Algorithm (Rivest-Shamir-Adleman). 2005.
URL : http : / / searchsecurity. techtarget . com / definition / RSA (visited
on 08/29/2013).
RSA Labs. Anatomy of an Attack. 2013. URL: https://blogs.rsa.com/
anatomy-of-an-attack/ (visited on 07/11/2013).
D. Russell and GT Gangemi. Computer security basics. O’Reilly,
1991.
Samsung. Galaxy Ace, Samsung. 2011. URL: http://www.samsung.
com/galaxyace/ace overview.html (visited on 08/10/2013).
Satter R. Spamhaus Hit With ’Largest Publicly Announced DDoS
Attack’ Ever, Affecting Internet Users Worldwide. 2013. URL: http:
//www.huffingtonpost.com/2013/03/27/spamhaus- cyber- attack n
2963632.html (visited on 07/11/2013).
Security Ledger. Google Adds Detection For Obad Malware. 2013.
URL : https://securityledger.com/2013/06/google-adds-detection-forobad-malware/ (visited on 08/06/2013).
Spamhaus. Spamhaus Home Page. 2013. URL: http://epp.eurostat.
ec . europa . eu / statistics explained / index . php / Telecommunication
statistics (visited on 08/01/2013).
Stone-Gross, B. Stels Android Trojan Malware Analysis. 2013. URL:
http://www.secureworks.com/cyber- threat- intelligence/threats/stelsandroid-trojan-malware-analysis/ (visited on 08/17/2013).
Svajcer, V. Plankton Malware Drifts into Android Market. 2011. URL:
http : / / nakedsecurity. sophos . com / 2011 / 06 / 14 / plankton - malware drifts-into-android-market/ (visited on 08/16/2013).
Symantec. Android.Exprespam. 2013. URL: http : / / www. symantec .
com/security response/writeup.jsp?docid=2013- 010705- 2324- 99&
tabid=2 (visited on 08/16/2013).
Symantec. Android.Sumzand. 2012. URL: http://www.symantec.com/
security response/writeup.jsp?docid=2012-080308-2851-99 (visited
on 08/16/2013).
Symantec. Android.Tascudap. 2013. URL: http://www.symantec.com/
security response/writeup.jsp?docid=2012-121312-4547-99 (visited
on 08/17/2013).
[118]
[119]
[120]
[121]
[122]
[123]
[124]
[125]
[126]
[127]
[128]
[129]
[130]
[131]
[132]
Symantec. Android.Tetus. 2013. URL: http : / / www. symantec . com /
security response/writeup.jsp?docid=2013-012409-4705-99 (visited
on 08/16/2013).
Symantec. Android.Uranico. 2012. URL: http://www.symantec.com/
security response/writeup.jsp?docid=2012-052803-3835-99&tabid=
2 (visited on 08/16/2013).
Symantec. Sun Charger, the Latest Android.Sumzand Variant, Continues the Massive Spam Campaign. 2012. URL: http://www.symantec.
com / connect / blogs / sun - charger - latest - androidsumzand - variant continues-massive-spam-campaign (visited on 08/16/2013).
Symbian. Symbian Foundation Home Page. 2013. URL: www .
symbian.org (visited on 07/18/2013).
Trend Micro. Adding Android and Mac OS X Malware to the APT
Toolbox. 2012. URL: http://www.trendmicro.com/cloud- content/us/
pdfs / security - intelligence / white - papers / wp adding - android - and mac-osx-malware-to-the-apt-toolbox.pdf (visited on 08/06/2013).
TrustGo. Google Play: TrustGo Antivirus Mobile Security. 2013.
URL: https : / / play. google . com / store / apps / details ? id = com . trustgo .
mobile.security (visited on 08/19/2013).
TrustGo. Trojan!Extension.A - Complex Malware Escapes AV Detection. 2013. URL: http://blog.trustgo.com/trojanextension-a-complexmalware-escapes-av-detection/ (visited on 08/16/2013).
Unuchek, R. GCM in Malicious Attachments. 2013. URL: http://www.
securelist.com/en/blog?print mode=1&weblogid=8113 (visited on
08/17/2013).
Unuchek, R. The most Sophisticated Android Trojan. 2013. URL:
http://www.securelist.com/en/blog/8106/The most sophisticated
Android Trojan (visited on 08/17/2013).
Vasa, R. Data Storage and Retrieval. 2013. URL: http://apcmag.com/
data-storage-and-retrieval.htm (visited on 07/26/2013).
Westaway L. Samsung Galaxy Ace won’t be update to Ice Cream
Sandwich. 2012. URL: http : / / crave . cnet . co . uk / mobiles / samsung galaxy - ace - wont - be - updated - to - ice - cream - sandwich - 50006538/
(visited on 08/10/2013).
XDA Developers. ClockworkMod. 2013. URL: http : / / forum .
xda - developers . com / wiki / ClockworkMod Recovery (visited on
08/10/2013).
XDA Developers. Real APK Leecher - Download apk from your PC.
2012. URL: http : / / forum . xda - developers . com / showthread . php ? t =
1539375 (visited on 08/20/2013).
Stefano Zanero, Claudio Merloni, and Luca Carettoni. “Studying
bluetooth malware propagation: The bluebag project”. In: IEEE
Security & Privacy 5.2 (2007), pp. 0017–25.
Yajin Zhou et al. “Hey, you, get off of my market: Detecting malicious
apps in official and alternative android markets”. In: Proceedings of
the 19th Annual Network and Distributed System Security Symposium.
2012.