/private/var/mobile/Library/SMS:

The “message” and “msg_pieces” tables are the two areas that should be the main focus when analyzing the sms.db.

The messages table contains each of the text messages, including the phone number from or to which the message was sent, date and time of the message, the message content, a “flags” column (specifies whether the message was sent or received), and other data. The following is a breakdown of each of the columns within this table and a definition of each:

The msg_pieces table contains the text content that is sent along with an MMS message. The following is a breakdown of the meaningful columns within this table and a definition of each:

/private/var/mobile/Library/Calendar:

The “Event” table is the one that examiners should focus on; however, other tables can also be analyzed as needed. The Event table contains information relevant to the calendar events that were manually entered by the user or possibly synced up with their e-mail account, MobileMe account, or another tool. The following is a breakdown of each of the columns that contain relevant information and a definition of each. Many of the columns have been omitted as they do not contain useful information.

/private/var/mobile/Library/CallHistory/:

The “call” table is where most of the information is going to be found; however, as with the other database files, the “sqlite_sequence” table tracks the most recently used row ID for certain tables in the database. The following is a breakdown of each of the columns within the call table that contain relevant information and a definition of each.

On the iPhone, there is a call history limit of 100 logs. Any calls placed or received above 100 will be stored in the database, but the oldest record will be removed. Therefore, upon viewing the call_history.db file in a SQLite database browser, an examiner will not see more than 100 records in the call table. However, using the advanced analysis techniques described earlier in this chapter (strings, hex editor, etc.), it is possible to recover the old call logs that were replaced.

/private/var/mobile/Library/Keyboard:

While this is not a database or plist, the user's dynamic dictionary file can contain interesting artifacts. A .dat file is a “data” file, and the way it is viewed depends on its contents. Because it is known that this particular file stores text, it can be opened in any text editor. However, when opened in this manner, all the words run together and the analysis is difficult.

It is much more efficient to use the “strings” command and either redirect the output into a text file or display the output through the “less” command (see Chapter 1 on how to use basic Linux commands).

Oftentimes, full text messages and e-mail content are found in this file; however, it is impossible to determine any other information about the source, such as date and time or the individual who sent or received the message.

Many examiners want to know whether passwords are stored in this file, and the technical answer is no. If a user enters a password (or PIN) into a password field on the device, such as when he or she logs into his or her e-mail account, the device knows not to store that information. However, if the user decides to enter their password into a note, document, or e-mail on the device, it is possible that it would be stored in the dynamic text file.

/private/var/Keychain/:

/private/var/mobile/Library/Mail/:

/private/var/mobile/Library/Webkit/Databases:

From the files described in the previous sections, one can see that there are various locations within the iPhone file system where e-mail remnants can be found: the “Mail” folder and the “WebKit” folder. The databases within the WebKit folder have been thoroughly discussed as they contain allocated files. Next, the contents of the Mail folder are discussed.

As mentioned earlier, there is a specific folder assigned to each Mail account synced to the device, and these files can be viewed with a physical image of the device. For an exchange mail account, the folder will begin with “ExchangeActiveSync…,” whereas a Gmail or Yahoo account might begin with “[email protected]”. Within this folder, the following folders can be seen:

Within these folders are some of the actual e-mail messages in the form of a “.emlx” extension. These files can be viewed in a text editor, or by importing them into the Mail program on a Mac. In addition to e-mail messages, there are also files with a “.emlxpart” extension. This contains files that have been attached to one or more of the e-mails. Let us assume that this file extension is unknown. The following command can be run on a Linux machine to determine what type of file this is, and thus understand what tool is needed to view it. First, we will list out the files in the “Messages” folder and then determine the file type.

From the output of the “file” command, it can be seen that the .emlx file is text and the .emlxpart file is a compressed archive, which must be unzipped. This file can be copied to another location on the examiner's machine (since the iPhone dmg should be mounted as read-only) and unzipped to view the file contents and attachments.

While messages in the user's “Deleted” mail folder can be recovered, those that have been fully deleted or emptied from trash cannot be found in the Mail folder. A file carving utility can be used to extract e-mails from a disk image (see the “File Carving” section earlier in this chapter). Here, e-mails can be recovered, including those that have been deleted. The examiner can then use the “grep” command to search through all the e-mail files for specific keywords. In the following example, all the e-mail files (*.email) are searched for the viaForensics e-mail address shown.

