Open randomaccess3 opened 1 year ago
It's not hard to add but necessitates providing the relevant MFT file as well.
How are the columns different from MFT output?
On the wrong computer and hitting a bug in parsing the $I30 on Andrews Anti-Forensics Disk Image v1.0
image, but the timestamps were created, accessed etc - would be useful if they were Created0x10
After a bit of testing (and re-reading the FOR508 material) - even though it says it's a FILENAME attribute, it gets the Stdinfo timestamps.
yea there is (usually).synchronization between SI and index records.
Not always. The last access timestamp can be different in the $STANDARD_INFORMATION and $I30->$FILE_NAME attributes.
Sure but that's where the other parts of the journal come into play. Edited original
See: ntfs-lastaccess.raw.
So $i30 copies FN attr but then syncs SI timestamps except sometimes there's a discrepancy with the last accessed timestamps?
No, the timestamp sets in the $STANDARD_INFORMATION and $I30->$FILE_NAME attributes are supposed to mirror each other. The former is used to serve requests from stat-like API calls, the latter is used to serve requests from readdir-like API calls (e.g., FindFirstFileA).
And sometimes the file size is also different between the $DATA and $I30->$FILE_NAME attributes. For example, create an empty directory, then create a single file in this directory, then slowly grow its size by writing some data into the file. Occasionally, the file size in the $I30->$FILE_NAME attribute becomes "smaller".
Playing with your $I30 parsing in MFTECMD. From my understanding, would it be a stretch to add a full path or parent path column and provide the MFT like you have with the $J?
Also - since the timestamp is the FILENAME timestamp, can you align the headers with the MFT parsed output from MFTECMD?
Playing with Bulk Extractor-Rec and it pulls out $i30 attributes into a file. MFTECMD worked really well to stitch it all back together. Ran this over an encrypted VHDX and will do a comparison with running Joachim Schictts tools