The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.



Here's an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 41,000 views in 2012. If each view were a film, this blog would power 9 Film Festivals

Click here to see the complete report.

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.



Here's an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 41,000 views in 2012. If each view were a film, this blog would power 9 Film Festivals

Click here to see the complete report.

I've fielded a few questions via email on building a WinFE over the past few days that I'd like to share on the WinFE blog.

Since Windows FE (Windows Forensic Environment, WinFE) is simply a Windows PE that doesn't automount hard drives, the build of a WinFE beyond that purpose is purely for customization and specific needs.   Those needs can be adding specific drivers,  programs, supporting files, Bitlocker support, network ability, and even making it pretty with a custom wallpaper.

Building a WinFE can be done in one of several ways;

1)  Command line (or batch files via a command line),

2)  Any GUI interface made to create a WinPE (such as Winbuilder),

3)  Or the method developed by Colin Ramsden.

My notes on each method:

1)   Command line - builds a WinFE the quickest, using only the registry settings created by Troy Larson.   A very minimal build, great for older computers with little RAM.   Pre-made batch files can be downloaded from the "Box" to your right on this page.

2)  GUI interfaces - I've tried several different programs and have selected WinBuilder as the easiest.   There are many scripts (additional features/programs) that can be added easily to the build that can practically create a near full-fledged Windows OS on a CD/DVD/USB.  It is also fairly easy to get many programs (FTK Imager, Encase, X-Ways, etc..) running in full mode.

BUT, adding  more features, programs, and scripts that are added results in more RAM needed in the evidence machine, more errors you will have during the build when adding scripts that may not be compatible with other scripts, and more testing to ensure the build works as a forensic application.

3)  Colin Ramsden's method - The best of both worlds.  A little more manual effort to build, but runs well on older machines and is a solid build.   More details at http://www.ramsdens.org.uk/

Colin Ramsden updated his write protect applications and WinFE Lite files. http://www.ramsdens.org.uk

"WProtect application updated as a slight bug was preventing the user buttons from returning to 'active' under certain circumstances.

The Download page has been updated.
Full Package Zip (1.00, WProtect Application 1.0.0.155)
WProtect Application (1.0.0.155)
WinBuilder Script (4, WProtect Application 1.0.0.155)"

I'll be giving a presentation at the CTIN Conference in Seattle, March 2013 on forensic boot systems (Linux), with a strong emphasis on WinFE.   I'll be showing off Colin's light WinFE, WinBuilder's build, and Troy Larson's original build.  Hope to see you there.

After a colleague posed a question about building VMs from RAIDs, I thought it might be a good topic for a post.  I won’t go into RAID basics, as you probably have a good grasp of that topic already if you’re visiting my site.  The RAID systems that I see most often are RAID 0s, insofar as the system disk is concerned.  We’re not concerned about a box that contains a system disk plus any variety of RAID.

In addition to being RAID 0s, the systems that are most common in my shop contain two disks.  Frankly, I’d be a little hesitant about building a system on a RAID 0 with more disks because of the lack of fault tolerance.  For our purpose, it really doesn’t matter.  In fact, we can build our VM from a RAID 5 or even some versions of RAID 6, if we use the world’s leading forensics tool, X-Ways Forensics (XWF).  For this demo, I’m going to use a two-disk RAID 0.  The first step is to create an image of each disk.  For the original images, the format is irrelevant.  I say “original” because we’re going to create another image later.

As in most cases with XWF, there are a few (X) ways to approach a task.  Let’s say that you don’t know whether you have a RAID, so you simply add your images to your case, as in the following video.

We now have two raw disks in our case.  XWF also advised us that disk structure implies that a RAID may be present (the MFT message indicates the possibility of an implausible file record and likely is of no consequence).  A little exploration will confirm that a RAID is present, so we can proceed to reconstruct the RAID.

