Apple devices are popular all over the world due to the user experience they provide, their magnificent design, and their revolutionary features, so it shouldn't come as a surprise that in 2016, Apple announced that over one billion iPhones had been sold. Over the past 5 years, mobile device usage has grown particularly fast, with data from 2021 indicating that there were one billion active iOS devices.

The information that's stored on a smartphone can help address crucial questions in an investigation, revealing whom an individual has been in contact with, where they have been, and what they've been doing with the device. As new features are added to the device and more apps are made available through the App Store, the amount of information that's stored on iOS devices is continuously growing.

Mobile forensics can be defined as the process of recovering digital evidence from a mobile device under forensically sound conditions using validated means.

The kind of evidence we can recover from a device depends on the device itself and what techniques are used for data extraction, but generally, smartphones contain personal information such as call history, messages, emails, photos, videos, memos, passwords, location data, and sensor data. No other computing device is as personal as a mobile phone.

Typically, the examination process should reveal all digital evidence, including artifacts that may have been hidden, obscured, or deleted. Evidence is gained by applying established scientifically based methods and should describe the content and state of the data fully, including where it is located, the potential significance, and how different data sources relate to each other. The forensic process begins by extracting a copy of the evidence from the mobile device. Once a copy is available, the next step involves analyzing the data, identifying evidence, and developing the contents of a final report.

The new golden age for iOS forensics

Over the past 3 years, the digital forensics industry has undergone a major revolution.

In 2019, the discovery of the checkm8 exploit for iOS devices was a complete game-changer as it opened new doors for digital forensics investigators, allowing full filesystem extractions of hundreds of millions of Apple devices. If you've never seen a full filesystem extraction before, you'll probably be surprised by the extent and variety of data that the device stores!

Checkm8 is based on an un-patchable hardware flaw that lives directly on the chips of iOS devices, ranging from devices running Apple's A11 chip down to the A5 generation. This includes devices from the iPhone 4S to iPhone X and several iPads.

This vulnerability is specifically a BootROM exploit, which means it takes advantage of a security flaw in the initial code that iOS devices load during the boot process, and it can't be overwritten or patched by Apple through a software update.

At the end of 2019, checkra1n was released, the first public, closed source jailbreak based on the checkm8 exploit. Digital investigators and forensics analysts have quickly adopted checkra1n to get access to the device's filesystem and keychain; however, as with all jailbreaks, this solution has several drawbacks as using a jailbreak inevitably modifies some data on the device's filesystem and is not considered forensically sound.

For these reasons, vendors such as Cellebrite, Elcomsoft, and Oxygen Forensic have developed proprietary solutions based on the original checkm8 exploit that work by patching the device's RAM. These tools allow investigators to perform full filesystem extractions without touching system and user partitions and without making any changes to the device as the exploit runs in memory.

In other words, on selected devices, the checkm8 vulnerability can be exploited to extract the full filesystem without actually jailbreaking the device. The following table shows the list of devices that are vulnerable to the checkm8 exploit:

Table 1.1 – Devices that are vulnerable to the checkm8 exploit

To exploit checkm8 for a filesystem extraction, your device must be compatible, and it must be running a supported iOS version. This is a major drawback as newer devices, such as the latest iPhone 13, are not supported. There are, however, other options.

In 2020, vendors such as Elcomsoft and Belkasoft introduced agent-based extraction, a new acquisition method that allows full filesystem extractions without jailbreaking the device. Once installed on the device, the agent escapes the sandbox through software exploits, gaining unrestricted access to the device and establishing a connection between the device and the computer. Agent-based extraction is forensically safe, and it is usually a lot faster and safer than most jailbreaks. At the time of writing, supported devices include all iPhones from the 5s up to the iPhone 12, running iOS versions 9.0 to 14.3.

In May 2020, a major update for the unc0ver jailbreak was released, adding support for devices based on A12-A13 chips. At the time of writing, unc0ver supports jailbreaking all devices from the iPhone 5s up to the iPhone 12. Supported iOS versions range from iOS 11 to iOS 14.3.

