I’ve been given a mobile phone extraction or reader report. What can I do with it?¶
Understand what was acquired, what was interpreted and what was selected for you before treating the report as the phone.
Script¶
You’ve been given a mobile phone extraction, a reader report, a portable case or a large export from a digital-forensics unit.
It may contain messages, calls, contacts, photographs, application data, internet activity, locations, accounts and thousands of other records.
The first reaction is often either:
“This contains everything from the phone.”
Or:
“I don’t know how to use this, so I need a specialist to tell me every answer.”
Neither is a safe starting point.
A mobile report is a way of presenting data obtained from a device or another source connected to it. Some of that data may have been copied directly as files. Some may have been decoded from databases or system records. Some may have been recovered from remnants. Some may have been selected, filtered or excluded when the review package was created.
The report is therefore several steps away from the physical phone.
There was a device.
An acquisition method was used to obtain data.
A tool processed and interpreted that data.
An examiner may have selected what to include.
The reader software then presents it in a form that an investigator can search and review.
Each step can affect what you see.
That doesn’t make the report unreliable. It means you need to understand what it represents before relying on it.
Start with the scope.
Which device was examined?
How was it identified?
When was it acquired?
Was it unlocked?
Which acquisition method was used?
Were the device, SIM, memory card, cloud account or backup treated as separate sources?
Was the report limited by date, data type, legal authority or investigative request?
Then establish what you have actually received.
Is it the acquisition itself?
A review package created from the acquisition?
A PDF or spreadsheet export?
A set of examiner bookmarks?
Or an analyst’s written summary?
A reader report may contain a large amount of data while still being only a selected subset of the material available to the examiner.
A PDF may be narrower again.
An analyst’s summary may contain conclusions and relevant findings without providing the full underlying dataset.
Don’t use those terms as though they are interchangeable.
Next, separate three questions.
What data was acquired?
What data did the forensic tool successfully parse or decode?
What data was included in the package you were given?
A missing WhatsApp conversation might mean the device didn’t contain it.
It might mean the application data wasn’t acquired.
It might mean the tool didn’t support that version.
It might mean the database was encrypted or damaged.
It might mean the examiner excluded that category from your report.
Or your search may simply have missed the way the information was stored.
Until you know which explanation applies, absence is a limitation rather than proof.
Now look at individual results.
A record marked parsed or decoded normally means the tool interpreted stored data and presented it as a recognisable artefact such as a message, call or location.
It doesn’t mean the interpretation has been manually validated in every case.
A result marked recovered may have been obtained from a database, cache, backup, file remnant or another source.
It doesn’t automatically mean the user deleted it.
A result marked deleted may reflect a database status, a broken reference, a recovered remnant or the tool’s own classification.
It doesn’t automatically prove deliberate deletion by a person.
Use the report for the work it is good at.
Search for known identifiers.
Review conversations and media.
Build lines of enquiry.
Tag relevant items.
Identify accounts, applications, dates and links between people.
Record the source path and artefact details for anything important.
Then return to the digital-forensics unit where the conclusion needs deeper validation, missing data matters or the report doesn’t expose enough source information.
A supervisor doesn’t need to understand every database table before authorising sensible action.
They should ask:
Have we identified the correct device and extraction?
Do we know the scope and limitations?
Are we looking at the full review package or a filtered report?
What does the relevant artefact show directly?
Has an important result been validated against its source?
What alternative explanation could produce the same record?
And what should go back to the examiner?
The extraction report is not the phone.
It is not automatically complete.
And it is not useless because a non-specialist is reviewing it.
Treat it as a structured representation of device-derived evidence.
Understand how it was produced, use it to find what matters, and know when the next question belongs back with the forensic examiner.
Key takeaway
A reader report is a route into device-derived evidence. It isn’t automatically the complete extraction, an analyst’s conclusion or a perfect copy of everything that happened on the phone.
Choose your next question¶
- What exactly is a mobile phone extraction report? (outside pilot sample)
- What should I check before I start reviewing the report? (outside pilot sample)
- How do I find out what data was actually extracted? (outside pilot sample)
- Does the report contain everything that was on the phone? (outside pilot sample)
- What should I ask the digital-forensics unit before relying on the report? (outside pilot sample)