When we add disk images to our case, XWF intuitively offers them as physical and/or logical disks in further tasks, as in the Select Disk box that we saw in the video.  We see that our original disk images remain in our case, but it’s really not necessary to keep them.  In fact, we didn’t have to add them when we created our case.  For example, during the original imaging process, we could take a look at the original disks through our write blocker and determine that we have a RAID 0.  After imaging, we can mount each image as a physical disk with FTK Imager or the tool of our choice.

Note that our image files are mounted as PhysicalDrive9 and PhysicalDrive10.  We can now create a case in XWF and reconstruct a RAID right from the start, without adding images or media.

We begin by reconstructing a RAID, just as we did before.  We’ll see that Disks 9 and 10 are offered as candidates for RAID reconstruction.  After reconstructing the RAID, we’ll add it to our case through the context menu, as before.  Note, however, that we must have our images mounted as disks to access our XWF case in the future.  In the previous method, our image files usually are always in place.

You may recall that I mentioned stripe size in terms of sectors.  Many of us are accustomed to referring to stripe sizes in terms of kilobytes, e.g., 128KB, which is a common stripe size for RAID 0s. XWF requires stripe size to be expressed as a number of sectors.  It’s easy math to determine sectors by dividing the number of bytes by sector size, which usually is 512 bytes (but could be 4,096 bytes these days).  Also, “bytes” mean the exact number: 128KB=131,072 bytes, so 131,072/512=256 sectors.  Determining the correct stripe size may take a little research or trial and error.

We now can work our case in XWF as we would with a typical single-disk case.  If we want to build a VM from our image files, we should create a new image from the physical, reconstructed RAID.  From the XWF File menu, we select Create Disk Image, and XWF will present the following option box:

In the case tree, our RAID 0 is highlighted, and the viewer window is in Disk mode.  My Create Disk Image options box is set to create a Raw (DD) image of the physical disk, which is our RAID 0.  Once the image is created, we can create a VM from the image as we would with any image of a single disk system.  Is that’s easy!

We’ve come to the point where we can conduct a rather complete exam of shadow volumes using dd and E01 image files.  Let’s say that we don’t need to do such a complete exam.  For example, we’re confident that one, particular folder may contain previous, unrecovered copies of a small number relevant files.  Maybe we’re looking for one file in particular.  In those instances, we may not need to mount the shadow volumes.

We can accomplish this task in either our SEAT workstation, in which we added a virtual disk of the target system, or in a running VM of the target.  The latter approach is required for E01 images and optional for dd image files.  You also can accomplish this with the VHD method that I presented earlier.  The approach is the same regardless of which method you choose.  Remember, however, that using a “live” VM of a system runs the risk that the system will delete old shadow volumes.  The risk can be overcome, but keep it in mind.

To demonstrate the procedure, I’m going to use my SEAT workstation, in which I added a virtual disk.

It’s that easy!  Note, too, that you can invoke Windows Previous Versions on almost any file or folder.

In my example, no previous versions existed.  If they had, we would have seen a list of earlier versions by date.  We then could open and examine any available version of the file.  Should you find files of value in the approach that I presented, you can copy the files from the VM to your host system.  Copying is seamless if you install VMware Tools in your VM.  Otherwise, you can enable a shared folder with your host.  Any such copy operation, however, is not a forensic recovery, so consider whether it suits your needs.

Now that we have a quick and easy approach to a limited review of shadow volumes, don’t become too accustomed to using it into the future.  Windows 8 seems to have done away with the Previous Versions aspect of the Volume Shadow Service.  In my tests of the latest Windows 8 Enterprise edition, it’s gone, and I believe that this has been confirmed on MSDN or similar forums.  We can take heart, however, in the fact that shadow volumes remain; at least for the time being.

Just when you thought WinFE development was done....

Troy Larson (developer of WinFE) has created a cmd script to create a WinFE from Windows 8 RTM.  It is available for download in the Box.com widget to the right of this post, "Build_WindowsFE.cmd".

From Troy,

"Why use Windows 8 FE?