Although jailbreaking a device allows full filesystem extraction, it's not considered a forensically sound process. An investigator should consider safer options such as checkm8 or agent-based extractions first if they're supported.

Tip

It's important to note the difference between checkm8-based extractions and jailbreaking the device through checkra1n or unc0ver. Tools such as Cellebrite UFED and Elcomsoft iOS Forensics Toolkit leverage the checkm8 exploit to temporarily provide access to the entire filesystem by running the exploit in the device's RAM. When the extraction is complete, the device will reboot as normal. No permanent changes will be made to the device.

On the other hand, jailbreaking the device will leave permanent traces and will also require installing third-party packages such as Cydia or AFC2, making additional changes to the device.

Challenges in iOS forensics

Smartphones are considered live, dynamic systems, and for this reason, they pose several challenges from a forensic perspective because data and files are constantly changing.

One of the main complications that a digital investigator may face is dealing with a locked device: recent iOS updates make passcode cracking almost impossible and other options will have to be considered to extract as much data as possible.

The growing number of devices and the variety of the software they run makes it extremely difficult to develop a single tool and a consistent workflow to address all eventualities. This is usually because a particular method that's used to extract data from one device will stop working when a new version of iOS is released; in fact, forensic extraction tools usually rely on security vulnerabilities to gain access to the device's filesystem and extract a lot more data than what you would normally find in an iTunes backup, or even to unlock a device when the passcode is unknown. When a new iOS update is released, these vulnerabilities could potentially be patched, thus rendering the tools useless.

The modern investigator will have to take these issues into account when approaching an Apple device and decide, on a case-by-case basis, what the best technique will be to obtain the broadest amount of valuable evidence.

Performing a forensic examination of digital evidence from a mobile device requires not only a full understanding of the data but also basic knowledge of how the device itself works and how that data was generated. This is particularly challenging on iOS devices due to the closed source nature of the platform, which makes it difficult to understand how exactly iOS interfaces with all this data and what's going on behind the scenes on the device.

Apple invests heavily in restricting the operating system and application software that can run on their hardware through several security features: applications running on Apple devices don't interact directly with the underlying hardware – they do so through a system interface. The iOS can be defined as an intermediary between the device's hardware components and the applications on the device.

Tip

Many publications provide information regarding iOS hardware. For a full list of iPhone components and devices, you can refer to the Apple Support page: https://support.apple.com/specs/iphone.

Understanding the iOS filesystem

Since iOS 10, Apple File System (APFS) has replaced HFS+ as the default filesystem. APFS is a proprietary filesystem that has been designed with mobile devices in mind: it's optimized for SSD storage and supports strong encryption. On iOS devices, the filesystem is configured into two logical disk partitions – the system partition and the user partition:

• The system partition contains the iOS operating system and all the preloaded applications that come with the device but contain little evidentiary information. The system partition is only updated when a firmware upgrade is performed on the device.
• The user partition, which is mounted to the /private/var directory, contains all user-created data and provides most of the evidentiary information that's pertinent to investigators.

Where is data stored on the iOS filesystem?

One of the examples of how iOS manages communication between applications and hardware is sandboxing, which enables users to interact with an application without accessing the filesystem directly, ensuring that each app is contained within one or more specified containers that are automatically created when a new app is installed on the device. This organization makes things a lot easier for investigators as all the files related to a specific app are grouped in specific locations.

Each container has a specific role:

• The bundle container contains the application itself, including all the assets that come with the application when it is downloaded from the App Store.
• The data container holds data for both the application and the user and is further divided into several directories that the application can use to organize its data.
• The group container is where applications can store data that can be shared with other apps of the same group.

The following diagram shows the containers for each application:

Figure 1.1 – A representation of application containers

The data container contains several different folders:

• Documents/: This folder contains user-created files and is automatically included in iTunes backups and iCloud backups.
• Library/: This folder is used by the application to store app-related data and is not created by the user. This folder is included in iTunes and iCloud backups.
• Temp/: Contains application-related temporary files and is not included in backups.

