WinFE Tests

• Abstract
• Methodology
• Test system setup
• About the Windows Forensic Environment
• WinFE Versions
• Registry Changes
• Disk Signatures
• Disk 1 test results
• Disk 2 test results
• Disk 3 test results
• Disk 4 test results
• Disk 5 test results
• Analysis - WinFE 2.*\3.*
• Analysis - WinFE 4.0
• Analysis - WinFE 5.*\10.*
• Conclusion\Recommendations
• Limitations
• WinFE source files

Abstract

There are reports of Windows Forensic Environment (WinFE) performing disk writes in certain circumstances, with the write action performed during the boot process before disks are write protected or third party tools used to set disks as read-only. The reports of write action are linked to WinFE creating a four byte disk signature in LBA section 0 (the disk Master Boot Record (MBR)) at offset 0x1B8.

This research seeks to identify circumstances in which WinFE will write a disk signature to an internal storage device MBR.

The research will also explore whether internal disks are write protected when WinFE is running.

It expands on the results of a previous experiment completed in 2013, which pre-dates the release of Windows 10 based WinFE (see here).

Methodology

Tests to be completed in virtual systems utilising five disk images, with the common denominator between these disk images being the abscence of a disk signature at offset 0x1B8 to 0x1BB -

• Disk 1 - blank/empty disk image with all bytes set as 00. See here for a screenshot of the disk MBR.

• Disk 2 - offset 0x1FE set as 55 AA. All other bytes including the four byte disk signature at offset 0x1B8 to 0x1BB set as 00. This simulates an initialized disk due to the presence of the "magic number" 55 AA in the last two bytes of the MBR. See here for a screenshot of the disk MBR.

• Disk 3 - Windows 98SE boot disk used to create one primary partition spanning the disk. MSDOS FDISK does not write a disk signature at offset 0x1B8 to 0x1BB - the four bytes at this offset are set as 00. See here for a screenshot of the disk MBR.

• Disk 4 - copy of disk 3 with two bytes at offset 0x1FE to 0x1FF written as 00 00 (overwriting the "magic number" 55 AA in the last two bytes of the MBR). See here for a screenshot of the disk MBR.

• Disk 5 - copy of disk 1 with the addition of an entry in the partition table (offset 0x1BE to 0x1CD). All other bytes set as 00. See here for a screenshot of the disk MBR.

Tests to be completed on systems with the following firmware -

• UEFI - 64-bit (64-bit WinFE only)
• UEFI - 32-bit (32-bit WinFE only)
• BIOS (32 and 64-bit WinFE)

Four steps to be completed with each disk image and WinFE build, with duplicate tests on systems with BIOS and UEFI firmware.

1. Disk SHA1 checksum to be taken prior to booting WinFE.

2. Boot WinFE and check for the presence of a disk signature and any other changes to LBA sector 0 (using a disk editor).

3. Shutdown WinFE and recheck the SHA1 checksum.

4. Additional check to be completed to test whether the disk is write protected whilst WinFE is running (using a disk editor to attempt to write to LBA sector 0).

Test system setup

VMWare Workstation 16 Player (version 16.2.3 build-19376536). This virtual test environment supports BIOS and UEFI 64-bit and 32-bit firmware. UEFI 32-bit firmware supported with the addition of the following setting in the .vmx configuration file -

• firmware = "efi"

Test systems to be configured with one SATA disk.

WinFE based on boot.wim extracted from Windows installation source files.

WinFE to be configured with SANPolicy 3 (supported across all WinFE versions) and NoAutoMount.

About the Windows Forensic Environment

The Windows Forensic Environment (a.k.a. WinFE) is a Windows based boot disk that can be used as a platform for digital forensic analysis and acquisition. 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 a software write blocker used to prevent writes to storage devices. Usage may include gathering evidence on systems where hardware cannot be removed, triage investigations, or as an alternative to potentially expensive hardware write blockers.

Troy Larson, Senior Forensic Examiner of Microsoft©, is credited with creating the Windows Forensic Environment. WinFE does not appear to be available as a commercial product from Microsoft. It is however relatively easy to create WinFE for personal use from freely available tools. WinFE is in essence a Windows Preinstallation Environment (WinPE - see here) 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.

WinFE Versions

As WinFE is essentially a Windows Preinstallation Environment (WinPE) with two registry modifications, there are multiple builds/versions of WinFE - all available in both 32-bit and 64-bit processor architectures. The earlier versions of WinPE used the same codebase as Windows XP/2003 - these are usually referred to as WinPE 1.*.

