The Sleuth Kit can be used to investigate disks and disk images but the images don’t actually have to be copied from a real, physical disk. You can analyze a virtual image that you have created just as easily. The Sleuth Kit includes a number of very useful command line utilities that can be run on Windows, Linux and Mac OS X systems. For our purposes, this is being done on a Mac OS X system where the program was built using the Xcode Command Line Utilities that need to be installed before you can build The Sleuth Kit. First, let’s take a look at an image that was created on a Windows system using diskpart to create a virtual disk image and then format it. Before we do anything, we need to take a look at the partition table in the image to see where the partitions are. Without that information, we can’t go much further.
You can see from the screen capture above that we have used the mmls utility from The Sleuth Kit to get the partition table. mmls tells us that this is a DOS partition table. We aren’t restricted to the type of partition table that’s on the disk, though. Let’s take a look at another virtual disk image that was created using the Mac OS X Disk Utility program. Using mmls on that, we can see a GUID partition table.
In either case, you need to locate the partition that you want to investigate. In order to get file system statistics, we can use fsstat but we need to point fsstat at the actual partition using -o to indicate the offset within the image. In our case, we are looking at the fifth slot from mmls, which has a starting offset of 40 so that’s what we tell fsstat.
From this, we can see that it’s an HFS+ file system that was last mounted by Mac OS X and it was journaled, meaning that the operating system was keeping track of changes to the filesystem in case anything bad happened so the changes could be redone to reconstruct a clean copy of the the data, including the metadata indicating where all of the files were located. While this is all very interesting, what we probably want to get at is the actual files within the image. For that, we can use fls. This will give us a file listing of the partition. Let’s go back to the Windows image from earlier, since it had a different partition type, file system and offset. Looking at the mmls output above, the third slot is the only one that actually carries a filesystem, so that’s the one we will use. Again, we need to provide the offset to get to the actual filesystem and in this case, the offset is 128.
Once we have the list of files that were stored in the file table, which in this case is the Master File Table (MFT) from the NT File System (NTFS), we can do a bit more digging into files if we chose to. What you see here are the entries within the file table only and with the MFT, there is a lot more information to be gathered. First, we need to know where to look. Find the entry for Diskpart1.png above. We can see that this is a regular file. There are two r’s there indicating that the filename and the metadata for the file agree. These would normally be identical, though if a file were deleted you may see a difference between them. Keep in mind that if a file has been deleted, it still remains on the disk — both the data and, in some cases, the metadata within the filesystem. There is then a chain of three numbers. The first indicates which entry in the file table we want to look at. The 128-1 indicates that this is an NTFS entry and we can ignore that. Where we want to look next is the entry in the MFT and we can get to that using istat.
The istat utility extracts and decodes all of the information from the MFT entry for that file. You can see the filename and then the other attributes associated with it, including the $DATA attribute at the bottom. This attribute includes a list of blocks where we should be looking for the file data. The metadata (filename, permissions, access dates and times, etc) is kept entirely separate in most cases from the actual data that’s contained in the file. If all you did was to gather the contents of the file, you wouldn’t have the filename. If all you did was look at the metadata, you wouldn’t have any idea what was in the file. The two are separate but both necessary. Our starting point to gather the data for the file is in block 8346. We can use blkcat to extract the data from that block. According to fsstat for this virtual disk, we have a cluster/block size of 4096 bytes. blkcat will take care of that for us and only grab a single cluster.
Just as with the other tools, you have to tell blkcat where the actual partition starts by providing an offset within the file. This tells blkcat where the filesystem itself is, meaning the BIOS Parameter Block from which it can locate the file table. When you look at the output here, which has been piped into xxd to do the ASCII decoding for us, you can see that this is a PNG file. We knew that from the filename but filenames can lie. You are not required to use .png as a file extension for a PNG file. Windows systems maintain a list of file associations so they know what programs to launch when you want to just open the file from the Windows Explorer. That’s simply a convenience. As a result, it’s always good to verify that what you have in terms of data is what the filename and file extension tell you that you have.
One thing we didn’t look at here is the case where you may have deleted files. Typically, if a file is deleted, you would see * between the r/r and the file table entry. If you see that, it doesn’t mean the data is gone. It just means that the file has been flagged as deleted and so the entries can be recycled at some point.
No comments:
Post a Comment