Jens-Petter Sandvik discusses his research at DFRWS EU 2018.
Jens: Yes, hello! I am Jens-Petter Sandvik from the NTNU, a Norwegian university of science and technology. I am doing a PhD there. Also working in the police with digital forensics, I’ve been practicing digital forensics for last 12 years. But now I decided to do some academic work also.
The background for this talk is from my court case in Norway I was working with. We had … it’s like a telephone, mobile phone, and we had evidence of the clock being adjusted back for 24 hours in time, at a very interesting time for the investigation. They found the database entries actually, SQLite, entries from database that showed that the ID number was increasing but time suddenly was turned back 24 hours.
24 hours isn’t a very round number for a computer. It’s 86,400 seconds or this in hexadecimal, [one fifty and one eighty] hexadecimal. So, it’s not a very round number, so it’s like … the whole thing about can this be a natural explanation or was it someone actually adjusting back the clock was of course the question.
After a more thorough examination of the device, we found out that the day before, the clock had been adjusted for 24 hours. So, it was not someone wanting to create an alibi after something had happened, but it was the day before something, [however] the phone had been set forward 24 hours and then turned back.
We found missing row numbers in the SQLite database before the boot of the phone. And after the boot of the phone, the clock was going 24 hours incorrect. And of course, the suspect told that the clock had adjusted itself randomly when battery fell out, and he said that this was a problem in the phone. So, we were testing the suspect’s phone and found out that the battery actually was quite bad, it didn’t charge properly, and removing and reinserting the batter made, actually, the clock on that particular phone jump forward in time.
We only got it to jump one minute forward, but still, it was an unexpected behavior. So, of course we couldn’t rule out that possibility that the clock had actually adjusted automatically 24 hours forward. We couldn’t rule that out from these experiments. But it tickled my curiosity. So, let’s see.
There. So, main findings – start with those at once, so you can fall asleep at once. We tested four different devices. We had one hypothesis, that the clock can be adjusted by low voltage on the battery. Or, an alternative hypothesis, that the clock goes either close to correct or is being reset to an epoch when the voltage is too low. The result showed that one phone was automatically adjusted 8-12 years into the future when voltage was held at 2.03 … between 2.03 and 2.10 volts for nine to 10 seconds. But for the three others, the clock showed quite close to our alternative hypothesis, that it either was going correctly until the voltage was too low, and then it was reset to a zero or an epoch.
We also tested some methods for documenting the time on a device, and all methods we tried had a precision of better than four seconds. The maximum of third minus first quartile was less than 0.6 seconds, so most cases it was within one second. And we made a model for delays and noise in clocks [of that devices], just to have this model about how it works.
This model was based on Willasen’s work from 2008, and Willasen explains that the clock on a device at a given time – ‘t’ here is time, and ‘c’ is the clock on the device – it depends on the civil time or the real time, the correct time, blt, plus a time offset. We have added these delays that happens when asking for the clock in devices also. That is this – I will come back to this later.
So, our methods was, first, a model describing the delays and noise when documenting a time. Testing precision of some ways to document a clock. Compare timestamps in … one of our methods is to compare timestamps in photos, like file system timestamps or EXIF timestamps with like running clock on a device. Or you use an app to compare timestamps.
We tested the clock on four different devices when they were held under a low voltage, and we did that by first finding the threshold of where the clock was reset, where did the clock start behaving strange. And then, test various combinations of time and voltage at this reset point.
To the model – we have used two different event types. One is the event triggering writing of a timestamp. You have an event here happening. The system asks about the time, and the clock answers, and you write the timestamp. And of course, between the event and the time, the system asks for the time, it’s a delay here, and also a small delay between the system call and the actual clock retrieval. And then, you also have some noise that affects the precision of the clock.
When updating an interface, you have a timer circuit that goes, asks the clock about the time, it’s time to do something, then it triggers a get time, and you also have a delay here between the clock, to the get time and until that interface is updated. So, if we put these two basic models together, we get something like this.
First, we have this [updating] an interface, like this typically clock shown on our computer screen. Of course, here, you have some delays here, you [have] the interface plus the camera shutters at the same time, and you have a delay here from the camera that gets the time and gets the clock from the camera device, and then the timestamp is written.
And of course, with the app running on the phone, we start the comparison. It’s asked for the system time, and ask the system clock for this, and for the external time and the external clock.
In our model, the difference between these two clocks – system clock and camera clock – can be modelled like this. If you remember the first … there, they had also this correct clock, this get cancelled out, so we only have the difference in the offset, plus the delays happening here, here, here, and here.
For the other case, we have … since these goes in parallel, you get the offset between those clocks, plus the delay, minus the other delay. So, in theory, these two delays should cancel each other out when comparing the clocks.
With this model in mind, we did some tests for testing the precision of documenting the timestamps. We used two cameras, one Huawei P9 phone and one Canon 60D DSLR camera. Used a stopwatch to compare with, and computer running an NTP client. We compared the timestamps from photos with NTP and stopwatch running and … so we took the photo of both NTP clock and the stopwatch to see how these compared with the timestamps in photos. And that means finding this delay here, in this model.
Also, testing an app running on the phones, the app was called ClockSync. It’s not forensically sound, so I would not recommend to do this on actual evidence, but it was very convenient for testing purposes.
And we saw that this is the differences between the timestamps. So, [here we are] with the phone GPS timestamp, and that [11:02] together with … compared with NTP clock running. You have filename, compared with NTP time. And so I tested the various timestamps there, and we see that most of them have a precision within one second, except for the GPS ones – here, here, and here. Because one of the GPS timestamps was four seconds off, and unknown why. It might be that the phone was indoor and therefore did not have any GPS fix, but the phone still wrote the GPS timestamp to the EXIF data.
The least variable one was the … when I have compared it with a stopwatch running this … in the photo. But still, it’s for most parts within one second precision, plus, minus. The app ClockSync also tested on four different devices. And here we see the most variability was on the device that was also considered the slowest when using it. But still, well within one second precision here.
So, when we know that delays and variability of this does not consist of more than one second, we were going to test what actually happened with the clocks on the phone. So, we tested four devices, two Android phones – Huawei Y625 and a Samsung Xcover 2. One Android tablet, Asus Memopad 10. And one Windows phone, a Nokia Lumia 830. The Android phones were tested using this ClockSync app, and the Windows phone by taking photos of the running NTP clocks. I mounted the camera over the phones, pointing toward the screen or the computer running these NTP clocks, so then I could compare directly the timestamps with the NTP time.
Documenting time before and after – I put the clock in a low power [modes]. I connected the power supply to the battery pads on the phone and I turned down voltage with the operating system running. Of course, if I should have done this to mimic our real battery, I would probably need to adjust the voltage down continuously until it came down to a point, but I chose to do the little bit faster solution.
The operating voltage on the batteries were 3.8 volts, but when it approached approximately 2 volts, it was not sufficient to run the operating system, so the operating system was shutting down while the real-time clock, the low-power clock on the CPU, was still running. And some batteries of course needed to connect to thermistor or battery size indicator to the device in order for the device to boot.
So, I found the time-voltage combinations where the clock was reset, and was looking for proof that the clock invalidated the alternative hypothesis. Then, that means to see if this clock offset is affected in this model.
So, to start with the most exciting results, the Asus Memopad 10 tablet. Here we see the 2.03 volts graph and the 2.10 volts graph, and when I tested this … along the X-axis is the time I have held it under low voltage. So, I turned the voltage low, and after a few seconds turned it back up to 3.8 volts. And along this axis is the resulting difference in time. So, I would guess … my guess or the alternative hypothesis is that this should show about zero difference until some pointer, and then go down to an epoch.
But this … the Asus Memopad, it showed that it was going close to correct, just a couple of seconds here, until it came to about nine, ten seconds, then it skipped up to eight years into the future, and then little bit longer next test, and it rolls back to running next to normal, and then it’s up to the same offset there, and then finally back down to an epoch. So, it jumped forward, it jumped forward to these dates – 20th of July 2025 and 18th of May 2029.
This is the offset in seconds, hexadecimal, it was this, so it’s not very round numbers either. The epoch was, funnily enough, 2nd of January 1970. And I also noticed that after 30-60 seconds of this future date, it was just back to normal time. It showed that it was … [actually it] happens because of an SSL error for Google check-in service. And the device clock was outside the validity of the SSL certificate, and therefore, Android automatically reset the phone to current date. But if it had jumped less then I think the SSL was valid until 1st of January 2019, so if this had jumped to a date before 1st of January 2019, it would have not been reset. And of course, since I used an app to check this, it was online, so it could reach the servers for the Google check-in service.
Similarly, we had the Huawei Y625, this one stops or lags a little bit before being reset, but the epoch is right before the clock shuts down. It doesn’t have a set epoch point like 1st of January 1970 or so, but it seems to be updating the time reset value regularly, so while it is running it updates the time it will reset to when it shuts down. Did not see any jumps in time apart from this. And this of course, you see the dips here in the graph is where I took a longer break in the tests. So, it’s …
And Samsung Xcover 2, have to try several voltages, and they all were showing the same pattern, it went close to correct until it was reset to epoch, and even on zero volts. This one seems to be in accordance with our alternative hypothesis. Epoch was 2012. Reset happened when battery voltage was less than 2.127 volts, and time was between 16 and 17 seconds.
The Windows phone, it also showed different pattern – here I changed the graph a little bit because I had to … it had to document the time in the photos for this, because I lacked the app. Used the phone to take photos, and the clock was reset to epoch when the battery voltage was less than 1.46 volts here. So, this is just a scatter plot showing where the phone was reset. These triangles is where the resets are and the circles are where it did go correctly. So, it’s like less than four seconds and below … our more than four seconds, and below 1.46 volts it was resetting. Epoch for this one was 2015.
It seemed to lag a little bit here. So, here I did some more tests to see if I could get it to run incorrectly, but it just seemed to lag or be stopping. It’s not a perfect linear relation when it was lagging. It’s between a factor of 0.25 and 0.4, so every second it lagged 0.4 seconds when I [held it] for 31 seconds, and only 0.25 … lagging 0.25 seconds per second held at 318 seconds, about five minutes. And the same as well with little bit less voltage. No jumps in time forward in time here either.
So, short summary? [20:54] did have a formal model for assessing time variability when documenting the time. Documenting a time with a photo, using any of the timestamps or external reference is adequate in most cases. I have very, very seldom been in a case where I need to have a precision of documenting the clock more than maybe in [tens or] seconds or minutes. So, it is very seldom we need a precision of more than one or five seconds.
But assess needed precision before collecting evidence. Also notice GPS timestamps can be imprecise indoor. One device that I tested jumped 8-12 years forward in time when battery was low. Three devices showed a lagging clock when the battery voltage was low, and one device was either correct or reset without any lag.
A little bit about the forensic implications of this. Under very specific circumstances, when battery voltage is low, clock can jump in time. My guess is that this happens because the voltage is not enough to keep the state of the [SRS registers], and therefore you get [22:24] before [22:25]. That is my guess, but I haven’t really been able to verify this. The OS will not be running when this happens at least. Voltage is so low that the OS itself will be shut down. And you will see that the clock has changed during the power-off state of the device. You don’t see that the clock is changing while the OS is running.
And yeah, that was actually everything I had. Any questions or comments?
[silence, applause]End of transcript
DFRWS EU 2019 will take place in Oslo in April – book your tickets here.