With the ability to perform file carving on a full physical disk image, a significant amount of e-mail content can be recovered from a device. Unfortunately, a physical acquisition is not always possible. In the event that only a logical or backup acquisition is possible, the WebKit is a good place for an examiner to start, and at the very least, e-mail account information can always be found in the keychain database. Refer back to Chapter 5 for details on how passwords stored in this database can be decrypted!

/private/var/mobile/Library/Maps/:

Each of these plists is in binary format. When hitting the space bar to open one of these files in Preview (on a Mac), some of the data appears to be encrypted, or otherwise unreadable. However, when opening it in a text editor, the directions, bookmarks, and history can be read. In this instance, converting from binary to XML is not necessary. As an example, here is what Directions.plist looks like when it is converted to XML and opened in a text editor:

When the same file is left as a binary plist and opened in a text editor, the data is difficult to decipher, but the directions are legible (see Figure 6.9 ).

/private/var/mobile/Library/Notes:

This app is pretty straightforward. There is one file that needs to be analyzed: notes.db. Upon opening it in a database browser, the “Note” table is where an examiner should focus his or her attention. The “note_bodies” table also contains note content; however, this same data is available in the Note table. The following is a breakdown of each of the columns within the Note table that contain relevant information and a definition of each:

/private/var/mobile/Library/Safari:

Each of the Safari data files (Bookmarks, History, and Suspend State) by default are in binary plist format, just as the files within the Maps directory. In this instance, however, the data can be easily viewed and examined by opening the file with the space bar on a Mac. When attempting to open the Safari binary plists in a text editor, the data is not formatted appropriately. Using plutil, or another utility to convert the binary plists to XML, the information is displayed in a more organized manner (as shown in the examples for each plist).

Allocated web history will be stored in History.plist, but in order to access deleted web browsing data, the SuspendState.plist must be analyzed. The only downside to SuspendState.plist is that timestamps are not shown as they are in History.plist.

/private/var/mobile/Library/Voicemail:

The database contains details about each of the voicemails; however, to actually listen to the messages, the examiner must open the “.amr” files using a media player. These files are named after the ROWID in the database. For example, for ROWID “6,” the equivalent voicemail will be “6.amr”.

The iPhone contains a feature known as visual voicemail. This allows the user to visually see the different voicemails contained on their device. If they wish to delete a voicemail, they can select that option on the touch screen. However, from a forensic standpoint, it is important to understand that when deleted, the voicemail first goes to a “Deleted” folder that can actually be seen in the Voicemail application on the device. The user can then go into this folder and either restore that voicemail or permanently delete it (think of this as a Windows Recycle Bin). Oftentimes, a logical acquisition tool will report a voicemail as “Deleted” when in fact it is simply sitting in the “recycle bin” on the device.

It is easy to determine from the voicemail database whether any records have been permanently deleted by taking a look at the ROWIDs. Since they increment by 1, if there is a missing number, it can be assumed that the missing record was deleted by the user. SQLite analysis techniques can be used to try and recover these deleted rows.

/private/var/mobile/Library/Preferences/:

At first glance, the bookmarks and history items appear to be encrypted data. However, the characters within the <string> tags are actually a YouTube ID. This ID can be copied into a URL in order to view the actual video. For example, here is the URL for a random YouTube video: http://www.youtube.com/watch?v=1yk8bC6QDYo . The string of characters following the “=” sign is the ID. By replacing this ID with one shown in the plist, the YouTube bookmarks and history can easily be viewed.

The most recent YouTube search performed by the user is also in this file, and is shown under the “last Search” key. In this example, the most recent search was “golf swing tips.”

/private/var/mobile/Media/:

Most examiners will want to see not only the photos that were stored on the device but also information about these photos. By using the information retrieved from the photos.sqlite database in combination with the actual photos or videos stored in the 100APPLE or 999APPLE folder, the examiner can determine information such as when those photos were taken or modified. Some of the advanced techniques discussed earlier, such as using a hex editor or the “strings” command, can help to locate deleted files within the database as well. While deleted videos are extremely difficult to recover (and sometimes impossible), deleted photos can be recovered through file carving. Unfortunately, at this time the metadata cannot be paired up with the recovered file because the photo no longer has its original file name, timestamps, etc.

