Exploring the iPhone Backup Made by iTunes

Abstract

Apple's(TM) iPhone(TM) is one of the widest selling mobile on the market, thanks to its simple and user-friendly interface and ever growing pool of available high quality applications for both personal and business use. The increasing use of the iPhone leads forensics practitioners towards the need for tools to access and analyze the information stored in the device. This research aims at describing the process to forensically analyze a logical backup of an iPhone made by the Apple iTunes(TM) utility, understanding the backup's structure, and creating a simple tool to automate the process of decoding and analyzing the data. In our research of the iPhone backup we identified data of forensic value such as e-mail messages, text and multimedia messages, calendar events, browsing history, GPRS locations, contacts, call history and voicemail recordings can be retrieved using this method of iPhone acquisition. [PUBLICATION ABSTRACT]

Headnote

ABSTRACT

Apple's(TM) iPhone(TM) is one of the widest selling mobile on the market, thanks to its simple and user-friendly interface and ever growing pool of available high quality applications for both personal and business use. The increasing use of the iPhone leads forensics practitioners towards the need for tools to access and analyze the information stored in the device. This research aims at describing the process to forensically analyze a logical backup of an iPhone made by the Apple iTunes(TM) utility, understanding the backup's structure, and creating a simple tool to automate the process of decoding and analyzing the data. In our research of the iPhone backup we identified data of forensic value such as e-mail messages, text and multimedia messages, calendar events, browsing history, GPRS locations, contacts, call history and voicemail recordings can be retrieved using this method of iPhone acquisition.

Keywords: iPhone, iTunes, iOS, Logical Backup, Mobile Phone Forensics, iPBA, iPhone Backup Analyzer.

1. INTRODUCTION

Modern mobile phones store vast amounts of data and have become an integral part of peoples' daily lives. The ever evolving technologies in the field of mobile communications introduced a whole new experience of using mobile devices, either for personal or professional use. Users rely on smartphones for an infinite number of tasks, from planning their day to browsing the Internet. But the increasing usage of smartphones in day-to-day activities cause these devices to store more and more information about their owners' life: where they've been, who they called, who they 'texted,' and so on. These data could be a rich source of evidence when the device itself is involved in a criminal activity and is seized as part of an investigation process, whether it is a target, an instrument or just a silent "witness". This brings the need to study forensically sound methods to handle the examination and analysis of these devices and of the data they contain.

Among the mobile phones available on the market we chose to work on the iPhone device from Apple Inc. The iPhone is a new generation smartphone which is seeing an incredible diffusion throughout the world, with a wide range of functions storing a wide range of data that can be extracted during a forensic analysis. We decided to analyze the iPhone data via the backup feature, because that is the methodology which appears more forensically sound by producing the slightest amount of modifications in the device under test: in fact, being able to exploit the backup data prevents the examiner from having to modify the device in order to extract data (a slightly bigger amount of data could be obtained by jailbreaking the device, but this procedure, whenever available, implies permanently modifying the evidence and thus should be avoided). While the acquisition of the content of an iPhone using its standard backup feature is widely known and reported, we found a lack of literature explaining in detail how the data acquired in this way are organized, and what forensically interesting data they contain. This research will explore the logical backup of an iPhone made using the standard backup features and try to describe all its contents we've been able to identify and which could be useful during an investigation. We'll present also a tool we developed to browse through the elements of the backup.

All the results shown in this article will assume that the backup was not encrypted (the encryption is an iTunes option disabled by default). If the backup data is encrypted, it has to be decrypted in order to perform the analysis described in the following chapters. Commercial products such as the Phone Password Breaker(TM) from Elcomsoft(TM) claim to be able to enable forensics access to password protected backups. Once decrypted, the backup data can be analyzed as stated in the following chapters.

This document is organized as follows:

* Section 1: Introduction.

* Section 2: Creating a logical backup. This section describes what is the logical backup of the iPhone, how can be obtained and why it can be useful for forensics purposes.

* Section 3: Backup structure. This section describes the structure of the iPhone backup and the elements we found inside: the standard files and the possible types of the other ones.

* Section 4: Backup Content. This section gives a comprehensive list of all the data we found in the backup directory, with an explanation of how the single files and databases are structured and which useful information we could find in them.

* Section 5 : iPBA - iPhone Backup Analyzer. This section describes the software we built and used to analyze the backup data.

Section 6: Conclusions.

2. CREATING A LOGICAL BACKUP

The iPhone backup on which all of the further analysis is performed is obtained using the iTunes software. The iTunes utility by Apple Inc. is available for Mac OS X(TM) and Windows(TM) platforms, and is the default software (and the only officially supported one) to interact with the iPhone. The software provides a backup feature which utilizes Apple's proprietary synchronization protocol to copy the iPhone data to a workstation. While the backup system can be manually disabled and provides an optional encryption function, the default behavior of iTunes is to make an unencrypted backup without asking, whenever the iPhone is connected. It can be noted that when the iPhone is synchronized with the computer it is paired with (via USB cable), data is copied from the phone to the computer and vice- versa, whether each element has a newer version on the phone or on the computer. Hence, in a forensics examination it is necessary to back up the device with a clean installation of iTunes which contains no data, to prevent newer elements to be copied from the forensics workstation to the device under analysis. Moreover it is known that the pairing can't be established via a USB write blocker, because the backup utility needs to mount the iPhone filesystem [1]. While this methodology was initially developed to analyze seized mobile phones, it is noted that it can be used the same way to conduct forensics analysis on seized computers which have been paired with unknown iOS devices (being the backup feature enabled by default).

Our analysis was conducted on an iPhone 3GS with iOS version 4.2.1 and iTunes version 10.2, the latest versions available during the research work. While more extensive studies should be conducted to prove it, it is noted that all iPhone devices sharing the same version of the operating system should be equally interested by the results described in this document. Moreover, Apple iPad(TM) devices, which share a slightly different version of iOS, should be analyzed with the same tools.

The results we provide in this paper were achieved by studying the logical backup with iPBA iPhone Backup Analyzer, an utility we developed as a simple mean to browse through the backup data. The software is written in Python and provides a graphical interface which shows the tree of domains and files in the backup, and provides a simple analysis of each file based on the content of the file itself. For example, binary files of known types are automatically converted to a readable form. As another example, for each SQLite database file the tool shows a list of the tables it contains, and it provides the possibility to click on a table name to see its contents.

