Welcome back to the "Android Mobile Application Penetration Test Tricks" blog series! We'll continue to examine techniques that you can use while performing your own mobile application penetration tests. In our last installment we configured BusyBox, and in this installment we'll utilize BusyBox functionality in order to monitor filesystem changes during mobile application execution. Let's jump right in! First launch the emulator with the "partition-size" and "no-snapshot" options:
$ emulator64-arm -avd myEmulator -partition-size 512 -no-snapshot
As discussed in the last installment, setting the "partition-size" option to a large value such as 512 MB will allow us to make changes to the "/system" partition. Including the "-no-snapshot" option prevents hardware configuration conflicts introduced by the "partition-size" option. By default the /system partition is mounted read-only, so you'll need to remount this partition read/write by launching the ADB (Android Debug Bridge) shell and executing the following command:
$ adb shell
root@android:/ # mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system
Now you can create a file with the current time of last modification
root@android:/ # touch /mnt/sdcard/timestamp
The touch command creates a file if it does not exist, or updates the time of last modification if the file already exists. Next you can perform some action within your Android application. In this case I will simply use the Android Contacts application in order to add a new contact. Now you can utilize BusyBox's find command in order to search the filesystem for files that have been modified. The basic command uses the "newer" option and looks like this:
root@android:/ # find / -newer /mnt/sdcard/timestamp
However, this command will return massive amounts of extraneous output from the /proc and /sys directories. These directories can be filtered with the "prune" option. In addition, let's also filter the /dev directory and polish the output using the grep command:
root@android:/ # find / \( -type f -a -newer /mnt/sdcard/timestamp \) -o -type d -a \( -name dev -o -name proc -o -name sys \) -prune | grep -v -e "^/dev$" -e "^/proc$" -e "^/sys$"
/data/data/com.android.inputmethod.latin/files/contacts.en_US.dict
/data/data/com.android.providers.contacts/databases/contacts2.db
/data/data/com.android.providers.contacts/databases/contacts2.db-journal
/data/data/com.android.providers.contacts/shared_prefs/ com.android.providers.contacts_preferences.xml
/data/system/dropbox/system_app_strictmode@1364420115012.txt
/data/system/dropbox/system_app_strictmode@1364420064936.txt
This gnarly looking command finds all files that have been modified since we touched the timestamp, filtering out the /dev, /proc, and /sys directories. Note that in rare instances random subdirectories may happen to be named "dev", "proc", or "sys". These subdirectories will appear within the output, but the find command will not descend into these directories. Keep this in mind if you see an entry with one of these names. Consider the following example:
root@android:/ # mkdir /data/proc
root@android:/ # touch /data/proc/sneakyFile
root@android:/ # find / \( -type f -a -newer /mnt/sdcard/timestamp \) -o -type d -a \( -name dev -o -name proc -o -name sys \) -prune | grep -v -e "^/dev$" -e "^/proc$" -e "^/sys$"
/data/proc
/data/data/com.android.inputmethod.latin/files/contacts.en_US.dict
/data/data/com.android.providers.contacts/databases/contacts2.db
/data/data/com.android.providers.contacts/databases/contacts2.db-journal
/data/data/com.android.providers.contacts/shared_prefs/ com.android.providers.contacts_preferences.xml
/data/system/dropbox/system_app_strictmode@1364420115012.txt
/data/system/dropbox/system_app_strictmode@1364420064936.txt
In this case the /data/proc subdirectory should be manually searched for files that have been modified:
root@android: # find /data/proc -newer /mnt/sdcard/timestamp
/data/proc
/data/proc/sneakyFile
Now you can monitor what local files your Android application is modifying! Next you could manually inspect these files in order to determine exactly what information your application is storing. Alternatively, BusyBox's find command can directly invoke the grep command for powerful functionality. For example, consider an application that might be storing authentication credentials within the filesystem. You can use the following command to search modified files for authentication credentials:
root@android: # echo username:password > /data/badApplication.txt
root@android: # find / \( -type f -a -newer /mnt/sdcard/timestamp -exec grep -l password {} \; \) -o -type d -a \( -name dev -o -name proc -o -name sys \) -prune
/data/badApplication.txt
Let's wrap up by creating functions to simplify command line syntax:
root@android:/ # vi /system/vendor/modified-functions
Now copy and paste the following content into the modified-functions file:
modified-list()
{
find / \( -type f -a -newer /mnt/sdcard/timestamp \) -o -type d -a \( -name dev -o -name proc -o -name sys \) -prune | grep -v -e "^/dev$" -e "^/proc$" -e "^/sys$"
}
modified-search()
{
find / \( -type f -a -newer /mnt/sdcard/timestamp -exec grep -l $1 {} \; \) -o -type d -a \( -name dev -o -name proc -o -name sys \) -prune
}
Next source the functions file:
root@android:/ # source /system/vendor/modified-functions
That's it! Now you can list files that have modified after /mnt/sdcard/timestamp with the dramatically simpler modified-list function:
root@android:/ # modified-list
/data/data/com.android.inputmethod.latin/files/contacts.en_US.dict
/data/data/com.android.providers.contacts/databases/contacts2.db
/data/data/com.android.providers.contacts/databases/contacts2.db-journal
/data/data/com.android.providers.contacts/shared_prefs/ com.android.providers.contacts_preferences.xml
/data/system/dropbox/system_app_strictmode@1364420115012.txt
/data/system/dropbox/system_app_strictmode@1364420064936.txt
And you can search files that have been modified after /mnt/sdcard/timestamp with the dramatically simpler modified-search function, passing the desired search string as the parameter:
root@android:/ # modified-search password
/data/badApplication.txt
Pretty cool, eh? Well that's all for this installment the "Android Mobile Application Penetration Test Tricks" blog series! Soon we'll be back to examine more techniques that you can use while performing your own mobile application penetration tests. Cheers!