19 Oct How to Read a Cellebrite Report: A Guide for Defense Counsel
Most defense lawyers I work with say the same thing about Cellebrite reports: it’s Greek. They open the .ufdr file, see thousands of messages and a dozen tabs of categories they’ve never heard of, and go hunting for the three texts quoted in the prosecution’s synopsis.
I understand why. It’s also how cases get lost. The examiner made dozens of decisions before that report reached you: what kind of extraction to run, what to parse, what to include and what to leave out. Most of those decisions are recorded somewhere in the report. You just need to know where to look.
This guide walks through a typical Cellebrite report the way I do when one lands on my desk. It’s written against Physical Analyzer and Reader 10.9. Labels shift a little between versions, but the structure has been stable for years.
First: what you actually received
Discovery usually arrives as a folder holding the Cellebrite Reader program and a report package ending in .ufdr. You open the .ufdr in Reader, a free viewer, and browse what the examiner processed.
What matters is what isn’t in that folder. The .ufdr is a report built from the extraction, not the extraction itself. The raw data (the .ufd or .ufdx extraction file and the data files behind it, often .bin, ZIP or TAR) stays with the examiner unless someone asks for it. NACDL’s sample discovery language asks for four things per extraction: the original HTML report, the Reader, the UFDR report, and all data captured by the extraction. With only the report, you’re looking at the phone through the examiner’s eyes.
One more thing about Reader: some entries can be hidden by its default settings. Some agencies warn about this in their own cover letters. Check the filters before you decide something isn’t there.
The Summary page: where the examiner's choices live
Start with the Summary (sometimes labeled Extraction Summary). Most lawyers skip it, and it tells you more about the case than any chat thread.
Report creation time. When the report was generated, with a time zone offset such as +10:00. This is often months after the extraction. The report reflects what the examiner chose to process at that point, not everything the phone held.
Source extraction. This one line tells you the most the report could ever show.
| Extraction type | What it captures | Deleted data? |
|---|---|---|
| Logical | Active data the phone hands over through normal channels | No |
| Advanced Logical | Logical data plus file system data the device exposes | Generally no |
| File System | Targeted files and databases from the file system | Some |
| Full File System | The complete file system, including system files and app databases | Yes, where it survives |
Cellebrite itself calls Full File System the richest extraction for modern devices. If the report shows a Logical or Advanced Logical extraction and the prosecution is making claims about deleted messages, ask where those claims come from.
Extraction start and end times. When the examiner was connected to the phone. Line these up against the seizure date and the warrant or consent. A phone extracted with no authority on file yet, or one left powered on for weeks first, is worth a hard look.
Extraction (UFD) file data integrity. This normally reads Intact. If it reads Not available, the report can’t confirm that the extraction file matches what was captured. Ask why.
Multiple extractions. Many reports list more than one source: a Logical and a File System pass, or the phone and its SIM card. Every item in the report is tagged with the extraction it came from. When two extractions disagree, the report won’t flag it for you.
Content counts: “Included in report” vs. “Total.” The summary often lists each data type with two numbers. When Included is lower than Total, someone filtered the data. There may be a good reason. Either way you’re looking at a selection, and you’re entitled to know the rule behind it.
Inside the data: every item has a source
Each category in the report (chats, SMS, calls, locations, web history, the timeline) is the tool’s reading of databases on the phone. Click into any item and Reader shows where it came from: the extraction it belongs to and, usually, the source file it was read from.
That source file is the most important field nobody looks at. A message parsed from the phone’s main message database is a different kind of evidence from one rebuilt out of a notification log or a backup fragment. When a message matters to the case, note its source file and ask whether the examiner ever looked at that file directly, or only at the tool’s summary of it.
Deleted and carved items
Reports flag some items as deleted. That flag is the tool’s judgment based on how the record was stored, so handle it carefully:
- “Deleted” can mean a person deleted it, an app cleaned it up on its own, or a disappearing-message timer ran out. The flag usually can’t tell you which.
- A deleted record can be partial. The text may survive while the timestamp or sender doesn’t, or the other way around.
What can and can’t come back is covered in Can Police Recover Deleted Text Messages?
Carved items sit even further out. Carving means the tool scanned raw data for patterns that look like a message, a photo or a location, and pulled out whatever matched. Carved items often have no reliable timestamp, no sender, and no link to the database they once belonged to. They can be real. They can also be fragments that only look complete. A carved item presented as a clean, dated message deserves the hardest questions in the whole report.
Timestamps and time zones
Every time in the report was converted from a raw value on the phone, using a time zone the tool or the examiner applied. Three things go wrong here more than anywhere else:
- The time zone. Read the offsets. In one publicly filed report, the report creation time shows +10:00 while the extraction times show +11:00. That’s daylight saving, and it’s correct, but it shows how easily an hour can move. If the phone crossed time zones, it gets messier.
- The event. A field may record when something was created, modified, viewed or written to disk. The Karen Read trial turned partly on a browser timestamp that marked when a tab came into focus, not when a search was typed. Here’s that breakdown.
- The phone’s own clock. Times come from the device. If its clock was off, or changed by hand, every time in the report inherits the error.
Who was holding the phone?
A report shows what happened on a device. It almost never shows who did it. Shared phones, unlocked phones, synced accounts, and messages sent from a linked tablet or computer all put activity on a device without its owner touching it. When the case depends on your client personally sending something, look for what ties a person to that moment: unlock events, other activity in the minutes around it, location data, other users of the device.
A red-flag checklist for any Cellebrite report
- Do we have the extraction itself, or only the .ufdr report?
- What extraction type was used, and does it support the claims being made?
- Do the extraction dates line up with the seizure and the warrant or consent?
- Does data integrity read Intact for every extraction?
- Are any “Included in report” counts lower than the totals? What was filtered, and why?
- For each key item: what’s the source file, and is it flagged deleted or carved?
- Which time zone was applied, and was the phone’s clock accurate?
- Does anything else on the device back up the key timestamps?
- What actually ties your client to the device at the critical moment?
- Which tool version produced the report, and were later versions released with parsing fixes for the apps involved?
When to bring in an examiner
Work through that list yourself. You’ll get further than most lawyers do. But some questions only the raw extraction can answer: whether a deleted flag holds up, what a carved item really is, what a timestamp field actually records. That’s where the report stops and forensic work starts.
If you have a Cellebrite report in discovery and your case leans on it, I offer independent Cellebrite report review for defense counsel. Most cases start with a TruthScan: a flat-rate review of one extraction that tells you where the report holds up, where it doesn’t, and whether a deeper analysis is worth your client’s money.