Maresware computer forensics, MAC file times article

What Time Is It?

Good article Here is an excellent article at Microsoft describing a lot of technical stuff about the file systems. Some of which relates to access date and its update.
and finally, check out the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate

What time is it? The problem

"What time is it?" Most people would have no problem answering this question. But a computer forensics examiner might.

PST, EDT, CST, GMT, ZULU. Do these abbreviations mean anything to you? If you deal with operating systems other than DOS they should. They are time zone designations. Even some DOS programs (such as PGP) make use of these terms.

For an investigator dealing with computer evidence, how important is the time(clock) setting on the suspect computer? It can make or break any case that relies on placing the suspect at his computer at a specific time.

A hypothetical case

Suppose a hacker has penetrated your system and is downloading files to his computer. Suppose you are in Greenwich, England and have monitored his activity on your computer. The time on your computer says 12:00 hours GMT. The next day the suspect’s computer is seized and sent for analysis. (The suspect lives in Washington D.C.). It is determined that the suspect is using Windows NT and has the NTFS file system set up.

The only way to convict the suspect is to show that your files showed up on his computer within 5 minutes of the time you were monitoring the activity. Your exact request to the examiner stated that you "needed to identify files downloaded at 12:00 hours."

The examiner performs accepted system handling techniques, including backup/imaging of a Windows NT system and looks for files with a time of 12:00 hours. None are found. What has happened? What should the examiner be looking for?

Perhaps the crucial piece of evidence is the time setting of the seized computer. That setting will determine the time stamps that are applied to new or modified files. For this reason, it’s important to record the local time setting on that computer. Also, it is likely that the seized computer's setting does not correspond exactly with the correct local time. So, you should record how far off the correct local time the computer setting is. (Most users are content to have the computer’s internal clock set to within a few minutes of local time.)

Another setting that may be important is the TZ (time zone) variable. This variable is usually set in DOS via the autoexec.bat file, or under NT in the Control Panel. It will indicate which time zone the suspect computer is using.

Even if the computer clock is determined to be accurately set, any file the suspect may have created during your time period would not reflect 12:00 hours GMT. It would more likely reflect local time of 07:00 or 08:00 hours depending on whether Daylight Savings Time was set and in effect during this period. (Don’t forget, Washington D.C. is 4 or 5 hours off GMT). But the examiner still can’t find any files with a time setting matching your 12:00 hours. Why not?

When you use File Manager or the DIR command to display file times, NT shows you the time the file was last written to. From that point on, NT and 9X may handle file times somewhat differently. (WIN95 is similar to NT in its treatment of timestamps. But not 100% compatible. Certain differences will be noted below.)

Assume the suspect didn’t do any writing to the files. All he did was copy them to his system, and maybe he used a program to view them. There are a variety of "copy" operations (ex.: FTP; a simple file "copy"; telnet) and they affect timestamps differently. Depending on the operations of the suspect's copy process, the operating system might now display the original file times recorded on your host system, which is not the 12:00 you are looking for. Let's assume you still don’t have a time match because the timestamp on the files on your system( which have now been transferred to the suspect computer) are nowhere near the time in question. The time stamp on your host files reflect when you last changed the file. Where to next?

Well, once your examiner straightens out the differences for the suspect’s local time setting, the next step is to check the last access time of the files. What’s that?

Three types of timestamps

With operating systems such as UNIX, LINUX, WIN9X, Windows NT and others, file times (and dates) are stored as three separate items. These are: (1) the creation time;(2) last write/modification time; and (3) last access time. Let's look at these.

"Creation time" is usually (but not always) the time the file was created. More specifically, it is the time when the file was first created or written to the disk. Note, then, that if the file was copied from another source, "creation time" would be the time the file was copied rather than the time it was first created. (Microsoft documentation roughly defines this as: the time the file was created. A value of 0,0 indicates that the file system containing the file does not support this time member.)

