No Partition Table? No Problem

Warning: Veteran forensics professionals probably already know this stuff. Posting for those newer to the field. All are welcome to read and comment, however.

So you've got a disk or maybe just the image of a disk and your forensic tools say there are no partitions on it. What now? Windows isn't going to mount it, so how do we see if any files are on the disk? Some Windows based forensic tools (X-Ways Forensics) will probably be able to identify any lost partitions on the disk, but you still can't mount it natively. Fortunately, there are still ways to get at the data, if it's there at all. Using skills I learned in SANS Forensics 508, I was successful in doing all I needed to do.

The hard drive I'm working with is from a friend's computer. He asked me to troubleshoot, or perhaps just shoot it as it had suddenly stopped booting up.  On Patch Tuesday, the installed Avast Antivirus flagged some files as rootkits and asked to remove them, which my friend allowed. Avast notified him to reboot in order to finish the disinfection. When rebooting, the computer stops after the POST screen and advises there is no boot device.

Windows Disk Management in the management console showed the entire disk as being unallocated. I made a raw image of the drive and am investigating the cause. As part of that, I wanted to mount the image in order to conduct antivirus scans, since Avast had reported rootkits.

Since my friend's computer was unable to find the operating system when trying to boot, I loaded the image into WinHex and navigated to byte offset 446 to look at the partition table. I found the entire table was gone, right down to the 55AA normally found at the end of the table at offset 510 and 511.

So, is all hope lost? Nope. I knew this to be a fairly new computer with Windows XP as the only operating system. In WinHex, I searched for NTFS to try to find the start of a partition. As expected, I found the formerly active partition at Sector 63.

I opened the SANS Forensics SIFT Workstation (ver. 2.14) in VMware Workstation and connected the disk my image was stored on to it through the Shared Folders option. The SIFT Workstation, for those who don't know, is a ready made forensic work environment in a VMware virtual machine. An .iso file to create a live CD is also available.

Knowing the partition started at Sector 63, I knew it should be easy to mount it in Linux and it was. At the command line, I navigated to the disk where my image was located like this:

cd /home/sansforensics/Desktop/VMware-Shared-Drive/disk

There I found my image, named image.001. Before attempting to mount, I decided to use the mmls tool from the Sleuth Kit to see if it could recognize a partition in the image. Even using the sector offset option, mmls still couldn't find any partition.

So, I decided it was time to attempt to mount the partition I knew was in the image. At the command line, I typed the following:

mount -t ntfs-3g -o loop,ro,show_sys_files,streams_interface=windows,offset=32256 ./image.001 /mnt/windows_mount

A few explanations of that command line are probably in order. For those unfamiliar with the mount command, it may seem odd I specified an offset of 32256 instead of 63. The mount command does not work with sectors. Rather, it works with bytes. Knowing each sector was most likely 512 bytes and that the partition started on sector 63, you must multiply the number of sectors times the bytes per sector: 512 x 63=32256.

Also, show_sys_files allows you to see all the Windows "meta" files.

The streams_interface=windows option allows you to view Alternate Data Streams in Linux using the ntfs-3g driver just as you would in Windows.

The mount location I specified, /mnt/windows_mount is a location already existing in the SIFT Workstation for mounting images. One of the great things about this is the /mnt folders and the /cases folder are all shared via the network and you can access them from your host machine as network locations.

Anyway, the procedure outlined above worked like a charm. The partition on the image mounted immediately and I found the filesystem within that partition was intact. I was able to navigate it in Linux, as well as accessing it through the network from my host Windows machine.

I mapped a drive letter on my host to the /mnt so I could easily access this partition from either the SIFT or run other Windows based tools on it from the host machine. The great thing about this is I was able to run log2timeline-sift in the SIFT environment on my image while scanning the mounted image with antivirus from the host Windows machine, all at the same time.

Now, as I said, there is no way to mount this disk (or image) natively in Windows, at least as far as I know. However, it can be done with other tools. I tried FTK Imager, since it is normally able to mount partitions within image files. However, it was unable to mount this one without the partition table being present. IMDisk, a fantastic free tool, allows you to mount images such as this and specify the byte offset of the partition, just like the Linux mount command. It is a Windows based GUI and is extremely easy to use. I tried it and it successfully mounted the image to an accessible drive letter. There are probably other tools that would work, but I didn't have any others to try.

My investigation into this computer is still ongoing. I will post later what, if anything, I find out. I hope I'm able to determine the cause of this incident and get it fixed. I hope this post made a little sense. I'm always happy to respond to questions, so feel free to comment below.