The development of automated cyber forensic tools has made a lot of our jobs quicker and easier when conducting an investigation. Having a tool that parses data, separates it and then packages it in an organized fashion is a real time saver—but what happens when your favorite forensic tool fails? Did you know there are phone applications that purposely poison the results of what can be recovered from an automated forensic tool? What if the suspect has an infected mobile phone that is acting as an agent for another bad guy remotely? How can you tell?
This article is intended to give law enforcement investigators some insight on doing manual forensics in the event automated tools fail. We'll also detail some ways an investigator can get access to encrypted private data to help further investigations.
Backing up the Tools
If there's one lesson that’s made an impact on me in my career as an analyst it would be that I should never rely on tools alone to do my job. They are often the targets of bad guys who know they may get caught one day. As a backup and fail-safe way of doing my analysis, I always try to perform tasks manually in parallel to using a tool to perform analysis.
Tools, by nature, require that certain attributes be in place and that some things be consistent. Example: When gathering SMS messages from a mobile device, an automated forensics tool may be expecting a standard location for a file that holds all the SMS text message data. If a suspect changes the location of the file and use a third-party application to send and receive text messages instead of the stock phone application, will the forensics tool find the second non-default location for storing the SMS text messages?
It depends on the tool and how robust it is. In this case, let's say the bad guy uses one text messaging application to do his bad guy stuff and the stock phone application to talk to his or her friends. Unless you look for that kind of deviation from the normal way a phone works you might miss some important evidentiary data. Some tools are intelligent enough to find all of the messages on the phone, but, again, it's always better to verify the results from the tool in a good old-fashion way—with your eyeballs.
Database Storage
Much of the data that is stored on mobile devices these days is stored in small databases on the phone. Database software on each brand of phone varies, but SQLite is used extensively on both Android and iPhones the majority of the time.
Even third party application makers who sell software on the phone app markets utilize these databases because there are built in libraries in the software languages they use to program these applications. The libraries take advantage of these native databases installed on the phone and make the programmer's job easier. The locations of these databases need to be verified by the examiner. Once the location is verified you should go one step further and extract the information contained in these databases manually.
There are plenty of tools out there that will open and query information in these SQL databases to ensure the automated forensic tools are working correctly. Below are some example locations of some of these important databases and what types of information they hold.
iPhone Databases
|
Normal Database File Path: |
What they're for: |
|
/mobile/Library/AddressBook/AddressBook.sqlitedb /mobile/Library/AddressBook/AddressBookImages.sqlitedb |
Address book information and images associated with the people in the address book
|
|
/mobile/Library/CallHistory/call_history.db |
Contains the call history with time and duration.
|
|
/mobile/Library/Caches/MapTiles/MapTiles.sqlitedb |
Contains a cache of images used by the Google Maps application. (No longer available in the upcoming iOS6) |
|
/mobile/Library/SMS/sms.db |
Contains the SMS text messages. |
|
/var/root/Library/Caches/locationd
|
Geolocation |
|
/private/var/mobile/Library/Safari/History.plist |
Browser History |
Android Databases
|
Normal Database File Path: |
What they're for: |
|
/data/data/com.android.providers.contacts/ databases/contacts.db |
Address book information and images associated with the people in the address book
|
|
/data/data/com.android.providers.contacts/ databases/contacts.db |
Contains the call history with time and duration.
|
|
http:///data/data/com.coremobility.app.vnotes/files |
Contains voicemails in this directory
|
|
/data/data/com.android.providers.telephony |
Contains the SMS text messages. |
|
/data/data/com.android.browser/gears/geolocation.db |
Contains last known GPS location |
|
data/data/com.google.android.providers.gmail/databases |
Contains gmail messages |
Extracting these database files at their locations and opening them with a SQLite browser will allow the investigator to get detailed information that isn’t filtered down or just plain wrong by a forensic tool.
What about private and encrypted data that's stored on the phone, can we get access to these important things? For some things you can. In the iPhone, for example, a particular area of interest to an investigator would be the phone’s keychain. The keychain is where all passwords for Apps are normally stored. This includes Mail passwords, WiFi passwords and a lot more. The Keychain restricts which applications can view which data. For example, only Skype should be able to access the Skype database, all other programs should be denied. An open source program called Keychain-Dumper can be used to access all the data in the keychain. You'll have to learn how to compile the program in a Mac environment using Xcode’s ARM compiler on the Mac. Get your fellow tech-geek to help you build it.
Once it's built the tool works by granting Keychain-Dumper specific entitlements that allow it to access all data. Of course, having these integral passwords can help further your analysis into other areas that might not even be on the phone itself.
Editor's note: Remy Baumgarten will be instructing the Basic iPhone Forensics and Exploitation for Law Enforcement course at the upcoming HALO Counter-Terrorism Summit, taking place Oct. 29 – Nov. 2. The Summit will occupy San Diego’s entire 44-acre Paradise Point private island for homeland security training exercises, demonstrations and education. For more information, call (619) 881-9125 ext. 3 or visit www.thehalosummit.com.
Remy Baumgarten is a security developer and researcher for ANRC, a fast growing market leader in computer security training and consulting. He is highly skilled in reverse engineering and malware analysis on various platforms including Windows, OSX, Linux and iOS. Before joining ANRC, Mr. Baumgarten was a Technical Lead on the Malware Team and the mobile expert on iOS at Booz Allen Hamilton.