±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 3 Overall: 34854
New Yesterday: 2 Visitors: 135

±Follow Forensic Focus

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

RSS feeds: News Forums Articles

±Latest Articles

±Latest Webinars

$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
Go to page Previous  1, 2, 3  Next 
  

Re: $MFT Resident data

Post Posted: Tue Mar 19, 2013 12:54 am

- randomaccess
From parsing mft records manually recently (CFCE), it seems like there is empty space between the attributes.


Attribute sizes are always a multiple of 8. This works great for the SI attribute, not so much for filename and resi data.
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6 

Patrick4n6
Senior Member
 
 
  

Re: $MFT Resident data

Post Posted: Tue Mar 19, 2013 3:30 am

Here is the correct MFT record file; www.mediafire.com/view...aur8563cl4

Sorry for the previous one.

Happy to see someone beating that, given 1024 byte sized records Smile
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: $MFT Resident data

Post Posted: Tue Mar 19, 2013 5:53 am

- joakims


Happy to see someone beating that, given 1024 byte sized records Smile


Joakims, besides posting the file, can you explain how you are creating/writing it?
What do you mean 1 character name?
Without extension?
The tests I made were making a file named "1.txt".
What do you mean "outdated" Windows versions?

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: Tue Mar 19, 2013 7:15 pm

Creating the file was just a matter of making a copy of a file I knew was resident, and named it "w", with no extension. I knew the original file was 707 bytes, so it was already close to limit. Next I ran my own mftrcrd tool on the file to see visually what it looked like in the MFT record. I ran it like this:

Code:
mftrcrd_x64 F:\w -a attriblist=off indxdump=off

I had the file open in a hex editor and added bytes, then re-ran the tool, and repeated until it turned non-resident.

Point about the $FILE_NAME attribute is that the filename length will impact on the attributes size. The $STANDARD_INFORMATION attributes is as far as I know fixed in size. The record header is also fixed, however was different in earlier implementation (like in 2k I think), in that it did not have file references as is used now (8 bytes). I am not able to reproduce that here, but if you can, then you should be able to increase the max size of resident data by at least 8 bytes (maybe more, not sure).
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: $MFT Resident data

Post Posted: Wed Mar 20, 2013 7:59 am

- joakims
....
I had the file open in a hex editor and added bytes, then re-ran the tool, and repeated until it turned non-resident.

Point about the $FILE_NAME attribute is that the filename length will impact on the attributes size. The $STANDARD_INFORMATION attributes is as far as I know fixed in size. The record header is also fixed, however was different in earlier implementation (like in 2k I think), in that it did not have file references as is used now (8 bytes). I am not able to reproduce that here, but if you can, then you should be able to increase the max size of resident data by at least 8 bytes (maybe more, not sure).

Very good, thanks. Very Happy

But this does not answer the original question, which I will try to re-word.

I used three (actually 4) different methods to create a file with the SAME name (which is/was 1.txt) under the SAME account and in the SAME directory, with increasing sizes, until it "exited" the $MFT and it occupied a cluster.

In a "perfect world" the size that should trigger the "migration" of the file from $MFT to "cluster" would be the SAME, then if you change the name, create it under a different folder (permissions) or under a different user (ownership) or on a different system and what not, this "fixed no matter the tool used" limit may change (as an example resulting a bit higher for a shorter filename and a little bit lower for a longer filename).

I will do more tests, in a fully reproducible way, adding a few other "writing approaches" and will check if examining the results with your mftcrd tool I can pinpoint - if not the reason why - at least the HOW/WHERE the diffference comes out.

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: Wed Mar 20, 2013 9:13 am

can you post up the files when they are at the maximum data attribute length for each process?

(I dont know why that sentence was so difficult to phrase)  

randomaccess
Senior Member
 
 
  

Re: $MFT Resident data

Post Posted: Fri Mar 22, 2013 4:00 pm

- randomaccess
can you post up the files when they are at the maximum data attribute length for each process?

(I dont know why that sentence was so difficult to phrase)


OK, started again from scratch. Smile

Here:
www2.zshares.net/vac5zybch4of

is a small (around 3 Mb) "floppy-like" image (suitable for being mounted in IMDISK or similar) with a set of pre-made files AND the tools and batches used to make them.
The size was chosen as it is (roughly) the smallest size you can make a NTFS filesystem in windows with a 4096 bytes cluster (i.e. same size as most "common" NTFS filesystems on disk) with the built-in in XP format command.

There is (as seen) a connection between filename length and "available space", but still fsz and fsutil *somehow* manage to make smaller sized files.
744 is confirmed to be the most you can put in a file which filename is within these lengths/form:
1
12
1.1
123


The algorithm (valid for "normal" file generation through dsfo or ECHO/ECHOO and similar) is simple enough (by design this applies only up to 8.3 filenames), in batch:

SET Max_size=744
SET /A Sum=%Name_length%+%Ext_length%-1
IF %Sum% geq 3 Set Max_size=736
IF %Sum% geq 7 Set Max_size=728

fsz and fsutil "steal" Shocked 8 bytes from the above.

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

jaclaz
Senior Member
 
 

Page 2 of 3
Go to page Previous  1, 2, 3  Next