Workarounds to Workarounds (and some hints & reminders)

Every now and then, I get email from readers who have difficulties, and some areas come up more often.  I also learn a few things as time goes by, and I gain some valuable pointers from colleagues who share my interests.  Therefore, I want to update or amend a few procedures as well as review some of the more basic steps that folks may overlook.

1. Building and booting EUFI/GPT systems and remembering the registry edit 

A little while back, I posted on building VMs from UEFI/GPT systems, found most often in Windows 8.  Since then, I’ve seen more of these outfits arrive in my shop, as the use of Windows 8 and large disk grows.  If you document your target system before an exam, which requires accessing the setup in most cases, you’re sure to recognize that the setup doesn’t resemble the BIOS of old.  There’s a sample screenshot in the above post.  Even if you dive straight away into your exam, you’ll find a clue when you study the partitioning of your target image file:

GPT Disk

X-Ways Forensics users will receive the answer to the clue without having to guess.  The GPT partitioning style with the four partitions, including the MS reserved partition, mean that you have a UEFI system.  The FAT32 partition likely holds your EFI boot data:


The first reminder is that we usually must edit the registry and at least one user’s password to boot into Windows 8.  Since the beginning of my blog, I described how to build your VM by selecting the option for a SCSI disk in VMware.



That option required an edit to the registry to enable the LSI SCSI service to start on boot: LSI SCSI

After mounting our VM, we loaded the target’s System hive into our own registry.  We navigated to the proper control set’s Services key and then to the LSI_SCSI subkey.  There, we edited the Start value’s data to 0x00, as above.

Well, what happens if you find a System hive that looks like this:  SAS

As you can see, there is no LSI_SCSI key.  If you find this to be the case, you have a couple of choices.  You can start over and select the LSI Logic SAS option as in the Virtual Machine Wizard screenshot above that displays the controller types.  Then, edit the registry by setting the first LSI_SAS controller’s Start value data to 0x00.  A quicker alternative is  to edit the mounted registry hive and your VMX file by replacing the highlighted line the next screenshot with the one that follows.  Of course, if you examine the target registry in your forensic tools you can determine the configuration before you even consider building a VM.

scsi vmx


Replace the above parameter with this one:

SAS vmx

Please don’t forget to insert the firmware = “efi” parameter that I described in earlier posts!  If you edit the VMX and your VM hangs, reboot into the Boot Manager, which you usually can access by pressing F2 a few times during the boot process.  There, just select the virtual VMware Virtual SCSI disk and hit Enter.

Boot manager

 2. Password removal

Back here, I described the Windows 8 feature that allows users to log on to their systems with MS Account credentials.  This feature allows both local and online logon.  The required password strength makes a hash attack a little more difficult.  However, the most important thing to remember is that, to gain access to the system, a password is required.  You cannot “blank” the password using tools like the Linux-based boot CD or NTPwedit.  You must change the password.  Although some tools ostensibly allow you to change the password, I’ve found that they fail in that regard.  I still know of only one tool (commercial, but cheap) that works: Reset Windows Password (RWP), which is available at and produced by Passcape Software.  I described its use and a UEFI workaround process here.

The workaround arose from the need to edit the password on a UEFI/GPT MS Account system with a tool on a bootable ISO/CD.  In hindsight, I should have suggested a quicker approach, which I will describe here.  As seen in one of the above screenshots, we edited our VMX file to enable the EFI firmware.  Passcape’s RWP is not yet available for use on a bootable UEFI, USB device.  So, if you use RWP or any tool on a bootable ISO, you need to re-edit your VMX as follows:

edit to bios

Once you re-edit the VMX file, you can boot to a non-EFI medium.  Just remember to change it back to EFI thereafter, or you system will not boot to Windows (“operating system not found” message).  I’ll add that RWP also allows you to invoke regedit and several other utilities directly from within the application.

3.  Shadow Volumes and Russian Dolls

This is another topic that folks bring up occasionally.  If we mount a shadow volume directly from an image or from an image that we boot in VMware, we’ll find that the shadow volume, itself, contains a System Volume Information (SVI) folder that contains shadow volumes.  Let’s say that we mount a shadow volume that was created on October 1, 2014, and was the earliest shadow volume in our target system.  When we look in the SVI folder of that mounted shadow volume, we may find a shadow volume that was created on September 1, 2014.  Now, it seems logical to assume that we can mount the latter shadow volume and go back in time even further, perhaps to the date when the system first was used.  We can’t.  I’ve tried a few approaches, including running vssadmin against the mapped shadow volume and attempting to boot the mapped shadow volume.  Neither method worked.  I wasn’t able to boot a shadow volume, even by reconstructing a physical disk with that volume.  I also ran this theory by one of the world’s leading Windows forensics experts, Troy Larson, who, not surprisingly, thought about this concept long before I did.  In short, Troy suspected that the shadow volume files and other data within a mounted shadow volume were incomplete and could not be reliably processed by the system.  Remember that shadow volumes really are “difference” files that depend on one another, and inconsistencies in any of them can affect their functionality.