As you can see, all application files are perfectly organized into their respective data containers. However, you may be wondering where exactly these containers are stored on the device's filesystem. Each application on a device is identified through a globally unique identifier (GUID), also known as a BundleID identifier. This identifier is uniquely generated when an application is first installed and can change if the app is updated or reinstalled.

Application bundle containers are stored at the following path on the iOS filesystem:

/private/var/containers/Bundle/Application/<app-GUID>/

Application data containers are stored at the following path:

/private/var/mobile/Containers/Data/Application/<app-GUID>/

Group containers are stored at the following path:

/private/var/mobile/Containers/Shared/AppGroup/<app-GUID>/

Tip

In this section, we've seen where applications store data on the iOS filesystem. But what about system artifacts? System-related data is stored all over the filesystem, so we won't find everything all in one place! We'll dive deep into system artifacts and where to find them in Chapter 4, Working with Common iOS Artifacts.

How is data stored on the iOS filesystem?

So far, we've learned how iOS organizes application data into containers and where these containers are stored on the filesystem. Now, let's discuss the types of files that commonly contain useful evidence within the iOS filesystem.

Other than user-generated content (such as documents, photos, videos, or text files), data stored on an iOS device usually consists of the following items:

• SQLite databases: SQLite is a standalone, self-contained database that can store just about any kind of data, including binary BLOBs, all in one file. SQLite databases are the primary source of storage for applications and system data, so parsing these databases will be one of the focus points of most digital investigations. Databases can also be extremely useful if you wish to attempt to recover deleted data, as deleted records usually leave a digital trace in the database itself or its temporary files. Essential artifacts such as SMS messages, WhatsApp conversations, contacts, call logs, notes, and browser history are all stored in SQLite databases.
• Property List Files (Plists): Plists are structured files that are used by iOS and applications to store, organize, and access data on the device. These can be stored in XML format or binary format. Typically, plists are used to store application settings or user preferences.
• Other file types: This includes log files, XML files, Protocol Buffers, and Realm databases. These file types will be covered in depth later in this book.

This is what a property list looks like in XML format:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>UUID</key>
        <string>3bdd52c7-ee36-4689-8517-c5fed2c98s5</string>
        <key>ClientID</key>
        <string>3bdd52c7-ee36-4689-8517-c5fed2c98s5</string>
        <key>ClientEnabled</key>
        <false/>
     </dict>   
</plist>

In the following chapters, we will do a deep dive into the details to understand what the best practices are for parsing plists and querying SQLite databases, how to handle SQLite temporary files in a forensically sound way, and where to locate core iOS artifacts.

Apple devices are widely known for their ability to secure user data. With every release of a new iOS device or update to the iOS operating system, Apple works hard to improve security by introducing new features and by patching known vulnerabilities. In the following sections, we'll go over the key elements of Apple's security model.

User authentication

To secure physical access to the device, some form of user authentication is required. iOS devices implement authentication through two mechanisms:

• Passcode authentication
• Biometric authentication

By default, Apple devices suggest a six-digit numeric passcode, although the user can choose a four-digit passcode too or a custom alphanumeric code. Once a passcode has been set, the user will have to enter it every time the device is turned on and when it wakes up.

To improve the user experience while maintaining high-security standards, with the iPhone 5s, Apple introduced biometric authentication through Touch ID, which uses fingerprints as a passcode. With the release of the iPhone X, Apple introduced Face ID, which employs face recognition to unlock the device.

Unlocking passcode-protected iOS devices is one of the main challenges in mobile forensics.

Because there are a relatively small number of numeric passcodes, brute-force guessing attacks could theoretically be used to exploit authentication. However, this is extremely risky as iOS is designed to rate-limit passcode entry attempts, and data can be permanently deleted from the device if too many failed attempts occur.

This passcode is not just used to unlock the device itself – it's one of the key features of the iOS data protection model: the passcode, combined with the hardware encryption key, is used to generate a unique and extremely strong encryption key that is used by an algorithm to encrypt user data.

