±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36487
New Yesterday: 5 Visitors: 190

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

$MFT Resident data

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3 
  

jaclaz
Senior Member
 

Re: $MFT Resident data

Post Posted: Jun 17, 16 14:55

Re-uploaded file here:
www.filedropper.com/ntfs3mb

(just in case someone wants to try and reproduce)

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

Chris_Ed
Senior Member
 

Re: $MFT Resident data

Post Posted: Jun 17, 16 20:36

This is a cool Friday afternoon problem. Smile

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.  
 
  

jaclaz
Senior Member
 

Re: $MFT Resident data

Post Posted: Jun 18, 16 00:41

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

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" Smile , 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:
www.forensicfocus.com/...9/#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
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

jaclaz
Senior Member
 

Re: $MFT Resident data

Post Posted: Mar 25, 17 19:18

Only to keep things as together as possible, just tested 4096 bytes sector see here:
www.forensicfocus.com/...3/#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
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

pbobby
Senior Member
 

Re: $MFT Resident data

Post Posted: Mar 28, 17 02:12

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.
_________________
Don't get baited. 
 
  

jaclaz
Senior Member
 

Re: $MFT Resident data

Post Posted: Mar 28, 17 13:45

- pbobby
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
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 

Page 3 of 3
Page Previous  1, 2, 3