It will provide access to Windows 8 features, such as StorageSpaces.

It works well with X-Ways Forensics 16.7. It natively supports 4 KB sector hard drives.

It has support for other sorts of Windows 8 storage features, such as encrypted drives.

SAN Policy 4 (Offline internal)!"

Colin Ramsden's write protect script (for Winbuilder) and his Lite build of WinFE both work on Windows 8 machines too.  Windows (8) FE uses a new SAN Policy 4 registry setting.

Thanks to Troy, again.

Eric Zimmerman and Brett Shavers have started writing the "X-Ways Forensics Practitioner's Guide", due out toward the end of year 2013.

Check back as to when the guide will be available.   This guide intends to be the source of using X-Ways Forensics.

This posting is copied from www.reboot.pro, posted by Colin Ramsden on his final version of the WinFE write protect tool.  My thanks to Colin for his countless hours of work for which all of us will benefit.

As to the future development of WinFE, maybe this is it for some time to come.   Anyone can now build a Windows based, forensically sound bootable operating system.  Choices of a having simple, shell based system or a full-fledged Windows 7 visual experience as your forensic environment gives plenty of flexibility.  What more could you ask?

"I’ve just released WProtect version 1.0.0.154 (available on www.ramsdens.org.uk), which as far as I am concerned is no longer a Release Candidate, but the final version (less any new bug fixes or code optimisations).

I actually think that WinFE is the best free Forensic Boot CD that is available, I used it in anger (V1.0.0.151) for the first time today, the Ubuntu based Raptor disk would not work on a particular Acer machine where the drive appeared to be somehow locked to the machine (did not even register with the Tableau T35i when removed). WinFE along with FTK Imager Lite imaged the drive in the host machine flawlessly.

The latest update includes some suggestions from forum member ‘EM’ (a.k.a Boot_Monkey) which include a slightly longer forced delay between disk actions, a text change to the ‘close’ button (now ‘continue’) during the initial run and ‘greyed out’ buttons when the application is busy dealing with disks.

It’s been a long and sometimes hard project, which has involved loads of code being written and binaries that have had to be reverse engineered (over 2 years since inception), there have been many hurdles that have been encountered and overcome along the journey, the main of which, was the initial patching of the VDS.EXE binary which did not prove too popular with Microsoft that pretty much left WinFE dead in the water until some new API calls were exposed.

Anyway, we got here in the end. I would like to take this opportunity to thank the following individuals for their support, both past and present:

Troy Larson (Microsoft) for his assistance with the initial registry settings, which are still used for the initial write protection, without these, the disks would be touched before my tool got the chance to execute.

Brett Shavers for being the driving force behind WinFE, Brett has taken time out of his very busy schedule and strived to promote WinFE and keep it in the public eye through his presentations, user guides, testing and the WinFE web site on WordPress.

Karl Morton, a very good friend of mine who is an exceptionally talented individual, in fact he was one of the lead programmers on the Team17 game ‘Worms’. Karl was responsible for writing the initial backend code in the form of a DLL which was his own rendition of Diskpart, a brilliant tool, however, this was eventually defunct due to the VDS.EXE patch issue, nevertheless, Karl has still been a great contributor by helping me with converting undocumented C++ code to assembly language. Karl is also responsible for attempting to write the filter driver which I hope will eventually replace my WProtect tool, I will still code the front end though.

There has been other help along the way, by people such as Royal Mayer and Nuno Brito who initially helped me with adding my application binaries to the WinBuilder script language.

So all that I have left to say is hats off to the guys that I have mentioned and anyone else that has contributed along the way.

Thanks,

Colin."

If you try hard enough, you can circumvent just about anything.  That includes hard drive write protection, whether you are booting to a Linux forensic OS, WinFE, and sometimes, even when using a physical hardware write protection device.  There have also been many instances where write protection methods have unknowingly failed only to be discovered later.  This has occurred with several Linux forensics boot systems and at least with one commonly used hardware write protection bridge.

