Skip to content

CH5: Mobile Device Architectures & The Boot Process

Learning Objectives

By the end of this chapter, students will be able to:

  • Differentiate between standard computer architectures (x86) and mobile System-on-Chip (SoC) architectures (ARM).
  • Identify critical hardware components relevant to digital forensics, including RAM, NAND flash, and the Secure Enclave.
  • Explain the "Chain of Trust" and the Secure Boot process for both Android and iOS devices.
  • Analyze the differences between various boot modes (Normal, Recovery, DFU, EDL/Download) and their forensic utility.
  • Evaluate how hardware-backed encryption impacts modern acquisition methodologies.

5.1 Introduction: Why Hardware Matters to a Forensic Examiner

In the early days of digital forensics, an investigator could simply remove a hard drive from a computer, attach it to a write-blocker, and image the drive. In the mobile world, this is rarely possible. Mobile devices are sealed, integrated systems where the storage, processor, and memory are soldered directly onto a single board. Furthermore, modern security measures are tied inextricably to the physical hardware of the device.

To understand how to extract data from a locked smartphone—or why, in many cases, you cannot extract data—you must understand what happens the moment you press the power button. This chapter explores the physical architecture of mobile devices and the complex software sequence known as the Boot Process.

For a forensic examiner, the boot process is not just a startup routine; it is the battleground where security defenses are mounted and where forensic exploits (like jailbreaks or bootloader bypasses) operate. When you connect a forensic tool to a seized device, you are often attempting to interrupt or manipulate this very process to gain access to the data before the operating system locks it down.

5.2 Mobile Hardware Architecture

Unlike desktop computers which typically use distinct components connected via a motherboard (CPU, GPU, RAM, separate Hard Drive), mobile devices utilize a highly integrated design known as a System-on-Chip (SoC).

5.2.1 System-on-Chip (SoC)

The SoC is the brain of the mobile device. It integrates the Central Processing Unit (CPU), Graphics Processing Unit (GPU), modem (cellular connectivity), and often the Image Signal Processor (ISP) for the camera onto a single silicon chip.

Forensic Relevance: Because these components are integrated, we cannot easily intercept data moving between them. For example, the encryption keys used to scramble user data are often generated or protected by a dedicated security co-processor located inside or tightly coupled with the SoC. This physical integration forces forensic examiners to rely on software exploits or advanced hardware attacks (like voltage glitching) rather than simple physical disassembly.

5.2.2 ARM Architecture vs. x86

Most desktops run on x86 architecture (Intel/AMD). Almost all mobile devices run on ARM (Advanced RISC Machine) architecture.

  • RISC (Reduced Instruction Set Computing): ARM processors use simpler instructions that require less power, making them ideal for battery-operated devices.
  • Big.LITTLE Processing: Modern ARM chips often use a mix of high-performance cores (for heavy tasks like gaming or video decoding) and high-efficiency cores (for background tasks like checking email) to save battery.
  • Endianness: While x86 is Little-Endian, ARM can be Bi-Endian (configurable), though Android and iOS typically run in Little-Endian mode. This is important when manually analyzing raw binary data or hex dumps.

5.2.3 Memory and Storage Types

Understanding where data lives is the core of forensics. On a mobile device, we primarily deal with two types of memory:

1. RAM (Random Access Memory) - Volatile

This is the workspace of the device. It holds currently running apps, open documents, passwords in plaintext, and encryption keys while the device is unlocked.

  • Forensic Note: RAM is volatile. If the device loses power or reboots, the data in RAM is effectively lost. This is why "Cold Boot" attacks (freezing RAM chips to slow down data decay) were theoretically discussed in the past but are largely impractical on modern SoCs due to the way memory is layered (PoP - Package on Package) directly on top of the CPU.
  • The "Live" State: As discussed in Chapter 3, this reinforces the "If it's on, keep it on" rule. If a phone is powered on and unlocked, the keys to decrypt the data are residing in the RAM. If the phone reboots, those keys are wiped, and the data returns to an encrypted state.

2. NAND Flash / UFS / NVMe - Non-Volatile

