I did try getting my tool to re-create the file path. The issue is, that with the 2,000,000 records that were usually extracted, it took ages!
I may look at re-doing this in the future or a newer version of my tool.
I made a proof of consept some time ago for rebuilding paths. Ended up making a separate program for it and making use of mariadb. But there are some challenges with doing something like that, for instance renamed directory.
The tool is open source and not dangerous. It can do one thing and is good at it. To extract from a vsc you need the volume mounted so that the shadow is exposed through the OS symbolic link.
I believe you that the tool is not malware - it is the first time the Chrome browser itself has blocked a download on the laptop I attempted to download the zip file (weird).
I downloaded the desktop client version of GitHub - maybe that will let me "clone" the repository if I am using the correct terminology.
I downloaded the desktop client version of GitHub - maybe that will let me "clone" the repository if I am using the correct terminology.
Either that. Or download the zip using another browser. Or compile the au3 source yourself.
The usual annoyance wrt AV is that these type of compiled exe's are backlisted by default by less sophisticated AV.
I did try getting my tool to re-create the file path. The issue is, that with the 2,000,000 records that were usually extracted, it took ages!
After some playing around optimising the process, we got up to around 100,000 path lookups per second in OSF. Of course it depends a lot of the hardware and the image format.
As you pointed out, the USNJrnl contains the file name, but not the path. The USNJrnl also contains the MFT record ID and parent ID. To get the full path to the file you need to cross reference the MFT record ID and parent ID with the MFT.
Of course the MFT record might have been updated after the USNJrnl was created. We flag this in the viewer (see screen shot in prior post) by highlighting the record in red. i.e. there is a chance the path might now be out of date.
Ok, I think we just slightly misunderstood each other. Nice that point out in red that a path has changed at some later point in time.
As for paths resolved from UsnJrnl, I was referring to a method of using UsnJrnl only to resolve paths. By doing that you can resolve certain paths that existed at an earlier point in time than what MFT knows about (probably part of the path for those lines in red from your screenshot).