-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scan for orphaned $FILE_NAME attributes of attribute list MFT entries for path reconstruction #29
Comments
Changes to https://github.com/dfirlabs/ntfs-specimens to generate test data dfirlabs/ntfs-specimens@41e93ad Looks like the Linux NTFS implementation re-uses the first available (user) MFT entry, by default The changes to the script do not have the desired behavior but highlights another interesting case. Looks like the Linux NTFS3g 2021.8.22 implementation allows the creation of files named
Adding |
Looks like the NTFS3g implementation actually removes the $FILE_NAME attribute from the list on removal: before removal
after removal:
|
Having a look at Windows before:
after:
So Windows does not remove the $FILE_NAME attribute from the list on removal |
An additional factor to account for in the scenario is if a Folder1 created after File2 (test scenario in ntfs-specimens needs a bit of tweaking to prevent testfile1 from being overwritten)
Which is not the same |
Made changes to test data scripts. With the larger $INDEX_ROOT attribute Windows seems to prefer to store the $FILE_NAME attribute in the "main" MFT entry (not in an attribute list MFT entry). Forcing $INDEX_ROOT to be non-resident has pushed $FILE_NAME back to the attribute list MFT entry. So the a new Folder1 can be created after File2, and it would likely be good to provide for means to distinguish between the deleted Folder1 and the existing Folder1 in the path hint. |
When reading a $MFT scan for orphaned $FILE_NAME attributes of attribute list MFT entries for path reconstruction. See log2timeline/plaso#3840 for more context.
$Deleted\Folder1\File1.txt
or$Orpan\Folder1\File1.txt
?Folder1
created afterFile2
The text was updated successfully, but these errors were encountered: