Acquisition and Handling

This deck covers what an examiner must know about the phone hardware and its security before acquiring data. The theme: device state (unlocked, AFU, BFU) decides what you can extract.

Mobile Device ComponentsSearch on YouTubeBookmarkSaved

CasingSearch on YouTubeBookmarkSaved

• Knowledge of the casing is essential in case of chip-off.
• Apple controls both hardware and software for its devices (non-removable casing).
• Android devices come from many manufacturers, so they are more likely to have removable casings.

Display ScreenSearch on YouTubeBookmarkSaved

• If the device cannot keep power or cannot power on, the battery may need replacing. That needs the display screen removed.
• If the screen is faulty it must be replaced. Most forensic tools (Magnet AXIOM, Magnet GRAYKEY, Magnet VERAKEY, Cellebrite) need the examiner to respond to on-screen prompts during extraction.

Data Ports and Power Supply PortsSearch on YouTubeBookmarkSaved

• Identify which cables (USB Type A, Type B, micro USB, Type C) are needed for data extraction, or to keep the device powered after seizure.
• If the device is on, keep it charged so it does not shut down. This maximises the data that can be recovered.

SIM vs eSIMSearch on YouTubeBookmarkSaved

A SIM stores the phone number, security keys, and on older cards sometimes text messages and contacts. What it holds depends on the device, network provider and the SIM itself.

eSIM cards are digital SIMs bought online from network providers. They cannot be physically removed; they must be detached from the device in software.

• One device can have more than one phone number. Newer iPhones support up to eight eSIMs, but only two phone numbers at a time.
• Both SIM and eSIM contain an ICCID. The network provider uses it to identify each user and which network and country code they belong to.
• Do not confuse ICCID with IMEI (International Mobile Equipment Identifier). IMEI identifies the device, not the SIM.
• ICCID is usually 18 to 22 digits long. IMEI is around 15 digits.

SIM and BiometricsSearch on YouTubeBookmarkSaved

Why are SIM cards linked to biometric functions on some devices? In some mobile banking, government ID and biometric verification flows, a secure operation needs both biometrics and the SIM.

Example flow: the user starts a secure action (mobile payment, SIM-based OTP signing). The TEE asks for biometric authentication. On success, the TEE grants temporary access to the SIM. The SIM runs the cryptographic operation and returns the result.

Forensic consequences of removing the SIM:

• Some exploits become unavailable. For example, a biometric unlock with Magnet GRAYKEY will not work if the physical SIM was removed before imaging.
• If the device was seized unlocked or recently unlocked (AFU), biometrics may still bypass the lock screen without the passcode.
• The SIM's presence (with the correct PIN or registered network) is part of the trust chain for Face Unlock and Fingerprint Unlock.
• Removing the SIM can force a lock state change, which disables biometric unlock.
• It can trigger a reboot or require the passcode, so biometric bypass becomes impossible.
• On many devices biometric unlock is disabled after reboot until a passcode/PIN is entered, or the correct SIM is detected.

SD Card and Emulated SD CardsSearch on YouTubeBookmarkSaved

• SD cards can be removed and examined separately. But if device encryption is on, it also applies to the SD card. Examined alone, the card may appear empty. This can indicate that it is encrypted.
• In that case, examine the SD card inside the device, where it is unencrypted.
• Emulated SD cards partition the internal storage. They create a designated storage area on the device that acts as an SD card.

Logic BoardSearch on YouTubeBookmarkSaved

• Connects the other elements: volatile memory, GPU, CPU and cryptographic engines, so they can communicate.
• Without a working logic board the device cannot power on, cannot access RAM and internal memory, and cannot run even simple instructions such as launching apps.
• Recognising the logic board helps with advanced acquisition such as JTAG (Joint Test Action Group), where the examiner connects directly to the board to recover data.

Mobile Device MemorySearch on YouTubeBookmarkSaved

A phone has two built-in memory types:

