The following recipe shows you how to do some snooping on your Android applications. Namely, find out what kind of data structures they are using to store important information and what kind of information they are storing, for example, high scores, passwords, contacts, and e-mails. Besides allowing you to set your high score to a negative number, this is an effective way for you to influence application behavior from its backend. It also gives you a perspective on how applications protect their users' data, for example, is the data encrypted? How is it encrypted? Does the application protect the integrity of the user data? It also makes for a very useful skill when reverse engineering and assessing application security.
Unfortunately for this one, you will need either a "rooted" phone or an emulator, because you already have root access on emulated devices.
If you want to get access to the resources of other apps, you will need root permissions. If you want to study the behavior of applications from the market, nothing prevents you from pulling them off of your device using ADB and installing them on a virtual device.
You will also need to install the Android SDK.
Listing files on an Android device can be done in the following ways:
- Drop a shell on your Android device with the help of the following command:
adb shell [options] - Navigate to the
/data/data/directory:cd /data/data/The directory should look similar to the following screenshot:
If you list the file permissions, creation, modification, and other metadata, it should look like the following screenshot:
Notice the owners and groups of the data directories, the first and second columns from the left in the listing. The owners here are actual applications. Linux, by default, runs each application as its own Linux user, which is essentially how the application sandbox operates. When an app is given permission to a resource that it inherently doesn't have access to, Linux puts it in the relevant user group.
- Execute the following command if you wish to see all of the application resources and metadata in one go:
ls –alR */
But, typically, you wouldn't want your screen to be flooded with a massive directory listing unless you're redirecting it to a file. You may want to display only the databases:
ls –alR */databases/
Or, maybe display just the files or whatever that is saved in the
/files/directory for each application:ls –alR */files/
Or, you could even search for a given type of file, by specifying an extension; here are a few examples:
ls –al */*/*.xml ls –al */*/*.png ls –al */*/*.mp3
- Once you've found the files you're looking for, all that you need to do is copy them onto your machine using a good old
adb pull:adb pull /data/data/[package-name]/[filepath]
All we're really doing here is listing different file types. One of those types is sqlite3 databases, the DB files that you would have seen in some of the directories. I'm sure you're dying to know how to crack them open and have a look at what's inside. This is how it's done.
Before we get going, you will need to make sure that sqlite3 is installed; it comes shipped with the Android SDK.
In this chapter, we covered some of the mechanisms that protect applications, some basic protections that involve inter-application communication, application permissions, as well as the cryptographic signatures, and filesystem-related access protections.
What you should take away from here are the tips and tricks needed to perform the security mechanisms by hand. This allows you to assess the effectiveness of these mechanisms independent of the Android devices enforcing them, and also allows you to interact directly with them, hopefully allowing you to understand them better.