CHAPTER ELEVEN

Time and Forensics

The only reason for time is so that everything doesn’t happen at once.

—Albert Einstein

WHAT IS TIME?

Depends on where you look for the answer:

According to the theory of relativity, it depends on the observer’s frame of reference. Time is considered as a fourth coordinate required, along with three spatial coordinates, to specify an event.3

Time is a one-dimensional quantity used to sequence events, and to quantify the durations of events and the intervals between them. Time is quantified in comparative terms (such as longer, shorter, faster, quicker, and slower) or in numerical terms using units (such as seconds, minutes, hours, and days).

The reconstruction of events as part of cyber forensics and incident response can involve events from only a single system, as well as events obtained from multiple, geographically separate sources, each with its own clock.

An especially useful technique for event reconstruction is “time-lining.” Here, discrete events that have a timestamp associated with them are ordered into a timeline. Timestamps can be obtained from file system metadata, system logs, or application data. Depending on the source of the events, this can provide a detailed sequence of the events that took place on a system (or multiple ones), allowing an investigator to reconstruct the sequence of events that took place.

When considering timestamps that were recorded by a computing system as evidence in an investigation, several factors need to be considered. The time on a computing system is kept by the system hardware clock and in some cases by an additional software system clock. Depending on the accuracy of these clocks, how they were initialized, and whether they are synchronized, the clock(s) may differ quite considerably from the “real” time. Furthermore, clocks may be misconfigured to be in the wrong time zone or be set to the wrong time, they may be manipulated arbitrarily, and may run fast or slow (clock skew).

Time usually just advances. If you have communicating programs running on different computers, time still should advance, even if you switch from one computer to another. Obviously if one system is ahead of the others, the others are behind that particular one. From the perspective of an external observer, switching between these systems would cause time to jump forward and back, a non-desirable effect.

As a consequence, isolated networks may run their own wrong time, but as soon as you connect to the Internet, effects will be visible. Just imagine some e-mail message arriving five minutes before it was sent, and there was a reply two minutes before the message was sent.

NETWORK TIME PROTOCOL

Network Time Protocol (NTP) is an Internet protocol used to synchronize the clocks of computers to some time reference.

NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse Internet operating at rates from mundane to light wave. It uses a returnable-time design in which a distributed subnet of time servers, operating in a self-organizing, hierarchical master-slave configuration, synchronizes local clocks within the subnet and to national time standards via wire or radio.4

NTP is designed to produce three products: clock offset, roundtrip delay, and dispersion, all of which are relative to a selected reference clock. Clock offset represents the amount required to adjust the local clock to bring it into correspondence with the reference clock. Roundtrip delay provides the capability to launch a message to arrive at the reference clock at a specified time. Dispersion represents the maximum error of the local clock relative to the reference clock. Since most host time servers will synchronize via another peer time server, there are two components in each of these three products, those determined by the peer relative to the primary reference source of standard time and those measured by the host relative to the peer.

Each of these components is maintained separately in the protocol in order to facilitate error control and management of the subnet itself. They provide not only precision measurements of offset and delay, but also definitive maximum error bounds, so that the user interface can determine not only the time, but the quality of the time as well. The accuracies achievable by NTP depend strongly on the precision of the local-clock hardware and stringent control of device and process latencies.5

Like other file attributes, date stamps and timestamps are recorded in the file system in addition to the file. As mentioned, the file system-level date stamps do not interfere with the date stamps that are stored in the file itself.

TIMESTAMP DATA

Timestamp data contained within the file system is metadata (data about data). As we discussed in Chapter 9, this data is stored in the file system records, which in a Windows Operating System would be stored in the Directory Entry if the filing system was FAT or stored in the MFT if the filing system was NTFS. Timestamp data can also be found in other locations such as system logs and application data, for example.

Timestamps are determined by copying the current value of the local clock to a timestamp when some significant event, such as the arrival of a message, occurs. In order to maintain the highest accuracy, it is important that this be done as close to the hardware or software driver associated with the event as possible.6

