Amazon reduced the price, grab it while you can before it goes up (again).
Update November 14, 2014
Unfortunately there are so few updates nowadays to WinFE, that this blog is woefully neglected...on a positive note, since WinFE practically needs no updates, there is hardly a need to keep up on WinFE once you have mastered building it.
The best and most current source of all-things-WinFE is from a free online course at http://courses.dfironlinetraining.com/windows-forensic-environment so other than taking the course, this blog will not have additional information building WinFE.
The course includes downloads and links to downloads to build every publicly known version and build type of WinFE, from the basic WinFE, WinFE Lite, WTE WinFE, Mini-WinFE, and WinBuilder WinFE.
The WinFE wordpress blog will be used only for sporadic WinFE updates and related information since WinFE has practically reached the best it can be at current software standards (Windows 8). The only posts that may be original from here on out would be case examples, but that quickly grows old (I booted a machine to WinFE and imaged it...). A few instances are very neat, like imaging a Surface Pro, and for those interesting cases, I'll post them as I come across them or am sent information about them.
At its foundation, WinFE is a strong forensic OS platform, built on the latest Windows operating system, which can run most types of forensic software. That's about it. Simple, but amazingly effective at a forensic boot platform. Since it is so very simple, the updates to the WinFE blog become less and less. Therefore, the free webinar course covers everything you need to learn about WinFE along with every download needed, plus tips on building, using, and testifying to the use of WinFE.
After you view the course and build a few WinFEs, you'll see that WinFE is only a forensic boot OS. But you will also see that because it is a Windows boot OS, you can do so many things with it that you can not do with a Linux forensic OS or with a hardware writeblocker. That is the beauty of WinFE. Simple. Ingenious. Hard to improve upon (at this point...).
You have my permission to use the WinFE course and its materials in a manner that benefits WinFE at no cost. That means you can use information from the course to teach WinFE at conferences or any training session. WinFE is free (technically, you need a Windows OS license...but otherwise its free), and I've made the course free as well. When teaching or writing about WinFE related to the source and you choose to attribute to the source, that's nice of you, but not necessary if you don't want.
Take a run at the WinFE course. Watch all the videos or only the videos of interest. They are broken down by build types and how-to videos. The most important benefit you can get out of the course (other than learning how to build/use WInFE) is getting some formalized training in front of you about WinFE. It's one thing to spend hours (days?) figuring out something but quite another when you can get the meat-and-potatoes of what you need to know in the shortest period of time. I'd reckon that even if you attend a presentation on WinFE, you will get so much more out of the online course that you won't regret the time spent.
I've also said a few times, that once you build and use a WinFE, you will regret not having done so years earlier. Don't forget, WinFE has been around since 2008...it works even better now than back then.
Hashbrown program 64 bit version only http://1drv.ms/1tLsNnG updated October 10 2014
Cool WInFE work done by Jeffrey A. Cunningham, Sr Digital Forensic Examiner, US Army (ChiefCham), on imaging a Surface Pro using a bootable UEFI WinFE. It is certainly neat to see this type of testing and research done on ANY forensic tool where the results can be shared with everyone.
Image a Surface Pro using bootable UEFI WINFE
Every now and then, I get email from readers who have difficulties, and some areas come up more often. I also learn a few things as time goes by, and I gain some valuable pointers from colleagues who share my interests. Therefore, I want to update or amend a few procedures as well as review some of the more basic steps that folks may overlook.
A little while back, I posted on building VMs from UEFI/GPT systems, found most often in Windows 8. Since then, I’ve seen more of these outfits arrive in my shop, as the use of Windows 8 and large disk grows. If you document your target system before an exam, which requires accessing the setup in most cases, you’re sure to recognize that the setup doesn’t resemble the BIOS of old. There’s a sample screenshot in the above post. Even if you dive straight away into your exam, you’ll find a clue when you study the partitioning of your target image file:
X-Ways Forensics users will receive the answer to the clue without having to guess. The GPT partitioning style with the four partitions, including the MS reserved partition, mean that you have a UEFI system. The FAT32 partition likely holds your EFI boot data:
The first reminder is that we usually must edit the registry and at least one user’s password to boot into Windows 8. Since the beginning of my blog, I described how to build your VM by selecting the option for a SCSI disk in VMware.
That option required an edit to the registry to enable the LSI SCSI service to start on boot:
After mounting our VM, we loaded the target’s System hive into our own registry. We navigated to the proper control set’s Services key and then to the LSI_SCSI subkey. There, we edited the Start value’s data to 0x00, as above.
Well, what happens if you find a System hive that looks like this:
As you can see, there is no LSI_SCSI key. If you find this to be the case, you have a couple of choices. You can start over and select the LSI Logic SAS option as in the Virtual Machine Wizard screenshot above that displays the controller types. Then, edit the registry by setting the first LSI_SAS controller’s Start value data to 0x00. A quicker alternative is to edit the mounted registry hive and your VMX file by replacing the highlighted line the next screenshot with the one that follows. Of course, if you examine the target registry in your forensic tools you can determine the configuration before you even consider building a VM.
Replace the above parameter with this one:
Please don’t forget to insert the firmware = “efi” parameter that I described in earlier posts! If you edit the VMX and your VM hangs, reboot into the Boot Manager, which you usually can access by pressing F2 a few times during the boot process. There, just select the virtual VMware Virtual SCSI disk and hit Enter.
Back here, I described the Windows 8 feature that allows users to log on to their systems with MS Account credentials. This feature allows both local and online logon. The required password strength makes a hash attack a little more difficult. However, the most important thing to remember is that, to gain access to the system, a password is required. You cannot “blank” the password using tools like the Linux-based boot CD or NTPwedit. You must change the password. Although some tools ostensibly allow you to change the password, I’ve found that they fail in that regard. I still know of only one tool (commercial, but cheap) that works: Reset Windows Password (RWP), which is available at http://www.passcape.com/reset_windows_password and produced by Passcape Software. I described its use and a UEFI workaround process here.
The workaround arose from the need to edit the password on a UEFI/GPT MS Account system with a tool on a bootable ISO/CD. In hindsight, I should have suggested a quicker approach, which I will describe here. As seen in one of the above screenshots, we edited our VMX file to enable the EFI firmware. Passcape’s RWP is not yet available for use on a bootable UEFI, USB device. So, if you use RWP or any tool on a bootable ISO, you need to re-edit your VMX as follows:
Once you re-edit the VMX file, you can boot to a non-EFI medium. Just remember to change it back to EFI thereafter, or you system will not boot to Windows (“operating system not found” message). I’ll add that RWP also allows you to invoke regedit and several other utilities directly from within the application.
This is another topic that folks bring up occasionally. If we mount a shadow volume directly from an image or from an image that we boot in VMware, we’ll find that the shadow volume, itself, contains a System Volume Information (SVI) folder that contains shadow volumes. Let’s say that we mount a shadow volume that was created on October 1, 2014, and was the earliest shadow volume in our target system. When we look in the SVI folder of that mounted shadow volume, we may find a shadow volume that was created on September 1, 2014. Now, it seems logical to assume that we can mount the latter shadow volume and go back in time even further, perhaps to the date when the system first was used. We can’t. I’ve tried a few approaches, including running vssadmin against the mapped shadow volume and attempting to boot the mapped shadow volume. Neither method worked. I wasn’t able to boot a shadow volume, even by reconstructing a physical disk with that volume. I also ran this theory by one of the world’s leading Windows forensics experts, Troy Larson, who, not surprisingly, thought about this concept long before I did. In short, Troy suspected that the shadow volume files and other data within a mounted shadow volume were incomplete and could not be reliably processed by the system. Remember that shadow volumes really are “difference” files that depend on one another, and inconsistencies in any of them can affect their functionality.
NOTE: I’d like to direct readers to the comment posted by Joachim Metz. He’s done a great job of documenting shadow volumes and provided a link to a paper that he published. His comment and paper may provide the precise answer.
For those who want to play around with UEFI, VMware has preview edition available that affords some undocumented (buggy) enhancements, so be careful if you give it a shot. That’s all for now.
The recent release of USB malware, in which any USB device is suspect of being infected after plugging into an unknown-if-clean machine, makes a problem for bootable USB devices in forensic collection. Some of the very scary claims to the USB malware are (http://news.discovery.com/tech/gear-and-gadgets/warning-usb-malware-code-unleashed-141006.htm):
That is bad stuff for a forensic bootable USB device. I've seen a few suggested solutions to the USB infection issue, but the fastest solution with WinFE is to burn to a CD/DVD instead of making a USB bootable. Problem solved.
Building a WinFE is still very very very very easy. Using the Mini-WinFE build, I just timed creating a WinFE DVD is less than 6 minutes. That was a few minutes with Winbuilder and a few minutes burning the ISO to DVD, while taking my time in the short process. If you haven't yet built a WinFE, the process is almost completely automated. Just point Winbuilder to your Windows 7/8 source and press go. Less than 5 minutes later, you have a forensically sound, bootable ISO/CD/DVD/or USB.
Granted, creating a WinFE CD/DVD in less than 10 minutes is not going to save you time compared to imaging a removed hard drive using a hardware imaging device. But...if you have LOTS of machines to image, booting the machines to be seized to WinFE most likely will be faster than removing hard drives and sharing hardware imaging devices. And for those pesky drives that won't come out, WinFE may be a good solution than fighting with an ultralight, can't-find-the-screws-to-remove-the-darn-hard-drive machines.
New version of X-Tension
-adds the functionality to create a picture/video library.
-adds the ability to extract pictures or movies that are type status of 'not confirmed'
(this was added as there are so many variations of avi formats, that even some valid working movies were not 'confirmed')
If the user does not want these files, they can be filtered out and the X-Tension run excluding filtered or excluded files
This is the same as version 3.5.12.k except adds the function to create a CETS manifest XML needed for those using CETS.
Arnold will post information for CETS users regarding changes needed to properly use the X-Tension.
C4All X-Tension CETS compatible version 3.5.13.a
For use with CETS:
1. This will provide a generic "CETS Media Manifest.xml" file
2. This generic file will not include the digital signature InvestigationID, ManifestID, or CategorizationID. However, the CategorizationID can be added manually.
3. With the CETS Media Uploader you can "re-sign" the manifest file if you use "adminmode" of the CETS Media Uploader.
To enter into Admin Mode:
1. Right Click on "CETSMediaUploader.exe"
2. Select: Sent To, Desktop (create shortcut)
3. Locate the shortcut on your desktop
4. Right Click on the shortcut and select : Properties
5. In the Target Field append to the end of the line(after the closing "): -adminmode
6. Double click the edited Short Cut
When you launch the CETS Media Uploader in Admin Mode you will a new button to "Sign Manifest" file.
Clicking on the button will bring up a dialogue window to manually select a user and the related investigation.
Keep in mind, that you must manually cut and paste your Categorization settings into the XML file.
Canadian Police Centre for
Missing and Exploited Children.
Neat to see WinFE being taught everywhere, as in, everywhere by many. Wish I could have been there for this presentation (mostly because I'd have to be in Australia to see it...).
"The team will debut a new course topic in Dallas: Introduction to Windows Forensic Environment (WinFE). In this lab and lecture, investigators will learn how to create a bootable forensic environment on a thumb drive. Using this thumb drive, investigators can then conduct previews of suspect computers in the field, looking for information that indicates whether the computer contains potential evidence in a case. The ability to conduct on-scene triage such as this is very important to investigators, as it gives immediate information about suspects and their devices."
The WinFE online course will be updated sooner with a few neat things that are coming up with WinFE. Until then, there have been over 2,000 registrations for the course and more every day.
I'm impressed that there are so many users interested in using WinFE, but then again, not really. It's still a really neat tool to have in your toolbox alongside the Linux forensics boot OSs. If you haven't taken a look at WinFE, give it a try. This course will remain online, free, and updated when there are updates to make.
I am checking out WTE and so far, WTE represents a great enhancement on making WinFE more user friendly in appearance and use. I'll post my thoughts on WTE sometime in the future after I really take a look at WTE in more detail.
Speaking of online courses, if you regularly "google" people for investigations, backgrounds, pre-employment checks, internal investigations, or need to find someone as a witness (or suspect, or victim), take a look at my Advanced Internet Investigations Course with Google Hacks. If you register with this link (or this code: winfe50), you get 50% tuition. The half off discount is for the first 50 people, then regular price of $195. The course is a tad over 4.5 hours and covers enough information where you can practically find anyone online, and in the physical world. Google operators, syntax, and hacks are covered including automated searching utilities (free software!).
[caption id="attachment_1262" align="alignleft" width="700"] Half price for the first 50 WinFE blog readers.
Ken Pryor wrote a kind review of the WinFE online course. Take a look at his blog for details.. http://digiforensics.blogspot.com/2014/07/windows-forensic-environment-training.html
Don't forget, the WinFE online course is just like WinFE...it's FREE!
Misty has updated Mini-WinFE. There are a few very neat updates, like UEFI support! Don't forget to sign up for free WinFE online training: http://courses.dfironlinetraining.com/windows-forensic-environment
Thanks to Misty!
2014.07.03 ========== * SysWOW64 support added when building from Windows 7/7(SP1)/8/8.1/8.1 Update 1 sources (should also work with some Windows Server 2008/2012 sources). The 5-Wow64 script was used as a base to identify file and registry dependencies. Credit therefore goes to everyone involved in the 5-Wow64.script (including JFX, Lancelot, 2aCD, ChrisR and "...to everybody on the BootLand forums for helping on the debuggind and improvement of this script."). Select 4] SysWOW64 in the main project script options to add SysWOW64. * UEFI support has been added. * CloneDisk script added * Virtual Keyboard (FreeVK) script added. * A number of changes have been made to the core script - wimlib-imagex now uses file lists when extracting dependencies from install.wim/boot.wim. This significantly improves build time, but has meant that any program scripts containing paths for file dependencies has required editing due to wimlib preserving directory structure (when extracting from file lists). * Fixed a bug when x64 local sources are used (in Create a cache from WinRE and the ADK scripts). Due to the way in which SysWOW64 redirects to the \Windows\SysWOW64 directory when running WinBuilder on a 64-bit system the file dependencies were being cached from \Windows\SysWOW64 instead of \Windows\System32 * Wimlib updated to 1.7.0. The amended update add command significantly reduces build time when the INJECT method is used. * Create ISO script updated. It now contains several options including Flat Boot and RAM Boot or multiboot RAM and Flat boot. It's also possible to create a BIOS or UEFI bootable ISO - or BIOS and UEFI bootable. * Create USB updated to include the option to RAM Boot or Flat Boot or multiboot RAM and Flat boot. UEFI support is also included. This script will not work if running WinBuilder on a Windows 2000/XP/2003 system. * Create USB (GPT UEFI) script added. This script will not work if running WinBuilder on a Windows 2000/XP/2003 system. Only fixed type disks are supported. * Added error check to the ADK For Win 8 (and 8.1) scripts - these cannot be executed if running WinBuilder on a Windows 2000/XP/2003 system. * Project.Settings.ini is added to the build listing all programs and project settings used in the current build. * Project documentation updated - minor updates throughout and two new sections added (MultiBoot WinPE and UEFI, BIOS, GPT and MBR) A special thanks to alacran for requesting UEFI and SysWOW64 support in MistyPE and for beta testing and feedback to actually get them working. Due to the number of changes made in this build it is entirely possible that errors may have unintentionally crept in. Please report any issues (or positive feedback) on the support topic at reboot.pro - http://reboot.pro/topic/19036-mini-winfe/ 2014.04.26 ========== * Added a number of additional options in the core script - these are all enabled by default. The new options will remove a number of unsupported options from the right-click context menu. Thanks to reboot.pro forum member farda for these suggestions. * Added "Open with" workaround for WinPE 4.0/5.0. See - http://reboot.pro/topic/19732-help-with-open-with-in-winpe-4050/ * WinFE settings are now seperate to the Shell script - but are still mandatory. They have been moved to a new script \Programs.winfe.script * Option to use either SANPolicy 3 or 4 (in new WinFE script) - SANPolicy 3 is automatically used with WinPE 2.*/3.* sources as SANPolicy 4 is only supported in WinPE 4.0/5.0. * File dependencies (to be extracted from install.wim or copied from the host Operating System) are handled in one (hidden) script - Core\required.files.script. This will make it simpler to implement any future file dependencies. * Added a script to copy files and folders from a local directory - allowing the easy addition of third party files. A menu entry will open the directory these files were copied to. * Added Tools\Create USB script - it's now possible to create a MistyPE bootable UFD during the build process. Use with caution - see documentation for more details. Tested with Windows 7 (SP1) and Windows 8.1. * Added ADK For Win 8 (and 8.1) scripts. Refer to documents. NOTE - this has only been tested using Windows 7 (SP1) and Windows 8.1. * Wallpaper support (.jpg) added for all builds - this feature was not previously working with WinPE 4/5. See Programs\Wallpaper script. * Wimlib-ImageX updated to version 1.6.2 * Added build 6.3.9600 (Windows 8.1 - Final) to the list of tested/working sources. * Added the following scripts - - WinHex - DMDE - Opera - 64-bit support added. - Keyboardlayouts * Included FAU in the download. This is redistributed with the permission of the author (GMG Systems Inc) - refer to the project documentation. * Program scripts now contain menu entries - this should make it easier to add new program scripts. Previously all menu entries were contained in the shell script - resulting in multiple script edits for any new programs added. * Various tweaks in core script - "FileDelete,"%Cache%\temp\*.*" has been added to to ensure that cached batch files and .ini files are deleted earlier in the build process. Without this fix there are errors in some very limited curcumstances. - Added verification check from registry files extracted from boot.wim - only used if the wimlib-imagex checks fail. * Script structure has been changed for all Program scripts. Hopefully results in better error checking for any missing files. * Browse for folder support is added by individual program scripts even if this option is not selected in the Core script. Resulting in a more modular approach (see "http://reboot.pro/topic/19042-modular-apps-philosophy-for-winpe/" for the philosophy behind this approach). * Documentation updated - added section on using the ADK For Win 8.1.
I created an X-Ways Forensics online training course at http://courses.dfironlinetraining.com/x-ways-forensics-practitioners-guide. This course, X-Ways Forensics Practitioner's Guide Online I is introductory to using X-Ways Forensics, but it covers more than enough to cover most of the use of X-Ways in a case.
The XWF II course goes into great detail with more information on using XWF in different scenarios and some more highly specific functions. Although the course is based on the book, it is not the book, nor is it the X-Ways Forensics classroom training. It is however, the least expensive and fastest way to get up to speed on X-Ways Forensics :)
There is a 25% discount code you can use "xwf1" that is good until July 17. Everyone that registers before July 17 receives a separate discount code of 100% for the XWF II online course that will be released as soon as this discount period ends. Both courses are the same cost, but the discount is valid only until July 17.
If you can't attend the X-Ways AG classroom training due to cost or time, this online training fits both your pocketbook and daily schedule.