Tuesday, 18 June 2013

Introduction to Android App Pentesting - Setting up the environment

A short while back I had to figure out how to setup and pentest an Android and iOS financial app. Not having done either before and not really finding too much information on the interwebs I took bits and pieces of what I did find and put it into the basic setup I am going to demonstrate in this short write up.

This is not an all-in-one from setup to haxor, just a guideline to the basic setup.

As mentioned above this is just an introduction to setting up my environment for an Android app pentest and some of the basic things to look for, there are some great sources of information on the different kinds of flaws and issues but to really understand the information, you need to setup your environment and start playing around.

Depending on the app your assessing you will be looking at different things, for instance; a banking application may store credentials in various databases or even keep a full history of the HTTP session in some cache files that could contain some sensitive information. Other apps may open up various holes on devices that allow another process to query sensitive data from the app your assessing via content-providers.

Anyways back to setting up the environment, I use a Mac but this can easily be tweaked to run on Windows or Linux.

Setup the Android Virtual Device (AVD)

You will firstly need to download and install the Android SDK (ADT Bundle), which can be found at the below link:

There are versions for Linux, Windows and OSX. The ADT Bundle contains everything you will need including Eclipse, ADT plugins and Android platform tools.

Extract the SDK to a folder then run the Eclipse application.

Once the Eclipse interface is up and running you can then create and setup a new Android Virtual Device (AVD). This will be the emulated device which you will use to install, run and test the Android app your going to assess. On the Eclipse interface find the Android Virtual Device Manager as seen in the below screen:

There are various options for creating a new device, I usually setup a tablet device but certain apps are built for phone or tablet specific displays.

Once created we can then use the SDK emulator tools (using a terminal or command prompt) under the following locations:


Now we can run the newly created AVD image, in the terminal we execute the following command:

./emulator –avd {AVD Name}

At this point the test device will boot up in a new window on your base machine.

Setting up a Proxy

If your app makes use of a browser/web service you can also boot the device up and set a default proxy, so that if your app is talking to a web service etc. you can use a great tool like Burpsuite to proxy all communications through for your tinkering.

./emulator –avd {AVD Name} –http-proxy

This can also be set inside the already booted up device:

Home > Settings > Wireless & Networks > Mobile Networks > Access Point Names

There are a few other ways to set proxies these are just the two I use
The default device is very clean with very limited apps installed.You can find various sources to install extra Google apps and such, but for now I will show you how to install the Android app you are going to pentest.

Installing Android Apk

To install .apk files to the virtual device we use a tool under the SDK tools folder (platform-tools, but this can change on different releases) called adb.

./adb install {path to .apk}

The app should now be available on the device, either on the home page or under the applications page. You can run it inside the device, perhaps first run it and let it do its thing before you start poking around at files, folders etc, get some real data in there.

Accessing the device - shell

You will now want to have shell access on the device. A shell on the device is a good starting point when playing with the app and seeing what the app installs, directories created, file permissions and data stored.

To get a shell simply use the adb tool:

./adb shell

By default Android apps are installed under the /data/data/ directory:

Inside the apps main directory there are some interesting folders and databases.

Android apps make use of sqlite databases for storage of all kinds of data which could include usernames, passwords etc. You will need to get familiar with sqlite3 commands to easily query the databases on the device.

There are a few commands to learn, but here are the basics:

.table – will list all the tables in the database
.schema {table name} – will list the table structure
.quit – will exit

Here’s an interesting find, inside the database is a table called password and httpauth. You can then query these with select * from password

That’s pretty much the basic environment setup.

Sieve - An App to Test

MWR have released an Android test app appropriately named Sieve. The app has all kinds of holes and flaws to find. You can download a copy from here:


I think when it comes to Android or iOS apps, data protection is about the most important category on the list, as these devices are more susceptible to loss and theft than regular computers. In addition to this, cached data may get copied to various machines that are used for syncing and data could be stolen from there.

It has been found that mobile operating systems can cache sensitive information such as keystrokes and create snapshots (screenshots of running applications) for extended periods of time. Applications on Android devices may store sensitive information in the form of temporary files, .localstore files, or in client side SQLite databases, .db.

For more details on Android and iOS secure development, which you can use to develop your own security tests from look at:

MWR Information Security, has also development an amazing tool called Mercury. Mercury is a framework for exploring the Android platform; to find vulnerabilities and share proof-of-concept exploits.

In fact MWR have a few papers on Android security and even won some own2pwn at CanSecWest, so look them up for more info, great bunch of guys!