Chapter 5. Acquisitions
Information in this chapter:
• iPhone Forensics Overview
• Imaging an iPhone/iPad
• Imaging other Apple Devices
This chapter covers the various types of forensic acquisitions that can be performed on the iPhone, iPad, and other iOS devices. The importance of forensic imaging is discussed, followed by the different ways in which a device can be imaged. Two different methods of data retrieval through the iPhone's backup files are explained in detail, followed by a logical acquisition and, finally, a physical extraction of the device. The possibility of imaging other iOS devices, including the iPod Touch and Apple TV, is also outlined.
Keywords: Forensic acquisition, iPhone backup, logical acquisition, physical acquisition, Zdziarski method
Introduction
Before we dive into the actual iPhone forensic techniques, it is important to note that there are a number of considerations that influence the technique a forensic analyst should use. This section covers the different types of investigations as well as the various methods of data retrieval from an iOS device or its backup files.
iPhone forensics overview
Forensic imaging refers to the acquisition of disk or memory contents from a device into an external file that can be stored and examined using forensic tools. The purpose of creating a forensic image of a device is to have a duplicate copy for analysis so that the original evidence remains pristine. In the digital world, we have the capability of running the analysis against a working copy so as not to modify the contents of the original device.
The “holy grail” of any forensic acquisition is the performance of a bit-by-bit copy of the original media and retention of proof that the two are identical by comparing the unique cryptographic signatures of the original and the copy to ensure they match. While the processes and procedures for this are well established in traditional hard drive-based computer forensics, the process for mobile forensic devices has proven to be quite a challenge. Unlike hard drives, which can be removed, or computers, which can start in special read-only forensic environments, cell phones have a very limited operating system and cannot boot into a forensic environment, and the memory is typically nonremovable. Logical copies are usually the only method of performing mobile forensics outside of imaging removed memory cards or reading SIM (subscriber identity module) card data.
Types of investigations
There are a variety of situations that might benefit from the results of an iPhone forensic investigation. While the application of forensics is common to all the situations, each individual situation may require different procedures, documentation, and overall focus.
The first situation people generally think of is investigations that will likely be adjudicated in a criminal or civil court of law. In these situations, there are a number of important considerations:
• Chain of custody
• Detailed contemptuous notes and final reporting
• Possible validation of results using different tools or investigators
• Fact- or opinion-based testimony
Another common scenario involves internal investigations within corporations. These investigations may end up as litigations in court but often they are used to determine the root cause of an issue (whether it is a system, external attack, or internal employee) and may result in disciplinary action against an employee. Internal corporate investigations can cover many areas but the most common include the following:
• Intellectual property or data theft
• Inappropriate use of company resources
• Attempted or successful attack against computer systems
• Employment-related investigations including discrimination, sexual harassment, etc.
• Security audit, random or targeted
There is also a need for forensics in cases involving family matters. The most common cases involve the following:
• Divorce
• Child custody
• Estate disputes
One other area where forensic investigation can be of significant value is the security and operation of a government. A government is usually the largest employer in a country and the United States is a good example. According to U.S. Census Bureau data, data from the 2009 Annual Survey of Public Employment and Payroll revealed that the Federal government across all functions had over 3.0 million employees while state and local governments had 16.6 million full-time equivalent employees (Government Employment & Payroll, n.d.).
Beyond employment-related matters, countries are also potential targets of attacks and intelligence gathering by foreign agencies. Forensics can play a key role in thwarting attacks against a country, investigating successful attacks and counterintelligence scenarios, and providing valuable intelligence needed for the governing of the country.
Difference between logical and physical techniques
The forensic techniques used to recover data from an iPhone are either logical or physical in nature. A logical technique extracts allocated data and is typically achieved by accessing the file system. Allocated data simply means that the data is not deleted and is accessible on the file system.
Physical techniques, on the other hand, target the physical storage medium directly and these do not rely on the file system itself to access the data. There are advantages to this approach, the most significant being that physical techniques may provide access to deleted data. As discussed in Chapter 3 (File System and Data Storage), file systems often only mark data as deleted or obsolete and do not actually erase the storage medium unless needed. As the physical forensic techniques provide direct access to the storage medium, it is possible to recover not only the allocated data but also the unallocated (deleted or obsolete) data.
Of course, the analysis of an iPhone physical acquisition is generally far more difficult and time consuming. Also, the physical techniques are more difficult to execute and missteps could lead to the device becoming inaccessible.
Modification of the target device
One of the guiding principles of any forensic investigation is avoiding modification of the target device in any manner. In many cases, this is quite achievable. For example, let us assume you are handed a desktop computer that is not powered on. You are informed that it was seized from a suspect and you need to launch a forensic investigation. Because you can account for the computer only from the point that you take custody, the device is fairly easy to investigate without material changes to the data. A typical investigation would fully document the computer, remove the hard drive, connect it to a physical write blocker, and effect a bit-by-bit forensically sound acquisition of the hard drive. The investigation would then take place on copies of the forensic image and the original device would remain unchanged.
As the power and functionality of computers increased, this ideal situation became more and more difficult to achieve. First, let us assume you are called to the scene of an investigation and there is a desktop computer, but this time the computer is in operation. Any interaction with that computer, whether you simply move the device or even physically unplug the device, will modify it in some way. While many examiners advocate simply unplugging the computer, you certainly change the computer as the contents of RAM, open network connections, and more (all of which can be quite valuable in an investigation) are permanently lost.
On the other hand, if you decide to examine the device while it is running, any interaction might change the device. To further complicate an investigation, it is possible that the computer is leveraging encryption and, while the device is running, that data may be accessible. However, if the device is powered off and the examiner does not have the encryption key, he or she may permanently lose the ability to recover that data.
Servers that have their special hardware or complex setups, or simply cannot be powered down without significant impact to other systems or people are another complicating factor. In these cases, the examiner must interact directly with the device while it is running even though such actions will change the device.
Of course, mobile devices, and iOS devices in particular, are nearly impossible to forensically analyze without impacting the device. Unlike desktops, notebooks, and servers, the storage on an iOS device cannot be easily removed. And if the device is powered on, a shutdown of the device or pulling the battery again modifies the data.
When mobile phones were first showing up in investigations, there was very little stored data that could be extracted from the device. Many investigations used traditional approaches such as a search warrant on the wireless carrier to obtain call detail records. It was also possible to remove the SIM card on GSM (global system for mobile communication) devices and extract some data. As phones began to store more data, there developed a deep divide between examiners who advocated the older methods that had little impact on the device and subsequently retrieved only nominal data and those who advocated a fuller exploitation of the device. The techniques used to exploit the devices did modify the device and therefore the ensuing debate.
As of 2011, much of the debate has subsided as the amount of data mobile devices now hold necessitates the more intrusive techniques. The Association of Chief Police Officers in the United Kingdom produced guidelines that address this issue quite clearly. The guide, entitled “Good Practice Guide for Computer-Based Electronic Evidence” establishes four principles of computer-based electronic evidence (ACPO, n.d.):
1. No action taken by law enforcement agencies or their agents should change data held on a computer or storage media which may subsequently be relied upon in court.
2. In circumstances where a person finds it necessary to access original data held on a computer or on storage media, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions.
3. An audit trail or other record of all processes applied to computer-based electronic evidence should be created and preserved. An independent third party should be able to examine those processes and achieve the same result.
4. The person in charge of the investigation (the case officer) has overall responsibility for ensuring that the law and these principles are adhered to.
As mobile devices clearly present a circumstance in which it is necessary to access the original device directly, it is permissible provided the examiner is sufficiently trained, provides valid reasons for the approach, keeps a clear audit trail, and his or her actions are repeatable by a third party. This is certainly good advice and helps provide a solid framework for the forensic investigation of mobile devices.
Handling evidence
Many agencies and first responders have established protocols for securing evidence and the following sections are meant to complement those existing procedures, not replace them. Of course, these represent special procedures, and educating first responders who have many other responsibilities can be quite a challenge.
When an iPhone or other iOS device is seized, or received as evidence, a few precautionary measures should be taken to prevent data from being overwritten. These steps will depend on the current state of the device.
• If the device is powered off, leave it as is. Turning the phone on risks the possibility of data getting overwritten.
• If the device is powered on, be sure to note whether it is passcode-protected (see next section for more details) and what firmware version is running on the device.
• Always be sure to charge the device. However, if the device is powered off, it is important to note that connecting it to a charger will likely power it on. In this case, it is a good idea to wait until you are ready to boot the device into Recovery or Device Failsafe Utility (DFU) mode for an acquisition, and connect the charger at that time (see Chapter 2 for details on booting into various operating modes).
Passcode procedures
Passcode-locked devices are becoming more common as a result of heightened security awareness in consumers and corporations. Circumventing passcodes is not always possible. As such, the first consideration when securing a device is whether an opportunity exists to immediately disable or otherwise circumvent the passcode.
If an iPhone device is encountered and the screen is active, strong consideration should be given to checking and potentially changing its settings. For devices that have passcodes, there is a short period, from 1 minute to “Never,” where full access to the device is possible without re-entering the passcode. If a device is in an active state, an examiner may want to consider increasing the screen timeout to prevent or postpone the screen from locking. The location for this setting is in Settings > General > Auto-Lock. From here, be sure to select “Never” so that the device does not auto-lock and require a passcode to log back in.
Of course, these steps make changes to the device and should be thoroughly logged in the case notes with a description of the state of the device, the rationale for the attempted changes, and the outcome of each change. Not only will this assist in future report writing but will likely be an important factor if your decision to change the device is challenged in court.
Network isolation
If a device is found and the screen is still active, it would be ideal to go into the menu and disable the pattern lock and place the device into airplane mode if a Faraday box is not available.
If a device was left running, do not turn it off! Instead attempt to place it into airplane mode, remove the SIM card, turn off Wi-Fi, or get it into a Faraday box as soon as possible to avoid any kind of remote wipe initiation. In addition, depending on the device, evidence can be obtained from the live memory. If the device were shut down, this data would be permanently lost. Memory capturing techniques were covered previously, and while memory recovery on the iPhone is currently not possible, the research community has made major strides and this technique will likely be possible in the future.
Powered-off devices
If a device is powered off and comes to the lab for analysis, the first step in any investigation is noting the model and firmware version of the device. While the model number can be retrieved from the back casing, the examiner will need to boot the device into recovery mode, bypassing the normal boot sequence, to retrieve the running firmware version. This can be equated to performing forensics on a standard computer hard drive. The last thing any investigator would do on a recovered computer is boot it up to determine what operating system is installed. Instead, the hard drive is removed and connected to a write blocker for imaging so as to prevent the destruction of any evidence it might contain. If a phone does not have to be booted into normal mode, why take the chance of overwriting key evidence that could make or break the case? Specific information on how the firmware version can be retrieved is discussed later in this chapter in the “Physical Acquisition” section.
Imaging an iPhone/iPad
On the iPhone or iPad, there are three methods of acquiring data: backup acquisition, logical acquisition, and physical acquisition.
Backup acquisition
Through a backup acquisition, data that has been backed up from the device onto a computer is retrieved. This method is used when the original device is not available. Because the source of the data is the backup files, only data that are explicitly backed up using Apple's synchronization protocol are recovered.
There are various mobile forensic commercial tools in existence that will perform an acquisition of an iPhone/iPad/iPod Touch backup file. Some of those tools include Paraben Device Seizure, Oxygen Forensic Suite, Mobilyze by BlackBag Tech, Mobile Sync Browser, and iPhone Analyzer. Each of these tools has been tested, and the process is described in depth in Chapter 7. There are also several open-source programs available that allow the contents of a backup file to be extracted, viewed, and analyzed.
As a review from Chapter 2, when a device is backed up through iTunes, the files are stored in a default location depending on the operating system being used (refer to Appendix A for backup locations). The status.plist, info.plist, and manifest.plist are all configuration files containing information about the device, backup files, and status of the backup. The main files that we care about for an acquisition are the *.mddata and *.mdinfo files (or for earlier versions of iTunes, *.mdbackup). These are the binary files that actually contain user data. If the files are opened as they are, they would not be readable. Instead, one of the tools mentioned above is needed in order to convert them to a human-readable form.
Unencrypted
Performing a forensic recovery of the iPhone's backup files can be accomplished using one of the available mobile forensic or open-source tools discussed earlier. In this chapter, we will walk through the process of acquiring this data using two different methods. As Chapter 7 in its entirety is devoted to stepping through each of the different commercial tools, we utilize one of the open-source tools that are currently available. Note that this is just one example of the many free tools available on the Internet that can be used to acquire a backup of a device.
Regardless of the software or method used, the overall process of a backup acquisition remains similar. Each of the binary plists must be converted to XML in order for the content to be legible (for more details on understanding and converting property lists, see Chapter 3). As with any digital forensic examination, all work should be performed on the image of the device rather than the original evidence. In this case, an additional copy can be made of the iTunes backup files prior to analyzing. Once the files are converted, the raw files can then be read as they exist on an iPhone. The iPhone file structure is introduced in this chapter, and then expanded upon in Chapter 6.
Any tool used to analyze an iPhone backup must convert the binary plists into the standard file structure that we see on the iPhone. Many of the commercial tools go one step further and pull some of the data out of these files and incorporate them into a reporting tool. This is helpful for investigators who may not be familiar with the iPhone's data structure. Clicking a button in a user interface that says “SMS” is much easier than navigating through plists and SQLite databases to find the SMS messages (see Appendix B for suggested tools to use for viewing these file types).
We will now walk through the process of acquiring data via an iPhone backup file.
To mimic what a typical user could do, the iPhone Backup Extractor will be used for this acquisition. This is not a mobile forensics tool, but is a free download that allows an individual to simply view the contents of a backup file. It converts the binary plists into files that can be easily viewed on a Macintosh computer. It is important to note that there are alternative open-source tools that will perform a similar extraction, and run on other platforms as well.
Once the iPhone Backup Extractor is started up, the “Read Backups” option will automatically list every iPhone, iPad, or iPod device in which backup files are currently stored on the host machine. Multiple device backups are shown in Figure 5.1. It must be kept in mind that this software will only list the devices for which the backup files are located in the default location. If the backup was moved or copied to another area, it will not be displayed within the software.
From the list, select the appropriate device (in this example, we are going to select the “3GS-4.0” device). From here, you should see a list of all the applications that are on the device as well as “iOS Files,” as shown in Figure 5.2. If you are looking for data specific to an application, you can extract only the files for that particular app. However, the iOS Files extraction will provide you with the entire iPhone directory structure (with the exception of any downloaded applications).
In the example shown in Figure 5.2, we are going to select iOS Files and extract those to a selected area on the computer. Those files can now be viewed and are ready to be analyzed as displayed in Figure 5.3.
Encrypted
A user can also initiate an encrypted backup by entering a password prior to syncing the backup files. When a backup is encrypted, a standard forensic or open-source tool is not capable of acquiring data from the *.mddata and *.mdinfo files in most cases, unless a password cracking tool is used.
With the release of iOS version 4, encryption is done differently on the device. If a backup is not passcode-protected, the keychain file (containing user name and password data) is encrypted using hardware keys stored on the iPhone. If the keychain database file is opened, certain information can be viewed, but passwords are encrypted.
If a backup is password-protected, the keychain file is now encrypted using software keys generated from the backup password. What this means is that, as long as the backup passcode is known, it is possible to get the keychain file's encrypted data on a device running firmware version 4.x only.
iPhone Password Breaker exercise
To demonstrate this method, we will use Elcomsoft's iPhone Password Breaker. This software enables forensic access to password-protected backups for iPhone and iPad devices. It recovers the plain-text password that protects encrypted backup files. It can also read and decrypt keychains for devices running iOS version 4.
A device is not needed to use this software; only the encrypted backup files (specifically “Manifest.plist”) are used. When the software is run, the main screen is displayed as in Figure 5.4. When the user clicks “open,” a list of backed up devices is displayed. As we are looking for the encrypted backup file, we would select the device with a lock shown next to it (in Figure 5.5, this is the “3GS-4.0” device).
Next, we did a brute-force attack and selected only five characters and all numerics (see next section for specific testing done on the various brute-force attacks). The four-digit passcode was revealed in less than 1 second and displayed within the main screen of the software (see Figure 5.6).
Another feature of this software is its ability to display passwords or other data that is typically encrypted within the iPhone's keychain database. To view this information, select File > Keychain Explorer from the main menu; then select the encrypted backup once again. The contents of the keychain file are immediately displayed on the screen (Figure 5.7) and can even be exported into a text file:
==== GENERIC PASSWORDS ====
PortableStorage (SharingPassword)
Service:
PortableStorage
Account:
SharingPassword
Data:
d7csjAPtRmub
Access Group:
apple
AirPort (3Jane)
Service:
AirPort
Account:
iPhoneForensicsBook
Data:
apple765iphone
Access Group:
apple
Using Keychain Explorer, user names and passwords were recovered for wireless access points as well as the voice-mail passcode used on the device. Also recovered, but not displayed in the screenshot, were e-mail accounts and passwords as well as user names and passwords for any applications using Apple's keychain database as a back end.
Elcomsoft iPhone Password Breaker testing
iTunes began supporting encrypted backups ever since the release of version 8.1. The user has the option to enter a password to protect the backup file. For this test, multiple encrypted backup files were created with varying password lengths. There is currently no software available that will read an encrypted backup, so other methods were utilized in order to crack the encryption passcode. ElcomSoft's iPhone Password Breaker can recover the plain-text password by decrypting the Manifest.plist file discussed earlier. With the development of iOS 4, Apple has set hardware level encryption. Once a user creates a passcode on the device, he or she has the option to check the “Data protection is enabled” option as mentioned earlier in Chapter 2.
The iPhone Password Breaker supports all models and iOS versions, so the enhanced encryption feature is not an issue in cracking the backup passcode. Table 5.1 outlines the various tests run on the backup file using this software, given the following hardware specifications of the system:
• Windows 7 (64-bit)
• Catalyst 10.3 Drive
• Sapphire graphics card
Each password in the “Numbers only” row started with a “1.” This is important because the brute-force attack used within this software systematically checks all possible characters until the correct one is found, starting with the earliest. For example, with a four-digit, all numeric PIN, the attack will start with the number 1, then gradually go up to 9 until the correct number is found. The “expected time remaining” that is shown in the software is assumed to be the longest amount of time expected. For example, using the combination of “all numbers” and a character length of eight, the software reported an expected remaining time of 20 minutes. However, the time was significantly decreased to 5½ minutes, most likely because the password started with a 1.
In the “Alphanumeric” row, with the number of characters being four and five, the software was able to successfully crack the password in a small amount of time. The remaining columns will show an estimated time, as we did not allow the software to run for that long.
In testing, it was noticed that the possibility of an individual instinctively using the iPhone's four-digit PIN code as their backup encryption password is likely. Some individuals might think they need to enter their iPhone PIN instead of creating a brand new password. As you can see in the chart, a numeric, four-digit passcode can be cracked in a very small amount of time.
Logical acquisition
Logical imaging refers to copying the active file system from the device into another file. Through this method, allocated data from the actual device is recovered and can later be analyzed. Logical techniques are often the first type of examination forensic analysts will run because they are easier to execute and often provide sufficient data for the case. iPhone forensics physical techniques can provide far more data; however, they are more difficult to execute successfully and also take considerably more effort to analyze.
Many of the mobile forensics tools that support iPhone logical acquisitions will also provide a reporting mechanism. Essentially, the tool will execute a logical acquisition of the device, and with this information, it will export commonly viewed files into a graphical user interface (GUI) or report. The problem with some of these tools is that the examiner can see the reported data, but cannot view the source of that data. For example, a report might show a website being visited, but not display the date and time. In such a case, the examiner would need to see the original source of the data in order to see other metadata associated with the file. For reasons such as this, it is helpful if an acquisition tool not only reports the data that was found but also allows the investigator to view the raw files from which it was derived.
The overall steps involved in a logical image of an iPhone, regardless of the software or tool being used, include the following:
1. Run the forensic software of your choice.
2. Connect the device.
3. Begin acquiring an image: this will pull all data from the device that was explicitly backed up using Apple's synchronization protocol. Similar files will be retrieved as from an acquisition of a backup, except that with this method, they are being pulled directly from the device.
4. Depending on the software being used, some or all of this information will be displayed within the software and can later be exported into a report.
In Chapter 7, the reader is guided through a logical acquisition for each of the commercial tools listed. The process begins with installation; then it steps the examiner through the acquisition, reporting, and analysis. As with any forensic tool or technique, it is important for examiners to not only go by the testing and tool validation performed by others but also verify the accuracy of the tool themselves.
Physical acquisition
Physical imaging has been widely used in forensics for many years but is relatively new to the mobile device world. Unfortunately for forensic analysts, iPhone security mechanisms prevent us from being able to extract a physical image from a stock device without first gaining privileged access. However, there are some methods that can be utilized to gain access to the device memory to grab a complete image of the NAND.
A physical acquisition creates a physical bit-by-bit copy of the file system, similar to the way a hard drive would be forensically imaged. For this reason, it has the greatest potential to recover large amounts of data, including deleted files.
The release of iOS 4 brought up many issues from a mobile forensics standpoint. As briefly highlighted in Chapter 2, hardware encryption is offered with iOS 4 on the iPhone 4, 3GS, iPod Touch (3G or later), and all iPad models. What this means is that, even if a full physical disk image is possible, all the data is still encrypted. At the time of writing this book, no solution exists for acquiring an image of a device running iOS 4, or at least a full disk image containing unallocated data.
There are currently three methods available to perform a physical acquisition on an iPhone or iPad: the Zdziarski method, FTS's iXAM software, or through a jailbroken device. With these techniques, a physical acquisition of an iPhone is possible and has been proven to work so long as the firmware version is below 4.x. The first two methods have also been tested by the National Institute of Standards and Technology, and a link to their tool testing site is http://www.cftt.nist.gov/mobile_devices.htm (NIST, 2010).
Preparation
Before jumping into the actual acquisition, there are a few topics that need to be covered to prepare the examiner for the acquisition process, regardless of the tool used.
Locate model and firmware version
One of the first steps for any iPhone acquisition is to locate both the model of the device as well as the running iOS version. This is an important step because many of the commercially available tools only support certain firmware versions. In addition, when using Zdziarski's method, a different set of automated tools is used for each unique model and firmware version combination. For these reasons, it is important to understand what is running on the device.
The model number is easy, as it is displayed on the back of the device. The firmware version can be complex, especially if the device is passcode-protected. If the examiner can access the device (in other words, it is powered on and unlocked), the firmware version can be found under Settings > General > About > Version. In the event that the phone is turned off or it cannot be accessed because it is locked with a passcode, an alternative method must be performed.
iRecovery, which was mentioned earlier in Chapter 2, can be run on the device in order to locate the firmware version. To do this, the device should be placed in Recovery mode (see Chapter 2) and connected to a forensic workstation. Using a terminal window, the examiner will need to change into the directory in which iRecovery was installed. In the example that will follow, iRecovery was located in the Applications directory on a Mac. Next, the iRecovery command was used to identify the iBoot version running on the device. The “-s” flag following the command spawns a shell, displaying general information.
Katie-Strzempkas-Macbook:~ kstrzemp$ cd Applications/
Katie-Strzempkas-Macbook:iRecovery kstrzemp$ ./irecovery -s
iRecovery - Recovery Utility
by westbaer
Thanks to pod2g, tom3q, planetbeing and geohot.
=======================================
:: iBoot for n82ap, Copyright 2009, Apple Inc.
:: BUILD_TAG: iBoot-636.66.33
:: BUILD_STYLE: RELEASE
:: USB_SERIAL_NUMBER: CPID:8900 CPRV:30 CPFM:03 SCEP:05 BDID:04 ECID:000003031C18438D IBFL:01 SRNM:[88832BDP1R4]
=======================================
[FTL:MSG] Apple NAND Driver (AND) RO
[NAND] Device ID 0xb655d7ec
[NAND] BANKS_TOTAL 4
[NAND] BLOCKS_PER_BANK 8192
[NAND] PAGES_PER_BANK 104876
[NAND] SECTORS_PER_PAGE 8
[NAND] BYTES_PER_SPARE 128
[FTL:MSG] FIL_Init [OK]
[FTL:MSG] BUF_Init [OK]
[FTL:MSG] FPart Init [OK] read old style signature 0x43303035 (line:371)
[FTL:MSG] VFL Register [OK]
[FTL:MSG] VFL Init [OK]
[FTL:MSG] VFL_Open [OK]
[FTL:MSG] FTL Register [OK]
[FTL:WRN] Failure running _LoadFTLCxt!
[FTL:WRN] Recovering NAND Data Structures - this will take some time!
[FTL:WRN] _FTLRestore OK!
[FL:MSG] FTL_Open [OK]
Boot Failure Count: 1 Panic Fail Count: 0
Entering recovery mode, starting command prompt
From the output of iRecovery, the “BUILD_TAG” version can be accessed. In this example, it was iBoot-636.66.33. This is Apple's stage 2 bootloader and, if you recall from Chapter 2, it is this that runs Recovery mode on Apple devices. The iBoot version can be translated to its appropriate firmware version by searching various websites. The iPhone Wiki typically does a decent job of providing the iBoot revisions and their corresponding firmware version. As the links continually change, a direct link is not provided here; however, going to http://theiphonewiki.com and searching for “bootloader” or “iBoot versions” will typically provide the necessary results. In this example, iBoot-636.66.33 is known to run iOS version 3.1.3.
If a device is not found, the iRecovery output will display that information accordingly and report “No iPhone/iPod found.”
Install appropriate iTunes version
Most, if not all, forensic acquisition tools rely on iTunes. Therefore, once the firmware version of the device is known, a version of iTunes that supports that iOS version must be installed. If iTunes version 8.2 is installed, and the particular iOS version required is 9.1 or higher, the computer will not recognize that an Apple device is connected and the acquisition will fail.
The question you might be asking yourself is, “Okay, so which iTunes version do I need for each iPhone or iPad firmware version available?” As with many aspects of mobile forensics, the answer is not always a direct one. However, Table 5.2 provides guidelines that suggest the iTunes version that may be required for the particular device that an examiner might wish to acquire. These suggestions are based on the iTunes versions required by each of Zdziarski's Automated Tools. For a few of Zdziarski's Automated tools, multiple iTunes versions are required; however, if using another commercial tool, it is suggested that the version listed first be installed. If the acquisition process is unsuccessful even after the suggested iTunes version has been installed, it might be worthwhile to either upgrade or downgrade to another version as the computer is evidently not recognizing the connected Apple device. Most of the commercial tools will display an iTunes error, and technical support can help an examiner determine which iTunes version is required.
Once the iTunes version is determined, it needs to be installed. If you need to upgrade to a higher version, a standard install will be sufficient. This will automatically replace the older version with the newer install. If a lower version of iTunes is required than the version currently installed, iTunes will first need to be uninstalled, including the removal of the iTunes helper files. To ensure that all iTunes artifacts are uninstalled from the machine, the following commands can be run in a terminal window:
$ sudo rm -rf /Applications/iTunes.app
$ /System/Library/PrivateFrameworks/DeviceLink.framework
$ /System/Library/Extensions/AppleMobileDevice.kext
$ /System/Library/PrivateFrameworks/iTunesAccess.framework
$ /System/Library/PrivateFrameworks/CoreFP.framework
$ /System/Library/PrivateFrameworks/MobileDevice.framework
Once the above commands are run, try to open iTunes in order to make sure that the software was successfully removed (a “?” should appear over the iTunes icon on a Macintosh computer, as there is no longer a linked reference to the software). Next, install the iTunes version that you wish to have running by following the installation wizard. When the installation is complete, the forensic workstation will have to be restarted in order to complete the downgrade. If the machine is not restarted, the acquisition will likely not work.
Acquisition – Zdziarski technique
This method was developed by Jonathan Zdziarski, a former Research Scientist for McAfee, Inc., who has contributed significantly to research into the iPhone and iPod Touch. Using his method, an examiner can acquire a bit-by-bit copy of the user data partition. This process requires modifying a read-only system partition, which is completely separate from where the user data is contained.
The Zdziarski method is run by downloading “Automated Tools” from his website and is strictly command-line driven. The process involves installing a recovery agent within the system partition of the device. Once the live recovery agent becomes active upon reboot, the user initiates a recovery script which creates a copy of the raw disk image on the device and pulls it onto the forensic workstation over a USB connection. The most recently released Automated Tools support all firmware versions for the 2G, 3G, 3G(s), and iPhone 4 up to and including 4.1 as well as all iPad versions. For any device running iOS 4.0 or higher, Zdziarski's method will recover only the logical file system, not a full physical image. Even a logical acquisition of iOS 4.x is a daunting task, as the tools are still being enhanced to work with the encrypted OS.
Once the forensic workstation has been set up with the proper iTunes version and the device model and firmware version is known, the imaging process can begin. In this example, we will refer to an iPhone 3G, running iOS version 3.1.3. It is important to note that around October of 2010, Zdziarski released an update of his tools in which some of the steps are slightly modified. As we step through the acquisition, the differences can be noted by the references to the “Old” Automated Tools in comparison to the “New” Automated Tools.
The general overall process consists of the following steps.
Connect the device
The first step is to connect the iPhone to the computer via a USB cable. If iTunes is automatically launched when the device is connected, be sure to exit the software before proceeding to the next step. Prior to running the script, the iPhone will need to be put in either Recovery or DFU mode, depending on the firmware version. Most versions will require the device to be in DFU mode, but specific instructions provided with the tool will specify this information, as does the output after running each script.
Some of the more recently developed Automated Tools require the use of Linux. The tools for these specific devices are developed to be used only on a Linux workstation (or virtual machine, VM) and do not require the use of iTunes.
Set up the Automated Tools
Prior to running the first scripts, a setup process that downloads the files needed must be completed in order to complete the acquisition process successfully. To ensure you are using the most up-to-date files, it is a good idea to run the setup process prior to each acquisition.
When the setup is complete, a message will indicate that the first script can now be run. The examiner will also be informed about the next step as well as the operating mode the device needs to be in.
Imaging process
The first of three scripts that are required for the imaging process installs a recovery agent onto the device. On most occasions, the phone will need to be in DFU mode for this step; however, there are exceptions for certain models (i.e., the iPhone 3GS running firmware version 3.1.3 as well as the iPad running 3.2.2). These two devices need to be in Recovery mode for the first step. Refer to Chapter 2 for details on how to boot a device into DFU or Recovery mode.
Shortly after running the script, the user will be prompted on-screen to disconnect and reconnect the device from the USB. The examiner will then see additional packets being sent over the USB connection, and when complete, the next step can be completed.
After the device is rebooted, the second script in this process can be run. When executed, the live recovery agent that was installed with the previous command will now become active. Once again, the examiner will need to place the device in the specified operating mode, disconnect and reconnect the device from USB, and follow the on-screen instructions. Once the script has been executed, it should inform the examiner whether the operation was successfully completed, and then the iRecovery tool is initiated to restart the device. Upon restart, the agent should be active.
Now that the recovery agent has been installed and activated, and the iPhone or iPad has been rebooted into normal mode, it is time to initiate the actual recovery. Prior to October 2010, Zdziarski's Automated Tools contained the setup script within each individual folder (as mentioned in the first step). With the updates released in the third quarter of 2010, some restructuring was done, preventing the module from requiring a setup process. As part of these updates, “usbmux-proxy,” which is proprietary for iTunes, is replaced with the open-source version, “usbmuxd.” Usbmuxd stands for “USB multiplexing daemon” and it is what allows for communication to the device over USB (Martin, 2011). By replacing usbmux-proxy with the open-source version, Zdziarski is preventing the need for iTunes to be installed in order to successfully run an acquisition. The intention of providing this replacement was so that iTunes versioning would no longer be an issue in imaging an iPhone or iPad device. Because these updated tools are still in their infancy, at times iTunes is still needed for some modules; however, certain devices (such as the iPad running iOS 3.2.2) have been acquired successfully on a Linux machine with no installation of iTunes.
To begin the final acquisition process, the provided recovery script must be used to initiate a physical acquisition of the raw disk image on the device. An image file is created on the forensic workstation, which will continue to slowly grow in size if the process is successful. If the file remains as 0 bytes, it is possible that either the live recovery agent was not installed correctly or not activated properly. Troubleshooting steps would include checking the iTunes version to ensure the workstation was even recognizing that a device was connected. Next, the three scripts are walked through again (after rebooting the device), keeping an eye on the output from the script to ensure that there are no errors during the installation or activation process.
Assuming the device is imaging as expected, do not interrupt the process until it is complete. You will know that the acquisition is finished when the “Cannot connect to usbmux” message appears within the terminal window.
Post-acquisition steps
Once the acquisition is complete, several commands will need to be executed from a separate terminal window in order to properly stop the running processes, as specified in Zdziarski's instructions within the Automated Tools.
Next, the image should be renamed to a case name, number, or other unique identifier. If the image is mounted on a Mac, the extension will also need to be changed to “.dmg”. If prompted when the extension is changed, just click “Use dmg,” as shown in Figure 5.8.
After modifying the file name, no other changes need to be made to the image file; therefore, it can be marked as read-only. On a Mac, right-click on the file and select “Get Info” (or on the keyboard, hold down “command+i”). This will bring up the properties of the file, and from here the “Locked” check box should be selected, as displayed in Figure 5.9.
Once the image file is locked, it is suggested that the examiner calculate a hash value for the image and document this information in a report. This process can be done through a Terminal window using the following command:
# If on a Mac:
$ md5 iPhone.dmg
$ shasum iPhone.dmg
# If using Linux, a hash tool can be installed such as md5sum, sha256 sum, etc.
$ sha256sum iPhone.dmg
$ md5sum iPhone.dmg
For either of these commands, the output will be displayed within the Terminal window. If an examiner wishes to copy the hash value directly to a text file, the following can be run to redirect the output:
$ md5sum iPhone.dmg > ~/Desktop/md5-hash-value.txt
The image is now ready to be mounted and analyzed.
Acquisition – iXAM
iXAM was created by Forensic Telecommunications Services Ltd. (FTS). Primarily a forensic technology lab, FTS developed iXAM through independent research and development. iXAM is entirely software-based, requiring the use of only a USB dongle. It runs on Windows only, but will also work in a VM environment that can be run on Linux or Mac. iXAM is installed by running a setup file, provided by FTS on an external USB drive (further installation instructions can be found in Chapter 7). Software updates are retrieved through a secure FTP connection.
The way iXAM works is it executes a custom bootloader on the device. Unsigned code is sent over a USB connection to a device running in DFU mode. Once on the device, the code is executed within RAM and does not touch the user data partition. During the imaging process, iXAM prevents the device from connecting to any external networks. Imaging is done one block at a time, and each block is checked for errors and a hash value is created. Once the imaging process is complete, the bootloader powers off the device. Upon reboot, the program is removed from RAM, which is why iXAM is said to have “Zero-Footprint.”
As of version 2, iXAM is known to support all iPhone models including 2G, 3G, 3G(s), and iPhone 4, and all firmware versions up to and including 4.1; however, as with Zdziarski's method, a full physical image is still not supported for iOS 4 devices because of the hardware encryption. The updated version is also anticipated to add greater functionality and drastically improve acquisition times.
The iXAM software arrives on a USB drive, and is installed through an executable file, which then steps the user through the process of downloading prerequisites, purging existing Apple Device drivers, and finally the provisioning and installation process.
The following sections outline the general steps taken to perform a physical acquisition of an iPhone using iXAM software. More details on the installation, acquisition, and reporting process can be found in Chapter 7.
Connect the device
First, the iPhone should be connected to the forensic workstation using a USB cable. In the testing done in Chapter 7, a VM was used that required extra steps to ensure that the iPhone was being seen by the VM rather than the host machine. Once the device is connected and the acquisition process initiated, the examiner is prompted to place the device in DFU mode with the help of a timer in the upper right-hand corner of the software. Next, the wizard walks the examiner through the installation of device drivers.
Imaging process
Moving forward in the process, the next step instructs the user that the Stage 1 bootloader is being sent to the device. The new hardware must first be verified, and then the process repeated for Stage 2 and Stage 3 bootloaders. These preparation steps lead to the start of the actual physical acquisition of the device.
The user is prompted to select the iPhone model that he or she wishes to acquire; then, after selecting the “Forensic Image” option (as opposed to a logical download), the imaging process begins.
Post-acquisition steps
Once the imaging is complete, the examiner is left with a dmg file, which can be mounted and analyzed. Similar to the steps taken for Zdziarski's method, this file should first be marked as read-only and a hash value calculated prior to any type of examination.
Acquisition – Jailbroken device
The reason why Zdziarski and iXAM are able to get a full physical image on an iPhone is that they have developed the means to gain root access on the device, which is difficult to accomplish without modifying the user data partition. Once this is achieved, a simple “dd” function can be performed in order to image the device just as a computer hard drive or other device would be forensically imaged. While the previous two methods do not jailbreak an iOS device in order to perform an acquisition, a physical image can also be taken of a device which has already been jailbroken by the user.
First of all, it is important to note that acquiring a jailbroken device does modify the user partition, and this method should be used only as a last resort and with the understanding that potential evidence could be overwritten. To physically acquire a jailbroken device, several steps must be taken. The high-level steps are outlined here, and expanded upon in the following sections:
• Create a wireless network
• Remotely connect to iPhone
• Image device
Create a wireless network
Prior to accessing the device in any way, a wireless network must be created (or an existing network used) in order to allow the forensic workstation to remotely connect to the device. For this procedure, a Mac OS X system will be used. While an existing network can also be used, let us go through the steps of creating a separate network for this scenario.
On a Mac, a new wireless network can be created through the system's Network Preferences. For this example, the network was named “iPhone-Book” as shown in Figure 5.10.
Next, a static IP address must be set for both the Mac and the iPhone. To set on a Mac, run the following command in a terminal window:
$ sudo ifconfig en1 inet 192.168.0.1 netmask 255.255.255.0
When running a command beginning with “sudo,” the examiner will be prompted to enter the administrator password.
To set the static IP address on the iPhone, navigate to Settings > Wi-Fi, then connect to the newly created network (iPhone-book). Once connected, the user will need to select the right arrow for that network, then “Static” and enter 192.168.0.2 with a netmask of 255.255.255.0 (see Figure 5.11). Once complete, the user selects “Wi-Fi Networks” in the upper left-hand corner to save these settings.
Now that both the Mac and the iPhone are on the same subnet, the two devices should be able to communicate with each other and are ready for the next step.
Remotely connect to iPhone
The examiner can now connect remotely to the device over SSH. On most jailbroken phones, the user name is “root” and the password is “alpine” by default; however, some research will need to be done on the examiner's part to ensure that this is true for the jailbroken device he or she is working with.
Run the following command on the Mac in order to connect to the iPhone:
If this is not successful, it is most likely because SSH is not installed on the device. As part of the jailbreaking process, most users will take the time to install the source packages suggested by the jailbreaking site that instructed them on how to gain root access on the device. However, some users may not complete this step. If SSH is not installed, the examiner will need to do some research on how to manage the Cydia sources on the device (or whatever was used to jailbreak the device, if not Cydia) and install “OpenSSH.”
Once connected to the device, let us make sure that we have the necessary files before beginning the imaging process. To do this, we need to make sure both “dd” and “netcat” are installed on the device by running the following commands from the iPhone:
3GS-40:~ root# which dd
3GS-40:~ root# which nc
3GS-40:~ root#
Typically, if the “which” command is run and the software is installed, the output will display the path to the source file. Since there was no path shown, we can assume that dd and netcat are not yet on the device. We can copy these tools to the iPhone from the Mac. First, we will need to find where these tools are stored on the Mac, and then run the “scp” command to copy the files.
Katie-Strzempkas-Macbook:~ kstrzemp$ which nc
/usr/bin/nc
Katie-Strzempkas-Macbook:~ kstrzemp$ which dd
/bin/dd
Katie-Strzempkas-Macbook:~ kstrzemp$ /usr/bin/scp /usr/bin/nc [email protected]:/bin/nc
Katie-Strzempkas-Macbook:~ kstrzemp$ /usr/bin/scp /bin/dd [email protected]:/bin/dd
Those last two commands used “scp” (or “Secure Copy”) to transfer the nc and dd tools from the forensic workstation to the iPhone, and stored these tools in the /bin folder on the root of the device. Now, let us SSH back into the iPhone to make sure these files are where they should be:
3GS-40:~ root# which dd
/bin/dd
3GS-40:~ root# which nc
/bin/nc
3GS-40:~ root#
Now that all of the necessary tools are installed, the imaging process can begin.
Image device
Using this technique, imaging is done over a program called netcat. Netcat creates a tunnel that allows two devices to communicate and transfer files back and forth over a specified port. One end of the tunnel must be set up on the forensic workstation and the other end configured on the iPhone. This process, as well as imaging the raw disk, is all done within two commands (one on the Mac and one on the iPhone).
The first step is to run netcat on the Mac using the following command:
Katie-Strzempkas-Macbook:~ kstrzemp$ nc -l 7000 | dd of=~/Desktop/rdisk0s2.dmg bs=1048576
This command tells netcat to “listen” on port 7000 and to create the output file “rdisk0s2.dmg” on the desktop, based on the input from the other end of the tunnel (which is yet to be initiated). Upon hitting enter, it will appear as though nothing is happening; however, the Mac is waiting for the other end of the connection.
Next, let us take a look at the raw disk files on the iPhone to determine which one to create an image of:
3GS-40:~ root# cd /dev
3GS-40:/dev root# ls -l rdisk*
crw-r----- 1 root operator 14, 0 Feb 9 10:53 rdisk0
crw-r----- 1 root operator 14, 1 Feb 9 10:54 rdisk0s1
crw-r----- 1 root operator 14, 2 Feb 9 10:53 rdisk0s2
crw-r----- 1 root operator 14, 3 Feb 9 10:54 rdisk0s2s1
These files were discussed in the “iPhone Disk Partitions” section of Chapter 3. As a recap, rdisk0 is the entire raw disk (including all partitions). Rdisk0s1 is the firmware partition, and rdisk0s2 is the user data partition (rdisk0s2s1 is unique to the 3GS device). So, when the dd command is initiated, we will want to acquire rdisk0s2 to get a full image of the user data partition.
To begin the acquisition, the following command should be run from the iPhone, which has been connected to over SSH:
3GS-40:~ root# /bin/dd if=/dev/rdisk0s2 bs=1M | /bin/nc 192.168.0.1 7000
Let us break down this command to gain a better understanding:
•
/bin/dd: This runs the dd command, which is stored in the /bin directory.
•
if=/dev/rdisk0s2: This specifies the “input file” as rdisk0s2, the raw disk for the user data partition (slice 2).
•
bs=1M: Sets a “byte size” of 1 MB.
•
/bin/nc 192.168.0.1 7000: This runs the netcat command, instructing the device to connect to 192.168.0.1 (the Mac) over port 7000 (the port the Mac is listening on).
To summarize, we initiated the dd command to image the “rdisk0s2” file, took that output, and sent it through a netcat tunnel, which is connected to our forensic workstation. As soon as this command is run, we should see the “rdisk0s2.dmg” file created on the desktop of the Mac and it should be increasing in size (see Figure 5.12).
Post-acquisition steps
Once the imaging process is complete (it will likely take several hours to acquire depending on the size of the device), the image file can be marked as read-only, mounted, hash value calculated, and analyzed.
Imaging other apple devices
It is also possible to image other Apple iOS devices such as the iPod Touch and Apple TV. Other devices, specifically the iPod, run either HFS+ or FAT32 depending on the operating system on which the device was initialized.
iPad
While the examples provided in this chapter did not specifically show a backup, logical, or physical acquisition of an iPad, the very same techniques used on the iPhone can be applied to this device.
When an iPad is connected to iTunes, a user can initiate a backup which is stored in the same location as that of an iPhone backup file. Again, this backup can be analyzed using the commercial tools highlighted in Chapter 7, or even the open source tools available on the Internet. The same applies for a logical acquisition.
As for a physical extraction, Zdziarski also provides specific modules for the iPad, and the same process and scripts are run. iXAM does not list the iPad as a supported device; however, according to the website, this device will be added in the near future.
Finally, a jailbroken iPad can be acquired using the same steps outlined earlier in this chapter for the iPhone.
iPod Touch
The iPod Touch is a portable media player and personal digital assistant, which allows the capability to connect to Wi-Fi, store and take photos and videos, and download apps for the App Store (among other features). While it does not have network access to allow for phone calls and text messages, acquiring data from this device could be extremely beneficial in the course of an investigation.
The iPod Touch runs iOS and can therefore be acquired by many of the tools that support the iPhone. While this particular device was not tested on the tools within Chapter 7, most list the iPod Touch as a supported device.
Apple TV
The first-generation Apple TV ran a modified version of OS X. The second generation, however, runs a version of iOS that is almost identical to the fourth-generation iPod Touch. Technically, Apple TV (2G) does not run a standard iOS; however, the operating system is very similar to that of the iPod Touch, iPhone, and iPad (“What Operating System…”, 2010).
The original Apple TV is essentially a hard drive running Mac OS X, and thus the drive can be removed and imaged the way a typical hard drive would. Many details on this version of the Apple TV, including how it works and where forensic data can be discovered, can be found by searching the Internet for “hacking the Apple TV and where your forensic data lives.” This set of information was presented at Defcon in July 2009 (Estis & Robbins, 2009). The second-generation Apple TV is a bit different. It lacks the hard drive storage; however, 8 GB of NAND Flash storage is available for caching.
Summary
The first step in any mobile forensic examination is to image or acquire data from the device. With so many different models and operating system versions, the process for one device may not be the same as that for another. In addition, some of the commercial tools do not yet support the latest firmware versions, leading the investigator to turn to other methods of data acquisition, such as from an iTunes backup file.
This chapter covered the various types of forensic acquisitions that can be performed on the iPhone, iPad, and other iOS devices. The importance of forensic imaging was discussed, followed by the different ways in which a device can be imaged. Two different methods of data retrieval through the iPhone's backup files were stepped through in detail, followed by a logical acquisition and, finally, a physical extraction of the device. The methods of imaging other iOS devices, including the iPod Touch and Apple TV, were also outlined.
References
ACPO Good Practice Guide for Computer-Based Electronic Evidence – 7Safe Information Security,
7Safe Information Security,
Retrieved February 19, 2011, fromhttp://7safe.com/electronic_evidence/index.html#;
(n.d.)..
Estis, K.; Robbins, R.,
Hacking the Apple TV and where your forensic data lives,
In:
Def Con Hacking Conference. (
2009, July 30);
Retrieved February 23, 2011, fromwww.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-kevin_estis-apple_tv.pdf.
Government Employment & Payroll,
Census Bureau home page,
Retrieved February 19, 2011, fromhttp://www.census.gov/govs/apes/;
(n.d.)..
Martin, H.,
Abort, retry, hack? » usbmuxd. Abort, retry, hack?Retrieved January 10, 2011, fromhttp://marcansoft.com/blog/iphonelinux;
(n.d.)..
National Institute of Standards and Technology,
Mobile devices. NIST Computer Forensic Tool Testing Program,
Retrieved January 10, 2011, fromhttp://www.cftt.nist.gov/mobile_devices.htm (
2010, November).
What operating system do the Apple TV models use? Can Apple TV run Mac OS X software? Can it run iOS applications? Can Apple TV run Windows? Can it play iPod games? @ EveryMac.com,
Mac specs, prices, answers, & comparison @ EveryMac.com – Est. 1996,
Retrieved January 10, 2011, fromhttp://www.everymac.com/systems/apple/apple-tv/apple-tv-faq/apple-tv-operating-system-mac-os-x-applications-running-windows-ipod-games.html (
2010, October 8).
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.