Encryption and Data Protection

While user authentication provides a degree of security in preventing unauthorized access to the physical device, these mechanisms could still be bypassed by exploiting vulnerabilities in software or hardware. A compromised device could potentially allow unauthorized access to the device's filesystem. For this reason, starting with the iPhone 4, the entire filesystem is encrypted using strong cryptography algorithms. However, with the release of the iPhone 5s, Apple set a new precedent in mobile security by introducing a technology called Data Protection, which relies on multiple dedicated components to support encryption and biometrics.

Secure Enclave

At the heart of iOS's security is Secure Enclave, a dedicated system on a chip (SoC) isolated from the main processor and operating system that provides cryptographic operations for data protection and key management.

Secure Enclave's main components are as follows:

• Secure Enclave Processor (SEP), which runs an Apple-modified version of the L4 microkernel and provides computing power exclusively to Secure Enclave.
• A memory protection engine.
• A True Random Number Generator (TRNG), which is used to generate random cryptographic keys.
• Dedicated Advanced Encryption Standard (AES) hardware engines, which communicate directly with the SEP through a secure channel and perform in-line encryption and decryption as files are written or read.
• A unique ID (UID), a cryptographic key that uniquely identifies the device. The UID is randomly generated and fused directly into Secure Enclave's hardware during device manufacturing, so it isn't visible outside the device.
• A dedicated, secure, nonvolatile storage system that can only be accessed by Secure Enclave. This is where data encryption keys are stored, ensuring that these are never exposed to iOS systems or applications.

The following diagram shows the different components of Secure Enclave:

Figure 1.2 – Secure Enclave components

Secure Enclave is responsible for several different security-related operations, including generating and storing keys necessary for encrypting data on the device and evaluating biometric data from Touch ID and Face ID.

SEP uses the UID to generate cryptographic keys that are tied to the specific device. This adds another layer of security: if the device's SSD storage is physically moved to a different device, files can't be decrypted and thus will be inaccessible, since every device has a unique UID and the original UID is required to decrypt files.

iOS Data Protection keys

Data protection on iOS is implemented by generating and managing a hierarchy of cryptographic keys.

To make things easier, before we delve into the details, let's take a look at what keys are used during the encryption and decryption processes and what their purpose is:

Figure 1.3 – Cryptographic keys used for iOS data protection

• The device's UID is an AES 256-bit key that's fused directly into Secure Enclave during manufacturing. This key, together with the user's passcode, is used to unlock class keys.
• Class keys are generated when specific events occur on the device; for instance, when a device is unlocked, a complete protection class key is created. Shortly after the device locks, the decrypted class key is discarded. Class keys are used to wrap and unwrap file keys.
• File keys are 256-bit keys that are used to encrypt the content of each file; these keys are per-file keys and, as such, are randomly generated every time a new file is created on the user partition. File keys are encrypted using a class key and are then stored in the file's metadata. The metadata of all the files is encrypted with the filesystem key.
• The filesystem key is a random key that is generated when iOS is first installed or when the device is wiped. The filesystem key is stored on the device, and it's been designed to be quickly erased if the user requests it. Deleting the filesystem key makes all the files on the filesystem inaccessible.

iOS Data Protection classes

Let's take a closer look at the class keys.

Apple allows developers to specify security settings for each file by selecting a protection class that is assigned to a file when it is created. There are four different protection classes, depending on how the file is meant to be accessed:

• Complete Protection: Class keys for this protection are decrypted when a device is unlocked and are automatically evicted shortly after device lock, so a file associated with this protection class will only be accessible when the device is unlocked.
• Protection Unless Open: This protection class allows files to be created and encrypted when the device is locked, but only decrypted when the device is unlocked. This is used, for example, when an email attachment is downloading in the background.
• Protected Until First User Authentication: Class keys for this protection are decrypted when the device transitions from a before first unlock (BFU) state to an after first unlock (AFU) state and remain in memory, even if the device is locked.
• No Protection: The class keys for this protection class are always available in memory when the device is on.

