The source code for scalpel can be downloaded from http://www.digitalforensicssolutions.com/Scalpel/ or installed via command line. The latter will automatically install the latest version. The following command must be run on the Linux workstation to install scalpel.

Alternatively, one can compile from source, which will allow the installation of the latest version on Linux or other platforms without waiting for the specific platform maintainer to update the prepackaged version. In this method, the package must be compiled and built from the source code using the specific commands. First, the archive must be extracted using the tar command (-x will extract the files, -z unzips the files, -v signifies verbose output, and -f specifies the archived file). The following commands should be run to extract the files and compile the program. In this example, Scalpel version 1.60 was used. The most up-to-date software available at the time should be used.

The scalpel executable is now in ~/scalpel-1.60 and is simply called scalpel. In addition, there is a sample scalpel.conf in the same directory, which is needed for scalpel to run and to extend the supported file definitions. Here is a starter scalpel.conf for an iPhone device:

As one can tell, the headers for this configuration file define the extension or file type, whether it is case sensitive, the maximum size to carve, the header definition (in ASCII, hex, and other supported notations), and the footer (if it exists). A targeted file type for carving does not need to define each setting. For additional information, see the sample configuration file in the downloaded source files, as there are many additional options that are quite powerful. Your workstation now has the software needed for file carving.

It is worth pointing out that a large number of file signatures have already been assembled. Gary Kessler, an independent consultant and practitioner of digital forensics, actively maintains a table of file signatures on his website. He references the “magic file,” which is found on most Unix systems and is located at /usr/share/file/magic on the Ubuntu workstation. On the workstation, one can run the “file” command, which takes a file as an argument and attempts to determine the file type based on the signatures in the magic file ( Kessler, 2011 ).

A simple example would include looking at an unknown file that cannot be easily identified by the file name (of course, some people might try to hide file types by changing the extension, but this is easily discovered by examining the file signature):

Looking at the “syslog.pid” file found in the “run” directory at the root of the device, the file command shows that this file contains ASCII characters.

To use scalpel, you will first need to have the program installed and compiled and also have access to a dmg (or other image file) and the scalpel configuration file. By default, scalpel will create a “scalpel-output” directory in the current folder, so make sure you are cd'd into the directory where you would like the output to go. Run the following command:

The command is broken down as follows:

When scalpel has finished, a “scalpel-output” folder is created in the current directory, which contains all the recovered files, sorted by file type. Table 6.1 contains a breakdown of the standard file types recovered from an iPhone using scalpel and the type of information that may be found within these files.

In this example, TSK is going to be installed on a Linux machine. To install and compile on a Mac, Apple's Developer Tools are first required (specifically, XCode 3 must be installed from developer.apple.com). Details on compiling TSK on a Mac can be found on www.appleexaminer.com , a site developed by Ryan Kubasiak, which contains a wide range of free tools and information dedicated to Apple device forensics.

The source code for TSK can be downloaded from http://www.sleuthkit.org/sluethkit/download.php . Once downloaded, the examiner can extract, compile, and install the software. The following command will extract the contents of the tar file (-x) in verbose mode (-v) to a file (-f), with much of the output removed for simplicity. In this example, TSK version 3.2.0 was downloaded, as this was the most recent version available.

Next, the software must be compiled. The following commands will complete this process; however, it must be kept in mind that one will first need to “cd” into the sleuthkit directory that was created in the previous step. Once again, most of the output for this command was removed.

Finally, the program can be installed:

The two specific tools used to create a timeline, fls and mactime, should be installed in /usr/local/bin/ (if installed on a Mac). If installed on Linux, scalpel will be installed in /usr/bin/scalpel. This means that the commands can be run from any directory, rather than having to “cd” into the folder in which the tools were downloaded or installed.

Once the install is successfully completed, the first step in timeline creation is to run the “fls” tool. “fls” goes through the entire directory structure on an image and lists each file contained on the file system, both allocated and unallocated. This command accepts several different arguments, and the general command contains the following parameters:

A description of the options can be found in Table 6.2 ( Kubasiak, n.d .).

The body file is simply a listing of all the files, file paths, and metadata that were gathered using the fls command. This file is not organized in a manner that allows an examiner to easily read its contents. A small section of the body file is shown below. While the directory path and file can easily be read, the remaining data are difficult to determine. Many of the numbers shown are various timestamps, but let us hold off on analyzing this data until it is organized a little better.