WinFE is not different in that it provides write protection when used appropriately.  Perhaps the most important word of advice when touching original evidence with any method of write protection is;

1)  don't mess with the hard drives

2)  don't mess with the hard drives

Particularly in WinFE, as has been discussed before, don't touch any other disk management tool besides the write protection tool to toggle your drives on/offline.

The safest bet is to not install any disk management tool in your WinFE builds, whether through Winbuilder or any other method. You don't need them anyway as Colin's write protect app manages disks much better anyway.  As long as you protect the hard drives, you have a great forensic tool, one of many that are in your forensic toolbox.

We’ve built our SEAT VM and added our target image to it as a virtual disk.  The first thing that I do is verify that all of the shadow volumes are present.  My first post presented a screen shot from the image file (MyImage) and depicted the shadow volumes.  We can compare the shadow volumes from the image file with those in our VM.  The following video presents the steps we use to enumerate the shadow volumes with the native vssadmin command run from our administrative command prompt.

The screen populates quite quickly, but the point is that we can identify the number of shadow volumes and their respective creation dates.  To make it easy to copy, here’s the syntax: vssadmin list shadows /for=[your target volume letter followed by a colon].  Note, too, that your beginning shadow volume number will be different from mine and does not necessarily start with the number one.  Another trick is to re-run the command and export the output to a text file, by adding a space at the end followed by >[path to your text file] [name of text file]. Creating a text file is handy for documenting your findings and for copying the shadow volume names, which we’ll do later.

Now we can mount any or all of our shadow volumes for examination.  We’re going to use VSS, which is a free, command line tool written by Dan Mares, who is a creative, long-time forensic software developer and examiner.  Dan also has developed free tools that are adjuncts to X-Ways Forensics and which help users customize certain reports.  You can pick up a copy of VSS at http://www.dmares.com/pub/nt_32/vss.exe.  Be sure to check for updates, as Dan is great about implementing suggestions.  You’ll also want to check out his other tools.  http://www.maresware.com/.  Thanks, Dan!

There are a few of ways in which we can use VSS.  We can mount one shadow volume; multiple shadow volumes that are numbered consecutively; or multiple, non-consecutive shadow volumes.  The following screenshot displays the syntax.

We already have a list of shadow volumes produced by vssadmin.  It’s now a matter of selecting the correct volume to provide to VSS.  Let’s go back to an abbreviated view of vssadmin’s output.  

The screenshot identifies one shadow volume.  It may not be terribly clear, but the shadow volume path is \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5. We’ll feed that path to VSS and mount the shadow volume.  We need only choose an unused volume letter, and we’ll pick H:

