Windows 8, GPT, UEFI, and Virtualization

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):

Legacy Boot

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:

VM Folder-1

The file of note is Win8.vmx.  For the best explanation of VMware system and config files, please visit Ulli Hankeln’s site at  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!

Win 8 Boot

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,  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.



  1. richard orero says:

    Hi, thank you for sharing all this knowledge over the years. I’ve been trying to boot up an image with an EFI partition for some time now. I’ve followed your instructions on the same but when I try to boot up the VM it doesn’t go past the boot menu page. I get the error “Attempting to startup from: efi vmware virtual scsi hard drive 0.0 – unsuccessful” if I select continue. Selecting “EFI VMware Virtual SCSI Hard drive (0,0)” from the Boot Manager option also doesn’t achieve anything.

    • jimmyweg says:

      Thanks, Richard. First, make sure that the efi option is in your vmx file. It’s also possible that the system was set to boot with a regular BIOS, so you can try to remove the efi from the vmx by replacing it with “bios.” Are you working from a dd image?

    • jimmyweg says:

      Okay, so it’s your SEAT that won’t boot? I take it that it boots without the added disk. I’m thinking that the configuration of your added virtual disk is off. In your screenshot #6, there is no size next to the added disk. What OS is on your new VM (image file)? I’d double check my vmdk file or try building a new one from scratch to be sure you follow the correct steps.

      • That’s right. The SEAT workstation boots fine without the added disk. The VM image is Windows 8.1.

        • jimmyweg says:

          That tells me that your virtual disk is the issue. See whether your VM even starts with that disk, without any edits that you hope to make when adding it to your SEAT. What type of image is your base? Use dd.

          • Shelby Mertins says:

            The suspect image is Windows 8.1. I attempted to boot this image and I got a message advising File:\Windows\system32\winload.efi is missing or corrupt.

          • jimmyweg says:

            If your vmx is correctly built, and you added the “efi” line I believe, it seems that it’s a fault of the underlying OS. If you Google that error, you’ll find several suggestions for fixes.

  2. When I try to boot the SEAT workstation with snapshot added, the Windows splash screen appear and then the screen goes to black and nothing else happens. I’m using Workstation 10 on a Windows 8.1 host.

    • jimmyweg says:

      That’s really not much information to learn what’s going on. Perhaps go back and start fresh. It’s easy enough to build a new SEAT, too.

  3. Justin Lazenby says:

    I’m trying to create a VM based on the E01 image of a Windows 8 machine. The physical disk was 750 GB and had 5 partitions (a couple of which have EFI parent folders in the folder structure). I created the VM, took a snapshot, but when I look to alter the SYSTEM registry hive, there is no LSI_SCSI key. I have LSI_SAS, LSI_SAS2, LSI_SAS3, LSI_SSS, and LSM. I searched for “LSI_SCSI” and found nothing pertinent. Any ideas?

    Also (separate topic), after I created my snapshot, I attempted to add it to a simple Windows 7 (x64) VM I’d created a while ago, but I’m getting the error, “The existing disk file is for a physical disk. Please select ‘Use a Physical Disk’ to reuse an existing physical disk.” I’ve double-checked that I’m adding the snapshot and not the original VMDK. Any further ideas? Thank you in advance.

    (I’m running VMWare 10 on a Windows 7 x64 box).

    • jimmyweg says:

      1. When you create the VM, choose the SAS option, and set LSI_SAS to 0x01. If that fails, you can try to set each SAS to 0x01, or try one at a time.

      2. You can’t add a mounted image as a virtual disk because it is a physical disk. The vmdk references the physical disk. You should be able to add the physical disk to your Win 7 VM. I would mount the image first with FTKI as “writable.”

      • Justin Lazenby says:

        The SAS option worked great. Windows 8 still doesn’t fully boot. It loops once and then enters Repair Mode. Not sure what’s wrong.

        The reason I was trying to add the snapshot to my Windows 7 VM was to follow along with the instructions above where it shows adding the virtual disk from its snapshot to the SEAT workstation. I’m pretty green with virtualization, so I know I’m doing something wrong. Your website has been a world of help, so far though. Thanks for the good work!

        • Justin Lazenby says:

          The SAS option worked great. Windows 8 still doesn’t fully boot. It loops once and then enters Repair Mode. Not sure what’s wrong.

          The reason I was trying to add the snapshot to my Windows 7 VM was to follow along with the instructions above where it shows adding the virtual disk from its snapshot to the SEAT workstation. I’m pretty green with virtualization, so I know I’m doing something wrong. Your website has been a world of help, so far though. Thanks for the good work!

          • jimmyweg says:

            Thanks, John, I’m glad that you made some progress. Did you add the “efi” parameter to your vmx? Regarding the Win 7 VM, I’d have to back and double check, but adding a snapshot from one VM to another typically means adding a virtual disk, as opposed to physical, even if the physical has been snapshotted. Let me know how you come along with your Win 8 VM.

  4. ijee says:

    Plzzz sir ..tell me does it work on windows 7….

  5. David Collett says:

    UEFI just causes more troubles, I think. Just a few days ago I forgot the admin password on a Windows 8 laptop. I have tried many bootdisks that I ever used, but none of them work! Eventually I got to find the PCUnlocker Live CD and it is the unique boot CD that can boot in UEFI mode.

    • jimmyweg says:

      It shouldn’t be that much trouble. As I mentioned, your boot disks must be UEFI compatible. KonBoot has such a setup, but remember, you could have an account that uses an MS account for logon. If so, you must have password, as blank won’t work. many password tools can blank a password, but not change the password. I don’t know whether you had an image file, but you can map the drive/image to another VM, or perhaps the host, and strip the password with NTpwedit or Reset Windows password, The latter can change or remove a password.

      • David Collett says:

        I’ve already purchased the enterprise edition of PCUnlocker from and it can also handle MS account password. After burn the image to CD, it can boot under UEFI. But to make a UEFI compatible USB drive, I have to use the burning programs ISO2Disc or Rufus but to choose the GPT partition. Passcape seems to support UEFI as well, I’ll give it a try. Thank you for your recommendation!

  6. Jeremy Shavin says:

    Hey Jimmy,

    Any solutions to booting Windows 8 where the only user account active is a Microsoft account and not a local account? As best I can tell, the credentials for the Microsoft account are not in the SAM. Let me know what I’m missing?

    • jimmyweg says:

      Still working on it. I do know that creating the account creates a new key in Security. As we discussed, it’s kind of like a domain logon.

  7. kate green says:

    Just for dd images?

  8. kate green says:

    My MBR disk couldn’t launch in VMware, INACCESIBLE_BOOT_DEVICE, would you give me some advices

    • jimmyweg says:

      Kate, that’s really not enough information on which to suggest a solution. An MBR disk basically is the standard model that all of my posts discuss. What OS? Image? Mounted image? Windows message? VMware message? As a wild guess, make sure that you have taken a snapshot to ensure you can access the image/disk.

      • kate green says:

        Thanks jimmy,i have already solved the INACCESIBLE_BOOT_DEVICE problems.I didn’t take the snapshot.

  9. Thanks Jimmy – appreciate your kind words.

Leave a Reply

Your email address will not be published. Required fields are marked *