I'll try a general answer.
Operating systems store files on disks with information such as the
creation date or the modification date.
We can consider two cases of date forgery: (a) the system date was
changed, the file created and the date changed again (b) the file was
created and then later the creation date was changed.
For case (a), all you can do is to detect an incoherency, since
changing the system date leads to a lot of them. But this may not be
evident. For example, operating systems often have a record of the
date a directory/folder was changed. Let's consider the following
situation:
t = 2 - directory is changed (and you know about it)
t = 3 - system date is changed to t = 1, file is created into
directory
consequently, modification date is set to t = 1
t = 4 - system date is set back to t = 4 (the actual time)
With this, you'll know that the creation date of the file was forged.
In fact, if a file with a creation date is earlier than the
modification date of the folder, you can suspect something (this
heavily depends on the operating system, though). However, you can
only have an interval about the time when the file was changed.
In case (b), you can rely on incoherencies as well to detect that the
creation date of the file was forged. However, the system once wrote
the old creation date and replaced it. Sometimes (read: often)
operating system don't write new data like a creation date just on top
of the old one. This is the case if the file system is journaled. In
this case, some specialized tools can detect that the creation date
was changed and might be able to figure out the actual creation date
(read: the first creation date that was written to the disk). In fact,
I'm not aware of any tool like this, so it's rather you with a disk
editor and the specifications of the file system on your knees.
On secure systems, doing something like changing a creation date
normally leads to a lot of traces and evidences. |