The Windows Forensic Environment (a.k.a. WinFE) is a Windows based bootdisk that can be used as a platform for computer forensic analysis. Being Windows based it enables users to run a number of Windows programs that they might already be familiar with. It is an alternative or addition to a number of forensically focused Linux distributions.
WinFE is not, as far as I am aware, available as a commercial product from Microsoft. It is however relatively easy to create WinFE for personal use from freely available tools.
Troy Larson, Senior Forensic Examiner of Microsoftİ, is credited with creating the Windows Forensic Environment. A Guide to Basic Computer Forensics is available here and is worth reading for those new to the subject.
WinFE is in essence a Windows Preinstallation Environment (WinPE) with two minor registry edits that are applied to ensure that any hard disks are not automatically mounted during the WinPE/WinFE boot process - minimising the risk of the contamination of data/evidence. WinFE is a lightweight version of Windows that can be used for many tasks - it is a complete, standalone operating system and will work independently of any other operating systems already installed. See here for a summary of WinPE - much of which applies to WinFE.
For more detailed information about WinFE, please refer to "The (Nearly) Perfect Forensic Boot CD" by Brett Shavers (available here).
The CyberSecurtiy Institute states that "...When performing a computer forensics analysis, we must do everything possible to preserve the original media and data...". Preservation of data is one of the core requirements of computer forensics and steps should be taken to ensure that evidence is not contaminated. Although this might not always be possible, accidental writes to evidence should be avoided. Hardware write blockers are often used as a means of ensuring data integrity by preventing accidental writes from occurring.
WinFE is a software based solution, however there are conflicting reports that WinFE might write to a hard disk without any user interaction, prior to any commands being executed. The majority of these reports indicate that WinFE writes a disk signature to the master boot record (MBR) of any attached hard disks if one is not already present - this reportedly occurs during the boot process.
In order to get some clarification about whether WinFE performs any accidental writes I started a discussion/topic on the reboot.pro forum - "Is WinFE Forensically Sound?" (see here). The purpose of this was to try to establish in what circumstances, if any, WinFE might write to a hard disk. Although the writing of a disk signature does not in itself invalidate any evidence gathered when using WinFE, I wanted some clarification about this poorly documented behaviour. I also wanted information about real world experiences of using WinFE and in particular incidents of unplanned disk writes, so that they could be avoided in future. Knowing in what circumstances WinFE might write to a disk allows steps to be taken to prevent this from (re)occurring.
Sadly there appeared to be little publicly available information and the responses I received were vague. I therefore decided to undertake my own tests. This was encouraged by a fellow reboot.pro forum member and has led to this document - credit therefore goes to Wonko the Sane for his support and encouragement with my research.
I still find it strange that in a field that focuses on strict procedures for the gathering of evidence to ensure data integrity, little testing appears to have been done on the tools used to actually gather the evidence. I am in no way anti the use of WinFE - I just find the vague and conflicting reports frustrating and unacceptable, and hope that this document can provide some answers.
As WinFE is essentially a Windows Preinstallation Environment (WinPE) with two registry modifications, there are at least seven builds/versions of WinFE - all available in both 32-bit and 64-bit processor architectures -
Please note that the different builds have different features - see here for a comparison.
The magic registry settings that are used to create WinFE are -
Earlier version of WinFE (versions 2.x/3.x) used SanPolicy 3. WinFE versions 4.0 and 5.0 can also use SanPolicy 4. The following information is from here -
The following is from Brett Shavers "The (Nearly) Perfect Forensic Boot CD"
It's possible to set the SANPolicy as 3 (or 3/4 in WinFE 4.0/5.x) without setting NoAutoMount - I posted my results with different combinations of these two registry keys here. Please do use caution as any Online disks will be allocated a drive letter if NoAutoMount is not set - potentially resulting in disk writes and evidence contamination. NoAutoMount adds a greater level of security - particularly if WinFE 2.x\3.x is used.
The most common reports of WinFE writing to a hard disk occur when the disk does not contain a valid disk signature. For more information about WinFE and disk signatures in Windows NT based systems I recommend that you read the WinFE Script Updated topic on reboot.pro. More specifically posts #14 (reboot.pro forum member joakim) -
The commandline application Diskpart is included in WinFE and provides a means of manipulating disks to provide or restrict access. In my tests, which are detailed below, I found that some Diskpart commands documented elsewhere failed in WinFE - most notably the ATTRIBUTE DISK SET READONLY command.
The Write Protect Tool (WProtect.exe) is a third party application developed by Colin Ramsden (see here) that can be used to set a disk as READONLY - preventing accidental writes and preserving evidence.
Mr Ramsden's Write Protect Tool provides an easy to use GUI that in my opinion is not only easier to use but also works better than diskpart. Mr Ramsden has made it freely available for non-profit use and the tool is available from his website.
Ideally I would have liked to have used a physical system for testing - unfortunately I did not have any spare hardware and therefore had to rely on virtual systems running on a PC.
The initial tests were carried out in a virtual environment using QEMU. The WinFE I used for those tests was created from a WinPE 3.1 base - more accurately boot.wim from a Windows 7 DVD, which was then customised with the required registry settings.
Unfortunately the other WinFE builds that required testing would not boot on this system. After checking a number of different virtual solutions I settled on VMwarePlayer - which is free for personal use.
The disk image used for testing in both virtual environments (QEMU and WMwarePlayer) was prepared in the same way -
This disk image was then used as the base image for all further tests. An MD5 check was undertaken to establish the MD5 checksum of the disk image file - this could then be compared with MD5 checksums taken after a test to monitor for any changes.
This following test was then carried out on all WinFE versions tested.
I have included WinFE versions 4.0/5.0/5.1 in the same section as they performed identically in the tests I carried out - even down to the screenshots and diskpart output.
NOTE - a SanPolicy value of 4 was used during testing (see here).
The screenshot below shows the information in the MountedDevices registry key. This was taken prior to any other tasks being carried out, immediately following the boot process. The first entry (Default) can be ignored. The second and fifth entries are for a CD drive. The third and fourth entries are for a floppy drive. The sixth and last entry is for the WinFE systemdrive - a RAM drive. There are no entries for a hard disk -
The screenshot below shows a hex view of the Master Boot Record (MBR) - taken from the running WinFE (click on the image to display it's full size). As we can see no disk signature has been written -
A number of diskpart commands were then executed to find information about disks and attributes. The last command executed was ONLINE DISK. This command failed -
After the above tests the system was shut down and an MD5 checksum of the disk image file was taken. This was checked against the checksum taken before WinFE had booted and had not changed - indicating that no writes had been performed.
I then tested the same disk image, however this time I manually added a disk signature (A8FE 37C8) to the disk image before booting WinFE.
Despite having a disk signature added, the MountedDevices key had identical entries to those in the previous test which used a disk without a disk signature. There were no entries for a hard disk - possibly because it had been flagged as OFFLINE due to the WinFE registry settings.
This time a hex view of the Master Boot Record shows the disk signature I added manually -
Diskpart commands were repeated. This time the ONLINE DISK command completed successfully and it was also possible to mount the partition and browse it's contents -
After the tests the system was shut down and the MD5 checksum was obtained from the disk image file. This was checked against the checksum taken before WinFE had booted and had not changed - indicating that no writes had been performed.
I believe that the failure to ONLINE the disk in the first test was a result of it not containing a disk signature. A disk signature couldn't be added as the disk was write protected and NT based systems cannot mount partitions on a disk without a valid disk signature - something stated earlier by reboot.pro forum member Wonko the Sane (here).
The Write Protect Tool was able to ONLINE a disk and mount partitions on disks without a disk signature. Unfortunately this was only possible if the write protection was first removed so that a disk signature could be written - something the Write Protect Tool was able to do despite this not being possible using Diskpart.
Although it is not possible to mount partitions on disks without a valid signature, it is still possible to copy the disk with a number of imaging tools including dd. It might be possible to mount partitions using the devio and imdisk tools, however I have not had the opportunity to test this. As all Windows NT based systems will already contain a disk signature the number of cases in which this will be an issue is limited to non Windows NT systems. If a disk was previously attached to a Windows NT system it may still contain a valid signature.
I have included WinFE versions 2.1/3.0/3.1 in the same section as they performed identically in the tests I carried out - even down to the screenshots and diskpart output.
NOTE - a SanPolicy value of 3 was used during testing (see here).
The screenshot below shows the information in the MountedDevices registry key. This was taken prior to any other tasks being carried out, immediately following the boot process. The first entry (Default) can be ignored. The second and sixth entries are for a CD drive. The fourth and fifth entries are for a floppy drive. The seventh and last entry is for the WinFE systemdrive - a RAM drive. The third entry (with Data - bb c8 f4 3e 00 40 00...) is the hard disk (the mounted disk image) -
The screenshot below shows a hex view of the Master Boot Record (MBR) - taken from the running WinFE. Note the addition of a disk signature (BBC8 F43E) which corresponds to the Data in the MountedDevices key (see above) -
The textbox below shows output following a number of diskpart commands. As you can see from this information WinFE 2.1 does not write protect any media and my attempts to set the disk as READONLY failed -
The text below show diskpart output following similar tests using WinFE 3.1 on the QEMU test system -
To summarise, there is no way to prevent these versions of WinFE from writing to a disk if it doesn't already contain a disk signature - without the user actually overwriting parts of the MBR themselves (see post #15 here).
My attempts to mark a disk as READONLY using diskpart failed. It was possible to set the READONLY attribute using the Write Protect Tool, however this cannot prevent the writing of a disk signature as this appears to occur earlier in the boot process.
Whilst it was not possible to use Diskpart to change the disk attributes to READONLY, it was possible to change volume attributes. It is well documented that doing so writes to the disk and this was confirmed in my own test as the MD5 checksum changed after the READONLY flag was added to a volume.
I also noticed that mounting a drive and viewing its contents (e.g. in a file manager or at the command line using the dir command), without attempting to carry out any writes to the disk, resulted in the disk image files MD5 checksum changing - indicating that a write had been performed. This is preventable using the Write Protect Tool to mark the disk as READONLY - something that can be done during the boot process by using the wprotect.exe -i command in winpeshl.ini.
Following the experiments I carried out in the reboot.pro forum (see links above), and the tests discussed here, I'd personally recommend using a WinFE based on WinPE 4.0 or 5.x with the SanPolicy set as 4. Based on my results this appears to provide robust protection from any writes to the disk(s) being carried out. It is however possible with all versions of WinFE to manually override protection so care should be taken.
If you must use WinFE based on earlier versions of WinPE (2.x/3.x) then I'd personally recommend running a 32-bit version and using the Write Protect Tool to ensure that all internal disks are set as readonly before any further action is carried out - just be aware that a disk signature will be written if one is not already present on the disk.
I would strongly advise against using WinFE 2.x/3.x without the Write Protect Tool as the simple act of browsing a mounted disk appears to perform a write action - as evidenced by the MD5 checks I carried out before and after booting WinFE. It was not possible to use Diskpart to set a disk as READONLY despite documentation elsewhere stating that this command works.
In something as critical as Forensic Examination, WinFE needs validation and testing to ensure that no writes are performed on any evidence disk(s), or to at least be clear in what circumstances writes might be performed. The test that I carried out were limited to 32-bit Windows Forensic Environments - other versions may behave differently.
The tests I performed were limited to a virtual environment and I cannot guarantee that WinFE will function in the same way on actual hardware.
There are a number of variables that need to be taken into consideration before using WinFE - unfortunately I do not have the time or the means to test them all. The WinFE's that I used during testing were modified boot.wim files from Windows Installation Media - they were not created using the Windows Automated Installation Kit (WAIK) or the Windows Assessment and Deployment Kit (ADK). WAIK or ADK builds of WinFE can contain different combinations of optional "Packages" which might affect usage.
There are reports that dynamic disks are automatically mounted and writable with some builds of WinFE (see here and here).