"Last write/modification time" may take on many different meanings. Practically speaking, it means when a program last made any changes to the file. Even though Microsoft defines it as last write time, if you consider this to be the last modification time, all the behavior of the operating system relative to this time stamp seems to be correct. Last modification would occur when you re-opened the document, edited it in some way, and wrote the result back to the disk. This is the time File Manager and DIR show you. (Microsoft defines this as: the time that the file was last written to. All file systems support this time member.)

Believe it or not, when an original file is copied (using the copy command or File Manager) both NT and 95 keep the original "last write/modification" time on the new file. However, the creation time is, by definition, the current time of the copy.

This is a source of confusion. How a file can be created after it is modified? The answer lies in the way the operating system maintains its timestamps. If the file in question was modified(written to) on the examiner's computer in Greenwich last week, that is the time File Manager will display on the suspect disk. Oddly enough, the "creation time" of the file on the suspect disk actually reflects the time the file was copied by the examiner. But the operating system doesn’t display that.

The trick to solving the time problem may involve the third type of file time, "last access time." This generally means the last time some action was taken on the file. It can include the last time the file was: copied; viewed with a viewer (such as Quick View Plus); opened for reading; or printed with a piece of software. (Microsoft defines this as: the time the file was last accessed. A value of 0,0 indicates that the file system containing the file does not support this time member. )

Generally, the NT system resets this "last access time" any time an action is performed on the file. And most activity on a file (except for doing a simple DIR) will cause this time to be reset. The examiner must test the operation of each software program used by both the suspect and by himself to determine if any of that software alters last access time.

So, how is last access time actually determined? Windows NT and 9X normally do not provide the capability of viewing any time except the last write time. As mentioned earlier, the last write time is the default for File Manager or DIR. The examiner would need custom software to view the last access time. Software exists that will do this, but that’s not for this article.

(Note: WIN9X does not appear to completely support the last access time, even though much of the programming documentation written says this time is available. As best as I have been able to determine, WIN9X stores the last access date, but not the time.)
Floppy disks bring their own set of problems in determining last access time. Because of long filename capability, if the floppy is being used in an NT or 9X computer, all three date stamps seem to be in place and follow the WIN95 formats. This means the last access date is maintained (i.e., no time); and that the creation time and write date/ time are also maintained. However, that same floppy disk, when used in a DOS based computer, will only update the last write time since DOS can only handle one file time.

So, the examiner needs to find the correct last access time of the files and to adjust for time zone and internal computer clock differences. For NTFS and WIN95, he must carefully test all the software to see what effect it has on the various file times. And make certain he has software which can accurately depict these times.

Is that it? Recall that early in this article I mentioned that the examiner must perform all proper image/backup procedures. Suppose that one of these procedures involved either performing some sort of CRC file verification or using a file viewing technique to see what files were on the suspect system. It is possible that the activity of the examiner, in performing these operations, has altered the last access time of the suspect files. If so, the examiner now has real problems.

What time is it? The Solution

Just as there are problems surrounding file times on Windows NT and WIN95 file systems, there are also solutions. In the discussion that follows, I will offer a short list of software, currently available on the Internet, that can keep your system clock synchronized to various "time servers" around the world. I will also present an overview of software I have written to make an investigator’s job a little easier when looking for and recording file times.

(Please note: for simplicity, when discussing file dates or times below, I use the term' date' to mean the combined file date and time.)

Help with setting your computer's time

First, let me list some programs I have found on the Internet which I use to set the correct time on my computer. Simply search the web for keywords in the filenames to locate the programs. These packages are designed to work under NT or WIN9X. Most of the authors also have versions for other operating systems. Most of these programs will not work through a firewall, and one is designed to work through a modem under MS-DOS. Some are free, some provide demo versions, and some are for sale.

