Our new workshop about mobile application testing, held for the 1st time at the Troopers conference 2013, is coming closer. So I would like to take the opportunity and post an appetizer for those who are still undetermined if they should attend the workshop ;-).
While the topic of mobile application testing is a wide field that may contain reverse engineering, secure storage analysis, vulnerability research, network traffic analysis and so forth, in the end of the day you have to answer one question: Can I trust this application and run it on my enterprise devices? So first you have to define some criteria, which kind of behavior and characteristics of an application you regard as trustworthy (or not). Let us peek at malware … besides harming your devices and data, malware is typically:
obfuscated and/or encrypted
contains anti-debugging features
contains anti-reverse engineering features
This makes the analysis process a difficult task and comparing these characteristics especially to ordinary iOS applications from the AppStore, at least one is also true for these apps: Those are encrypted and are only decrypted at runtime on your Apple gadget ;-).
Lately there have been some rumors on the full-disclosure mailing list referring to a blogpost of Hatforce about a new method to bypass the PIN/password lock on Android Gingerbread phones.
The approach was to boot into the Recovery Mode and execute a reset to factory state. The ideal result should be a reliable wipe of the /data partition. However, the author managed to recover data after the wiping process. This has been stated as a method on extracting sensitive date without knowing the actual pin or passcode.
This approach was tested on a Nexus S smartphone with Android 2.3.6 assuming the problem could be present on other devices too.
As of our experience this actually affects all Android devices without device encryption. Meanwhile we had more than ten different Android 2.3.x devices from four different vendors. All of them need less than a minute for a factory reset. An actual example is the HTC Desire HD with a 1,1GB /data partition excluding the /cache partition. The factory reset procedure took about 40 seconds, which can hold as an advice to question if this time is actually sufficient to wipe the whole storage. Finally we have been able to recover data after factory-reset devices as part of previous studies.
Besides mentioning that the source code indicates Android devices runnig Android Honeycomb and later effectively wipe data. After looking up in the source code of Android Ice Cream Sandwich we found that the FileWriter class is used for the wipe of the /cache and /data partition. So no indication on overwriting the data here. We assume, that by mentioning the issue as resolved, he was referring to Android Honeycomb device encryption being use, which indeed resolves this issue. This feature has been announced as a new feature anyway.
The fact about getting the data without knowing the PIN however does not really fit the case. From our opinion that’s not a new thought anyway. As long as the storage is not encrypted there always ways to access and read it. My favorite way is to flash the recovery mode with a custom one, e.g. ClockWorkMod By this means it’s possible to run Android Debugging Bridge, su and dd binaries which in return can be used to connect to the device via USB cable and create a raw copy of the storage. Additionally it becomes available to follow the loudness principle and acquire data on a forensic level.
However there is one important aspect mentioned in the blogpost, which we fully agree with: lost device means lost data!