Encrypting content while performing normal operations on a device can be challenging. Protection classes allow files to be encrypted safely, modulating the degree of protection based on how and when each file needs to be accessed.

For example, data that is useful to applications running in the background, such as messages or contacts, can be assigned to the Protected Until First User Authentication class; this allows data to be accessible to the device while keeping it encrypted.

iOS data encryption and decryption

When a file is written to the filesystem, the content of the file is encrypted with a per-file key, which is wrapped with a class key and stored in a file's metadata. The metadata is then encrypted using the filesystem key.

We've already seen how class keys are generated using a combination of the hardware's UID and the user's passcode while the filesystem key is generated upon iOS installation and stored on the device. Now, let's analyze the individual file encryption process step by step:

1. Every time a file is created on the filesystem, Secure Enclave creates a 256-bit file key and passes this key to the hardware AES engine.
2. The AES engine encrypts file content while it is written to flash memory using the provided file key.
3. The file key is then wrapped with one of the four class keys, depending on the assigned protection class, and is stored in the file's metadata.
4. Metadata for all the files is encrypted with the filesystem key.

All key handling happens in Secure Enclave, thus never exposing the operations to the system and its applications.

The decryption process works the other way round:

1. When a file is opened, its metadata is decrypted using the filesystem key, revealing the wrapped file key and the assigned protection class.
2. The file key is unwrapped using the class key and is then passed to the AES engine.
3. The hardware AES engine decrypts file content while it reads the file from memory, using the provided file key.

   Tip

   Key wrapping is the process of encrypting one key using another key to securely store or transmit it.

Although the data protection architecture may seem complex, it provides both flexibility and good performance.

By now, you should have a basic understanding of where iOS stores application data, how data is structured, and how iOS leverages authentication and data protection to guarantee a high level of security on all devices.

In the next section, we will learn about the guidelines for a forensically sound examination process.

Although there is no well-established standard process for mobile forensics, there are some common guidelines that can be followed to ensure that the examination will be carried out through a proper methodology. This will make the process forensically sound and the results reliable.

Generally, a mobile forensics examination can be broken down into the following six steps:

1. Seizure and identification
2. Preservation
3. Acquisition
4. Analysis
5. Validation
6. Reporting

   Tip

   The key point to understand here is that the process you use to examine the mobile device and extract data from it is what makes the examination forensic. It is neither the software nor the hardware you use, but solely the process that you use during the examination that makes it truly forensic.

These guidelines and processes should be periodically reviewed as technology continues to evolve and different mobile devices are marketed.

Seizure and identification

The first step pertains to the physical seizure of the device. This involves gathering information on the type of incident that the device was involved in and at least some basic information on the device's owner.

The way the seizure occurs depends on your jurisdiction, so you should be familiar with laws regarding seizing and analyzing smart devices and what the requirements are (that is, a search warrant is usually required). At this stage, you should also have a general understanding of what data you are expected to find, as this will help you define specific objectives and plan the next steps according to your requirements.

First and foremost, you need to document everything you do and consider how to preserve evidence. How you handle the device matters and it can have a huge impact on the outcome of the investigation.

You should also note the state that the device was found in. The following are some examples:

• Is the device powered on or off?
• Is the device protected by a passcode?
• Is the passcode known?
• Is the SIM card present?
• Is there any visible damage?
• What's the date and time on the device?
• If the device is on, what apps are running?
• Basic ownership information.

One of the fundamental aspects of a forensically sound process is that operations should be carried out without altering or changing the contents of data that resides on the device in any way. Note that iOS devices are live, dynamic computer systems, so any kind of interaction with the device would result in changes to system files and databases, not to mention the possibility of inadvertently deleting temporary files that could contain useful evidence. Care should be taken to limit all interaction with the device, except for the preservation operations, which will be indicated in the next section.

