Hi,
I want to know how to check or verify a file/folder's creation date, modified date, accessed date in FTK ??
In the properties tab is shows as n/a for a folder whose mac is modified.
Thanks in advance !
You never stated the OS or file system of the image…if it's NTFS, I'd suggest dumping and parsing the MFT.
I want to know how to check or verify a file/folder's creation date, modified date, accessed date in FTK ??
Alternative 1 You use a tool that has been verified to do the right thing for time stamps. If you don't have one, you probably have to do the job of verification yourself.
Alternative 2 you use your knowledge of the file system to extract the binary time stamp, and then you either convert it yourself, using methods you know, or use a tool that know does the job correctly.
In the properties tab is shows as n/a for a folder whose mac is modified.
Without knowing the file system, there's no way to suggest anything.
Very well, I'll assume NTFS. FTK related software (or at least some of it) says 'N/A' for unusual timestamps. For example, a time stamp like 10000-01-01 (that's right, year 10000) will produce an 'N/A' in some FTK versions. (Though 9999-12-31 235959.99999 will be translated correctly.) (It also goes 'N/A' for a situation where the timestamp is all 1's – i.e. 0xffffffffffffffff – but as far as I know, those never happen unless you take a hex editor and modify the raw disk directly.)
'OS Forensics' will do most such kinds of NTFS time stamp correctly, though it, too, will fail for some extremely extreme timestamps.
Added You might also want to check that your time zone settings aren't messed up.
In addition to the suggestions above, you could also mount the image via FTK Imager (or another analogous program), navigate to the file of interest, right click on it, and select properties. What better program to interpret a NTFS disk (assuming it is, of course) than Windows?
What better program to interpret a NTFS disk (assuming it is, of course) than Windows?
Well, … if it is a problem involving legal-but-extreme time stamps Windows GUI covers only the time span 1980–2107 (i.e. FAT time stamp range), and may even be off by a few a seconds in that translation. GUI file property dialogues may do better – they translate time stamps differently than the plain GUI list – but I haven't tested them much. PowerShell is better, but does not go past the year 9999, which is more or less what FTK does. (At least, all this was true two years ago. I haven't checked it out much since then.)
If anyone wants to check out how things stand with the tools of today, try
http//
Added The conclusion almost seems to be to use a tool that can be coaxed into providing the binary (uninterpreted) contents of the relevant field.
Extract of the binary time stamp can provide you with some info that can help you in verifying the details. But for that, you need to know the exact file format.
Regards
Well, the (BTW nice) test image is seemingly showing the "right" Modified/Created/Accessed date/time when opened in 7-zip, which seems to me like more convenient than right clicking and choosing properties on single files.
And, even without powershell, WMI/WMIC should do nicely at least for "real" dates.
jaclaz
Granted it would depend on the specific file but often you could also use the surrounding files to help validate, items should have consistant time stamps. Items that are created near or around when the file claims to have been created or modified.
…you could also use the surrounding files to help validate, items should have consistant time stamps.
Hhhhmmm…don't know if I'd go with that.
I've had a number of cases where malware files were placed in a folder, and "time stomped" based on the "surrounding files".
I've also seen a malware variant with a keystroke logging component that would consistently re-time stomp the log file after adding new entries. Even though the file itself had not been created on the system, in one case, until July 2014, and the last time stamped entry in the file was for Dec 2014, the dates (including last modified) for the file read Aug, 2013.