Do You Have The Time (or What Time Is It



Do You Have The Time (or What Time Is It? Really)

Article by Dan Mares, The Norcross Group, and Mares and Company

When asked, do you have the time, or what time is it? Most people don't have a problem answering. They look at the clock on the wall and respond accordingly. However, when you ask the same question of a computer forensic analyst they may ask you to clarify what you really want and may ask you a number of other questions regarding time.

The analyst may ask: what file system are you using? (FAT, NTFS, *IX, HFS, etc); do you want the time in GMT/UTC/ZULU/Local time; do you want the modified, creation, last access, last change, or entry modified time; do you want the internal files meta-data time; what starting reference or Epoch time is being used; and maybe one or two other questions.

In a very basic and hopefully non-technical fashion I'm going to try and make some basic sense out of the different ways to interpret, explain, and more importantly ask for the time type you "Really" want.

The file time(s) may be important in almost any investigation or analysis. The time is also important when trying to associate file, electronic document or an e-mail date in e-discovery and other data preservation scenarios. So knowing what to ask for and how to interpret it may be something that can make or break a case.

Before getting into the specifics about file times, we must understand that the analyst must know and feel confident that the computer system, which housed the file(s) in question, had the correct time setting. If the computer BIOS time was not set correctly, then it becomes incumbent on the analyst to make necessary adjustments, probably manually, to whatever time values they arrive at. This can be something as simple as determining if the BIOS date/time was set to UTC or Local time.

To keep things relatively simple, we will assume that the computer files were generated using one of the current Microsoft operating systems (Win2000, XP, Vista, etc) which will allow us to concentrate on the three main file times (and a mention of a forensically obtainable 4th) and that we are writing to either and NTFS or FAT file system. Files on the Unix (*IX), HFS and other Macintosh file systems will probably behave differently, not only because they are using a different Epoch starting date, but also because the operating system may interpret what is stored in the time value differently. The user will have to research those differences.

We will define the three main file dates maintained on the Microsoft file systems (NTFS and FAT), and see how each date may be affected by the OS or the users actions. These file dates are considered part of the files' attributes, just the same as the file size and filename. For the sake of brevity, the terms date and time are used interchangeably, and when we mention date or time, we actually mean the stored value which when "decoded" is the date and time of the file.

Although it is specific to Microsoft WORD internally stored time metadata, an interesting background and technical reference can be found here:

Also, it is important to realize that, depending on the file system NTFS, FAT, *IX the file time is maintained in different formats. The Microsoft programmers library article at: (VS.85).aspx

Contains the following information:

A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). The system records file times when applications create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer. For example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume.

At this rate, the 64-bit value will probably hold up into the year 60,000. Long after we have changed our way of keeping time.

Point to remember: depending on the file system, the dates are stored differently.

While the *IX file systems maintain time stamps as the number of seconds since the start of the Unix Epoch of January 1st, 1970 (UTC). Drilling down in Wikipedia () you will find Epoch defined as a reference date. (Unix Epoch is January 1, 1970, while HFS is not).

Thus, converting stored times from one file system to another may have its own problems.

Another interesting point is found at:

When you copy a file from a Windows NT file system (NTFS) drive to a file allocation table (FAT) drive, the time stamp changes to an even number of seconds.

File time stamps on FAT drives are rounded to the nearest two seconds (even number) when the file is written to the drive. The file time stamps on NTFS drives are rounded to the nearest 100 nanoseconds when the file is written to the drive. Consequently, file time stamps on FAT drives always end with an even number of seconds, while file time stamps on NTFS drives can end with either even or odd number of seconds.

As you can see, there are a lot of little nuances which may have to be considered when discussing file times, and it is always better to research and test items for yourself.

Now lets see what these three file times are and how they are interpreted.

Creation Time:

The date the file was first placed or written to this media/drive. In our current example (see below) it can be considered to be the file date that a person wrote the document and first saved it to a drive. In other instances it could also refer to the file being first placed at a specific (but different) location on the same drive. (Remember the word "first" and the phrase "first placed or written", for later reference).

