CH6: Acquisition Methodologies

Learning Objectives

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

Differentiate between the four primary levels of mobile data acquisition: Manual, Logical, File System, and Physical.
Analyze the "Mobile Forensics Pyramid" to understand the trade-offs between extraction complexity, data volume, and forensic risk.
Explain why traditional hardware write-blockers cannot be used with modern mobile devices and identify alternative methods for maintaining data integrity.
Execute proper pre-acquisition assessment protocols, including device state analysis, power management, and physical inspection.

6.1 Introduction to Mobile Acquisition

In traditional computer forensics—dealing with laptop hard drives or USB thumb drives—the acquisition process is relatively standardized. You remove the drive, connect it to a hardware write-blocker to prevent any data alteration, and create a bit-for-bit forensic image (a physical copy).

Mobile forensics is different.

Because mobile devices are proprietary, embedded systems with integrated storage and volatile memory, we generally cannot remove the storage chip to image it separately without destroying the device (a technique known as "Chip-Off," which we will discuss in Chapter 14). Furthermore, modern mobile operating systems (iOS and Android) are designed to aggressively protect user data through encryption. They do not simply "surrender" their data to a forensic tool; the tool must communicate with the operating system to request the data.

Therefore, Mobile Acquisition is defined as the process of extracting data from a mobile device by interacting with its hardware and software interfaces.

The Mobile Forensics Hierarchy (The Pyramid)

To understand how we get data, forensic examiners often visualize acquisition methods as a pyramid. As you move up the pyramid, the methods become more technically complex and invasive, but they also yield significantly more data (including deleted data).

Manual Extraction (Base): Simply looking at the screen and taking pictures. It yields the least data (only what is visible) but is universally compatible.
Logical Extraction: Communication via standard APIs (like iTunes or Android Debug Bridge). This recovers "active" data (files that the user can see), such as SMS, contacts, and photos. It rarely recovers deleted data.
File System Extraction (Advanced Logical): This is the modern industry standard. It leverages vulnerabilities or agent-based exploits to gain access to the file system (databases, logs, application usage). It recovers significantly more data than a standard logical extraction, including some deleted artifacts stored in database "free pages."
Physical Extraction (Peak): A bit-by-bit copy of the flash memory. This is the "Holy Grail" of forensics because it allows for the carving of deleted data from unallocated space. However, due to modern Full Disk Encryption (FDE) and File-Based Encryption (FBE), true physical extractions are becoming increasingly rare and difficult to decrypt on consumer devices.

The "Forensically Sound" Paradox

In Chapter 1, we discussed the importance of validation and forensic soundness. In the context of mobile acquisition, we must accept a hard truth: interacting with a mobile device will alter it.

When you connect a phone to a forensic workstation:

The battery begins to charge (altering system logs).
The data port becomes active (triggering USB events).
The forensic software may push a temporary application (an "agent") to the phone to facilitate data transfer.

Because we cannot leave the device "untouched," our definition of forensically sound in mobile forensics shifts. It means that any changes made to the device must be minimal, necessary for the extraction, and documented.

6.2 Pre-Acquisition Considerations

Before you ever plug a suspect device into your forensic workstation, you must perform a thorough pre-acquisition assessment. Rushing this stage is the leading cause of failed extractions and damaged evidence.

The "Write-Blocker" Issue

One of the first questions students ask is, "Why don't we just use a USB write-blocker?"

A hardware write-blocker works by physically preventing a computer from sending "write" commands to a storage drive. However, mobile phones are not passive storage drives; they are active computers. To get data off them, a "conversation" must happen between the forensic tool and the phone.

The Request: "Hello Android, please send me the SMS database."
The Response: "Here is the database."

If you were to place a write-blocker between the phone and the computer, you would block the "Request," and the extraction would fail immediately. Therefore, we rely on software-based write protection (ensuring our tools are configured not to write unnecessary data) and strictly documented procedures.

Device Assessment Checklist

Follow this protocol for every device prior to acquisition:

1. Physical Inspection