Earlier versions of WinPE (prior to the introduction of version 2.0) were aimed at enterprise customers and were not available to the general public. As of version 2.0 it was possible for non-enterprise customers to create their own WinPE by using the freely available Windows Automated Installation Kit (WAIK). The WAIK has now been replaced with the Windows Assessment and Deployment Kit (ADK).

Windows Operating Systems use a numbering format for identification purposes - these numbers can be used to identify the codebase from which a particular WinPE was created. Windows builds use the numbering format ‘MajorVersion.MinorVersion.Build’ - e.g. 6.1.7600. Unlike the product names associated with Windows Operating Systems (e.g. Windows 7) these numbers can refer to multiple products - version 6.1.7600 for example refers to both Windows 7 and Windows Server 2008.

WinFE versions include -

Following the release of Windows 10, WinPE/WinFEversions are identifed by MajorVersion.MinorVersion.Build numbers that generally correspond with the Windows 10 build from which they are compiled. WinPE 10.0.16299 for example corresponds with Windows 10.0.16299 (aka Version 1709 / Fall Creators Update).

There are some exceptions to this rule as the WinPE included in Windows 10.0.18362 (May 2019 Update (1903)) and 10.0.18363 (November 2019 Update (1909)) sources are both based on WinPE 10.0.18362.

Another example of the same WinPE version being included in multiple Windows sources is WinPE 10.0.19041. The following Windows 10 sources all include/use WinPE 10.0.19041 -

• May 2020 Update (10.0.19041 / 2004)
• October 2020 Update (10.0.19042 / 20H2)
• May 2021 Update (10.0.19043 / 21H1)
• November 2021 Update (10.0.19044 / 21H2)

WinPE 10.* versions include -

Registry Changes

The registry settings that are used to create WinFE are NoAutoMount....

...and SANPolicy....

Earlier version of WinFE (versions 2.x/3.x) utilise SanPolicy 3. SANPolicy 4 can also be configured in WinFE versions 4.0 and newer (from here) -

• SAN policy 3 - Doesn't mount storage devices.
• SAN policy 4 - New for Windows 8. Makes internal disks offline. Note. All external disks and the boot disk are online.

It is possible to set the SANPolicy as 3 (or 4 in WinFE 4.0/5.x/10.x) without setting NoAutoMount. Some results with different combinations of these two registry keys are available here. 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.

Disk Signatures

WinHex screenshot highlighting the location of a disk signature (offset 0x1B8 to 0x1BB) -

The most common reports of WinFE writing to a hard disk are linked to a disk signature being written when the disk does not contain a valid disk signature. For more information about WinFE and disk signatures in Windows NT based systems refer to the WinFE Script Updated topic on the reboot.pro forum. More specifically post #15 (reboot.pro forum member Wonko the Sane) -

"...Rest assured that as soon as a Windows NT EITHER: finds the 4 bytes of the disk signature set as 00 00 00 00 OR: finds two disks with the SAME disk signature - the disk signature will be written at mount time."

and also post #5 in the "Is WinFE Forensically Sound?" thread (by reboot.pro forum member Wonko the Sane) -

"...Any NT based system, as part of the "mounting" procedure for a volume (please read as "to assign a drive letter to it") needs to identify UNIVOCALLY the disk on which the volume resides AND the volume itself. This identification is made through TWO pieces of data:
1. the disk signature
2. the Volume PBR offset on that disk..."

The following information from reboot.pro forum member joakim suggests that disk signature creation is linked to the Windows kernel -