This is the device's "hard drive." It stores the operating system, apps, and user data (photos, messages, databases).

  • eMMC (Embedded Multi-Media Controller): The older standard found in budget or older devices. It behaves somewhat like an SD card soldered to the board.
  • UFS (Universal Flash Storage): Common in modern Androids. It allows for faster read/write speeds and simultaneous data transfer (full-duplex).
  • NVMe (Non-Volatile Memory Express): Adapted by Apple for iPhones to achieve extremely high speeds comparable to desktop SSDs.

The Wear Leveling Challenge: Flash memory wears out if you write to the same spot repeatedly. To prevent this, the storage controller uses Wear Leveling to distribute data evenly across the chip.

  • Garbage Collection: When files are deleted, the controller eventually wipes those blocks to prepare them for new data. This makes recovering deleted files (File Carving) much harder on mobile devices than on traditional spinning hard drives. Once the "Garbage Collector" runs (often triggered by the TRIM command), the data is physically gone. This contrasts with traditional hard drives where deleted data might sit in "unallocated space" for years.

5.3 The Boot Process and the "Chain of Trust"

The boot process is the sequence of events that occurs from the moment the power button is pressed until the user sees the lock screen. In modern forensics, this is where the security model is enforced.

Manufacturers use a concept called the Chain of Trust (or Secure Boot).

  • Concept: Each step in the boot process checks the digital signature of the next step before allowing it to run.
  • Goal: To ensure that no malicious software (or forensic extraction tools!) has tampered with the operating system.

If a signature check fails (e.g., if a forensic examiner tries to load a custom recovery image to bypass a passcode), the device halts the boot process to protect the data.

5.3.1 General Boot Flow

While names vary between Apple and Android, the general flow follows a specific hierarchy:

  1. Boot ROM (Read-Only Memory): The very first code that runs. It is hardcoded into the processor chip during manufacturing. It cannot be changed (Read-Only). It contains the root public keys to verify the next stage. If a vulnerability exists here (like checkm8), it is unpatchable.
  2. Low-Level Bootloader (LLB): Initializes essential hardware (like RAM) and verifies the next stage.
  3. High-Level Bootloader (iBoot / ABOOT): Verifies and loads the Operating System kernel. This is often where "Fastboot" or "Recovery" modes live. This is the stage usually targeted by "Unlocking the Bootloader."
  4. Kernel: The core of the OS. It manages hardware resources and security policies.
  5. User Space: The Android framework or iOS SpringBoard (the visual interface).

5.4 Android Architecture & Partitions

Android is based on the Linux kernel. Its storage is divided into logical sections called Partitions. Understanding these is vital for physical extraction analysis, as different extraction methods yield different partitions.

5.4.1 Key Android Partitions

  • /boot: Contains the kernel and the RAMdisk. Without this, the phone will not boot.
  • /system: Contains the Android OS files, system apps, and libraries. Usually Read-Only. If you find malware here, it suggests the device was "rooted" or compromised at a deep level.
  • /recovery: A separate bootable partition containing a mini-OS used for maintenance (updating, factory resetting).
  • /data (The "Userdata" Partition): This is the gold mine. It contains:
    • User installed apps.
    • SMS/MMS databases (mmssms.db).
    • App databases (WhatsApp, Facebook, Signal).
    • Photos, videos, and downloads.
    • Note: On modern Androids, this partition is encrypted by default.
  • /cache: Stores temporary data and update logs. Sometimes contains artifacts of app installations.

5.4.2 Android Boot Modes

