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 data carving utility and asked it to pull out all jpg files from the disk image. Since that would have been too easy, I reminded the readers that we were dealing with a disk image that had been altered by the suspect to make data recovery more difficult, though only slightly so. I asked you to go back and review the previous entries and to see if you could find another way to find this file other than data layer carving.
Lee Whitfield beat others to the answer by noticing fsstat's ouput from a previous post showed a cluster chain of exactly 31 clusters. In fact, I said in my hints that the answer was in previous posts at least twice. Here it is in an image that appeared in a previous post:
.jpg)
So we've got this FAT cluster chain that happens to be exactly the right size for the file we're trying to recover. How do we recover the file and see if it's what we're after? There are several ways, but let's stick with our Sleuthkit tools and use blkcat to recover the file:
You can see I ran the file command against the recovered file and sure enough, it's a jpg. I'll spare you the screen shot of the file opened in an image viewer, but suffice to say, it really is an image file.
A couple questions come to mind. First, what if the file hadn't been contiguous? Well, then we may have recovered a partial jpg and still been able to open it in an image viewer to see parts of it. Experienced investigators have probably seen such images before. Second, how do we know for sure this is the file we were trying to recover? As my daughter used to say when she was younger, we can't know. It may be pure coincidence that this file is an image file and just happens to occupy the right number of clusters on the disk as the file that we're after. If this were a real case, that's something you would explain in your report.
For the sake of this series, we're going to say that this is indeed our file. The point of this series is to repair the disk image, undoing all the changes that our suspect made and restoring it back to normal. In order to do that we need to change what so that it points to the correct starting cluster?
If you said "the FAT Directory Entry", congratulations, you're understanding better than most people. If you didn't know that was the answer, congratulations you probably have more of a social life than those of us who knew the answer. Remember, the FAT Directory Entry for a file contains the starting cluster for the file. The rest of the clusters that make up the file are pointed to by the FAT cluster chain in the File Allocation Table.
So how do we fix the FAT Directory Entry? With our hex editor of course. Recall from way back that we used the output of fsstat to determine that the FAT Directory Entry for the root directory is at byte offset 196608.
Here's a look at the FAT Directory Entry for our file in the hex editor:
I won't go over the entire data structure for the directory entry, we covered some of it already, so go back and read the entry on repairing the FAT Directory Entry for more details and if you're into this stuff and want way more details, I recommend Brian Carrier's book, File System Forensic Analysis.
The bytes we're concerned with are in offset 90 of the directory entry and they are A4 01, which when converted to decimal (remember to reverse the byte order to convert from little to big endian) is 420. What? 420? But istat said the starting sector was 834! What gives? Remember there are a bunch of reserved sectors on our disk that are used for other things than data storage, like the boot sector, the File Allocation Table and the backup allocation table, etc. You may recall that the first cluster in a FAT file system is at cluster 2 and we already saw that cluster 2 was in sector 416 so we're dealing with a difference of 414 between cluster number and sector. So, do the math, cluster 420 is sector 834.
I digress. We need to fix the directory entry to point to the right starting cluster, which was, according to the image above, sector 456. Again, do the math, sector 456 == cluster 42. Convert 42 to hex and we get 2A. So we need to put 2A in the starting cluster entry for our directory entry. But it's a 16-bit value so it's really 00 2A. Can we just plug 00 2A in place of the A4 01? Of course not! We've got to convert from big endian to little endian, so we put 2A 00 in instead and save the usbkey.img file, unmount it and mount it and here we go:
istat now shows the right cluster chain, we can copy the file out of the mount point and the "file"command shows that we copied out a jpg. So, we've successfully repaired the disk image with regard to the first and second files, only one left, which we'll start to tackle next week.
Now then, the moment at least a few of you have been waiting for, the Syngress book giveaway question. If our file really had been at sector 834 in the disk image and had been 31 sectors in length, what would the byte offset have been in the disk image for the cluster chain and what would the values have been for the cluster chain? Answer the question correctly in the comments and you'll win a copy of Malware Forensics: Investigating and Analyzing Malicious Code written by Cameron H. Malin, Eoghan Casey, BS, MA and James M. Aquilina. Again, your answer should include the byte offset where the cluster chain begins and the 16-bit values as they would appear in a hex editor for each of the 31 cluster entries in the FAT.
If no one posts the correct answer before next Tuesday, I'll post the correct answer and we'll give away the book another post. I'll likely drop some hints if needed so it probably won't come to that.
Good luck and thanks for playing.
Update: 20090728 13:07 UTC:
Assume the file is contiguous.
Update: 20090728 16:25 UTC:
There are two copies of the FAT. I'm only making modifications to the first copy of the FAT in this series. Your answer should reflect that as well. Several folks have contacted me out-of-band. You're on the right track, keep trying.
Update: 20090728 16:44 UTC:
It's easier to test your work if you have a copy of the usbkey.img, so I've made one available here. This is the exact image that all the posts in this series have used, so if you want to play along at home, this should help. The md5sum is e2cb099b105fa25af1606d0c7ccc7bbe.
Update: 20090728 18:49 UTC:
Maybe a chart will be of some assistance:
Offset Sector Cluster ----------------------
Update: 20090729 14:53 UTC:
Offset Sector Cluster ----------------------- 2048 414 --- 2050 415 --- 2052 416 002 ...
Does this help?
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.
.png "Finding_Evil_WMI_Event_Consumers_with_Disk_Forensics_-Blog_(1).png")
.png "Blog_teaser_images_(19).png")
