SANS Digital Forensics and Incident Response Blog

A big FAT lie

In the last post in our quest to restore the tampered FAT file system to its untainted state, we rebuilt the cluster chain in the File Allocation Table so we could copy out the file from the mounted file system. Let's move on to the next file in our image.fls ouput from usbkey.img

Let's see about "cover page.jpg." For starters, let's copy the file out of the mounted file system:

copycoverfail Well, what do you know? Our copy failed. This error message is remarkably similar to the one we saw in a previous post where we repaired the FAT Directory Entry, but still hadn't rebuilt the cluster chain in the FAT. Could it be the case that we have a missing cluster chain for this file? It's a possibility, let's investigate. Using the FAT Directory Entry 8, given to us by fls, we run the istat command and see the following: istat8 Right away we notice at least one odd thing about this file, possibly two. The most obvious thing is that the file size is 15585 bytes, yet we only see a single sector on the disk has been allocated. We already know from running fsstat against the image that our cluster size and sector size are both 512 bytes. Because we round up, our file of 15585 bytes should occupy 31 clusters (also sectors in this case), but we only have one listed. Ok, what next? Well, let's try carving out 31 clusters beginning at sector 834 and see what we get. We can do this using the blkstat (or dd) as follows: blkcat834 Did you catch the output from the command? It was 31 sectors of nulls. Don't believe me? Let's pipe the output to xxd and less: blkcat834xxdless I'll spare you the pages and pages of output, but I think you get the idea. There's no data at this location on the disk. What else could be wrong? Let's review what we know so far:

  • We have an allocated jpg file
  • The file is 15585 bytes or 31 clusters
  • istat reports a single cluster
  • There's no data at the cluster location
  • Remember we're dealing with a disk image that's been altered by our suspect. Think about physical evidence. Say a criminal is trying to hide some piece of physical evidence, might he lie about where that evidence is? What could be going on here and how might we find the true location of this file in the image without resorting to data carving using tools like foremost? Here's a big hint, go back and review the previous posts in this series. The answer is in there, at least twice. Let me repeat the question: How might we find the true location of this file in the image without resorting to data carving (i.e. no foremost like tools)? First person to answer that question in the comments wins a free copy of Harlan Carvey's new book, Windows Forensic Analysis DVD Toolkit, 2nd Edition courtesy of Syngress.

    Update: 20090721 12:05 p.m. UTC
    There's been some conversation about this post on Twitter so I thought I'd provide some additional info here. Mark McKinnon adds "Another hint is that [you] need to look at what tool you are using and understand where that tool is getting its info."

    I haven't talked to Mark yet today, but let's consider his hint. Where does istat get it's information? Two places, some of it comes from the FAT Directory Entry and some comes from the FAT. Recall from previous posts that the former gives us the starting cluster and the latter contains the cluster chain that tells us where the file continues.

    Also, one reader commented that we may need to rebuild the cluster chain as we did with the previous file. When I informed them that we wouldn't need to do that in this case, they quickly replied, "Oh yes, the file is allocated."

    That's enough additional hints for now. Let me just say one more thing, at the risk of it costing me a fortune, I'm going to open up the award to international participants. That's right, I'll ship the book overseas, if I have to. Just don't tell my wife.

    Dave Hull, GCFA Silver #3368, is a technologist focusing on incident response, computer forensics and application security. He can be found on the web at


    Posted July 21, 2009 at 12:38 PM | Permalink | Reply

    Lee Whitfield

    Looking at the items over the last few weeks my answer would have to be that the starting cluster in the directory entry has been changed. Hence the copying of the file is not working.
    Looking at the file size and the FAT entries the file size is 15585 bytes and there is an entry in the FAT that is 456-486 (31) -> EOF (equalling 15872 bytes). This is where the file resides.

    Posted July 21, 2009 at 12:41 PM | Permalink | Reply


    Ding! Ding! We have a winner. For now, readers will just have to trust that the answer is correct. Next Tuesday we'll take Lee's answer and put it to the test by recovering the file that FAT cluster chain points to and verifying that it's the one we're after.
    Good work Lee!

    Posted July 21, 2009 at 12:53 PM | Permalink | Reply

    Robert Miller

    Sooooo Close, dang this thing called work :-)
    Congrats Lee well deserved!