As a forensic examiner, you will frequently manipulate these modes to attempt data extraction.

  1. Normal Mode: The standard user interface.
  2. Recovery Mode: Accessible via button combinations (e.g., Volume Up + Power). Used for factory resets or applying updates (ADB Sideload).
    • Forensic Use: In older devices, examiners could install "Custom Recovery" (like TWRP) to bypass locks. Secure Boot now prevents this on stock devices unless the bootloader is unlocked.
  3. Fastboot Mode (Bootloader Mode): A protocol used to modify the flash filesystem via a USB connection.
    • Forensic Use: Used to flash unsigned images if the bootloader is unlocked. However, unlocking a bootloader on a modern Android almost always triggers a mandatory "Wipe Data" command, destroying the evidence.
  4. Safe Mode: Boots the OS without third-party apps. Useful if malware is preventing the phone from functioning, allowing the examiner to potentially uninstall the interference or reach settings.
  5. EDL (Emergency Download Mode) / Odin Mode (Samsung):
    • EDL (Qualcomm devices): A low-level interface intended for manufacturers to repair "bricked" phones. It accepts commands before the full OS loads.
    • Forensic Relevance: Advanced forensic tools (like Cellebrite, GrayKey, or Oxygen) often exploit vulnerabilities in EDL or similar low-level modes to bypass locks or perform physical extractions (decrypted) without knowing the passcode. This is often called a "Bootloader Exploit" or "Download Mode" extraction.

5.4.3 Android's Trusted Execution Environment (TEE)

In the mobile ecosystem, software vulnerabilities are common. Malware, rootkits, or even a compromised operating system could theoretically read any data stored in the device's main memory (RAM). To prevent this, modern Android architecture relies on a critical hardware-backed security standard called the Trusted Execution Environment (TEE). We will discuss Apple's equivalent to this, the Secure Enclave, in the next section.

The Concept: Secure World vs. Normal World Most Android devices run on ARM processors which utilize ARM TrustZone technology. This technology essentially splits the main processor into two virtual, hardware-isolated environments:

  1. The Normal World (Rich Execution Environment - REE): This is where the main Android Operating System, your apps (Instagram, Gmail), and the user interface live. This is considered an "untrusted" environment because it is user-accessible and susceptible to malware or software exploits.
  2. The Secure World (TEE): This is a separate, isolated environment that runs its own micro-kernel (a tiny, highly secure operating system). It runs in parallel to the main Android OS but is invisible to it. The "Normal World" cannot read the memory or access the resources of the "Secure World," even if the Android OS has been fully compromised (rooted).

Manufacturer Implementations While ARM provides the architectural standard (TrustZone), different manufacturers build their own TEE software implementations on top of it:

  • Google Trusty: The open-source TEE operating system provided by Google as the standard for Android.
  • Samsung Knox: Samsung's proprietary security platform which utilizes the TEE to protect biometric data, Samsung Pay, and "Secure Folder" contents.
  • QSEE (Qualcomm Secure Execution Environment): A common implementation found in devices using Qualcomm Snapdragon chips.

Forensic Implications The TEE is the most significant hurdle in modern Android forensics because it serves as the vault for the device's Disk Encryption Keys.

  • Isolation from Root: Gaining "Root" privileges on the Android OS gives an examiner full control over the Normal World. However, because the TEE is hardware-isolated, a rooted Android OS still cannot read the encryption keys stored inside the TEE memory.
  • The Gatekeeper: The TEE acts as a strict gatekeeper. When a user inputs their PIN or scans their fingerprint, that data is sent to the TEE. The TEE verifies the credential inside the Secure World. Only if the verification passes does the TEE release the decryption key to the hardware engine to unlock the user's data.
  • Prevention of Offline Attacks: Because the keys are locked inside the TEE hardware, examiners cannot simply desolder the memory chip and attack the password using a supercomputer (an "Offline Brute Force" attack). Without the specific TEE hardware to validate the PIN and release the key, the raw data on the memory chip remains permanently encrypted.

5.5 iOS Architecture & The Secure Enclave

Apple controls both the hardware and software of the iPhone, leading to a much stricter and more uniform security architecture.

5.5.1 The Secure Enclave Processor (SEP)

Introduced with the iPhone 5S, the SEP is a coprocessor strictly focused on security. It effectively acts as a "computer within a computer."

  • Function: It handles Touch ID/Face ID data and manages the encryption keys for the file system.
  • Isolation: The SEP is isolated from the main processor (Application Processor). Even if the main iOS kernel is compromised (jailbroken), the hacker cannot easily read the keys inside the SEP.
  • UID (Unique ID): A key fused into the SEP silicon during manufacturing. Apple does not keep a record of this key, and it cannot be read by software. It is used to wrap (encrypt) the user's passcode. This ties the data to that specific physical device. You cannot move the memory chip to another iPhone to read the data (a major difference from old-school forensics).

