[sleuthkit-users] Re: [linux_forensics] File Dates and Times

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

Ok, problem fixed in The Sleuth Kit (but read on). The solution is more 
elegant and uses the 'mktime()' function instead of a manual 
calculation.  The new fatfs.c file can be found here:

http://sleuthkit.sourceforge.net/sleuthkit/fatfs.c

Replace the one in src/fstools and recompile.  The fix will be in the 
next release.

But, the code that I was using was based on the OpenBSD kernel code, 
which is basically the same as the Linux code:

http://lxr.linux.no/source/fs/fat/misc.c?v=2.6.0#L215

That function does not take daylight savings into account.  Therefore, 
I wanted to mount my test image in Linux to see what it gave for 
results.  When I did this on a redhat 8 system, the times were 5 hours 
slow ... (not fast like is expected if it were set to GMT).  Is there a 
flag I need to set somewhere, or is this normal?  The timezone of my 
system is set to EST and I haven't done much with FAT in loopback on 
this system, so I'm not sure if it is my system configuration or not.

So, based on the FAT kernel code, it seems that Linux has the same 
problem unless daylight savings is taken into account somewhere else in 
the kernel.  Can anyone else verify this by comparing the M- or C-time 
of a file made in the summer in Windows and in Linux?

thanks,
brian



On Tuesday, January 20, 2004, at 10:03  AM, Brian Carrier wrote:

> Randall,
>
> Don't be so confident  yet :)
>
> I just tested something on a random file and image before I replied to
> this and I think I may have identified a problem.  Is the date of the
> file in daylight savings time?
>
> FAT does not care about timezones, but The Sleuth Kit makes it care
> about timezones by converting the FAT time into the UNIX time (which is
> timezone relative).  The conversion may break down with daylight
> savings.  I'll fix it later today.
>
> I added a bug report for it:
> https://sourceforge.net/tracker/
> index.php?func=detail&aid=880606&group_id=55685&atid=477889
>
> How ironic.  EnCase v3 used to ignore daylight savings and now I'm
> using it when it is not needed.
>
> brian
>
>
> On Tuesday, January 20, 2004, at 09:20  AM, Randall Shane wrote:
>
>> To Our Collective Group,
>>
>> I am analyzing a Windows ME machine and there seems to be some
>> discrepency in file dates.  I was hoping for some input.  My analysis
>> through Autopsy reveals a deletion time in the 9 o'clock range.  I had
>> a peer
>> review my work and utilizing two separate utilites, X-ways-trace and
>> the encase
>> info
>> record finder script, both read the Info2 file recycler 'log' as the
>> deletion occurring in the 8 o'clock range.
>>
>> Here's my question - The system time was set to CST, (confirmed
>> through registry
>>
>> settings), and this is consistent with what was plugged into Autopsy.
>> I am
>> confident
>> that the file deletion times from Autopsy are accurate but how can I
>> validate
>> this?