/private/var/Keychains:

The “inet” table is where e-mail account data can be found, and the “genp” table is where the remaining login data can be located. As the “inet” table has been elaborated on in the Mail section, we will discuss only the “genp” table here. The following is a breakdown of each of the columns within the genp table that contain relevant information and a definition of each:

In Chapter 5 , we discussed the possibility of using Elcomsoft's iPhone Password Breaker to decrypt an encrypted backup file, and therefore gain access to passwords within the keychain file. This method is successful only with a device running iOS 4 or higher, and the backup file must be encrypted.

Another option is available on jailbroken devices only. The “keychain_dumper” utility, developed by Patrick Toomey, is run from the device and can decrypt Keychain passwords on the fly. To acquire and use this tool, the following instructions should be followed:

Assuming that the application developer was leveraging the Keychain file and was not using an alternative form of encryption, the passwords should be available in clear text and displayed in a format similar to the following:

/private/var/root/Library/Caches/locationd: Some of the following files may or may not appear in the locationd folder, depending on the firmware version running on the device. Listed here are the files that contain significant data, and a couple of these are discussed in further detail in the “Databases/plists” section that follows.

While these files appear to contain very important information on where the device was, what cell towers it was connected to, and the specific dates and times of these occurrences, it is also important to note that there has not been much research on these files. Oftentimes, the data in these files place the device at multiple geographic locations at the same time. Therefore, this information should be used as a guideline only when performing an investigation.

/private/var/mobile/Applications/<Facebook Application Identifier>/:

In addition to the allocated files recovered from the Application folder, much more app data can be recovered through additional techniques. After running the “strings” command on the entire disk image (refer to the earlier section on “Analysis Techniques” for details on running strings), simply doing a search for the user's Facebook login will recover additional data. Some of this data includes status updates, messages written on the user's wall, and actual messages that were sent to or from the user.

/private/var/mobile/Applications/<Application Identifier>/Documents/v1/users/<username>/groupons:

/private/var/mobile/Applications/<Application Identifier>/Preferences/:

The information within these files is fairly straightforward. To view the property lists, they have to be first converted from binary to XML using plutil (or another utility). The date and time do not need to be converted. When this app is being analyzed, the plists in the “dealLocations” and “deals” folders should not be confused with those listed under the specific user name. The Groupons listed in those two folders are simply coupons that were available, but the user did not actually purchase them.

/private/var/mobile/Applications/<Application Identifier>/:

The files described in this section contain a significant amount of data; however, this is data that has not been deleted from within the app. To recover deleted information, it is suggested that an examiner use some of the additional analysis techniques described earlier in this chapter. For example, looking at the disk image in a hex editor and searching for a unique user name should recover messages sent to or from that user, including some deleted data.

/private/var/mobile/Applications/<DropBox Application Identifier>/:

In addition to the allocated files described in this section, data carving methods can also be performed on the iPhone.dmg file to recover the actual files that were stored within DropBox, including deleted files. As data carving extracts .doc, .pdf, .jpg, and more, this method can be very useful.

If the iPhone user's computer is also available, be sure to look for a DropBox folder on their machine in order to recover additional files.

/private/var/mobile/Applications/<Mint.com Application Identifier>/Documents:

While only a few of the tables have been discussed, there is additional data in the remaining tables. If an examiner is required to analyze the mint.com mobile app, he or she should be sure to review all the data meticulously so as not to miss any data.

With this particular app, the user has the option to log out of the app. If this is done, no data will be found in the mint_gala.db file. All of this information is still stored on the device, but advanced techniques (such as those discussed earlier in the chapter) are required to recover the data.

/private/var/mobile/Applications/<Windows Live Messenger Application Identifier>:

The CurrentUserName.tmp file is actually a plist, and when analyzed contains the user's hotmail address. This is a binary plist and would typically require a tool such as plutil to be converted to XML; however, as the file contains only the user name, viewing the binary plist to retrieve this data works just as well.

Aside from the user name (or hotmail e-mail address in this case), Windows Live Messenger did not appear to store specific app data. Keep in mind that version 1.1.1 was analyzed for this example, and future versions may store additional data.