Saturday, June 19, 2010

Give Me $FILE_NAME or Give Me Death

I think we’re long past the point as a community where we should be pushing the vendors of our GUI forensic tools to provide us with the $FILE_NAME time values inside of an NTFS $MFT record.  Every tool parses the $STANDARD_INFORMATION time values, but that should no longer be considered the bare minimum for a GUI forensic tool.  Most tools do not provide the $FILE_NAME time values as part of their standard file system navigation experience.  The concern that has been expressed in the past was that adding this information would be confusing to the user.  While I can certainly understand that it might be confusing to an inexperienced or poorly trained examiner, that’s not a good reason for not presenting the information.  If an examiner doesn’t understand how an $MFT record works, then this confusion is a teachable moment that will hopefully prompt the examiner to learn more about the inner workings of an $MFT record.  The information is out there and it’s easily accessible on the Web, through training courses and books.

Yes, I can parse the data manually or by scripting with the various vendor tools.  However, it’s much more useful to me if I can have these data stamps parsed automatically and presented to me as part of the main user interface experience.

I’m not familiar with all of the forensic tools that are available so I’ll have to rely on other people to let me know what tools might be doing this already. I’ve been using Sleuth Kit more and more these days and it parses everything (istat) because it’s Brian Carrier’s awesome tool.  I heard a long time ago that Pro Discover might present some of this information to the user also, but I’d be curious if someone could verify that for me. Any other tools that are doing this?

What do you think? Am I missing something? Why wouldn’t we want this information presented to us up front in our GUI tools?

Forensic 4cast Awards Voting Has Opened

The nominations have closed for the upcoming Forensic 4cast awards and the voting has started.  SANS announce this week that the awards will be open to everyone so if you are in the DC area and aren’t attending the SANS Forensic and Incident Response Summit, you can still attend the awards.

New Tools

I’ve been made aware of a couple new forensic tools that I’d like to share with everyone. 

The first one is Defraser which is a tool by the Netherlands Forensic Institute.  I learned about this tool when I was taking SEC563 at SANSFIRE recently.  This is a carving tool that will recover full and partial video data.  I have just started it so I can’t yet speak to how well it works yet, but I’m excited about the possibilities.

The second tool is called raw2vdmk.  It looks like it’s an alternative to LiveView.  I use LiveView quite a bit and I’m quite fond of it.  I haven’t tried raw2vdmk, but I would potentially give it a spin if it could do something that LiveView couldn’t do for me.


  1. Any other tools that are doing this?

    MFTRipper from Mark Menz, although there is an issue with the order of the times that hasn't been worked out in a new/updated version. I use David Kovar's script to provide some verification for my own Perl code.

  2. Thanks, Harlan! What I'll do is collect the information that people send me and then make a list (with links to the tools people mention) that I'll put in one of my next blog posts.

    Congratulations on your Forensic 4cast nominations, btw. :)

  3. Looks like Harlan beat me to the two tools I was thinking of! I know a number of other people have built enscripts to be used within encase that will parse the MFT as well.


  4. I work at AccessData and we added this feature in the Forensic Toolkit 3.1 release.

    If the filename timestamps differ from the STANDARD_INFORMATION timestamps then they are parsed and can be seen in the properties window when viewing a file.

    Phillip Hellewell
    Software Engineer, AccessData

  5. FTK 3.1 exposes these values. In the properties pane for a file it lists the $FILE_NAME values for the name values like: "Date Modified (8.3 filename)" - for each of the filenames. It only lists them if they are set and if they differ from the $STANDARD_INFORMATION values, so if you don't see them they are the same. I think this was done because these are 16 extra values to complicate things that are usually the same.

  6. Thanks for the information, Nathan and Phillip. I appreciate you guys taking the time to stop by and let us know how Access Data is innovating in this area.

    I upgraded my FTK to the most recent version after reading your posts and I didn't find any files that showed the $FILE_NAME data, but it was just a very quick test.

    While I can understand that adding this information might add more clutter to the UI, the solution that Access Data is offering, as you guys describe it, is still the tool deciding what the examiner should see.

    I don't want or need that level of hand holding from the tool and I want to be able to see the $FILE_NAME information regardless of whether the tool maker thinks those time stamps are interesting or not.

    I also want to be able to see it in the column view along with the $STANDARD_INFORMATION time stamps so that I can sort by that data.

    How about allowing us to see this $FILE_NAME data no matter what in the properties window and have it be an optional display option for the column view?

    You guys are doing great work with FTK 3. For example, I don't know when you introduced it, but I like the option to have the informational bubble (I forgot what it's called in the UI) appear if I put my cursor over a picture in Gallery view. It's nice to have the name, sizes and created time data at a glance like that.