Damage: Is the screen cracked? Is the chassis bent?
Ports: Check the charging port for lint, debris, or damage. A dirty port is the most common reason for connectivity failure. Use a non-conductive probe (like a wooden toothpick or plastic spudger) to gently clean the port if necessary.
Biohazards: If the device was recovered from a crime scene (e.g., found on a body or in a substance), ensure it has been sanitized according to laboratory safety protocols before handling.

2. Power State Management

If the device is OFF: Leave it OFF. Powering on a device moves it from a "Before First Unlock" (BFU) state to an "After First Unlock" (AFU) state, but it also triggers boot sequences that may enable security timers or wipe commands if the device is managed by a hostile MDM (Mobile Device Management) profile.
If the device is ON: Keep it ON. If a modern smartphone powers down, it reverts to a high-security BFU state where almost all user data is encrypted. You may never get back in.
- Action: Immediately connect the device to a portable power bank or a forensic workstation to maintain charge.
- Action: Enable "Stay Awake" settings if you have access to the UI, to prevent the screen from locking.

3. Signal Isolation

As discussed in Chapter 2, a device connected to a cellular or Wi-Fi network is vulnerable to remote wiping commands.

Airplane Mode: If you have access to the device interface, enable Airplane Mode immediately. Ensure Wi-Fi and Bluetooth are actively toggled off (don't just rely on the Control Center shortcut; check the actual Settings menu).
Faraday Isolation: If you cannot access the settings (device is locked), the device must remain in a Faraday bag or a shielded enclosure during the acquisition process. Note that acquisition inside a Faraday bag requires a specialized bag with a shielded USB pass-through window so you can connect the cable without breaking the shield.

4. Peripheral & Storage Check

SIM Card: Is a SIM card present? This is crucial for attributing the phone number to the device. (Refer to Chapter 4 regarding SIM processing).
External Storage: Does the device have a microSD slot? If so, forensic best practice usually dictates removing the microSD card (if accessible) and imaging it separately using a standard hardware write-blocker. This preserves the integrity of the card and often speeds up the acquisition of the main handset.

Connectivity and Trust

For a forensic tool to communicate with a phone, the phone must "Trust" the workstation.

iOS: When plugging an iPhone into a new computer, a prompt asks "Trust This Computer?" You must have the passcode to tap "Trust" and enable data transfer.
Android: You must enable "USB Debugging" within the Developer Options menu.

If the device is screen-locked and you do not have the passcode, your acquisition options will be severely limited (likely restricted to a physical recovery mode exploit or a manual external view), which we will cover in the "Tools" section.

6.3 Manual Acquisition

Manual Acquisition—often referred to as "manual extraction" or "manual scrolling"—is the most straightforward yet time-consuming method of capturing data. It involves the examiner physically interacting with the device’s touchscreen or keypad to view content and documenting that content using an external camera or video recorder.

While it sits at the bottom of the "Mobile Forensics Pyramid" in terms of technical sophistication, do not underestimate its value. In many cases, it may be the only method available.

Methodology

The process is simple but rigorous:

Setup: Place the device on a specialized photography stand or a stable surface with non-glare lighting.
Capture: Systematically open relevant applications (Messages, Photos, Call Logs).
Document: Photograph every screen. If a conversation scrolls for 50 pages, you take 50 overlapping photos.
Video: For dynamic content (like a video playing on the phone or a scrolling timeline), use a video camera to record the screen interaction.
Transcription: In some legal contexts, you may be required to manually type out the contents of text messages into a spreadsheet to make them searchable.

When to Use Manual Acquisition

Unsupported Devices: The device is too new, too old (e.g., a burner phone from 2005), or too obscure for commercial tools to recognize.
Damaged Data Ports: The USB port is physically broken, preventing a cable connection, but the screen still works.
Security Restrictions: The device is locked, USB debugging is disabled, and no exploit exists, but the user consents to show you a specific thread of messages.
Validation: You use manual acquisition to verify that the tool-generated report matches what the user actually saw on the screen.

Pros and Cons

Pros	Cons
Universally Compatible: Works on any device with a functioning screen.	Extremely Slow: Can take days for a single device with heavy usage.
Admissible: Courts easily understand "I took a picture of what I saw."	High Human Error: Easy to miss a message or scroll past evidence.
No Technical Exploits: No risk of "bricking" the device with invasive software.	No Deleted Data: You only see what the user sees (Active Data).
Visual Context: Captures exactly how the data appeared to the user.	Unsearchable: Photos of text are not text-searchable without OCR (Optical Character Recognition).

6.4 Logical Acquisition

Logical Acquisition is the process of extracting active data from a device by interacting with the operating system using standard manufacturer protocols.

Think of this as asking the phone politely for its data. The forensic tool (such as Cellebrite UFED or Magnet AXIOM) acts as a "manager," instructing the phone to perform a backup of its content and sending that backup to the examiner's workstation.

How It Works

iOS (iTunes Protocol): On an iPhone, a logical extraction is essentially an iTunes backup. The tool initiates the backup service, and the phone zips up its databases and files into a backup package.
Android (ADB Backup): On Android, the tool utilizes the Android Debug Bridge (ADB). It sends a command (e.g., adb backup) to the device, which triggers the OS to package user data and send it over the USB cable.

The "Active" Requirement

Crucially, a logical extraction requires the device to be unlocked and the computer to be trusted. If the phone is passcode-locked and you cannot bypass it, you generally cannot perform a logical extraction because the OS will refuse the connection.

Data Types Recovered

Logical extractions typically recover Active Data—the data currently existing and accessible on the file system. This includes:

Call Logs
SMS/MMS Messages
Contacts
Photos and Videos (stored in standard galleries)
Audio recordings
Installed App lists

Limitations

The major limitation of logical acquisition is its inability to access the "root" of the file system or "unallocated space."

No Deleted Data: Because you are asking the OS for existing files, it will not send you deleted files.
Sandboxing: Mobile OSs "sandbox" applications, meaning one app cannot see another app's data. A standard logical backup often misses data from third-party apps (like WhatsApp, Signal, or Telegram) unless that app specifically allows its data to be backed up.

6.5 File System Acquisition (Advanced Logical)

As mobile security has improved, the gap between "Logical" and "Physical" extractions has widened. To fill this gap, the forensic industry developed File System Acquisition, often called Advanced Logical or Full File System (FFS) extraction.

This is currently the "Sweet Spot" for modern mobile forensics. It offers the best balance of data recovery and success rate on encrypted devices.

Methodology: The "Agent" Approach

Unlike a standard logical extraction that asks the OS for a backup, a File System extraction often uses a temporary exploit or a helper application known as a Forensic Agent.

Injection: The forensic tool pushes a small, privileged application (the Agent) onto the device.
Escalation: The Agent exploits a vulnerability (or uses administrator privileges) to gain wider access than a standard app.
Extraction: The Agent bypasses the "sandboxing" rules, reading the raw database files of other apps and system logs.
Cleanup: Once the data is copied, the Agent is uninstalled from the device.

Why It Is Superior to Logical

While a Logical extraction gives you the content of a text message, a File System extraction gives you the database file (e.g., sms.db or mmssms.db) that holds that message.

Accessing the raw database files allows for:

"Free Page" Recovery: Even without a physical dump, SQLite databases (which phones use for almost everything) often retain deleted records in "free pages" or "WAL (Write Ahead Log)" files until they are overwritten. A File System extraction captures these files, allowing tools to carve out deleted SMS or chat logs.
Third-Party App Data: This method is excellent for retrieving data from encrypted apps like WhatsApp, Signal, or Facebook Messenger, provided the keystore (encryption keys) can be extracted alongside the database.
System Logs: It recovers deep system artifacts like "KnowledgeC" (iOS) or "UsageStats" (Android), which track exactly when apps were opened and for how long—critical for proving user activity.

Note

We will cover SQLite databases in depth in Chapter 8, and App Artifacts in more depth in Chapter 12!

Summary Table: Logical vs. File System

Feature	Logical Extraction	File System Extraction
Method	Standard Backup API	Agent / Exploit / Root Access
Access Level	User-accessible files	Full directory structure
Deleted Data	Rare / None	Moderate (Database carving)
App Data	Limited to backup-enabled apps	Comprehensive (Sandbox bypass)
Risk	Low	Moderate (Temporary changes to device)

6.6 Physical Acquisition

Physical Acquisition is the most comprehensive extraction method available in mobile forensics. It involves creating a bit-by-bit copy of the device's entire physical storage (flash memory).

Unlike Logical or File System extractions, which rely on the operating system to hand over files, a Physical extraction attempts to read the raw binary data directly from the storage chip.

The "Holy Grail": Unallocated Space

The primary reason forensic examiners pursue physical extraction is to access Unallocated Space.

When a user deletes a file (like a photo or a text message), the operating system does not immediately scrub the data from the memory chip. Instead, it simply marks that storage space as "available" (unallocated) for future use. Until that space is overwritten by new data, the old data remains intact.

Physical Extraction: Reads everything, including these "deleted" bytes.
Logical/File System: Generally ignores unallocated space because the OS doesn't "see" files there anymore.

The Modern Challenge: Encryption

While physical extraction was the standard for feature phones and early smartphones (like the iPhone 3G or early Androids), it has effectively hit a wall with modern devices due to Full Disk Encryption (FDE) and File-Based Encryption (FBE).

The Problem: Even if you successfully copy every bit of the flash memory, the data is encrypted. Without the decryption key (which is often tied to the user's passcode and a hardware-backed security chip like the Apple Secure Enclave or Android Titan M), the physical image is just a collection of random, unreadable noise.
The Result: On modern devices (iPhone 5s and newer; Android 6.0 and newer), a "Physical" extraction is often impossible or yields encrypted gibberish unless you have a high-level exploit (like a bootrom exploit) that can decrypt the data on the fly.

Legacy Methods: JTAG and Chip-Off

For older phones, damaged devices, or IoT devices (like smartwatches or drones) that do not use high-level encryption, we still utilize advanced hardware-based physical acquisition methods.

JTAG (Joint Test Action Group): Connecting to standard test points on the device's circuit board to instruct the processor to transfer raw data.
Chip-Off: Physically unsoldering the flash memory chip from the motherboard and reading it in a specialized card reader. (Note: These advanced methods will be covered in detail in Chapter 14).

6.7 Tools of the Trade

Mobile forensics requires a "Swiss Army Knife" approach. Relying on a single tool is a recipe for failure, as no single tool supports every device or app version. We categorize these tools into Commercial (paid, proprietary) and Open Source (free, community-driven).

Commercial Forensic Suites

These are the heavy hitters used by law enforcement and enterprise labs. They handle the complex work of exploiting security vulnerabilities, parsing thousands of app versions, and generating court-ready reports.

Cellebrite UFED (Universal Forensic Extraction Device): widely considered the industry standard for mobile data extraction. It supports the widest range of devices and is famous for its physical extraction capabilities.
Magnet AXIOM / GrayKey: AXIOM is renowned for its analysis capabilities (making sense of the data), while GrayKey (now part of Magnet) is the premier tool for bypassing passcodes on locked iOS and modern Android devices.
MSAB XRY: A powerful European-based suite known for its highly secure "forensic container" file format (.xry) which ensures evidence integrity.

Open Source & Command Line Tools

When commercial tools fail—or when you need to validate a finding—you turn to the command line. These tools are the backbone of many commercial suites and allow you to interact directly with the device's diagnostic protocols.

1. Android Debug Bridge (ADB)

ADB is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run commands on the device.

Examiner's Cheat Sheet: Common ADB Commands

Command	Description	Forensic Use Case
`adb devices`	Lists all connected devices and their status.	Triage: Verifies the workstation "sees" the phone and checks if USB debugging is authorized.
`adb shell`	Opens a remote interactive shell on the device.	Exploration: Allows you to navigate the file system manually (`ls`, `cd`, `cat`) to look for evidence.
`adb backup -all -f evidence.ab`	Creates a full backup of app data to a file named 'evidence.ab'.	Acquisition: The primary method for performing a logical extraction of an Android device.
`adb pull <remote> <local>`	Copies a specific file or folder from the device to your computer.	Targeted Collection: "Pulling" a specific video file or database without imaging the whole phone.
`adb logcat -d > log.txt`	Dumps the current system logs to a text file.	Live Analysis: capturing volatile data about what apps are running right now.
`adb install <file.apk>`	Pushes and installs an Android application package (.apk).	Agent Deployment: Used to install forensic agent apps (like those used by Cellebrite) manually.
`adb shell getprop ro.product.model`	Returns the device model name.	Identification: Confirming exactly what device you are holding.

2. libimobiledevice (iOS)

While Apple keeps its ecosystem closed, the open-source community created libimobiledevice—a cross-platform protocol library that communicates natively with iOS devices. It is what allows Linux and Windows machines to talk to iPhones without iTunes.

Examiner's Cheat Sheet: Common libimobiledevice Commands

Command	Description	Forensic Use Case
`idevice_id -l`	Lists the UDID (Unique Device Identifier) of attached devices.	Identification: Obtaining the unique 40-character hex string needed for warrants and reports.
`ideviceinfo`	Dumps detailed device information (Serial, IMEI, iOS version, WiFi Mac).	Triage: Gathering all technical specs of the device instantly for your notes.
`idevicesyslog`	Relays the system log (syslog) to the screen in real-time.	Troubleshooting: Watching the phone "think" to see if it is rejecting your connection or throwing errors.
`idevicebackup2 backup <path>`	Initiates a standard iTunes-style backup to a specific folder.	Acquisition: Performing a forensic logical acquisition of an iPhone without using iTunes.
`ideviceinstaller -l`	Lists all applications installed on the device.	Triage: Quickly determining if the suspect has specific apps (e.g., Signal, Telegram) installed.
`ideviceimagemounter <image>`	Mounts a developer disk image.	Advanced: Required to enable certain debugging features on the iPhone for deeper analysis.

Activity

Try out this hands-on, simulated activity to get an understanding of how both adb and libimobiledevice is used at the command line level.

Community Analysis Tools

Once you have the data (via ADB or backup), you need to parse it.

iLEAPP / ALEAPP: (iOS/Android Logs, Events, And Plist Parser). These are Python-based scripts developed by the forensic community (specifically Alexis Brignoni and Yogesh Khatri). They are excellent for parsing extractions and finding artifacts that expensive commercial tools might miss.
LEAPP Acronym = Logs Events And Protobuf Parser

The LEAPP Framework

iLEAPP: iOS Logs, Events, And Plist Parser
ALEAPP: Android Logs, Events, And Protobuf Parser

How They Work

Unlike acquisition tools (which get the data off the phone), LEAPP tools are parsers. They take the data you have already acquired—such as a .zip file from a Logical extraction, a .tar file from a File System extraction, or a raw folder of files—and they "leap" through the data to find specific artifacts.

They generate a lightweight, easy-to-read HTML Report that organizes the evidence into categories like "Chat," "Location," "Installed Apps," and "Device Events."

Note

We will be utilizing ALEAPP extensively in Chapter 9 (Android Forensics). You will have the opportunity to load real Android data dumps into the tool and generate your own forensic reports to analyze user activity.

Validation

A critical reminder: Tools make mistakes. A commercial tool might misinterpret a timestamp or fail to parse a new version of WhatsApp.

Cross-Tool Validation: If Tool A says the suspect was at Location X, try to verify it with Tool B.
Manual Verification: If Tool A says a text message exists, use the Manual Acquisition method (photography) or the raw database view (SQLite browsing) to confirm it is actually there.

6.8 Case Study: The "Gap" in the Evidence

To truly understand the difference between acquisition methods, let’s look at a realistic scenario involving a narcotics investigation.

The Scenario Law enforcement arrests a suspect, "Subject A," believed to be a mid-level distributor in a narcotics ring. During the arrest, officers seize an iPhone 11 that is powered on and unlocked (AFU state). Subject A claims he is merely a user and denies any involvement in distribution.

Attempt 1: The Logical Extraction The initial responder performs a standard Logical Extraction (iTunes-style backup) using a commercial forensic tool.

The Result: The report shows standard SMS text messages to his mother and a few friends. There are no incriminating photos in the Camera Roll. The "Installed Applications" list shows that WhatsApp and Signal are installed, but the report contains zero messages from these apps.
The Conclusion: Based only on this extraction, the evidence supports Subject A's claim. There is no proof of distribution.

The "Gap" The investigator knows from surveillance that Subject A uses WhatsApp. Why didn't the data show up?

Reason: The Logical extraction relied on the backup protocol. The WhatsApp application developer had flagged their data as "excluded from backup" for security reasons. The tool politely asked for the data, and the OS politely refused.

Attempt 2: The Full File System Extraction The device is sent to the digital forensics lab. The examiner identifies a vulnerability that allows for a Full File System (FFS) extraction. They deploy a forensic agent to the device.

The Process: The agent exploits the OS kernel to bypass the "sandbox." It locates the private directory for WhatsApp: /private/var/mobile/Containers/Shared/AppGroup/group.net.whatsapp.WhatsApp.shared/ChatStorage.sqlite.
The Result: The tool extracts the raw ChatStorage.sqlite database. Inside, the examiner finds thousands of messages coordinating drug deliveries, photos of tracking numbers, and contacts stored only within WhatsApp, not in the phone's main address book.
The "Deleted" Bonus: Because the examiner has the raw SQLite database file, they use a tool to parse the "Free Pages" (unallocated space inside the database file). They recover 50 messages that Subject A had deleted two days prior to the arrest.

The Outcome The File System extraction provided the nexus required to charge Subject A with distribution. The Logical extraction, while faster, missed 90% of the relevant evidence because it could not bypass the application sandbox.

This case illustrates why relying solely on "what the phone gives you" (Logical) can be dangerous in modern investigations.

6.9 Chapter Summary & Key Takeaways

Mobile acquisition is no longer a "push-button" science. It is a complex decision-making process that balances the need for data against the limitations of modern security and the risks of evidence alteration.

We have moved away from the days when a "Physical Extraction" was guaranteed. Today, the Full File System (FFS) extraction is often the highest level of access available on consumer devices, serving as the industry standard for securing third-party app data and system logs.

As you prepare for your field work, remember that the tool is only as good as the examiner using it. A forensic report is an unbiased interpretation of data. It is your job to validate that data, understand where it came from (the file system), and explain it clearly to the court.

Key Takeaways

The Hierarchy of Extraction:
- Manual: What you see (Screenshots). Good for validation.
- Logical: What the OS allows (Backups). Good for active data like SMS/Contacts.
- File System: What the OS has (Databases/Logs). The modern standard for apps and some deleted data.
- Physical: What the chip holds (Raw Memory). The "Holy Grail" for unallocated space, but rare on modern encrypted phones.
Forensic Soundness: Unlike computer forensics, mobile forensics requires interaction with the device. "Soundness" means making the minimum necessary changes and documenting them thoroughly.
The Pre-Acquisition Ritual: Always assess power, isolate the signal (Faraday/Airplane Mode), and check for physical damage before connecting a cable.
Don't Trust One Tool: Commercial tools (Cellebrite, Magnet) are excellent but fallible. Always validate findings with a secondary method or open-source tools like ADB, iLEAPP, or ALEAPP.
The Encryption Barrier: We cannot simply "image" a modern phone's chip and expect to see data. We must use exploits or agents to decrypt the data in real-time during extraction.

Next Step

In Chapter 7, we will explore Timestamps and File Carving. You have learned how to get the data; now you must learn when it was created and how to recover the pieces that the user tried to destroy.