Creation time, Modified time and Accessed time

zimbo

First rule of computer forensics - be very careful about accepting as gospel anything you are told in a forum, or anywhere else for that matter. There are some very experienced and wise practitioners here but test everything yourself in the environment in which your hypothesis has to stand. This equally applies to what you read on MSDN or anywhere else which you might consider as an official source, MSDN and other such resources are not written for forensic purposes. Equally treat what I say with such scepticism.

If you are writing a report use and choose your words carefully.

So for example "Last written This date and time will be updated even if the file is opened, viewed and saved as itself with the same filename and no changes being made to the actual files data."

Test this yourself and see if this applies in all circumstances; try it with a txt document in Notepad and then try it with a Word document. Open a Word document in Word doing nothing else then click save and close, check the times. Do the same but chose Save As with the same filename. What happens?

"Last Accessed The last time the file was viewed, but not changed. "

In XP view a file in as many different ways as you can think of, does the Last Accessed get updated? Does the Accessed date get updated straight away or might there be a delay? Restart the computer, has this made any difference?

View a file, change it and then save, has the Last Accessed been updated as well as the Last Modified. Do this with different file types, do it with the same file type but different applications. Is the statement above "Last Accessed The last time the file was viewed, but not changed." accurate?

In Vista open a txt in Notepad and change it and then save, are the Modified and Accessed dates the same? Do this with a Word document in MS Word and check the Modified and Accessed dates, is the behaviour the same?

Second Rule - nothing is ever simple in computer forensics.

H

Does this mean that the file was created on the 12th Aug at 1134 or is this time something else? Am i right in assuming the file was last modified on the 14th July? Also if I was to examine the meta-data for the doc I find different times to the above. Which one is right?

A couple of things to look at…

First, what is the context? What is the file system in question?

Next, if the file system is NTFS, the information you presented is most often retrieved from the $STANDARD_INFORMATION attribute. Parse the $MFT and compare the creation date in the $FILE_NAME attribute.

Then consider where the file originated. Was it downloaded from the Internet? If the OS is Windows XP SP 2, you should find a Zone.Identifier ADS to go along with the file. Was the file extracted from an archive?

Basically Im looking to find out when the file was created because I think I understand the last two, what I cant get my head around is how the created time is AFTER the modified time.

Did you check the .doc file metadata?

Some references

http//support.microsoft.com/?kbid=299648
http//msdn.microsoft.com/en-us/library/ms724290%28VS.85%29.aspx

There's also the interesting concept of 'NTFS tunneling' mentioned in Windows Internals 5th ed., p. 947-8, and also in KB 172190.

"With tunneling, any new file created with the same name as [ the deleted or renamed original file], and within a certain period of time, will keep some of the same metadata."

When a file name is removed from a directory (i.e. deleted or renamed), long name, short name and creation time is saved into a cache. If a new file appears in the same place with the same name (by create or rename) within a period of 15 seconds, the cached data is applied to the new file.

The KB article only lists NT and 2000, but as WI5 relates to Vista and Windows Server 2008, I can only assume it's general NTFS behaviour.

So … created date and time could, in certain circumstances, indicate not when the current file was created, but when its immediate predecessor was created … or it's predecessor, in turn, recursively. (That probably explains some weird things I've seen with document files …)

Those 15 seconds come from HKLM\System\CurrentControlSet\Control\FileSystem\MaximumTunnelEntryAgeInSeconds … and tunnelling can also be disabled by setting …\MaximumTunnelEntries to 0 (which may cause older applications to break).

Hm. Can't remember I have seen this behaviour mentioned anywhere before – wonder how many apple-carts it might upset. And just imagine what secrets might still be lurking in KB entries for NT and not repeated since …

There's also the interesting concept of 'NTFS tunneling' mentioned in Windows Internals 5th ed., p. 947-8, and also in KB 172190.

"With tunneling, any new file created with the same name as [ the deleted or renamed original file], and within a certain period of time, will keep some of the same metadata."

[snip]

Hm. Can't remember I have seen this behaviour mentioned anywhere before – wonder how many apple-carts it might upset. And just imagine what secrets might still be lurking in KB entries for NT and not repeated since …

I ran across the issue of file system tunneling when working on research for Adobe Flash cookies. I had a hard time figuring out the behavior that I was seeing regarding Flash cookie metadata until Eoghan Casey rode to my rescue and taught me about file system tunneling.

Kristinn Gudjonsson is my research partner for this effort and we're working on a white paper that is shaping up (if we do say so ourselves) to be pretty interesting. It will be of interest for a variety of audiences, we think, because it touches on timeline analysis, browser forensics and almost certainly mobile device forensics once Flash Player 10.1 is released.

I will be presenting on the topic of Adobe Flash cookies at Guidance's CEIC conference and the last portion of the presentation will cover file system tunneling.

The actual paper will have a lot more information and depth to it, as you might imagine, but the presentation will give attendees a strong overview and understanding of these artifacts.