Do mine ears hear a challenge?
Windows FE has been gaining a bit of attention lately across the forensic blog-o-sphere.
My interest primarily in Windows PE, as well a secondary interest in Windows forensics (as applied to sysadmin tasks) got me digging for more details on the rare object.
Eventually I pulled out enough information to make the following GSD post:
Turns out it has become popular in its own right and has been cross-linked at a number of other blogs.
As I have been reading these other posts with enjoyment, I’ve noticed the following comment made on many of them, including on my own post.
Windows FE is not a "forensically sound" Windows boot disk. You can prove this by booting any non-Windows system with Windows FE and take a hash of the drive(s) before and after booting with Windows FE.
At the time I didn’t have the opportunity to test this statement out, or research what was going on that made Windows FE builds not able to write to the booted system’s physical storage devices.
My response to the comment was open and respectful:
@ ForensicSoft - No, I was not aware of the claim that Windows FE still modifies the system even when "read-blocked" with the required registry tweaks.
Is this only for "non-Windows" system off-line booting or does it apply also to Windows system off-line booting?
I haven't had the time to build my own Win FE boot disk, but it's on my considerable "to-do" list.
I'll have to take your advice and run a hash test as you suggest.
Thank you for sharing.
Forensics specialist DC1743 over at his Forensics from the sausage factory: Windows FE saves the day with a Dell Inspiron 530 post made a much more focused response:
It is easy to take issue with sweeping statements.
Windows FE may write a disk signature to a partitioned disk, if the disk does not already have a signature. The disk signature starts at 0x01B8. The partitioned space—volumes—are not written to.
The read-only switch in Diskpart also writes a byte to the hard drive that makes that hard drive read-only to Windows.
For these reasons the whole device hashing approach may result in differing hash values - however this behavior does not necessarily make the use of Windows FE forensically unsound.
Finally, John Sawyer posted a followup article an earlier Windows FE post also expressing some openness to the idea that maybe Windows FE might not be as forensically sound as claimed:
Tool Validation: Trust, But Verify - Evil Bytes Blog - Dark Reading
I received a lot of great feedback after my Friday post about WinFE, the bootable Windows Forensic Environment. The biggest question was whether it really is treating the drive as read-only. In my closing, I said I'd do more testing than just building the CD and making sure it booted up in my virtual machine environment. As security professionals and forensic investigators, don't you all validate your tools before using them?
By this time I was sufficiently in enough doubt that Windows FE (when properly built) didn’t change the physical drive it was used on I actually posted a comment about that doubt on a fresh Windows FE blog post by Liquidmatrix Security Digest: Shattered Dreams… and a welcome community.
As soon as I hit “Comment” I knew I had to stop and validate, or risk the error of spreading false information if not borne out.
So I decided to do an admittedly limited pair of tests to see if I could validate the original claims.
The Claim and Test Methodology
The claim itself against Windows FE easily defines the tested goal:
Windows FE is not a "forensically sound" Windows boot disk. You can prove this by booting any non-Windows system with Windows FE and take a hash of the drive(s) before and after booting with Windows FE.
So here were my goals:
- Build my very own Windows FE “forensic environment” boot disk based on Win PE 2.0.
- Prep a target Windows system to be used as the focus of my “incident” test.
- Use a forensic (non-Windows based) LiveBoot CD to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
- Use the Windows FE boot disk to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
- Reuse the same boot-disk in Step 3 to re-hash the target system one more time (to see if the Win FE boot changed the drive).
- Compare results.
- Sanitize (zero-out all sectors) of the target physical system used in Step 2.
- Install a “non-Windows” operating system on the target system’s physical drive.
- Use a forensic (non-Windows based) LiveBoot CD to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
- Use the Windows FE boot disk to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
- Reuse the same boot-disk in Step 3 to re-hash the target system one more time (to see if the Win FE boot changed the drive).
- Compare results.
If at the end of steps 6 or 12 I find that a different MD5 hash has been generated, then Windows FE fails and the claim that “booting any non-Windows system with Windows FE” is correct.
If they pass, that, to the extent of these particular tests, the statement is false.
The Test: Step 1
Following the information exactly on building a Windows FE disk that I found and posted in my previous Windows FE post, in no time flat I had quickly and easily prepared and burned my Windows FE disk. Note: my version was build on the Vista SP1 WAIK version. Use of a different version may provide different test results.
In preparing the disk, I also included George M Garner Jr.’s Forensic Acquisition Utilities as I would need a tool on there (dd.exe) to calculate the MD5 hash off Windows FE booting.
As an fairly experienced Win PE builder, this was simple to build, including making the two registry changes needed (as claimed) to prevent write-back access to the physical drives of the booted system.
5. In regedit, go to the HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\MountMgr key, and if the NoAutoMount dword does not exist, create a dword named "NoAutoMount" with a setting of 1. If the key already exists, change the setting to 1 if it is any other value.
6. Next, go to HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\partmgr\Parameters and change the SanPolicy setting to 3. (If the Parameters key does not exist, create it.) At this point, the registry in the mounted .wim file is set to boot and operate without mounting volumes or modifying media.
The rest is just standard Win PE building stuff. More on why those two registry tweaks are so critical later…
Disk in hand I was ready for the next steps.
Target System Prep: Windows OS
I selected a standard Dell Optiplex 745 business-class system that has dual cores, 1 GB RAM, and a single SATA 80 GB drive.
I booted the system with one of my many Win PE boot disks.
I then ran DISKPART, selected DISK 0, and ran the CLEAN ALL command which as documented, zeros out all the sectors of the focus drive.
For good measure, I then used one of my many sector viewers to inspect the disk to verify there was nothing left and it was zeroed out.
I then used DISKPART to create a primary partition, set it active, assign a drive letter and format it under NTFS.
I then applied a standard machine XP Professional image using ImageX, booted the system when done, completed the sysprep process and got it in a “usable” state.
I shut the system down.
Ready for Windows OS system hashing!
I next needed to take a MD5 hash of the Windows system using a non Windows FE boot disk.
There are lots of great and freely available Linux forensic-focused boot CD’s to use for this task. In the end I chose to play with DEFT (Digital Evidence & Forensic Toolkit) which is a Xubuntu Linux-based Computer Forensics live CD. The more I use it the more I find stuff to like. I used the DEFT version 4 beta build for my tests.
Using a CD-tray needle, I opened the CD tray door and placed the DEFT boot CD in it (to avoid any possibility of accidently getting the Windows OS loaded) and booted the system.
Once booted and the DEFT-GUI loaded, I used their Dhash GUI tool to generate a MD5 hash of the physical hard drive, reported by DEFT as sda. (Dhash reference links: Dhash - DEFT wiki, Dhash - DEFT Linux, and Dhash 1.1 DEFT Linux)
I captured the following MD5 hash:
4e3efe13706b83007770035d0829589e
I shut the system down, inserted the Windows FE disk and rebooted the system.
Once up on the CMD window, I used DISKPART to verify I could see the physical drive (I could) and then browsed into the Win FE disk’s \WinFE folder I created and put the FAU tools into.
I used the dd.exe tool with the following command: (Note: both George M Garner Jr.’s FAU documentation as well as these dd.exe tips from Alexander Geschonneck helped me.)
dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5
When completed it outputted the following MD5 hash:
4e3efe13706b83007770035d0829589e
I then shut down the system and again rebooted with DEFT LiveCD and used Dhash to rehash the drive one more time to verify Win FE hadn’t changed/modified the physical drive.
4e3efe13706b83007770035d0829589e
It had not.
Test Observation #1
Based on this test, it appeared clear to me that when properly built, a Windows FE boot disk did not modify the physical hard-drive contents of a Windows-based OS system on that drive.
So far so good, but that isn’t being challenged in the comments.
Recall, the comment poster claimed that the non-forensics issue is found “…by booting any non-Windows system with Windows FE…” (emphasis mine).
On to test challenge stage 2.
Target System Prep: Windows OS
Using the same test system Windows was loaded onto, I booted the system with one of my many Win PE boot disks.
I then ran DISKPART, selected DISK 0, and ran the CLEAN ALL command which as documented, zeros out all the sectors of the focus drive.
For good measure, I then used one of my many sector viewers to inspect the disk to verify there was nothing left and it was fully zeroed out.
This time I needed to install a non-Windows system on the drive. For this I chose the Linux-based forensic CAINE Live CD. I’m also finding a lot to like in this forensics distro as well.
It has an option to do a local install which I selected. During the setup process I created a ex3 partition as well as a swap partition.
When done I booted into the system proper, off the hard-disk, mucked around a bit to generate hard-drive changes, and then shut the system down.
Ready for non-Windows OS system hashing!
I next needed to take a MD5 hash of the CAINE non-Windows (Linux) system using a non Windows FE boot disk.
I again used the same DEFT live CD.
Using a CD-tray needle, I opened the CD tray door and placed the DEFT boot CD in it (to avoid any possibility of accidently getting the CAINE system loaded) and booted the system.
Once booted and the DEFT-GUI loaded, I used their Dhash GUI tool to generate a MD5 hash of the physical hard drive, reported by DEFT as sda.
I captured the following MD5 hash:
71649687fa1f7b64462da2d6ac6c7bee
I shut the system down, inserted the Windows FE disk and rebooted the system.
Once up on the CMD window, I used DISKPART to verify I could see the physical drive (I could) and then browsed into the Win FE disk’s \WinFE folder I created and put the FAU tools into.
I quickly used the dd.exe tool with the following command:
dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5
When completed it outputted the following MD5 hash:
99de7237675a4f61ee529e3d74173391
Oh my gosh!
The Windows FE disk did appear to now issue a different hash on the drive by booting a non-Windows OS with it.
Could it be true after all?
A Pregnant Pause of Silence and Study
I then shut down the system and again carefully rebooted with DEFT LiveCD and used Dhash to rehash the drive one more time to verify Win FE had indeed changed/modified the physical drive.
71649687fa1f7b64462da2d6ac6c7bee
Amazingly, that was the same MD5 that I captured from DEFT pre Windows FE boot.
I shouldn’t have gotten that if Windows FE had changed the disk.
Something was up.
I shut down and rebooted again with Windows FE.
I paid closer attention this time as I re-ran the dd.exe MD5 hash.
dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5
This time, I noted that before it started the Hashing, it was waiting for a response from me if I wanted (Y/N) to apply the “conv=noerror” parameter first.
I have to confess I didn’t notice that before.
I referred back to George M Garner Jr.’s Forensic Acquisition Utilities documentation page and specifically the part about dd.exe as follows below under “Specific Remarks #7”:
The default block size for DD is 1 MiB. The handling of “bad blocks” (“conv=noerror”) is new. Traditional versions of DD skip “bad blocks” in increments equal to the block size. If the block size is larger than the sector size of the device, data will be lost. The alternative is to set the block size equal to the device sector size. But that is usually quite slow. The new version of DD uses the specified block size until a “bad sector” is encountered, at which point the block size drops back to a value equal to the device sector size. The larger blocks size is resumed once the “bad block” is passed, until the next “bad block” is encountered.
Ah!
The first time on the non-Windows OS test in Win FE I now recall answering “N” and thus got the hash 99de7237675a4f61ee529e3d74173391.
This time I answered “Y” to the use “conv=noerror” option.
I captured the following MD5 hash:
71649687fa1f7b64462da2d6ac6c7bee
Same as the original pre- Windows FE boot using DEFT.
For good measure I then shut down Windows FE, and rebooted with the DEFT LiveCD one more time and Dhashed sda one more time.
And I captured the following MD5 hash:
71649687fa1f7b64462da2d6ac6c7bee
Windows FE Experiment Conclusions
Based on my specific system and configuration testing validation, I can comfortably make the following statements:
- When properly booted and used, the DEFT forensic LiveCD does not appear to modify or change the physical hard-drive of a Windows-based OS.
- When properly created, booted, and used, a Windows FE (PE 2.0 Vista SP1 base) forensics LiveCD does not appear to modify or change the physical hard-drive of a Windows-based OS.
- When properly created, booted, and used, a Windows FE (PE 2.0 Vista SP1 base) forensics LiveCD does not appear to modify or change the physical hard-drive of a Linux-based non-Windows OS.
- When properly booted and used, the DEFT forensic LiveCD does not appear to modify or change the physical hard-drive of a Linux-based non-Windows OS.
Granted, this was one series of tests, on one particular hardware system configuration using XP professional and Linux OS’s. Other non-Windows OS’s and/or hardware configurations might produce different results.
But it looked good for me.
While not a forensics investigator and just a sysadmin in the trenches, Windows FE seems to sufficiently answer my questions on whether or not it can off-line boot a system without making changes to the storage media (hard-drive) of the system. It can.
Forensics examiners and investigators who have give legal testimony when using Windows FE could and should perform similar independent testing to validate their particular system/OS combinations first.
The Rest of the Story.
All this was a lot of geeky fun for me.
I haven’t used the commercial forensics tool in question noted in the comments as being “..the only forensically sound write-blocked Windows boot disk in existence.”
It might indeed be a great and fantastic product. I haven’t used it so I can’t say, particularly for real forensics usage. I can understand why they would be proud of their product and all the efforts they have put into development. I can’t blame them for wanting to share their pride with others, and differentiate it from other forensics products.
But like forensics specialist DC1743 said, the comment claim was a pretty sweeping one. And it didn’t hold true in my test.
The commentor issued a challenge to test their statement for accuracy. I did and found it a bit wanting after test validation.
As I mentioned before, John Sawyer hit it on the head when he reminded all forensics experts (and lowly sysadmins as well) that we all have a duty to test the tools we use. Tool Validation: Trust, But Verify - Evil Bytes Blog - Dark Reading
Fortunately for all of us, there are a lot of fantastic forensic tools out there to pick from. Commercial ones and non-commercial ones alike. Each have their own sets of strengths and weaknesses.
The Two Keys of Windows FE
This whole exercise wasn’t enough, however.
I wanted to see if I could find a bit more information on the particular (and only) registry keys that were modified in building the Windows FE disk and what differentiated them from a regular Windows PE disk.
Turns out there just isn’t a lot of public documentation on these keys, but I did find some juicy bits anyway.
(Note: SAN stands for “storage area network” in these cases.)
HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\MountMgr key, and if the NoAutoMount dword does not exist, create a dword named "NoAutoMount" with a setting of 1
This control setting (under default) tells the storage mounting manager (when booting a system) to add and automount storage disks to the system. From the second link noted above.
The SAN policy determines whether a newly discovered disk is brought online or remains offline, and whether it is made read/write or remains read-only. When a disk is offline, the disk layout can be read, but no volume devices are surfaced through Plug and Play (PnP). This means that no file system can be mounted on the disk. When a disk is online, one or more volume devices are installed for the disk.
This enumeration supersedes the NoAutoMount registry key, which can be found under the following registry path:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Mountmgr\NoAutoMount
The value of this key is a REG_DWORD value that is set to 0x00000000 to enable the Windows automount feature or a nonzero value to disable it. If the automount feature is enabled, Windows automatically mounts the file system for a new basic volume when it is added to the system and then assigns a drive letter to the volume. In system area network configurations, disabling automount prevents Windows from automatically mounting or assigning drive letters to any new basic volumes that are added to the system.
…and as described in “normal language” as provided by David Shen –MSFT in the third link above:
We can verify the status of Automatic mounting of new volumes by looking at the value of the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MountMgr\NoAutoMount
If the value is set to 1: This indicates that Automatic mounting of new volumes is Disabled.
If the value is set to 0: This indicates that Automatic mounting of new volumes is Enabled.
Now for the second key.
HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\partmgr\Parameters and change the SanPolicy setting to 3
This key appears to control how the Windows system processes the partition manager configuration when loading the system and any SAN (storage area network) devices it finds while booting.
From the first link:
- Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr
- In the details pane, examine the value of the Start registry entry. To start PartMgr when the computer starts, this value must be 0x00000000.
- Exit all programs, and then restart the computer.
Note The following table lists the service startup types that are available in Windows. Startup type
Hexadecimal value
Boot
0x00000000
System
0x00000001
Automatic
0x00000002
Manual
0x00000003
Disabled
0x00000004
Typically, device drivers are set to use a startup type of Boot or System. Typical Windows services are set to use a startup type of Automatic or Manual.
And from the second link:
The functionality of Storage Area Network (SAN) enables a server to mount disks and other storage devices automatically from other computers.
By configuring the SAN policy on a Windows image, you can control whether or not disks are automatically mounted, which disks can be mounted, and you can disable automatically mounting disks.
Configure the SAN policy on Windows PE
For Windows PE images that are available in the Windows OPK and the Windows AIK, the default SAN policy is to mount available disks automatically. This might reduce the performance of Windows PE if there are many available disks in the SAN environment.
SAN policy number Description
1 Mounts all available storage devices. This is the default value.
2 Mounts all storage devices except those on a shared bus.
3 Does not mount storage devices.
This is getting deeper than the typical Windows OS sysadmin waters I swim in, so I’m open to hard-core Windows OS registry pros to correct me or provide additional supportive explanation on what’s going on here.
But basically, it seems based on these links, that by making the registry changes specified when building the Windows FE disk, it prevents the automounting of attached storage media (disks) to a system during the Windows (PE/FE) boot process, and forces any mounting that needs to occur to be done manually (by the system operator).
If this is correct, and these two Windows Registry keys are set correctly, then it seems that in most cases, the Windows PE (FE) OS boot shouldn’t care what OS is loaded on the system and the drives remain unmounted and unattached from the Win PE (FE) boot OS system.
You can see them and browse them, but they remain “unmounted” devices and not accessible unless manually attached and mounted to the Win PE (FE) system using DISKPART.
Or so it seems.
Whew.
Who knew testing and validation could be so educational and fun!
Cheers and best regards to all computer forensics developers and expert examiners alike! My late grandfather (retired F.B.I. Special Agent) would be proud of your collective efforts.
I know I sure am.
--Claus V.