Once the device has been seized, an investigator could be tempted to manually access data from the device, such as by running messaging apps and viewing conversations directly from the device's screen; however, this should be strongly discouraged as this would result in system logs and other system-related files being altered, which is not forensically sound behavior.

At this stage, the investigator will also have to identify the device, its hardware model, and the iOS version. This information will be useful if you wish to start assessing what options the investigator has for extracting evidence from the device.

For each examination, the investigator should also identify the following:

• The legal authority for examining the device
• The goals of the examination
• Other sources of potential evidence (including cloud storage)

Preservation

Smartphones are, by design, meant to communicate through cellular networks, Bluetooth connections, and wireless Wi-Fi networks. To prevent the device from communicating, it is important to isolate the device as soon as possible. Isolating the device prevents new data (incoming calls, incoming messages, and so on) from modifying existing evidence and thus enforces data preservation. Additionally, if the device were allowed network access, data destruction could occur as Apple products can be remotely wiped via a kill signal.

The easiest way to isolate an Apple device is by enabling Airplane mode; this deactivates the device's wireless and cellular connections. You can enable Airplane mode from the device's Settings or, if the device is locked, directly from the control center by swiping up from the bottom. If the device is an iPhone X or newer, you can access the control center by swiping down from the top-right corner. However, it's worth noting that isolating the device can also be accomplished by putting the device in a Faraday bag, a container made of metallic shielding that blocks the radio frequencies used by cellular networks, GPS, and Wi-Fi networks.

Don't forget to keep the device charged to ensure it doesn't power off. Generally speaking, you want the device to remain in the state in which you found it:

• If the device was off, leave it off.
• If it was on, make sure you leave it on so that it doesn't lock!

This is particularly important if the device is passcode protected and the investigator doesn't have the code: if the device powers off, it would transition from an AFU state to a BFU state, rendering data recovery much more challenging and, in some cases, impossible. We will learn more about device states later in this chapter.

Tip

One of the most common mistakes is removing the SIM card from an unlocked device to isolate it from a cellular network. This may make sense when you're working with different devices, but you want to avoid removing the SIM card from iPhones or iPads because doing so will result in iOS automatically locking the device, biometric unlock will be disabled, and USB restricted mode will be activated.

After successfully seizing and isolating the device, care should be taken to maintain the device's chain of custody. NIST defines the chain of custody as follows:

"A process that tracks the movement of evidence through its collection, safeguarding, and analysis life cycle by documenting each person who handled the evidence, the date/time it was collected or transferred, and the purpose for the transfer."

You can learn more about this topic by visiting the following website: csrc.nist.gov.

Acquisition

Acquisition is the process of obtaining information and evidence from a device.

Before the actual acquisition process begins, you should have a clear understanding of what kind of evidence you're looking for as this will have a great influence on the tools you choose to use.

Generally speaking, there are three different kinds of data acquisition, and the method the investigator chooses affects how much data can be extracted from the device:

• Logical acquisition
• Full filesystem acquisition
• Physical acquisition

In the following table, you can see what kind of data can be extracted with each method:

Table 1.2 – Comparison of data that can be extracted with different acquisition methods

Logical and filesystem extractions

As you can see, a logical acquisition will extract some user-generated data from the device such as photos, messages, and notes. A logical extraction will usually be the easiest and quickest type of extraction and most forensic tools support it. However, considering the number of files available on an iOS device, only acquiring the full filesystem will give access to precious evidence such as third-party app data, precise location data, and pattern-of-life information.

A filesystem extraction is a representation of the files and folders from the user partition of the device; it is possible to partially recover deleted data by analyzing databases and temporary files, such as WAL files.

Physical extraction

Devices up to and including the iPhone 4 can undergo a full, forensically sound physical extraction of the entire raw disk. This kind of extraction delivers the most data as, much like a standard hard drive, both the system and the user partitions are extracted, as well as unallocated areas of the disk. This is incredibly useful as it allows investigators to recover deleted data, including messages, photos, and videos. However, with the introduction of iOS 5, Apple changed the way data was encrypted on disk and enabled other security features, such as data protection class keys. At the time of writing, extracting a physical image of modern iOS devices is simply not possible.

