Build questions

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
Rate this blog entry:
821 Hits

WinFE updated

Colin Ramsden updated his write protect applications and WinFE Lite files.

"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
WProtect Application (
WinBuilder Script (4, WProtect Application"
Rate this blog entry:
716 Hits

WinFE Presentation

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.
Rate this blog entry:
1081 Hits

RAIDs & Virtual Machines

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!

Rate this blog entry:
669 Hits

Getting a Quick Look at Shadow Volumes

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.

Rate this blog entry:
571 Hits

Windows 8 and WinFE

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 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.
Rate this blog entry:
971 Hits

X-Ways Forensics Practitioner's Guide is coming!

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.

Rate this blog entry:
1181 Hits

Colin's Final Version of his write protect application

This posting is copied from, 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 (available on, 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.


Rate this blog entry:
1639 Hits

A little reminder about 'write protection'

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.
Rate this blog entry:
759 Hits

Mounting Shadow Volumes

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  Be sure to check for updates, as Dan is great about implementing suggestions.  You’ll also want to check out his other tools.  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.


  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 […]


  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 […]


  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 […]


  4. Raffael

    August 23, 2012 at 4:17 am

    How do you examine VSS on deleted/recovered partitions?


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


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


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


  5. Ken Pryor

    July 15, 2012 at 6:10 pm

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


  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!


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


      • Harlan Carvey

        July 16, 2012 at 4:20 am


        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…


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


Rate this blog entry:
1577 Hits