Linux ntfs-3g imple...
 
Notifications
Clear all

Linux ntfs-3g implementation and deleting files  

  RSS
hvisti
(@hvisti)
New Member

Hi all,

I'm currently writing code related to NTFS forensics and test image creation. I just came across something that puzzles me.

No matter which source I look, when you delete a file from a NTFS partition this is more or less what should happen
1) The MFT record is marked unused in its flags (0x16)
2) Blocks allocated to the file are marked as free in $BITMAP
3) Directory tree where the file belonged is reshuffled

However, when I mount a ntfs partition to Linux (Ubuntu 12.04) with ntfs-3g (needed to support alternate data streams), in addition to completing the above steps, the following happens

4) FILE_NAME attribute is deleted from the MFT record.

This is a huge irritation. Forensic software can still locate these files but they are orphaned and without file name. The second set of time attributes stored in FILE_NAME is also lost.

Any comments on this? Or any way around? Curiously, STANDARD_INFORMATION and DATA attributes are not deleted, only FILE_NAME. Is this how NTFS file deletion is supposed to happen? If it is, I am a bit puzzled where EnCase and others can actually get the file name, for partitions operated under Windows.

Kind regards,
Hannu

Quote
Posted : 25/06/2013 2:24 pm
minime2k9
(@minime2k9)
Active Member

Just to clarify, are you mounting the volume as read only?

ReplyQuote
Posted : 25/06/2013 3:27 pm
hvisti
(@hvisti)
New Member

Just to clarify, are you mounting the volume as read only?

No, read write.

What I am actually doing is a tool that creates test images for forensic students to play with and to test different tools. One of the simplest things to do is of course to delete a file and let them recover it. Another interesting thing to do is timeline related stuff - to have the student answer the question "could this have happened" or "reconstruct the chain of events".

I have written the part that modifies some NTFS structures, especially timestamps. Some "hiding methods" are notoriously difficult to implement on raw file system. I use the unmounted image to write to file slack or unallocated space but deleting a file is a mess as then I'd need to write code to re-balance b-trees.

This is why I decided to just mount the newly created image, do deletions, unmount, read in NTFS structures as they are and do the timeline setup. I came across this problem when my application started crashing if there is a deleted file on the partition. And the reason to this was, the FILENAME attribute was missing for every deleted file.

I do not actually think it should be missing but it is, which leads me to think the ntfs implementation does this intentionally. It may be nice if someone wants to destroy evidence but for my purpose this is a nuisance

ReplyQuote
Posted : 25/06/2013 4:06 pm
Chris_Ed
(@chris_ed)
Active Member

Looking through the source, the section in question (as far as I can tell) starts in dir.c, line 1885

/*
* Search for FILE_NAME attribute with such name. If it's in POSIX or
* WIN32_AND_DOS namespace, then simply remove it from index and inode.
* If filename in DOS or in WIN32 namespace, then remove DOS name first,
* only then remove WIN32 name.
*/

So as you say it seems that this is a definite design choice. Bear in mind that as there has never been any full documentation, it is possible that the creators assumed that this was normal operation for NTFS at the time of writing ntfs_3g.

By all means send a message to the dev community and let us know if you get a response! )

P.s, looking at the most recent release notes it seems they may have "fixed" this..?

ntfs-3g keep the name of a deleted file in place for easier undeletion

ReplyQuote
Posted : 25/06/2013 4:42 pm
hvisti
(@hvisti)
New Member

Looking through the source, the section in question (as far as I can tell) starts in dir.c, line 1885

/*
* Search for FILE_NAME attribute with such name. If it's in POSIX or
* WIN32_AND_DOS namespace, then simply remove it from index and inode.
* If filename in DOS or in WIN32 namespace, then remove DOS name first,
* only then remove WIN32 name.
*/

So as you say it seems that this is a definite design choice. Bear in mind that as there has never been any full documentation, it is possible that the creators assumed that this was normal operation for NTFS at the time of writing ntfs_3g.

By all means send a message to the dev community and let us know if you get a response! )

P.s, looking at the most recent release notes it seems they may have "fixed" this..?

ntfs-3g keep the name of a deleted file in place for easier undeletion

Thanks a million! I did not realise they had published a newer version. This sure fixed the problem and saved me a week of b-tree balancing work.

Kind regards,
Hannu

ReplyQuote
Posted : 25/06/2013 6:35 pm
Share: