Unlike many of the code division multiple access (CDMA) devices, which have an SD card slot, the iPhone does not contain any form of external storage (other than a SIM card). All data is stored in the internal NAND Flash memory. In the “iPhone Disk Partitions” section later in this chapter, slice 2 (or “rdisk0s2”) is where all the user data files are stored. It is this partition that is imaged during a physical acquisition of the device. A listing of the top-level files and directories in which much of the user data is stored is listed below. A significant portion of Chapter 6 focuses on these main directories, as well as other portions of the file system.

As all data are stored on the internal device, having the ability to image the iPhone in a way that pulls off both allocated and unallocated data can be crucial in an investigation. Deleted text messages, photos, or videos can often make or break a case, thus making a physical acquisition of the user data partition (rdisk0s2) ideal.

One of the more common types of data storage used by many mobile application developers is the use of a SQLite database. Databases are used for structured data storage and SQLite is a popular database format that appears in many mobile systems as well as traditional operating systems.

SQLite is popular for many reasons. Notably, the entire code base is high quality, open source, and released to the public domain. The file format and the program itself is very compact and contains significant functionality in less than a few hundred kilobytes. Unlike more traditional relational database management systems (RDBMS), such as Oracle, MySQL, and Microsoft's SQL Server, with SQLite the entire database is contained in a single cross-platform file.

Applications need to be able to store and retrieve data in an efficient manner. Developers have commonly created their own individual file formats for this purpose; however, many are now turning to SQLite because it is free, open-source, high quality, and efficient. Even after a system crash, SQLite transactions are still available.

Apple developers have leveraged SQLite databases for data storage within the iPhone. Many of the popular default applications are stored in this format such as the Address Book, Calendar, Notes, Text Messages, Photos, Voicemails, and more. Data within these files is broken up into tables, which contain the actual data. Figure 3.2 displays the SMS SQLite database structure within SQLite Database Browser on a Mac. A listing of all the tables is shown, with the “Message” table actually selected.

Information on SQLite files can also be retrieved through command line. On a Linux Ubuntu workstation, a database file can be viewed and modified. The following command opens the SMS.db file using SQLite version 3:

Once open, various commands can be run in order to retrieve data. For example, the following lists all tables in the database:

The next command describes the structure of the message table, referred to as the “schema.” The schema describes the way in which the database will be organized in its own special language.

Looking at the schema of the messages table is just another way of understanding the different fields within that table as well as all data types associated with that field. Another way of looking at this information is through the SQLite Database Browser that was used earlier. This software is a free, open-source tool used to create, design, and edit database files that support SQLite. SQLite Database Browser is available for Mac, Linux, and Windows platforms, and can be downloaded at http://sqlitebrowser.sourceforge.net. Other SQLite database viewing options are also available at http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

Since such a significant amount of iPhone data can be found within SQLite files, an examiner should make it a priority to understand how these databases are leveraged. Details on recovering information from these files will be covered in Chapter 6.

Property lists are used by applications to store, organize, and access various data types on iOS devices as well as Mac OS X. More commonly referred to as “plists,” these files are made up of a hierarchy of three classes, all bundled up into one “list.” These three classes consist of the Cocoa Foundation, Core Foundation, and XML. When a plist is created in XML format, an application is then able to read from it, while at the same time converting the XML properties into their appropriate objects to be used in both the Cocoa and Core Foundations (Apple Inc., 2010). A property list in XML format, opened on a Mac using TextWrangler, looks similar to the text displayed below. This is a portion of the “com.apple.Maps.plist” file. In it, latitude and longitude coordinates, and other data (not necessarily shown here) can be easily identified.

A property list can be stored in either XML format or binary format (which is used by the Cocoa Class OS layer). Apple began storing certain preference files in binary format in order to reduce the file size and make application access more efficient. As an example, repeated values within a file need to be stored only once and can be referenced when needed later in the file. Also, data can be stored in bytes rather than in a string. These are just a few examples of how binary plists (or bplists) can reduce the file size of a property list (Caithness, 2010).

