Mobile Forensics · Timelines & Analysis · Lesson 2 of 5

Building a Timeline

Merge many sources into one honest timeline, all in UTC.

Many sources, one clock

A timeline is a list of events in time order, built from every source the examiner is allowed to look at. On a single phone that might include the call log, messages, photo metadata, app databases and system logs. Add the cloud account and the carrier's records, if the warrant or consent covers them, and you may have thousands of events from a dozen places.

Each source keeps time its own way. One database stores Unix milliseconds in UTC. Photo metadata may store a local date and time, sometimes with an offset and sometimes without. A carrier report may be in UTC or in the carrier's local time, depending on the company and the report. A screenshot of a chat shows whatever the phone displayed at the time.

The core rule is to normalize everything to one reference, almost always UTC, before you put events side by side. Only after that do you convert back to local time for the people reading the report, clearly labeled.

For every event, a careful examiner keeps more than the converted time:

• The raw value exactly as found, such as 750000000.
• The source: which file, table and field it came from.
• The format and offset used to convert it, such as Cocoa seconds, UTC.
• Any doubt, such as a local time with no stated offset.

This lets anyone else repeat the conversion and get the same answer. If a mistake turns up later, you can fix the one rule that was wrong instead of redoing the whole timeline. It also makes the work easier to defend, because every line can be traced back to the evidence.

Keep the scope in mind too. A timeline is only built from data you have the authority to examine. Records outside the time window or the categories in a warrant don't belong in it, even if the tool shows them.

Clocks, corroboration and gaps

Every timestamp a phone writes comes from the phone's own clock. If that clock is wrong, every event it records is wrong by the same amount. Most phones set their time automatically. Android can take time from internet time servers (NTP) and from signals sent by the mobile network (NITZ). iPhones also set the date and time automatically by default. When automatic time is working, the clock is usually close to correct.

Usually is not always. A user can turn automatic time off and set any date they like. A phone with no network for a long time can slowly drift. A device that was dead may start up with the wrong time until it gets a signal. NIST's mobile forensics guidelines advise recording the date and time shown on the handset and comparing it with a reference clock, a trusted time source, noting any difference. If the phone was off when seized, do this when it's first powered on.

Next comes corroboration: checking an event against an independent source. If the phone's call log shows a call at 14:02 UTC and the carrier's record shows the same call at 14:02, that event is strong. If they disagree by exactly ten minutes, you may have found clock skew, and you can measure it.

Finally, be honest about gaps. A quiet hour in a timeline doesn't mean nothing happened. The phone might have been off, in airplane mode, or out of signal. Data may have been deleted, overwritten or never saved. Some logs keep only a few days. Write gaps into the report as gaps, with possible reasons, rather than filling them with guesses.