My research as a journalist involves resolving a conflict about time stamps on a computer seized by LE.
DST in the US changed in 2007 so that a computer that had been not updated after the change could be recording incorrect time stamps for a few weeks.
Prior to the 2007 changeover, the DST local time clocks would be moved forward one hour on the first Sunday in April, or in 2006, April 2, 2006.
However in 2007 when the DST change in the US took effect, the DST clocks moved forward the second Sunday in March, or in 2007, March 11, 2007.
So if a computer had not been updated after the 2007 DST change, the computer time stamps {assuming they had not been manually changed by the user} could be recording times one hour earlier than actual local time.
Here is the readout from the computer on this issue. I believe it is from Encase.
OS Info
Product Name Microsoft Windows XP
Current Version 5.1
Registered Owner
Registered Organization
System Root C\WINDOWS
Current Build Number 2600
Path Name C\WINDOWS
Product ID 55277-OEM-0011903-00106
Last Service Pack Service Pack 1
Product Key
VersionNumber
Source Path D\i386
Install Date 09/24/05 075442PM
Last Shutdown Time 07/16/08 042228PM
TimeZone Info
Current control set is 001
Default control set is 001
Failed control set is 000
LastKnownGood control set is 003
Standard time bias is -500 hours offset from GMT.
StandardName Eastern Standard Time
Standard time is set to change the Standard bias by 0 minutes.
Standard time is set to change on Sunday of the 5th week of October, at 0200 hours.
DaylightName Eastern Daylight Time
Daylight savings is set to change the Standard bias by 60 minutes.
Daylight savings time is set to change on Sunday of the 1st week of April, at 0200 hours.
Active time bias is -400 hours offset from GMT.
The current time setting is -400 hours offset from GMT.
The offset must be either added or subtracted from GMT depending on the time zone location
Note the references to first week in April and fifth week on October are the pre-2006 parameters for DST in the US.
Can I correctly conclude that it is reasonable to consider that timestamps on some files between March 11, 2007 and April 2, 2007 could be off by one hour? That is, the time stamps could be one hour earlier than actual local time?
The essential piece of information that you're missing here is the file system.
NTFS file times are recorded in the MFT in UTC format, which is analogous to GMT time. Therefore, in their raw format, the time zone is irrelevant; translation of those time stamps for review will be affected, however.
You'll run into problems depending upon how you go about your analysis. For example, tools such as EnCase can be configured to display the time stamps on files in local system time with respect to the analysis system itself, based on the time zone settings of the system being examined, or based on UTC format. As such, analysts need to be aware of this, and take it into account.
I tend to perform most of my analysis based on UTC times, and then translate to the time local to the system itself, as necessary.
Can I correctly conclude that it is reasonable to consider that timestamps on some files between March 11, 2007 and April 2, 2007 could be off by one hour?
Not on the grounds you have provided.
NTFS file system timestamps are always UTC (or, to be correct, UTC without leap seconds), and so are not affected by DST issues. Quite a lot of other timestamps (in system logs, etc) are also kept in UTC format, so the same goes for them.
Any logs kept in local time, however, such as some browser history, are places where there may be problems.
If the relevant hard disks volumes use the FAT file system, however, it's another thing FAT logs all file timestamps in local time, and so the effects you mention would be present.
And if you are looking at CDs in ISO-9660 format, it could easily go for them as well, as it's never been strictly defined which time zone they should use. It would depend on the CD burning software.
Also … as it seems that EnCase has been used …
EnCase time zone interpretation is a nice little problem of its own in some cases, the analyst just lets EnCase go ahead and deduce the correct timezone adjustment to apply to UTC timestamps. Usually, it gets it right, but there are situations when it doesn't. (This could be one of them – as the system appears to be misconfigured to start with). And of course, there are situations when an uninformed analyst manually selects a timezone that 'looks like' the expected one, but which has different DST rules. Double-checking that the right time-zone configuration has been applied is important.
If EnCase has been misconfigured, for whatever reason, it will show the wrong timestamp translations. And if EnCase's timestamp translation need to be compared with 'real' local timestamps (i.e. time information from somewhere else and that follow the real DST rules), things can get confusing.
The TimeZone information you provide is (I'm fairly certain) how the examined system was configured – that is, what time would a local user see. The next question is how EnCase is configured – what time does the analyst see? The same thing as the local user, or something slightly different, or even wildly different?
Thanks KeyDet89
I am studying your reply.
The points you mentioned about the examiner choosing which time stamp configuration to use is one I am considering.
I am also looking at whether it could be reasonable for a handful of files to be time stamped one hour off differently than the majority of the files?
I was hopeful that something like a DST error during the changeover in 2007 could offer a reasonable explanation for that possibility.