After executing the command, VSS will prompt us to hit <Return> one more time and then present what the screenshot depicts.  It includes the root directory listing.  Our shadow volume (#5) now is mounted as Volume H:  You can repeat that process and mount any, or as many, shadow volumes as remaining drive letters permit.

Hint: to repeat the process, use your up-arrow and simply replace the volume letter and shadow volume number (#), i.e., ShadowCopy[#].  There is no need to copy/paste the entire path repeatedly.

Next, we’ll mount a range of shadow volumes.  First, let’s look at the syntax, which is provided in VSS’ on-screen help.

We can start with a given shadow volume and mount every shadow volume that follows, up to our choice of the last shadow volume number.  In our case, there are 19 shadow volumes and the first is #5.  (I haven’t researched the question of why shadow volume numbers often start at a number greater than #1, but it doesn’t appear that it’s because there were X previous ones.  Windows authority Troy Larson probably knows!)  Before we go forth, I want to point out that you should study the dates of the shadow volumes in relation to your case.  Several restore points can be created on the same day, perhaps within hours of one another.  You’ll cut your exam and VM overhead if you exercise some judgment in picking the shadow volumes to mount and examine.

For demonstration purposes, let’s mount them all. I’ll start with no shadow volumes mounted and enter, vss h: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5 23 AUTO.  Note that AUTO is upper case.  The first shadow volume is #5, and the last is #23.  Watch:

Actually, it was coincidental that I happened to have 19 shadow volumes and 19 open, consecutive drive letters   To unmap any or all of our shadow volumes, we proceed as in the following screenshot.  I’ll unmap them all.

Following the VSS command, you enter every volume letter, followed by a colon, which you want to unmap.  If unmapping seems to hang, just refresh your screen in Explorer with F5.

That’s it for this post.  Next time, I’ll demonstrate one or two exam approaches with X-Ways Forensics. In the meantime, if you get bored, you’re all set to examine your shadow volumes with any tools that you wish to install in your SEAT workstation.

12 comments

1. Working with Shadow Volumes

   January 21, 2016 at 1:26 am

   […] shared it.  In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system.  At the time that I did […]

   Reply

2. Doing Analysis

   January 21, 2016 at 1:16 am

   […] where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:, which […]

   Reply

3. Windows forensics (A.Carvey) | Jacques DALBERA's IT world

   December 3, 2015 at 1:48 pm

   […] where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:, which […]

   Reply

4. Raffael

   August 23, 2012 at 4:17 am

   Jimmy,
   How do you examine VSS on deleted/recovered partitions?

   Reply

   • jimmyweg

     August 23, 2012 at 8:34 am

     I’ll have to guess, as I haven’t done that. First, I’ll say that you can’t examine deleted shadow volumes, AFAIK, and I tried. For example, you can recover a deleted SV and copy it into the Sys Vol Info directory. That doesn’t work, and may screw up the shadow volume service. Remember that the SVs are difference files, and the “index” has to track the SVs as a whole to rebuild things. Throwing in a “foreign” SV seems to mess up the system.

     If you can recover a deleted, intact partition, I suspect that you can image it and create a VM or VMware virtual disk from the image. If you can do that, you can probaly add it to your SEAT workstation and see whether the VSS can rebuild the SVs. You also may be able to rebuild the entire physical disk (image) and boot the previously deleted partition.

     Reply

     • Cal

       May 8, 2016 at 2:53 pm

       Hi, nice blog!
       What about an old snapshot of the same, working partition? I mean, every once an older shadow copy is deleted to create a newer one, due to space constraints to the VS service; however, sometimes a deleted snapshot can be recovered with a raw access to the disc, and .LOG# files in Sys Vol Info dir should hold some infos on syscache.hve changes.

       I wonder if there is a mean to verify integrity of such a recovered shadow and to access it.

       Reply

       • jimmyweg

         May 9, 2016 at 8:43 pm

         The snapshots depend on linking. After deleting snapshots within a VM, VMware typically has no problem with running the VM from any given snapshots. Forensic tools, however, may be unable to mount the successive snapshots because of linking issues, I suspect. I’ve found it rather difficult to gather much any data from deleted (recovered) VSC, because the dependencies are lost.

         Reply

5. Ken Pryor

   July 15, 2012 at 6:10 pm

   I’m really enjoying and learning a lot these tutorials, Jimmy. Thanks for sharing!
   KP

   Reply

6. Raffael

   July 15, 2012 at 12:28 am

   Hi Jimmy
   Thanks for your work!
   I usually mount disks with Encase PE. This allows to access VSC directly in my workstation (no vm). This approach does not work if you use Ftk Imager or Mount Image Pro .

   Looking forward to reading more of your posts!
   Raffael

   Reply

   • jimmyweg

     July 15, 2012 at 4:37 pm

     Thanks very much, Raffael. Correct, mounting with FTKI or MIP will not provide access to the SVs. I don’t use EnCase, so I can’t speak to this feature, but it does seem handy. Another approach, which I’ll describe in a leter post, is mounting a VHD image. The drawback is that you have to create a VHD. If you do, however, you can access the SVs right from your host system.

     Reply

     • Harlan Carvey

       July 16, 2012 at 4:20 am

       Jimmy,

       I’m not sure how I follow that creating a VHD is a “drawback”, per se. Analysts work on a copy of the acquired image, and not the original “evidence”, and the free tool available from MS simply appends a footer (less than 1K) to the image in order to turn it into a VHD. Once you’ve done that, you can still access the acquired image via FTK Imager, etc.

       Thanks for posting this information…it’s great to see more of this sort of thing making it into the public view. Keep it up…

       Reply

       • jimmyweg

         July 16, 2012 at 10:19 am

         Thanks, Harlan. Yes, converting the dd to VHD actually is quite simple with VhdTool. In my approach, I use the original image, which is not altered. If I want to convert the image to VHD, I guess that I would make a copy for that purpose, unless you can convert the VHD back to dd, but then you’d want to hash the original again. So, although I do have one or two backups of every dd (as E01) image, having to make another to convert to VHD is something I’d rather avoid. You can build your VMware device in less than one minute. Perhaps someone may develop a tool to image a medium directly to VHD with the approriate verification, something like E01. AFAIK, that’s not do-able at the moment.

         Reply

In civil litigation, the procedures for data collection are a little more relaxed as compared to criminal investigations, but cost is a huge factor.  Typically, criminal suspects lose custody of their seized systems and won't necessarily cooperate with the seizure of electronic evidence.  Civil litigants on the other hand, will usually maintain custody of their systems and cooperate with the data collection.   With the costs of travel to simply image a hard drive or copy a folder, one hard drive can cost a client thousands of dollars in expenses.

But here is a neat trick.

1)  Ship the custodian a customized WinFE CD and an external drive.

2)  Over a phone call, walk the custodian (or IT staff) in booting the system to WinFE and plugging in the external USB hard drive.