• iOS process memory can recover snippets of web-related information, SMS or iMessage, and email. It is only available on supported AFU devices or a Full File System extraction.
• Android has a similar feature called Dumpsys, acquired in a Quick Image. Dumpsys is part of the live data and holds slightly different information from iOS process memory.
• Dumpsys can contain processor usage of running apps, Wi-Fi information, user information (number of users on the device), and battery status.
• Process memory or Dumpsys helps Incident Response: running processes reveal extra artifacts and device activity.

Dumpsys Use CasesSearch on YouTubeBookmarkSaved

adb shell dumpsys location            # last known location
adb shell dumpsys package com.example.app   # permissions of one app

Understanding EncryptionSearch on YouTubeBookmarkSaved

• With Android 5, Google tried to enable encryption by default on all devices. Devices with default encryption performed poorly.
• Google reversed the decision, and Android 5 shipped to most devices without default encryption.
• Every device shipped with Android 6 or higher has encryption by default.

Android Full-Disk Encryption (FDE)Search on YouTubeBookmarkSaved

• Implemented in Android 5.0. Based on dm-crypt.
• A 128/256-bit random key is generated when encryption is enabled.
• This key encrypts all user data partitions (/data).
• The master key is itself stored encrypted with a key derived from the user's PIN/password/pattern.
• If the passcode is not entered, the device does not fully boot. Alarms, SMS/MMS and calls do not work until the passcode is entered.

FDE forensic implications

• Acquired in BFU (Before First Unlock): /data is inaccessible; only encrypted blocks are visible.
• Acquired in AFU (After First Unlock): /data is decrypted in memory. Tools such as ADB, Magnet and UFED may get a decrypted file-system-level image.

File Based Encryption (FBE)Search on YouTubeBookmarkSaved

• Under FDE many system functions were unavailable until the lock code was entered. Android created Direct Boot to fix this.
• Direct Boot keeps some OS functions available after boot but before the user unlocks the handset.
• Google Pixel phones introduced FBE in 2016. It is available on many devices running Android 7 or higher.
• FBE encrypts each individual file and file path, not the whole memory container.
• Each user has two storage locations:

• Several folders are duplicated with a _ce or _de suffix. The suffix shows at which point of startup and authentication the area is decrypted.
• Examiners can extract data from _de areas without the passcode.

FBE forensic implications

• At boot (BFU): only DE data is available. This is very limited: system logs, alarms, notifications, some messages.
• After unlock (AFU): DE and CE data are both accessible.
• In BFU the investigator may get only partial data. In AFU richer acquisition is possible, but it still needs privilege escalation/root or vendor exploits (GrayKey, Cellebrite, Magnet AXIOM).
• Reboots hurt investigations more. A reboot returns the device to BFU, and much CE data becomes inaccessible without the PIN.

Why Chip-off No Longer WorksSearch on YouTubeBookmarkSaved

Both iOS and Android now use file-based encryption. Files are decrypted only after certain conditions are met during boot. So chip-off is no longer viable. Why:

• Each file is encrypted with its own File Encryption Key (FEK).
• FEKs are protected by higher-level keys derived from the user's PIN/password and a hardware-bound secret stored in the TEE.
• The hardware secret never leaves the TEE and is not stored in NAND. A chip read off the board has only ciphertext.

In older versions, Android fragmentation allowed exploits giving direct memory access through EDL (Emergency Download Mode) or similar built-in modes. Since FBE in Android 7, these are less useful.

Security Features that Block Physical ImagingSearch on YouTubeBookmarkSaved

Secure boot, FRP locks, locked bootloaders and tamper-resistant chips all reduce the examiner's ability to get physical memory images.

Secure BootSearch on YouTubeBookmarkSaved

• What it does: verifies the integrity and authenticity of the bootloader and OS using cryptographic signatures.
• Impact on forensics: prevents booting into custom recovery or forensic tools (for example custom recovery images for memory acquisition). Any unauthorised change to boot components halts the boot, so examiners cannot load memory acquisition tools.

Factory Reset Protection (FRP)Search on YouTubeBookmarkSaved

• Prevents unauthorised access after a factory reset unless the original Google account credentials are used.
• Designed to stop a stolen or lost phone from being wiped and reused without the owner's permission.

Locked BootloadersSearch on YouTubeBookmarkSaved

