Mobile Operating Systems and File Systems

Modern iPhones use a GPT (GUID Partition Table) layout on their internal NAND storage. The two primary partitions visible to forensic tools are the System partition and the Data partition. The System partition is read-only, signed by Apple, and contains the iOS kernel, frameworks, and built-in apps. The Data partition, mounted at /private/var, holds all user-generated content: installed third-party apps, their data containers, databases, caches, and keychain entries. Since iOS 10.3 both partitions are formatted as APFS volumes within a single APFS container.

Within the Data partition the directory structure most relevant to forensics is under /private/var/mobile. Third-party app data lives under /private/var/mobile/Containers/Data/Application, with each app getting a UUID-named subdirectory containing Documents, Library, and tmp sub-folders. System databases, including SMS (/private/var/mobile/Library/SMS/sms.db), call history (/private/var/mobile/Library/CallHistoryDB/CallHistory.storedata), and Safari history (/private/var/mobile/Library/Safari/History.db), reside under /private/var/mobile/Library. Media files live under /private/var/mobile/Media.

APFS snapshots are a forensically significant feature. iOS creates snapshots during backups and OS updates. A snapshot preserves the file system state at a point in time, so even if a user deletes files after a snapshot is taken, the snapshot volume may still contain the earlier versions. Some logical acquisition tools can mount APFS snapshots directly and recover files that have since been deleted from the live volume.

Android devices use eMMC or UFS storage with a GPT partition table. The exact partition names vary by manufacturer and SoC, but the canonical partitions common across devices include: boot (kernel and ramdisk), system (read-only OS), vendor (manufacturer drivers and overlays), userdata (all user and app data), cache or metadata (OTA update staging), and persist (calibration data that survives factory reset). On devices running Android 10 and later, Dynamic Partitions may group system, vendor, and product into a single super partition managed by a logical volume layer.