Choosing the best acquisition method

Investigators should always perform a logical acquisition first and then, if possible, attempt a filesystem or physical acquisition.

Jailbreaking the device is generally required to enable unrestricted access to the device's filesystem; however, more and more vendors are adding the possibility to run forensically sound checkm8-based extractions (all operations are performed in the device's volatile RAM) or agent-based extractions. Both options allow you to obtain the full filesystem without jailbreaking the device.

At the end of the day, the method you choose will usually depend on four variables:

• The state in which you find the device (locked or unlocked)
• The device model and iOS version
• The tools you have access to
• The possibility of jailbreaking the device

If the device is locked and you don't have the passcode, there is not a simple solution that can consistently bypass iOS security. However, depending on the device model, several options can provide a limited amount of data. We will examine these in detail in the next chapter.

If the device is unlocked, depending on the available tools, you can attempt a filesystem extraction. You should start with the less intrusive option, such as an in-memory checkm8 exploit, if your tools support it. If the device doesn't allow checkm8 exploiting, you can attempt an agent-based extraction if the iOS version is compatible. Although this entails installing an agent on the device and some minor changes can occur, this is considered forensically safe. If neither of these options is available, you can consider jailbreaking the device through checkra1n or unc0ver. Make sure you understand how the jailbreak works, how it affects the device, and what the risks are. Finally, if none of these options are available, you will have to go for a logical acquisition.

We will learn all about extracting data from iOS devices in the next chapter, but for now, it's important to note that the phone should be acquired using a tested method that is repeatable and is as forensically sound as possible. It is highly recommended to experiment with various tools on test devices to determine which acquisition method and tool work best with different devices.

If you don't have direct access to the device, there are other sources of evidence you can consider, such as iTunes backups and iCloud extractions.

Analysis

The main point of doing a forensic examination is to find, extract, and process evidence related to a particular case or investigation.

Although there is no standard process to analyze what you extracted from a device, here are some guidelines that should help you get started:

• Go through all the available data to become familiar with the main sources of evidence found on the device.
• Use your tools and forensic software to quickly parse common data sources, such as SMS databases, installed apps, call logs, photos, and so on.
• Attempt to recover any deleted data both with software and by manually carving binary files, logs, plists, and SQLite databases.
• Identify key artifacts by searching for keywords and details that are specific to your investigation.
• Harvest metadata from files and look for hidden evidence (timestamps, geolocation data, binary BLOBs, and so on).
• Find relationships between different artifacts.
• Perform temporal analysis on all acquired evidence, building a timeline of relevant artifacts and events.

When you're dealing with a limited amount of data, it may be possible to assess evidence by manually browsing through all the folders and viewing the contents of the files on your workstation. However, when you're looking at gigabytes of data sources, including SQLite databases, caches, and plists, you'll probably have to resort to using forensics tools. In such cases, investigators must develop a strategy to use the best tools, depending on the type of digital evidence and the goals of your investigation.

We'll cover commercial tools in detail in Chapter 2, Data Acquisition from iOS Devices and Chapter 3, Using Forensic Tools, but before that, it must be noted that all mobile forensics tools are just application software. These tools are not magical things that conduct autonomous processing and reporting simply by clicking a button! Digital investigators must understand the features and limits of each tool.

Mobile forensic tools typically differ in the kind of extraction that can be done, but different tools are also compatible with different devices and different versions of the iOS operating system. With the variety of different types of mobile devices, no single software supports all mobile devices.

Automated tools can speed up the time it takes to process huge datasets and I strongly believe that the modern investigator should have more than one tool available. However, this process is not a substitute for a methodical, manual forensic examination and validation.

In the end, it all comes down to the target device model, the iOS version, the type of extraction, the goal of the examination, and how the produced evidence might be used later.

Validation

