Dissecting the iOS operating system

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.