Various programs put their own date and time records in the file contents or meta-tags, like Microsoft Office products and other software. File system level date and time file property do not interfere with the time and date stamps that are stored in the file itself.

Timestamps contained within a system can be introduced in many ways, for example from e-mail headers or HTTP cookie data. So, there may be timestamp data found within a piece of evidence that was introduced from other, external systems.

Timestamp Varieties

• Creation date and time is an attribute of a file or a folder that specifies the original creation date and time of that file or folder. When the file or folder is created, or the first time it is saved to a location, creation date and time are recorded in the file system. Ordinarily, this date and time attribute is never changed afterwards since its main purpose is to indicate the original file creation date and time.
• Last modified date and time is an attribute of a file or folder that indicates, at the file systems level, when the file or folder was modified the last time. When the file’s contents are modified and saved, the last modified date and timestamp is set to correspond with the time at which the changes were made. The purpose of this attribute is to show when the last changes to the file or folder were done.

  Any work with documents, images, and other files automatically alters (modifies) the timestamp of the file. However, in some cases it might be essential to revert a file’s last modification date and time back to a particular date and time (e.g., for sorting, recording, logging, or other purposes).

• Accessed date attribute (also called last accessed date) indicates on the file systems level when a file was accessed the last time. Last accessed date attribute differs from modification date and file property. While modification date and time indicates when the last changes were made to a file’s contents, last accessed date does not necessarily presuppose changes of content. When a file is modified, modification and last accessed dates are set to the same value. However, if the file is only opened for viewing, copied, moved, or—in other words—if the file or folder is used in any way, the last accessed date is changed to the current date.

  Any viewing, copying, or moving of the documents, images, and other files automatically alters the last accessed date stamp of the file. Sometimes, last accessed time is changed due to some program’s operation with files or folders. It might be antivirus software, which accesses files for virus scanning purpose or Windows Explorer, which extracts an icon from an executable file thus changing the last accessed date.

  Resolution of the file last accessed date is one hour for NTFS and one day for FAT. This means that only access hour or day will be recorded for this file property, skipping access minutes or hours accordingly.

  For improved file system performance, the last access time update in switched off in Windows Vista by default. Thus, the last access time attribute is set upon creating a file and not changed afterward, even if the file is modified. However, it is possible to enable last access time updates if necessary.7

KEEPING TRACK OF TIME

In digital forensic investigations, knowing the correct time when events occurred can be of great importance. This could be because of the need to correlate events from different systems, establish alibis, or to find out when events occurred with respect to events in the real world.8

—Brett Tjaden

It is a fundamental design principle that timing must satisfy register setup and hold time requirements. Both data propagation delay and clock skew are parts of these calculations. Clocking sequentially adjacent registers on the same edge of a high-skew clock can potentially cause timing violations or even functional failures. Figure 11.1 shows an example of sequentially adjacent registers, where a local routing resource has been used to route the clock signal. In this situation, a noticeable clock skew is likely.

In Figure 11.1, all registers are clocked at the same edge, but the arrival time of the edge is different at each register. Figure 11.2 indicates an example of the clock skew for the circuit shown in Figure 11.1.9

The goal in cyber forensic event reconstruction is to sequence all events that are important so that cause-time relationships may be established for an investigation. If all events we need to reconstruct are timestamped by the same system clock, some of the factors discussed above may not matter as the times will differ from “real” time in a consistent manner and a sequence of events can be established.

The possibility of clock manipulation, however, is a factor that always needs to be considered. In particular, when clocks are set back in time an identical time may be recorded for events that occurred before and after the clock change. Furthermore, few computing systems are completely isolated, and external timestamps are introduced in many ways.

For example, information from e-mail headers or HTTP cookie data may play an important role in an investigation, at which point the external and internal timestamps need to be correlated. Also, whenever digital evidence is used to establish or support the point in time when events in the physical world occurred, the timestamps of the systems that are involved need to be translated to this reference time.10

Web servers are generally of more interest to forensic investigations, because timestamps from web servers often can be found on client machines, and HTTP is a widely used protocol in many aspects of computing today.11