NOTE: I’d like to direct readers to the comment posted by Joachim Metz.  He’s done a great job of documenting shadow volumes and provided a link to a paper that he published.  His comment and paper may provide  the precise answer.

For those who want to play around with UEFI, VMware has preview edition available that affords some undocumented (buggy) enhancements, so be careful if you give it a shot.  That’s all for now.


A Quicker Way to the Shadow Volumes and Dealing with Win 8 VHDXs

Arsenal Image Mounter (AIM) is a new image-mounting tool from Arsenal Recon.  Not only is it free, but the folks at Arsenal have been gracious in lending support.  AIM employs a special SCSI driver that lets us mount image files of various types so that Windows Disk Manager can see our mounted image (a pseudo disk, as I like to call it) as an actual disk. This innovation allows us to access shadow volumes in a completely new way and avoid converting images to, for example, VHD files.  AIM also can mount our image as write protected or as writable.  I won’t go into more depth on AIM’s features, as you can visit the web site to learn more and acquire a copy.

Heretofore, Windows would not enumerate shadow volumes on images mounted with the most popular tools, e.g., FTK Imager, Mount Image Pro, etc.  A notable exception is a Windows virtual disk file (VHD), which is not used to an appreciable extent, if at all, as the target of a disk image file in computer forensics.  I’ve explained before how to work with these virtual disks with respect to the Window 7 variety (VHD).  Windows 8 brings a new format, which is the VHDX file, which I’ll mention again later.  For now, suffice it to say that there no longer is a need to convert a dd image to a VHD if your goal is access shadow volumes on your host system.  As I’ve demonstrated in my VHD post, the conversion required the addition of data to the end of your dd image.  While that made an easily reversible change to an original image file, some folks were not comfortable doing so and chose to create a spare dd file.

Let’s take a closer look at AIM and how it can help us get to shadow volumes very handily.  I’m going to work with a dd image of a Windows 7 system, though there is no difference with an E01.  In the following screenshot, I’ve opened AIM and navigated to my image file (001).


Next, we’ll see the window that AIM presents after I select the image.  I’m going to maintain the default options, which the screenshot depicts.  Typically, we don’t have to ask AIM to fake (cache) a disk signature, which AIM allows because Windows won’t mount a disk if it does not have a signature.  I’ve seen only one case in which a disk signature was absent, and it concerned a VHD file created by Windows 7’s system image feature.  Note than AIM handles 4KB (and other) sectors.

aim options


After I click OK, AIM presents the mounted disk as Drive 10 in my system (above and in next screenshot), which we then can find in Explorer as well as in Disk Manager.  Note that Disk Manager reports the pseudo disk as it does every other disk, but indicates that it is read only.  In case you haven’t looked or noticed it before, mount an image with another tool and compare Disk Manager’s findings with an AIM-mounted image.


Next, let’s access shadow volumes without using virtual machines or any other steps outside of our host system (mine is Windows 8).  As you’ve seen in one of the screenshots, our mounted image’s system volume was mapped to Drive M. The next demo is a video, which presents how we can enumerate the shadow volumes on Drive M.

Again, you can try that with another image mounter to see the distinction.  Now, we’ll map one of the shadow volumes with Dan Mares’s VSS, which is a tool that I’ve mentioned frequently in my blog. The basics of VSS can be found here, among other posts.  You can pick up VSS free at  The next video demonstrates VSS.

At this point, we can work with Drive P as we can with any logical volume.  We can open the volume in most forensics tools or image the logical volume if we wish.  Remember, too, that an alternative to mapping a shadow volume to a drive letter is to create a symbolic link to the volume.  The next screenshot shows how this is done.  We’ll create a link to Shadow Volume 13 in the aaa directory.  Remember to add the trailing backslash in the syntax, after the ShadowCopy number.


While I’m talking about Symlinks, it’s important to note that Windows uses them in various places on our systems.  For example, \Users\All Users is a SymLink to \Program Data on the active system partition.  If, for example, we open Users\All Users on our mapped shadow volume (P) and open Program Data on our host system, we can see that their contents are the same:


This will happen whether you map the shadow volume to a drive letter or create a SymLink.  Needless to say, this can lead to some misinterpretations during an exam.  However, if you open the mapped shadow volume in a forensic tool, at least with X-Ways Forensics, the SymLink issue will be ignored.

Now, let’s return to VHDX files briefly.  At this time, a number of forensic tools can’t access that file format.  If you encounter one, it likely will be a system image backup on a Win 8 image.  To give most tools access to your VHDX file, mount the Win 8 image file in a Win 8 host with AIM.  The next video follows the process:

Note that this works when you mount your VHDX-host image with AIM.  It likely will not work with other imagers that don’t allow Disk Manager to have access to the mounted image.  While you can copy the VHDX from your image to a Win 8 host, it’s unnecessary if you have AIM.  Another option is to create a VM from your Win 8 image, mount the VHDX therein, and access the mounted VHDX file with X-Ways Forensics from a thumb drive.  When you’re done, right-click the mounted VHDX in Disk Manager and opt to detach the disk.  Bear in mind that Win 7 will not mount a VHDX file.



