WinFE Tests


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 -

Tests to be completed on systems with the following firmware -

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.
  1. Boot WinFE and check for the presence of a disk signature and any other changes to LBA sector 0 (using a disk editor).
  1. Shutdown WinFE and recheck the SHA1 checksum.
  1. 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 -

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 -

WinPE Major.Minor.Build Windows Operating System source
2.0 6.0.6000 Windows Vista
2.1 6.0.6001 Windows Vista (SP1) / Server 2008
3.0 6.1.7600 Windows 7 / Server 2008 R2
3.1 6.1.7601 Windows 7 (SP1) / Server 2008 R2 (SP1)
4.0 6.2.9200 Windows 8 / Server 2012
5.0 6.3.9600 Windows 8.1
5.1 6.3.9600 Windows 8.1 Update

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 -

WinPE 10.* versions include -

WinPE Build WinPE Version Windows Operating System source
10.0.10240 1507 -
10.0.10586 1511 November Update
10.0.14393 1607 Anniversary Update
10.0.15063 1703 Creators Update
10.0.16299 1709 Fall Creators Update
10.0.17134 1803 April 2018 Update
10.0.17763 1809 October 2018 Update
10.0.18362 1903 May 2019 Update (Windows 10.0.18362 / 1903)
November 2019 Update (10.0.18363 / 1909)
10.0.19041 2004 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)


Registry Changes


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

Key HKLM\System\ControlSet001\Services\MountMgr
Name NoAutoMount
Type DWORD
Data 1

...and SANPolicy....

Key HKLM\System\ControlSet001\Services\partmgr\Parameters
Name SANPolicy
Type DWORD
Data 3 (or 4 in WinFE versions 4.0 or newer)

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) -

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) -

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

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

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.

64-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
2.1 Vista source 1
3.0 BIOS 7 source 2
3.0 UEFI 7 source 2
3.1 7 SP1 source 3
4.0 8.0 source 4
5.0 8.1source 5
5.1 8.1 Update source 6
10.0.10240 1507 source 7
10.0.10586 1511 source 8
10.0.14393 1607 source 9
10.0.15063 1703 source 10
10.0.16299 1709 source 11
10.0.17134 1803 source 12
10.0.17763 1803 source 13
10.0.18362 1909 source 14
10.0.19041 21H2 source 15

32-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
3.1 7 SP1 source 16
4.0 8 source 17
5.1 8.1 Update source 18
10.0.19041 21H2 source 19

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.

64-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
2.1 BIOS Vista source 1
2.1 UEFI Vista source 1
3.0 7 source 2
3.1 BIOS 7 SP1 source 3
3.1 UEFI 7 SP1 source 3
4.0 8.0 source 4
5.0 8.1source 5
5.1 8.1 Update source 6
10.0.10240 1507 source 7
10.0.10586 1511 source 8
10.0.14393 1607 source 9
10.0.15063 1703 source 10
10.0.16299 1709 source 11
10.0.17134 1803 source 12
10.0.17763 1803 source 13
10.0.18362 1909 source 14
10.0.19041 21H2 source 15

32-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
3.1 7 SP1 source 16
4.0 8 source 17
5.1 8.1 Update source 18
10.0.19041 21H2 source 19

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.

64-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
2.1 Vista source 1
3.0 7 source 2
3.1 7 SP1 source 3
4.0 8.0 source 4
5.0 8.1source 5
5.1 8.1 Update source 6
10.0.10240 1507 source 7
10.0.10586 1511 source 8
10.0.14393 1607 source 9
10.0.15063 1703 source 10
10.0.16299 1709 source 11
10.0.17134 1803 source 12
10.0.17763 1803 source 13
10.0.18362 1909 source 14
10.0.19041 21H2 source 15

32-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
3.1 7 SP1 source 16
4.0 8 source 17
5.1 8.1 Update source 18
10.0.19041 21H2 source 19

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)

64-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
2.1 Vista source 1
3.0 UEFI 7 source 2
3.0 BIOS 7 source 2
3.1 7 SP1 source 3
4.0 8.0 source 4
5.0 8.1source 5
5.1 8.1 Update source 6
10.0.10240 1507 source 7
10.0.10586 1511 source 8
10.0.14393 1607 source 9
10.0.15063 1703 source 10
10.0.16299 1709 source 11
10.0.17134 1803 source 12
10.0.17763 1803 source 13
10.0.18362 1909 source 14
10.0.19041 21H2 source 15

32-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
3.1 7 SP1 source 16
4.0 8 source 17
5.1 8.1 Update source 18
10.0.19041 21H2 source 19

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.