Deeper analysis of each file has been conducted with standard instruments which are described in the text. These instruments include some standard Mac OS X utilities (such as the Plist editor for analyzing binary and plain text plist files), third party utilities (such as the SQLite client to explore the content of SQLite database files) and standard UNIX command line utilities (such as dd, strings or hexdump).

3. BACKUP STRUCTURE

The backup data is stored in a preconfigured folder for each of the operating systems iTunes is made available for.

Mac OS X: /Library/Application Support/MobileSync/Backup/

Windows XP: \Documents and Settings\(username)\Application DataVApple Computen

MobileSync\Backup\

Windows Vista, Windows 7:

\Users\(usemame)\AppData\Roaming\Apple Computen

MobileSync\Backup\

It is possible to have an arbitrary number of backups, as each backup is stored in a subdirectory of the previously described path. The name of the backed-up folder is a string of 40 hexadecimal digits, and represents a unique identifier for the device from where the backup was obtained. This unique identifier appears to be a hashed value since it was the same unique name given to the backed-up folder by iTunes on both Mac and Windows operating systems. Within this folder, there are hundreds of backup files with long hashed filenames consisting of 40 numbers and characters. These filenames signify a unique identifier for each set of data copied from the iPhone memory [Bader and Baggili, 2010].

The files found in the backup directory can be classified into five categories:

* SQLite3 database files;

* Plain text plist files;

* Binary plist files;

* Multimedia and text files.

* Non-standard data files.

The SQLite3 database files store a single database each in SQLite3 format. Each database can contain an arbitrary number of tables. The plain text plist files are Extensible Markup Language (XML)-like text files. Their binary counterparts are XML-like files stored in binary format which can be easily converted back to a plain text format with the Mac OS X plutil utility. A more in-depth description of those file types is provided in sections 3.2 and 3.3.

In addition to the files described before, the backup directory contains five more standard files with a fixed name, described in section 3.1.

3.1 Standard backup files

These files are created by the backup system and store data about the backup itself and the device it was made of. Their names are:

* Info.plist

* Manifest.plist

* Status.plist

* Manifest. mbdb

* Manifest. mbdx

The first three files are plist files which can be easily analyzed using the Property List Editor application on Mac OS X or by manual examination with a text editor (binary plist files must be converted to text format first by the MacOsX plutil utility). The file Info.plist (plain text plist) stores data about the backed up device (such as the device name, GUID1, ICC-ID2, IMEP, and serial number) and the iTunes software used to build the backup (such as iTunes settings and the iTunes version number).

The file Manifest.plist (binary plist) describes the contents of the backup. In this file we find the applications installed on the backed up device (each with its version number), along with the date the backup was made, whether the backup is encrypted or not, and again data about the device and the iTunes software.

The file Status.plist (binary plist) seems to store information about the status of the backup itself, such as whether the backup is complete or not.

The last two files of the list, Manifest.mdbd and Manifest.mbdx, are binary files which store the descriptions of all the other files in the backup directory. It can be noted that in these files there are also, described as separate records, the directories and the symbolic links, which of course don't have a corresponding file in the backup directory.

The structure of the index file Manifest.mbdx is shown in Figure 1.

Manifest.mbdx consists of a header and a number of records, one for each element indexed (files, directories, symbolic links). The header contains two fields: a string identifying the file type and the number of records in file. Each record contains three fields. The first field is a 20 characters unique identifier of the element (if the element is a file, the key is also the name of the corresponding file stored in the backup directory). The second field is the offset (in bytes) of the corresponding element in the Manifest.mbdb file. It must be noted that offsets in file Manifest.mbdb don't count the file header (first 6 bytes), so to obtain the absolute offset we must add 6 to the value in the offset field. The last field is a 16 bit value describing the file permissions. The first 4 bits of this last field identify the file type:

* OxAxxx: symbolic link

* 0x4xxx: directory

* 0x8xxx: regular file

The xxx part (three nibbles) in the file mode seems to carry information about the referenced element permissions in Unix style [2].

The second file, Manifest.mbdb, contains a record for each element indexed by the previous file. The structure of the file is shown in figure 2.

Each record can contain an integer, an array of integers or a string. The strings are composed of an uintló that contains the length in bytes (or OxFFFF for empty strings) followed by the characters in UTF8 format (Unicode normalization form D). All the numbers are big endian.

As shown in figure, each record contains (among the other fields):

* Domain: the domain the element belongs to. Domains are a way to functionally categorize elements in the device backup and will be described later.

* Path: the full path of the element.

* Link Target: the target of the element, if the element itself is a symbolic link (otherwise the field contains value OxFFFF).

* Mode: the file permissions. This field holds the same value seen in file Manifest. mbdx.

* User ID and Group ID.

* M. time: the time (in Unix time format) when the actual content of the file was last modified.

* A. time: the time when the file was last accessed.

* C. time: the time when changes were last made to the file or directory's inode.

* File size: the size of the file in bytes.

Each record can contain a list of properties of arbitrary dimension [3].

3.2 SQLite files

SQLite is an ACH^-compliant embedded relational database management system contained in a relatively small (275 KB) C programming library. The source code for SQLite is in the public domain and implements most of the Structured Query Language (SQL) standard. It is arguably the most widely used database engine, as it is used today by several widespread browsers, operating systems and embedded systems among others. Due to its small size, SQLite is well suited to embedded systems, and is also included in Apple's iOS (where it represents one of the primary means of archiving data) [4].

It is important to point out that the in some cases it is possible to retrieve deleted data from SQLite files. When a record is deleted, the area in the file where it was stored is marked as unused but is not immediately overwritten, so its content can already be recovered, for example by the Unix strings command. (The strings command scans a file and outputs all the ASCII strings it found. It has been verified that among those strings it can be found the content of deleted records.) By this mean it has been possible to recover, for example, deleted notes, messages and contact names from the device under test.

3.3 Plist files

Property Lists (often referred to as Plist files) are files that store serialized objects. In iOS (as well as all versions of Mac OS X) the property lists are stored in XML format, with a public DTD5 defined by Apple. The XML format supports nonASCII characters and storing NS Value objects. The most used tags found on the device under test are:

* <string>: UTF-8 encoded string.

* <real>, <integer>: decimal string.