Next, the mactime command must be run in order to sort, merge, and otherwise organize the data into a readable format so that an examiner can more easily analyze the data. Similar to the fls command, mactime accepts a few different arguments with the following general format:

A description of these parameters is shown in Table 6.3 ( Kubasiak, n.d .).

Once the timeline.csv file is opened, the examiner can see all actions taken on the device including the file, file path, whether it was created, modified, or deleted, as well as the date and time on which this action occurred. A timeline is especially helpful in an investigation when an examiner can jump to a specific date and time to determine what actions took place. As you can see in Figure 6.1 , there are many different fields within an fls timeline including Date, Size, Type, Mode, UID, GID, Meta, and File Name. While some of those columns are fairly straightforward, let us discuss the contents within each column and what they represent.

The Date column is pretty clear. It contains the date and time (time zone specified when running the command) that the event occurred. The next field contains the size of the file in bytes. Following that is the “Type” column which plays an important role in the timeline analysis. These are the MACB times which tell whether the specified file was modified, accessed, created, or birthed. Let us describe these a bit further as they are very important in analyzing the data in this timeline. The MACB time can be defined as follows (Kubasiak, 2009):

The fourth column, Mode, contains file permissions in Unix format. Every file on the file system has a set of permissions that determine read, write, and execute permissions for a user, group, or other. The “user” is the owner of the file, a “group” may contain multiple users that have elevated privileges on the file, and “other” refers to everyone else with an account on that system. In Table 6.4 , file permission values are explained ( Dartmouth, n.d. ). So, looking back at the fourth column in Figure 6.1 , the file permissions show “r/rrw-r- -r- -.” The user has “rw” or read and write access, while the group and others have “r” or read access.

The UID and GID columns are the user and group IDs, and the Meta column, or metadata address, is the inode number of the file, which contains information about the object. Finally, the File Name column represents the path and file name on which the action occurred.

As an example, let us take a look at the timeline of events for August 25, 2010, around noon. A portion of this time frame has been extracted from a timeline.csv file created using the fls and mactime commands. For simplicity and readability, the following columns have been removed: Size, Mode, UID, GID, and Meta.

As you can see, the date and time is shown in the first column, followed by the MACB times, and finally the path/file name in the third. Analyzing the files within a timeline can be very time consuming, as it requires a lot of research to understand what the files signify. For the first example, we will start with an easy one. Starting at the top, we see a list of files within the /mobile/Media/DCIM folder. On the iPhone, this folder contains photos either taken on the device or synced to the device. Let us jump straight to the first jpeg file: IMG_0001.JPG. The timeline shows that this file was created, accessed, and metadata modified at 12:02:04. It is known that photos within the “100APPLE” folder were those taken from the on-board camera, so it would be safe to assume that this particular photo was taken at that time. To see which picture this was, an examiner could navigate to that file on the file system.

Moving down further in the timeline, the Mail app appears to have been used in some way. It shows that the viaforensicstest Gmail account was accessed and birthed (created) around 12:23 p.m. The next line shows “AutoFetchEnabled” which is updated when the e-mail is synced between the device and the mail server. It is likely that the Gmail account was originally synced with the device at this time.

As a final example, let us look at the final three lines. The timeline shows that the notes database was changed and the metadata modified, which implies that a note was viewed, created, or deleted from that particular database. The last line shows that a snapshot was taken of the notes application. Snapshots of applications on the device are taken at random points in time (this is discussed in more detail later in this chapter). This particular snapshot was most likely taken of the Notes application while it was open. Assuming the examiner is able to get a physical image of the device, this snapshot could very possibly be recovered through file carving.

This portion of the timeline contained merely 31 records out of the several thousand that were available in the timeline.csv file. To truly benefit from timeline analysis, it is important to have a specific time frame in mind and jump straight to that section.

Various applications will either ask the user if they wish to cache their current location, or the apps will store GPS data behind the scenes depending on the functionality of the app. For example, both the iPhone's camera and video camera will store latitude and longitude coordinates which describe where the device was at the time the photo or video was taken. The Google Maps application that arrives on the device by default also stores the user's current location as well as any other location that was searched within the application.

On top of these standard applications, there are countless apps available for download that will track GPS coordinates.