VMware VMs for Free (At Least for Some)

I’m talking about VMware Player Plus (Player), which is a very limited version of VMware Workstation.  It is free for non-commercial use, and I’ll let you decide whether the license allows you to use the application.  You can download Player at and learn more about it at  The commercial version is $99.00, whereas VMware Workstation is $249.00.  You can upgrade Player to Workstation for $149.00, or basically the original difference.

One of the biggest drawbacks of Player is that it doesn’t include the snapshot feature of Workstation.  While Player can create a VM, it can’t create one from a virtual or physical disk as we do in our forensic work when we use image files.  Player also can’t mount a virtual disk.  To create a VM in Player requires that you install an operating system.  Player allows you to run and interact with a virtual machine.  Here’s what it looks like, including a shot from the window where we can create a new VM.


To play a VM, we go to the Open option from the File menu.  There, Player asks us to navigate to the VM file of the appropriate type.

Open File

When we created VMs from dd images, we build a custom descriptor file (vmdk) that conformed with the geometry and name of our image file.  When we used a mounted image, as in the case of E01s, we created our VM from a physical disk and allowed Workstation to configure our VM for us.  When we first booted or returned to run our VM, we basically opened the VMware configuration file, which is the vmx file.  Regardless of whether we used a dd image or mounted image, Workstation produced a vmx file for us.  In the case of a physical disk or a UEFI system, we edited our vmx file as I described in previous posts.  To reiterate, you can’t use Player to create a VM from a vmdk file, although we need a vmdk file to describe our disk and a vmx file to run a VM.

In most cases, we can start with templates for our vmdk and vmx files.  They simply are text files that we edit to fit our particular target system.  To use Player in the absence of Workstation, I’m going to use a mounted image.  Why?  We can’t take a snapshot, and our image (mounted disk) must remain unchanged even if we have to edit the registry and strip passwords.  The process basically is the same as in Workstation 10, but we have more work to do because we don’t have Workstation to build our base files for us.

We must start with an image mounter that allows write caching, e.g., FTK Imager.  Let’s mount our image, which I’ll select in the next screenshot.

select image

Before we mount the image, we must be sure to select the Writable option in Imager.



When we click Mount, we’ll see our mounted image.


Take note of the PhysicalDrive number, which is 2.  We also see that the disk volumes are mounted as well.  From here, we can load the target system’s registry System hive into our own registry and edit the HKLM\TargetSystem\ControlSet001\services\LSI_SCSI\Start to 0x00.  I described the process here.  The next step is to remove any passwords using a GUI based tool, like NTpwedit, which I also described before.  Leave the image mounted in Imager.  The mounted image must remain mounted whenever you want to boot it in Player or Workstation.  If you unmount the image, you’ll have to do the edits from scratch, as they only were stored in cache.

Now, we have to create descriptor (vmdk) and configuration (vmx) files.  I have a template of each, which you can download: vmdk vmx.   Copy the files to a folder, and be sure to reinstate the correct extensions for each file.  Next, we have to edit the files to fit our particular mounted image.  I’ll use screenshots to highlight the edits.



Next, let’s turn to the vmx file.


I simply created the vmx template by creating a VM from a physical disk (mounted image) in Workstation 10.  You can see the version in the screenshot.  I don’t think that Player cares about the version number.  The next arrow identifies the device type.  You may remember that we deleted the word “raw” when we built VMs from mounted images in Workstation in order to allow snapshots.  We need not be concerned with that here, as we can’t take snapshots in Player.

Let’s see what happens.

After you run your VM, you’ll find a few additional files in your VM folder, but you can ignore them.  Note that you can install VMware Tools from the File menu.  You also can add hardware and share folders with your host.  You can run applications and test anything that you would in the original system, but remember that you can’t roll back or un-do changes as you could in Workstation.

I’ll add that it’s possible to create snapshots manually. It’s quite an undertaking and something that I’ve had no need to attempt.  Again, given the minimal cost of VMware Workstation, I would “spend” more in my time than the cost of Workstation.

Windows 8 VMs and MS Account Users – We’re In! (Plus a Way Around Startup Passwords-Syskey)

Well, it didn’t take very long to come up with a method to access a Windows 8 Microsoft Account user’s desktop.  The issue is that, when we strip passwords from user accounts, our tools typically zero out the current password.  If we use NTPwedit, the process appears in the following screenshot.  We target the account, leave the password fields blank, hit OK, and save our changes.  Strip password

Thereafter, the NTLM hash appears as in the following screenshot.

NTLN hash

However, the most important thing to remember is that MS Account users require a password.  A blank password won’t work; you can’t log in locally without a password.  If you try to enter a password with NTPwedit, you may be greeted with the screenshot that appears next.


There are other tools that can strip passwords, but you’ll have to test your choice to see whether it works.  Remember, if you have a GPT disk as your target, VMware will not mount it in Windows.  Instead, add the virtual disk to your SEAT Workstation and either use a Windows based password tool on the target disk or boot the SEAT workstation to a password-editing boot disc.  Typically, you can’t boot a UEFI system to a CD/ISO, but need a USB device with UEFI support.