"...I did some testing yesterday (not with WinFE, but with the 2 special registry entries), and it seems difficult to prevent Windows from writing this 4 byte signature when it's missing. I was tracing it into the kernel and suspect the relevant code is somewhere within IoCreateDisk (look for references to DeviceObject), but was unable to prevent the writing..." (post #14)

...The disk-signature-writing-process is unrelated to any mounting, and will happen regardless of whether any volume on that physical disk is mounted. In the kernel it is referenced to as "UniqueDeviceObjectNumber"...." (post #16)

Based on this information, disks previously mounted on Windows NT systems will contain an existing disk signature unless it has been manually removed or the MBR has become corrupted. Disks not exposed to Windows NT systems may also contain a disk signature - as an example the following screenshot shows a disk signature on a disk with ubuntu Linux installed (the operating system was installed in a virtual machine and has never been mounted on a Windows NT system) -

Disk 1 test results

Disk 1 - blank/empty disk image with all bytes set as 00.

• SHA1 check - confirms that a SHA1 checksum of the diskimage was taken prior to booting WinFE.

• Disk signature check - LBA sector 0 checked for changes from the running WinFE (visual check of bytes at offset 0x1B8 to 0x1BB using a disk editor). ✘ denotes that a disk signature was written.

• SHA1 recheck - disk image SHA1 checksum tested after running WinFE. ✘ denotes that a disk write occurred.

• Read-only check - check to establish if the disk is write protected when WinFE is running (using a disk editor to attempt to write to LBA sector 0). ✘ denotes that the disk is not write protected.

64-bit WinFE

32-bit WinFE

The tables above dispay results from WinFE running on systems with UEFI and BIOS firmware. The majority of the results are identical across BIOS and UEFI, with the exception of WinFE versions highlighted with a       background.

Based on these results there is clear evidence that Windows 5.*/10.* versions of WinFE will write a disk signature if the disk MBR contains zero bytes. WinFE 4.0 does not write a disk signature and also write protects the disk. WinFE 2.0 and 3.* do not write a disk signature, however these versions do not write protect internal SATA disks. 64-bit WinFE 3.0 based on Windows 7 source appears to be an anomaly when running on UEFI firmware, as it also adds write protection.

Disk 2 test results

Disk 2 - offset 0x1FE set as 55 AA. All other bytes including the four byte disk signature at offset 0x1B8 to 0x1BB set as 00. This simulates an initialized disk due to the presence of the "magic number" 55 AA in the last two bytes of the MBR.

• SHA1 check - confirms that a SHA1 checksum of the diskimage was taken prior to booting WinFE.

• Disk signature check - LBA sector 0 checked for changes from the running WinFE (visual check of bytes at offset 0x1B8 to 0x1BB using a disk editor). ✘ denotes that a disk signature was written.

• SHA1 recheck - disk image SHA1 checksum tested after running WinFE. ✘ denotes that a disk write occurred.

• Read-only check - check to establish if the disk is write protected when WinFE is running (using a disk editor to attempt to write to LBA sector 0). ✘ denotes that the disk is not write protected.

64-bit WinFE

32-bit WinFE

The tables above dispay results from WinFE running on systems with UEFI and BIOS firmware. The majority of the results are identical across BIOS and UEFI, with the exception of WinFE versions highlighted with a       background.

Based on these results there is clear evidence that WinFE 4.0/5.*/10.* versions of WinFE do not write a disk signature to internal SATA disks if the two bytes at offset 0x1FE to 0x1FF (the last two bytes of the MBR) contain the "magic number" 55 AA. These versions of WinFE also write-protect internal disks, reducing the risk of accidental disk writes in forensic applications.

WinFE 2.1 and 3.* will write a disk signature if the two bytes at offset 0x1FE to 0x1FF (the last two bytes of the MBR) contain the "magic number" 55 AA. These versions of WinFE do not write-protect media - with the possible exceptions of 64-bit WinFE 2.1 and 3.0 (based on Windows Vista and Windows 7 respectively) running on UEFI firmware.

Disk 3 test results

Disk 3 - Windows 98SE boot disk used to create one primary partition spanning the disk. MSDOS FDISK does not write a disk signature at offset 0x1B8 to 0x1BB - the four bytes at this offset are set as 00.

• SHA1 check - confirms that a SHA1 checksum of the diskimage was taken prior to booting WinFE.

• Disk signature check - LBA sector 0 checked for changes from the running WinFE (visual check of bytes at offset 0x1B8 to 0x1BB using a disk editor). ✘ denotes that a disk signature was written.

• SHA1 recheck - disk image SHA1 checksum tested after running WinFE. ✘ denotes that a disk write occurred.

• Read-only check - check to establish if the disk is write protected when WinFE is running (using a disk editor to attempt to write to LBA sector 0). ✘ denotes that the disk is not write protected.

64-bit WinFE

32-bit WinFE

The tables above dispay results from WinFE running on systems with UEFI and BIOS firmware. The results are identical across BIOS and UEFI systems.

Based on these results there is clear evidence that WinFE 4.0/5.*/10.* versions of WinFE do not write a disk signature to internal SATA disks if MSDOS is already installed. These versions of WinFE also write-protect internal disks, reducing the risk of accidental disk writes in forensic applications.

WinFE 2.1 and 3.* will write a disk signature if MSDOS is installed and the disk does not already contain a disk signature. These versions of WinFE do not write-protect media.

Disk 4 test results

Disk 4 - copy of disk 3 with two bytes at offset 0x1FE to 0x1FF written as 00 00 (overwriting the "magic number" 55 AA in the last two bytes of the MBR)

• SHA1 check - confirms that a SHA1 checksum of the diskimage was taken prior to booting WinFE.

• Disk signature check - LBA sector 0 checked for changes from the running WinFE (visual check of bytes at offset 0x1B8 to 0x1BB using a disk editor). ✘ denotes that a disk signature was written.

• SHA1 recheck - disk image SHA1 checksum tested after running WinFE. ✘ denotes that a disk write occurred.

• Read-only check - check to establish if the disk is write protected when WinFE is running (using a disk editor to attempt to write to LBA sector 0). ✘ denotes that the disk is not write protected.

64-bit WinFE

32-bit WinFE

The tables above dispay results from WinFE running on systems with UEFI and BIOS firmware. The majority of the results are identical across BIOS and UEFI, with the exception of WinFE versions highlighted with a       background.

Based on these results there is clear evidence that WinFE 2.1/3.*/4.0/5.*/10.* versions of WinFE do not write a disk signature to internal SATA disks if MSDOS is already installed and the two bytes at offset 0x1FE to 0x1FF (the last two bytes of the MBR) are set to 00 00 (overwriting the "magic number" (55 AA)))