After processing evidence from the device, the investigator must verify the accuracy of all the steps that have been carried out. This process should not focus exclusively on verifying the data extracted from the device. It should also entail validating the tools that were used for the examination and validating the entire process to ensure it has been carried out in a forensically sound way.

Unfortunately, validation is one of the most overlooked aspects.

Before starting an examination, it is highly recommended to experiment with various tools on test devices and known datasets to determine which acquisition and analysis tools work best with specific iOS device models and versions.

Established procedures should lead to the process of acquisition and analyzing a device. This is especially true when an investigator is working on data from third-party apps or Unidentified Forensic Objects (UFOs). Practices must be tested to ensure that the results that have been obtained are valid and independently reproducible.

An examiner who is called to testify on their findings should be able to explain not only what evidence was found, but also where that data was found and how the iOS operating system generated those artifacts. This could entail manually decoding binary data and file carving. Analyzing actual binary files that user data was parsed from, along with SQLite databases and plists, offers the investigator the opportunity to perform deep analysis of the iOS device's filesystem, extracting evidence that could be missed by relying only on automatic tools.

The following list resembles some of the best practices regarding verification and validation:

• Hash values: All the files that are extracted from the device should be hashed during the acquisition process to ensure that no changes occur. If you're doing a filesystem extraction, you can calculate the hashes for each file at the end of the process. Data integrity can be verified by calculating the hash for a single file and checking it against the original value.
• Deterministic tools: All the tools that are used for an examination should be deterministic: a given tool should produce the same output when given the same input data, under the same circumstances.
• Data verification: Check if known data stored on the device is reported accurately, without any modifications. Generally, data that's extracted from the device should match the data that's viewed on the device's screen.
• Tool accuracy: The quality of the output of a tool should be checked by using multiple tools to extract/process the same data and compare results.
• Process testing: When working on UFOs or artifacts where there is not an established examination process yet, validate your findings by testing each solution on different devices and under known control conditions and evaluate the results of each test.

Reporting

The last step in the mobile forensics process is reporting. Reporting can be defined as the process of preparing a detailed summary of what was done to acquire and analyze digital evidence from a mobile device. A forensic report should also include all the relevant evidence, presented in a clear, concise manner, and the conclusions that were reached in the investigation.

Many forensic tools provide a built-in reporting feature that allows you to automatically generate a digital report that includes items from the investigation, such as the following:

• Key artifacts
• Device identification (model, s/n, phone number, and so on)
• Case number and the analyst's name
• Date and time of when the examination took place
• Tools that were used for extraction and analysis

Depending on your jurisdiction, a forensic report should also describe how the data was extracted (logical, physical, or filesystem extraction) and explain what measures were taken to ensure the entire process was repeatable and forensically sound.

Timeline analysis

One of the most common forms of forensic reporting includes temporal analysis, which is defined as the process of creating a timeline of events that occurred on the device at a specified date and time.

A timeline generally includes data from a variety of sources; for example, location data, system logs, and messaging evidence can be combined and can lead to the discovery of what happened, where it happened, and when it happened.

Determining when events occurred on the device and associating device usage with an individual by reporting logs, files, and timestamps can be extremely useful.

In this chapter, we learned what the goal of a forensic examination is and how the discovery of the checkm8 vulnerability provides new opportunities for data acquisition from iOS devices.

First, we introduced the iOS operating system and discussed some key elements of its security architecture, such as Secure Enclave and Data Protection. Then, we went through the steps of an iOS forensic examination.

The first step is seizing the device and adopting techniques to preserve evidence, such as placing the device in a Faraday bag or enabling Airplane mode. There are different ways to acquire data from an iOS device, depending on the model, iOS version, and what tools are available. This chapter covered logical and filesystem acquisition techniques, as well as jailbreaking and agent-based extractions.

Analyzing artifacts should be done by following a thorough validation process that ensures that commercial tools produce consistent results and that evidence has been processed in a forensically sound way.

Finally, we learned what key elements should be included in a forensic report.

The next chapter will discuss iOS data acquisition in detail and provide a hands-on approach to the tools that are used to conduct a forensic examination.