| Author |
Message |
   
Nicholas Miles
Username: int3grate
Registered: N/A
| | Posted on Tuesday, Jan 20, 2009 - 15:45: | |
I am trying to figure out the correct way to calculate the size of file resident in the $DATA attribute of an MFT record. I know for a none-resident file I can just grab the "real file size" value from the $FILE_NAME attribute and it comes out correct every time. For resident files - this is not the case (real file size and allocated file size are always 0 in this case). I've tried calculating the file size by looking at the "attribute size" value present in the standard attribute header in the $DATA attribute and subtracting from that the value of the size of the header (taking into account the "name length" value which is almost always 0). This gets very close to the file size that Winhex and Windows show, but is always a couple bytes off for some reason... Does anyone know the correct way to get the filesize for files that have a resident $DATA attribute? Thanks, Nick |
   
Nicholas Miles
Username: int3grate
Registered: N/A
| | Posted on Tuesday, Jan 20, 2009 - 15:45: | |
Sorry - forgot to specify I'm working with NTFS. |
   
Nicholas Miles
Username: int3grate
Registered: N/A
| | Posted on Tuesday, Jan 20, 2009 - 16:00: | |
Also - I meant to post this in the disk editing section... Sorry about that. |
   
Nicholas Miles
Username: int3grate
Registered: N/A
| | Posted on Wednesday, Jan 21, 2009 - 19:23: | |
Alright, found out that the real file size field and the $FILE NAME attribute does return the right size, it's just padded to an 8 byte boundary... Is there anyway to determine the amount of padding? |
   
Nicholas Miles
Username: int3grate
Registered: N/A
| | Posted on Wednesday, Jan 21, 2009 - 19:50: | |
Nevermind - what I'm looking for is stored at offset 0x10 in the standard attribute header. |