WinFE 4.0/5.*/10.* will write-protect internal disks, reducing the risk of accidental disk writes in forensic applications. WinFE 2.1 and 3.* do not write-protect media - with the possible exception of 64-bit WinFE 3.0 (based on Windows 7) running on UEFI firmware.

Disk 5 test results

Disk 5 - copy of disk 1 with the addition of an entry in the partition table (offset 0x1BE to 0x1CD). All other bytes set as 00.

• SHA1 check - confirms that a SHA1 checksum of the diskimage was taken prior to booting WinFE.

• Disk signature check - LBA sector 0 checked for changes from the running WinFE (visual check of bytes at offset 0x1B8 to 0x1BB using a disk editor). ✘ denotes that a disk signature was written.

• SHA1 recheck - disk image SHA1 checksum tested after running WinFE. ✘ denotes that a disk write occurred.

• Read-only check - check to establish if the disk is write protected when WinFE is running (using a disk editor to attempt to write to LBA sector 0). ✘ denotes that the disk is not write protected.

64-bit WinFE

32-bit WinFE

The tables above dispay results from WinFE running on systems with UEFI and BIOS firmware. The majority of the results are identical across BIOS and UEFI, with the exception of WinFE versions highlighted with a       background.

Based on these results there is clear evidence that WinFE 4.0/5.*/10.* versions of WinFE do not write a disk signature to internal SATA disks if it contains an existing entry in the partition table.

WinFE 2.1/3.* do not write a disk signature to internal SATA disks if it contains an existing entry in the partition table and the two bytes at offset 0x1FE to 0x1FF (the last two bytes of the MBR) are set to 00 00 (overwriting the "magic number" (55 AA))).

WinFE 4.0/5.*/10.* will write-protect internal disks, reducing the risk of accidental disk writes in forensic applications. WinFE 2.1 and 3.* do not write-protect media - with the possible exception of 64-bit WinFE 3.0 (based on Windows 7) running on UEFI firmware.

Analysis - WinFE 2.*\3.*

The results when running WinFE on disks 1-5 indicate that WinFE 2.*\3.* does not provide write-protection for internal SATA disks. There are some exceptions when running WinFE on systems with UEFI firmware, however these can potentially be interpreted as anomalies.

Although DiskPart documentation states that it can be used to set disk attributes as read-only, the command failed in practice. The following is output from running DiskPart in WinFE 3.1 and attempting to set disk attributes as read-only (adding write-protection) - Microsoft DiskPart version 6.1.7601 Copyright (C) 1999-2008 Microsoft Corporation. On computer: WinFE DISKPART> list disk Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- --- Disk 0 Online 2048 MB 2048 MB DISKPART> sel disk 0 Disk 0 is now the selected disk. DISKPART> detail disk Disk ID: 00000000 Type : SATA Status : Online Path : 0 Target : 0 LUN ID : 0 Location Path : PCIROOT(0)#PCI(1101)#PCI(0300)#ATA(C00T00L00) Current Read-only State : No Read-only : No Boot Disk : No Pagefile Disk : No Hibernation File Disk : No Crashdump Disk : No Clustered Disk : No There are no volumes DISKPART> attribute disk Current Read-only State : No Read-only : No Boot Disk : No Pagefile Disk : No Hibernation File Disk : No Crashdump Disk : No Clustered Disk : No DISKPART> attribute disk set readonly DiskPart failed to set disk attributes.

It is possible to set the READONLY attribute using third party tools including Colin Ramsden's write-protect and Erwan Labalec's DiskMgr, however this cannot prevent the writing of a disk signature as this appears to occur earlier in the boot process.

The following screenshot shows output following an attempt to write to LBA sector 0 (using a disk editor) after using DiskMgr to change disk attributes, and demonstrates write protection having been applied -

