sleuthkit-users

[sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

Help! I'm confused by the way sleuthkit (with autopsy) is handling timestamps 
on a FAT32 filesystem.

I need to be able to establish an accurate timeline for one particular day and 
have managed to set things up so that I can get some sort of timelime, but I 
don't really understand how the timezone setting in Autopsy affects the 
results. (The skew concept is fine - I need to correct for a hw clock that's 
15 minutes fast so I've set it to +900).

The situation is this - the day in question falls during GMT time, but we're 
now into BST. I've set the timezone in autopsy to be GB, but have discovered 
a conflict in one of the files I'm looking at - it's a log file and the 
application generating it has stamped the time in the file as an hour later 
than the last write time on the file itself.

For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly in 
BST at the moment.

Re: [sleuthkit-users] FAT filesystem timestamp confusion

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

Angus Marshall <an...@n-...> said:
 
> The situation is this - the day in question falls during GMT time, but we're 
> now into BST. I've set the timezone in autopsy to be GB, but have discovered 
> a conflict in one of the files I'm looking at - it's a log file and the 
> application generating it has stamped the time in the file as an hour later 
> than the last write time on the file itself.
> 
> For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly in 
> BST at the moment.

Angus,

First, FAT does not care about time zones.  Most file systems store the time
with respect to GMT and when the time is actually read the local OS adjusts
accordingly.  FAT just saves the time and does not care about the timezone, so
that is why you will not see a difference when you change the timezone in
Autopsy. 

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

Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:
> Angus Marshall <an...@n-...> said:
> > The situation is this - the day in question falls during GMT time, but
> > we're now into BST. I've set the timezone in autopsy to be GB, but have
> > discovered a conflict in one of the files I'm looking at - it's a log
> > file and the application generating it has stamped the time in the file
> > as an hour later than the last write time on the file itself.
> >
> > For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly
> > in BST at the moment.
>
> Angus,
>
> First, FAT does not care about time zones.  Most file systems store the
> time with respect to GMT and when the time is actually read the local OS
> adjusts accordingly.  FAT just saves the time and does not care about the
> timezone, so that is why you will not see a difference when you change the
> timezone in Autopsy.
>
> 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)


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)

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

Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

On Friday 04 Apr 2003 12:10 am, you wrote:
> Angus Marshall <an...@n-...> said:
> > On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:
> 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.

Interesting - OK, I'll tweak the workstation tomorrow so that it's locked into 
GMT and also change the autopsy config to lock that to GMT too. I'll report 
back sometime over the weekend.


> > 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?

ls gives the correct modification time of 21:45

Re: [sleuthkit-users] FAT filesystem timestamp confusion

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

> > > 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?
> 
> ls gives the correct modification time of 21:45

Are all (W, A, and C) of the times set to 2:45 or just some of them?  You can
get all of them via the File Mode in Autopsy.  I've seen some FAT images with
a couple of random times that are way off.  

If they are all way off, can you send me the parent directory contents (off
list)?  This is easily done by finding out the meta data address of the parent
directory (800 for example) and using icat:

    # icat -f fat12 img.dd 800 > dir.dat

The only thing in there are the file names, times, and starting cluster. 
Nothing sensitive.

brian