I can’t say anything about the behavior of Android devices because I don’t have one, but I suppose that there will not be a great difference. Maybe someone could contribute his experiences.

Best regards,

Hastur

Many thanks for the article.

Josh

P.s how did you get the bat symbol in the bar at the top of your idevice?

You’re right, I assumed that timestamps must always be produced by the OS, and that they should always reflect a date which is logical considering when NTFS has been in use. While I considered that people might change the date in order to bypass license restrictions or as an anti-forensic technique, I never considered that somebody would set a date like 1964-06-02 because that date has special meaning to them.

Thanks for clarifying this.

System time affects them. System time can be modified for many reasons — bypassing license restriction is one I have encountered.

Timestamps may also come from archive files (ZIP, tar, etc.).

The timestomp utility (or the later setMACE tool) allows just about anyone to reset timestamps, and just about any programmer can do that using his own code also. And if a person does so, one reason may be that the date is important for some reason: like april, 1850 or december, 1969 or 1964-06-02. In the right context, those dates may easily have a meaning that is more important than the bare date itself.

Still, if the time has been reset for whatever reason, I still need to analyze it, and as the domain of NTFS timestamps range from 1601 to the 32000s, the translation should work over that domain. Windows can do that translation correctly — why shouldn’t computer-forensic tools do so as well? It is, quite literally, a fairly small matter of programming — it takes less than a day to write the relevant code, and approximately another day to test it comprehensively.

I don’t think I made the conclusion you cite — I hope I have demonstrated that some computer forensic tools have shortcomings in this area, and noted that those shortcomings may be cause for concern for successful analysis. I also recommended that a risk/damage analysis probably is the best foundation for a decision what should be done about it. But if you think the damage is negligible to you, who am I to say you are wrong, for the cases you are or will be working?

Good luck with your studies in computer forensics. When your text book or instructor gets into the subject of validating your tools and results, you are getting close to the specific area I have touched on in this article. Be prepared with your questions then.

My point was, that as someone who has not actually worked on real forensic cases, it seems to me that the tools you mentioned all work just fine for the date range that one would encounter on real NTFS systems, namely 1993 (release of the Window NT 3.1) through the near future.

Is it reasonable to expect a file to truly have an NTFS timestamp in the 1950′s? Or the 1600′s? Such a file cannot exist, since obviously there were no computers then (at least not PCs using NTFS).

That’s why I think that investigating timestamps in those pre-PC or far-future dates is interesting but academic, I don’t see how it has practical applicability.

To conclude, as you apparently have, that timestamps displayed in various software packages cannot be relied upon at all, seems to me to be a dangerous throw-out-the-baby-with-the-bathwater approach.

As I wrote, my forensics experience is zero… So am I missing something here?

My personal opinion is that it is never OK to get this wrong. That’s why I created the test data — to see if I could discover tools that failed to do something as simple and straightforward as translating a legal timestamp correctly.

With tools that do faulty translation, I’d do my best to call the problem to the attention of the toolmaker, and insist very strongly on a good and well-tested correction. Until that patch comes along, some alternative is required for all timestamps — I’d probably go for the PowerShell approach together with an image mounting tool. Alternatively, I’d program some DCode-like application that used the appropriate system calls in Windows, to make sure I was using the native translation routines.

With tools that identify timestamps that are outside the supported range, it’s easier to identify problematical timestamps, but the solution is essentially the same.