5.5.2 iOS Boot Chain

  1. Boot ROM: Hardcoded, immutable root of trust. Checks the signature of the LLB.
  2. LLB (Low-Level Bootloader): Verifies and loads iBoot.
  3. iBoot: The stage 2 bootloader. It verifies and loads the iOS Kernel. If verification fails, it forces the device into Recovery Mode.
  4. Kernel: The heart of iOS.

5.5.3 iOS Forensic Modes

  1. Recovery Mode: Shows the "Connect to iTunes/Computer" cable icon. It allows restoring the device (wiping data) or updating it.
    • Forensic Use: Limited use for data extraction, but useful for identifying device model (ECID) and serial number if the screen is broken.
  2. DFU Mode (Device Firmware Update): A state where the device allows communication with iTunes but hasn't loaded the bootloader or OS yet. The screen remains black.
    • Forensic Relevance: This is the entry point for famous exploits like checkm8.
    • The checkm8 Exploit: This is a permanent vulnerability in the Boot ROM of iPhones ranging from the iPhone 5s to the iPhone X. Because it is in the Read-Only Memory (ROM), Apple cannot patch it with a software update. Forensic tools use this to gain temporary "root" access to the device to perform Full File System extractions, even on locked devices (though decrypting the data still requires the passcode in most cases, or a brute-force attack handled by the tool).

5.5.4 Key iOS Partitions

While Android uses a complex structure with many partitions, the iOS file system is generally simpler in layout, primarily consisting of two distinct partitions (or "volumes" in modern APFS architecture). Understanding this division is critical because one holds the software, and the other holds the evidence.

  • The System Partition (Root):

    • Mount Point: /
    • Content: Contains the operating system, boot files, and pre-installed Apple applications (like the Calculator or Compass app code).
    • Forensic Relevance: This partition is Read-Only. On modern iOS, it is protected by a "Signed System Volume" mechanism. This means user data is rarely found here. If you find modifications or foreign files in the System Partition, it is a strong indicator that the device has been "Jailbroken."

  • The User Data Partition:

    • Mount Point: /private/var
    • Content: This is where all user-created data resides. It is the primary target for any forensic acquisition.
    • Key Evidence Locations:
      • /private/var/mobile: The user's "Home" folder.
      • /private/var/mobile/Media/DCIM: Photos and Videos.
      • /private/var/mobile/Library/SMS: Text message databases (sms.db).
      • /private/var/containers: This is where third-party apps (WhatsApp, Facebook, TikTok) live. iOS uses "Sandboxing," meaning each app gets its own isolated folder within this directory.
      • /private/var/keychains: Stores the "Keychain" database, which holds saved Wi-Fi passwords, email credentials, and app tokens.

Note

We will dive deeper into both Android and iOS partitions in future, dedicated chapters!

5.6 Forensic Implications: The Encryption Barrier

The architecture described above leads to the single biggest challenge in modern mobile forensics: Hardware-Backed Encryption.

5.6.1 Full Disk Encryption (FDE) vs. File-Based Encryption (FBE)

  • FDE (Older Androids): The entire /data partition is encrypted with one key. If you have the key (Passcode), you have everything. This was an "all or nothing" approach.
  • FBE (Modern Android & iOS): Each file is encrypted with a unique key. This allows different files to have different security levels.
    • iOS Data Protection Classes: Apple assigns classes to files, which determines when they can be accessed.
      • Complete Protection: Data is encrypted 10 seconds after the device locks. The decryption key is wiped from RAM. (e.g., Health data, Emails).
      • After First Unlock (AFU): Once the user unlocks the phone once after a reboot, the encryption keys remain in RAM. This allows apps to run in the background (like receiving a WhatsApp message while the phone is in your pocket).

