I have a drive image from which the registry has been removed (on purpose) prior to the image file being given to me. As you may have already guessed, the case itself is fictitious. I found some other threads that discuss similar topics but all relate to the analysis of media that has no OS installed (a floppy for example). It seems that the general consensus in that scenario is to use the local time zone of the area where the image file was created, however my situation is a bit different as I did not create the image file myself.
The drive has XP sp2 installed…is there anywhere ELSE besides the registry where I might be able to locate a time zone? If not, should I go with the local time zone where I am conducting the analysis from? I feel that is my only other option (and the one I've been using so far), I just don't like the feeling of 'guessing' in a report.
The drive has XP sp2 installed…is there anywhere ELSE besides the registry where I might be able to locate a time zone?
Check logs. System logs might help, but I'm thinking of AV logs, backup logs and such things.
You might also want to check cached web contents – some may contain timing info, and it should be possible to relate that to creation time.
If not, should I go with the local time zone where I am conducting the analysis from?
That would be guessing, wouldn't it? – a slightly more appropriate choice would be to use the timezone of the location where the system was used. It may be the same, but relating it to the system seems more appropriate than relating it to the examiner.
I would probably use the main time base of the timestamps – if NTFS, then UTC, if FAT then 'system time', and leave it as a 'not resolved' question to bring that time frame into proper synch with 'real time'.
You also need to consider the recipient of the report, and what he/she will do you want to ensure there are no misunderstandings, or grounds for misinterpretation, that might start a large (and costrly) activity on what eventually will be found to be insufficient grounds.
If you have Internet Explorer usage in the case then have a look at the index.dat files for the DAILY or WEEKLY history (not the main, cache or cookie histories). The records in these files contain a Local time stamp and a UTC timestamp side by side. The format is Windows FILETIME format and it is readable by my
Just extract the 8 bytes in hexadecimal format starting at offset 8 from the start of any "URL" record within these files, put it into TimeLord or Dcode, make sure there is no alteration for timezone before you convert the value and it will return the local time. Do the same for the next 8 bytes starting at offset 16 (0x10) and you'll get the same time but in UTC. The difference between the two is the timezone offset. Don't forget to account for DST, the best way to do this is to calculate the difference between Winter offsets and Summer offsets if you have them. You can then probably ascertain the timezone quite easily (using TimeLord you can browse through the timezones looking for any suitable candidates if you can't already work it out).
Regards, Paul
Are there any Restore Points available?
or maybe windir\Repair registry hive files?
If you have Internet Explorer usage in the case then have a look at the index.dat files for the DAILY or WEEKLY history (not the main, cache or cookie histories).
While this did not work when I tried it first for one of the entries the "Weekly" history (the dates were completely different days), I picked one from the "Daily" history and it worked perfectly! Thank you so much Paul. Also I like your Time Lord program…very cool.
There are WINDOWS/Repair hive files that I completely overlooked…the time zone was right there the whole time as was a wealth of other information I needed. Strange that whoever designed the case knew to remove the WINDOWS/system32/config files but not WINDOWS/Repair ones…oh well at least I learned a new trick with the index.dat time differences!