I have been given a mobile extraction. What happens next?¶

The acquisition record identifies H-31, the extraction method, tool version, completion time, output hashes and one application that could not be decoded.

Start with the package documentation, not the search box. Finding out what was actually extracted means separating what the tool acquired, what it parsed and what the examiner included in this reader package. The report menu describes presentation; it is not an inventory of everything successfully collected.

The acquisition log states that RelayChat files were acquired and parsed. A second encrypted application was acquired but not decoded. Media outside the authorised date range was excluded from the portable report. These are specific limitations, not a reason to dismiss every available result.

Message MSG-11908 is retained with its source path, database record, surrounding conversation and linked attachment - not as a detached screenshot.

A screenshot may help explain what an investigator saw, but it can omit source, field names, filters and neighbouring entries. Preserving a useful reader result and recording where an artefact came from keep the displayed item connected to the underlying extraction.

The surrounding records show that the same conversation uses account ID RC-7712, contains an earlier photograph thumbnail TH-441 and continues after the assault. That context materially changes the value of one sentence viewed alone.

The source row carries a deletion flag, but the examiner confirms that the report cannot identify who deleted it or the precise deletion time.

“Deleted” in a mobile extraction can describe a database state, recovered row or parser interpretation. It does not always mean that the phone user deliberately pressed delete, and it does not guarantee that the complete original item has been recovered.

Parsed or decoded means software interpreted source data into a human-readable result. Parser output is often reliable and extremely useful; important ambiguity should be checked against the source structure, tool documentation or examiner - not waved away with “the software says so”.

A recipient device retains the same message ID, text and provider timestamp without a deletion flag. That independent copy strongly confirms the communication event while leaving the later deletion mechanism open.

Message, map, image and application records align into a sequence while retaining their different timestamp meanings.

A cross-application timeline should preserve each original timestamp, timezone, source and event meaning. A message stored time, map-search time, photograph capture time and notification time are not interchangeable merely because the reader displays them in one column.

The timeline uses UTC for ordering and preserves the original fields. Choosing which timestamp to use depends on the event being described. The close sequence is evidentially important; it should not be rewritten as though all four systems recorded the assault itself.

Device possession, provider records, recipient evidence and venue footage converge on Lena while identifying a second participant.

Account RC-7712 is registered to a recovery address used by Lena. Provider session records place it on the same handset installation during the relevant period. CCTV shows Lena using a phone matching H-31 outside the venue shortly before the message, and the handset remains in her possession when recovered. The recipient identifies their own account and supplies the matching message thread.

Possession of a phone does not by itself prove authorship, and an account name does not prove the app user. Here the proposition is supported positively by account control, contemporaneous possession, a matching provider session, the recipient copy and closely timed venue evidence. The combination is circumstantially strong because the sources observe different parts of one sequence.