zero'ed MAC times and dates

Any Autopsy specific discussions, events, module releases, that don't fall into the other categories.

Moderator: carrier

zero'ed MAC times and dates

Postby redalert6 » Mon Apr 11, 2016 6:01 pm

i have a directory listing of what appear to be deleted files, however the MAC times are all 000-00-0000. Clearly these files have been deleted but why would autopsy list zeros for the MAC times?
Posts: 1
Joined: Mon Apr 11, 2016 5:56 pm

Re: zero'ed MAC times and dates

Postby giuseppe » Sun Jul 31, 2016 12:49 pm

Hi there.
I was looking for an answer about the same issue redalert6 posted. I think it's not correct that the files with zero'ed MAC times are of course deleted files. I say this because I have different files, with zero'ed MAC times, which are still in the original directory. i used autopsy 4. Look at this photo with directory listing of deleted files. Click the image to view all field.
I have highlighted 4 files:
1) This file is still in the folder, so it's not deleted and has zero'ed MAC times
2) This file is really deleted and the MAC times are not zero'ed
3) This is the same file as 2) but the name file finishes with ":Zone.Identifiers" (sorry but I cutted the image, for best fit screen)
4) This file is really deleted but has zero'ed MAC times as 1) (which is not deleted)
The questions are:
a) What does it mean when MAC times are zero'ed?
b) When MAC times aren't zero'ed, what of the time columns (modified, change, access, created) do we have to refer to? Which one is the time of deletion?
c) What does it mean file name which finishes with ":Zone.Identifiers"?

Thank you in advance
Posts: 5
Joined: Sun Jul 31, 2016 10:04 am

Re: zero'ed MAC times and dates

Postby giuseppe » Wed Nov 22, 2017 9:39 am

No one has idea for the above subject?
Posts: 5
Joined: Sun Jul 31, 2016 10:04 am

Re: zero'ed MAC times and dates

Postby Hoyt » Thu Mar 01, 2018 3:40 pm

I wrote some portions of this to help those that may not know, not to patronize anyone.

ZoneIdentifiers are a Microsoft construct related to downloads and URL security zones. See here.

For some reason, Autopsy isn't pulling information from the file's metadata for those files with zero'd MAC times. Assuming there was no module error, this could be due to there being no metadata to be read (for various reasons) or a data corruption of the metadata itself. In either case, Autopsy will substitute zeros for data. Remember that this data isn't coming from the file itself and depends on the filesystem in question as to where it's located. Remember also that Autopsy automatically recovers deleted files (by undeleting, not carving), therefore any files that were recovered this way will be located in their respective former directories in the Autopsy UI. I assume that's what you mean when you say a file is still there.

To make this clear and regarding NTFS, file metadata, specifically MAC times, aren't stored with the file itself per se, but rather in the Master File Table (MFT or $MFT) as part of the File Record. For files with resident content (contained fully within the $MFT), the File Record is in effect the file, but files with non-resident content are those where the actual file content is located elsewhere than the $MFT. Each File Record is made up of a File Record header and attributes. The one we're interested in here is the $Standard_Information attribute (identifier 0x10 00 00 00). This is where Autopsy pulls MAC times for a file and it is always resident (found within the $MFT).

When a file or directory is created:
1. It's assigned a File Record in the $MFT.
2. It's designated allocated in $MFT's bitmap and the File Record header.
3. File Record attributes are written.
4. Non-resident content clusters are mapped in $Bitmap.

When a file or directory is deleted:
1. The Record Header sequence is incremented by 1.
2. It's designated unallocated in the File Record header and $MFT's bitmap.
3. Non-resident content clusters are unallocated in $Bitmap.

Nothing else happens to it until the File Record is reused. Autopsy and related forensic tools simply reverse the deletion steps to "undelete" files. If the File record was reused, the record header and attributes are overwritten. This includes resident content. Non-resident content may still be recovered via carving, but will not have a File Record, i.e. file name, MAC, etc. to match up with.

This doesn't totally explain what you seem to be seeing, I don't think. One other place a forensic tool may look for some, but not all file metadata is the directory index entry (INDX). I don't know what happens in the event of a conflict with the File Record, if that's even possible, or what The Sleuth Kit does in such a case. I do know TSK is INDX aware (tsk_ntfs.h). This may help account for what you're seeing or not, I just don't know.

One thing I'd recommend doing is adding the image to FTK Imager and see how those results differ from what you see in Autopsy. FTK Imager also undeletes files automatically, so this should be a good comparison.

Hoyt Harness, CFCE
Posts: 74
Joined: Thu Dec 11, 2014 4:02 am
Location: Little Rock, AR

Return to Autopsy General

Who is online

Users browsing this forum: Google [Bot] and 2 guests