—Brett Tjaden

CLOCK MODELS AND TIME BOUNDING: THE FOUNDATIONS OF FORENSIC TIME

When a cyber forensic investigator needs to determine to what time a computer’s clock was set at a given time in UTC, or find out at what time a timestamp recorded on a system really occurred, he or she needs to utilize either a clock model or time-bounding techniques.

The clock model introduced by Malcolm Stevens (Unification of Relative Time Frames for Digital Forensics)12 takes a reference time (usually UTC) as a base, and then the investigator has to specify offsets to the reference time for any clock he or she wishes to describe. These offsets can be dynamic in nature, although Stevens does not elaborate on how to define an offset that changes its value over time.

This model has its strength in showing what values a computer’s clock had over time, but to map a host timestamp back to its reference time the inverses of all offsets need to be computed and applied to the timestamp. Furthermore, Stevens neglects the fact that a timestamp value found on a host may map back to the host several times in the reference time, which is a result of a host clock being set back in time.

Time-bounding techniques try to establish a causal order between individual events and thus an overall order of all events on the system. If some of those events can be attributed to a time, it may be possible to define ranges of times when other events must have happened.

Time-bounding techniques will most likely be used in conjunction with a clock model: the model will provide some of the timestamps associated with events while the time bounding technique can be used to verify or disprove that the clock description that is derived for a computer is consistent with the evidence found during the forensic investigation.13

MS-DOS 32-BIT TIMESTAMP: DATE AND TIME

The Windows 32-bit time is a time format used by Microsoft in the FAT filing systems for timestamping. We see it in the directory entries, specifically in create times (byte offset 14–17) and last write times (byte offset 22–25).

We clearly see in Figure 11.3 that the ASCII presentation of the create date byte offsets (14–17) [NQF:] is not stored in the way time should be presented.

Dates and time are such that they are mathematical in that they are incremental. Representing such incremental data with ASCII would be difficult and would quickly become cumbersome, as each second in time would need its own binary representation. As we know, time is infinite and we don’t have an infinite amount of bits to meet all the possible outcomes to represent time. So, a mathematical approach must be used.

As we can see in Figure 11.3, create date and time is assigned four HEX values or bytes. We know there are eight bits to a byte, so 8(4) = 32 total bits.

MS-DOS date and time values are a 32-bit value that specifies the month, day, year, and time of day (hours, minutes, seconds).

The 32-bit time system operates as two 16-bit values:

• One 16-bit value containing date
• One 16-bit value containing time

In other words, dates and times are each stored separately in a two-byte binary value. Two 16-bit values = one 32-bit value. Thus, 32 bits are needed to represent date and time.

Therefore, in Figure 11.4:

We mentioned that converting dates and times from HEX to ASCII was not the solution. How about converting the HEX value to its decimal equivalent? Pull out the old scientific calculator.

Converting the HEX values, bytes 4E 51, representing Time, yields the decimal value 20,049. Converting the HEX values, bytes 46 3A, representing the Date value, yields a decimal value of 17,978.

In order to be properly enumerated, both Date and Time require three data fields:

Note: this timekeeping mechanism works for the purposes as prescribed by Microsoft. Keep in mind, there are many areas where this rather imprecise, broad timekeeping method would have serious shortcomings. Many things in science, medicine, manufacturing, and similar areas require greater precision: milliseconds or microseconds to be tracked.

Obviously, this requirement would have some serious shortcomings in such an environment that records time only to the second, for example. But for its purpose and in its day the MS-DOS 32-bit timestamp was sufficient, and for most people in their day-to-day lives three fields to record the date and three fields for tracking time is more than sufficient.

Even when NTP is utilized, there may be small discrepancies in the clocks between different computers. While the time differences are in the millisecond range this may be a problem if a high degree of accuracy is needed, potentially making time correlation difficult again. For most cyber forensic investigations this may not be important.14

We require three separate fields for date yet have only two bytes to do it with, and the same is true for time. Two bytes equates to 16 bits, and 16 bits can be split up to represent three fields (see Figure 11.5).

