I’ve had a few requests to explain how we can create a Windows VM from an image of a logical volume, as opposed to an image of a physical disk. While I don’t think that it’ done frequently, there are instances when an examiner must image the Windows partition on a running system. I haven’t done a lot of testing here, so, as the weight loss ads say, your results may differ. In a sense, this approach is a beta; it’s a starting point with room for improvement. I’m working with a single dd image, as E01 images will present some obstacles when it comes to editing. I’m not sure how much interest folks have in this process, so I may or may not go into E01s or expand this topic, absent audience encouragement.
I realize that some folks image logically because they found Bitlocker, PGP, or another full disk encryption scheme in place. Once imaged logically, they will have access to the encrypted files, but they won’t have a bootable image. I haven’t studied encryption mechanisms and their role in the procedures that I outline in this post, but assume for the time being that we’re not working with full disk encryption.
VMware will not boot a logical image or volume. It won’t create, mount, or run a VM from a logical partition. We need the key components that a physical disk includes, but which a partition does not. The first step is to reconstruct a physical disk when we have only a logical partition. Thereafter, we have to make it bootable and load an operating system. What I’m not going to do is provide a great deal of instruction on the system boot process and how Windows loads. I’m going to demonstrate with a Windows 7×64 image, as that’s what I used to get to this point. As noted, I haven’t done a great deal of testing, so issues may arise for which I may not have an answer. I’ll use X-Ways Forensics (actually WinHex) because it offers some extraordinarily useful features that will get us to the point where we can boot our system. I’ll also plug Brett Shavers and Eric Zimmerman’s upcoming book, The X-Ways Forensics Practitioner’s Guide, for which I served as tech editor (Brett and Eric did the heavy lifting). It will be released soon at http://store.elsevier.com/X-Ways-Forensics-Practitioner%E2%80%99s-Guide/Brett-Shavers/isbn-9780124116054/.
X-Ways Forensics (XWF) offers many approaches to accomplish a task. For those who don’t know, the X in XWF is figurative and represents a number. Why? Because for many tasks, any number (“X”) of ways (X-Ways) exist to accomplish the task. My method is not necessarily the best, and I wouldn’t be surprised if there’s a better way, even with XWF.
As noted, you’ll see that my demonstration uses WinHex (with the Forensic license), which really is much more than a hex editor and allows us to edit objects more liberally. WinHex is available with XWF and basically has the same features, but on a platform that allows an overall writable environment. Just replacing the name xwforensics with winhex on a copy of the xwforensics.exe executable leaves you with a copy of WinHex. Before you start worrying about the word “changes,” stop. Our imaged partition will remain unscathed, and its hash will verify when we’re done. The differences between XWF and WinHex are found here.
I consider the procedure to comprise two, distinct processes. The first is the boot process, and the second is the Windows loading process. Windows won’t load unless the system boots and then finds Windows, i.e., the operating system. So, what’s missing when we image the Windows volume (Volume C for our purpose) on many current installations? You’re correct: the Master Boot Record (MBR) and Partition Table. I’ll just refer to them jointly as the MBR.
Additionally, you also may be missing the backup boot sector and volume slack that follows the end of the logical volume. Volume slack consists of a number of sectors that do not equate to a whole cluster. The backup boot sector is 512 bytes. By looking at a number of drives, I’ve found that the surplus sectors typically number seven. So, we have seven surplus sectors plus the boot sector, for a total of eight (assuming eight-sector clusters). These sectors really are not part of the logical partition and may not be included with partition image, depending on how it was acquired. Nevertheless, we must consider them later when we calculate geometry. In the field, you may want to note the logical and physical geometry of your target before you leave.
I’m going to simplify, but the BIOS/UEFI checks the hardware (POST) and reads the MBR. Think of the MBR as a program that reads the partition table. It then finds the “active” partition, from which the computer boots and which contains the boot files. The boot sector code at the start of the active partition runs and loads the boot loader, bootmgr, which accesses the Boot Configuration Data (BCD) store, which basically is a registry hive-formatted file. Bootmgr then turns over the process to the Windows loader, winload.exe. I’ll stop here. Actually, we don’t have to worry about what happens next, if all goes well. We’re not going to worry about GUID partition tables, either.
Wait a minute. Before I forget, I’m sure that you’ve noticed that many modern systems actually have at least two partitions on the disk. That little 100MB partition generally contains the files needed for the boot process to load Windows. Equally important is the fact that this partition is the active partition. While it is the active partition, it is not the system partition that contains our Windows installation. Nevertheless, the boot files on this small partition contain the information that enables Windows to load from the system partition. Should you find yourself in a position of having to image the system partition of a running machine, I urge you to note the disk configuration, nonetheless. You need to know what you left behind, so you can move ahead more efficiently should you wish to virtualize the system.
I’ll set out our plan now, and then explain the steps. This process is not a five-minutes-to-a-VM as we saw when building VMs from physical images. One way or another, we have to move or copy a lot of data that equate roughly to the size of you imaged partition. The approach that I’m going to take first assumes that your image came from a system with the 100MB System Reserved partition. We’re going to prepend an MBR and a System Reserved Partition (SRP) to our logical volume (image file). (We could just prepend an MBR, and maybe I’ll go into that method in another post.) If your image came from a system without an SRP, you’ll have to wait for another blog post, as the following steps don’t relate to your predicament.
First, we need an MBR+SRP, which can come from almost any Win 7 source (stick with 32 or 64 depending on your target system). I suggest that you create a new Win 7×64 VM, as it’s quick and clean. Once created, I’ll open the virtual disk in WinHex. Watch the video, and I’ll explain the steps afterward.
When we left the video, we had opened our new, Win 7×64 system disk (VMware virtual disk) and viewed a template. XWF/WinHex templates are very handy files that interpret various data structures, like MBRs/Partition Tables. It is a definable dialog box that allows us to edit these data structures much more easily than we can with raw hex editing. By changing the values in the editable (white) boxes, we can modify the MBR to conform with a new system or make repairs. If you want to use a template to edit a disk or interpreted image, you must use WinHex as opposed to XWF.
I’m going to present a screenshot of the template below, as it will help us to understand where we go from here. Remember, I’m using WinHex, so I can edit a disk (interpreted image file).
We see that the system contains two partitions: the SRP and the operating system (Windows) partition. The SRP (Partition Table Entry #1) begins at Sector 2048, so physical Sectors 0-2047 (the MBR) precede the SRP. We also can see that the SRP contains 204,800 sectors, or 100MB (104,857,600 bytes). By doing a little math, we find that the SRP ends with Sector 206,847. Sectors 0-2047 contain the MBR, and the SRP contains 204,800 sectors: 2048+204800=206,848 sectors (0-206,847) or 105,906,176 bytes. Partition 2 begins at Sector 206,848. (We’re going to stick with 512-byte sectors.) Note, too, that the SRP is the active partition, as evidenced by the 0×80 value at Offset 446 of the MBR. You can find it in the above screenshot. I encourage you to use the tool of your choice and navigate as I described, as doing so will make things clearer and help you to explain the process should the need arise.
Let’s move on and open the image of our Windows partition image file. Note that I open it as a regular file and not as an image.
Also note that our image is about 230GB. My partition existed on a 240GB hard drive. Below, we can see that our Win 7 base system and our partition image file are open side by side (see tabs). While we could tell WinHex to interpret our dd image file as a disk, we won’t do that.
You’ll probably recognize that our file bears a striking similarity to a Windows partition, as that’s what it is. I’ll point out now that we opened our image as writable, so bear that in mind, but don’t be concerned about what follows. Make sure, too, that your target image is not read-only (Windows attribute). In the next video, we begin in WinHex with the focus on the Win 7×64 base disk.
Now, we can interpret our image as a disk.
When we select the option in the above screenshot, WinHex will ask whether we want to save our edits, so be sure to save the file. Put simply, we copied an MBR and an SRP from a base Win 7×64 disk/system to the beginning of a Win 7×64 logical partition. A dd image represents a byte-by-byte file of an object, in the original order. You might have noticed an extra boot sector at the end of your block. That’s a backup boot sector on the SRP, so don’t let it confuse you, which won’t happen if you pay attention to offsets. The reason why we opened our image as a file was that we intended to increase it in size. WinHex can increase the size of a file, but no tool can “stretch” a disk (thank you, Stefan, for reminding me of that). However, all is not well at this point. Remember that a partition table identifies whether a partition is active, the number of sectors that precede the partition, and how many sectors the partition contains. We’re okay on the first point, as the copied SRP remains active. It also is the first partition and contains the same number of sectors as before.
In effect we transformed a logical image to a physical image. Our original image partition is now the second partition on the disk. In my example, my original partition image was about 230GB. However, if we go back up to the template screenshot, we can see that Partition 2 presents as containing 125,620,224 sectors, which equates to a size of about 60GB, which was the size of my base Win7x64 virtual disk. After we interpret our image file as a disk, it appears as below.
We see that the size of our partition is incorrect, and we also see that WinHex calculated 164GB of unpartitioned space. If we add those numbers, it equates roughly to the actual size of our imaged partition (230GB). We’ll take care of that issue next, by using our handy template to edit the MBR. First, I must remind you about the boot sector backup that I noted earlier. We must account for that to keep our disk geometry in line and have a recognizable file system.
In the next screenshot, I return to our original partition image and present WinHex’s handy Technical Details Report, available under the Specialist menu.
Above, we see that out partition contains 468,652,024 sectors. However, we also must account for the additional eight sectors that contain the volume slack and boot sector backup as we complete our physical disk construction. So, 468,652,024 + 8=468,652,032. Now, we go back to our disk-in-progress and open the MBR template. If we study the template and recall our calculations, we see that everything is correct, with the exception of the number of sectors in Partition 2 (our image). I’m not going into MBR/template parameters that may or may not be editable, as we need not consider them for this project.
In the video, I edited the number of sectors in Partition 2, hit Enter, and changed the MBR. I used 468,652,032 sectors to allow for the new logical volume size plus the volume slack and boot sector backup. Then, when I refine my volume with a new snapshot, things look as they should. From the Specialist menu, you can select Refine Volume Snapshot (or just hit F10).
When the snapshot box opens, elect to take a new snapshot.
After we take a new snapshot, your disk should look like this:
Note the difference between this screenshot and the similar one that I took before we edited the MBR. After I finish, I go back and make my image read-only. Now, let’s see whether it works.
The procedure here is the same as that described in my first post. Create a vmdk descriptor file with the proper geometry, and then use it to create a new VM. Thereafter, take a snapshot, mount the snapshot as writable, edit the registry and reset the LSI_SCSI value data to 0×00, strip the password if applicable, and start your VM. If your disk will not mount, or Windows claims that it is not formatted, the cause likely is incorrect geometry. Fix the problem before going forward. You may see the following screen when you boot, so let Windows start normally.
This is what we hope to see:
Before I sign off, I better bring up a point about the hash value of our original image. I said that we would not alter image, and we did not. However, depending on how you access your image to verify this, you may end up hashing something different from the original. This has to do with volume slack and the boot sector backup. That data was not in our original image, but if you access the original image through the newly created disk image, you may end up including volume slack and the boot sector backup in your hash calculation. After you have your VM in working order by following the proper protocols, and you want to verify the image, mount the image as a logical volume, as seen below in FTK Imager:
Then, open the mounted volume (Drive M in my example) in XWF, and hash the volume.
I mounted Volume M and accessed the Tools\Compute Hash menu to hash the mounted volume.
Granted, we don’t have a stand-alone volume image at this point; however, we have the original volume within an image of a physical disk. Nothing has changed from the standpoint of any evidence that you recover from the logical partition. Note that we did not copy the volume slack and backup boot sector to our new physical image, but only allowed for its space in the partition table. Hence, we will not be able to read from those eight sectors. For our purpose, it doesn’t matter.
Again, this process may not work in every case. if you can’t mount your new image, check your steps and verify your offsets. If it mounts, but won’t load Windows, there are some things we can try to resolve that issue. I’ll save those for another post. Good luck!