Concerning other password editors, I’ve encountered problems in booting Windows 8 VMs with Petter Nordahl-Hagen’s Offline NT Password & Registry Editor.  It seems to cause a hardware fault in my VMs.  I also tried the version known as PogoStick, available from, and I encountered a similar problem, or it seemed to do away with the user account name, but did change the password.  The utility does warn users to take care when attempting to change a password instead of blanking the password.

I’ve also tried the paid version of Kon-Boot 2.2, but it did not get around an MS Account password.  Remember, even if you unlock Administrator and log on as Administrator, you cannot edit the MS Account’s password, either through the Control Panel or with the command line utility Net User.  You can experiment yourself with other tools, and perhaps you’ll find one that works.

After trying a few tools, I found a great commercial tool that can reliably change a password as well as get around a syskey-locked machine, which I’ll describe later.  The tool is Reset Windows Password (RWP), which is available at and produced by Passcape Software.  There are three editions: Light, Standard, and Advanced, and only latter two will deal with Syskey.  The Standard edition is $145 and worth the price.  The light version is $45 and can reset or change SAM account passwords.  So, if you boot the target system or your SEAT workstation, the process is in the following video.

That may suffice in the vast majority of cases.  Of course, this approach will get you into the local system and not to the actual MS Account. That’s good, because we never want to log on to any email or online account without lawful authority or do anything that conflicts with the ECPA (Electronic Communications Privacy Act).

What happens if we change a password in accordance with this or my other posts, and we’re greeted by the following screen?


Welcome to Syskey.  Syskey basically is the utility that encrypts the password hash in the SAM hive.  The Syskey (encryption) key can be stored on the drive or on a floppy disk (a USB key also is possible).  The location of the key is found in the System hive:

Key: SYSTEM\CurrentControlSet\Control\Lsa
Value: SecureBoot
Value: 0x1 Startup Key stored on local hard drive
Value: 0x2 password Startup Key
Value: 0x3 Startup Key stored on floppy disk

I’m not going to present a tutorial on Syskey, hash encryption, password caching, etc.  Suffice it to say that the process involves the DPAPI (Data Protection API) and some files like CREDHIST, which stores user hashes on a historical basis, and Preferred, which contains the current master key.  I won’t pretend to have a complete grasp of the mechanisms involved in the process, but Passcape offers a number of free papers that go into some detail.

In the next video, I’ll demonstrate how to set up the system (Win XP, Vista, 7, 8) to require a startup password.

Note that the Syskey password is required to get to the logon screen, so you won’t have the chance to try your newly created or zeroed password without the Syskey password.  Once you enter the Syskey password, you’ll arrive at the user logon screen.  If you studied the Syskey window, or recalled the LSA key’s value data, you noted that the key might be stored on a removable medium.  What do you do then?  Read on.

Here’s where the Standard and Advanced versions or RWP pays dividends.  As far as I know, it’s the only tool that can reset Syskey.  If you purchase RWP and study the Help and information on the site, which includes a forum, you’ll note that resetting syskey comes with some implications.  All user certificates and passwords will be reset, such as those associated with MSIE and, of course, EFS.  However, we don’t care because we’re working in a virtual world.  We always can go back in time to a place before we made a mistake.  Here’s a video that goes through the syskey reset process and explains a little more later.

As noted above, resetting syskey causes all passwords to be reset.  The reason that we must go back and change any MS Account passwords to a valid string, like 123, is because the Syskey reset will blank those passwords or set them to the null value.  I understand that the Syskey hash is stored in the Security hive, but is not crackable by most hash/password crackers.  I’m also unaware of another tool that can reset Syskey.  I’ll let my readers explore Passcape’s site to learn about their programs, and they offer limited-feature demos to enable folks to get a feel for the tools.  I’ve also found the publisher to be very helpful in terms of support and educating me about the process.  If I explore this issue a little further, I’ll post more details.


Windows 8 VMs and MS Account Users – A Workaround For Now

In our ongoing effort to use virtualization in forensics, we’ll have to deal with Windows 8 systems that employ Microsoft (MS) accounts as the local users.  The point is to boot an image to a target user’s account, and I’ll get to that issue later after I present a few basics.  Windows 8 offers users the option to log on to their computers by using MS account credentials.  That option is a feature of Windows 8 that allows a user to employ any MS account-based email address and password to sign in to Windows 8.  Doing so allows the user to synchronize the local system with other systems that he or she accesses and take advantage of MS online services.  If you don’t have a MS account, simply go to and click the Sign up now link.

You don’t need a “real” email address to create an account initially, and I created a fictitious account for my tests (oh, to have been born in 1990!).  However, you want to use a legitimate account for an actual system, as MS eventually will require email validation, although perhaps only for a hokey-looking email address.

Create MS