DATE DETERMINATION

As with time, date is stored as a two-byte binary value. So the date value here, represented by byte offsets 16–17, is HEX 463A (see Figure 11.6).

First, what we need to do is reverse the endianness to little endian as this data is ordered as such. This results in the date represented as HEX 3A46.

Next we break the HEX values into their raw binary form (i.e., into bits; see Table 11.1).

TABLE 11.1 Binary Form of HEX 3A46

We need four sets of 4, or two sets of 8, thus 16 total bits (0011101001000110).

Third, the binary number is reordered and divided into three parts representing three date fields: Year, Month, and Day. Let’s read on further to see how this is accomplished.

Month

How many months are in one year? 12! How many bits are needed in order to represent 12 individual and separate values?

Four bits gives us 16 potential values, enough to represent the 12 months of the year.

Day

How many days (maximum) in a month? Again an easy question. Naturally, 31 days is the maximum amount needed. How many bits are needed in order to represent 31 individual and separate values?

Five bits gives us 32 potential values, just enough to represent the maximum of 31 days per month.

Year

How many years in an eternity? We have so far assigned nine bits to represent month and day; this leaves us with seven bits to represent year value.

So we have 128 potential values for year, which is limiting by any calculation.

The Microsoft 32-bit time/date formula gets tricky yet again with years. According to MS DOS, the world began on January 1, 1980. The seven-bit binary value is converted to decimal and the resulting value is added to the MS DOS starting year, 1980. The resulting value is then the actual year.

Let’s take a look at our example, moving from Table 11.1, and assigning the year, month, and day bits accordingly (see Table 11.2).

TABLE 11.2 Binary Representation of Year + Month + Day

Year	Month	Day
7 bits	4 bits	5 bits
0011101	0010	00110

Convert the binary values for year, month, and day into their respective decimal equivalents (see Table 11.3).

TABLE 11.3 Decimal Equivalent of Year + Month + Day

Remember to find the correct value for year; we must add the decimal value obtained, in this case 29, to the starting Microsoft year value of 1980 (see Table 11.4).

TABLE 11.4 Determining the Correct Decimal Value for Year + Month + Day

If we look at document properties (see Figure 11.7), we can verify our year, month, and day findings.

HEX date value 3A46 equals February 6, 2009 (2-6-2009) and HEX time value 4E51 equals 10:10:28 AM.

Having examined how MS-DOS 16-bit date is determined, we now turn our attention to exploring just exactly how the two bytes or 16 bits used to represent time are determined.

TIME DETERMINATION

To determine an exact time, we must first reverse the current endianness of the HEX time from 4E51 (see Figure 11.4, byte offsets 14 and 15) to little endian, so that the data is ordered as such, Time = 514E.

Second, we need to break the HEX values into their raw binary form, into bits. We discussed this previously in Chapter 7 when determining Cylinder Head Sector (CHS) locations. The 32-bit timestamp concept may be complex but all the components and concepts, such as endianness and reordering bits, have already been discussed in previous chapters.

Thus, converting each element of Time, byte offsets 51 and 4E, into their representative binary equivalents results in the binary values of 01010001 and 01001110, respectively.

We need four sets of four, or two sets of eight, resulting in 16 total bits to represent Time.

Third, the binary number is reordered and divided into three parts representing the three “elements” of time: hours, minutes, and seconds, as shown in Figure 11.8.

As usual, the answer to why this type of arrangement and this particular binary split is that there is code that is written which makes this happen. But why write code to break time up in such a manner? Why a split of five binary bits (hours), six bits (minutes), and five bits (seconds)?

The reasons why have already been discussed in the first chapters of this book. It all has to do with possible outcomes or combinations. As discussed, in order to represent the on or off state of a light switch you would only need one bit—a1 (On) or 0 (Off). More complex ideas must be represented (e.g., the seasons: winter, spring, summer, and fall).

