Lisa,
I found the same things a while back while comparing Sleuth Kit NTFS
times with other tools. The short answer is that Windows 2K (the only
version of Windows that I tested) and EnCase 3 (the only Windows-based
forensic tool that I tested) do not properly handle day light savings.
If you create a file during daylight savings and get the details
during non-daylight savings, then it will be an hour early. If the
opposite happens, then you will be an hour late. Linux and The Sleuth
Kit handle it correctly if the correct timezone variable (i.e.
EST5EDT) is given.
I made the following table of what needs to be done. The hour
subtraction / addition logic that needs to be applied is:
| Current time on analysis system |
| non-DST | DST |
----------------------+----------------+------------------|
Suspect Date non-DST | 0 | -1 |
----------------------+----------------+------------------|
Suspect Date DST | +1 | 0 |
----------------------------------------------------------|
where the DST times (for the US) are 2AM on the first Sunday of April
to 2AM on the last sunday of October and the non-DST times are the
rest of the year. The same logic seems to be required for EU
"Summertime".
I have been told that EnCase 4 fixes this, but have not tested it. I
also sent an email to cftt@yahoo to see if other Windows tools do the
same and did not get any replies. I would be interested in which
tools you tried.
Also note that this will only happen with NTFS because FAT does not
care about timezones or daylight savings.
A quick answer to why this happens is that NTFS, UFS, and EXTxFS file
systems save the time in GMT. The OS then converts the GMT time to
the local time. That is why you need to change the timezone of the
computer when using some Windows tools to get accurate times. It
seems that Windows adds a static value when changing from GMT to
localtime instead of adding two values depending on the date.
For those that want to test this, set your Windows clock to 1:58 AM
April 6, 2003 and make sure the option to change for Daylight Savings
is checked. Make a file and note that the create time is 1:58. Let
the system change from 2AM to 3AM and check the date on the file
again. It will say 2:58 AM.
brian
Lisa Dokes <securitylistsat_private> said:
> Folks: I'm currently conducting an investigation in relationship to
alleged
> inappropriate Internet activity.
>
> My initial results showed some very early (in the morning) access
times, so
> I cross validated with a few different tools. There are a few
questions I
> have however that I'm hoping I can get some help with. The system I'm
> examining was used is in the same time zone as me.
>
> 1. Does it matter that I'm extracting data created in a different
time of
> year? For example, we are currently in Daylight savings time. Some
of the
> data I’ve extracted was created during a period that would have been
> Standard time.
>
> 2. Shouldn't the MAC times still be what they were at the time the
data was
> created/accessed, or am I seeing an hour difference?
>
> 3. If I'm seeing an hour difference, why?
>
> I'm rather puzzled by all of this. I spoke with another examiner
and he
> succeeded in confusing me more. Shouldn't the MAC times always be
correct,
> regardless of the time zone that the forensic examiner is in?
>
--
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sat May 10 2003 - 06:54:00 PDT