How does the software handle access time for deleted data ?

[keipou]

Hi,

I set up a test xp workstation and then try to select a folder with data for deletion following by cleaning the recycle bin.

Running Osforensics, I looked at the deleted data. I noticed the access time did not correspond to the time I performed the deletion. The creation and modication date seems ok. I double check the xp windows registry and the access time stamp is not set to off.
I then tried to run the same disk with Autopsy. The deleted files recovered show the correct access time when I deleted the data. That means the access time is in the disk but was reported differently by Osforensics.

My question here is what access time stamp does the software used in reporting for the deleted data ?

Is there a simple way for me to use Osforensic to locate the mft table of the Magic file number of the deleted file and then I can perform some offset count to locate the time stamp to double check things ? Could it be that access the time stamps was used between S$FILE_NAME or $STANDARD_INFORMATION?

[David (PassMark)]

Just for the record, what registry value did you check?

By default Windows Vista (and later) don't update the access time when a file is accessed (despite the name). But it depends somewhat on what operation is done on the file. Bu in XP it should be updating the access time.

What file system are you using?

For example in FAT the access time is only accurate to a day. See,
https://msdn.microsoft.com/en-us/library/ms724290.aspx
Which makes it hard to check the value in a quick test.

In other cases updated to the access times can be cached in RAM and flushed to disk only from time to time (e.g. each hour). I don't know the exact time figure for XP however. So this also makes doing a quick test difficult.

So it might be just a timing issue or test process issue.

I'll check the code however.

Is there a simple way for me to use Osforensic to locate the mft table

From the Deleted File Search module you can right click on a file to jump to the files location on the disk. If the file is a small MFT resident file, then it will drop you into the MFT. Otherwise it will drop you elsewhere on the disk.

You can also effectively browser the MFT from the File System Browser, and see the deleted files and their meta data. Delete files appear in Red.



This doesn't tell you the offset in the MFT however.

[David (PassMark)]

An update:
We are using the $FILE_NAME attribute for reporting date / times in deleted files.

[keipou]

Hi,


This is windows xp NTFS ystem. Let aside the update time and other issues etc, just to be sure, I used the same disk and run some independent tests by ntfswalker and autopsy and compare against the result of Osforensics.
Let us look at one particular deleted file 2013_10_16_16_14_15.jpg
From the result of Osforensics below, it has access time of 30 June 2016 22:38



I ran Autopsy and got the access time stamp to be 2016-07-05 11:17:23 SGT. This is correct because this is the time I access the files before performing deletion.





I ran again nfswalker and get the same result as Autopsy. See result below :







I can not explain how the access time stamps are derived in OSforensic as they do not match any of the known time stamps.

[keith]

If possible, we would like to send a debug build to get to the bottom of the file time issue. Can you send e-mail to us and we'll provide a link to the build.

[keipou]

Thanks.
Already email your side awaiting an answer

[keith]

An update on the file time issue.

OSForensics was displaying the file times from the NTFS $FILE_NAME attribute rather than the $STANDARD_INFORMATION attribute. $STANDARD_INFORMATION contains more up-to-date file times. This will be fixed in the OSForensics V4 release.

We are also looking into displaying both sets of file times in the internal viewer.