A Secure Android

An in-depth look at the Android OS

Zachary Douglass

Computer Science: Networks

Radford University
Radford, United States
zdouglass@radford.edu
AbstractSince the turn of the millennium, mobile devices
have become a popular medium for connecting with others,
conducting business, and keeping up with every day life.
Harnessing the power of a laptop with the ability to fit into a
users hand, smart phones have become the go to for millions of
mobile subscribers. Although modeled after other traditional
desktop designs, smart phones are much more complex than
their originators. Combining cellular and network
communications, attacks are more prevalent and security must
be tougher. Taking a look at Googles open-source project,
Android, Ill be providing Androids operating system
architecture, the most common attacks against it, and how to
prevent these attacks.

HISTORY OF ANDROID
Google Inc. first released Android in September
2008. They called it Android 1.0, but later took to
the idea of giving it a sweeter name. Version 1.5,
for example, was dubbed CupCake and its most
recent version, 4.2, is named Jelly bean. You get
the idea. This was the birth of Googles opensource project, which has claimed global
creditability since it was first released to the
public. The project is based off the Linux kernel
with each application written in Java. All
applications are compiled through the Dalvik
Virtual Machine, which is Googles Android
specific virtual machine. [2]
I.

ANDROID ARCHITECTURE
The Android operating system was written on
top of the Linux operating system. Much of the
design principles are the same providing strong,
secure means of managing applications, memory,
and data. Figure 1 models the Android operating
system and as you can see resembles a traditional
desktop operating system, just on a smaller scale.
II.

Figure 1

The Android OS Architecture

The first layer of the model is the kernel and this

is where the drivers are located along with power
management. This level not only combines the
security of the Linux kernel, but also a system
called IPC, inter-process communication. The IPC
is primarily used to ensure secure communication
between application processes. The next layer
incorporates the operating systems core native
libraries in association with the Dalvik Virtual
Machine. Sitting on top of the operating system,
there is a framework of applications that are
sandboxed in order to keep them from accessing
OS-specific data. A three-class permission model
is implemented similarly to desktop and laptop
computers. [1] There is an owner, groups, and
other users. The owner, who has root permissions,
means they can read, write, and execute files.
Groups and other users have specific permissions
given to them. For example, the super user may
only grant read permissions to groups and
possibly no permissions at all for other users.
Android has to be more precise with file

permissions though, since applications require

more permissions than do normal computer
programs and applications. In a technique called
sandboxing, Android separates applications
from the operating system to ensure safety and
security.
DREAD THE PLAY STORE
The most common attacks are from Googles app
store. Better known as Google Play, it cannot be
monitored twenty-four seven so Androids kernel
must differentiate applications permissions. When
an application is downloaded for example, under
normal circumstances it would be written to the
users file system and now the application can
access all super users files. The whole point of
operating systems is to prevent user processes
from tampering with other processes. In this case,
Android will assign a newly downloaded
application ID, different from the operating
system, so that it can only have access to its own
ID. Think of it as the operating system being a
building and each individual application are
different rooms. Once the application is
downloaded, the doors are shut and locked and
only the super user can unlock and access these
rooms. This system does have flaws though. For
example, if an application is requesting multiple
permissions, the user must grant all of them or
else the application will not be downloaded. Back
to the building analogy, each rooms door is still
shut and locked, but now certain rooms have
doors connected to each other from inside. The
architecture is dubbed Sandbox and this is how
Android keeps applications separated from other
system processes. The appropriateness of
permissions is hard to judge and often users will
go ahead and download the application anyway.
[1] The problem with applications requiring
permissions from multiple points from the
operating system is that infected applications can
now access most resources on the phone. The ease
of creating and uploading applications to the Play
Store is growing tremendously and now anyone
can create and publish applications onto the store.
Due to its availability to all Android users, the
III.

Play store is the main channel of malware

distribution. [1] Instead of paying for
applications, most users download free
illegitimate copies of paid applications and this is
where most infections originate. In a process
called repackaging, attackers will download the
paid application, alter the code and repost the
application under the same name. The process is
very similar to code injection, where the attacker
will write malicious code within the application
and when a user downloads it, the code will work
in the background sending important information
back to the attacker. Many of these applications
are uploaded to third-party stores; so in order to
stay safe, dont download anything if it isnt from
the Play store. Google is aware of the massive
amounts of malware being uploaded to the Play
store, with 94.8% of malware being designed
specifically to attack Android. [3]
Bouncer
In order to defend against this growing
problem Google designed Bouncer. Bouncer is
a system that automatically scans newly created
applications along with developer accounts [4]
for malware, spyware, and trojans. If any of these
are detected, along with any misbehaving
applications, they are immediately flagged for
removal. The effectiveness of Bouncer proves to
be tremendous. Acting with a mind of its own,
Bouncer checks the behavior of applications and
stores how they should be running. If Bouncer
encounters an application that is acting out of the
norm, it will take a closer look. Last year,
Bouncer aided in the removal of up to forty
percent of malicious applications, but with a
number of attackers growing smarter, Bouncer
might not be able to keep the Play store as safe as
it would like. [4] Nonetheless, Bouncer was a key
benefactor in the discovery of the widest ranging
malware
attack
on
the
market:
Android.Counterclank.
A.

Android.Counterclank
Andoird.Counterclank is a Trojan horse
commonly found in the Android operating system.
The virus is a modification of Android.Tonclank,
B.

a bot-like threat that can receive commands to

