This topic is extremely "narrow", it is actually more "forensics" than "Team Reboot", and possibly the only person on Earth that may actually be interested, even marginally, to this is Joakim.
While doing a few "crazy" experiments with re-creating a "fake filesystem" from a FTK imager .csv (which BTW is a TAB delimited text file) I found some queer behaviour of the NTFS (or of the XP I tested this in or of the Explorer in it).
Everything began here:
Chad131 had what seemed to me a nice idea for a test:
Though the "generic" (as opposed to "specific FTK imager .csv") has been IMHO nicely solved with the tool mentioned here.
I decided to do a few tests and Francesco kindly posted a "test" .csv:
So I started looking for some tools that I could use in one of my "primitive batches".
To create the sparse files I initially tried the re-known tool by Bo Branten mksparse.exe, but soon noticed that it has an issue, i.e. it *needs* a filesize that is multiple of 512 bytes, so I digged a bit more in my toolbox and came out with makesparsefile.exe, a nice, lesser known tool:
Copyright © 2008 Jérôme Hodé (he also provides a nice makesparseVDI tool and more):
Then I checked first thing the Nirsoft Nircmd (which is a very nice tool and IMHO a "must have" one):
BUT it seemingly has not the "nanosecond" kind of precision in time that I needed (and BTW it misses a simple way to get the file time/date)-
Then I checked the (another extremely nice set of tools), the Swiss File Knife:
also seemingly misses a way to get the file date/time but that has the needed "nanosecond" precision).
I take this back.
The sfk filetime -all -flat or sfk filetime -all flat2 works nicely.
So I put together one of my as usual half-@§§ed batches to test the approach.
Some of the "filesystem structures" described in the FTK imager .csv miss (obviously) the Created/Modified/Accessed timestamps, so I thought I could set them to "0".
First "surprise", notwithstanding the "theoretical" date limit of NTFS of datres going back to 1601:
I did not manage to get the sfk to accept dates earlier than 01-01-1980 (this is most probably an "internal check" of the sfk tool), anyway, I set those elements (rendered in the fake filesystem as directories) to 01-01-1980 00:00:00.000000.
In an Explorer view of the mounted filesystem those had NO Created/Modified/Accessed AT ALL. <- puzzling, but actually exactly what I was looking for (whilst using another file-manager, i.e. 7-zip or doing a DIR in command prompt gave the "right" 01-01-1980 date and time).
The other evident issue is that since my batch created the structure in the same order of the .csv, when I used the sfk to "touch" a file, the directory in which it was contained had it's Accessed time changed.
So one needs to either "touch" the directories after having set all files or re-process the dirctories in a "second pass", only a minor issue.
But I decided to go further and - just for the fun of it - "0date" all elements in the filesystem, as I was trying to understand how to deal with the OS changing - *somehow* and/or *automagically* - Accesssed dates/times when performing actions on the filesystem.
I did a couple "DIR /S" and Windows Searches on the volume and left it alone for some 24 hours with the machine running, the reason being explained here:
The ONLY file that had it's access date changed was \P1\[root]\$Bitmap <- queer.
So, I redid from scratch, and noticed that almost immediately after the "0date" touching, let's say within "a few" minutes delay, and WITHOUT any command given in the console, nor in GUI, still the \P1\[root]\$Bitmap Accessed time changed.
A few more tests gave other *random* files accessed, like $Upcase, or $I30.
Guessing that, even if made as "plain" files, filenames like $Bitmap, $I30, etc. had some "special" meaning, I tried "renaming them" to §Bitmap, §I30, etc.
Fourth surprise, it didn't change anything in the "queer" behaviour.
So I thought, of course, by default the indexing service is ON, so I turned it OFF for the volume and re-did the file/folder creation, with same results.
So, I decided to avoid completely those names and just get a bunch of "random" files/folders, from one of my other files, copy them to the volume and re-0date all of them, with same result.
Another "queer" thing is that while if I right click in explorer on a file and choose "Properties" the Accessed date/time is (obviously) changed, the same thing does NOT happen if I do the same thing on folders, that however do change their timestamp if you (say) delete a file which is inside them.
Conclusion (temporary) is:
- Windows XP, or Explorer (or *whatever* in the running system) accesses at least one file in a mounted volume "by it's own will".
So, I re-did from scratch, but this time running FIlemon to "watch" specifically the "*" (everything) on the M: volume.
I cannot make heads or tails of the result, it *seems* like Explorer accesses a number of files, seemingly looking for Alternate Data Streams but these accesses do not result (always) in a changed Accessed times.
Instructions to replicate/setup the test environment.
Get the mentioned tools makesparsefile.exe and Swiss File Knife, put them in a directory together with the attachment, which contains, the couple half-@§§ed batches I used and a copy of the "example.csv" from Francesco.
To get FileMon (yes the "old" version, that was merged with Regmon and resulted into Procmon), go to Softpedia:
The batches are "hardcoded" to drive M: (and to "example.csv").
What I used in my tests was a "Virtual Memory" IMDISK of 10 Mb in size (since they are all "sparse" files and directories there is no *need* for a larger filesystem.
Those that do not know EXACTLY where their towel is are kindly asked to ignore this thread/post and DO NOT EVEN THINK of playing with this kind of matters, botching an existing, good drive because of even a small mistake is a concrete risk.
Seriously: kids, DO NOT DO THIS at home.
As always, ideas, different paths to experiment with, etc. are welcome.