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 https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/6_0 and learn more about it at http://www.vmware.com/products/player/.  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.

Player

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.

Options-1

 

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

Mount

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 0×00.  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.

VMDK1

 

Next, let’s turn to the vmx file.

VMX1

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.

PWFail

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 http://pogostick.net/~pnh/ntpasswd/, 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 http://www.passcape.com/reset_windows_password 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?

syskey

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
Type: REG_DWORD
Value: 0×1 Startup Key stored on local hard drive
Value: 0×2 password Startup Key
Value: 0×3 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 https://login.live.com/login.srf?wa=wsignin1.0&rpsnv=11&ct=1385239460&rver=6.1.6206.0&wp=SAPI&wreply=https:%2F%2Faccount.live.com%2Fsummarypage.aspx&lc=1033&id=38936 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 http://windows.microsoft.com/en-us/windows-8/microsoft-account-tutorial 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?

failed

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.

SAM-SYS

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

Snap34

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 http://www.hirensbootcd.org/download/.  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

mount

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.

error1

error2

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 http://store.elsevier.com/X-Ways-Forensics-Practitioner%E2%80%99s-Guide/Brett-Shavers/isbn-9780124116054/.

X-Ways Forensics (XWF) offers many approaches to accomplish a task.  For those who don’t know, the X in XWF is figurative and represents a number.  Why?  Because for many tasks, any number (“X”) of ways (X-Ways) exist to accomplish the task.  My method is not necessarily the best, and I wouldn’t be surprised if there’s a better way, even with XWF.

As noted, you’ll see that my demonstration uses WinHex (with the Forensic license), which really is much more than a hex editor and allows us to edit objects more liberally.  WinHex is available with XWF and basically has the same features, but on a platform that allows an overall writable environment.  Just replacing the name xwforensics with winhex on a copy of the xwforensics.exe executable leaves you with a copy of WinHex.  Before you start worrying about the word “changes,” stop.  Our imaged partition will remain unscathed, and its hash will verify when we’re done.  The differences between XWF and WinHex are found here.

I consider the procedure to comprise two, distinct processes.  The first is the boot process, and the second is the Windows loading process.  Windows won’t load unless the system boots and then finds Windows, i.e., the operating system.  So, what’s missing when we image the Windows volume (Volume C for our purpose) on many current installations?  You’re correct: the Master Boot Record (MBR) and Partition Table.  I’ll just refer to them jointly as the MBR.

Additionally, you also may be missing the backup boot sector and volume slack that follows the end of the logical volume.  Volume slack consists of a number of sectors that do not equate to a whole cluster.  The backup boot sector is 512 bytes.  By looking at a number of drives, I’ve found that the surplus sectors typically number seven.  So, we have seven surplus sectors plus the boot sector, for a total of eight (assuming eight-sector clusters).  These sectors really are not part of the logical partition and may not be included with partition image, depending on how it was acquired.  Nevertheless, we must consider them later when we calculate geometry.  In the field, you may want to note the logical and physical geometry of your target before you leave.

I’m going to simplify, but the BIOS/UEFI checks the hardware (POST) and reads the MBR.  Think of the MBR as a program that reads the partition table.  It then finds the “active” partition, from which the computer boots and which contains the boot files.  The boot sector code at the start of the active partition runs and loads the boot loader, bootmgr, which accesses the Boot Configuration Data (BCD) store, which basically is a registry hive-formatted file.  Bootmgr then turns over the process to the Windows loader, winload.exe.  I’ll stop here.  Actually, we don’t have to worry about what happens next, if all goes well.  We’re not going to worry about GUID partition tables, either.

Wait a minute.  Before I forget, I’m sure that you’ve noticed that many modern systems actually have at least two partitions on the disk.  That little 100MB partition generally contains the files needed for the boot process to load Windows.  Equally important is the fact that this partition is the active partition.  While it is the active partition, it is not the system partition that contains our Windows installation.  Nevertheless, the boot files on this small partition contain the information that enables Windows to load from the system partition.  Should you find yourself in a position of having to image the system partition of a running machine, I urge you to note the disk configuration, nonetheless.  You need to know what you left behind, so you can move ahead more efficiently should you wish to virtualize the system.

I’ll set out our plan now, and then explain the steps.  This process is not a five-minutes-to-a-VM as we saw when building VMs from physical images. One way or another, we have to move or copy a lot of data that equate roughly to the size of you imaged partition.  The approach that I’m going to take first assumes that your image came from a system with the 100MB System Reserved partition.  We’re going to prepend an MBR and a System Reserved Partition (SRP) to our logical volume (image file).  (We could just prepend an MBR, and maybe I’ll go into that method in another post.)  If your image came from a system without an SRP, you’ll have to wait for another blog post, as the following steps don’t relate to your predicament.