If a property list is formatted as XML, the file can be viewed using any standard text editor. If stored in binary format, which is essentially a more compact version of the XML plist, the file must be opened by an application that can convert it to ASCII. Plutil, which stands for “property list utility” is one of these applications. This tool converts plist files between binary and text formats when run against a property list file. It also has the capability to scan a property list file and check it for proper XML syntax. Plutil is purely command-line driven and can be run on Windows, Linux, or Mac OS X (PERL, 2008). By default, plutil is installed on a Mac in the directory /usr/bin/plutil, and is available for download on the Internet for Windows and Linux. Prior to conversion, a binary plist is unreadable and shows something like “bplist00” followed by any number of unrecognizable characters.

To convert this file to ASCII format, the following command can be run using plutil:

To convert from XML to binary format, run the following:

No output will be shown, but when the user attempts to open the file, the format will have been converted to either binary or XML, depending on the command that was run. Another helpful option that can be run against a property list file is the “-lint” option. When incorporating this option into the command, the utility will let the user know whether the plist contains syntax errors:

Data within a property list can be of various types, including strings, numbers, binary data, dates, and Boolean values. Because a property list consists of three classes of data, this data must be represented in three different ways. The various data types as well as the ways in which they are represented to each class are demonstrated in Table 3.1 (Apple Inc., 2010).

On the iPhone in particular, property lists are commonly used by applications on the device in order to present options to the user. In particular, Safari web history and bookmarks, YouTube data, Favorites, and many other preference files are stored within property lists. Property list use has simplified mobile application development. Programmers can use these configuration files in order to modify features and functions within the application. Changes can be made to an application by simply modifying the plist and updating this file on the device.

For more details on binary and ASCII plists, refer to CCL Forensics presentation on “Property Lists in Digital Forensics.” This document contains the history of property lists, the structure of both XML and binary format, the algorithm used to convert between the two formats, and how to carve and parse property list files and content.

Another option that developers have is storing data in the cloud rather than on the device itself. Initially, very few applications took advantage of the network as a storage option; however, as devices and applications mature, network storage is gaining leverage. There are many applications available on the iTunes store that allow file sharing and network access. Some examples of these include My Network Folders, Air Sharing, QMobile, and Dropbox. These applications operate in several ways. One method allows the device to upload or download stored files through a web browser. Another option involves connecting the device to a computer, mounting it as a drive, and then copying files to and from the device. As an example of a file sharing app, Dropbox has become a widely popular file sharing website, which has mobile applications for iOS, Blackberry, and Android devices. The current application, version 1.3, was updated on November 10, 2010 and has over 1100 mostly positive ratings. After it is installed and used, all user activity is stored within the “Applications” folder. More details on the analysis of this particular application is reviewed in Chapter 6.

RAM is used by the system to load, execute, and manipulate key parts of the operating system, applications, or data, and is not saved on reboot. Like traditional computers, RAM can contain very important information which applications use to process data. Some examples include:

The ability to acquire RAM from a device can be crucial in an investigation; however, it is important to get this information prior to the device being shut down or rebooted. While examining memory from a standard Windows hard drive, Linux workstation, or even Android device is possible, there is currently no method to recover memory from a live iPhone device. Up until early 2011, RAM acquisition of Mac OS X could be accomplished to some extent by recovering the “sleepimage” file, located in /private/var/vm/sleepimage. The purpose of this file is to store what the Mac had in its memory when the system went to sleep. When the computer is “woken,” the information contained in the sleepimage file is re-distributed to memory in order to allow the Mac to return to its original state prior to sleeping (Sleepimage, 2010).

In early 2011, Mac Memory Reader was released. This is a command line utility that performs a memory dump on a Mac OS device and outputs the results onto an external device (Valenzuela, 2011). Unfortunately, Mac Memory Reader does not apply to iOS devices yet.

Unlike RAM, NAND Flash is nonvolatile and thus data is preserved even when the device is without power or it is rebooted. The NAND Flash is used to store not only system files but significant portions of the user's data as well.

NAND Flash memory has characteristics very different from the magnetic media found in modern hard drives. These properties make NAND Flash ideal storage for mobile devices, while at the same time presenting a number of challenges for programmers and opportunities for forensic analysts.

First, NAND Flash has no mechanical moving parts like the spinning platters and arms found in traditional magnetic hard drives. This improves the durability and reduces both the size and power consumption of the device. The memory is distributed as one or multiple chips, which often integrate both NAND Flash and RAM and are directly integrated into the circuit board of the device.

