Alternative clock drift calculations

Sometimes knowing the exact time of an event is key to an investigation. Often it isn't (it's all relative after all) but it's always important to check how reliable the times you see, are.

The easiest method is to check the computer clock against a calibrated clock, a GPS clock or radio controlled clock are ideal. If this is done reasonably soon after the 'incident' or seizure of the computer, the difference will give an accurate measure of how much time to add or subtract from the times seen during the analysis. If you don't have the original machine, can't get to the system clock or leave the computer off for an extended period without checking, you may have to work harder.

Firstly a note about what is seen, even when a valid time is obtained.

• Daylight Saving- Remember that the use of daylight saving time may have changed since the computer was last used. This is normally quite obvious with a clock being about an hour out (for many of us), but it's worth checking the date of the last use of the computer to be sure, as other factors may also be in play.
• Type of Operating System- Windows will set the computer clock to the local time so that if DST is applied, the time on the computer will be moved forward an hour. Other OSs can maintain the computer clock in local time or UTC . Dual boot systems would make things trickier still!

Event Logs

The Windows event logs can provide clues as to how accurate the clock is, or was. Stephen Bunting has some information on detecting changes in the clock settings, but it's also possible to show when Windows has synchronised with a time server.

In the System Event log, filter for W32Time as the source and look at event IDs 35 and 37. If the computer is set to automatically update the time and is regularly able to contact the time server, then the clock is likely to be reasonably accurate. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time contains more details of the settings.

Yahoo pages

Web pages from Yahoo contain a really handy line at the end of the page source that shows when that page was served. It looks something similar to this:

!-- p18.www.ird.yahoo.com compressed/chunked Wed Apr 17 21:20:10 GMT 2009 --

Whilst understanding that there may be a slight delay between this stamp and the creation of the associated internet history record, this provides a great way of determining the clock offset at this time. Just compare the internet history record, created from the computer's clock with the time stamp, created from the web server and you have your value. If you can compare a number of web pages from around the same time you can start having more confidence by averaging out the slight transmission delays.

Of course this relies on the belief that Yahoo's web servers are accurate (apparently 74% of web servers were within 10s for one study), but if this is combined with time stamps in other webpages (look for unix times, but test their relevance!) and other sources of evidence such as event logs or even good old fashioned witness accounts, you can start to have much more confidence in the times that you are including in your reports even if the case doesn't hinge on a split second degree of accuracy.

I've written a basic EnScript that looks in selected files for the Yahoo time stamp and displays that, along with the created date of the file in the console. It doesn't do anything fancy and the code is probably awful but I'll make it available here (note that it only works in EnCase 6.13 and later).