Well, it’s here! Moreover, if you’ve encountered one, you may think that GPT stands for “giant pain in the tush” It can be, especially if you don’t know a little about how these disks work in the newer machines. I mentioned GPT in past blogs, here and here. I won’t go into much detail about it, but I will present a few particulars so we can see why this topic is relevant to virtualizing Win 8 systems. GPT (really) stands for GUID Partition Table and replaces the Master Boot Record (MBR) that we’re accustomed to seeing. In Windows, GPT allows for 128 partitions, whereas MBR, in simple terms, limits us to 26 (one for each letter of the alphabet). As you saw from my earlier posts, GPT also supports disks >2TB, whereas MBR does not.
Next, we have UEFI (Unified Extensible Firmware Interface), which is tied to GPT. UEFI is the replacement for the BIOS and is required to create a bootable, GPT disk. Windows 8 includes a few features that go hand in hand with GPT/UEFI. One is the Secure Boot/Trusted Boot process, which is designed, in part, to protect the system from bootloader bugs and can prevent a system from booting or require some form of remediation, if any threats are discovered. The process also will recognize infections of critical system files and automatically boot into a repair mode, if it detects infections, and restore previous copies of the system files. Secure Boot is based upon UEFI, and many new systems will ship with UEFI systems and Secure Boot active. It’s very important to note that you can’t boot such a machine to a non-UEFI system disk, unless you set the UEFI boot option to compatibly mode, a/k/a CSM (compatibility support module), in the UEFI setup (analogous to BIOS setup).
Here’s a screenshot of the UEFI setup on an HP system.
Above, you can see some of the options that I described. This system happens to default to CSM if a UEFI/GPT disk is replaced by a MBR disk. Here’s what the Legacy Support option presents (Disabled/Enabled):
Should you disable this option, you could not boot a EUFI/GPT disk. If you seek to disable Legacy Support, a warning to that effect will present. This system will default over to CSM if it finds an MBR disk. There may be any number of variations among system manufacturers.
Many of you know that, through Windows Disk Management, Diskpart, and other tools, we can change the partitioning of a disk to and from GPT/MBR. However, we can’t do that with conventional tools if the disk contains partitions.
As you can see, the option to convert my GPT disk to MBR is unavailable. If I right click on the partition, gpt-formatted (J:), I would have the option to Delete Volume… Thereafter, I could create either a GPT or MBR disk.
There is some debate over whether VMware 9.x can boot a GPT disk without at least a tweak to the configuration (VMX) file. From tests, I found that a simple edit could overcome a failure to boot a GPT image. Note that the same principles apply to booting mounted images, which are the practice with E01 and other non-raw image files. However, we will have to adjust how we work with E01/mounted images (stuff for a later post). To complicate things, it seems that VMware does not support mounting VMDK files that represent GPT disks.
By now, you should be familiar with creating a VM from a dd image by preparing a VMDK descriptor file. That process remains unchanged. Once you accomplish that task, you will have a number of VMware system files in your VM folder:
The file of note is Win8.vmx. For the best explanation of VMware system and config files, please visit Ulli Hankeln’s site at http://sanbarrow.com/. So, we’re at the point where we have a VM. Next, we take a snapshot. We can try to boot out Win 8 VM and see what happens. If you receive a no operating system found message, I suggest that GPT/UEFI may be the culprit. Of course, you probably visited the system settings earlier to document the setup. There, you could have learned what might be in store concerning VMs.
Open your VMX file in a text editor and add the parameter firmware = “efi” to the file. Below is a screenshot of a portion of my VMX file.
Now, your Win 8 image should boot, if at least the registry is set to boot to the LSI SCSI drive that’s in our standard VMDK file. You should remember that, concerning Vista and Win 7 images, we took a snapshot and mounted our virtual disk with VMware as writable. Then, we edited the registry so that the LSI SCSI service started at boot (0x00):
You also should recall that we stripped any essential passwords while our virtual disk was mounted. The problem we have now is that VMware doesn’t support mounting GPT virtual disks. You can go through the motions, and VMware will appear to mount the disk. However, when you try to access it, you’ll see what follows.
Now, you may just get lucky and find that your target system already is set to load the LSI SCSI driver at boot and that the user had no password. If that’s the case, you’re luckier than I am, and you’re good to go. For the time being, we do have a workaround, which relies on our trusty SEAT Workstation. While we can’t mount the virtual disk to our host system from VMware, we can add the virtual disk, from its snapshot, to our SEAT Workstation. Watch.
When we use VMware to mount a virtual disk, VMware defaults to the most recent snapshot of the virtual disk. If we mount a VMware disk otherwise, we have to navigate to the latest snapshot manually. Below, we can see that VMware is about to mount a snapshot file, which is apparent from the 000002 identifier, which was appended to the name of our original vmdk file.
You may wonder why we elected to add the virtual disk in persistent mode. Well, we want to edit the registry and strip passwords, just as we did when mounting a virtual disk as read-write with VMware. Our Win 8 VM has been snapshotted, so our original image, which also is write-protected, remains unchanged. Next, we’ll boot our SEAT Workstation.
Above, we see that our Win 8 virtual disk has been added to our Seat Workstation as Volume E:\. Now, we’ll edit the registry of our virtual disk.
I’ve become accustomed to naming added hives in a manner that makes them stand out, just so I don’t edit my own system’s registry by mistake! Note that you may find that your target’s System hive already may have the desired setting. You can check that before you get this far, simply by examining the registry with your forensic tools. The same thing applies for passwords.
NTPWedit, being a Windows too, can run within our SEAT Workstation. Simply copy the executable to your SEAT Workstation. You can try to boot your Win 8 VM with one of the password editing discs, though I have not tried that approach. Again, the process of adding your Win 8 virtual disk to your SEAT Workstation may be unnecessary, if you find that you target system already includes the correct registry setting and included no passwords. Nevertheless, you had a refresher on the process, which is, in substance, the same with respect to Win Vista/7. Now, we shut down our SEAT Workstation and remove the Win 8 virtual disk.
Last, let’s see whether our Win 8 VM boots. It does!
There a few more things related to GPT, Win 8, etc., and I’ll be back with more as I get caught up and as I learn more about overcoming some of the hurdles that I identified above. There also are a few things to discuss about examining shadow volumes in Win 8 systems. They still exist in Win 8, though the Previous Versions feature is gone. You may want to start thinking about building a SEAT Workstation on a Win 8 platform!
As time goes by, we’re seeing more tools that can make a shadow volume exam more efficient and may make my method “obsolete.” Much depends on how you work and your resources. I like my approach because it allows me to incorporate my findings into X-Ways Forensics almost seamlessly. Shadow volumes aside, booting an image of a target system is, IMHO, an essential part of almost every exam.
I want to make mention of one new tool that’s worth a look: Reconnoitre, which Paul Sanderson produced, http://sandersonforensics.com/forum/content.php?168-Reconnoitre. Paul let me do a little beta testing, and I was impressed with the power of his latest creation. Many of you are familiar with Paul’s tools, so you know that they perform as represented and meet the demands of the forensic community. That’s it for now.