Much better, thanks.
FYI, the "issue" as you refer to it are actually multiple
The FILETIME values are sometimes overloaded with special value, as athulin points out 0 and ~0, but also -1 and 0x2a2a2a2a2a2a2a2a have been seen in e.g. PST, ESEDB. Overloaded values are likely to be context specific.
Some tools do truncate the FILETIME to a 32-bit signed POSIX timestamp, and then use the system functions to represent the time. This not often looses the date and times before and after the Unix epoch (1970), although if done correctly dates before 1970 can be represented using negative POSIX timestamps, nonetheless there still is a cutt-off point and ranges are lost.
The conversion also looses precision, because FILETIME is in 100th nano seconds and POSIX timestamp is in seconds (although variations exists that use micro seconds). The fallacy of these tools is that it is the precision can be useful to detect "artificial" created times, which if the API allows for less of a precision than timestamps generated by the system.
The fallacy of these tools is that it is the precision can be useful to detect "artificial" created times, which if the API allows for less of a precision than timestamps generated by the system.
I wrote an MFT parser in Perl and incorporated a check for precision in the FILETIME time stamps, as a means of detecting this issue.
However, in my experience, there's been a move away from the use of such tools and toward the use of GetFileTime()/SetFileTime()…get the times from kernel32.dll and use those to replace the times on the file(s) you're trying to obfuscate.
keydet89, sure the precision by itself is not sufficient to rule-out time manipulation, but it can help in identifying it.
I applaud your effort in identifying the particular APIs for manipulating key LastWrite times to arbitrary values. I would suggest that in doing so, you've accomplished several tasks all at once
1. Identified the API and increased the possibility (albeit not the likelihood) of this occurring.
2. Illustrated the need for an overall analysis process.
3. Illustrated the need for a greater understanding of the Registry as an investigative resource.
4. Illustrated more than ever the need for timeline analysis.Thank you.
I'm a rookie so maybe I don't understand, but shouldn't those 4 reasons for applauding Joakim apply to other anti-forensic techniques? For example, normal file timestamp modification that has been going on for years… I'm not sure why investigators need to be continually reminded to fix the same problems in our analysis process. I mean if someone hasn't learned those things from anti-forensics so far, are they really going to learn this time?