3) Access the forensically booted drive remotely to image directly to the supplied USB external drive.

The external drive can be shipped back to you overnight. You can accomplish in minutes what would take hours and thousands of dollars (air-ground travel, meals, lodging), all without leaving the office.

There is more than one method of accessing the booted WinFE system remotely, either through Remote Desktop, VNC, or any number of commercial applications such as TeamViewer.   Any of these methods allow for you to take control of the custodian system (in the WinFE OS), and run just about any Windows based forensic application to forensically image the custodian hard drive to the USB external drive.  Or you could create containers of targeted files/folders.  Or you can triage the computer to determine if it needs to be collected.

Should you decide to save your client or company thousands of dollars per case, here are some tips when using this WinFE "remote" collections method:

1)  Build your WinFE with the forensic apps you need (FTK Imager, Encase, etc..).

2)  Have a one-click connect icon on the desktop for the custodian to start the remote connection.

3)  Run a system information application on the custodian machine (WinAudit) to identify the hardware in the system.  Maybe even have the custodian or IT email you a photo of the system being imaged.  Store the hardware scan with the image file.

3)  Create two images (one to be shipped, one to be maintained at the premise in case the shipped image is lost in transit).

In practice, you can connect to as many WinFE booted computers as needing to be imaged, one after another, all imaging to external hard drives.

Of course, not everything always works out as planned.

Custodian machines may not have a CD drive - ship a WinFE CD and WinFE USB together,  just in case....

Hard drives may be bitlocked-you can still access the drive for imaging through WinFE.   Other encrypted drives may be accessed too, depends on the setup of the system.

Custodian machine may be broken - might have to ship the entire machine or hard drive/s, but that's still cheaper than travel expenses.

No internet access for the custodian machine - you need this for this method to work....you could always ship a wireless card with the WinFE CD and external drive.

If volatile memory is required to be captured, like RAM, this isn't your best option or even a good option.  In fact, this is not the best 'live response' method at all.

And yes, this can also be done with many of the Linux forensic boot discs.  But is certainly much easier for the majority of custodians to use a Windows FE OS if their everyday systems are also Windows.  Plus, you can use just about any of your everyday Windows forensics applications.

