MOBILE FORENSICS

Have digital metadata professionally analysed

TYPICAL QUESTIONS

When is this analysis required?

• ✔Does a message technically belong to the chat shown?

• ✔Is a media file linked to a specific news item?

• ✔What timestamps were recorded for creation, dispatch, receipt or status changes?

• ✔Are there any database relationships that confirm or put into perspective the screenshot?

• ✔Can gaps be explained by deletion, synchronisation, data migration or app behaviour?

• ✔Can message IDs or thread references be compared with other devices or backups?

An automatic tool output should not be equated with a final assessment. Database schemas and field definitions may change between app versions. Manual checking, validation and documented interpretation are therefore essential.

The file system manages not only the contents of a file, but also technical properties such as name, path, size, attributes and various timestamps. Depending on the operating system and file system, further information may be available. This data helps to investigate a file’s location, any copying processes and its association with an app.

However, file system timestamps should not be equated with the actual creation time of the content. If a photo is exported from a messaging app, the new file may be assigned a later creation time, even though the image itself is older. Conversely, when restoring from a backup, the original timestamps may in some cases be retained. The correct interpretation therefore depends on the specific storage and transmission method.

Location information may be found directly in media, in app databases, in map or navigation data, in WLAN references or in other system artefacts. GPS coordinates in an image are just one possible source. Other artefacts may represent locations, movements, route searches, saved positions or network references.

Location data requires particular care. A stored location may describe the device’s location, the destination of a search, the location of a recorded file, or simply a position derived from other data. Accuracy, measurement method and time reference must also be checked. A single location value should therefore never be presented as proof of presence without context.

Other relevant traces relate to the device and the applications installed on it. These may include model and system information, app package IDs, installation or Update references, permissions, account IDs, synchronisation status and backup information. Such data helps, for example, to verify whether a particular application was present during the relevant period or whether data may have been synchronised across multiple devices and cloud services.

This information must also be put into context in terms of time. The current installation status does not necessarily prove that an app was actively used at an earlier point in time. Conversely, traces of an app that was installed previously may remain, even though it was subsequently uninstalled.

Many mobile applications store data in SQLite databases. In addition to the visible user data, these databases often contain technical fields, IDs, status values and relationships between tables. In WAL mode, additional pages – or pages that have not yet been transferred to the main database – may be present in an associated WAL file. The SHM file supports the management of WAL operations.

To ensure a professional investigation, the main database, WAL and SHM should be backed up and documented together, where available. Nevertheless, it is important to note that not every data record found in a WAL file is automatically deleted, obsolete or relevant as evidence. Its position, transaction, page allocation and the state of the database must be assessed by an expert.

Metadata can reveal inconsistencies. For example, a photograph purportedly taken directly with a smartphone may contain software information suggesting that it was processed at a later date. A chat screenshot may not match the existing database entries in terms of timing or structure. A file may have been created in the file system at a different time to the capture time stored within it.

However, such discrepancies are initially merely indicators for further investigation. They may also arise from legitimate processes such as export, cloud synchronisation, forwarding, editing, a change in time zone or restoration from a backup. A thorough investigation therefore distinguishes between:

• ✔a technically identified deviation,

• ✔a plausible technical explanation,

• ✔a strong indication of subsequent alteration and

• ✔an instance of manipulation that can actually be proven.

Forensic neutrality: The purpose of the investigation must not be to confirm a desired assertion. What is decisive are the objectively existing traces and the reasonable conclusions that can be drawn from them.

Clarify the question: Which statement is to be technically verified?

Documenting evidence: The device, its condition, identifying features and handover are recorded.

Forensic data backup: The appropriate backup method is selected based on the device and the task.

Documenting integrity: Where appropriate, files and exports are secured using hash values and traceable working copies.

Identify relevant sources: media, databases, file systems, logs, cloud and app artefacts are narrowed down.

Check formats and meanings: the time format, time zone, database field and technical semantics are validated.

Correlating metadata: Individual tracks are cross-referenced against independent sources.

Check alternative explanations: synchronisation, export, migration, backup and software behaviour are taken into account.

Document results in a reproducible manner: record the steps taken, tools used, versions, queries and limitations.

Distinguishing between findings and assessment: A clear distinction is made between technical findings and expert conclusions.

• ✔A single timestamp is referred to as the „creation date“ without further verification.

• ✔UTC, local time and summer time are often confused with one another.

• ✔The file system time and the recording time of the content are treated as the same.

• ✔Missing EXIF data is automatically treated as an indication of tampering.

• ✔GPS data is presented as proof of presence without any verification of its accuracy.

• ✔Automatically parsed tool outputs are accepted without manual validation.

• ✔App versions and different database schemas are not taken into account.

• ✔A copy or export is treated in the same way as the original file.

• ✔Conflicts are not reconciled with any synchronisation or backup processes.

• ✔The absence of any trace is interpreted as evidence that an event did not take place.

Metadata can be removed, altered, overwritten or regenerated as a result of normal system operations. Some applications store only a small amount of information; others use encrypted or proprietary data structures. Modern operating systems restrict access to certain areas. Furthermore, sophisticated manipulation or unknown software bugs can complicate the analysis.

A rigorous analysis therefore does not claim to be able to reconstruct every event beyond all doubt. Rather, it describes which data sources were available, which methods were used, which findings are reproducible, and where technical uncertainties remain.

• ✔Verification of the authenticity or chronological context of photographs and videos,

• ✔Investigation into alleged chat manipulation,

• ✔Reconstruction of communication and event sequences,

• ✔Checking the origin of a file, its export or editing,

• ✔Analysis of location- and movement-related factors,

• ✔internal investigations and incident response,

• ✔Preparation of a private or court-ordered expert report,

• ✔Validation of digital evidence.