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:

EFI

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.

scsi

 

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 http://www.passcape.com/reset_windows_password 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.

 

11 comments

  1. Mike D says:

    I am attempting to boot a Windows 10 Virtual Machine from an Elcomsoft ISO with VMWare 12. I created the VM from a dd image of a 2 TB HD which was running Windows 10.

    The VM machine successfully booted to the user’s logon screen. I then shut the virutal machine down.

    I then connected the Elcomsoft ISO to machine in the settings within VMWare 12 & then selected “power on to EFI”. Within the boot manager menu, I selected the virtual CD/DVD as the boot device. Nothing happens. Any direction on how to get one of these UEFI/Windows 10 VMs to boot from an iso would be appreciated.

    • jimmyweg says:

      I don’t use anything Elcomsoft. The issue is probably that the ISO is not UEFI compatible. You can change your setup from UEFI to BIOS, boot to the ISO, and then change it back to UEFI after you edit the password, which, I assume, you’re trying to do. Reset Windows Password from Passcape offers a UEFI ISO, and it’s cheap. Will work better.

      • Mike D says:

        Yes. I think you are right in regards to the ISO not being UEFI compatible. I inserted a bootable thumb drive with Paladin (UEFI compatible) and connected it to the VM, and it booted fine.

        I am actually not trying to reset the password. I am actually attempting to determine the Windows Logon password which appears to be MS Account based. I have two Windows 10 computers of interest (one encrypted with Bitlocker & one without encryption). I believe that the same password was employed on both. I am trying to pull the password from the non encrypted machine and use it on the encrypted machine and extract a logical image.

        In the past, I would simply extract the System and Sam files and dump into a password tool. I have been told that this process no longer works with the login credentials based on MS Accounts. After performing some more research on the version of the ISO I was attempting to use, it appears that it does not handle logon credentials based on MS Accounts either. Do you know if Passcape will actually “hash/solve” the MS account password? Or,are you aware of any other solutions to determine the password?

        Thanks,

        • jimmyweg says:

          >I have been told that this process no longer works with the login credentials based on MS Accounts.

          The password hash should be obtainable from the SAM/SYSTEM hives. The fact that it’s an MS logon shouldn’t matter, at least in my experience, particularly if the user ever logged in offline. To do so, the hashes would have to be stored locally. Extract the hives from your image. Load them into SamInside and obtain the NTLM hash. If you don’t use SamInside (free), be sure your tool obtains the correct hash! Then, the best chance is using a CUDA-based system to crack the hash. I suggest OCLHashcat, which is free, and will out-perform any paid tool If it’s a really strong password, you’re s.o.l.

  2. Lars says:

    Hi,

    do you know a way to virtualize a E01 Image of Win8 in VMWare Player? I tried for hours now, but I always get “unsuccesful” from EFI for every device I add.

    In VMWare Player I can’t connect the physical drive (Image of E01 mounted in FTK) as SAS-Device. Only as IDE, SATA or SCSI.

    Thank you!

    Best regards

    Lars

  3. Joachim Metz says:

    > Am I grasping the process?
    Largely yes; let me try to be more verbose.

    Assume C = current, C – 1 = previous (or P), C – 2 is older (or O).
    Both P and O are differential snapshots relative to C.

    If I have P (and assume it is the current volume) and take a look at P -1. The system will assume it to be a differential snapshot relative to P.

    Since VSS only tracks changes relative to C, P – 1 (as a snapshot) is not the same as O; it’s an older, no longer existing version of O. It very likely points to the same location on disk but as O. However since the content of the differential snapshot has been updated to be relative to C, it no longer exists from the perspective of relative to P.

    P.S. the captcha on really sucks; especially since it also does not remember the text commented.

    • jimmyweg says:

      Thanks again, Joachim. First, I installed a new captcha plugin, and

        you

      should not see another captcha. Your example helps quite a bit. I may try to take some screenshots with arrows and such to show the relationshps that exist and which are “broken” in a graphical format.

      This also reminded me that a colleague and I have played around in an effort to mount deleted shadow volumes within a current volume, without success. My sense is that the system (“index” to the difference files) no longer references deleted shadow volumes, so the VSS can’t reconstruct the file system from them. The principle is at least roughly the same as you outlined. There are, however, some forensic tools that may find files/file records within them.

      • Joachim Metz says:

        > I installed a new captcha plugin

        Thx, much appreciated

        > There are, however, some forensic tools that may find files/file records within them

        The question is here, are they representing the data that is there (this is what vshadowinfo would do when running it on a mounted VSS) or do they determine the original snapshots from current snapshots.

        Depending on to the extent the snapshots get restructured. If only new changes get added, then in theory it could be possible to find the point where O was P – 1.

        Though this would not buy us much with volsnap (VSS) since very old snapshots would be lost anyway. But since VSC is a larger sub system than just volsnap this might be useful for other copy providers.

  4. Joachim Metz says:

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

    The shadow volumes are not contained in these files. These files are are files to protect the areas on the volume that contain the changes against the current volume.

    You are seeing these files because you’re looking at an older version of the file system. The actual VSS is handled at volume level below the file system.

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

    They are not incomplete, they don’t exist. If the current volume is N and you’re looking at snapshot N – 1, let’s name this Y. If you look at Y – 1 this has become N – 2 in the current volume. Since the changes are tracked backwards (from the current volume) Y – 1 does not exists. You are looking at file system and VSS catalog remnants.

    For more information see: https://googledrive.com/host/0B3fBvzttpiiSZDZXRFVMdnZCeHc/Paper%20-%20Windowless%20Shadow%20Snapshots.pdf

    • jimmyweg says:

      Thanks very much, Joachim. I think that you can consider the “shadow volumes” in the SVI folder to be “difference” files, so, as you say, the actual shadow volumes are not in these files. It’s just a term that folks have become accustomed to using, though not technically precise as you point out.

      I may have to diagram your second point (and study your excellent paper) to understand your second comment completely. If I follow, N is the current volume. I mount Y (N-1), and a snapshot in Y is Y-1 or N-2. If that or any snapshot in Y exists in N, I would mount that snapshot from the current volume. So, I’ll presume that Y-1 is a snapshot that does not exist any longer in N. To help me move along, let’s say X is a snapshot in mounted volume Y, and X does not exist in N. I can’t mount X because it does not exist in N and the VSS must go backwards from N. Am I grasping the process? I’ll add an addendum to my post to direct folks to your comment and paper.

Leave a Reply

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