Output from using the command-line to attempt to write to the disk (with an existing volume mounted as C:\) Microsoft Windows [Version 7.1.7601] C:\>echo WinFE write protection test > WinFE_Test.txt The media is write protected

Results from previous tests indicate that although it is not possible to use Diskpart to change the disk attributes to READONLY, it is possible to change volume attributes. It is well documented that changing volume attributes will perform a write to the disk.

Results from previous tests also indicate that mounting a drive and viewing its contents (e.g. in a file manager or at the command line using the dir command) resulted in the disk image files MD5 checksum changing - indicating that a write had been performed. This change occured when navigating the directory structure, without attempting to carry out any writes to the disk. It is possible to prevent disk writes using third party tools to set disk attributes as read-only prior to running any applications.

To summarise, when using WinFE versions 2.*/3.* there is no way to prevent these versions of WinFE from writing to a disk if it does not already contain a disk signature. The abscence of the bytes 55 AA (the "magic number" at offset 0x1FE to 0x1FF in the last two bytes of the MBR) appears to mitigate against a disk signature being written in WinFE 2.1/3.*, however it is unlikely that these bytes will be missing on any disks containing a partition irrespective of the operating system used to prepare/partition the disk.

Analysis - WinFE 4.0

WinFE 4.0 is the only version of WinFE that passed all tests undertaken in this research. Results were consistent across 32-bit and 64-bit versions of WinFE, on systems using BIOS and UEFI firmware. Internal SATA disks were write protected early in the boot process and a disk signature was not written under any of the conditions likely to be encountered in normal operations, including -

• MBR containing 00 bytes
• Magic number (55 AA) present at offset 0x1FE to 0x1FF
• Absence of magic number (55 AA) at offset 0x1FE to 0x1FF
• Entry in MBR partition table

Analysis - 5.*\10.*

These versions of WinFE passed the majority of tests undertaken in this research. Results were consistent across 32-bit and 64-bit versions of WinFE, on systems using BIOS and UEFI firmware. Internal SATA disks were write protected early in the boot process and a disk signature was not written under any of the conditions likely to be encountered in normal operations, including -

• Magic number (55 AA) present at offset 0x1FE to 0x1FF
• Absence of magic number (55 AA) at offset 0x1FE to 0x1FF
• Entry in MBR partition table

The only instance in which a disk signature was written was during tests using disk 1, a disk with the MBR containing 00 bytes. It is unlikely that this condition will be encountered on any disks containing a partition irrespective of the operating system used to prepare/partition the disk.

Conclusion\Recommendations

Disks previously mounted on Windows NT systems will contain an existing disk signature unless it has been manually removed or the MBR has become corrupted. Other operating systems may also write a disk signature. Based on limited anecdotal evidence there appears to be some instances of WinFE writing to disks in Forensic applications, creating a disk signature if this information is missing. Assuming the disk writes are limited to disk signature creation, circumstances in which this will occur appear to be negligible.

Based on the results of the tests undertaken during this research, WinPE 4.0, 5.x or 10.x sources with SanPolicy set as 3 are recommended. Based on the results these versions appears to provide robust write protection, in particular against writes to bytes at offset 0x1B8 to 0x1BB (disk signature). As indicated by the results from the tests, WinFE 5.x and 10.x did write a disk signature when the MBR was empty. This condition is highly unlikely to be met in real use.

Use of earlier versions of WinPE (2.x/3.x) is discouraged. When using these versions there is no way to prevent writing a disk signature. The abscence of the bytes 55 AA (the "magic number" at offset 0x1FE to 0x1FF in the last two bytes of the MBR) appears to mitigate against a disk signature being written in WinFE 2.1/3.*, however it is unlikely that these bytes will be missing on any disks containing a partition irrespective of the operating system used to prepare/partition the disk. If WinFE 2.x/3.x is required, then the disk should be flagged as read-only as early as possible. Without adding write protection the act of mounting a drive and navigating the file\folder structure is likely to write to the disk.

Warning - it is possible with all versions of WinFE to manually override protection. Use caution.

Limitations

The tests were limited to a virtual environment and WinFE may function differently on physical hardware.

The majority of test were completed using 64-bit versions of WinFE. A much smaller subset of WinFE versions were used when testing 32-bit systems.

The WinFE versions used in tests were modified boot.wim files from Windows Installation Media with the WinFE registry settings applied. 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.

WinFE Source files

The tables below shows more detailed information about the sources used in the tests. The Mini-WinFE project was used to modify boot.wim from these source files, applying the registry edits documented in the Registry Changes section of this page.

64-bit sources -

32-bit sources -

Document date - 5^th June 2022