Application security

Examining Android App Specific Data on Non-Rooted Devices

In all of our previous articles so far in this series, we discussed all the examples only on rooted devices and emulators. Generally, there are people who argue that it is not possible to exploit certain vulnerabilities such as insecure data storage on non-rooted devices. In this article, we will discuss how to examine the internal memory of Android apps on non-rooted devices using the backup feature. It is possible to get the backup of a specific application package or the whole device in order to examine it. This allows us to perform an analysis on the data that is being stored on the local device at runtime.

Prerequisites:

1. usbdebugging should be enabled on the device.

2. adb - it comes along with Android SDK

3. You can download the sample app below.

4. The next step would be to download adbextractor, which contains a set of tools required to do our job.

We can download adbextractor from the link below.

http://sourceforge.net/projects/adbextractor/

After downloading, extract the contents from the downloaded zip file. We can do this from the command line using the unzip command.

[plain]

unzip android-backup-extractor--20140630-bin.zip

[/plain]

We should now have the following tools with us. In this article, we are going to use "abe.jar" only.

Let us now create a working directory called "backup", so that everything can be carried out in the same folder to avoid confusion. We are going to use the same setup for some other concepts. So make sure you have the same setup in order to follow the steps along with me.

Place abe.jar extracted in our working directory as shown in the figure above.

The first step would be to launch our target application and insert some data:

The data we entered into this application will be inserted into a database. So let's check if the data is inserted or not. I am using an emulator for this purpose.

As we can see in the above figure, I have navigated to the location of the target package. We have a database named PWNSQLITEDATA.db in there.

We can have a look at the contents using the SQLite3 command line tool as shown below.

Everything looks OK.

Now, our job is to examine the same on a non-rooted device. So, let us begin.

We are going to use an Android feature which allows us to make a backup of the application. We can use "adb" to accomplish this.

First, let us see the options available with the "adb backup" command.

As we can see in the above figure, we can make a backup of all system apps as well as user installed apps. We can also make a backup of a specific package by specifying the package name.

So, let us use the following command to get the backup of our target app.

[plain]

adb backup -f <filename><package name>

[/plain]

The command in our case now becomes:

[plain]

adb backup -f mybackup.ab com.androidpentesting.sqlitestorage

[/plain]

This is shown below.

The above command needs user interaction as it waits for the user to click the "backup my data" button on the device. If you want, you can set a password and encrypt the backup. I am not encrypting the data here. This looks as shown in the figure below.

Once you click the button, it will create a new file in our working directory.

As we can see in the above figure, we have an additional file named "mybackup.ab" in the same directory.

We cannot directly read the contents of this file. So, we need to convert it into a format which we can understand.

This is where we are going to use the abe.jar tool, which is already there in our working directory.

First, let us see the help command of the abe.jar tool using the following command.

[plain]

java -jar abe.jar --help

[/plain]

This looks as shown in the figure below.

As we can see, we can use abe.jar to pack or unpack the backup file. So, let us use the "unpack" option to unpack the backup file. As we can see in the help, we need to specify the target file as ".tar".

Now, the backup file has been converted to a tar file and it should be in our working directory.

We should now extract the contents using tar command. It extracts all the contents to "apps" folder, as shown in the figure.

[plain]

tar -xf mybackup.tar

[/plain]

The following figure shows the structure of the folder, which was created in the previous step.

It has a folder with the name of the package. Inside that, a file named _manifest and directory named "db" are created.

Usually, db contains all the databases. If the app contains any sharedpreferences, all that data would reside inside a directory named "sp".

If we observe, we have the database associated with our target app. "PWNSQLITEDATA.db"

We can now look at the contents of the database we got using a SQLite3 client.

I am using the SQLite3 command line tool as shown below.

As we can see in the above figure, we are able to see all the data associated with the apps database. This is how apps like DroidExplorer get a backup from our device.

Note: This method is useful even for forensic examiners in case they want to recover deleted data from SQLite databases. The files can be given to a hex editor and then search for specific keywords.

Conclusion

It is pretty clear that, even if the device is not rooted, we can access the data associated with the app if we have physical access to the device. We can also alter the data of a specific app using this method. If an app is storing data on the client side and making simple passcode or pin checks, it is possible for an attacker to remove and bypass those checks using this method. In the next article, we will discuss how to take advantage of this method to alter app specific data on a non-rooted device.