OK.. so last night I had time for some quick unofficial unscientific testing.
On a laptop with Windows 7 I uploaded a 686MB video file via a USB thumbdrive.
I thought I used USB 2 for a slower transfer rate but it transferred very quickly.
I started the transfer at exactly 0212601.
The file finished at 213634.
Xways reports the Created time as 212601, exactly the time I started the download, and a "Record Changed" date as 212634, exactly when the file finished.
I then put the drive back into the laptop and played the video for a few seconds and recorded the time I played the video. 230605
Xways shows a Record Changed time of 230606.
So, in this quick unofficial unscientific testing the windows 7 did log the correct Last Updated date and time.
Larry
On a laptop with Windows 7 I uploaded a 686MB video file via a USB thumbdrive.
"Uploaded"? "Transferred"? "Download"?
What you did sounds like a simple copy operation.
I then put the drive back into the laptop and played the video for a few seconds and recorded the time I played the video. 230605
Xways shows a Record Changed time of 230606.
So, in this quick unofficial unscientific testing the windows 7 did log the correct Last Updated date and time.
This thread started out with you asking about Last Accessed times, and now you're referring to "Record Changed" time, which is an entirely different time stamp.
In each of the attributes in an MFT record ($STANDARD_INFORMATION and $FILE_NAME), there are four time stamps…created, last modified, last accessed, and "record changed". I'm assuming here that when you say "last updated", you're referring to last modified.
What I'm curious about is, what happened to the issue you were having with the last accessed time stamps?
So, in this quick unofficial unscientific testing the windows 7 did log the correct Last Updated date and time.
Sure it does, though the value is generally called "Last Access".
The file was accessed and the value was changed, this is normal.
The whole point of that Registry setting is about directories, which Last Access timestamp was updated even when there was no "actual access", such as in a DIR command or running a search for a file.
For files, the fun begins in which operations on them actually change that Timestamp.
You seemingly have just proved that playing a video file does changes it's last access timestamp.
But would the same happen for (say) a .txt file opened in Notepad? ?
jaclaz
So, in this quick unofficial unscientific testing the windows 7 did log the correct Last Updated date and time.
(Added I now see that keydet89 and jaclaz have already made some of the same points I try to make.)
But just because it was … I'd rather call it 'informal' … you cannot convincingly connect the video playing with the Last Access time stamp update. You played a video, and you observed that the time stamp was updated. You also need to connect the two causally.
I'll now put my black hat on. I shouldn't really – informal tests don't really stand up to nitpicking, and are not meant to do so. I just want to show how difficult it can be to create a convincing test. To do so I need to enter 'hostile mode', much the same as a proof reader who tries to find errors rather than non-errors.)
The main question is my mind is what question you really were testing. That directory operations affect last access timestamps for *all* directories in the file's path, or that they don't, and only file access does?
You report (or seem to report) that Last Access Update changes after playing a movie. But you do not report the last access time stamp of the directory hierarchy. Thus, you're just reporting a 'datum', you're not connecting it to a question.
You reports that Windows updates Last Access … but you've only tested a single program. As Windows allows a programmer to change file timestamps at will, could this be a special case, and it really is the program you use that makes the change? That possibility needs to be eliminated.
You chose a rather complex program (I think – what program were you actually using?) for the test – the same test could probably have been performed with Notebook, a much simpler program (and one which all Windows users have). However, the same objection could be made as Notebook is not open source. More careful test design would, I think, either use a suitable open source program (there are Windows versions of 'touch' out there that may be useable), or create one, that code inspection can show does not do any such manipulation. Without it, the objection that 'the program did it, not Windows' is legitimate.
Another complexity is that of Windows itself – all kinds of things seem to happen 'by themselves'. Is there a technical possibility that some other program caused the last access time stamp to be updated? If so, the possibility needs to be eliminated or at least minimized. (This probably requires repeated testing, and careful configuration – turn off indexing, turn off scheduled jobs, minimize other background components such as antivirus. And perform a number of null tests in which no test action is performed at all, and verify that there's no change in the relevant time stamps.)
Windows Shell (that is, Windows Explorer and the components it uses like 'open file' dialog boxes) are known to implement its own rules for time stamps, but I don't know of any thorough examination of it. On XP, just moving the cursor over a file icon caused last access to be updated, as Explorer accessed the file to get at the metadata shown in the popup. I haven't tested that in Windows 7, but I assume it is still so. I'm not sure I know how to eliminate that without eliminating Windows Shell – it may be possible by using only keyboard navigation, though. I'd probably go command line entirely, myself.
Also, what is 'Record Change'? While I would (informally) be inclined to accept the implication that it corresponds to Last Access, I would not do so if this was 'real life'. It could just as well refer to 'ChangeTime' or 'LastWriteTime'. (Not too long ago I saw someone in the EnCase support forum reporting that some tool had got time stamps wrong time stamp X was reported as time stamp Y. Not good.)
Finally, how was the test system configured? Was NtfsDisableLastAccessUpdate on or off? Your test implies it was on, but you do not say that you checked it.
No, wait. There's a last point can I repeat your test? I should – and I should get the same results. But without a detailed test description – was the video played by starting the player program and opening the video file, or was it right-click and 'Play'? Does it make a difference? I don't know – but as the right-click relies on Windows Shell, I can't exclude the possibility.
OK, black hat off.
Creating good, convincing tests is quite difficult. It's probably even more difficult to do so for digital forensics, as a minor change in a piece of software can change just about anything. Few, if any, other forensic sciences have to deal with differences between v1.0 and v1.1 in their subject matter. (Or, putting my black hat back on for a moment, do even check to verify that they don't examine a v1.1 release – my black hat is made of tin-foil, in case you hadn't noticed … )
And that point also enters the design of a 'forensically sound' test what software releases were tested? Test results cannot strictly be extrapolated to other versions. There's always a risk that some change or bug fix broke the thing being tested.
No, I'm not saying that forensic analysts should create tests. I only say that they need to be able to evaluate test results and rely on those that are sound.
A problem is then how to identify a sound test or test methodology. Used to be publication in a peer-reviewed journal. Not too many of those around these days…
Worst case scenario Perhaps the recent reversal of FBI microscopic hair analysis results (http//
Not a nice place to be.
I am sorry but I don't understand, a (properly implemented) experiment either confirms a given behaviour or it does it not.
If the experiment is badly implemented then obviously the results are invalid.
The point of my questions is probably best summarized as the question 'So how do we know if a reported result was obtained by a properly implemented experiment?'
So many results are reported in blogs and articles and books … but the sources of the results are not.
The point is important forensic sciences (with the sole exception of DNA testing, I think) are coming under closer and closer scrutiny due to a demonstrable lack of scientific foundation for their results.
The point of my questions is probably best summarized as the question 'So how do we know if a reported result was obtained by a properly implemented experiment?'
So many results are reported in blogs and articles and books … but the sources of the results are not.
The point is important forensic sciences (with the sole exception of DNA testing, I think) are coming under closer and closer scrutiny due to a demonstrable lack of scientific foundation for their results.
I fully concur that it is a crucial point. )
I believe that "by default" a scientist (in the best sense of the word) should trust noone but the results of (repeatable) experiments.
I would add the not-so-trifling fact that a lot of people either lack (no offence intended, particularly for those - like myself BTW - that are not professionals in the field and that do whatever they do just for the fun of it) the needed exactness in the description of the experiment or - deliberately or unknowingly - alter the essence of the experiment or of the findings with some (unjustified) hype.
Unfortunately the latter is what usually makes them become "reknown" and that make the (improperly described) experiment or relative findings eligible for publication on a scientific paper or magazine or related news sites, conferences etc.
There is a definite lack of (proper) "peers review" and even when some of it is actually performed, often it is not adequate, the phenomenon covers all sciences, and the growing number of improperly managed papers and conferences fuels a perverted spiral. cry
The known experiment by John Bohannon
http//
could be extended specifically to the digital forensic field without any effort (I have my reasons to believe this, though I am not going to make names publicly)
And from time to time a visit to
http//retractionwatch.com/
confirms that the situation is IMHO preoccupying.
jaclaz
Well, thanks for all the feedback on this topic.
The test was not meant to be in the least bit scientific. It was just a simple basic quick unofficial unscientific testing.
Basically I wanted to see of the last-accessed date and time stamp was changed when a file was viewed. And that's it..
The file in question was a AVI so thats what I tested using Windows Media Player just like the video in question, using Windows 7, just like the computer in question.
Quote from someone… "This thread started out with you asking about Last Accessed times, and now you're referring to "Record Changed" time, which is an entirely different time stamp."
Being a new self trained (until the next So Cal class) user of x-ways I was in the belief that the the record changed and last accessed timestamps were synonymous but I see that they probably are not.
Also, while reading some of the Microsoft documentation it stated that NTFS may delay writing the last accessed time stamp for up to an hour.
So, today I reinserted the hard drive back into my computer and played the video but waited for a few hours before shutting it down and reacquiring it..
THe Last Accessed time stamp had not changed on the file or the folder that contains the file.
I believe that after this very basic, quick, unofficial, unscientific testing and reading all your feedback I can say that at the every most, Windows last accessed timestamps in Windows 7 can not be trusted at all. In my tests, the time stamps were not updated in any of the 3 or four tests I did..
Larry
I believe that after this very basic, quick, unofficial, unscientific testing and reading all your feedback I can say that at the every most, Windows last accessed timestamps in Windows 7 can not be trusted at all. In my tests, the time stamps were not updated in any of the 3 or four tests I did..
Maybe you are going a tadbit too far.
Let's make an example.
You have a file with
Creation 2014/12/31 2236,15
Modified 2014/12/31 2313,27
Last Access 2014/12/31 2350,44
Assuming that no manual tampering occurred with the timestamps, you can say
1) The file was created on 2014/12/31 2236,15
2) The file was modified on 2014/12/31 2313,27
3) The file was accessed on 2014/12/31 2350,44
The point with #3 is that you can surely say that
The file was accessed AT LEAST on 2014/12/31 2350,44.
(and WHAT caused the update of the access time may depend not on the mentioned Registry setting, but from a whole set of different factors, like the shell/file manager used, by the running of any number of "scanning/searching" programs, from the very nature of the file itself and from the specific app that may have opened it).
But you cannot normally say that
The file was NEVER accessed in year 2015.
The context is also very important, if (say) you find 237 files (say in a same directory or of the same type ".XYZ") with a Last Accessed time within 3 seconds it is clear that the access recorded is the result of some form of automatic scanning, search or listing (or however effect of a running program), if you find three video files with the access times of the second and the third roughly similar to the access time of the previous one + it's play duration you could consider it a hint that the three files were viewed/played in sequence.
Everyone around here suggests making full system timelines for a reason wink .
jaclaz
So timeline analysis is recommended for several reasons.
Not attempting to overcomplicate this, but want to emphasize the importance of taking into account other filesystem artefacts in the analysis in addition to the obvious $MFT (that just gives you the status of 1 specific point in time). For instance, by analysing the $LogFile you will get some more information about what has happened on that volume over time. Maybe also a $UsnJrnl is present. There may also be other sources like shadow copies, which basically is a snapshot of the volume back in time that contains earlier versions of files including those already mentioned.
Timestamp tampering is of course possible, which is one of the reasons why one really should consider proper timeline analysis. For instance, SetMace may let you modify all relevant timestamps in a given file's $STANDARD_INFORMATION (inside the $MFT record) as well as its $FILE_NAME attribute (inside the INDX record of the parent). The program perform these timestamp manipulations in such a way, that there will not be any trace of the modification in the $LogFile or $UsnJrnl (unless SetMace itself was actually stored on the volume and you will find traces of that). And to make things worse, it can also modify all these timestamps on all present shadow copies for the target volume. However, by analyzing $LogFile and/or $UsnJrnl things may come to light and become clear. Check out the new $LogFile parser that may be useful; https://
So consequently, staring at $MFT only (even considering shadow copies), may provide misleading information that could result in incorrect conclusions.