NAND Flash also has very high density and is cost effective to the manufacturer. This, of course, makes it very popular with manufacturers. One side effect of the manufacturing process and technology in general is that NAND Flash literally ships with bad blocks directly from the manufacturer. The manufacturer will generally test the memory as part of the manufacturing process and mark bad blocks in a specific structure on the NAND, which is described in their documentation. Software that then directly interacts with the NAND Flash can read the manufacturer's bad block markers and will often implement a bad block table that can logically track the bad blocks on the system and remove them from operation. This greatly speeds up bad block detection and management. So, while NAND Flash is more physically durable than spinning platters, its error rate is much higher and must be accounted for in development and use.

Another significant limitation of NAND Flash is that it has a very limited write/erase lifespan before the block is no longer capable of storing data. The lifespan varies by device and is largely impacted by the amount of data stored per NAND Flash cell, the central building block for storing the 1 or 0 bit(s). If the cell stores only a single bit (single-level cell or SLC), then the NAND Flash supports around 100,000 write/erase cycles for a 1-year data retention. However, NAND Flash rarely uses SLC, as manufacturers (and consumers) demand more data storage in devices that are of similar size or smaller. The technology has moved to multilevel cells (MLCs), where a cell can store 2, 3, or even more bits per cell. However, this not only complicates the manufacturing process and slows down the write/erase cycle but also significantly reduces the endurance of the device. A typical MLC NAND Flash storing 2 bits per cell experiences a 10-fold reduction in endurance (measured as a 1-year data retention) with a value of approximately 10,000 write/erase cycles. As the bit density per cell increases, the endurance continues to drop, which must obviously be addressed by the controlling device.