[caption id="attachment_657" align="aligncenter" width="640"] Well, you may miss out on traveling on the client's dime, but your client will be happy (that's the goal anyway, isn't?).

This may not be good news for anyone wanting to make easy money with travel, but in the long run, your clients (and boss perhaps) will appreciate the savings and speed at which this can be done.  You'll also be to get more done in a shorter period of time.  That is a good thing.

In this step we’ll add our target system virtual disk to our SEAT VM.  We already have the target (MyImage) virtual disk that we created, and we’ll add it to our system as in the next video.

Add Virtual Disk

As you saw, we chose to add the disk as an independent disk in non-persistent mode.  Any changes to the disk are discarded when we power off our SEAT VM.  Actually, as we’re going to examine shadow volumes, we’re not too concerned about routine changes that our operating system may make to volumes attached to our SEAT VM.  Nothing within the shadow volumes will be changed.  Remember, we’re not out to do a general exam; for that we can use our favorite tools on our image file.

When you add the disk, VMware may present a box that warns of a hardware compatibility issue.  If my SEAT VM was created in an earlier version, I’ll get the following warning.

If you encounter this, change your SEAT hardware compatibility as in the video.  Your hardware may differ from mine, but I bring my hardware up to my current version (Ver. 8).  Choose Alter this virtual machine as your last step.

We’re ready to boot our SEAT workstation and get our target ready for a shadow volume exam.  In Windows, we can see our target system as Volumes E:, F:, and G:  Your volume letters may differ as may the number of partitions on your target.

A little exploring reveals that our target’s system partition is Volume F:  While the last screen shot is right above us, I want to point out a very handy feature of VMware, which is the Pause button. You can see it in the screen shot as the two, vertical bars right below the File menu item.  Pausing the VM freezes the action.  So, if you have a number of tasks underway and don’t want to shut down your SEAT VM, just pause it until you want to return to work.  Remember, too, that the VMware Snapshot feature is your friend.

The first thing that I do is write protect the target system disk.  Even though the disk is non-persistent, it can be written to during our session.  It’s also possible that the volume shadow service may delete one or more of the target’s shadow volumes.  To write protect our target, we’ll employ Windows Diskpart, which is a command line tool that’s part of Windows 7.  In the next video, I’ll step through the process.  We’ll begin at the point where I entered the Diskpart shell.

Diskpart

To exit Diskpart, simply type the command exit. Note that the write protection survives a hot or cold reboot.  Nevertheless, you don’t have to shut down your SEAT VM, unless you want to make certain changes to its configuration in VMware.  Otherwise, you simply can use the Pause feature.  Should you want to remove write protection, go through the steps in the video, but enter the command attributes disk clear readonly as the final command.

That’s it for now.  In the next post, I’ll get down to mounting and accessing the shadow volumes.  Thanks for visiting!

3 comments

1. Gerald

   July 10, 2012 at 7:31 am

   Jimmy,

   Hello, great series and info. Have you experimented with using the SIFT to make all .E01, .AFF or .RAW images available to the Windows Forensic box for Volume Shadow analysis? I have found it to be extremely quick to set up and reliable (takes about two minutes). Successive exams are faster to setup. Corey Harrell did a posting on how to do that here: http://journeyintoir.blogspot.com/2012/05/more-about-volume-shadow-copies.html

   Reply

   • jimmyweg

     July 10, 2012 at 9:08 am

     >Have you experimented with using the SIFT
     I haven’t. I do have SIFT, but I’m kind of linux-averse. It’s great stuff, but I like my GUI. I’m curious about the iSCSI approach, and perhaps it will work in my Windows-based VM. I’ll have to experiment. As I mentioned, I can make this work with E01s, but it’s a little more work. I started down this road because I received quite a few remarks about problems with EnCase PDE and LiveView. I don’t use EnCase, so I can’t attest to any issues, but I did play with LiveView and prefer my “hand-built” approach. My aim, which will become a little clearer as I progress, is to do a SV exam with X-Ways Forensics. You can use any tool as long as it will run in a VM. For that matter, you can do the same thing directly in the running VM of the target that we bulit in my first post. XWF can be run from a thumb! You also can add the target virtual disk directly to SIFT through VMware. You’ll have to let me know what you think as I proceed. Thanks.

     Reply

     • Gerald

       July 10, 2012 at 9:45 am

       >I’m curious about the iSCSI approach, and perhaps it will work in my Windows-based VM. I’ll have to experiment.

       Absolutely it will work to access VSCs. Just make sure your Win forensic box is on the same subnet as the SIFT workstation. Send me an email at This email address is being protected from spambots. You need JavaScript enabled to view it. and I will send you back a short PPT on the method. Should save you a bit of experimenting time.

       Reply