64-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
2.1 Vista source 1
3.0 UEFI 7 source 2
3.0 BIOS 7 source 2
3.1 7 SP1 source 3
4.0 8.0 source 4
5.0 8.1source 5
5.1 8.1 Update source 6
10.0.10240 1507 source 7
10.0.10586 1511 source 8
10.0.14393 1607 source 9
10.0.15063 1703 source 10
10.0.16299 1709 source 11
10.0.17134 1803 source 12
10.0.17763 1803 source 13
10.0.18362 1909 source 14
10.0.19041 21H2 source 15

32-bit WinFE

WinFE
version
WinFE source SHA1
check
Disk
signature
check
Read-only
check
SHA1
recheck
3.1 7 SP1 source 16
4.0 8 source 17
5.1 8.1 Update source 18
10.0.19041 21H2 source 19

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) -

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:\)

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 -


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 -

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 -

Source WinPE version ISO name
SHA1
source 1
Vista SP1
2.1 en_windows_vista_with_service_pack_1_x64_dvd_x14-29595.iso
SHA1: bdadc46a263a7bf67eb38609770e4fdbd05247cb
source 2
Win 7
3.0 en_windows_7_home_premium_x64_dvd_x15-65733.iso
SHA1: 336779ea6b65f63e11a609b4d021439c47ab315b
source 3
Win 7 SP1
3.1 en_windows_7_enterprise_with_sp1_x64_dvd_u_677651.iso
SHA1: a491f985dccfb5863f31b728dddbedb2ff4df8d1
source 4
Win 8
5.0 en_windows_8_x64_dvd_915440.iso
SHA1: 1ce53ad5f60419cf04a715cf3233f247e48beec4
source 5
Win 8.1
5.0 en_windows_8_1_x64_dvd_2707217.iso
SHA1: bc2f7ff5c91c9f0f8676e39e703085c65072139b
source 6
8.1 Update
5.1 en_windows_8.1_enterprise_with_update_x64_dvd_6054382.iso
SHA1: b7dd748446d89b9449a160cdc24bd282989bbd96
source 7
1507
10.0.10240 en-gb_windows_10_enterprise_2015_ltsb_x64_dvd_6848456.iso
SHA1: 6476e33d7f50e66a53b347db7a3aa953516ac8a0
source 8
1511
10.0.10586 en_windows_10_multiple_editions_version_1511_updated_apr_2016_x64_dvd_8705583.iso
SHA1: 1b247b5b348e78c9bc3afd3c1cbe10cee3d1b9d5
source 9
1607
10.0.14393 en_windows_10_enterprise_2016_ltsb_x64_dvd_9059483.iso
SHA1: 031ed6acdc47b8f582c781b039f501d83997a1cf
source 10
1703
10.0.15063 en_windows_10_multiple_editions_version_1703_updated_march_2017_x64_dvd_10189288.iso
SHA1: ce8005a659e8df7fe9b080352cb1c313c3e9adce
source 11
1709
10.0.16299 en_windows_10_multi-edition_vl_version_1709_updated_dec_2017_x64_dvd_100406172.iso
SHA1: 1851a0007321fa084145ea24b8d30bf7a72bf1c6
source 12
1803
10.0.17134 en_windows_10_consumer_editions_version_1803_updated_march_2018_x64_dvd_12063379.iso
SHA1: 08fbb24627fa768f869c09f44c5d6c1e53a57a6f
source 13
1809
10.0.17763 en_windows_10_enterprise_ltsc_2019_x64_dvd_be3c8ffb.iso
SHA1: d5b2f95e3dd658517fe7c14df4f36de633ca4845
source 14
1909
10.0.18362 en_windows_10_business_editions_version_1909_updated_aug_2020_x64_dvd_f291e1db.iso
SHA1: d2a857f5950f173f651334d6a5aae2e7f4a76b06
source 15
21H2
10.0.19041 us_windows_10_enterprise_ltsc_2021_x64_dvd_d289cf96.iso
SHA1: 2fb2897373c4f71b06f4490943b3d564b0f0fd6d

32-bit sources -

Source WinPE version ISO name
SHA1
source 16
Win 7 SP1
3.1 en_windows_7_enterprise_with_sp1_x86_dvd_u_677710.iso
SHA1: 4e0450ac73ab6f9f755eb422990cd9c7a1f3509c
source 17
Win 8
4.0 en_windows_8_enterprise_x86_dvd_917587.iso
SHA1: fefce3e64fb9ec1cc7977165328890ccc9a10656
source 18
8.1 Update
5.1 en_windows_8.1_enterprise_with_update_x86_dvd_6050710.iso
SHA1: 584a9ad7e2bb3d7e189adcfba44a497cc9155937
source 19
21H2
10.0.19041 en-us_windows_10_enterprise_ltsc_2021_x86_dvd_9f4aa95f.iso
SHA1: 3f7f38802043aa55ebe930655ee35be876213e4d

Document date - 5th June 2022