• What it does: stops unauthorised firmware, custom ROMs or recovery tools from being flashed.
• Impact on forensics: blocks custom kernels or acquisition tools (such as TWRP or custom ADB images) needed for physical extraction. Unlocking the bootloader often wipes user data, which destroys the evidence.
• Rooting is harder: rooting needs a bootloader unlock, which wipes the device.
• If the phone is already unlocked and has a custom recovery (TWRP), flashing Magisk through recovery does not wipe data. So you can root without data loss only if the bootloader is already unlocked.

How to Check if the Bootloader is UnlockedSearch on YouTubeBookmarkSaved

Reboot into fastboot/bootloader mode (common keys: Power + Volume Down, varies by OEM), connect over USB and run:

fastboot oem device-info
# or
fastboot getvar unlocked
fastboot getvar all

Typical output:

(bootloader) Device unlocked: true     <- bootloader unlocked
(bootloader) Device unlocked: false    <- bootloader locked

From a running device, use the ADB shell:

adb shell getprop ro.boot.flash.locked          # 1 = locked, 0 = unlocked
adb shell getprop ro.boot.verifiedbootstate

• Many devices show a "Bootloader Unlocked" warning at boot (yellow/orange screen).
• Example, Pixel: "The bootloader is unlocked and software integrity cannot be guaranteed."

Tamper-Resistant Chips, Secure Enclave, TEESearch on YouTubeBookmarkSaved

• TEE (Trusted Execution Environment) / Secure Enclave: stores sensitive keys and enforces hardware-backed security policies.
• Memory encryption keys are stored in the TEE or Secure Enclave and are not accessible by physical means.
• Even if RAM is dumped, the key material is inaccessible, so the data stays unreadable.
• No more direct RAM access: modern Android does not allow full access to /dev/mem or physical RAM without root.

Summary of Acquisition, Handling and EncryptionSearch on YouTubeBookmarkSaved

The deck's own summary list:

• Investigator preparation
• Device handling considerations by first responders
• Effect of hashes: PC vs mobile forensics
• FDE vs FBE: CE and DE
• TEE and Secure Enclave
• Actively unlocked, AFU and BFU states
• Consequences of rebooting or removing the SIM
• Effect of secure boot, bootloader state and rooting the device

Types of Forensic ImagesSearch on YouTubeBookmarkSaved

The deck's figure groups image types as nested boxes:

• With file-based encryption, physical images are not acquired nearly as often.
• Examiners now target a true "logical" image: a full file system image of all active files on the device.
• A full file system needs elevated permissions or root. Often an exploit must be found and used.
• Developers keep patching these exploits. This creates a constant "cat and mouse" game between analysts and devices.

File Storage Types in MobileSearch on YouTubeBookmarkSaved

• SQLite databases are the common storage container: SMS/MMS records, web history, contacts, call logs and third-party app data.
• iOS also uses plist (property list) files, mostly for preference data across the file system. There are XML-encoded plists (human readable) and binary plists (compact and efficient, not easily readable).
• Android uses XML or JSON files instead of plists. Both are human-readable text and can hold a lot of preference data.

Deleted Data in ImagesSearch on YouTubeBookmarkSaved

• A full file system image does not always recover deleted files, only deleted records (metadata).
• SQLite databases can return deleted records, but only if the parsing tool knows how the data is structured and what to look for.
• Deleted pictures or videos are unlikely to be recovered from a file system image alone.
• In targeted or "quick" images, most tools query only active information in the database. Deleted information may still be on the device but not in the returned image.

Logical vs Full File System in AXIOMSearch on YouTubeBookmarkSaved

• A Logical Image in AXIOM Process is a true logical extraction: it obtains all available files and folders.
• Full or logical extraction is only available when the device has privileged access (rooted or jailbroken).
• For a PIN-locked Android or iOS device, Magnet GRAYKEY or Magnet VERAKEY can deploy advanced tactics to acquire various levels of data, including a Full File System extraction.
• Full File System extractions hold far more: location data, third-party app data, and user activity including health data.

Quick self-testSearch on YouTubeBookmarkSaved