You can go to to learn all about setting up and using a “sign in everywhere” account, so I won’t t into great depth.  Of note is that, to create an MS account login, you must be online.  Thereafter, you must be online for your first logon.  You don’t, however, need to be on the Internet to log on locally thereafter.

Create MS ac


create ac offline

Anyway, let’s say that you go about creating your VM as we’ve done in the past.  You edited the registry.  You know there is one user account that requires a password, because you checked the NTLM hash with SamInside.  While editing the registry, you also stripped the password with NTPwedit.  You fire up your VM and are pleased to see that you’ve arrived at the user screen.

logon 2

Okay, you still feel pretty good about your progress, as you made it to the logon screen.  You stripped the password, so you need only click the arrow in the above screenshot.  Right?


Still feel pretty good?  Let’s go back in time and try to figure out what happened and perhaps learn a few things about whether we can get into the system.  First, I’ll show what the registry contains after we created our MS account and logged on to the system.  Remember, the system was online for the first logon, but may be offline thereafter.


Above, I’ve loaded my SAM and SYSTEM hives into SamInside.  My password is 1300myaccount (now changed) and you can see that the NTLM hash does in fact equate to that password (in the hash generator box).  So, we would think that zeroing out the password would get us into a non-Internet-connected Win 8 VM.  Well, it won’t.  The original password still is required to log on to Win 8.  Moreover, at the moment, I have only good news and bad news.  I’ll start with the good news.

If you look again at the last screenshot, you’ll notice the built-in Administrator account.  That account has no password (the hash is the null value), but typically is locked.  So, if you face this dilemma, go back and mount your virtual disk fas writable. Remember, you can’t mount a GPT disk from VMware, so go back and check my post about that solution.  After you map your disk, run NTPwedit, unlock Administrator, blank the password (just to be sure), and save the changes.

Edit Admin 1

After you boot your VM, you’ll notice something different in the default login window.

next logon

Yes, it’s the left-arrow next to the picture.  Click the arrow and voila!

Next arrow

If you click the Administrator, you’ll gain access to your VM.  While this gets you into the system, it’s not ideal.  Many times, we want to boot to the target account to determine that user’s particular settings.  Remember, a user’s NTUSER hive and AppData tree contain settings and configurations that are particular to that user.

In my next post, I’ll present the relatively simple solution to this problem.  Remember that MS requires 8-character passwords that must have two different character types, and that could make a password attack more difficult.  Note, too, that the MS Account’s SAM does not provide certain artifacts, e.g., most recent logon date and logon count, so be sure to keep that in mind when you do your exams.  In any event, while I find time to issue another post, I thought that I’d present a basic explanation and what may be an acceptable alternative in at least some cases.

VMware 10 and Booting Through a Write-Blocker

In my last post, I pointed out an issue that affected the way we boot E01 and other non-dd image files.  The issue arose because VMware 10 does not allow us to map a physical disk, e.g., a mounted image, as writable.  We want to mount potential VM disks as writable to edit the registry and remove passwords.  Naturally, this change also affects how we boot a disk through a write blocker.  I posted on that method previously.  In this post, I’m running VMware 10.0.0 on a Win7x64 host.  My target disks run Win7x32 and Win7x64.

To get around the VMware 10 limitation with a mounted image, we mounted the image with FTK Imager or another tool that allowed write caching.  Write caching takes potential writes to a mounted image and stores them in a file instead of on-disk.  We then accessed the mounted image directly, edited the registry, and removed passwords. Next, we built a VMware VM from the edited mounted image, edited the vmx file to allow snapshots, took a snapshot, and away we went.  However, in this post, we’re working with a “real” physical disk, albeit through a write blocker. There’s nothing to mount.  Image mounters can’t “mount” a write blocked disk or any physical medium.  They’re not supposed to do that.  After all, why mount a disk when it’s already mounted?  Now, if you have a write blocker that allows write caching (Voom Shadow), you can simply follow the steps in my last post.

Note that we can create a VM directly from a (write protected) physical disk that came from a system disk that we receive for examination, but it’s apt to be unbootable, given a typical Windows 7 system on the disk.  Of course, the object is to make it bootable despite the fact that VMware 10 won’t allow us to write to the disk.  The first thing we’ll do is create a VM from the write-blocked disk.  When we power up our blocker, the disk will be mapped as a physical disk and Windows will present the logical volume(s).


In the screenshot, my write-blocked disk is Disk 8, which happens to contain one logical volume, which Windows mapped as M.  Now, let’s create a VM.  We’ve done this before, but here’s a video to remind you of the process.

Next, we’ll edit our virtual machine configuration file (vmx) to allow snapshotting.  Take a snapshot when you reopen your VM.

We now have a VM that’s based on a write-protected disk, but has a snapshot that will serve as the target for writes.  We can try to boot it to Windows, but it will blue-screen.  Trust me.  So, let’s make another configuration change to our VM.