The consolidated.db file is new in iOS 4, and there is not a significant amount of documented information on the topic. This file stores GPS and Wi-Fi data in one central location, presumably to improve device efficiency since it now only has to access one file in order to send or retrieve location data. The database contains the following tables. The two that have been found to be the most beneficial are the WifiLocation and CellLocation tables.

The WifiLocation table contains the MAC address, timestamp, latitude and longitude coordinates, and other fields that can determine which wireless locations the device was connected to at a certain point in time. As an example, let us analyze the first row of the table shown in Figure 6.5 .

First, we will need to translate the timestamp displayed in the first column (306439818.409918). Using the CFAbsoluteTimeConvert (as these times are in OS X Epoch format), the time converts to Friday, September 17, 2010, at 01:10:18 p.m.

Next, we will need to look up the latitude and longitude coordinates provided in order to determine the actual location. There are various websites available that will translate these coordinates into an address; however, an easy way is to simply go to Google Maps ( http://maps.google.com ). Here, you will need to enter in the coordinates in the following format: +latitude, −longitude (see Figure 6.6 ).

A similar conversion can be done using the CellLocation table. Instead of Wi-Fi locations, this table contains cell tower logs, timestamps, and GPS coordinates (see Figure 6.7 ). The cell tower logs are displayed as MCC, MNC, LAC, and CI:

Using the timestamp and GPS coordinates within this table, a similar conversion can be done to determine which cellular tower the device was connected to at a certain point in time.

Using these resources, we can determine that the device was possibly in Oak Park, IL, on Friday, September 17, 2010, at 01:10:18 p.m. You might be wondering why this is not definitive. With this file, it is understood that several different coordinates are populated into the database at one time. So, according to the timestamps and location, the device could be in several different areas at the same time (however, these areas are typically within a few miles of one another). This could be because the database is not constantly being updated as a new location is populated therefore, there might be 3, 4, or even 20 locations updated into the table at one time. For this reason, it is important not to rely solely on the timestamps until the consolidated.db file is researched further and better understood.

In the WiFiLocation table, there were 404 records on a lightly used iPhone 3GS. Imagine having to manually convert the timestamp and GPS coordinates for each record in order to find the right one. It has been mentioned that a script was developed that would parse the data into Google Earth, but there is no word on its release ( iPhone GPS Data…, 2011 ). Until this file is better understood and tools developed to extract and convert the data, the information in this database should be used cautiously.

Within the file system, another area that contains geographical information on the device and its apps is the “locationd” folder. This folder is located in /private/var/root/Library/Caches/locationd. The locationd folder contains many different files:

One file worth mentioning is “cache.plist.” This file contains the Core Location's last GPS fix, or where the device was last located on the basis of identified wireless signals. This portion of the file is shown in the beginning and looks similar to what is shown in the following code:

Latitude and longitude coordinates are provided, which will translate to an approximate geographical location. While timestamps within the cache.plist file are not provided, an examiner can look at the day and time on which this particular file was last modified in order to get an approximate time the device was at this particular location.

Another file in the locationd folder that may be of use is cells.plist. This file contains numerous records of cell tower locations, similar to the CellLocations table found in consolidated.db. A snapshot of this file is shown in the following code:

The numbers shown in the “key” correspond with the same numbers displayed in the consolidated.db CellLocations table: MCC, MNC, and LAC. So, in the example above, 310 is the MCC, 410 is the MNC, and 0x1e7a (in decimal this is 7802) is the LAC. The “string” listed directly below these numbers contains latitude and longitude coordinates as well as a timestamp shown in OS X Epoch (304.557710.149). This is very similar to the data we saw in the CellLocations table of the consolidated.db file. This is because all of the cell tower and GPS data was consolidated into one database with the release of iOS 4. Nevertheless, it is important for an examiner to understand that this data can be found in both locations. This way, regardless of whether the device is running iOS 4 or earlier, geographical location data can be recovered.

Many applications, both default and downloaded, leverage Apple's Keychain database for user name and password management. The keychain-2.db file is stored on the root of the device in /private/var/Keychains. This database consists of six tables: genp, sqlite_sequence, inet, cert, keys, and tversion. The two main tables that are known to contain the most evidentiary data are genp and inet (however, it is never a bad idea to analyze all the tables in the database to ensure that important data are not missed).

The “genp” table contains a list of accounts that the device has been logged into at one point. Included in this table are wireless access points the device was connected to, voicemail login, device login (passcode), and any downloaded applications that elected to use the keychain database to store login credentials. The account name (username) and a description of that account are provided along with a “data” field, which contains an encrypted password for each account. This data is shown in Figure 6.8 .

The “inet” table contains any e-mail accounts the device has been synced to through the default Mail application. The following information can be found about each account:

While the passwords in both tables are in an encrypted format, there are ways to decrypt this data. As pointed out in Chapter 5 , with the release of iOS 4, encryption is now done at the device level. When an unencrypted backed-up device is initiated, the keychain file is encrypted using hardware keys stored on the device. When the database is opened, much of the information can be seen, but the passwords remain encrypted (as shown previously in this section). If an encrypted backup is generated, the keychain file is now encrypted using software keys generated from the backup password. Using Elcomsoft's iPhone Password Breaker, the passwords within the keychain file can be unencrypted and viewed in clear text. This technique is successful only on devices running firmware version 4.0 or higher. For detailed procedures on the use of Elcomsoft's software to crack the keychain file, see the section in Chapter 5 that discusses encrypted backups.

Another technique was able to reveal the keychain passwords without the use of purchased software. This attack requires possession of the phone as well as knowledge on jailbreaking the device. Once the device is jailbroken, an SSH server is installed on the device in order to allow software to run on the iPhone. Next, a keychain access script is copied to the device which is able to communicate with the keychain database and extract data, including passwords. This works because, with iOS 4, a key can be generated from within the device, without having to know the device passcode.

When the user selects the “Home” button to exit an application and go back to the main screen on the device, a screen shot is sometimes taken of the app prior to exiting, depending on the options selected by that particular application's developer. If enabled, these snapshots are stored on the device, and can later be recovered.

The images taken of the default apps can be found in /private/var/mobile/Library/Caches/Snapshots, and the filename will be something like com.apple.mobilemail-Default.jpg, com.apple.mobilenotes-Default.jpg, or com.apple.mobilesafari-Default.jpg. Since these screen shots are taken at random points throughout the use of an application, they will often contain useful data. For example, if a user selected the “Home” button after reading an e-mail, it is possible that a snapshot of the e-mail content would be taken and stored on the device. The same goes for third-party applications that have been downloaded by the user. If the developer enabled this option, snapshots for a downloaded application would be stored in that particular Application folder.

For the recovery of these snapshots, data carving techniques are typically required. While a few snapshots may be stored in the /Caches/Snapshots folder, the remaining images are unallocated. Most of these images, however, can be recovered by running Scalpel (or another file carving utility) on the disk image, and they will be stored in one of the “jpg” folders.

Often times, it is necessary to prove that a device belonged to a certain individual. While this can be a difficult task, using the pairing records is one way to achieve this. Whenever an iPhone is synced with a computer, a key is stored on both the phone and the workstation in order to allow the two devices to share data. If the certificate on the phone matches the certificate on the computer, then it can be concluded that those two devices were paired at one point.

This information on the iPhone is stored within a plist file, which is named after the desktop's unique identifier. There will be one file per device, and they can be found at /var/root/Library/Lockdown/pair_records/ (refer to Table 6.5 ). Below, you can see that this particular iPhone was paired with five unique devices (not necessarily all computers).

Several files are listed, and the examiner will need to look at the modification date and time to determine which device to look at. Once the plist is open, the information is displayed in XML format. The “DeviceCertificate” is the key we are looking for. As it is, this key is base64 encoded. Once decoded, the certificate can be found within a file on the workstation. To decode the base64 certificate, any websites and tools are available on the Internet. Go to one of these websites, copy and paste the certificate in the field, click decode (or whatever the program specifies), and the resulting output will be the certificate you need.

Next, the examiner must look at the certificate contained on the workstation. The location of these files will depend on the operating system running on this machine. Refer to Table 6.5 for locations in both Windows and Mac environments as well as on the iPhone itself ( Zdziarski, 2008 ).

In this example, a Mac workstation was used. So after navigating to the Lockdown directory, a series of plist files were found. In this case, the file names referred to the Unique Identifier of the device was synced to the computer, not necessarily all iPhones. The certificates in the plist files on the iPhone must be compared with the certificates in the plist files on the computer. Manually, this could be a time-consuming process. It is suggested that comparison tools be utilized, such as “diff.” This utility will compare two files, and the output will show only the differences between the two files. When using “diff” to compare the certificates, if there are two keys that do not result in any differences, it can be determined that those two devices were paired.