I’ve been given a mobile phone extraction or reader report. What can I do with it?¶

A mobile extraction or reader report is basically your working view of data recovered from a phone or related source. It lets you search messages, calls, contacts, media and app data without poking around on the original handset.

The useful starting point is to understand how the material reached your screen. What you are reviewing has normally passed through several stages: a source was acquired, forensic software processed the acquired data, and a report or reader package was then created for review.

That is not a problem in itself. It just tells you what to ask when you find something important — and especially when something you expected to see is missing.

From the phone to the report¶

A useful way to picture the process is:

Each stage answers a different question.

If an app does not appear in the report, for example, you need to know whether its data was acquired, whether the tool could decode or parse it, and whether that material was included and visible in the package you received.

Does the report contain everything that was on the phone? deals with that completeness question in more depth. The extraction and the report are different inventories explains the distinction between acquired data and the review package.

What a reader report may look like¶

A typical reader product such as Cellebrite Reader or a Magnet Portable Case may present data by category rather than by raw file structure. An investigator might see an entry resembling:

The tool has already done a lot of useful work for you here. It has taken fairly messy underlying data and turned it into something an investigator can actually search and read.

That entry can support several practical tasks: locating a conversation, establishing the time shown in the source, finding the account or number recorded with it, and identifying the underlying artefact for further checking.

But the labels are part of the forensic interpretation. If the difference between “sent”, “delivered”, “recovered” or “deleted” matters to the case, establish what that field means in this extraction and application rather than relying on the label alone.

Start by identifying the package¶

Before beginning a long review, establish the identity and scope of what you have received.

Check:

• the case and exhibit/device reference;
• the make/model or other identifier for the source device;
• the acquisition date;
• the acquisition type and whether any stage was partial or unsuccessful;
• whether SIM, memory card, backup or cloud sources were dealt with separately;
• the forensic tool and report/reader version;
• whether the package has been filtered by date, category, authority or request; and
• whether another extraction or earlier report exists.

What should I check before I start reviewing the report? gives the pre-review checklist.

This context matters because two reports from the same handset can legitimately contain different material if they were made from different acquisitions, tool versions, processing results or selected scopes.

Use the report as an investigative workspace¶

For routine review, a reader package is extremely useful.

You can search for:

• names and aliases;
• telephone numbers;
• email addresses;
• usernames and service identifiers;
• dates and times;
• words or phrases;
• URLs;
• locations;
• filenames and hashes; and
• other identifiers already developed elsewhere in the investigation.

Keep a sourced list of the terms you use. Alternative names, usernames and identifiers explains how to build that search set without turning unverified associations into facts.

When you find something important, preserve enough information for another person to relocate it. A useful note normally includes the extraction/report identity, artefact type, application or source, time, participants or identifiers, and any source path or artefact reference exposed by the reader.

A screenshot may help illustrate the finding, but it should not become the only record of where the item came from.

Understand what the tool has interpreted¶

Forensic tools often transform technical source material into convenient labels.

For example:

Reader label	What it may represent
Parsed / decoded	Source data that the tool interpreted into a recognised artefact
Recovered	Material reconstructed or obtained through a recovery method
Deleted	A source state, recovered record, broken reference or tool classification depending on the artefact
Incoming / outgoing	Direction inferred from fields in the application data
Sent / delivered / read	Application-specific message states, where available

These labels can be perfectly useful for investigation. The important point is that the underlying source and application behaviour give the label its meaning.

If a single disputed interpretation matters to a major decision, return to the digital-forensics unit with a defined technical question rather than trying to reverse-engineer the parser from the reader screen.

Follow a finding into the wider evidence¶

Suppose the report shows a WhatsApp conversation with a relevant number at 19:41 UTC.

That may immediately generate useful next questions:

• Is the number already linked to a known person or account?
• Does the other participant's device contain the same exchange?
• Does the application/account evidence support the recorded identity?
• Does the timing align with provider, CCTV, transaction or location evidence?
• Is there another device or linked client that could have created the event?

This is where the report becomes a line-of-enquiry tool rather than just a searchable archive.

What corroboration should I look for before attributing mobile evidence? explains how to test the weakest link between artefact, account, handset and person.

When the reader is enough — and when it is not¶

Many findings can be reviewed directly from a well-produced reader package: a clear active conversation, a photograph, a contact entry or a call record may be sufficient to develop the next enquiry.

Return to the forensic source when:

• a missing item materially affects the case;
• a timestamp or status has an important technical ambiguity;
• the result appears recovered, deleted or reconstructed;
• the reader does not expose enough provenance;
• a parser interpretation is disputed; or
• a significant decision depends on whether the artefact really means what the label suggests.

You do not need to send every interesting result back to the DFU. Most routine findings can be used perfectly well from the reader. Go back when the detail genuinely matters or the answer depends on how the tool interpreted the source.

The point to remember¶

A mobile extraction report is a powerful review surface because it turns complex device data into searchable investigative material. Use it confidently for that job, but keep sight of the route by which the data reached the report:

source → acquisition → processing → presentation

That route tells you where to go next whenever completeness, meaning or attribution becomes important.