We now have built a virtual machine from an image of the target system.  Next, we’ll build a Windows 7 VM and configure it as our examination platform: Shadow Examination and Analysis Technique (SEAT) workstation.  Building the VM basically is the same as installing a operating system from scratch, and I’ll  go over the basic steps in the following video.

Build Base VM

I installed Windows 7 Ultimate 64 from a DVD, but you can use an ISO instead of a disc.  I have a library of operating systems on ISOs, as they come in handy.  Please be mindful of licensing requirements.  I didn’t install a network adapter, but will do so later.  I use as much RAM as I can afford, and you can experiment.  RAM can be adjusted from a powered off state.  I like using a single, growable disk for my VM.  For the most part, I set up the system as I like.  I turn off User Account Control, but we must leave System Protection enabled.  I also set my folder view options to allow access to hidden and system files.  Remember that you can use snapshots to protect the state of your VM.  Below is a screenshot of my VM.  I keep my frequently used tools on the desktop.  Be sure to include a shortcut to the command prompt, and be set it to run in administrator mode.

For you X-Ways users, you can configure your options as you do normally.  Be sure, however, to set the option to run XWF as administrator by default, and allowing multiple instances is suggested.  Remember that XWF, as most forensic suites, is USB dongle based.  When you want to work with XWF in your VM, you must connect the dongle to the VM as in the image below.

 If you have more than one Feitian dongle as in the screenshot, you’ll have to experiment to find the correct dongle.  Then, connect it to the VM (Disconnect from host).  Note that, if XWF is running in the host system, it will become aware that the dongle was disconnected and issue a notice.  The easiest thing to do is close the host instances of XWF before you work in the SEAT application.  Of course, if you have more than one dongle, you can work simultaneously in both environments.  Note that you can install any USB devices that you wish by using the same procedure.

Note, too, that our SEAT workstation is portable. At the moment, my VM is about 18GB, so it’s easily copied to another forensic workstation or USB drive.  In the next post, I’ll review how we mount the target VM in out SEAT workstation and begin an exam.

4 comments

1. Derek Frawley

   August 3, 2012 at 11:05 am

   Thanks for the vm creation tutorial.
   Do you have anything that will show how to do with E01 file(s) or multiple raw files.( as mentioned in the tutorial) Most of the images i have are E01 and takes too long to re-image.

   Reply

   • jimmyweg

     August 3, 2012 at 12:32 pm

     I’ll add a post on E01s this weekend, if I have time. In any event, I’ll do that next. Thanks for the comment and suggestion!

     Jimmy
     http://JustAskWeg.com/

     Reply

2. Scott Koehle

   July 9, 2012 at 7:03 pm

   Great Stuff, Jimmy. Thanks for taking the time to put this website together. Very Helpful.

   Scott Koehle, CFCE
   Altoona Police Department
   1106 16th St
   Altoona, PA 16601
   814-932-2588

   Reply

   • jimmyweg

     July 9, 2012 at 9:15 pm

     I’m glad that it’s helpful. If you enciunter any issues, please let me know.

     Reply