Another Tuesday, another FAT post. If you're just joining us, you can find the whole series of posts here.
Over the last month or two, we've been working with a FAT image that has been modified by the suspect in a case we're working. We have slowly been undoing the changes made by the suspect, one file at a time. We have one file left to make right so let's see what's going on with our third and final file. Recall the output from fls from previous posts:
.png)
We've already recovered the first two files and adjusted the cluster chains in the File Allocation Tables or starting cluster values in the FAT Directory Entry. Our final file to recover is "Scheduled Visits.exe".
Let's get to it. As with previous files, we'll start with the istat command:
We give istat the name of the image file and the directory entry, 11 in this case, that we got from the output of the fls command. istat shows us a bunch of information about the file and looking over it all there's nothing that jumps out at us like the last file we recovered. You may remember that with that file we had an incorrect starting cluster and istat's output only showed a single allocated cluster as a result.
Our metadata looks like it lines up, let's copy it out of the mount point and run file against it and see what we get:
Interesting, our exe file is a zip archive. Could it be a self-extracting archive? Let's try using unzip to extract it:
Unzipping the file fails and based on the error message, it appears that the unzip command doesn't like the way the file ends. In the real world, we could be dealing with a corrupt zip file and a great way to figure that out would be to create a few sample zip files and examine them with a hex editor to see if they have a common footer and then see if our file is missing the same footer. I'll leave this as an exercise for the reader. In this case we're dealing with a file system that's been modified by our suspect and this is an exercise to teach us about FAT file systems and how they work.
Given that, let's get to our challenge question and give away a copy of Mac OS X, iPod, and iPhone Forensic Analysis DVD Toolkit by Ryan R. Kubasiak, Sean Morrissey and Jesse Varsalone, courtesy of Syngress. Our zip file has come to a premature end, but istat shows the file size is 1000 bytes and that there are two clusters allocated to it, which is more than enough. If you look back at screen shots from previous posts or if you have the a copy of the usbkey.img file and use the right tools to examine it, you'll see that something's not right about what istat is telling us. For the book, what's wrong, in which file system data structure do we fix it and how exactly? The first correct answer posted in the comments, wins the book. As in previous weeks, I'll update with some hints as time goes on, no more than one per day based on the feedback I've received previously from those who have been so close, but didn't have enough time. If you want to contact me outside the blog, there are a number of ways to do so (you figure it out). If no one posts the correct answer before 12:20 UTC next Tuesday, the book goes back in the giveaway pile.
Good luck.