First, we need an MBR+SRP, which can come from almost any Win 7 source (stick with 32 or 64 depending on your target system).  I suggest that you create a new Win 7×64 VM, as it’s quick and clean. Once created, I’ll open the virtual disk in WinHex.   Watch the video, and I’ll explain the steps afterward.

When we left the video, we had opened our new, Win 7×64 system disk (VMware virtual disk) and viewed a template.  XWF/WinHex templates are very handy files that interpret various data structures, like MBRs/Partition Tables.  It is a definable dialog box that allows us to edit these data structures much more easily than we can with raw hex editing.  By changing the values in the editable (white) boxes, we can modify the MBR to conform with a new system or make repairs.  If you want to use a template to edit a disk or interpreted image, you must use WinHex as opposed to XWF.

I’m going to present a screenshot of the template below, as it will help us to understand where we go from here.  Remember, I’m using WinHex, so I can edit a disk (interpreted image file).

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 0×80 value at Offset 446 of the MBR.  You can find it in the above screenshot.  I encourage you to use the tool of your choice and navigate as I described, as doing so will make things clearer and help you to explain the process should the need arise.

Let’s move on and open the image of our Windows partition image file.  Note that I open it as a regular file and not as an image.

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.

Interpret

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

RVS

When the snapshot box opens, elect to take a new snapshot.

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 0×00, strip the password if applicable, and start your VM.  If your disk will not mount, or Windows claims that it is not formatted, the cause likely is incorrect geometry.  Fix the problem before going forward.  You may see the following screen when you boot, so let Windows start normally.

boot

This is what we hope to see:

Boots1

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 0×00.  Just change the 0×03 to 0×00 (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.

LS1

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 0×00.

SAS

LSI 2

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.

segmented

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.

vmx

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.

“I followed your instructions, and my image won’t boot.”

First, I want folks to know that comments and questions are welcome on my blog.  I enjoy responding and will give it my best within the confines of my free time.  The aim of this post is to point out some common mistakes that examiners make when creating their VMs from single, dd image files.  Typically, the issues arise from a faulty VMDK descriptor file.  Most of the questions that I receive follow a colleague seeing the following message when he or she is at the last step of creating a VM from a vmdk file built for a given image.

error msg

So, let’s start with a picture of what a valid VMDK file presents for a single dd image file of a Windows Vista/7/8 drive.

vmdk

First of all, a VMDK file must be plain text.  Don’t create it in WordPad, Word, WordPerfect, etc., unless you are sure to save the file as plain text.  Here is a plain text file that you can use as a template: VMDK file.  I’ll take the blame for this one, as I had posted a RTF in my first post without enough explanation.  It’s fixed now.

Another common oversight is to use commas in numbers.  The numbers of sectors and cylinders, which are the numbers that you will edit, must appear as in the screenshot.  They’re yellow-highlighted in the screenshot.

Next, be sure to name you image file correctly.  In the example, it’s “image.001″.  Case is not sensitive.  Typos will kill the process.  In addition, the above VMDK file is designed to reside in the same folder as your image file.  If you want to store it elsewhere, insert the path to the image file within the quotes, e.g., “D:\Cases\VMs\Image.001”  Notice that certain parameters are enclosed in quotes.  If you neglect to use a single quotation mark, you’re apt to get a failure.

That’s it for now.  I’ll post a similar troubleshooter concerning E01-based VMs at a later date.

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.

BIOS-1

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.

Convert

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 http://sanbarrow.com/.  So, we’re at the point where we have a VM.  Next, we take a snapshot.  We can try to boot out Win 8 VM and see what happens.  If you receive a no operating system found message, I suggest that GPT/UEFI may be the culprit.  Of course, you probably visited the system settings earlier to document the setup.  There, you could have learned what might be in store concerning VMs.

Open your VMX file in a text editor and add the parameter firmware = “efi” to the file.  Below is a screenshot of a portion of my VMX file.

VMX

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 (0×00):

reg

 

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.

Error

 

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.

Snapshot

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.

Boot SEAT

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, http://sandersonforensics.com/forum/content.php?168-Reconnoitre.  Paul let me do a little beta testing, and I was impressed with the power of his latest creation.  Many of you are familiar with Paul’s tools, so you know that they perform as represented and meet the demands of the forensic community.  That’s it for now.