You can also look at (http://www.eecis.udel.edu/~ntp/software.html, or http://tycho.usno.navy.mil/cfiletimes.html ) for additional software. Most of the servers are located in the U.S. However, there are many other servers located all over the world. Here is a short software list: 4DTIME40.ZIP, ATOMCLK.EXE, NBSCOM.EXE, NETDATE.EXE, SNTP.EXE, YATS32.EXE.

Good forensic analysis practices--initial steps

Next, after correctly setting the time on your computer, good practice requires that you always work on an imaged copy of the hard drive, and that you have a write blocker installed. At a minimum, you will be using a file viewer to view suspect files. File viewing and most file operations will attempt to alter the access date of a file. If a write blocker is installed, it may not allow this. And that presents a problem. You can turn off the write blocker when viewing files and performing other operations, or live with the inconvenience that it presents. (At this point, I will assume your write blocker is inactive so you can use your viewer and that you are working on an imaged copy of the evidence.)

If you do not have a write blocker, (and even if you do), you might want to consider using the "accdate" command in the config.sys file to turn off access date updates.

For the remainder of this article, I will present a procedure and some file cataloging or inventory programs that will provide you with a strong defensible position when facing challenges about file dates. I will generally assume the investigator is using Windows NT. However, most of the techniques (except those dealing with last access time) will also work on WIN9X file systems. Remember that in considering the procedures discussed below, you also must always bear in mind what constitutes acceptable evidentiary procedures within your own jurisdiction. Each country and each agency within that country may have specific regulations concerning processing of evidence and the procedures discussed below may need to be altered to be consistent with those requirements.

Documenting file dates with an inventory

At the earliest possible point during the analysis the investigator should create an inventory of all files on the system. (The simplest command is: DIR /AHS.) Most software lists the last modified date of a file because that is what File Manager and DOS present. Sometimes this file date may not be the best choice; or, you might want to record one or both of the other file dates as well (see the three types of timestamps discussed earlier.)

I created and use in my own forensics work a very useful inventory program, Maresware's Hash. This program will produce a list (also referred to as a "catalog" or "inventory") of every file on the disk. The output record produced includes: file names; file sizes; MD5 hash value of the files; and one of the three types of file dates (whichever one you selected).

A good practice in using Hash for your inventory procedure is to run it first to produce a list of every file with its last access date. (Remember 9X doesn’t use last access time, just the date. On WIN95 systems the last access time is 00:00). Then run the program again to list the last modification date; and run it a third time to record the creation date. Running the program as the initial step in your examination will provide a "checkpoint" of the status of the files before any forensic analysis was done. Later on, if the examiner has used a tool which may have altered the last access date, he has an arguable defense: proof of what the original access date was. This may be a very important file date. (See the note at end of this article.)

But why include the MD5 hash values in the inventory? Because they have enormous value in ensuring file integrity. It provides you the critically important ability to demonstrate that your examination did not alter any part of the original file/evidence. CRC, Checksum, or Hash/Signatures of a file are all values derived by a mathematical calculation which uses every bit of the file. Depending on the algorithm used, the chances are from roughly 1 in 64000, to 1 in 2 times 10 ** 34 (that’s 10 with 34 zeros) that two dissimilar files will produce the same value. When two dissimilar files produce the same value that is referred to as a "collision".

If a strong algorithm is used to calculate the initial value of a file, then at a later time if that value has not changed, there is a near-certainty that the contents of the file have not changed either. MD5 is the algorithm where the chances of 2 dissimilar files having the same value is 2 times 10 ** 34. By searching the Internet for the keyword ' MD5' you can locate voluminous documentation describing the operation and reliability of this particularly strong algorithm.

This simple procedure of creating an inventory of all files on the system, with its three types of file dates, is the single most important step in a computer forensic examination. I created Hash with sufficient capacity to handle the large number of files found on today's systems. I frequently find over 10,000 files on a stand alone computer. And networks compound the number of files which need to be catalogued.

There are several other Maresware programs, discussed below, which are useful in producing file inventories. They operate in slightly different ways, and an examiner might need to use one, or all, for different tasks.

The second Maresware program, Diskcat, can also record all three dates. Diskcat, short for "disk catalog," produces a catalog of every file on a disk or diskette. It lists the filename, date, and size. It can also generate a 32 bit CRC, and show what type of program generated the file. It does all this in a fixed length record format, which makes the output easy to import into a database for further analysis(a feature I find enormously helpful). This program only changes the last access file time when the CRC is requested. All other modes of operation do not alter any file times. (See note at end of this article)

Another Maresware inventory program is Crckit. This program will calculate the 32 bit CRC of a file. It can also list any of the three file dates chosen. Crckit also attempts to reset the file dates so no significant alteration is produced. It does not have all the capabilities of Hash and is mainly used for single directory listings. However, for a file by file validation, it is excellent. (See note at end of this article)

A final Maresware inventory program is Mdir. It is designed as an" intelligent" replacement for the DIR command. Mdir produces an output listing with the look and feel of the DIR command, but provides much more capability. One of its features is the ability to provide any one of the three file dates based on the user's choice. It is a "quick and dirty" method of doing an intelligent DIR of a directory.

In summary:

Prior to beginning a forensic examination, the investigator should make sure that the forensic(examiner's) computer has the correct time set. This can be accomplished using appropriate software to synchronize the computer’s clock with a recognized time standard. Also, the examiner should record the time on the suspect's machine to determine the difference in computer times.

As a first step, before any computer forensics examination begins, the investigator should create a listing/catalog of every file on the suspect system with its corresponding date and time(and, preferably, including calculations of the related hash values).

Especially when dealing with advanced operating systems like Windows NT and WIN9X, the examiner needs to perform his work constantly mindful of the fact that the system maintains three file dates and that almost any operation he performs will alter the last access date.

Notes:

Maresware's Hash, Diskcat, and Crckit, when requested to calculate the MD5 or 32 bit CRC of a file, all open and read the file in order to compute the values. Because they open the file for reading, the operating system resets the last access date of the file. There is no way around this.

However, the programs are designed with the ability (at the user's request) to restore the date on all files to the original value. This restoration of original date does make changes to the disk, but produces no significant alterations. With advanced operating systems in use today, it becomes almost impossible to run a system without the operating system itself changing items on the disk. You must be prepared to explain that and to state your reasons for turning on the system.

If this changing of the date back to its original value poses a potential evidentiary problem, then the user should use the Hash or Diskcat program and NOT request the MD5 or CRC calculation. This operation without any calculations will not open any file and will produce only a catalog of the disk. In this mode, no file opening takes place, and the operating system doesn’t alter file dates. But all you get is a file listing, and no numeric validation as to the integrity of the file. You must make a choice as to which you prefer. If you are conducting the examination using an imaged copy of the evidence, as you should be, this is not the problem it might appear to be. After capturing the three dates, you simply run the programs again, and let the operating system alter the dates in its usual fashion. You have the original dates recorded, and you are prepared to explain the operating system's process of changing the dates.

One last note: remember that under NTFS, the last access time is updated only on an hourly basis.

BOTTOM LINE:

From: http://support.microsoft.com/kb/299648
File properties with regards to the date and time stamps
If you copy a file from C:\fat16 to C:\fat16\sub, it keeps the same modified date and time but it changes the created date and time to the current date and time.
If you copy a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time but changes the created date and time to the current date and time.
If you copy a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time but changes the created date and time to the current date and time.

If you move a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time and keeps the same created date and time.
If you move a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time and keeps the same created date and time. In tests, this only seems to hold true when the "move" is conducted within the explorer GUI. If you are in a command (cmd) box, and use the move command, the create date does update just as if you were using the copy command.

If you move a file from C:\fat16 to C:\fat16sub, it keeps the same modified date and time and keeps the same created date and time.
In all examples, the modified date and time of a file does not change unless a property of the file has changed. The created date and time of the file changes depending on whether the file was copied or moved.