It all started when I was contacted by an experienced examiner, confused with the data he was being presented on a device. Note that In the interests of privacy, lots of details have been altered for this blog post.

Background

A homicide occured on the eveing of 1st October 2021 and a Phone, belonging to the victim, was left at the scene. The victim was transported to hospital and the offender arrested.

The device was left at the secured scene until 12PM the following day when it was bagged, tagged and transported to a secure property store.

It eventually made it's way to Digital Forensics examiners two weeks later on the 14th October.

The examiner took the device to a faraday environment and opened the package, photographing the process as he went.

Finding the battery dead, the device was placed on charge at 10AM and a few moments later, booted and the passcode used to unlock.

It was placed into Airplane mode and further photographed before starting the extraction process. A Full FileSystem extraction was obtained.

The Problem

So far, everything had gone to plan, but upon parsing, issues started to appear.

The device was showing usage on the evening of the 1st October such as Plug In/Unplug, Backlight, Unlock events etc. all occuring while the phone was in a supposed secure, unoccupied scene.

So who was using the device in an empty house? Or, Why was it recording activity when it wasn't being used?

The Details

You may know my fondness (as with all examiners I expect) of the KnowledgeC database. It is a wealth of information and I've never seen it be "wrong".

In this case, there was a consistent pattern of battery depletion throughout the day until it was plugged into power at around 10PM, Placed into Airplane Mode and unlocked etc.

Battery seen to be depleating but was plugged in at around 0030?

There was only two options I could think of.

A) Someone was in the empty house and using the phone (Although it had been cleared and secured).

B) The device time was wrong (But the data from earlier in the day was correct)

Looking at containermangerd.log.0 was interesting, as there was a boot event in 1969...

ContainerManager shows a boot at 17:06:38 on Dec 31st 1969 (aka 00:06:38 1st Jan 1970 UTC)

I know from previous examinations that iPhones don't have a backup battery for the Real-Time Clock and that when the device is dead, you still usually have enough power in the battery to keep the clock running for a few days at least (Depending on battery health).

I also know that when the battery does totally run out of power, the clock resets to 1st Jan 1970, updating to the correct time once it connects to the network.

From the containermangerd file, that appears to be what happened: The battery died, the clock was reset to 1970 and subsequently updated to 22:08 on Friday 1st October.

But that didn't help figure out who was using the device at that time.

Hypothesis

Something I'd not spent any time investigating is what happens when a device boots with a reset clock but is then denied access to the network to update it's time. The immidiate assumption is that it would just continue to run thinking it was 1970. But what if the clock could change itself and pick up where it left off before it died?

Testing

I don't have time to wait for the battery to die. Even on my old iPhone 6s test phone, waiting for the battery to die enough to kill the clock could take days. I also don't have the luxury of a faraday cage in my home office. So instead, I decided to try something else.

At 1312hrs, I put the device into Airplane mode and made sure the antenna's were all disabled and wouldn't turn themselves back on.

Prior to airplane mode

I then removed the screen and the screws which secure the battery connector and waited a little longer.

Prior to battery disconnection

At around 13:20, I pulled the battery. Since iPhones don't have any other battery inside, I figure this would be the same as the battery being completely dead.

Battery disconnection

Then I waited.

Finally, at 1455, I reconnected the battery and let the device boot.

Upon rebooting

Eureka! The device was showing 13:08, a time prior even to when I turned on Airplane mode!

I left it for a little while and watched as the incorrect time marched slowly on like nothing was wrong.

Now I wanted to see what artifacts I could find on the device.

The first thing I was interested in was containermanagerd.log.0. As expected, I found references to 1969 right before the time that was updated.

ContainerManager shows a boot at 17:00:23 on Dec 31st 1969 (aka 00:00:23 1st Jan 1970 UTC)

There is clearly a file on the device which updates every now and then with the most recent time. And this file is then used to set the clock in case the network time is unavailable.

So the mystery was solved. The phantom user of the device was the examiner themselves.

Wrapping Up

I will also note that the device photographs also reiterated what was tested above. But it's always good to do some digging.

It also reiterates the importance of noting the time on the device at the time of the extraction; even if the clock has reset.