Re: [sleuthkit-users] Tsk_loaddb timezone?

[Simson G. <si...@ac...>]

Luis,

You are correct:
	— NTFS stores in UTC
	— -z is not relevant for NTFS.

When testing this, you need to consider not just if DST was in effect when the files were written, but also if it is in effect when the files are viewed. Earlier versions of EnCase would change the file timestamps depending on whether you viewed the file in winter or summer. I believe that this was fixed in later versions.

Simson


> On Aug 26, 2016, at 10:03 AM, Luís Filipe Nassif <lfc...@gm...> wrote:
> 
> Hi Simson,
> 
> I've tested on NTFS images too, and the timestamps are stored ok in the database as UTC, regardless of being daylight savings time or not, and with or without the ported -z option. As I understood, I think -z option is to specify the original timezone of the evidence being ingested, it is not relevant to NTFS, but is to FAT. That is different from ajusting the timestamps to a specific timezone used by the investigator during an analisys.
> 
> So I think tsk stores timestamps as UTC, and I think tsk_loaddb needs -z option to work with FAT images. That option exists in JavaBindings api because it is needed.
> 
> Another problem is that I've observed the difference between the timestamps shown by Windows and the ones stored by tsk_loadb is -3 hours (because of UTC-3 timezone, that's ok) for most files but is only -1 hour when it should be -2 hours for timestamps in daylight saving time. I think tsk assumes (without -z option) FAT timestamps are stored with daylight saving time conversion, but they may be not.
> 
> I agree with you that different systems (Windows, Linux, Cameras and Cell phones) may store the timestamps on FAT by different ways, with or without daylight saving time, as UTC or not, so I think the -z option is important to let the user specify.
> 
> Luis
> 
> 2016-08-25 22:56 GMT-03:00 Simson Garfinkel <si...@ac... <mailto:si...@ac...>>:
> Testing on FAT32 images is not enough. My belief is that different operating systems have different behavior.
> 
> MSDOS, for example, only had one concept of time — local time. When daylight savings came around it was the responsibility of the operator to change the clock accordingly. Back in the 1980s this was one of the big advantages of Unix over DOS.  
> 
> Windows 3.1 did include timezone support. A program called TZEDIT allowed editing the time zone information.  Apparently TZEDIT was available in 1995 (https://www.reasoncoresecurity.com/tzedit.exe-ff22959d3c2875308b1a47481964b44b95177128.aspx <https://www.reasoncoresecurity.com/tzedit.exe-ff22959d3c2875308b1a47481964b44b95177128.aspx>); I think that it was available earlier. 
> 
> There was always problems with times being wrong when the timezone flipped. I don't remember how DOS file timestamps changed after a daylight savings time change. The times might have changed, but they might not.  Some forensic tools allow you to specify the timezone and whether or not daylight savings time is in effect for looking at DOS partitions. That is what the "-z" option does.  It's not clear to me if tsk_loaddb requires the -z option or not; it depends on if local time or UTC time is being put in the database.
> 
> Simson
> 
> 
> 
>> On Aug 25, 2016, at 4:56 PM, Luís Filipe Nassif <lfc...@gm... <mailto:lfc...@gm...>> wrote:
>> 
>> I've done some tests with two real life FAT32 images and I think the timestamps are being incorreclty decoded by tsk_loaddb. It seems to use local timezone, UTC-3 here at São Paulo, and to store UTC timestamps in the generated sqlite for most files. The problem is with timestamps in daylight saving periods. For example, Windows shows 07:00 and tsk_loaddb stores 10:00 for a file not in daylight saving time, it is ok. But for a file in daylight saving time, Windows shows 08:00 and tsk_loaddb stores 09:00 when it should store 10:00 UTC. FTKImager shows 07:00 for that file.
>> 
>> I think timestamps are stored in FAT FS without daylight saving conversions, as I decoded with a hex viewer. I think Windows does the conversion on demand (+1 hour) when it displays the files in Explorer. But I think tsk is considering that timestamps are stored in FAT FS with daylight saving calculations, what I think is not the case. That explains the difference of only 1hour between Windows and loaddb, when it should be 2hours for a file in daylight saving period on a system at UTC-3 (UTC-2 with daylight saving).
>> 
>> I observed tsk_loaddb lacks -z option to configure timezone, but that option is present in fls, ifind, istat, tsk_gettimes.... I've ported -z option to tsk_loaddb and run it with -z BRT3 (without daylight saving) to force it to not do daylight saving calculations, that produced the expected output in sqlite.
>> 
>> Luis
>> 
>> 2016-08-25 15:33 GMT-03:00 Ketil Froyn <ke...@fr... <mailto:ke...@fr...>>:
>> I think it uses local timezone. I reported this issue in Autopsy where
>> FAT timestamps are interpreted as a local timezone, and I'll assume
>> that tsk_loaddb would have done the same:
>> 
>> https://github.com/sleuthkit/autopsy/issues/1687 <https://github.com/sleuthkit/autopsy/issues/1687>
>> 
>> It should be fairly straightforward to test, though. Create a small
>> sample image with dd and mkfs -t fat, mount it loopback, create some
>> files, and finally run tsk_loaddb on the resulting image file to
>> compare tsk's file dates with the ones you set.
>> 
>> On 24 August 2016 at 21:38, Luís Filipe Nassif <lfc...@gm... <mailto:lfc...@gm...>> wrote:
>> > Hi,
>> >
>> > Anyone knows the answer? Does tsk_loaddb use UTC ou local timezone to
>> > interpret FAT FS dates?
>> >
>> > Thanks,
>> > Luis
>> >
>> >
>> > 2016-06-17 13:11 GMT-03:00 Luís Filipe Nassif <lfc...@gm... <mailto:lfc...@gm...>>:
>> >>
>> >> Hi,
>> >>
>> >> What timezone does tskloaddb use for fat file systems? It is possible to
>> >> configure it like Java bindings addimageprocess?
>> >>
>> >> Thank you,
>> >> Luis
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > sleuthkit-users mailing list
>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users <https://lists.sourceforge.net/lists/listinfo/sleuthkit-users>
>> > http://www.sleuthkit.org <http://www.sleuthkit.org/>
>> >
>> 
>> 
>> 
>> --
>> -Ketil
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users <https://lists.sourceforge.net/lists/listinfo/sleuthkit-users>
>> http://www.sleuthkit.org <http://www.sleuthkit.org/>
> 
>