Welcome back, my rookie hackers!
Before we delve into this much anticipated section on "Hacking Android", we first need to understand a bit about the Android operating system.
The Android operating system was purchased by Google when it acquired a company named curiously enough, Android Inc., in 2005. A couple years later in 2007, Google and a few other companies started the Open Handset Alliance for the purpose of developing open standards for mobile computing. This group then developed Android, based upon the Linux kernel 2.6. The first phone to use the Android OS was released in 2008.
The Android Model
To effectively hack the Android operating system, we need a basic understanding of Android architecture. Android, like nearly any other platform, has a stack of layers. The figure below details the multiple layers of the Android platform.
Each layer provides some service to layers above it. Let's take a look in detail at each of these layers.
The Linux Kernel Layer (Red)
The Android OS is built on the Linux kernel with some minor changes by Google. This kernel is responsible for the core functionality such as process management, memory management, security and networking.
The next layer in the Android architecture are the Android native libraries. These libraries, similar to Linux, are written in C or C++ and help the device handle different types of data. Probably most importantly, the runtime libraries are responsible for running applications on Android and includes the Dalvik virtual machine.
Dalvik Virtual Machine (Yellow)
All the applications on the Android platform are written in Java. As you know, when Java is compiled, we get bytecode. A Java Virtual Machine can execute this bytecode, but Android uses a special type of virtual machine to run its bytecode, the aforementioned Dalvik Virtual Machine.
Our Android OS Dalvik VM runs bytecode that is converted by the Dex compiler. The Dex compiler converts the byte code into a more efficient form requiring less power and resources for our mobile devices.
This is the uppermost layer where the user interacts with the device. Applications are of two types, pre-installed and user-installed. User-installed applications are downloaded from multiple places, but most often from the Google Play Store.
Android was designed with security in mind. The developers enforce features that help to keep the user data safe through multiple layers of security. These features include; a permission model and an application sandbox among others. Let's examine these two security features.
Any Android application must be granted permissions to access sensitive functionality such as the Internet, dialer, location, etc. by the user installing the app (unfortunately, most people simply click OK when installing apps without being discerning of the permissions they are offering). This model helps to keep malicious software from being installed on the device given that the user takes the time to think and decide what are acceptable permissions to give to the app.
In Android, each application runs as a unique user that ensures that each application is sandboxed at the kernel level. Like Linux, the kernel makes use of UID and GID restrictions, so that an application can not access data of another user.
Android File Hierarchy
To hack the Android system, we need to understand the Android file system hierarchy. If you are familiar with the Linux file system hierarchy, you will find Android relatively familiar. The Android file system is a customized version of the Linux file hierarchy.
The following a a brief list of the most important folders in Android from the hacker perspective.
This directory contains most of the system related files other than the kernel. This is comparable to the / directory in a standard Linux system, so you will find such sub-directories as bin, etc, lib, media, usr and others.
This directory contains each applications data. SMS messages, contacts and dialed numbers all reside in the /data directory.
The home directory of the root user.
All Android applications must be digitally signed by the developer. The developer holds the private key and when the developer wants to provide updates and other activities with the applications, they must use the same key.
In my next installment in this series, we will examine the Android file system.