carry out certain actions, as well as steal
information from the device. [7] The virus is in
connection with a few popular applications
including Balloon Game, Sexy Women
Puzzle, and Hit Counter Terrorist. All sounding
very amusing, misguided users will unknowingly
download one of these applications and risk the
loss of precious data. The Trojan works by
installing a script into the application called
apperhand. [7] Once the user downloads the
infected application, it will communicate back to
the host via cellular or network communications,
who also have the apperhand package installed.
Now the two packages are able to communicate
and send data to, and from each other. Infected
users will notice a Search icon located in the
home screen of the phone. Users who notice this
icon can than take affirmative action by
uninstalling any of the above applications to
ensure the device is back to normal.
LENGTHY PATCHES
Once a phone has been infected with malware,
Googles ability to fix the problem is a lengthy,
time consuming process. In addition, a new patch
may render a phone useless based on the type of
phone it is, the carrier its being used on, and even
the geographic location. [6]. Data limitations
may be applied and even certain hardware
components may fail based on the patch. After
weeks, possibly months of coding a new patch, a
new ROM may be installed onto the phone and
this is where the problem lies. If the new patch is
in fact substantial enough to fix a users phone,
much time has already passed. A user could have
already received a new phone or even switched
service
providers.
Manufacturers
usually
discontinue older versions of software as well,
leading to software that never gets tested. Carrier
services that are less known, for example, Cricket
or nTelos, use older versions of software because
they have yet received the rights to use newer
versions of software. This leads to many
customers using threatened software and once
more leads to the advancement of malicious
applications.
IV.

KEEP YOUR COOL

The range and extent of malicious applications
along with multiple means of intrusion give the
sense that Android might not be as suitable as it
sounds. Users are not the only ones who are
concerned about these matters though. Companies
like Symantec and AISEC are working very hard
to keep the people enjoying a worry-free life.
AISEC, for example, has created an exploit
execution framework, which gives them the
ability to test malicious code in a safe
environment. With our framework, we are able
to analyze exploitability of devices with specific
test sets and payloads in a semi-automatic
manner. [1] The execution framework
application is useful in the sense that it doesnt
have to alter code or update itself based on which
device it is testing. The application extracts a
specific vulnerability from a device thus, can be
distributed to many different devices and executed
simultaneously. [1] The framework works by
first downloading the configuration file. From
there, the application decides which type of
exploit it would like to run. Then, depending of
the device the framework is testing chooses a
version of the exploit to run. E.g., Exploid,
Zimperlich,
KillingInTheNameOf,
KillingThemSoftly, or GingerBreak. (These are
applications that give root access, or full
privileges to a device.) Finally, the framework has
full access to a device and can sift through to
exploit any vulnerability the device may have.
V.

Figure 1.2:

Debugging Process

Figure 1.2 shows how a vulnerability was found

and debugged properly with AISECs exploit
execution framework.
CONCLUSION
The mobile phone revolution is still in its
infancy and with millions of people joining each
day, the industry must keep a close eye on its
customers. Although Android is a highly regarded
open-source project that provides users with
functionality and security, it must be careful of the
viruss, malware, and spyware that affect users
everyday. Android provides a strong infrastructure
for safe computing combined with other
companies to provide the best product the world
has ever seen.
VI.

REFERENCES
[1]

[2]

[3]

Fedler, Rafael, Christian Banse, Christoph Krauss, and Volker

Fusenig. "Android OS Security:
Risks and
Limitations." Http://www.aisec.fraunhofer.de/. AISEC, May 2012.
Web.
7
May
2013.
<http://www.aisec.fraunhofer.de/content/dam/aisec/de/pdf/tech
%20reports/AISEC-TR-2012-001-Android-OS-Security.pdf>.
Ehringer,
David.
"The
Dalvik
Virtual
Machine
Architecture." Http://show.docjava.com/. N.p., Mar. 2010. Web. May
2013.
<http://show.docjava.com/posterous/file/2012/12/10222640The_Dalvik_Virtual_Machine.pdf>.
Misra, Amit. "Google Inc (GOOG) Android Failed to Fight Against
Malware: Infections Tripled in 2012." Dazeinfo RSS. Dazeinfo,
17Apr.
2013.
Web.

[4]
[5]
[6]

[7]

May2013.<http://www.dazeinfo.com/2013/04/17/google-inc-googandroid-failed-to-fight-against-malware-infections-tripled-in-2012/>.
Albenenius, Chloe. "Google 'Bouncer' Now Scanning Android
Market for Malware."PCMAG. PC Magazine, 2 Feb. 2012. Web. May
2013. <http://www.pcmag.com/article2/0,2817,2399778,00.asp>.
Google Inc. "Tech Info." Android Security Overview. Google Inc.,
n.d. Web. May 2013. <http://source.android.com/tech/security/>.
Vidas, Timothy, Daniel Votipka, and Nicolas Christin. All Your Droid
Are Belong To Us: A Survey of Current Android Attacks. Usenix.
Usenix,
n.d.
Web.
May
2013.
<http://static.usenix.org/event/woot/tech/final_files/Vidas.pdf>.
Asrar, Irfan. "Android.Counterclank Found in Official Android
Market." Weblog post.Endpoint, Cloud, Mobile & Virtual Security
Solutions. Symantec, 27 Jan. 2012. Web. May 2013.
<http://www.symantec.com/connect/blogs/androidcounterclankfound-official-android-market>.

[8]
[9]
[10]
[11]
[12]