±Forensic Focus Partners
New Today: 0
New Yesterday: 0
· Extracting data from dump of mobile devices running Android operating system
· Development of Digital Forensic Tools on Mobile Device, a Potential Area to Consider?
· Can You Get That License Plate?
· How To Decrypt WeChat EnMicroMsg.db Database?
· A guide to RegRipper and the art of timeline building
· Recovering Evidence from SSD Drives in 2014: Understanding TRIM, Garbage Collection and Exclusions
· FT Cyber Security Summit 2014 – Recap
· Why Offender Profiling is Changing Thanks to Mobile Forensics and Increasingly ‘Social’ Criminal Activity
· Understanding Cyber Bullying – Notes for Digital Forensics Examiners
±Follow Forensic Focus
Active file and deleted file with identical timestamps
I have a puzzling forensic case where image files with identical filenames have identical timestamps (Modified, Accessed Created) where one copy of the file was recovered with Metacarving from the identical file location (folder).
How can this be?
Even if the file was copied in the same folder location and one copy deleted I would expect some shift in the Timestamps and the copied file would normally have a sequential bracketed extension to the main filename.
This goes to court in three days so I would greatly appreciate some speedy input to allow me to supply an explanation to the court.
Thanks in supplication
P.S. The operating system is Windows Vista.
If you are doing a normal file carve, via signature matching, then you won't get any valid dates, nor even a file name for that matter.
If you are recovering a file via deleted records in the MFT, then you will get a name and some dates, but I wouldn't describe this as a 'carve'.
Are you sure whatever tool you are using isn't just presenting active files along with the deleted files. So while you think you are looking at deleted files, you are in fact looking at all files (active and deleted).
- Senior Member
The term Metacarve is a Forensic Toolkit term for deleted records extracted from the Master File Table. A relevant case file extract suitably masked is shown below.
Case110110_1.1.E01/Partition 2/HP [NTFS]/[MetaCarve]/7744/folder name/folder name/filename
Sorry for the confusion, but my question still stands.
Thanks for your rapid response to my query.
Also this way, you can double check the actual dates being reported.
Is the second MFT a valid MFT or just a duplicate that has been picked up.
Are the files stored in the same location, or a different physical location.
- Senior Member
- MartyBoyEven if the file was copied in the same folder location and one copy deleted I would expect some shift in the Timestamps and the copied file would normally have a sequential bracketed extension to the main filename.
That is assuming the 'basic' file operations. But why must it be a basic file operation?
A user (or a program) can prevent NTFS from modifying any of the (documented) timestamps of a file he/it operates on. And the same user/program can both read and set those timestamps. There's nothing technical impossible involved -- it's not even technically challenging to do so.
Why do you only mention three timestamps (Modified, Accessed Created)? NTFS has four timestamps, and normal forensic tools will provide those. Could the fourth timestamp be different?
More interesting would be if the non-documented timestamp related to the filename attribute were exactly the same. You need special tools to extract those, unless you prefer to the job by hand. If they are different, you can at least order the two entries by time. AnalyzeMFT is one such tool -- there are several other.
So ... what programs on this particular computer are known to leave timestamps alone when they operate? Or set timestamps to predictable values? Backup/restore software? Antivirus? Archive programs? And what scenarions involving those programs could explain the results you see?
You only mention identical timestamps ... but you don't say that anthing else (except filename) is identical. Is size identical? Other attributes such as sequence number.
Do you have the USNJournal? Does it contain anything relevant?
Simplest scenario is: user extracted file X using something like WinZip or 7-Zip, which sets timestamps. (PKZIp does something similar -- it can records and set each of the four standard NTFS timestamps.) Then, he deletes the file. And then repeats the extraction. That may cause the situation you're seeing.
Another possibility might be that the oldest of the two files was found to contain some malware, and the newest of them is the file with removed malware. There would be lots of other changes, as well as logs, indicating such activities, though. Have you found this particular file name logged anywhere?
And how about a file that was deleted by mistake, but restore by any of the possible backup solutions present in Vista?
(Added: Are the timestamps identical to the last bit, or only identical in the textual version that your tools show you -- i.e. within whatever rounding/truncation is taking place?)
- Senior Member
- PassmarkAt the risk of seeming daft. What is Metacarving? I know "meta" and I know "carving". But Metacarving? Surely this is a made up term.
- In theory there is no difference between theory and practice, but in practice there is. -
- Senior Member
Here are a few items of new information based on what has been written in the responses.
Most of the issues raised in the responses have been assessed and discounted already because of facts surrounding the computer forensic case, such as opportunity, expertise and motivation. There was no A/Virus software installed, nor any other automated system management applications.
The number of files involved in this issue is substantial but the identical timestamp replication is only between the active file record (which comes from the MFT) and the deleted file record, which is also extracted from the MFT.
The timestamps are identical to one second, according to the forensic case file. I have no reason to distrust the software, although I haven't tried comparing UTC timecode records. I can't recall if there are any UTC timecodes in the MFT (more homework)
The compressed folder range of possible scenarios may fit the known facts, but I am still testing timestamp behavior with different archiving programs and formats over the weekend.
Because the time gaps between the timestamps of each different file name is differing by only a few seconds over the entire range of files which are (and were) all in the same folder, I am sure some type of automated process has been involved.
My guess at this stage is a compressed folder was downloaded and the files extracted to their single repository folder, the individual files were then deleted, and the files then extracted a second time and left in the same repository,
However I would have thought this would have changed one of the 3 MAC timestamps for the deleted version of each file. My expeerience is that the Last Accessed Date is usually changed to the timestamp when the deletion occurred, but I am aware that different versions of MS Windows treat the Last Accessed Date differently.
Anyway any other thoughts/ideas or explanations most welcome.