How to read this
- Entry type
- Evidence review
- Sources verified
- 6 September 2026
- Evidence classes
- specification, marketing, company statement, government
This entry reviews evidence published by other people. DEVI did not test any tool or examine any device for it. Blocks marked with an evidence class quote or summarize a source; sentences beginning “we” describe what DEVI did with those sources, which was to read them. Anything DEVI could not confirm is marked as such and left as an open question rather than written up as a finding. Sources change without notice, which is why the verification date is stated.
"Full file system supported" and "access to locked devices" sound like answers to the same question. They are answers to two different questions, and an extraction capability is only described once both have been answered.
This entry is about how to read that sentence. On 6 September 2026 we read five vendors' current public documentation and quote what those pages say: Oxygen Forensics' device extraction methods, Belkasoft's mobile device acquisition page, Elcomsoft's iOS Forensic Toolkit page, Cellebrite's Premium page, and Magnet's Graykey page. Every quotation below links to the page it came from. We did not test any tool.
The two questions inside one claim
Depth asks how much data a method returns. Contacts and messages, or app databases, or the keychain and system logs as well.
State asks what condition the device has to be in for that method to run at all. Powered on and unlocked, rebooted and never unlocked, or locked with a passcode nobody has.
Neither answer constrains the other. A method can be very deep and require a cooperative device. A method can work against a locked device and return a thin slice. "Full file system" with no state attached, and "locked device access" with no depth attached, are both half of a sentence.
The clearest demonstration of that is a vendor listing the same method twice.
The same method, two states, two depths
Oxygen Forensics organizes its public extraction-methods page by device state first: locked Android, unlocked Android, locked iOS, unlocked iOS. Its checkm8 entry appears under both iOS headings, with the same device list and a different result.
Same vendor, same exploit, same handsets, same operating system ceiling. The depth changes because the state changed: partial in BFU, full file system and keychain when the device is unlocked.
Nothing needs to be inferred from that. It is one page, saying it twice.
Axis one: how much a method returns
A caution before the definitions. There is no industry dictionary here, and the terms below are not used identically by every vendor. We say how we use them, and flag the places where sources disagree.
Logical
Data requested from the operating system through supported interfaces — a backup protocol, or an agent the tool installs to ask the OS politely. Fast, and bounded by whatever those interfaces expose.
Oxygen documents "Logical extraction via the iTunes backup procedure of Apple devices running iOS 8.0 – 18.3" and, on Android, "Logical data extraction via USB and Wi-Fi of Android devices running Android OS 4.1 – 15.0." Belkasoft describes its iTunes backup method as requiring "an unlocked device or a valid lockdown file," supported on "any (including iOS 26)."
Note what that pair shows on its own: the iOS version ceiling for a backup extraction is essentially the current OS, and the state requirement is a device somebody can already open.
File system
A copy of the accessible file system, including application sandboxes — app databases, caches, and records that a backup interface does not hand over.
Full file system
The file system plus the protected key material: keychain on iOS, keystore on Android. This is the level most capability marketing means when it says "everything."
That is a depth claim with a device list and an OS range, which is what makes it checkable. It is not a state claim, and it should not be read as one.
Physical
This is the term with the least agreement across sources, and it is worth seeing three uses of it side by side.
- Elcomsoft reserves it for legacy hardware. Its page offers "Passcode unlock and true physical acquisition (select 32-bit devices)," and elsewhere notes that "Passcode unlock and imaging support are available for several 32-bit iPhone models and a number of 64-bit devices based on Apple A8/A8X SoC."
- Oxygen uses "Android physical" for a method that is not a raw flash read at all: "Temporary rooting of Android devices running Android OS 4.0 – 10.0. The Security Patch Level date must not exceed October 2019."
- Belkasoft describes an MTK method that produces a physical image you may not be able to read: "The MTK method enables you to acquire physical images of MTK-based devices using Preloader mode. It does not decrypt acquired images, so it works best for older, non-encrypted Android devices."
Three vendors, three meanings, one word. The third is the one to keep in mind: on an encrypted device, a bit-for-bit image and readable evidence are different things, and only one of them is what an examiner needs.
For this entry we use physical to mean an image of the storage below the file system layer, and we say each time whether the source describes that image as decrypted.
Cloud
An account rather than a device. It belongs on the depth axis because it changes what data is in scope — material that may never have been resident on the handset — rather than what condition the handset is in. It is out of scope here, and it carries its own legal questions that this entry does not address.
Axis two: what condition the device has to be in
Unlocked, or with consent
The passcode is known, or the user is cooperating, or a valid pairing record exists. Elcomsoft is explicit that its logical acquisition needs one of these: "Experts will need to unlock the device with passcode or Touch ID, or use a non-expired lockdown file extracted from the user's computer," and, for devices its agent does not cover, "Device must be unlocked and paired with the expert's computer."
Most of the deepest documented results live here.
AFU — After First Unlock
The device has been unlocked at least once since it last booted, so user-data keys have been derived and are resident in memory. The device may be locked at the screen right now, and a great deal is still reachable.
BFU — Before First Unlock
The device has booted and has never been unlocked since. The keys protecting user data have not been derived. This is the state where depth collapses, and the vendors who describe it say so plainly.
A scoping note on the vocabulary. AFU and BFU describe a key-availability distinction that comes out of how iOS protects user data at boot, and the sources above use the terms in an iOS context. Vendors also apply them to Android — Cellebrite's Premium page uses both terms for Android devices — but the pages we reviewed do not state that the underlying mechanics are the same on both platforms, and this entry does not assume they are.
Locked, passcode unknown
The adversarial case, and the one where documentation thins out fastest. Where the pages we reviewed do address it, they name a narrow route: Belkasoft points to a separate brute-force module "for iPhones and iPads with specific SoCs inside"; Oxygen lists passcode brute force per chipset family under its locked Android headings; Elcomsoft confines passcode unlocking to legacy silicon and adds that "supported devices can be unlocked and extracted even if they are in a state of lock after 10 unsuccessful passcode attempts."
Where the axes get blended
Read the two together and some very common sentences stop being informative.
A depth claim with no state. "Full file system and keychain" tells you what you would get. It does not tell you whether the device has to be open first. On the pages we reviewed, current-iOS full file system methods are documented in an unlocked context: Oxygen lists its iOS Agent only under Unlocked iOS Devices, and Elcomsoft's agent sideloading route "requires a paid Apple Developer account, the device itself, and its screen lock passcode."
A state claim with no depth. The reverse is just as incomplete, and the clearest live example is a product page that names the state axis precisely and the depth axis not at all.
Both halves of that are worth stating carefully. Cellebrite is naming a real and difficult state, and the claim may be entirely accurate. What the page does not do is say how much data comes back from either state, which is the other half of the sentence — and the half an examiner has to plan around.
Neither axis. Magnet's Graykey page is a third pattern. We searched it on the same date: it contains no occurrence of "AFU", "BFU", "After First Unlock", "Before First Unlock", "full file system" or "locked". It offers "industry-leading iOS access", "comprehensive data extractions", and "decryption of keychain (iOS) and keystore (Android) data."
One line on that page does describe a consequence of the state axis without using its vocabulary: "Protect your extractions from automatic reboot timers and preserve available data that can expire over time." Data that expires when a device reboots is the AFU-to-BFU transition, described from the examiner's side.
What public documentation can and cannot tell you
Three statements get collapsed into one constantly, and keeping them apart is most of the discipline this entry is arguing for.
- A capability is publicly documented. Oxygen, Belkasoft and Elcomsoft publish dated device lists and OS ranges. Those can be read, compared, and found wrong.
- A capability may exist and not be publicly documented. Absence from a product page is evidence about the page.
- A capability has been independently demonstrated. Different again, and rarer than either.
The distinction bites hardest on restricted products, because their documentation is not a marketing choice so much as a distribution one.
For a product nobody outside a vetted customer base can buy, a public page is not where its capability envelope lives. We can say what the page says. We cannot say what the product does, and neither can anyone else working from public material.
The one place these questions get answered by measurement rather than by publication is government testing, and those reports record the extraction method per device precisely because it changes the result.
Same report, same tool, different depth per device — which is why a result quoted without its method is not a result. That is the subject of our earlier entry on what CFTT testing shows about mobile extraction tools.
Reading a capability claim
A practical habit, and the reason this entry exists:
- Find the depth term. If there is none, the claim is about access, not about data.
- Find the state term. If there is none, assume nothing — a deep method documented without a state is usually documented in an unlocked context.
- Find the boundary. A device list, an OS ceiling, a chipset family, a security patch level. A claim with no boundary cannot be checked against a device on your bench.
- Check the host, not only the handset. Elcomsoft's bootloader extraction is macOS and Linux only; that constraint lives on neither axis and still decides whether the method runs.
- Ask which of the three statements you are reading — documented, undocumented, or demonstrated.
What we could not verify
Not independently verified
Whether the vendors above use "file system" and "full file system" to mean the same boundary as each other. Each page uses the terms; none we reviewed defines them. We have described the distinction as we use it in this entry and quoted the vendors rather than harmonizing their wording.
Not independently verified
Whether the AFU and BFU distinction describes the same underlying key-availability behavior on Android as it does on iOS. Cellebrite applies both terms to Android devices. We did not find a vendor page in this review that states the mechanics are equivalent across the two platforms.
Not independently verified
Anything about Cellebrite Premium or Magnet Graykey beyond what their public pages say. Both are restricted products, their support matrices are not public, and we make no claim about what either can or cannot do. The observation here is about the pages, not the products.
Not independently verified
Whether the pages we quote were current on the date they were published. None of the five vendor pages we reviewed carries a visible publication date, revision date or product version alongside its capability statements. That is why the Sources and evidence box below names products without versions: the pages do not give any. We can date our reading of them; we cannot date the statements.