There are numerous and costly--and closed source--methods for recovery data from the Apple iPhone, iPod Touch, and iPad. If you are lucky enough to be part of Law Enforcement, then you have free access to Johnathan Zdziarski's tools and methodology (Thank you, Johnathan). But what to do if you don't have the proprietary tools, or they just don't work on the version of iOS you encounter?
Allow me to introduce the libimobiledevice project. It is a library that communicates to the aforementioned Apple devices, with the addition of Apple TV devices, but does not use any proprietary libraries, nor does it require jailbreaking to accomplish its goals. I'll let the description on the project home page take over from here: libimobiledevie "allows other software to easily access the device's filesystem, retrieve information about the device and it's internals, backup/restore the device, manage SpringBoard® icons, manage installed applications, retrieve addressbook/calendars/notes and bookmarks and (using libgpod) synchronize music and video to the device."
That said, it is not designed as a forensics tool. I may be characterizing it wrongly, but in short, it brings iTunes-like capabilities to Linux. It does not give full filesystem access to the device, just the media folder and sub folders. This means you can access the Photos and videos taken with the device, as well as access the music catalog through your file browser. But be careful--you have read/write access.
Best practice requires that you disable automounting in your system to avoid changing data on the device when you connect it to your system. This can be done in a Gnome desktop by using gconf-editor to disable automounting in nautilus ( apps | nautilus | preferences | media_automount [uncheck] ). It's a good idea to disable media_automount_open and enable media_autorun_never while you're at it. You won't find your iPhone with fdisk when you connect it, which might leave you wondering just how in the world you're going to mount it?
Libimobiledevice is incorporated into Ubuntu and Linux Mint Debian Edition (my preference) and uses the Gnome Virtual File System (GVFS) for mounting the Media folder of devices in the .gvfs/ folder of your home directory. But you've disabled automounting, so you need another method that allows read-only mounting. That's handled with ifuse, but you'll likely have to install it. With ifuse, the device can be mount read-only in a location you specifiy. The device is automatically identified unless you choose to identify the device by its UUID (only necessary if you have more than one device connected at a time). You mount with "ifuse [options] location", such as "iphone -o ro /mnt/analysis". If you happen to have a jailbroken device, then adding the '--root' parameter will give you full logical access to the user partition on the device.
Mounting with ifuse, on a device that has not been jailbroken, gives access to the same to the device as libimobiledevice through GVFS, only with write protection. Media files can be useful, as I indicated in an earlier post, but how does an investigator get to the meaty stuff, like SMS messages, call history, and the like?
Well, there are tools that have been built to use the imobiledevice library, aptly called imobiledevice-utils in the Debian package management system. The utilities consist of the following tools: idevicebackup, ideviceimagemounter, idevicescreenshot, ideviceenterrecovery, ideviceinfo, idevicesyslog, idevice_id, and idevicepair. Of particular interest are ideviceinfo, and idevicebackup.
The ideviceinfo tool displays data about the phone itself, including the device name, serial number, OS version, and phone number. Even locked phones provide useful data, though not as robust as an unlocked phone. The idevicebackup tool works like iTunes backup. It creates a device backup in a location specified by the user. idevicebackup2 is required for iOS 4.3. and above, but can only be obtained by building it from source, which is available through a link on the imobiledevice website. The backup includes photographs, videos, and databases from the device, including SMS messages, call history, address book, etc!
The files in an iPhone backup are renamed in hex and are referenced in two mbdb databases that index the original name, location and MAC times for the backup files. The mbdb_parse.py utility can be used to identify the files. I am working to modify mbdb_parse.py to automate renaming of the files, but the standard output can be used like an ls -lh output. The limitation of mbdb_parse.py is that it displays user/group values in hex and MAC times in unixepoch time. I have been able to modify the program to allow me to rename the files into their original names, but the program is not ready for release as yet.
I will cover forensic processing of the backup in a later post.
Wednesday, May 4, 2011
I've written a couple of articles about my experience with iPhone data ("iPhone Sings like a Jailbird", "Recovering Data from Deleted SQL records", and "Parsing the iPhone SMS Database"), and recently I have been helping others with some iPhone data recovery. Those experiences have led me to create a few simple iPhone forensics tools. I'll list them in name order and briefly describe them:
You can download iphone_tools here.
iphone_ab is a tool to parse the iPhone address book, which is stored in a SQLite file called AddressBook.db. The tool links two tables to produce a simple output containing first and last name, phone number/email address, record creation date and record modification date. There is much more data that can be mined from the database, but this is the basic data that interest most investigators.
iphone_ch is a tool to parse the iPhone call history, which is stored in a SQLite file called call_history.db. The tool reads the 'call' table and reports the date, call type, phone number, and call duration of each record. Unixepoch time is converted to local time and call flags are interpreted (Incoming, Outgoing, etc.).
iphone_cs is a tool to parse the iPhone consolidated.db, which is a SQLite file that stores gps data used by apps. Experimentation shows that one table in particular, the CellLocationLocal table, records the location of the iPhone handset when it runs apps that use location data. Don't think location data is restricted to mapping apps--I have seen dictionary apps that ask to use your location. Now, why is that? In a word: advertising. iphone_cs will parse the CellLocation, CellLocationLocal, and WifiLocation tables for GPS data and allow the data to be formatted for mapping tools like gpsbabel or websites like GPSVisualizer.com.
iphone_images is a tool that will search a path for images and videos (identified by mime type) and provide the EXIF data by use of the excellent exiftool. Alternatively, files containing GPS data can be parsed to export data suitable for mapping. Finally, videos purchased through the Apple Store can be sifted for the Apple Store user name and real name of the purchaser.
iphone_music is a tool that will search a path for audio files, particularly those in the 'iTunes Control/' folder (though not restricted to these files). iTunes uses random filenames for music it transfers to an iPhone or iPod. The tool, at its most basic level, reveals the song name, album, and artist to help owners identify their device by its content (think recovered stolen device). The tool can also produce rich metadata, again, thanks to exiftool, as well as single out those songs purchased through the Apple Store and report Apple Store credentials like iphone_images.
iphone_sms is a tool to parse the iPhone SMS database, located in a file called sms.db. The tool reads the message table and reports the date, message type (sent, received, etc.), phone number, and text message in each record. Unixepoch time is converted to local time and message flags are interpreted (Sent SMS/MMS, Received MMS , etc.).
All of the tools, written for BASH, attempt to follow the Unix principal of make one tool to do one thing and do it well. They each have a variety of options that can be read by invoking help, e.g., 'iphone_sms -h'. The database tools do not find the target database for you, since your iPhone data may come from a variety of sources (iPhone images, backups, etc.). Output for all files is to stdout (the screen) but may be redirected to a file. For example, to redirect the mapping data from iphone images and videos, the command 'iphone_images -m /private/var/mobile/Media > images_gps.txt' could be used.
I hope you have success with the tools. Please contact me with any errors you detect and/or feature suggestions you might have. I am already contemplating an "export" function to, for example, export the images to a directory that were the source of the GPS data the mapping output from iphone_images.
You can download iphone_tools here.
at May 04, 2011
Time Perspective Telling time in forensic computing can be complicated. User interfaces hide the complexity, usually displaying time stamp...
I was asked recently to help recover deleted messages from an iPhone SMS database. Conveniently, this is called "sms.db" on the i...
I've written a couple of articles about my experience with iPhone data (" iPhone Sings like a Jailbird ", " Recovering Da...
I was attempting to brute force an iPhone 4 passcode for data recovery. The phone was in poor condition and had undergone modi...