Two possible outcomes can be represented with one bit, yet there are four seasons. So, in order to present the four seasons you need enough bits to give you four possible outcomes. Two bits can give you four possible outcomes: 00, 01, 10, and 11. Now each of those values can be assigned to a season. The same holds true for time. Let’s read on further to see how time is calculated and represented.

Hours

How many hours are in one day? Easy, 24! How many bits are needed in order to represent 24 individual and separate values? Remember from our earlier chapters:

Recall binary is Base 2 so everything is squared. Thus, five bits gives us 32 potential values, enough to represent the 24 hours in a day. As a result, 16 total bits to represent time, less five bits for hour, equals 11 bits remaining.

Minutes

How many minutes in an hour? Again, easy: 60 minutes. How many bits are needed in order to represent 60 individual and separate values?

Six bits gives us 64 potential values, enough to represent the 60 minutes of an hour. The 11 bits remaining, less six bits for minutes, equals five bits remaining.

Seconds

How many seconds in an hour? Too easy, 60! How many bits are needed in order to represent 60 individual and separate values?

Six bits would be needed in order to properly represent the 60 individual seconds within a minute. See Figure 11.9.

But we have only five bits remaining! Whoa, we need six bits. Wait, only five bits left to represent seconds. What happened? How can we accurately represent seconds with only five bits or 32 total potential values? We cannot!

Logically, since there are only five bits remaining, and we need a maximum value of 60, Microsoft uses the value 30 and multiplies by 2, thus giving us our maximum value for seconds. See Figure 11.10.

Microsoft’s 32-bit time system essentially rounds up to the nearest even second!

If we break down a day into individual seconds, we find that there are 86,400 seconds in a 24-hour day. A two-byte directory entry for date contains 16 bits. How many possible unique values are there for 16 bits? Answer: 65,536. The deficiency is quickly apparent here too.

Back to our file “Incriminating evidence.doc” (Figure 11.11).

From byte offset 14 and 15, bits 0–4 represent the hour, bits 5–10 represent the minute variable, and bits 11–15 represent the second. (See Table 11.5.)

TABLE 11.5 Decimal Equivalents for HEX 514E

Note: The decimal result (seconds) will need to be multiplied by two (2).

We can see the time, therefore, is 10:10:28 AM. (Note that hours are based on a 24-hour clock, thus, 10 AM is represented by the value 10 and 10 PM would be represented by the value 22, for example.) Don’t forget to multiply the seconds, in our example (i.e., 14) times 2 to arrive at the correct value for the “seconds” indicator (i.e., 28).

Since this value is multiplied by two it will always be even, therefore rounded to the closest even second.

If we look at the document properties (see Figure 11.12) we can verify our date and time findings as explained earlier.

HEX date value 3A46 equals February 6, 2009 (2-6-2009) and HEX time value 4E51 equals 10:10:28 AM.

TIME INACCURACY

The Create Time, which we calculated from the data contained within the FAT directory entry for the document incriminating evidence.doc (see Table 11.5), is 10:10:28, yet the properties window, as shown in Figure 11.12, is showing a time of 10:10:29.

The directory entry also contains the date and time that the file was created or last modified.

The time is accurate only to plus or minus 2 seconds because it is stored in a two-byte field, which can store only 65,536 unique values (a day contains 86,400 unique seconds). The time field is subdivided into seconds (five bits), minutes (six bits), and hours (five bits). The date counts in days using three subfields: day (five bits), month (four bits), and year—1980 (seven bits).

With a seven-bit number for the year and time beginning in 1980, the highest expressible year is 2107. Thus, MS-DOS has a built-in Y2108 problem.15

The inaccuracy of the windows 32-bit timestamp is clearly apparent here. We are able to see this discrepancy here because the file was accessed from an NTFS partition, the active partition. This file was stored in a FAT16 partition (inactive) but accessed from the active NTFS partition with Windows XP OS.

There is metadata contained within application files such as Microsoft Word, and this allows for the robust, active NTFS file system to retrieve a more exact time.

SUMMARY

In cyber forensic investigations, just as in criminal and medical forensic investigations, knowing the correct time when events occurred can be of great importance. This could be because of the need to correlate events from different systems, establish alibis, or to find out when events occurred with respect to events in the real world.