* <true />, <false />: boolean values (tag only, they don't contain other data).

* <date>: ISO 8601 formatted string representing a date.

* <data>: Base64 encoded data.

* <array>: a list that can contain an arbitrary number of elements.

* <dict>: a list containing an arbitrary number of pairs of <key> and plist element tags.

Because XML files are not the most space-efficient means of storage, Mac OS X 10.2 introduced a new format where property list files are stored as binary files. Starting with Mac OS X 10.4, this is the default format for preference files.

The plutil utility (introduced in Mac OS X 10.2) can be used to check the syntax of property lists, or convert a property list file from one format to another. XML property lists are hand-editable in any text editor, but Apple provides a "Property List Editor" application as part of their Developer Tools installation that provides a hierarchical viewer/editor which can also handle binary formatted plists. [5]

Base64 encoded data can be decoded with many utilities which can be freely found online. Mac OS X does not provide a default application to decode Base64, but the result can be achieved by saving the data block in a text file and then exploiting a function of the openssl utility (provided by default in the standard installation of Mac OS X):

openssl base64 -d -in <infile> -out <outfile>

4. BACKUP CONTENT

The first categorization of backup files is described by their domain. The domain for each file is written in its corresponding record in the Manifest.mbdb file. Each file has a domain name chosen from the following list:

* Application domain.

* Home domain.

* Keychain domain.

* Managed Preferences domain.

* Media domain.

* Mobile Device domain.

* Root domain.

* System Preferences domain.

* Wireless domain.

The domains Managed Preferences and Mobile Device do not appear to contain useful informations (at least in the device under test), while the others contain useful data which is described in further sections. It is noted that elements in the Application domain are listed with a subdomain related to the name of the application they belong to, while elements in the other domains appear not to use this feature. When the subdomain is used, the domain string in Manifest.mdbd is written as <domain>-<subdomain>.

4.1 Application domain

The domain AppDomain contains a certain number of subdomains, one for each installed application. Each subdomain contains some files divided into a number of directories, most of them standard for all applications. A typical structure is shown in figure 3.

The directory Documents contains application-specific data, such as multimedia files for media players. Data in this directory is saved in an application specific format.

The directory Library contains standard elements and has an almost identical structure for every application.

The subdirectory Library/Cookies contains a plist file named Cookies.plist containing the cookies for the application, i.e. simple data chunks used for temporary data storage.

The subdirectory Library/Preferences usually contains two files:

* . GlobalPreferences. plist: a symbolic link to a standard file containing settings common for all applications on the device.

* A file with the same name as the application with extension plist containing application specific preferences.

The subdirectory may also contain other settings files (usually symbolic links) related to standard elements of the operating system used in the application (such as PeoplePicker.plist for selecting names from the device Contacts or ADlib.plist for managing iAD banners).

The subdirectory Library/WebKit contains elements related to WebKit, which is the standard engine used under iOS to render web pages. The directory contains a subdirectory LocalStorage into which temporary data is archived for offline use and could contain another directory named Databases. The ability of web applications to create databases on client machines is a new feature of HTML5 and the directory Databases is used to save such data. This data is saved as a single SQlite file (in a specific subdirectory, as shown in figure 4) for each HTML5 database, plus a file called "Databases.db" which lists the other ones.

The data structure in each database is application specific and can be easily analyzed to retrieve all the data stored in the Webkit offline storage by the application. For example, Fring (a free voice-over-IP application) uses this methodology to store events (like call or chat logs or Twitter events) and contact photos. These pieces of information can be easily dumped from the database file and used as evidence.

4.2 Home domain

The Home domain contains a Library directory with a structure similar to what described for the single applications. This directory contains all data for the applications provided by default by iOS. In this section we describe the elements we have been able to identify, ordered by the application they belong to.

Address Book Library/AddressBook contains the address book data of the device. The directory contains two SQL ite databases:

* AddressBooksqlitedb contains contact data.

* AddressBooklmages.sqlitedb contains contact images, both thumbnails and full size images.

The main table is the one named ABPerson, which stores a record for each element of the address book and the main values associated to it (first name, last name, organization, job title, creation date and so on). Each contact in the address book may have an unlimited number of contact data (phone numbers, emails, etc.), so these values are stored in a separate table ABMulti Value. Each record of this table has a label and a value. Some kinds of entries can be made of more than one element (for example, the address field is made up of an address, a city name, a ZIP code and so on), so it's necessary to link to another table ABMultiValueEntry where the single elements are stored, each one identified by a label.

Each entry in the address book can be linked to a group, defined in the table ABGroup. The connection between contacts and groups is made by the table ABGroupMembers.

At last, each contact may have an image. Images are stored in the database file AddressBooklmages.sqlitedb as thumbnails and as full size images with crop size data.

Safari Mobile Browser Library/Caches/Safari/Thumbnails contains PNG images of the open tabs in the Safari browser. The files, along with their creation date and time, can provide useful information about the device and its user.

The directory Library/Safari also contains data related to the Safari web browser. Three files can be found in this directory:

* Bookmarks. db is a SQLite database file in which all the web bookmarks are stored. The database contains three tables, the most important of which is bookmarks that contains a record for each bookmark or collection of bookmarks (bookmark folder). Each record contains, among the other fields, a unique numeric id, a type identifier (0 for bookmarks and 1 for folders), a parent id (which links an element to the bookmark folder it is placed in), a descriptive title, the number of children (only for bookmark folders), the URL (only for bookmarks) and the attributes deletable and editable (1 for true and 0 for false).

* History. plist is a binary plist file which contains the recently visited web pages. It is structured as an array of dictionaries, each of which represents a single entry. Each element has, among the other attributes, a title (corresponding to the title of the linked page), a URL, the last visited date and a visits counter.

* SuspendState.plist is a binary plist file which contains information about the open tabs in the Safari browser. It is structured as an array of dictionaries (one for each tab), each one in turn containing a dictionary with information about the back function (i.e., the URLs visited before the current one in each tab). The dictionary stores all the information needed to show the page as it was shown to the user last time (scale, vertical position, etc.).

Calendar Library/Calendar contains the data for the Calendar application. The directory contains a single SQLite file named Calendar, sqlitedb. The main table in the database is the table Event, which stores a record for each calendar entry. The most significant tables linked to a calendar entry are the one depicting the reminders (table Alarm), the recurrence of the event (daily, weekly, monthly, yearly, none) (table Recurrence) and the attendees to the event (listed in table Participants and linked to events via table Attendees).

Configuration Profiles

Library/ConfigurationProfiles and its subdirectory Publiclnfo contain plain text plist files related to the device configuration (the structure of this directory as found in the device under test is shown in Figure 5). The most interesting files are UserSettings.plist and EffectiveUserSettings. plist which contain system preferences related to the capabilities of the device user (such as parental control). It is unknown what is the difference between the two aforementioned files, and they appear to contain the same values.

Cookies

Directory Library/Cookies contains the device cookies, which are structures used to temporarily store small amounts of text. A cookie can be used for authentication, storing site preferences, shopping cart contents, the identifier for a server-based session, or anything else that can be accomplished through storing text. A cookie consists of one or more name-value pairs containing pieces of information, which may be encrypted for information privacy and data security purposes.

In the analyzed device this directory contains four files:

* Cookies. binary cookies, a binary file which seems to contain cookies created by the Safari web browser. A simple string analysis using the strings Unix command revealed a list of visited sites with their associated cookie values (which could include, for example, session keys that can be used for further investigation). As an example, the following listing contains part of the output of the Unix strings command performed on the previously described file.

. support . github . com

A utmb

100728323.5.9.12 92 6 67 87 67 86

. support . github . com

A utmz

100728323.12 92 6677 8 8.1 . 1 . utmcsr= (direct) | utmccn=

(direct) | utmcmd= (none)

. support . github . com

? utma

7 309543 9.8474 95668.126393118 9.12 63 931189.12 63931

189.1

.manuali .net

? utmv

73095439 .user_level_anonymous

While the exact meaning of the entries is not known, we can assume that the device browser accessed the listed urls: support.github.com and manuali.net. Further analysis could be performed on the single strings extracted to uncover their meaning and how they could be used during a forensic analysis (for example, a string bound to a uri could be a session id for a logged in user; thanks to this information an investigator could be able to obtain more data about him from the provider of the web service).

* com.apple.iAd.cookiedb, a SQLite file which contains a single cookies table, presumably used to store cookies for the iAd system.

* com.apple.itunesstored.plist, a plain text plist file containing cookies stored by the iTunes Store as an array of dictionaries.

* com.apple.itunesstored.2.sqlitedb, a SQLite file which also seems to contain cookies stored by iTunes Store. It contains a single cookies table.

Keyboard Directory Library/Keyboard contains one or more plain ASCII files used to store dynamic dictionary words, i.e. recently used words which are used by the auto-completion dictionary (as recently used words are supposed to be the most likely candidates for words auto completion). This list includes words not present in the default orthographic dictionaries which have been inserted by the user. In the analyzed device there are two files, one for each dictionary used (standard English dictionary and Italian dictionary).

* dynamic-text.dat

* it_IT-dynamic-text.dat

These files can be examined by the Unix strings command to reveal all the text stored, and can be useful to retrieve non standard words used by the device owner, such as proper names.

Maps The Maps application provides an interface to the Google Maps service for searching and browsing locations. The directory Library/Maps contains data for the application in three binary plist files:

* Bookmarks. plist seems to contain the locations bookmarked in the application. After decoding the file with the plist utility, it appears to contain the bookmarks saved as data elements:

<data>

CAAQABgD I AAq Jl ZpYSBWYWx sb

NTAlMCBQYXNzaXJhbm8gQlMsI

YWxpYTUBAAAAQglQYXNz aX Jhb

</data>

The bookmarks' data, stored under the data key, is encoded in Base64 format. After decoding we found that it contains the description of the bookmark, either by its search string, its address or by the URL used to show it on Google Maps online.

* Directions. plist seems to contain the current status of the directions system of the Maps application. After decoding the file with the plist utility, it appears to contain the directions saved as a data element. The data section contains Base64 encoded strings of all the instructions to reach the destination, along with the distance and time between each of them.

* History. plist contains the history of recent searches made by the user in the Maps application. The file contains an array of elements. Each element is a dictionary identified by a numeric key HistoryltemType which assumes values 0 or 1. Type 0 elements represent a searched address, and are stored in clear text with the text used by the query, latitude and longitude values. Type 1 items represent a searched direction (from two positions), and are stored as data elements in the format seen above.

In the directory Library/Maps there is also a PNG image named Maplcon.png. This image shows the position of the temporary bookmark placed on the map by the user. This file is used as the profile image when creating a Contact element from a position on the map, and combined with its creation date and time could represent useful information during a forensics analysis.

Applications preferences The directory Library/Preferences contains a number of binary plist files (66 in the device under test). Each file stores preference for a specific core application (or part of it). The application to which each file belongs is easily identified by its name. During our examinations we found files containing data which could be useful for forensics purposes, listed below.

* com.apple.Maps.plist stores information about the status of the Maps application. We found some interesting keys, such as the last viewed latitude, longitude and zoom scale, the start and end strings in the route search fields along with the search strings inserted by the user.

* com.apple.MobileBluetooth.devices.plist stores a list of all the bluetooth devices paired to the host device. The file is structured as a list of keydictionary couples. The key contains the MAC address of the bluetooth device and the dictionary contains a list of properties of the device itself, such as a default name, a complete name and the capabilities (handsfree, headset, and so on).

* com.apple.MobileBluetooth.services.plist stores a list of all bluetooth services supported by the device, and for each service stores a history of paired devices with the date of the last use, along with other information. The file is structured as a list of key-dictionaries. The key contains the name of the service, and the dictionary stores the saved data.

* com.apple.accountsettings.plist stores information about the accounts set on the device, for example the accounts used for synchronization purposes or for managing email or notes. The file is structured as a list of dictionaries. Each dictionary is related to a single account and stores data as key-content pairs. The account is identified in each dictionary by the key Class. On the device under test 5 account have been found. We provide a brief description of each.

* Class: DeviceLocalAccount. This seems to be the default account existing on the device. It has a list of Enabled Dataclasses (Notes and Bookmarks) and a Type string showing the value On My iPod Touch.

* Class: SMTP Account. This is an account for sending emails using a Gmail address via SMTP protocol. It contains, among the others, the key hostname (which contains the Gmail host address for SMTP services, http://smtp.gmail.com) and Username.

* Class: SMTP Account. This is an account similar to the one described before but bound to a Mobile .me account.

* Class: GmailAccount. This file seems to be related to the main Gmail account used to receive email in the device. It contains, among the others, the key AccountPath which points to the path where the email files are stored on the host computer (under the Mac OS X directory -/Library/Mail/) and the full Gmail username.

* Class: Local Account. This file represents the host computer local account, used to store elements not included in the previous one. In the device under test these elements are the Notes and the Outbox folder. This element contains, among the others, the path where the files are stored on the host computer.

* com.apple.locationd.plist stores a list of applications allowed to access the location (GPS) capabilities of the device.

* com.apple.mobilemail.plist stores settings related to the Mail application. Among other settings, we find the key SignatureKey, which contains the default signature appended to every email sent from the device.

* com.apple.mobilephone.plist stores data about the telephone application.

The most interesting keys found in this file are

* AddressBookLastDialedUid, which stores the user id (as seen in the Contacts database) of the recipient of the last call made by selecting a name from the Contacts application.

* DialerSavedNumber, which stores the last number dialed on the phone.

* RecentsLastViewedDate, which stores the timestamp of the last time the recent calls have been shown to the user.

* com.apple.mobilephone.speeddial.plist stores data about the speed dial function of the mobile phone (the bookmarked numbers for faster dialing). The file is structured as an array of dictionaries, each one about a single bookmark. For each entry the device stores data like the name, the number and the id of the recipient in the address book.

* com.apple.mobiletimer.plist stores user configuration about the two functions of the Clock application: the mobile timer and the world clock.

For the mobile timer, the file stores an array of dictionaries (under the key Alarms), each one representing a single alarm. Among the other pieces of information, the most interesting keys are the alarm time (keys hour and minute), the title (key title) and the last modified time (key lastModifled). If the alarm is set to start on a specific day of the week, the day is stored in the key daySetting.

For the world clock the file stores an array of dictionaries (under the key cities), one for each shown clock. Each clock is bound to a specific city, so the data structure stores data like the country name, latitude and longitude, and the timezone.

* com.apple. preferences. datetime.plist stores data about the timezone of the device.

* com.apple. springboard.plist stores settings regarding the user interface. The most interesting element in this file is the key SBRecentDisplays, linked to an array of strings. The strings are the names of the last opened applications in inverse chronological order, as they are shown in the device's springboard (task manager).

* com.apple. stocks. plist stores the configuration of the Stocks application.

* com.apple. weather. plist stores the configuration of the Weather application.

* com.apple. y outube.plist stores information about the YouTube application. The data which can be retrieved from this file are the bookmarks and the history of the last seen videos. For each video it stores the eleven character code with which the videos are identified in the YouTube system.

The easiest way to discover the video linked to a code is to insert it in the YouTube URL:

http://www.youtube.com/watch ? v=XXXXXXXXXXX where the Xs represent the code.

The directory Library/SMS stores the Short Message Service (SMS) messages in the device. The main storage area is the file sms.db, an SQLite database. It is important to know that iOS stores SMS messages as "conversations," i.e. threads of messages sent to, and received from, a single phone number shown in chronological order. For each group of messages there is a single entry in the msg_group table, which also shows the number of unread messages in the thread and the ID of the most recent message. Each element in the previously mentioned table is linked to an element of the specular table group member, which stores the address, i.e. the phone number of the recipient.

Each SMS is a single record in the message table. Each record holds the text of the message, the number of the sender/receiver, the id of the message group, a flags field which represents whether the message was sent or received (values 3 or 2 respectively), the read/unread flag and the timestamp.

The device stores also drafts, which are text strings written in the text area of the SMS application but not yet sent. These strings are stored in subdirectories of the directory Library/SMS/Drafts. Each subdirectory is named after the ID of the group it refers to (see figure 8) and contains a single binary plist file named message. plist. This file contains the text of the draft.

Multimedia Message Service (MMS) messages are stored in the same way as regular messages, but without the text. The contents of the messages, which could be multimedia elements and/or text, are stored as separate records in the table msg_pieces. Each record of this table contains, among the other data, the content type (image or plain text), the content itself and the ID of the message it belongs to. If the content is an image, it can be contained in the record or be referenced by file name on the multimedia directory of the device. If the referenced content is not stored in the table then it is stored under the Media domain, in the directory Library/SMS/parts. Each subdirectory contains one or more multimedia elements, often in pairs: the element and its preview (the latter has the same name of the file it references, but without extension and with suffix "-preview"). The name of each element contains the ID of the message it belongs to and an ordinal value.

4.3 Key chain domain

The Key chain is a centralized, system-wide storage where iOS applications can store information they consider sensitive. Typically, such information includes passwords, encryption keys and certificates. Data in the keychain is always encrypted.

When a user backs up iPhone data in an unencrypted form, the keychain data is backed up, but the sensitive data remain encrypted as it was in the device filesystem. The keychain password is a unique device key, which is deemed impossible to access from outside the device itself. Therefore, passwords and other secrets stored in the keychain on the iPhone cannot be used by someone who gains access to an iPhone backup [6].

This form of backup has a limitation: it is not possible to restore the backup onto another device, because it would not know the key used to encrypt the keychain. To address this issue, Apple changed the way keychain backup works in iOS 4. Now, when creating an encrypted backup, the user has to create a password to protect backup, then keychain data is re-encrypted using an encryption key derived from backup password, and thus can be restored on another device (by providing the backup password). If the backup password has not been set, then everything works like before iOS 4. Keychain encrypted with device key is included in the backup [7]. We'll explain later why this could be interesting on a forensics perspective.

The Keychain domain contains files related to security and encryption systems on the device. The most interesting file in this domain is the key chain-backup. plist, which stores a copy of the keychain of the device, containing all the stored passwords and certificates. The file is a binary plist file which, after being converted into a plain text plist file with the Mac OS X utility plutil, shows a structure composed by an array of diet entries like this one:

(ProQuest: ... denotes formulae omitted.)

This example is the entry extracted from a test device containing the password to access a WiFi network named Brainld. The password is stored (in encrypted format) in the first data tag.

Keychain encryption As stated before, the keychain data is always stored in encrypted format, even for unencrypted backups. As we have been able to understand by searching the Internet [8], it appears that the algorithm used to encrypt data is Advanced Encryption Standard (AES) with a 256-bit key length. In unencrypted backups (as well as in the device filesystem) the sensitive information is encrypted with a key stored inside the device which can't be accessed from outside. This leads to the conclusion that trying to break this form of protection is not a feasible way.

In encrypted backups, instead, the sensitive data in the keychain has to be reencrypted using a key derived from the encryption password provided by the user. The symmetric AES key is extracted from this password by applying the PBKDF2 algorithm with an unknown salt over 10,000 iterations on the password. This is a standard practice for key strengthening user supplied passwords for AES, because the process makes brute force attacks more expensive in terms of computational power and time.

From a forensics perspective, knowing the keychain is encrypted only by a key derived from the user password means that by knowing the details of the encrypting algorithm along with the password,it is possible to decrypt the keychain and acquire all the passwords stored in it. Commercial software (like iPhone Password Breaker from Elcomsoft) are reported to be able to accomplish this result.

4.4 Media domain

The Media domain is where all the multimedia information of the device is stored. In this domain we can find, for example, the directory Library/SMS, which, as stated before, stores multimedia elements (photos and videos) from the MMS archive.

Except for the SMS data, all the Media domain is stored in the device under the directory Media. The simplified structure of the Media folder is shown in figure 1 . In this section we will describe all the data found in this domain which is deemed interesting for forensics purposes.

The folder Media/DCIM/ 100 APPLE stores the unmodified files for the elements in the device's multimedia library (images, audio recordings and videos). The files are all stored in the form IMGXXXX.EXT, where XXX is a consecutive number attributed to files during creation and EXT is the file type extension. In the device under test we found JPG, PNG image files and MOV, MP4 videos or audio recordings.

Note that JPG images can store EXIF data. EXIF data are pieces of information stored in the file header which can contain various elements about the image and the device used to create it. We found that the amount of EXIF data varies with the application used to take the photo: for example, images taken by the Photo application of the iPhone store the largest amount of data, while photos taken by other applications (such as the Facebook app) store fewer elements.

For forensics purposes, the most important tags (i.e., the tags that might prove useful as evidence) are DateTimeOriginal, which stores the date and time when the photo was taken, and GPSInfo, which stores the geographic position where the picture was taken according to the iPhone GPS unit. The GPS data is stored as a list of key-value pairs, as depicted in EXIF 2.2 standard [9].

As an example we show a GPS tag extracted from the EXIF data of an image found in the device under test.

Tag: GPSInfo, value: 1: 'N' , 2: ((45, 1), (3010, 100), (0, 1)),

3: 'E', 4: ((9, 1), (1028, 100), (0, 1)),

7: ((13, 1), (27, 1), (89, 100)) }

This data shows, according to EXIF 2.2 Standard [9], that the photo was taken at latitude 45 30.10' 0"N, 9 10.28' 0" E at 13:27 UTC.

The folder Media/PhotoData contains a plist file (storing the date of the last modification of photo databases) and two SQLite databases containing information about the photos and videos stored in the device.

The main table is the one named Photo (in Photos, sq lite), where there is a record for each photo or video. In this record we found, among other information:

* Width and height in pixels.

* Thumbnail index: the position in the .ithmb files (see later in this chapter) where we can find the thumbnails of the photo or video.

* Directory and filename: where the original file is stored (usually in Media/DCIM/IOOAPPLE).

* Capture time: timestamp of when the photo (or video) was captured.

* Duration: the duration of the video (0 for image records).

* Orientation: 6 for portrait or 1 for landscape orientation.

The records in table AuxPhoto (in file PhotosAux.sqlite) store latitude and longitude for each photo.

The folder Media/PhotoData/ 100 APPLE contains preview data for the video files seen in folder Media/DCIM/IOOAPPLE. For each video file this folder contains two or three files with the same name as the original file but different extension:

* IMG_XXXX.JPG is an image with a preview of the first frame of the video.

* IMGXXXX. THM is also a JPG image with a small, square preview of the first frame of the video.

* IMG_XXXX. THP is a data file which exists only for MOV video files and stores preview frames of the video. The frames are stored (after a 16 bit header) as 22x29 pixel raw images (with no padding between each frame), in the same format used to store thumbnails (see later in this chapter).

The folder Media/PhotoData/Thumbnails contains three files:

* thumbnailConfiguration

* 120x120. ithmb

* 79x79. ithmb

thumbnailConfiguration is a plain text plist file containing version numbers for the thumbnail management system. The other two are raw graphic files storing the thumbnails for all the images in the multimedia library of the device. The files store the single images as 120x120 and 79x79 pixels bitmaps respectively in RGB 555 Highcolor format, in which each pixel is represented by a 16 bit value (of which only 15 effectively used). Between each bitmap there is a 28 bytes padding. It is interesting to note that when a file is deleted from the library its thumbnail is not immediately overwritten.

The folder Media/PhotoData/Videos stores in its subdirectory structure the BTH files for the video in the multimedia library. The files have the same name of the video they refer to but with BTH extension (IMGXXXX.BTH). The BTH files contain a preview of some frames of the video. Their structure is similar to what we saw for thumbnails files: each file store a number of frames as 79x78 pixels bitmaps in RGB 555 format. The file embeds also a binary plist storing some properties of the preview, the most interesting of them being the duration of the video.

The folder Media/Recordings stores data for the Audio Recorder application. In this folder we found:

* The recorded audio files in M4A format.

* A plist file named CustomLabels. plist.

* A SQLite database file named Recordings. db.

In the SQLite database, the only interesting table is ZRECORDING, which stores a record for each recording. For each recording the table stores the duration (in seconds), the timestamp, the complete path of the audio file and the index of the label used to name the recording on the device (there are many preset labels). A label code of 7 indicates that the user created a custom label, which is also stored in a field of the record. The file CustomLabels. plist contains a dictionary of keystring pairs, in which the key is the complete name of a recorded audio file (with extension) and the string is the label associated (being it a standard label or a custom made one).

In the device under test the only content of the Root Domain appears to be the directory Library/Caches/locationd which, as the name suggests, seems to hold information about the location capabilities of the iPhone. The structure of the domain is shown in figure Error! Reference source not found..

The file clients. plist is a binary plist file. It contains a list of key-dictionary pairs. Each key holds the name of an application which has requested access to the location capabilities, and the corresponding dictionary contains information like:

* Whether the application has been authorized to access the location data.

* The name of the main executable of the application.

* The timestamps of when the location acquisition has been started and stopped the last time by the application.

The file which seems most interesting from a forensics perspective is consolidated.db, which is.an SQLite database file which seems to contain the data used by the device assisted GPS. The assisted GPS is a system to achieve an approximate localization of the device by using data from mobile cells and wireless networks found nearby, and it is used while the main GPS system isn't ready to give the exact position. To achieve this result the device needs to store a cache of known cells and WiFi networks with their approximate geographical position.

The most interesting tables in consolidated.db appear to be WifiLocation and CellLocation. The table CellLocation seems to store a cache of Base Stations (one for each record), identified by their MCC6, MNC7, LAC8 and CI9.

Each record stores:

* A single cell identification: MCC, MNC, LAC and CI.

* A timestamp.

* A geographic position (latitude, longitude, altitude).

* Vertical and Horizontal accuracy.

While it is not known exactly how the system works, it has been verified that for a single value of timestamp (i.e. for a single instant) many records are recorded, all belonging to a limited area. It has also been verified that the mobile phone was effectively located in the area among the base stations found at the time recorded by the timestamp. So we can reasonably assume that the device stores, at the time specified by the timestamp, data about all the base stations the device "knows" and their approximate geographical position (probably this data is temporarily stored elsewhere as it is harvested, maybe in the now empty table CellLocationHarvest, and then written to this table). This information may be valuable to a forensics examiner, because it can be used to prove that a seized device was in a known, limited area at a certain time. In the device under test we have been able to recover even one year old positioning data. The locations can be extracted from the table by a simple SELECT statement and then used to create a Keyhole Markup Language (KML) file which in turn will be shown by a geographical application such as Google Maps.

After researchers reported that location-based information was stored in such unencrypted and unprotected form, Apple was forced to change the way this file is managed. From iOS version 4.3.3 the file consolidated.db no longer contains the location tables (either for cells or WiFi hotspots).

The domain System Preferences appears to contain only the directory SystemConfiguration, which stores some binary plist files holding information about the configuration of the core components of the iOS system. The files in the System Preferences Domain of the device under test are depicted in Figurel3.

The most forensically interesting files found in the device are:

* com.apple.network.identification.plist seems to store data about the networking devices the iPhone has been in contact with. It appears to be composed of a list of "identifiers" (the IP address of a router and the corresponding hardware address, or the name of the interface for a cellular WAN), each one of them associated to a timestamp and an array of "services". Each service is in turn a dictionary containing Domain Name System (DNS) and IPv4 data. In the device under test, by analyzing this file we could find the addresses of the DNS servers, the address of the router, the address assigned to the mobile phone and the subnet mask of the network. These elements could be forensically useful by letting the examiner know the device has been effectively attached to a network, along with its Internet Protocol (IP) address.

* com.apple.radios.plist seems to store only whether the device is in airplane mode or not. Being in airplane mode means that all the radio components in the device (GSM/UMTS, Bluetooth, WIFi) have been disabled.

* com.apple.wifì.plist stores a list of known WiFi networks. For each network the file contains, among the others, BSSID, SSID (name of the network), security mode (WEP/WPA), strength of the signal, channels used and the timestamps of the last manual join and autojoin.

The Wireless Domain holds data related to the mobile phone part of the device. The structure of the domain is shown in Figure 14.

The domain is made up of two directories. The first, Library /CallHistory, contains just one file, a SQLite database named calljiistory.db. As the name suggests, the database stores in a table called callonz record for each of the last 100 phone calls the device received, missed or made.

For each call the database tores the number of the other phone involved, the timestamp (in Unix Epoch time format, i.e. the number of seconds elapsed since January 1st, 1970), the duration in seconds, the country code of the country the call was originated from and a flag distinguishing between incoming (value 4) and outgoing (value 5) calls. This last field has a special value (1507333) which identifies calls failed due to network problems.

The file call history. db contains another table called data which appears to store logs for UMTS data connection of the device. In the device under test we found that the file has four records, the last three of them with all the "bytes" fields set to zero. We can assume that each record was designed to store data for a single network interface (as it appears to be described by the field "pdp_ip"). In fact, as seen in previous logs, the iPhone appears to use just the interface pdpipO, which is why the record with pdpip = 0 is the only populated one.

In the only populated record, the fields bytes rcvd and bytes_sent are the values of incoming and outgoing data traffic (in kilobytes) from the last reset of the counters. The fields bytes 'lifetime rcvd and bytes lifetimesent are the same values as stated before but can never be zeroed by the user and so represent the total amount of data traffic of the device during its entire lifetime. The fields bytes _last_rcvd and bytes _last_sent appear to be the data traffic (always in kilobytes) for the last connection.

The file calljiistory.db has another table named SqliteDatabaseProperties in which each field consists of a pair key- value and appears to store values related to the timers measuring the length of calls made by the device. The reason these values are stored in a proprietary table (in a different way from the data transfer logs) seems to be that the values in this table are updated by database triggers whenever a new record is added to the call table. The table contains records for the data transfers counts, too, but those values are all zero in the device under test and do not seem to be used. The most notable values found in this table are:

* call history limit: maximum number of call records stored in the call table.

* timer last: duration (in seconds) of the last call.

* timer incoming and timer outgoing: duration (in seconds) of incoming and outgoing calls from the last counters reset.

* timer _all: sum of the previous values.

* timer lifetime: sum of durations of all incoming and outgoing calls in the lifetime of the device.

5. IPBA - IPHONE BACKUP ANALYZER

To analyze the backup data in a simple manner we developed a software tool, called iPBA - iPhone Backup Analyzer. This tool provides a simple mean to browse through a backup directory and perform a first analysis of each element contained. It is written in Python and Tk, and thus it should be able to run on each platform which supports this scripting language (it has been tested on Mac OS X and Linux).

The software is started by launching the main script file, passing via command line the location of the directory, such as:

./main.py -d Backup/

Upon startup, the tool locates the index files Manifest.mbdb and Manifest.mbdx and parses them for all the data related to each single element they describe. This data is then stored in a SQLite database built in RAM (one record of a table for each element). Another table stores the objects properties, as each object could have an arbitrary number of properties.

After parsing the index files, the user interface is built (see Figure Error! Reference source not found.). In the left column there is a tree to show the elements in an ordered manner: first by their domain, then by their subdomain (only for the Applications Domain), then by their path and at last by their filename. In the upper part of the left column are shown properties about the backup, parsed from the Info.plist file, such as the version of iOS on the device, the date of the backup and unique identifiers of the iPhone (ICCID, IMEI).

When the user clicks on a filename in the tree, the software tries to analyze it and provides the output in the main text area. The data collected from the index files are written first:

* File type (file, directory, symbolic link).

* Unix permissions.

* Data hash (if stored in the index files).

* User and Group ID.

* Last modified time, last access time, creation time.

* File key (the name of the file in the backup directory).

* Flag.

* File properties (if any).

Then more data are provided by analyzing the file itself:

* Last modification time of the file in the backup directory.

* File type (by magic numbers).

* Message Digest 5 (MD5) hash.

* First 30 bytes of the file in hexadecimal format.

* First 30 bytes converted to ASCII characters.

Finally, a more comprehensive analysis is conducted based on the type of the file:

* If the file contains ASCII text, the whole content of the file is shown in the main text area. The same applies when we are analyzing plain text plist files.

* If the file is a binary plist, it is converted to plain text plist by an external utility written in Perl to a temporary file. The temporary file is then shown in the main text area.

* If the file contains binary data, then the file content is displayed as an hexadecimal dump. The utility displays on each line of the main text area the input offset, followed by sixteen space-separated bytes of data, followed by the same bytes converted to their ASCII counterpart.

* If the file is a recognized image (such as PNG or JPG), the image itself is shown in the main text area. If the image is a JPG, then the software displays a list of all the EXIF data it contains.

* If the file is a SQLite database, then the software displays a list of all the tables in the file, each with the number of records it contains.

When an SQLite file is selected, in the right column the software displays a list of the tables in the file. When the user clicks on a table, the tool dumps the content of the table (preceded by a description of the table structure) in the main text area.

The software is still in active development, and has been fitted with a couple of experimental functions which will be extended in future releases, such as a search function, a timestamp converter (from absolute time format) and an option to export the text in the main text area to an external file. Future versions of iPBA will continue to improve the analysis of each object, by providing additional builtin tools to show additional data more related to each file type (for example a way to decode thumbnail files, which as shown above are built in a non standard format). Other improvements will lead to provide personalized functions to decode and present important data for which the structure has been recognized (for example, we could provide a function to exploit the structure of the SMS database to show the conversations in a iPhone-like style). And to make the software useful in a forensics examination it will need reporting functions with integrity check of the objects.

5.1 Practical informations

iPBA iPhone Backup Analyzer has been released as open source software under the MIT license. Further informations about the software itself, along with links to download the code and Screenshots are provided at the address http://ipbackupanalyzer.com.

We chose to distribute the software as open source mainly to provide a common platform for the analysis of iOS backup data; all the interested people are encouraged to participate, by contributing with new code, fixing bugs or by just testing the software and making suggestions.

6. CONCLUSIONS

This study explored the forensics examination of the content of an iPhone device by exploiting the backup data acquired by the iTunes software. The examination process tried to make a comprehensive identification of all the objects found among the thousands of files contained in the backup directory. During this study an application has been developed to make the process faster and simpler.

During this research we have been able to locate a significant number of pieces of data which constitute the first objectives of a forensics analysis of a smartphone (such as contacts, sms data, browser data and so on) along with the objectives required by the analysis of a complex device like the iPhone (applications data, notes, audio memos and so on). We have been able to uncover hundreds of elements and provide a brief description of each, along with hints about their usefulness in a forensics analysis and instructions to build tools to further analyze them.

iPhone forensics is an evolving field, first of all because of the continuous changes in the structure of the operating system which leads to modifications in how the data is stored and formatted. The structures we described in this research will be probably subjected to modifications in the following versions, so the first goal of the mobile forensics community should be to keep an open eye on future releases of iOS to uncover these modifications and keep the knowledge of iOS up to date.

Footnote

1 GUID (Global Unique IDentifier): a unique reference number used to identify a device.

2 ICC-ID (Integrated Circuit Card IDentifier): an international identifier for the SIM card in the device.

3 IMEI (International Mobile Equipment Identity): a number, usually unique, used to identify mobile phones.

Footnote

4 ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably.

Footnote

5 DTD: Document Type Declaration

Footnote

6 MCC: Mobile Country Code. The code identifies the country of the operator.

7 MNC: Mobile Network Code. The code identifies the mobile provider.

8 LAC: Location Area Code. The code identifies a set of base stations grouped together to optimise signalling.

9 CI: Cell Identity. The code identifies a single Base Station.

References

REFERENCES

[1] Mona Bader and Ibrahim Baggili. iPhone 3GS Forensics: Logical analysis using Apple iTunes Backup Utility. Small Scale Digital Device Forensics Journal, 4(1), September 2010.

[2] Understanding file permissions on Unix: a brief tutorial. URL

http : //www . dartmouth .edu/ rc/help/f aq/permissions . html. Retrieved February, 201 1.

[3] MBDB and MBDX Format. URL

http: //code .google. com/p/iphonebackupbrowser/wiki/Mbdb Mbdx Format. Retrieved February, 2011.

[4] SQLite Wikipedia article. URL

http : //en. wikipedia . org/wiki/SQLite. Retrieved February, 2011.

[5] Plist Wikipedia article. URL

http: //en. wikipedia . org/wiki/Property\s\do5 (1) ist. Retrieved February, 2011.

[6] Mac OS X Reference Library: Keychain Services Concepts, a. URL

http : //developer . apple . com/library/mac/#documentation/ Security /Conceptual/keychainServConcepts/02concepts/concepts . h tml. Retrieved February, 2011.

[7] Peeking Inside Keychain Secrets, b. URL

http: //blog. er ackpas sword. com/2 010/ 08 /pee king- inside - keychain -secret s /.Blog post retrieved February, 2011.

[8] Cracking Blackberry Backup Passwords. URL

http: //blog. er ackpas sword. com/2010/09/.

[9] Exchangeable image file format for digital still cameras: Exif version 2.2. Technical report, Japan Electronics and Information Technology Industries Association - Technical Standardization Committee on AV & IT Storage Systems and Equipment, April 2002. Retrieved March, 201 1, from http://exif.org/Exif22.PDF.

[10] Cfdate reference on mac os x developer library. URL

http : //developer . apple . com/library/mac/documentation/C oreFoundat ion/Re ference/CFDateRef /Reference /reference, html. Retrieved on March, 2011.