SANS Digital Forensics and Incident Response Blog: Tag - FAT Directory Entry

FAT File Sizes

If you're just checking this blog for the first time, you should know that this post is one in a series of posts dealing with a FAT file system that has been tweaked in various ways to make recovery of the data more difficult, if only for the casual observer. Forensics folks like yourselves would have no issue recovering the data, but the point of this series is to learn about the FAT file system and how it works.

In last week's FAT Tuesday post we looked at a file in our usb key image (get it here) called "Scheduled Visits.exe". We looked at the metadata for the file using


A big FAT lie part 2

Last week we looked at the next file in our disk image (next file according to the output from fls). We saw that though the file was 15585 bytes, istat reported only a single sector for the file. Based on our cluster/sector size of 512 bytes, the file should have occupied 31 sectors (15585/512=30.439..., round up).

We theorized that we may have a broken or missing FAT cluster chain. Knowing the file should occupy 31 clusters, we used the blkstat command to carve out 31 clusters of data beginning at sector 834. We found only nulls.

At this point, most sane investigators probably would have reached for their favorite

...


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:


Rebuilding FAT cluster chains

For those reading this entry and not familiar with the others in the series, a brief bit of background is in order. This post is the fourth in a series about the FAT file system. We have a disk image taken from a suspect's USB key, but some of the metadata has been modified to make getting at the evidence more difficult, though only slightly. We're attempting to undo the modifications our suspect has made and restore the image to its unaltered state.

I did a little digging over the weekend and discovered a couple links that may be of interest to those playing along at home. First, Mike Murr, of Code-X Technologies and Forensicblog.org, has covered some aspects concerning our image on his blog


FAT Directory Entry repair

This is the third installment in a series of posts about FAT file systems. We're using the usbkey.img file that's given to students of SANS Sec. 508. The image has been altered by the suspect. Our goal is to return it to it's unaltered state.

In the second post, we gathered some information about the files on the image and using a hex editor took a look at the two metadata structures for FAT file systems, the FAT Directory Entry and the