Clearly, the lack of global agreement on time could potentially hamper forensic investigations in which there is a need for event correlation for events collected from disparate sources, as well as for the correlation of computer events with events in the real world. The large number of hosts that are not synchronized to UTC shows that there is a strong likelihood of event correlation problems when more than one host is involved in a forensic analysis. This is especially true if a high degree of precision is needed for the timestamps.16

It should be recognized that clock synchronization requires by its nature long periods and multiple comparisons in order to maintain accurate timekeeping. While only a few measurements are usually adequate to reliably determine local time to within a second or so, periods of many hours and dozens of measurements are required to resolve oscillator skew and maintain local time to the order of a millisecond. Thus, the accuracy achieved is directly dependent on the time taken to achieve it.17

Timing inaccuracies are broad and vast. Inaccuracies can be systemwide to NTP server inaccuracies, or system specific due to clock skew. Inaccuracies can be specific to a certain geographical location due to confusing time zones or to a specific operating system’s file system, rounding odd seconds to the nearest even second. Discrepancies can be as long as time permits or as short as a second.

This timing inaccuracy is huge when compared to the MS-DOS 32-bit timestamp timing inaccuracy of a second. It is highly unlikely that a timing inaccuracy of a second (as seen in the MS-DOS 32-bit timestamp) would be so pivotal to corroborating someone’s innocence (or guilt). One thing time inaccuracies have in common is that they can discredit an expert, such as a cyber forensic investigator.

Opposing counsel could attempt to discredit an investigator for stating inaccuracies in the examination of the evidence (e.g., a file was created at 10:10:28 when in fact it was created at 10:10:29). Can this be explained away? Yes it can.

Could this put some doubt in a juror’s mind as to the accuracy of the investigation? Yes.

From the following discussion of the importance of time, both to an investigation and to a cyber forensic investigator, in Chapter 12 we will rejoin Ronelle’s investigation into the activities of Jose, at the concluding steps of the Investigative Smart Practices process begun in Chapter 10, communicating the findings.

NOTES

1. “Glossary for Extragalactic Astronomy,” CalTech, 2005, retrieved November 2010, http://nedwww.ipac.caltech.edu/level5/Glossary/Glossary_T.html.

2. Internet Encyclopedia of Philosophy, retrieved November 2010, www.iep.utm.edu/time.

3. Collins English Dictionary, HarperCollins, 2003, Retrieved November 2010, www.thefreedictionary.com/time.

4. D. Mills, “RFC1305—Network Time Protocol (Version 3) Specification,” Network Working Group, March 1992, retrieved November 2010, www.faqs.org/rfcs/rfc1305.html.

5. Ibid.

6. Ibid.

7. Febooti Software, retrieved October 26, 2010.

8. F. Buchholz and B. Tjaden, “A Brief Study of Time.” Reprinted from Digital Investigation, 4S 31–42, Elsevier Ltd., Copyright (2007), with permission from Elsevier, retrieved November 2010, www.dfrws.org/2007/proceedings/p31-buchholz.pdf.

9. “Clock Skew and Short Paths Timing,” Application Note AC198, Actel Corporation, 2061 Stierlin Court, Mountain View, CA, 94043-4655 USA, 650.318.4200, retrieved November 2010, www.actel.com/documents/Clock_Skew_AN.pdf.

10. Buchholz and Tjaden, “A Brief Study of Time.”

11. Ibid.

12. M. W. Stevens, “Unification of Relative Time Frames for Digital Forensics,” Digital Investigation 1, no. 3 (2005): 225–39.

13. Buchholz and Tjaden, “A Brief Study of Time.”

14. Ibid.

15. A. Tanenbaum, A., “Example File Systems,” March 8, 2002, retrieved December 2010, www.informit.com/articles/article.aspx?p=25878&seqNum=4.

16. Buchholz and Tjaden, “A Brief Study of Time.”

17. Mills, “RFC1305—Network Time Protocol (Version 3) Specification.”