Real-World Scenario: The AFU vs. BFU State You arrive at a crime scene. A suspect's iPhone is lying on the table, powered on.

  • BFU (Before First Unlock): The phone was rebooted (or battery died and was charged) but the user has not entered their PIN yet. Most data is strictly encrypted. Forensic extraction will be very limited (mostly system metadata and perhaps some unencrypted cache).
  • AFU (After First Unlock): The user turned it on and entered the PIN at least once. The phone is now locked, but the keys are in RAM. A forensic tool attempting a "Hot Extraction" or an exploit might be able to pull significantly more data because the keys are accessible to the system.
  • Takeaway: This is why we stress keeping the device charged. If it dies and reboots, it drops from AFU to BFU, and you lose access to the keys in RAM.

5.6.2 Why "Chip-Off" is Dying

In the past (approx. 2010-2015), if a phone was smashed or water-damaged, forensics experts would desolder the memory chip (NAND) and read it in a specialized reader. This is called "Chip-Off."

Today, due to the Secure Enclave on iPhones and Trusted Execution Environment (TEE) on Android, the data on the memory chip is encrypted with keys that only exist on the main SoC. If you remove the memory chip, you leave the keys behind. The data you read will be random, encrypted gibberish. Chip-off is now mostly reserved for older "burner" phones, IoT devices, or drones that lack this advanced encryption architecture. If you encounter a modern iPhone 13 that is smashed, Chip-Off is not a viable option; the board must be repaired to boot the device and utilize the original encryption keys.

Note

We will still be covering advanced physical acquisition types and the concepts behind chip-off forensics in a later chapter. While it is not as relevent for mobile devices, it is still a useful method for other digital media devices.

5.7 Case Study: The "Checkm8" Breaking Point

Context: In a 2020 narcotics investigation, authorities seized an iPhone X belonging to a high-level distributor. The device was passcode locked (6-digit PIN). The suspect refused to provide the code.

The Challenge: The device was running a modern version of iOS. Traditional logical acquisition was impossible due to the lock, and the phone was in a BFU (Before First Unlock) state, meaning the encryption keys were not loaded in RAM.

The Architectural Vulnerability: The forensic lab utilized a tool leveraging the checkm8 exploit.

  1. Boot ROM Exploit: The examiner placed the device into DFU mode. The tool exploited the unpatchable vulnerability in the Boot ROM (the very first step of the boot process).
  2. Bypassing iBoot: By compromising the Chain of Trust early, the tool loaded a custom, unsigned RAMdisk into the phone's memory. This RAMdisk acted as a temporary operating system.
  3. Brute Force: While the user data was still encrypted, the custom RAMdisk allowed the forensic tool to communicate directly with the Secure Enclave (SEP) at a hardware level. The tool could then run a brute-force attack on the passcode much faster than manually typing it on the screen. Crucially, because they controlled the operating environment, they could prevent the phone from triggering a "data wipe" after 10 failed attempts.
  4. Result: The passcode was found in 4 hours. The phone was unlocked, and a Full File System extraction was performed.

Lesson: This case highlights that while software (iOS) can be updated, hardware (Boot ROM) is permanent. Understanding the boot chain allowed examiners to bypass the OS entirely and attack the hardware security directly.

Try out this simulation to understand how the checkm8 exploit worked on the boot ROM vulnerability.

5.8 Chapter Summary

The days of treating a mobile device like a USB drive are over. Modern mobile forensics requires a deep appreciation of computer architecture. We learned that mobile devices use SoCs which integrate components tightly, making physical interception difficult. We explored the Boot Process, a rigid "Chain of Trust" designed to stop tampering, but also the very mechanism forensic engineers attack to gain access.

We discussed how RAM is volatile (necessitating power preservation) and how NAND Flash uses wear leveling (complicating file carving). Finally, we distinguished between BFU and AFU states, emphasizing that the "state" of the encryption keys in the hardware is the most critical factor in how much evidence you can recover.

In the next chapter, we will take this theoretical knowledge of hardware and apply it to the practical methodologies of data acquisition.