Which Mobile Forensic Vendors Publish Testable Specifications?

How to read this

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.

A vendor page says a product reaches the full file system. Another says it gets into locked devices. Neither sentence can be checked, argued with, or relied on until you know what it applies to.

This entry asks one narrow question about public documentation, and nothing about capability: when a mobile forensic vendor makes a public capability claim, can a reader outside the company tell what exactly the claim covers?

We read the current public pages of seven vendors on 6 September 2026 and recorded what was visible that day. We did not test any tool, and nothing here says a product can or cannot do anything.

What makes a claim testable

A claim is testable to the degree that somebody who does not work for the vendor could identify the conditions under which it would be true, and notice if it were not. That is a property of the sentence, not of the software.

We read every page against nine questions:

• Product — which product is this about?
• Version — which build or release?
• Device — which handsets or models?
• OS and patch — which operating system versions, and which security patch levels?
• Method — which extraction technique?
• State — what condition must the device be in?
• Depth — how much data comes back?
• Limit — what is explicitly excluded or unsupported?
• Date — when was this written or last revised?

Depth and state are the two axes we set out separately in extraction depth and device state are not the same thing, and the vocabulary there is assumed here rather than repeated.

Two things this framework is not. It is not a score: a page can be exact about chipsets and silent about dates, and calling that a number would throw away the part an examiner actually needs. And a claim that answers few of these questions is not thereby false — it is harder, or impossible, to falsify as written. Those are different criticisms, and only the second one is ours to make.

We also tag at the level of the claim, not the page. A single product page routinely carries both a falsifiable specification and a promotional sentence, and the useful skill is telling them apart in the same paragraph.

Cellebrite

Two pages: the UFED product page and the Premium page.

That footnote matters, and it is the reason we quote the asterisk. The figures are attributed to a source rather than floated bare. But the source is internal customer usage that is not published, and the page does not name a comparator, a device set, a build or a period, so a reader still cannot say what "5x more" is five times as much as.

The same page does answer the depth question in plain terms — "multiple unique data collection methods, including full file system (FFS) and physical extractions" — and touches state with "Utilize After-First-Unlock (AFU) and other techniques". On the public page we reviewed we found no named device model, no chipset, no operating system version, no security patch level, no extraction method and no product version.

We searched that page for a depth term to attach to those states. "Full file system" does not appear on it, and neither does "logical". Its only occurrence of "file system extraction" is inside a customer testimonial statistic. So the Premium page names the state axis with precision and the depth axis not at all, which is the mirror image of the pattern on most other pages we read.

Neither page shows a revision date in its visible text. Both carry one in page metadata: 15 July 2026 for UFED, 20 April 2026 for Premium.

Magnet Forensics

The Graykey product page answers fewer of the nine questions than any other page in this review. We searched it for "AFU", "BFU", "After First Unlock", "Before First Unlock", "full file system" and "locked": none of the six appears. What it does state is a depth claim of a kind — "decryption of keychain (iOS) and keystore (Android) data" — alongside "industry-leading iOS access" and "comprehensive data extractions".

The supported-device question has a different and more interesting answer.

That post is one of the few pages in this review carrying a visible date. It also links to two "supported devices" pages on Magnet's support site. We followed both on 6 September 2026 and each redirected to a Magnet Forensics sign-in page.

So the accurate statement is narrow and factual: the device list exists, the company says where it lives, and it is not readable from outside the customer base. That is a statement about where documentation is kept. It is not a statement about the product, and it is not a statement about why.

The same page also carries the eligibility line that explains a good deal of the above: "Graykey is restricted to select countries. Graykey is not available to the private sector."

Oxygen Forensics

The device extraction methods page answers eight of the nine questions, and it is organized around two of them: its top-level headings are Locked Android Devices, Unlocked Android Devices, Locked iOS Devices and Unlocked iOS Devices.

Counted against the nine questions, the page names fourteen device models, chipsets across the Kirin, Qualcomm, Exynos, MediaTek and UNISOC families, twenty-three operating system version references, eighteen extraction methods, depth per method, and explicit ceilings. It is the only page in this review that states security patch level cutoffs at all.

It does not show a date in its visible text. Its page metadata gives a publication date of 2 December 2024 and a last-modified date of 26 May 2026, which a reader would have to view the page source to find.