If we open WORD, choose a file(new operation and then do a save-as, the creation date will be the current date of this action. Because it is the first time this document was "created". For the file listed below, the creation time, and first saves of the sample.doc is June 30, 2005 at 10:39 Eastern time. (We will signify the modified or write, access and created times with an m, a or c after the listed time to be able to easily differentiate the time being displayed). Combining the m, a, c designation is where the acronym MAC date/time comes from.

Created: Original folder location on a drive shows the file is about 4 years old:

sample.doc 06/30/2005 10:39c EST (eastern standard time)

Now, using a command prompt (window), simply copy the file up one level to a higher folder, (C:>copy sample.doc .. ) the new creation date becomes March 28, 2009 at 7:54 AM, Eastern time. The file is copied to a new folder one level up on same drive, using the same name, we get:

sample.doc 03/28/2009 07:54c EST

This is an example of the creation date being changed because the new file (even though it has the same name, and is in fact the same file) is now "placed at a specific" location on the drive. Was this document really first created in 2009? Not at all, it was created at this specific location in 2009. But the original was created in 2005.

Lets take that file and copy it to a different drive. (C:>copy sample.doc d:\ ) we get:

sample.doc 03/28/2009 09:00c EST

Notice the creation date now becomes the date that the file is first placed on this other drive. We now have three different creation dates for the same file.

sample.doc 06/30/2005 10:39c EST (original)

sample.doc 03/28/2009 07:54c EST (copy #1 up a level)

sample.doc 03/28/2009 09:00c EST (copy #2 to different drive)

Which one is correct? Well, all are correct in their respective right, but you will probably look at the earliest creation date as the true first time this file came into existence. But how would you explain your reasoning to a reviewer or jury. And how could you tell just by looking at the creation time, that this is the true first creation time?

How the "creation date" is arrived at will follow for most files that are first created on a drive or new location. It is probably the easiest to understand, when the file was "created" at this location means "put there". Simple, yes/no?

Modified or Last Written Time:

The modified or last written date is the date that a user last opened the file and possibly modified or edited the file contents and subsequently "wrote" the altered contents back to the disk. Be careful, that you understand the content change may include internal metadata contents, which the user isn’t normally concerned with. Which is discussed next.

An apparent anomaly sometimes appears when dealing with Microsoft WORD if the user only opens an existing file for the purpose of printing. In this case, after the printing has taken place and the user attempts to close the file, the last written date is only updated if the user responds positively to the prompt "Do you want to save changes, etc...". If the user declines to save the changes to the document that was opened "only" for printing, then the last written date is NOT adjusted. This apparent anomaly is caused by the fact that (some versions of) WORD generally keeps (among other dates) an internal metadata reference to the last printed date. In order to update that internal metadata, the file MUST be saved, and thus the metadata contents modified when it is written to disk.

I have also found that if you open a file in WORD, and examine the “properties” tab under the file menu, when you go to close the file, you are asked to save it. Apparently the process of examining the properties tab will cause a modification/write date update also.

There are probably a number of other “non-editing” situations, which will cause WORD to update the modification date, and the user needs to verify for themselves the changes, being aware that different versions of WORD may act differently. (So what else is new?).

In most other situations where you are not using WORD the last written is truly the date that a modified file is "saved" to the drive. Depending on the application being used, this "saved" operation can take the form of many prompts and may even be automatic and not user prompted. Just keep in mind, that the most common and logical explanation of last written, is when the file is actually "saved" or "save as" to the drive. Regardless of whether any actual changes were made, the OS thinks changes were made and thus modifies the last written time. You may hear the term last written and modified used interchangeably for this date item.

For our sample file,

Original last written time:

sample.doc 06/30/2005 10:40m EST

Notice it is one minute later than the creation time. This is to be expected, and understandable as the file was probably only opened for a short time before saving and closing it. With documents or files, which a user edits and routinely saves, it is not uncommon for the modified time to be a few minutes after the creation time.

That same file, when copied to a folder one level above, still maintains the modified time, because obviously, it was not modified/edited, and was only copied. So there was no reason the OS needed to change the modified time.

sample.doc 06/30/2005 10:40m EST

but the creation date is still the newly created (copied) date :

sample.doc 03/28/2009 07:54c EST

Notice that the current creation time of 3/28/2009 07:54c is about 4 years newer than the last write time of 6/30/2005. Many people ask how can a file be created after it is written? The answer lies in the explanation that it was last modified somewhere else, well before it was merely copied to this new location. And at this new location it was only "created" on the disk, and not edited, modified or in any other way "saved" to disk. (BUT as seen before, could have been printed and the print date not recorded).

This apparent anomaly in time differences can be used to show that a file was originally created somewhere else, and only now at a later date copied to this current resting place. If you see a written date before the created date, you can be pretty sure there was a prior version sitting at another location.

And finally, the copy results to another drive shows that the modified or last write time is still maintained as the original, even though it was copied to and written to another drive. The use us external thumb (USB) storage drives is a common example of this situation.

sample.doc 06/30/2005 10:40m EST

That concludes two out of three file times.

Last Access Date:

The last access date (time) is the time when the file was accessed or otherwise opened in some way by an application. The process, which changes the access date, can be one of many things. Some of the more common are: opening a file for; copying, viewing (even if you don't make changes), virus check, printing, or editing. Opening a file for just about anything will cause the last access date to be updated. Do not confuse the opening or mere access of a file with the update or modification to the file contents which would cause the modified date to be adjusted accordingly.

Moving (renaming) a file in place DOES NOT appear to alter the last access date. This is because that rename operation is taken not on the file, but on the directory that contains the file. The MFT entry modified date (see below) would be updated in this case.

The last access date of our original sample file after the 2nd copy operation is now:

sample.doc 03/28/2009 09:00a EST

This last access time is a result of the most recent copy process, which copied the file from the original drive to the external or in this case the d: drive.

There is not much more that can be said about last access date, except that if you use an application to "access" the file, the access date will be updated. However, with computers and programs “There are always exceptions”.

MFT Entry Modified Date:

The fourth date found in the NTFS file system, and not seen by the normal computer user is the MFT Entry Modified Date.

A simple explanation is the date that the MFT entry for this file is modified. One action to generate this change would be a renaming of the file. Other situations may occur which only update this value, possibly the date at which the file is deleted, but the readers will have to research that for themselves. Also, this date is not available for the casual user to view. It is usually only seen when a forensic tool can access the MFT and decode the value.

Microsoft WORD internal Metadata Time properties.

In addition to the system dates, which are maintained and seen by the user when viewing the dates using Explorer, Microsoft WORD keeps another 4 dates within the document. These are internal metadata that can be viewed when listing the file(properties option. The 4 dates are, modified, accessed, created, and printed. The dates may or may not be maintained depending on the version of WORD being used. But a major item for an analyst to make use of is the file created date.

Lets assume we have a document that was created on January 1. It would have a file system date of January 1 for create and modified dates.

Now, we copy the file to an external USB drive on June 1, and also edit it on that date. The created and modified date on the USB drive would be June 1. And at first glance, one might assume that this was the first instance of the file. Since the file create (date it was first placed on the drive) and modified date are the same. However, one thing, which Microsoft WORD does for us, is that the internal metadata creation date is the true first time the file was created. Review of the metadata properties tab of the file shows a creation date of January 1. Case solved.

Additional things to consider about file dates.

• Check out this page for a really good explanation of when the file dates are changed relative to the FAT and NTFS file systems.

• The fat file system DOES not keep record of the last access time. It only maintains last access date. So when manipulating files on FAT file systems, there is no last access time maintained. So the resolution for access times on FAT file systems is 1 day.

• FAT modification/write time has a resolution of 2 seconds. Which means you will never see a FAT file system write time with an odd second.

• File times on NTFS are rounded to the nearest 100 nanoseconds. But special software (usually forensic) is needed to see anything smaller than the seconds.

• On NTFS file systems; last access time is generally updated in one-hour granularity. So any access within that hour will usually not cause a new update. Meaning the last access time will only get you in the ballpark, but no cigar.

• In Windows Vista, the updating of the last access date has been turned off by default. This was done most likely for efficiency purposes. The good and bad is that the last access date is not updated, but the last access date recorded is most probably the creation date of the file.

• When, in Explorer, you "right click" on a file to show file properties, the access date is changed to that moment in time. Why? Possibly because the explorer program by default tries to open the file and see if there is an embedded icon within the file (you know, these are the icons displayed in the explorer window next to the file name). Explorer opening the file to see if an icon is present changes the access date based on the OS default settings. So, in a forensic environment, DON'T right click on a file name to see its properties.

• Unix and *IX the creation time is not really the same as the Windows creation times. The c-time on Unix is technically called the file change time which gives slightly different definition than the Windows creation time. (You should do your own additional research to determine the difference). Also, the Unix Epoch is not the same as the Windows Epoch.

• Some virus checkers fail to reset the last access time of a file after it has been checked. The better ones properly reset the last access time so no indication is left that the file was “accessed”.

• The registry key: NtfsDisableLastAccessUpdate

At: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Determines whether the OS will update the last access date or not. If it is set to 1, then last access date updating is turned off (notice the key definition is "DISABLE:, and a 1 means YES). If it is set to 0, then the OS will perform last access update. If this key is not present, the OS uses its default design, meaning by default Vista DOESN'T update last access while W2K and XP do update last access date.

A number of the Maresware software programs (diskcat, hash, and others) will show the registry setting when they are run, so that the user knows if this key is on, off or not set.

• And last but not least, Microsoft documentation (as well as most Unix implementation) allows any program with proper security level to set/reset any of the times. Which means that a properly written and run program can (within reason) set these dates to anything they wish.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download