Dear All,
Hope you all are well )
This has been bugging me for some time. I have two devices 1. Computer (Win 8.1) and 2. Portable HDD (NTFS).
I have the same folder on Device 1 and Device 2. This folder (Parent) has some files and a folder
Looks like folder from 1 has been copied across to 2. Here are the various timestamps-
For the files inside Parent
Device 1 | Device 2
File Created 2014 | File Created 2015
Last Accessed 2014 | Last Accessed 2015
Last Written 2014 | Last Written 2014 (same as Dev 1)
Entry Modified 2014 | Entry Modified 2014 (same as Dev 1)
For the folder inside Parent
Device 1 | Device 2
File Created 2014 | File Created 2015
Last Accessed 2014 | Last Accessed 2015
Last Written 2014 | Last Written 2015
Entry Modified 2014 | Entry Modified 2015
How can the "Entry Modified" for files on Device 2 be earlier than "File Created" on Device 2? (in fact the same!!). However, in case of the folder, it gets updated.
Any ideas?
Well, those are yearstamps! wink
Let's see if this helps you.
You have three main "characteristics"
- File Created <- or "CreationTime"
- Last Accessed <- or "LastAccessTime"
- Last Written <- often called "modified" or "LastWriteTime"
and a fourth one ("Entry Modified" and the other "names" being Encase specific I believe, called "ChangeTime (in $MFT)" in the tool I am giving a link to later in this post)
https://
The first three are "normal" file attributes, the fourth is actually a $MFT modification date.
A file and a folder are "different" objects, in the sense that the same characteristics may mean or behave differently for a file or for a folder.
#1 is a characteristic of the file (or folder) that is specific to the filesystem on which it resides (and is not normally kept/carried over when copying)
#2 is a characteristic of the file (or folder) that is specific to the filesystem but that is normally carried over with the file when copied (though it may depend on how exactly the file is copied or selected for copy)
#3 is a characteristic of the file but unlike the other ones it really belongs to the file, it is carried with the file on copy and remains the same until the file is actually changed.
#3 for a folder/directory instead it would make no real sense and it is usually the same date as "created", see also
https://
Different copy methods may create different results on the target, and there are some peculiarities that can be created by the OS itself or by a (seemingly innocuous) command that has been run in it see also
http//www.forensicfocus.com/Forums/viewtopic/t=9465/
and linked to documents/threads.
Characteristics #1 to #3 should correspond to three fields in the $MFT, the SI times ($STANDARD_INFORMATION), but there are also the FN times ($FILE_NAME) that can be doubled if it is a long file name.
Examining directly the $MFT with a tool like Joakims (Joakim Schicht) excellent ones
https://
may be a good idea.
See here for a nice little explanation
https://
The fourth is most probably also the SI "Change Time".
jaclaz
Thank you jaclaz for the reply.
I gave the year just to keep things simple - wink
Yes, it is the MFT Entry Modified timestamp that was bugging me and after some further digging I found the answer.
If you move folder B on the device into folder A, also on the device, it will not update the MFT “Entry Modified” timestamps of the contents of the folder B.
Once again thank you for your reply and also for the links you have posted. )
SANS has a great poster for helping to understand when MACE times are modified during certain windows events. It's called
SANS has a great poster for helping to understand when MACE times are modified during certain windows events. It's called
Windows Forensics "Evidence Of"
It's a pity it doesn't document the research it is based on. Don't know about you, but I've not seen any documented research into this particular time stamp.
Just ask yourselves what does 'File Copy' timestamp (in the rules box of the poster) really refer to? The original or the copy? And just how was the copy performed? By system call, by command line or by Windows Shell operation? And the incurable sceptics might ask how outside influence on the timestamps was eliminated – so that no background operations of Windows affected the tests.
The basic time stamps can be set by any user with the appropriate rights (SetFileInformationByHandle()). If nothing else modifies things, there are default rules about what happens. However, Windows Shell is known to modify timestamps an operation done in Windows Explorer does not necessarily produce the same result as an operation performed from the command line. And Windows Shell is not the only program that does so file archivers do it, file transfer software does it, … and so on. Are there any present on the computer examined? Can they be excluded from analysis?
Interpreting a time stamp can only be done under a set of assumptions for each interpretation. An honest examiner documents them all.
One thing I find thought-provoking is the number of people who refuse to use Win 8.1 shell, but instead prefer one of the add-ons that emulate the old start menu ViStart, Classic Shell, etc. Do those follow the same 'rules' as the standard Microsoft components? In the absence of any solid research … it might well be that the presence of any of them invalidates some of those 'rules'.