I chose to use an ISO of a Windows 7×64 installation DVD.  I’ll anticipate some questions by telling you that you can use your host’s physical CD drive with the Windows disc if you wish.  If you do, just leave the VM’s CD drive mapped to your host system’s physical CD drive.  Note that, if we intended to go through an actual Windows repair, we’d need the same version disc as was on our target system.  Here, we don’t.  Before I present the next video, I’ll tell you what we’re going to do.  We’ll boot to the DVD and go into Windows Repair.  There are a couple of ways to get VMware to boot to your DVD, but I usually just hit Escape after the VM starts.  You also can reset the boot order in the BIOS, VM\Power\Power On to BIOS from the menu.

I usually take a snapshot at this point.  We’ll close out of repair mode, which should reboot our VM to the guest system’s login screen. If the user has no password or has one that you know, you’re set to log on to the system.  Otherwise, we must remove the passwords.  Before you get this far, you could have opened your disk in your favorite tool and checked whether a password would be an issue.

There are a few ways in which we can reset the password.  I used an ISO of free, multi-tool application named Hiren’s Boot CD, available at  The disc includes a number of free tools, including a mini-Windows XP PE platform.  However, at the moment, I want to use the password reset feature.

I went through the process somewhat quickly, so pay attention to the prompts and options.  Make sure that you select the proper partition, which is the partition contains the registry (#2 in my example).  The default is Partition 1, which often is the boot partition and not the system partition in Windows 7 and 8 (I haven’t tested 8 yet).  I usually unlock the target account and remove the password during the same operation.  Remember that when that when it comes time to reboot, we use Ctrl-Alt-Ins in VMware.  Ctrl-Alt-Del will take us to the options on our host system.

At this point, your write-blocked disk should boot to Windows 7, and you can log on as the user.  Note that this process can be a little buggy sometimes.  Before VMware 10, we edited our physical disk through our first snapshot, which we mounted as writable.  Although we’re doing almost the same thing here, I’ve found that the repaired system sometimes blue-screened, though not because of the standard driver issue.  To avoid that problem, take a snapshot of the system when it boots successfully for the first time.  Let’s call that snapshot our “Base System.”  Then, you simply can go to the Base System snapshot and start from where you last ended.

I would install VMware Tools at the first successful boot, but that depends on my mission.  I’ve found that installing VMware Tools can avoid a blue screen on reboot, though the installation requires a reboot, itself.  As I mentioned before, installing VMware Tools creates a restore point, which can overwrite others.  Take more snapshots along the way, so that you can develop the evidence that you desire.  Remember, too, the disk number of your write blocked drive.  As you mount or swap disks in you host, disk numbers may change.  If your original disk number changed, edit the <original>.vmdk file.

Frankly, I don’t consider booting a write blocked drive as practice that I will repeat more than once or twice on a given drive.  If the disk warrants that much attention, I’ll image it (dd) and go through more conventional exam procedures.  BTW, you can pick up a Voom Shadow device to boot an original drive.  Although my approach takes a little more work, it’s about $1,900 cheaper, considering that everyone already has a write blocker.

Anyway, you may have to try a few experiments to get a given system to boot reliably.  As an alternative to booting to a Windows install disc, you can use Hiren’s disc and load the “Mini XP” system.  From there, you can use Regedit to edit the registry, and use a Windows password stripper if you load it into the Hiren ISO or access it from a USB stick that you mount in the XP environment.  Good luck!


VMware 10 and E01s – Plus the Pesky “physical disk is already use” & “error reading volume” messages

I. VMware 10

VMware 10 is the latest release, and it will affect how we mount E01s if we want to boot them in VMware.  In my first post about booting E01 images, I explained that we had to mount them as physical disks (logical, too, if wanted).  The process involved the following steps:

  1. Mount the E01 image in FTK Imager (or similar tool).
  2. Create a VMware machine by selecting the mounted physical disk.
  3. Edit the vmx file to change rawDisk to Disk.
  4. Take a snapshot.
  5. Map the disk in VMware as writable.
  6. Edit the registry and strip passwords.

Well, Step 5 isn’t possible at this point.  If you try to map the disk as writable, VMware will present the message in the following screenshot.

Mount as writable

If you open the disk as read-only, it will map fine, but we will not be able to do any editing.  All is not lost.  Simply be sure to use FTK Imager to mount your disk as writable, so that it will cache edits.  Moreover, as we want to effect edits on a logical volume, be sure to have FTK Imager mount both the physical disk and logical volume.  Heretofore, we needed to mount only the physical disk.  Then create your VM as usual, but omit mapping the disk in VMware.  Although FTK Imager will discard the edits that you made to the mounted image when you unmount it, those changes will persist in your VMware snapshot.

Of course, you must remount the image whenever you want to access it in VMware.  One thing to remember is that, if you remount your image in FTK Imager, be sure that your drive number remains the same as the original, or you must edit your vmdk file to match the new number, Drive 7 in the example below.  Your vmdk file will include a line like this, based on the screenshot that follows:

RW 488397168 FLAT “\\.\PhysicalDrive7” 0


Doing things this way was something that we always could have done.  It just wasn’t my practice, and I almost never use an E01 as my working image file.  Even with a split DD image, you may fine mounting preferable to creating a vmdk file with all of the extents.

VMware never officially supported mapping physical disks as writable, and evidently patched Version 10 to prevent us from doing so, until we figure out a hack.  If I come up with one that allows writable physical disks, I’ll post back.  According to the VMware tech with whom I spoke, the issue was that too many users were damaging real media, i.e., real disks.  Actually, VMware also discourages users from snapshotting physical disks, and we get around that by editing the vmx file.  However, there also is a command line tool named vmrun in your VMware\VMware Workstation folder, and you always could have used that to create a snapshot of a physical disk.  As we have a simple method already, I won’t demonstrate vmrun.

II. Error Messages

Okay, if we’ve used mounted images for any length of time, we’ve probably been frustrated by an error messages that appear when we try to map a mounted image or boot it in VMware .  This message can show up regardless of whether we try to mount read only or writable.



These errors presents when something “out there” has a hook into your mounted image.  I don’t know what it could be or whether it can be several things.  I’ve tried to replicate them, with only limited success.  They seem to present when I do a lot of mapping/unmapping and mounting/unmounting.  Sometimes, if I unmounted the image, closed VMware, mounted the image again, started VMware, and tried to run the VM, I received an error message that is similar to the first one shown above.

It appears that the easiest way to get around the errors and get back to work is, in the words of your favorite Help Desk tech, “reboot your computer.”  That means your physical, host machine.  If that doesn’t work, post a comment and I’ll dig deeper when time permits.  Thanks for your time.

What am I missing here? Maximizing Artifact Recovery from Shadow Volumes

I’m taking a break from posting articles on creating virtual machines and disks to talk about a phenomenon that affects our examinations of NTFS volumes, regardless of whether our target is any form of image file, mounted image, or physical disk.  From the beginning, I geared my posts to examining shadow volumes (SVs), and I suggested methods that, for the most part, employ virtualization.  Regardless of which of my methods we use, we’ve always mounted our SVs so that they appear as a logical volume.  Once mounted, we can access the typical files and folders as they existed when the Windows Volume Shadow Copy Service took a snapshot.

When we do an exam, we may employ any number of tools that may recover data from SVs natively.  Each has its own methods of finding and presenting the information that we seek and, short of mounting a SV, traverses and interprets SV files.  Typically, any files that my tools find in SVs do in fact exist in the SVs, and I can verify that by using one of my mounting approaches.  Aside from the usual files that we recover automatically by analyzing the SV files, themselves, there may be all kinds of artifacts that exist within the SVs, such as records contained within files, e.g., databases.  It’s those artifacts to which this post relates.

First, I’m not an authority on the structure of SVs.  We know that they’re basically block level backups where changes to files are saved in 16KB chunks.  When we mount a SV, Windows puts everything back together so we have a recognizable file system.  In a sense, the SVs are analogous to compressed files, the contents of which are meaningless while compressed.  However, it’s not that simple.  SV files are “difference” files, a term that derives from the fact that they store changes to objects.  The SV files work together in a way that’s like a jigsaw puzzle where we need every piece to put the entire picture into view.  Their parent folder, System Volume Information, includes a number of files that coordinate the reassembly of a former volume.  If you delete a given SV file, doing so will break everything!  The Volume Shadow Copy Service won’t find your SVs, let alone permit you to mount any of them.

Our tools may do a good job of gleaning recognizable data from raw SV files without the need to mount them and examine the mounted volumes, and mounting each SV can take more time than we’d like to spend.  By doing so, however, there may be a trade-off in terms of the information that we recover.  My point is not to criticize any tools, which, by the way are getting better all the time.  My point is to describe how our practice may limit what we recover, and that may be okay in given situations.  Therefore, I’m not going to mention any tool by name, as I encourage you to test my findings yourself with the tools of your choice.

Before I get to the heart of the matter, I want to remind readers that there is a key distinction between physical and logical structures that can affect the recovery of any object.  Put simply, files exist in clusters and follow a path of clusters that may be fragmented.  Clusters are a product of a logical file system and don’t exist on physical media, where sectors contain our data and are laid out from Sector 0 through Sector X.  If a fragmented text file is in Cluster 100 with the balance in Cluster 200, Windows will present the complete file to us.  However, on the physical disk, there isn’t a way to determine the sector chain that contains the entire file.  We may find a portion of the file in a group contiguous sectors, but we don’t know which remaining sectors may hold the balance of the file.  Large files, like SVs are more apt to be fragmented.  As a result, you may want to consider running both a logical and physical recovery across an image/drive to get the best of both worlds.

By examining a SV logically, your tool should be able to piece together data that lies in non-contiguous clusters.  However, whether physically or logically traversing a raw (unmounted) SV finds all of the desired information is another matter.  Let’s consider records of web browser activity.  Microsoft Internet Explorer (MSIE), through Version 9, stores records in index.dat files, while most of the other popular browsers, e.g., Firefox, use SQLite databases.  I took a look at MSIE and Firefox Internet history, and I’m limiting my discussion to data that may be found in SVs.  The test systems ran Windows 7.

For my first test, I copied a 2GB SV from an image to my workstation.  If you run a tool against every file on a logical system, it may view a SV file as any other and interpret its contents.  The exception will be if the tool actually mounts the SV to a drive letter or recovers intact data stores from the SV.  If you run a tool against a physical image or drive, it will traverse every sector, including sectors that contain SVs, albeit not as files.  I exported SV files and carved records from them, and that’s analogous to a logical recovery that carves across files.  It’s also somewhat similar to a physical recovery, which ultimately carves data from every disk sector.  Please note that we are not trying to recover files, but structured data, i.e., database or index records, within files, and that complicates the situation.

I then used some tools to traverse the 2GB SV file for MSIE history records.  My tools recovered 148 MSIE history records from the raw SV.  I used the same tools to recover history records from the then-existing MSIE folder tree in a mounted SV, and each tool recovered 537 records.

Firefox history tests provided much wider numbers between the recovery methods.  With respect to the same 2GB SV, I did not recover any Firefox history records from the raw SV.  However, when I restored the places.sqlite file from the mounted SV, I found that it contained more than 42,000 Firefox history records.

In a second test, my target was a 1.5GB SV from a different system.  Each tool recovered 29 MSIE history records from the raw SV.  By exporting the history from a mounted SV, my tools recovered 1,958 MSIE history records.

For my last test, I used a 3.6GB SV.  Each tool recovered 451 MSIE history records 764 Firefox history records from the raw SV.  By mounting the SV and running recoveries against the native host files, I recovered 675 MSIE and 1,284 Firefox history records.

I should point out that, with respect to Firefox, I sometimes recovered more history records from a single, mounted SV (places.sqlite file) than I did from the entire physical image.  I didn’t test both MSIE and Firefox from every system, as a given user did not necessarily employ both browsers, or the user preferred one over the other to a large extent.  Every system will be different.

Again, my aim was not to host a tool competition, but to test competing practices.  My tools are state of the art and they validated one another’s findings.  What is today’s state of the art may not be tomorrow’s, and I’m sure that the gap between the methods will narrow.  I’m also sure that the test results related to Internet history would be similar to findings for other artifacts that are stored in a variety of files.  Give it a try.  In the end, I will say that I don’t mount SVs in every case.  I often run recoveries against logical volumes or physical disks and leave it at that.  It depends on the case and the results of what I find in the first go ’round.  Remember, part of our job is to use good judgment.


VMs From Logical Volumes – Turning Logical into Physical

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

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

Template 0

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 0x80 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.

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

open image (2)

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.

Post interpret-2

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.

Tech details

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:

Post snapshot

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 0x00, 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:

mount new image

Then, open the mounted volume (Drive M in my example) in XWF, and hash the volume.

compute hash

I mounted Volume M and accessed the Tools\Compute Hash menu to hash the mounted volume.

hash result

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!

Troubleshooting VMs, Part 2

To follow up on my last post, I thought of some other mistakes that will prevent your VM from booting.  Bear in mind, that I’ve made most of these mistakes as I came to the point of starting my blog.  On several occasions, I discussed that we had to edit or at least examine the registry of our guest system.  That requirement results from the fact that we built our VM with a SCSI disk, and the system on our guest (image file) may want to boot from an IDE disk.  You can go back through my posts to recall the basic steps to create a VM.  For now, just remember that we created our VM with a LSI SCSI controller.  First, let’s look at the unedited, SYSTEM hive from our guest drive, which we mount as read-write in VMware and loaded into our own (host) registry.

reg 1

As we created our VM with a LSI SCSI disk, we have to start the LSI SCSI driver at boot.  So, we change the Start value data to 0x00.  Just change the 0x03 to 0x00 (change the 3 to 0 in the edit box).

reg 2

Assuming that we fixed any password issues, we should be good to boot.  But wait; we get the old BSOD.  How can this happen, you ask Weg, as you edited the LSI SCSI registry key?  Here’s one way that it could.


When we get to the point where we choose our disk controller, VMware defaults to the LSI SAS controller, and even recommends that we keep the LSI SAS.  If you simply click through this option box, your machine will contain the SAS, and not the SCSI, controller.  When we boot, the system will crash because the wrong driver will load.  If you catch this mistake, you need not start fresh.  SAS is fine, if you load the LSI SAS driver.  Just go back and reset the LSI SCSI to 3, and change the LSI SAS (the first one, if there are two) to 0x00.



In the upper screenshot, note that we edited LSI_SAS and not LSI_SAS2.  If everything else is okay, you resolved the issue and your VM will boot.

Concerning VMs created from dd images, some folks forgot that we use a different procedure for segmented images.  Each segment must be enumerated in our VMDK file.


Lastly, we need to mount E01 and other image formats as physical disks to build VMs from them.  We need not create the usual VMDK file for the physical disk, as VMware will create it for us when we elect to build a VM from a physical disk.  Just be sure to go to the folder in which you created the VM and edit the VMX file.


Delete the word raw.  Then, take a snapshot after closing and re-opening the VM to refresh VMware.  Next, edit the registry/passwords as you would in the case of a dd image VM.