The userdata partition is the primary forensic target. It is formatted as ext4 or F2FS depending on the device. It mounts at /data and contains: /data/data (per-app private data directories), /data/media/0 (the user's internal storage, exposed as the "SD card" via a FUSE or sdcardfs layer), /data/system (system settings databases, gesture lock files, and the packages.xml manifest), and /data/app (installed APK files and their OAT-compiled code).

Key forensic databases under /data/data by provider package: call logs and contacts reside in com.android.providers.contacts (contacts2.db) and com.android.providers.contacts for Android 2.3+, SMS and MMS in com.android.providers.telephony (mmssms.db), browser history in com.android.browser or com.google.android.browser (browser.db), and calendar data in com.android.providers.calendar (calendar.db). These paths are consistent across AOSP builds but may differ on heavily customised manufacturer UIs.

APFS encrypts data using AES-XTS with a per-file key wrapped by a class key derived from the device's hardware UID (fused into the SoC at manufacture) combined with the user's passcode. This key hierarchy means that a chip-off acquisition of the raw NAND chips returns ciphertext that cannot be decrypted without either the passcode (which allows derivation of the class keys) or a hardware attack on the Secure Enclave, the coprocessor that holds the hardware UID and performs all key operations. The Secure Enclave enforces exponential backoff and, on devices with Touch ID or Face ID, limits passcode attempts to ten before wiping the key material.

When a file is deleted in APFS, the file's inode and extent records are removed from the B-tree metadata structures. Unlike traditional spinning-disk file systems, APFS does not leave orphaned inode entries that persist until new writes overwrite them. The SSD's flash translation layer (FTL) will eventually trim the underlying blocks. However, APFS does maintain a journal and the metadata B-tree uses copy-on-write semantics, meaning that prior versions of tree nodes may remain in unallocated space for a period. Snapshot-aware acquisition can capture file states that predate the deletion.

ext4 uses a journaling architecture and stores file metadata in a fixed inode table. When a file is deleted, the inode entry is marked free and the directory entry is removed, but the inode's block pointers remain intact until the inode is reused. In practice this means that unallocated space on an ext4 partition may contain recoverable file content and metadata for files deleted since the last inode reuse at that location. Many mobile forensic tools (Cellebrite UFED, Oxygen Forensic Detective, MSAB XRY) include ext4 carved unallocated space recovery as a standard feature.

F2FS uses a log-structured design. Writes are appended to a sequential log divided into segments and sections. The Node Information Block (NIB) tracks the current location of each file's node (inode equivalent). When a file is deleted, its node address is invalidated in the NIB and the segment space is marked for garbage collection. Because the file system writes sequentially rather than in-place, older versions of file data may persist in segments that have not yet been garbage-collected, but the location is not predictable from a simple inode scan. Recovery requires reconstructing node history from segment summaries, a technique supported in research tools but with limited coverage in commercial tools as of 2024.

Full-disk encryption (FDE) in Android before version 7 encrypted the entire userdata partition with a single key derived from the user's PIN or password plus a device-specific hardware key. Android 7 and later switched to file-based encryption (FBE), mirroring iOS's approach: each file is encrypted with a per-file key, and keys are unlocked on a per-user basis at authentication. Under FBE, device encrypted (DE) storage is available before the first user unlock, while credential encrypted (CE) storage requires the passcode. This matters for seizure: a device running Android 7+ that has never been unlocked after reboot exposes only the DE storage to an ADB extraction.

iOS application isolation is enforced at multiple levels. At the file system level, each installed app receives a unique UUID-named container directory. The Bundle Container holds the app binary and resources; the Data Container holds Documents, Library, and tmp subdirectories where the app stores its data. The mapping between the opaque UUID and the app's bundle identifier is stored in a plist file within the container metadata directory, a step forensic examiners must complete to identify which UUID belongs to which app.

At the process level, iOS uses a combination of UNIX permissions and TrustedBSD mandatory access control (MAC) enforced by the Sandbox kernel extension (also known as Seatbelt). An app's signed entitlement list defines which system services it may call, which data classes it may access, and whether it may communicate with other apps via app groups. An entitlement is a cryptographically bound claim that the app developer applies at compile time and Apple validates at distribution. An app without the com.apple.developer.healthkit entitlement cannot read HealthKit data regardless of UNIX permissions.

The Secure Enclave Processor (SEP) is a separate ARM core in iPhones from the iPhone 5s onward. It holds the device's UID key (fused at manufacture, never exposed to the application processor) and the user's biometric templates. All keychain encryption and data protection class key operations pass through the SEP. When an examiner connects a device using a lockdown pairing certificate, the SEP validates the pairing and grants access only to data in protection classes permitted by the current device state, not to the underlying key material. This is why jailbreak-based acquisition methods that bypass the application processor but not the SEP still face encryption barriers on the underlying storage.

Android's primary isolation mechanism is the assignment of a unique Linux UID to each installed application. The package manager assigns UIDs starting at 10000 (the first app UID) and increments for each new install. The app's private data directory at /data/data/<package_name> is owned by that UID with mode 0700. No other app process, running as a different UID, can read or write the directory without root access. System apps and certain privileged packages share predefined UIDs (system = UID 1000, radio = UID 1001) and have broader file system access.

Since Android 5.0, SELinux has been enforced in enforcing mode on all devices. SELinux adds a mandatory access control layer on top of the UID model: each process and file is labeled with a SELinux type, and a policy defines which process types may access which file types. Root access alone is insufficient to access a file if the SELinux policy does not permit the process's type to read it. This is why some rooting methods that gain a root shell still cannot read certain protected files until they also disable or permissive-mode SELinux, an action that must be documented in an examination report because it constitutes a modification to the device state.

For an examiner with physical access to the userdata partition (via physical acquisition, JTAG, or chip-off), the UID and SELinux controls are file system metadata, not runtime enforcement. The examiner reads the partition image as raw bytes and navigates the directory tree without any OS-level permission checks. The key practical paths are: /data/data/com.android.providers.telephony/databases/mmssms.db for SMS and MMS, /data/data/com.android.providers.contacts/databases/contacts2.db for contacts and call logs on older devices, and /data/data/<social_app_package>/databases/ for third-party messaging apps. On Android 9 and later, call logs moved to /data/data/com.android.providers.contacts/databases/calllog.db as a separate database.