One scoping note. This is one page. It is not a statement about everything Oxygen publishes, and the marketing language on the company's product pages reads much like anyone else's.

Belkasoft

The mobile device acquisition page answers the device, chipset, OS, method, state, depth and limit questions, and is notable for how often it states what does not work.

An explicit non-support statement is the most checkable kind of sentence a vendor can publish, because it can be shown wrong by a single counter-example. Two of the seven vendors here publish them routinely; this is one.

The page carries no visible date and no page metadata date, and it names no product version, so a reader cannot tell which release of Belkasoft X the ranges describe or when they last moved.

ElcomSoft

The iOS Forensic Toolkit page names devices, chipsets, operating system ranges, methods, states and limits, and it states one kind of limit no other page in this review does — a constraint on the examiner's own machine.

A capability that exists only on two of three host platforms is exactly the sort of condition that decides whether a method runs, and it appears on neither the depth nor the state axis. It is worth reading product pages for that class of constraint specifically.

The product page itself carries no date. The version question is answered elsewhere: the company's news page is a dated, version-numbered release history — 10.10 on 24 June 2026 adding pairing-free sideloading of the extraction agent, 10.02 on 29 April 2026 extending agent-based extraction to iOS and iPadOS 26. Among the sources we reviewed, that combination — a numbered release tied to a date tied to a named capability change — is the closest thing to a public changelog.

MSAB

The XRY Pro page names the state axis more explicitly than any other page here, spelling both terms out.

Those are capability claims with real technical vocabulary in them — three named encryption schemes, both device states, RAM as a data source. What the page we reviewed does not attach to them is any device model, chipset, operating system version, security patch level, extraction method, product version or visible date. "The latest" is doing the work that a version number would do elsewhere.

So this page answers the state question well, gestures at depth, and leaves the other seven unanswered. It carries a page metadata modification date of 9 June 2026 (day/month/year).

Compelson / MOBILedit

The description of editions is the only source in this review structured primarily around what each tier cannot do.

Read against the nine questions this is an unusual profile. Depth, state and limit are answered clearly and per tier; device, chipset, OS version, patch level and product version are not answered at all; there is no visible or metadata date. It tells you precisely what you are buying and almost nothing about what it will work on.

We record that as the company's own statement about its highest bypass tier. It is also the only public confirmation we found that a regulatory regime bears on these tiers at all, which is worth noting beside the PRO tier's phrase "non-regulated". What specific controls apply, and whether any United States export classification reaches these products, we did not establish; see below.

What the pattern looks like, and what it does not

Set the seven side by side and one thing is visible that we did not expect.

The specificity questions and the date question come apart. The three sources that answer the fewest technical questions — the two Cellebrite pages and the MSAB page — all carry machine-readable modification dates in their page metadata. Three of the four sources that answer the most — Belkasoft, Elcomsoft's product page and the MOBILedit editions matrix — carry no date at all, in the body or the metadata. Oxygen has both, though its dates are in the page source rather than on the page.

A reader who wants to know both what a claim covers and whether it is current generally has to visit two different pages, and sometimes cannot get both.

"Not stated here" is the only finding available. Every negative in this entry means one thing: not present on the public source we reviewed, on the date given. It does not mean the vendor has no device list, that the capability is absent, or that anything is being withheld. Three of these products are sold only to vetted government customers, so their detailed documentation is not public by design — and a design decision is not a disclosure failure.

We are not ranking anyone. The most we will say is scoped: among the public sources we reviewed on one day, the Oxygen extraction-methods page answered the largest number of our nine questions, and it is the only one that stated security patch level cutoffs. That is a statement about one page on one date, and it is not a statement that any product is better, more capable or more trustworthy than any other.

What public documentation cannot tell you

Nothing in this entry is a measurement. A specification is a claim the vendor makes and could be held to; it is not evidence that the claim held on a particular handset. The only body of measured, published evidence about these products that we know of is government testing, which asks a different question and is the subject of our entry on what CFTT testing shows about mobile extraction tools.

The practical use of this review is narrower than a comparison and more useful than one. When you read a capability claim, count how many of the nine questions it answers, and treat the unanswered ones as the conditions you will have to establish yourself.

What we could not verify