Resources - Time-stamps

Date-Time stamp rigging — errors to make and how.

Chapter 14

I knew that Deryck knew how to use the COPY command to copy files.

Just before I was suspended, I caught Deryck using the COPY command in a way that was different, a way that I had never seen before and his story that he was simply copying files to a floppy diskette was simply not true as verified by using DOSSHELL at the time.

There was plenty of evidence of company data-time-stamp rigging. These manifested themselves in two ways: timestamps that had impossible dates or times caused by outside circumstances; and, time-stamps that had values that could not exist.

The former consisted of, for example, files that had dates that were before they could have existed and the latter was realised in the form of times such as 61 minutes and so on.

First of all, time-stamps are there to let you know when something has happened to a file such as when it was created, last modified, viewed and so on, depending upon the operating system - not all operating systems support all of these options.

The time-stamp, along with other data about the file's name, how long the file is, who can access it and so on is not part of the data of the file itself, it is about it and therefore is called 'metadata'.

As was demonstrated in the case, you can change the date-time-stamps and then make false claims about the new values that are to the detriment of somebody else - using dishonesty to gain an advantage over another is the definition of fraud - in this case, computer fraud.

One way of doing this is to use the COPY command. You can see in the demonstration screen-shot that I have two identical files - one has been made and the other is a copy of it produced by using the COPY command in the conventional way.

If you set the system clock to whatever date and time you like - again, using the command line - you can then copy a file onto itself using the command:

copy [filename] /b+ ../y

and it will give the file the current date and time from the computer.

The advantage of this is that you can never get a non-existent date or time and the disadvantage is that if you have a lot of files to do, all requiring different dates and times, it can take a lot of time and effort.

Harry told me of there being programs that changed the dates and/or times of files, a whole directory at a time, using the interrupts mentioned in the INTRLIST programmer's encyclopaedia.

After I had left the company and got access to a machine, I had a go at writing one of my own, with a GUI to make it easier to see - this is written in VisualBASIC for DOS.

You can see that I gave the user the option of changing the date and/or time to set values - you don't have to change both of them - or you can do so randomly. With the random option, you can select real times only or any value.

An incompetently written or used program would not check for real-only dates and times.

So, how can there be dates and times that are not real?

UNIX and similar operating systems use a value that starts at a particular time - 1st January 1970 is the beginning of the UNIX epoch - and then increments by one for each second so, between 23:59:59 and 00:00:00 the following day, there is a change in the value of only one.

Microsoft uses a different method. The year is stored as a 7 bit value (0..127); the month is stored as a 4 bit value (0..15); and, the day is stored as a 5 bit value (0..31). The hour is stored as a 5 bit value (0..31); the minutes as a 6 bit value (0..63) and the seconds - which is rarely ever seen on the system - as a 5 bit value (0..31) which is multiplied by two, giving even values from 0 to 62. These add up to 32 bits used to store the date and time.

If you have a program that just produces 32-bit random numbers without checking for impossible values, you will get what was seen in the directory listings supplied eventually by the company, showing times such as 6:61 and so on.

Incidentally, the occurrence of impossible minute values was around 1 in 15 or 4 in 60 which is what you would expect from a simple randomisation of time values - it is easy enough to make a program change only the date or only the time values by using something called a 'mask'.

The wires program demonstrates that date-time-stamp rigging has occurred by giving it a date that is months ahead of when it could ever have been made - Harry didn't give me the idea for it until the summer of that year. That file's date-stamp it prima facie evidence of company computer fraud.

As for the CAPTURE files, I suspect that it is something that Eric had a go at - there was already a password interface in the developer's toolkit that came with MS QuickBASIC Extended. It would have been easy enough to compile what was ready-made there without any malicious intent, just curiosity.

However, there was no way that it could be confused by any reasonable person as the password screen for any program on the system - primarliy because there was only one program that actually used passwords and I had top level access to that any way.

As for the claims made by, well, I'm not going to spoil that at this stage. Read on.

	This was all getting very ‘Edge of Darkness’ again.

---