Sunday, November 25, 2012

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.


  1. Ken,

    Thanks for the posting. I had a similar issue a couple of months ago. The IMDisk would have helped immensely. Also, did you try looking at the drive geometry (C/H/S) to determine issues with the partition table?

    Enjoyed the posting. It is very useful for those newer to the DFIR field.


    Ed Hunter

  2. Thanks Ed! I haven't looked at the drive geometry yet. Not really sure how to proceed with that. Still reading up on that. I haven't had to deal with something quite like this before.

  3. Ken;

    Nice informative post !

    SIFT has defiantly become my Swiss Army Knife and is regularly my tool of choice when I need an immediate answer or want to verify a finding from a comercial tool. Thanks for the tip on IMDisk - I use it to mount images to run my IR tools against them but did not know you could enter an offset for the partition.


    Paul A. Henry

  4. Thanks Paul! I use SIFT all the time and really like it. I don't remember where I first heard of IMDisk, but it's another tool I frequently use.


  5. First off, great post, and thanks for sharing. When I've run into a similar issue, I've just removed the data prior to sector offset 63, and accessed the image as a logical volume, being sure to document what I did and why all along the way. It's great to see alternatives, though.

    > Veteran forensics professionals probably already know this
    > stuff.

    I'm glad you posted this anyway. Throughout my time in the DFIR field, this has always been the biggest excuse folks use for NOT sharing. In the 13 or so years I've been involved in DFIR work, I've only encountered this myself once. I'm sure that there are "veterans" out there who have never actually encountered this themselves. There's no one of use who knows everything, and the unwillingness to share by so many really weakens the community as a whole. Thanks for stepping up, Ken.

  6. Thanks Harlan! I enjoy doing posts like this and would like to do more.

  7. "...would like to do more."

    Other than time, what's holding you up?

    This is actually a recurring theme...sharing within the DFIR community. In the time that I've known you, this is one of the times I've seen you post something with enough detail that most analysts should be able to replicate what you did, and from there possibly even expand on it.

    One of the complaints about training courses is the cost, not just of the course itself, but getting there and back, as well. Posts like this offer little bits and pieces of practical knowledge that can be easily's a problem, and here's a tool/process/methodology that I used to solve it.

    To be honest, we do not see enough of this within the community. I see this requested all the time, particularly when it comes to folks asking about thoughts regarding new editions of books, or blog posts...but what is not seen is the requester offering up their own input to the request.

    No one of us is as smart or experienced as all of us together. Working in isolation puts us, as a community, at a great disadvantage, and yet we (as a community) not only accept, we perpetuate it.

    Thanks for stepping out of the shadows and into the ring.

  8. s/steams/streams in the bold mount command.

  9. Thanks for catching that Rob! Seems that no matter how many times I proofread a post, I always miss something.