Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Brian C. <ca...@sl...>]

Angus Marshall <an...@n-...> said:

> On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:

> >
> > That really doesn't explain the log entry time versus the file time though.
> > The only thing that I can think about is that Windows does not handle day
> > light savings (or BST) well at all!  I sent a message about this to the
> > forensic tool testing list a while back.  In Windows, you can make a file
> > before day light savings takes effect, let the clock roll over and then
> > check the time again and it will be off by an hour!  Windows appears to
> > subtract an hour from all files during these time frames instead of just
> > the ones during those 6 months. (EnCase v3 does the same thing).
> >
> > Therefore, I wonder if the problem is because Linux is changing the time by
> > an hour when it displays it, but since Windows didn't then it is having
> > issues. What happens if you set the timezone to GMT (or even EST) and not
> > one of the timezones that changes (like EST5EDT).  Does that help?
> >
> > brian
> 
> Wow! thanks for the fast reply Brian.
> 
> Setting the zone to GMT does seem to make the filesystem timestamp
> consistent with the file contents, but I'd really like to know why it makes 
> a difference at all on a FAT filesystem in this case. I have to give some 
> initial findings to the police tomorrow and am wary of giving them 
> potentially wrong info. because it could affect an alibi. (Side note, when I 
> mount the image read-only and issue a ls --full-time, I notice that some 
> files have an offset field of 0000 and some have +0100 - could my experience 
> be an artefact of something "clever" in the Linux system I'm using ? ls on 
> the files being questioned above agrees with the results of the timeline 
> analysis btw)

The Sleuth Kit (and I would imagine Linux) reads the time from the FAT image
and translate it into a UNIX time (which is an offset relative to GMT).  It
then uses the 'localtime' function that translates the UNIX time (a big
number) to a human readable format.  That function takes the timezone and
savings time into account and adjusts accordingly.  Therefore, that function
is changing the time unless the timezone is set to one that does not change.


> I've also noticed a curious behaviopur with FAT12 on the latest sleuthkit 
> release. Files on a floppy were written to it at 21:45BST, with the timezone 
> set to GMT0BST, they show as 2:45 tomorrow in the timeline. (file writes and 
> analysis done on the same machine btw)

What does a 'ls' or 'dir' show?

brian