Forensics on Android phones and security measuresFri 22 June 2012 by cedric
iPhone forensics has been well studied by lots of security people (and our team). Android is less looked at probably because there is less challenge for hackers (because of openness) and also because of the heterogeneity of devices. On mobile devices, forensics is possible as soon as you get code execution on them. If there is a defined passcode, a forensics guy/attacker would need to get code execution before the operating system starts in order to bypass this passcode. Usually, this code execution can be thought as a vulnerability in the bootloader.
This post deals with analyzing the forensics methods available on Android phones before Ice Cream Sandwich (4.x). So it will work on any device running Android 2.x and below.
As explained, doing forensics implies getting code execution at a low level (before the operating system starts). Low-level code embedded in the firmware usually comes from manufacturers (and not from the Google AOSP). Consequently, it is not really accurate to talk about Android forensics. More precisely, we should talk about forensics on mobile devices that run Android.
We will focus on HTC phones in this post (because we have been working a lot with these devices until now) but we will definitely get back for more details on other manufacturers as soon as possible. We already detailed a method that allowed us to dump files from the bootloader in a previous post but the proposed method in this post is more generic.
The default boot process takes place by starting code from bootloaders until HBOOT (a bootloader as well). From this, it is possible to start the regular operating system (Android) or a special mode called the "recovery mode". HBOOT also allows to communicate with it in this mode or using a protocol called "fastboot".
By default, HBOOT allows to reflash the "boot" or "recovery" partition by putting a signed "update.zip" file or to boot code by putting a signed .nbh file on the sdcard. Everything needs to be signed. Moreover, the fastboot protocol that is proposed by the AOSP does not allow to reflash the device. And finally, the stock recovery image is simple: it basically allows to reset the device in its original state (erasing the data partition).
The idea behind unlocking a device is to allow the use of "fastboot" to reflash the device. Consequently, it is possible to flash any custom (unsigned) ROM. The process is detailed in a previous post. What we can say about this process is that it needs to erase the user partition so it can not be used in a forensics analysis.
The idea behind disabling the security flags of a device (i.e. putting the device in S-OFF) is to give a total control on it. If the device is S-OFF, HBOOT will accept any (unsigned) custom ROM (update.zip or .nbh file). It is often used by manufacturers to deliver engineering phones that allow developers to reflash all partitions (including HBOOT itself).
If we need a forensics method, it means the Android device we hold has a defined passcode and we can not (at first) bypass it. There are 3 kinds of passcode in the Android world: scheme, PIN code and password.
We have chosen to use the XTC clip to disable the security flag of HTC phones. It supports (almost) all HTC phones and HBOOT versions. Without going into too much detail, this tool uses a signed debug .NBH file and a "fake" SIM card to literally ask the baseband to make the device S-OFF.
Loading an alternative boot
From now on, it is possible to push an "update.zip" file containing a custom recovery that will allow us to boot in recovery mode and extract the files we want. If we need, we will always be able to restore the original recovery with the exact same procedure.
Another method consists of pushing an "update.nbh" file on the SDcard with code to disable the LOCK state. Then, one can reboot in HBOOT mode and use the fasboot commands. It is less intrusive and also reversible.
Getting sensitive data
From the recovery mode, we are able to mount the user partition, bypassing the Android passcode. We can get some databases such as: calendar.db, mmssms.db, facebook.db, browser.db, telephony.db, contact2.db, etc.
If we want, we can get the following files: settings.db, password.key, gesture.key. Then we are able to bruteforce the passcode - offline (from the PC). It only takes a few minutes for a scheme (any) or a basic PIN code (e.g. 4 digits). However, there is no real need since nothing is ciphered with the passcode.
Alternative note: with this method, an attacker could also inject a backdoor in the system partition. It is possible because there is no signature check of what is loaded from the flash (contrary to the iOS architecture).
If we need to restore the device to its original state, we can reflash an original recovery image, relock the device using a custom "update.nbh" file. Restoring the security flag is more complicated but we managed to make it work on an HTC Desire Z by directly sending a command to the baseband. This procedure takes place in 4 steps:
- put the device in HBOOT mode (hold down and press power)
- select the fastboot mode from the menu
- issue the "fastboot oem rtask C" command from the PC
- send the "AT@SIMLOCK=7,1" command to one of the USB serial (using usbserial in Linux for example)
With this procedure, we managed to access the personal data or inject a backdoor in the mobile phone. We used the XTC clip to disable the security. Disabling the XTC clip capabilities is possible by replacing the RSA public key of HTC in HBOOT. This procedure needs to be made manually and it may void the warranty but it is the only known solution to this problem. Consequently, the debug "update.nbh" files (signed by HTC) will not be accepted anymore by the device.
This study also serves as basics for forensics on Android 4.x since there is now a way to cipher the entire device (such as the Samsung Galaxy Nexus).
Source code is available in github. It allows you to:
- create/parse NBH files
- create/extract .img files (such as boot.img and recovery.img)
- bruteforce any passcode