If I Could Turn Back Time—A Closer Look at iOS Time Modifications
Recently I received a question from one of our customers that asked: “Have you considered what the data would look like if someone using their iPhone, changed the time setting, then continued using their phone?” Why would someone do this, you ask? The simple answer is to make it look like an activity occurred on a different day.
I had never fielded this question before, so I decided to test it and provide feedback. The results were not what I was expecting. To be honest, it was much easier than anticipated.
Let’s take a look at my test methods and the results.
Testing, Testing, 1…2…3
- Test Device: iPhone X running iOS 13.5
- Extraction Solution: UFED 7.33 checkm8
The customer stated that call logs were of interest, so I completed the following test:
- On June 3rd, 2020 at 2:23 PM Eastern Time, I called myself from my test device. The call lasted about 16 seconds.
- I then went into the Settings and turned “Set Automatically” to the “off “position before I changed the date to June 1, 2020 at 12:33 PM Eastern Time.
- Once that step was completed, I placed a call to my husband at 12:34 PM Eastern Time and left a voice mail message that was approximately 28 seconds in length. (Keep in mind the real time for this would have been June 3, 2020 at 2:34 PM.)
- I called my test device from my phone (to have incoming call data) at 12:37 PM Eastern Time. This call lasted approximated 10 seconds.
- I then missed a bunch of calls on my test device.
May the Truth be Revealed
This is where documentation is key. You need to document anything you did on the test device to really understand the results. A checkm8 extraction was completed using Cellebrite UFED and the extraction was parsed in Cellebrite Physical Analyzer 7.34.
The Call Log is shown below. Notice that the order of data shows the calls that happened after I changed the time to the time the phone was set to? This can be extremely confusing if you didn’t document your test steps.
I always recommend verifying the data, especially when conducting a test and verification. You can hop directly to the database by clicking on the “Source file” as provided in the right pane.
The CallHistory.storedata matched exactly what is parsed above. The database will adopt the time the user set in the device. Here is a quick query that will help you cull the database results.
z_pk AS “Call Sequence #”,
zaddress AS “Phone Number”,
zduration AS “Call in Seconds”,
when zoriginated = 0 then “Incoming”
when zoriginated = 1 then “Outgoing”
end AS “Call Direction”,
when zanswered = 0 then “Call Missed”
when zanswered = 1 then “Call Answered”
end as “Call Status”,
datetime(zdate+978307200,’unixepoch’,’localtime’) AS “Timestamp”
So, how would you know the time change had occurred? To be honest, I was chasing plists at this point and felt as if I was running in circles.
I then decided to peek at the timeline. To do this, I simply clicked on “Go to” and then “Timeline” under Device Event on the right pane for the first suspicious call—the first one from June 1st, 2020. (Note: the screenshot below shows the times in UTC +0:00, which is my preferred way to conduct examinations. However, for test purposes it made sense to set my time zone as Eastern, which is displayed in the other screenshots).
The results are shown below. Right away, I spotted a “Device Event” from the Powerlog that showed the clock had been changed. It also showed the exact time I had changed it to on my test device (June 1st, 2020 at 12:33 PM Eastern Time). Pretty slick, right?
I recommend hopping right to the Timeline when you have a timeframe of interest. It may save you more time than you think.
Testing and validation are crucial when you aren’t sure what the evidence is supposed to look like. I have been doing digital forensics for almost 19 years and this is the first time I have been asked this specific question, which is why it warranted a test. Sometimes a simple test is all you need to make certain you understand the data.