Extraction Types Logical • File System • Full File System • Physical • AFU/BFU

Cell Phone Forensic Extraction Types (What They Mean, What They Usually Contain, and Why Access Varies)

“Extraction type” is a shorthand for how data is collected from a phone and what level of access the examiner had at the time. Modern iOS and Android devices use strong encryption and security states that can dramatically change what is available. For the broad foundation first, start here: What is Cell Phone Forensics and How Does It Work?

Where this fits in your learning path

This page is an educational glossary-style deep dive on extraction categories and device states. If you want the complete “start-to-finish” service overview of how mobile work is scoped, acquired, analyzed, and reported, see our main hub: Cell Phone Forensics. If you want a broader tool-and-vendor overview (and why different tools label “the same thing” differently), see: Cell Phone Forensic Tools & Software.

Key principle: The most accurate way to describe an extraction is not the marketing label, but the data categories actually obtained and the device state at the time of collection.

Extraction types at a glance

These labels are commonly used across mobile forensic tooling. Exact contents vary by device, OS version, encryption state, and method.

Logical extraction

A logical extraction generally means the examiner collected user-level data that the operating system (or a supported API) will provide. This is often the most “compatible” method, but also the most limited.

Commonly includes: contacts, call history, messages (varies), media (varies), app data where exposed
Often excludes: many system logs, deeper app containers, and protected databases
Best use: quick triage, basic timelines, corroboration, and cases where deeper access is not possible

File system extraction

A file system extraction generally means broader access to the device’s file hierarchy (including more app containers and system artifacts), subject to encryption and lock state.

Commonly includes: more app databases, more configuration files, additional OS artifacts
May include: SQLite companion files (WAL/SHM), richer timeline artifacts, some logs (retention varies)
Key variable: whether credential-protected data was available at the time of collection

Full file system extraction (often the “best practical” tier)

“Full file system” is often used to describe the most complete practical collection that modern tools can obtain on many devices—especially newer phones— when lawful access conditions exist (most commonly, the device can be unlocked).

Often yields: broad app containers + system artifacts, richer databases, more timeline-relevant files
Commonly requires: device passcode/unlock cooperation and compatible methods
Why it matters: analysis quality improves when app databases, companion files, and system context can be correlated

In many modern cases, “full file system” is the de facto target because traditional “raw physical” access is frequently blocked by encryption and security controls.

Physical extraction (what it historically meant vs modern reality)

Historically, a “physical” extraction referred to low-level access (often described as a bit-for-bit image of storage). On modern, encrypted devices, that concept is frequently not attainable in a meaningful way without specialized conditions.

Older devices: physical methods were sometimes more feasible
Modern devices: hardware-backed encryption often prevents readable “raw” acquisition
Practical focus: full file system / advanced access methods when lawful and supported

AFU vs BFU (device states that change what you can extract)

Many misunderstandings about mobile forensics come from ignoring device state. Two phones can be the same model and OS, but yield different results depending on whether the device has been unlocked since boot.

BFU (Before First Unlock): the phone has booted but has not been unlocked with the passcode since that boot. Many credential-protected keys and files remain unavailable.
AFU (After First Unlock): the phone has been unlocked at least once since boot. More decryption keys may be in memory or available to services, enabling broader access.
Why AFU is preferred: AFU commonly enables access to a larger evidence set (especially protected app data) and produces more complete timelines.

Examiner best practice is to document the observed lock state and clearly describe how that state impacts the completeness of the extraction.

What each extraction tier usually enables (high-level evidence categories)

More likely with logical

Basic user data (contacts, call records, some messages depending on OS/app)
Media files that are exposed or user-exportable
Some app-level content when apps expose exportable datasets

Logical is often sufficient for narrow questions, but it can be incomplete for disputes that require deep validation or app-level timelines.

More likely with file system / full file system (AFU preferred)

Richer app databases (SQLite) and companion files (WAL/SHM) used for timeline reconstruction
More system configuration context (accounts, permissions, profiles/policies where applicable)
More “behavioral” artifacts: app usage context, connectivity context, and state indicators (availability varies)

This tier generally enables stronger cross-validation: app records + system context + timestamps can be reconciled and explained.

Checkm8 (why older iPhones can sometimes allow deeper access)

checkm8 is a bootrom-level exploit affecting certain older Apple devices (chip generations A5 through A11). Because it exists in hardware bootrom, it is often described as “unpatchable” on those devices. In forensic contexts, checkm8-derived techniques can sometimes enable enhanced acquisition pathways on eligible devices—though results still depend on the device’s security configuration and the method used.

Supported device families (conceptual)

Commonly described as: Apple A5–A11 devices
Practical shorthand: iPhone 4S through iPhone X era (device-specific)
Not applicable to newer iPhones with later chips

Important: “Eligible for checkm8” does not automatically mean “full physical image is possible.” Encryption and lock state still govern what is readable.

Supported iOS versions (tool-dependent)

The iOS version range that a checkm8-based acquisition supports is not a single universal number—it depends on the specific toolchain and method. Some forensic tooling advertises checkm8-based extraction coverage for select devices across a wide range of iOS versions, while jailbreak tooling has its own version constraints.

Forensic tool support varies by vendor and device subset
Jailbreak support ranges are often narrower and change over time
Best practice: document the exact method used and the access it actually granted

If you want the broader mobile forensic “tool ecosystem” and what common labels mean in reports, see: cell phone forensic tools and software.

Why “physical extraction” is uncommon on newer phones (and what replaces it)

Modern iOS and Android devices use hardware-backed encryption and security controls designed to prevent low-level acquisition from yielding readable data. In many cases, the most defensible and useful approach is a full file system extraction (when lawful access is possible) paired with careful artifact analysis.

Encryption reality: raw storage access does not automatically produce readable user data without decryption keys.
Lock state matters: AFU is usually preferred because more protected evidence becomes available after unlock.
Deleted data expectations: modern encryption + flash storage behavior often makes “recover everything deleted” unrealistic—especially on newer devices.
Better approach: correlate available app databases, companion files, system context, and lawful account/provider records where applicable.

For a full overview of how these choices are applied in real investigations, see: cell phone forensics services.