Unlike RAM and NOR Flash (which also has Flash memory and is typically used in systems such as a computer's basic input output system or BIOS), NAND Flash cannot be accessed randomly. Instead, access to data is achieved via an allocation unit, called a page, which is typically between 512 and 2048 bytes, but generally increases as the overall size of NAND Flash increases. As an example, on one 32 GB iPhone 4 device, there were shown to be 8192 bytes per page. Even though NAND Flash does not provide the fast random access like RAM, access time is still quite fast since it does not require the mechanical platter and arm movements used in traditional spinning hard drives. The pages are then organized into a larger logical unit called a block, which is typically much larger than a traditional 512 GB hard drive sector. When a block is allocated for writing, the pages inside the block are written sequentially.

Within the iPhone's file system, there is a file called “ADDataStore.sqlitedb” that contains specific details related to the NAND Flash contained within that device. With some of the earlier models, this database was empty. However, when populated, the “Scalar” table will contain information similar to the following:

Key characteristics of NAND Flash are the operations available for reading and writing:

While individual pages can be read or written, the erase operation only functions at the block level. When a block is erased, the entire block is written over with 1's (or 0xFF in hex). The erase operation is the only mechanism by which a 0 can be changed to a 1 in NAND Flash. This point is worth belaboring. In a traditional hard drive, if a value is changed from a 0 to a 1 (or vice versa), the program simply seeks the value on the hard drive and applies the appropriate voltage to change and store the new value. However, the fundamental architecture of NAND Flash provides only one mechanism to change a 0 to a 1 and that is via the erase function which is applied at the block level, not an individual page level. For this reason, a page can be written only once, and if the value of the page needs to be changed, the entire block must be erased and then the page rewritten.

Here is a specific example using a single byte for simplicity: Let us say this particular byte holds the decimal value 179 and we want to add 39 for a total value of 218. For those unfamiliar with converting numbers between base10, hex (base16), and binary (base2), the built-in calculator programs in Windows, Mac OS X, and Ubuntu Linux, all provide a programmer mode that will perform the conversions. For the numbers above, we have the conversions between numbering systems shown in Table 3.2.

So the value 179 contains three 0's and two of them need to change to 1's to present our new value of 218. However, NAND Flash cannot make that change without erasing the entire block. So, if this single byte were attempted without the erase, the result would be 146, not 218. Here is how this happens:

As the byte does not contain all 1's (0xFF), the only portions of the write cycle that will succeed are 1's either remaining a 1 or changing to a 0. Whenever the write function encounters a 0 and is requested to change to a 1, it fails and simply retains the 0 value. The resulting byte is 0x92 or 146 base10 – clearly not the value intended. Another way to describe the write function is that it only changes the changed 1 values to a 0 when requested, the equivalent of the “logical and” of the two values.

In summary, a page can be written only once and, if it needs to be rewritten, the entire block must first be erased.

As one can tell, NAND Flash imposes various restrictions and limitations and thus developers and file systems must be Flash-aware to effectively work within the constraints. Two important techniques deployed are error-correcting code (ECC) and wear leveling. Both have significant implications for forensics and data recovery.

First, ECC is a technique in which an algorithm is used to detect data errors on read or write operations and correct some errors on the fly. Since NAND Flash degrades over time through usage, the system must be able to detect when a page or block is going bad and recover the data stored there. After a number of errors or failed operations is exceeded (typically three failed operations), the page or block will be marked bad and added to the bad block table.

The second important algorithm used to effectively manage NAND Flash on the iPhone is the wear-leveling code. Wear leveling spreads the writing of data across the entire NAND Flash to avoid overutilization of a single area, which would wear those blocks out more quickly. It is built into HFS Plus (Hierarchical File System Plus) with the goal of reducing writes and deletes to the NAND so that the data is preserved as long as possible. Wear-leveling is also the reason why so much information can be recovered from the device. Old data copies are not deleted, but instead marked as “unallocated.” For this reason, there are latent copies of sensitive iPhone data that can be analyzed for information but may have been deleted days, weeks, or months earlier. This analysis is discussed further in Chapter 6.

The iOS kernel is loosely based on the Mac OS X kernel, and contains several layers that are used to run applications. The layers include Core OS, Core Services, Media, Cocoa Touch, and Applications. The following is a description of each of the architecture layers within iOS (Apple Developer, 2010):

Each HFS Plus system is made up of volumes, which represent a portion of the physical disk. Each system can be made up of one or more volumes, with each volume consisting of a header, and alternate header, and five special files. Three out of the five special files contain a B-tree structure: Catalog File, Extents Overflow File, and Attributes File. A B-tree is a data structure that allows data to be efficiently searched, viewed, modified, or removed. It is made up of nodes that store key information, allowing for fast searches (Kubasiak et al., 2009).

One attribute of the HFS Plus file system is that it allows the option of “journaling.” When journaling is enabled, a log of changes is kept, which keeps track of the changes it plans to make prior to making them in the main file system. In the event of a system or hardware component failure, the journal is used to help restore the disk back to its original state prior to the failure. Instead of having to check the entire file system, the OS just looks at recent journal transactions, allowing for a fast recovery.

Two disk partitions exist on the NAND Flash. The first is the system, or firmware partition, which is where the OS as well as basic applications resides. When firmware upgrades are performed on the device, the system partition is updated. With few applications actually installed here, the system partition takes up only a small portion of storage space on the device. It is configured to be read-only by default, except while performing a software upgrade. During this process, the entire partition is formatted by iTunes, without affecting any of the user data.

The user data partition, also referred to as “Slice 2,” takes up most of the space on the NAND. This is where most, if not all, evidentiary data can be found. Information on the default applications, those downloaded through the iTunes App Store, and other stored data can all be found on this partition. This image, after being forensically acquired, can be renamed as a “.dmg” file and mounted on a Mac for analysis (more on this in Chapter 6). While both slices can be imaged and analyzed, the user data, or “Media” partition, is what is typically acquired. This partition is mounted on the device at “/private/var.”

Table 3.4 provides a breakdown of the two disk partitions and provides information on mount points, information stored, and more.

As a test iPhone that had previously been jailbroken was available, the device could be connected in order to view the mounted partitions. The phone was connected through SSH, and the “mount” command was run on the root of the device. The System partition is shown first as being mounted on “/” (or root) as well as the User Data partition mounted on /private/var. Both partitions show HFS as the file system, and the User Data partition even shows that journaling is enabled.

The above information showed block devices, while the following are the raw disk images on the iPhone. Rdisk0 is the entire disk, including all partitions. Rdisk0s1 is the firmware partition, or Slice 1 as described above, just as Rdisk0s2 is the User Data partition. On a 3GS device, “rdisk0s2s1” is also shown.