Notifications
Clear all

$MFT Resident data  

Page 2 / 2
  RSS
Chris_Ed
(@chris_ed)
Active Member

This is a cool Friday afternoon problem. )

I read through your reboot.pro thread and checked the provided

tiny

NTFS FS and as far as I understand there are four processes you used for your test files

- echo (738 byte limit)
- fsutil (728)
- dsfo (736)
- fsz (720)

Two of these are 3rd party tools specifically designed to manage FS data. As "echo" and "fsutil" are the only commands created by Microsoft, I think it is best to rely on them for determining "default" NTFS behaviour. So let's focus on them.

The nature of the file "creation" is not the same in your tests. As far as I can tell, your batch files perform the following operations

- echo - APPEND an existing file 1 byte at a time
- fsutil - CREATE new files in increasing sizes

I think there might be some key differences here. For my own test, I created a 4 byte file using a hex editor and saved it, using a standard Windows Save File dialog, to my NTFS volume. At this point, the data is RESIDENT.
I then expanded the file to 704 bytes - well within our limit - and after saving it went NON-RESIDENT. While initally this was confusing (as in your example, an APPENDed file went up to 738 bytes) it turns out that my other attributes were 320 bytes in length, so I only have 696 bytes available for resident data.
However - if I used the "Save As" dialog and created a new file - using the same 704 bytes of data - the new file is RESIDENT. So I can see different behaviour for "CREATE" and "APPEND" actions.

It is possible, therefore, that in the inner workings of the NTFS driver there is a different upper limit for the size of resident files depending if they are created or appended.

ReplyQuote
Posted : 17/06/2016 9:36 pm
jaclaz
(@jaclaz)
Community Legend

@Chris_ed
Yes, though you cited some preliminary results of tests done before creating the (hopefully) reproducible file just re-posted. 😯

My "final" results are as follows (as stated in my previous post and hinted in the readme file inside the given image

test_MFT_file.cmd is the demonstration that there is a difference between creating a file with fsz.exe or fsutil (MS tool) and with plainer methods.
The result of using dsfo are the same (tested) as using ECHO or ECHOO.COM, i.e. anything that "adds" bytes to the file.

fsz 736
fsutil 736
dsfo 744
echo (or echoo.com) 744

So there definitely is a difference between "create" and "append" ) , and this difference seems to be a constant of 8 bytes and is "common" between "original MS" and "corresponding third party".

Whatever "mechanism" fsutil uses it seems the same as the one fsz uses (create) and whatever mechanism ECHO uses, it seems the same as the one dsfo or echoo.com use (append).

The final result remains that given the optimum conditions
#1 a very short filename and #2 using the "append" method, as stated here
http//www.forensicfocus.com/Forums/viewtopic/p=6565939/#6565939
you cannot "stuff" more than 744 bytes in a resident file.

The "new" frontier of experimenting would be to see how many bytes can be stuffed on a 4 Kb "native" disk/filesystem (where the $MFT record is - I believe - the minimum accessible size, i.e. 4096 bytes instead of 1024).

jaclaz

ReplyQuote
Posted : 18/06/2016 1:41 am
jaclaz
(@jaclaz)
Community Legend

Only to keep things as together as possible, just tested 4096 bytes sector see here
https://www.forensicfocus.com/Forums/viewtopic/p=6587693/#6587693

…. I quickly made one and tested the effect on a file "size.dat" enlarged by fsz.exe.
The limit is 3776 bytes, 3777 gets the "dignity" of occupying a cluster

this size may vary of a few bytes depending on the actual method that is used to write the file and on the length of the filename, for file size0123.dat the limit is 3768.

jaclaz

ReplyQuote
Posted : 25/03/2017 7:18 pm
pbobby
(@pbobby)
Active Member

Haven't read the thread - maybe someone already commented.

I ran a challenge for my workmates on MFT resident data; I was able to fit just under 4k in JPG data in an MFT record.

It's because I made a disk that had 4k sectors instead of 512 bytes per sector.

ReplyQuote
Posted : 28/03/2017 3:12 am
jaclaz
(@jaclaz)
Community Legend

Haven't read the thread - maybe someone already commented.

I ran a challenge for my workmates on MFT resident data; I was able to fit just under 4k in JPG data in an MFT record.

It's because I made a disk that had 4k sectors instead of 512 bytes per sector.

Which is EXACTLY the topic of the LAST post before yours (which you may have actually read, even if you didn't read the entire thread).

"just under 4k" is "obvious" since the $MFT record is 4096 bytes in size on a 4096 sectored disk, a more accurate size number (like it was 720-736 for the 1024 record on "normal" 512 bytes) has been just reported as being between 3768 and 3776 bytes.

jaclaz

ReplyQuote
Posted : 28/03/2017 2:45 pm
Page 2 / 2
Share: