How do I find out what data was actually extracted?¶
title: How do I find out what data was actually extracted? subtitle: Use the acquisition record and source structure, not just the categories visible in the reader. slug: how-do-i-find-out-what-data-was-actually-extracted series: mobile-extraction-and-reader-reports section: understanding-what-you-have card_type: question_card pathway_order: 5 section_order: 4 status: draft owner: IF Digital last_updated: '2026-07-25' version: '0.1' review_gate: pending review_mode: ai-assisted review_timebox_mins: 30 qa_gate: pending qa_count: 0 pipeline_ref: PIPELINE_PRG_001 pipeline_version: '1.1' public_safe: true video_ready: true word_count: 524 estimated_read_time_seconds: 217 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - acquisition log - data inventory - source files - scope sources: - title: 'NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics' url: https://csrc.nist.gov/pubs/sp/800/101/r1/final - title: SWGDE Best Practices for Mobile Device Forensic Analysis url: https://www.swgde.org/documents/published-complete-listing/20-f-005-swgde-best-practices-for-mobile-device-forensic-analysis/ - title: 'Cellebrite: Configuring and reviewing a Reader report' url: https://cellebrite.com/en/ask-the-expert/cellebrite-reader-familiarizing-yourself-with-the-platform/ - title: 'Cellebrite: Creating reports for Reader' url: https://cellebrite.com/en/series/tip-tuesday/different-methods-for-creating-reports-in-cellebrite-reader/
How do I find out what data was actually extracted?¶
Use the acquisition record and source structure, not just the categories visible in the reader.
Script¶
The categories shown in a reader report don’t tell you everything that was acquired.
They tell you what the processing and reporting workflow has made visible in those categories.
To understand the extraction, separate three inventories.
What data was acquired from the source?
What data did the forensic software parse or decode?
What data was included in the package you received?
Start with the acquisition documentation.
Look for an acquisition summary, extraction log, examiner worksheet or report section identifying the device, the acquisition method, the start and completion times, the tool and version, the source areas acquired, the result or any error, and hashes or identifiers for the output files.
This is the best starting point for understanding what the tool attempted and what it produced.
Then examine the source tree or extraction structure if your reader exposes it.
A report may contain a file-system view, data files, application folders, databases and media that sit outside the high-level artefact categories.
The presence of a file in the source tree doesn’t mean the tool successfully interpreted its contents.
The absence of a parsed WhatsApp category, for example, may coexist with application files that need different processing or specialist review.
Now check the processing summary.
Which applications and artefact types were recognised?
Were any databases encrypted, corrupted or unsupported?
Did the tool report decoding errors?
Was additional processing carried out with another tool?
Did the examiner manually examine any source that the automated software didn’t parse?
SWGDE notes that forensic tools have different capabilities and that one tool may interpret data another tool misses. Reprocessing with updated software can also produce additional artefacts.
Then check the report-generation settings.
Which categories were selected?
Was a date filter applied?
Were only tagged or bookmarked items exported?
Was the report created to meet a restricted legal scope?
Were large media files excluded to make the package manageable?
A reader package created for an investigator can deliberately contain only part of the processed case.
Don’t infer the acquisition inventory from the report’s left-hand menu alone.
Ask for a clear source summary where it isn’t provided.
A useful answer from the digital-forensics unit might say:
“The device produced a full file-system extraction and a separate SIM extraction. The supplied reader package contains all parsed artefacts from the handset except media outside the authorised date range. Data from one encrypted application wasn’t decoded.”
That gives you three different pieces of information.
The acquisition level.
The processing limitation.
And the report scope.
The common mistake is:
“There is no Telegram section, so no Telegram data was extracted.”
The application may not have been installed.
Its files may not have been acquired.
They may have been acquired but not parsed.
Or they may have been excluded from your package.
Another mistake is to treat a large file count as proof of completeness.
A package can contain millions of records while missing one important encrypted application.
If the question is operationally important, record the acquired sources, the extraction type, the successfully processed categories, the unparsed or failed areas and the report-selection criteria.
That is the real inventory.
The report menu is only the presentation layer.
Key takeaway
The data acquired, the data parsed and the data included in your report are three different inventories.
Related questions¶
- Does the report contain everything that was on the phone?
- What is the difference between logical, file-system and physical extraction?
- What should I ask the digital-forensics unit before relying on the report?
Source notes¶
- NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
- SWGDE Best Practices for Mobile Device Forensic Analysis
- Cellebrite: Configuring and reviewing a Reader report
- Cellebrite: Creating reports for Reader