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.

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

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:

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:

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:

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: 07/21/2009 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 TrustedSignal.com.