±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 33165
New Yesterday: 2 Visitors: 194

±Follow Forensic Focus

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

RSS feeds: News Forums Articles

±Latest Articles

RSS Feed Widget

±Latest Webinars

mft2csv - NTFS systemfile extracter and $MFT decoder

Forensic software discussion (commercial and open source/freeware). Strictly no advertising.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:06 pm

It signals the end of the record. You can regard it as an attribute that contains nothing and is called END.

Ddan  

Ddan
Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:11 pm

Yes I know that the 0xFFFFFFF is the END, but are you saying that the 4 bytes after it is just a definite end (a second confirmation of record end)? It just seems strange..
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:20 pm

Sorry misunderstood your question.

If you are talking about anything after the the four 0xFF bytes, this is just rubbish in the slack space. If you see a second set of these four bytes it basically means that the record was longer at some stage. You may even see more sets. If you have, for example along filename, this will also produce a dos name. The process of working out the dos name causes the record length to shrink. I think it starts out with two long filenames and then changes the first entry to a dos name. You can often see this as part of the dos name attribute.

Ddan  

Ddan
Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:32 pm

It can't be rubbish as it's the same 4 bytes all over. I have not done thorough tests, but just felt like asking based on past experience and what (from my memory) appears to be a consistent find.. Ie, the 4 bytes are there on volumes created on different systems.
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:45 pm

Read my earlier explanation using long filenames as an example. The same process would apply to the same file wherever it was, so I would expect the bytes in the slack space immediately after the end to always be the same.

If you can find an mft record which has an attributelist (0x20) attribute, have a look at that in detail. Before the 0x20 was created the record must have been almost full. You can often see complete attributes in the slack space of these records. You can also trace that these attributes are now in the 0x20.

Ddan  

Ddan
Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 10:58 pm

God, I am having a bad day. I think you are right.

Just looked at a few records and see you are probably talking about the 0x82794711 string? Is that the same as on your system? I don't have an explanation for that.

Ddan  

Ddan
Member
 
 
  

Re: mft2csv - NTFS systemfile extracter and $MFT decoder

Post Posted: Sat Feb 11, 2012 11:36 pm

Yes it is the god damn 82794711 I am talking about Wink (quite anoying..)
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 

Page 6 of 10
Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next