Windows FE “Live CD” Posts Followup

To get up to speed, please make yourself familiar with these two previous GSD posts:

• Windows FE – Details Teased out of the Web – Grand Stream Dreams
• Windows FE: Forensically Sound? – Grand Stream Dreams

The first one highlights a Win PE version build that offers forensic folks an alternative to the many Linux forensics “LiveCD” builds.  It contains background information as well as a link for instructions on building.

The second post was an amateur’s attempt to investigate claims that the Win FE disk isn’t, in fact, forensically sound.  I couldn’t find any actual documentation or commentary on the Web that examined this claim at all, so I set about doing my own experiment.  My admittedly limited testing found that booting a particular non-Windows system installation with Win FE did not change the drive hash.

It also allowed me an opportunity (fun excuse) to explore and detail the specific storage-mounting controls as found in the registry which prevented writing to the examined storage volumes.

Feedback from the Forensic Pros

Since then I have received a number of comments from the real forensics pros that have provided additional clarification and explanation about what is going on, along with gentle suggestions for improved validation methods.

I appreciate them deeply as my intention is to understand and document accurately what is going on with the Windows FE build in particular and Windows PE systems in general.

In the interest of sharing this great information, and to accept their honorably offered criticisms (in the sense of the act or art of analyzing and evaluating…) of my Win FE posts, I felt it was my duty to highlight them specifically in this followup post starting with Troy Larson a senior forensics investigator in Microsoft’s IT Security group who left this first of two comments.

Thanks for the write up. I am the creator of Windows FE, and I very much appreciate your testing and write up.

I have tried to document instances where Windows FE might right to disk, as well as why. Basically, Windows FE will write a disk signature to any disk that does not already have a disk signature--that is, generally, non-Windows disks (disks that have not been attached to Windows systems). Windows disks have disk signatures, so that is why you don't see a write activity.

Troy also kindly left this more detailed comment:

… ForensicSoft is quite correct. In fact, I believe I have shared more than a few emails with a person at ForensicSoft. However, I don't consider the issue as fatal to the forensic soundness of Windows FE, but then I take the position that it's how tools are used and not the tool itself that makes for forensic soundness. Windows FE can be used in a forensically sound manner.

Windows FE will write a disk signature to a non-Windows disk. Windows FE writes a disk signature to any disk that doesn't have a disk signature. This is a well documented behavior of Windows, and, as such, is predictable. As predictable, the behavior can be expected and explained by the forensic investigator. Thus, one could use Windows FE on non-Windows disk, and have forensically sound findings--as long as the four bytes at the disk signature location are not at issue. I have seen nothing that indicates that Windows FE writes to any partitioned space--Windows or non-Windows.

I have a great deal of respect for the people at ForensicSoft. I appreciate that they have taken the time to advise the forensic community of a potential issue in Windows FE. Windows FE is a tool that came out of Microsoft's forensics team. It is not a product. As you note, it is a customization of Windows PE v.2.1.

So Troy provides an explanation from his considerable testing work for cases where the disk hash has been observed to change with use of the Windows PF disk.

This is in line with the information suggestion previously by 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:

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.

DC1743 also posted a follow-up comment on one of my Windows FE posts:

In respect to the non windows testing I was not sure exactly what was going on with the conv=noerror option. Are you saying that the drive you were testing had read errors?

I guess you may not have access to a hardware write blocker, but if you did, hashing the disk with the installed linux OS whilst connected to one may have given you a better base line. As things stand we are trying to validate one form of software write blocking by using another form of software write blocking in our testing. I appreciate that the methodology may still be sound but it gives the critics more to aim at.

TinyApps Blog author and kind friend Miles offered his knowledgeable perspective as well saying

I would recommend using a hardware write-blocker, especially in forensic cases. I use WiebeTech's Forensic ComboDock:

http://www.wiebetech.com/products/ForensicComboDock.php

I haven't trusted software-only solutions ever since being unpleasantly surprised by disk changes Winternals Administrator's Pak (a Windows-based bootable rescue CD) made to a system without warning.

Lessons Learned

Number One

It seems clear that Windows PE / FE disks will, under particular circumstances, assign (write) a disk signature to a storage device if none is found.  That is the case when non-Windows OS systems are installed on the storage device.

That said, I still have the feeling that more work needs to be done to define and/or provide examples of when those particular circumstances do occur.  For instance, after the above comments were made, I went back to my original test-bed system and after booting it with the Win FE disk, verified that no Windows disk signature was present or assigned despite repeated accessing of the disk from the Win FE disk.  It never showed up.  That would be in line with my hashing matches observed.

Now in this case, my actions were only related to accessing and “off-line” viewing of the disk/contents.  I could see where if Win FE was used to capture an image, then write the image to a sanitized device, Win FE might indeed need to apply a disk signature to the cloned storage device in order to mount it in read/write mode as it put the image on the disk.  Maybe that is where the hashing difference comes in that is being talked about?  Not on the original “suspect” disk being viewed, but when “put” on the duplicate disk.  Maybe not?  I’m still unclear and hope this can be better explained.

Here are some more great links about Windows disk signatures with XP and Vista systems for background information:

• Win2k [and XP] Master Boot Record (MBR) Revealed! - by Daniel B. Sedory.  Great and while technical, quite readable exploration of the Windows 2000 and XP MBR structure.
• Multibooters – Vista’s MBR Disk Signature – Short but detailed examination of the Vista (and hence Windows 7 to a large degree) MBR structure and functions.  Bit different than XP/2000.
• Disk Administrator Corrupts Partitions – Microsoft Help and Support ID 134308
• A Description of the Diskpart Command-Line Utility -- Microsoft Help and Support ID 300415.

Number Two

It is clear to me that probably the only “professionally forensically sound manner” that exists in ensuring that a hard-disk drive (or other storage media) is not corrupted or changed when accessing it by an examiner is to use a physical write-block device attached to said device.

While software-based “write-protected” boot disks have their place, they still take a second-chair to the purpose-specific hardware-based write-blockers.

• Software Write Block – NIST IT Lab Computer Forensics Tool Testing Program reviews.

To respond to a few of the comments, no, I do not have access to a write-block device.  I’m hoping to include one in the supply and material budget for next year along with an updated SATA-drive supported disk-duplicator.  Our slot/bay-based ATA-drive duplicator is gathering dust as most all of our new systems are SATA hardware now.  Use of one in my tests would certainly have provided a greater measure of reliability with testing and results.

• Forensic disk controller - Wikipedia, the free encyclopedia
• Write Blockers - Forensics Wiki
• WiebeTech Micro Storage Solutions - Forensic ComboDock™ v4 Government and Law Enforcment Drive Imaging Docking Station, IDE to FireWire Drive Dock
• Hardware Write Block – NIST IT Lab Computer Forensics Tool Testing Program reviews.

Number Three

DC1743’s comment also pointed out another “issue” with my methodology that I hadn’t even considered: did the hard-drive of my test system have sector errors?  I’m not sure, but based on my limited understanding of the different results I saw from the dd MD5 hashing of the drive with and without use of the “conv=noerror” option it appears that could be the case.

Curiously, and not noted in the test, was the fact that I tried local installation of Helix, RAPTOR, and DEFT forensic Linux builds on the test system’s hard drive. All three balked during the drive preparation process, despite my successful manual creation of the ext3 and swap partitions manually in their installers.  Only the CAINE Live CD allowed me to install itself locally with no issues or complaints.   Maybe it is more fault-tolerant somehow.  So something indeed may be going on with that particular hard-drive.  Windows has never complained about accepting an installation.  I’ve added a hard-disk deep sector scan test to my “to-do” list for the coming week, just out of curiosity….and because I hate loose ends!

This highlights the importance of pre-checking and thoroughly testing and certifying the storage media to be used to place a captured image on is free of errors and problems.  It probably is part of the normal forensics procedure to understand if the “evidence” drive also contains any physical surface errors.  Certainly both of these things could, in theory, lead to differences between image hashing which must be accounted for.

The forensic professionals know this already but for sysadmins and the curious this is probably one key part that isn’t nearly as “sexy” as image capture and content analysis itself.  It must however be kept in mind.

I also found that the NIST IT Lab Computer Forensics Tool Testing Program has issued a January 2009 draft paper on Forensic Media Preparation.  While no results are present, it does provide an introduction to one stage of this, drive sanitization, but doesn’t seem to comment regarding verification of drive health and sector errors in particular.  That particular PDF contains some additional links to other papers on media preparation and sanitization that might be worth looking into.

Maybe it isn’t as practical an issue as it seems, but to my unlearned perspective I’m thinking it is something that is addressed at some point in forensic media preparation and usage.

Closing Comments

I still really like the idea of what Windows FE disk builds bring to the table.

Aside from their use to forensic investigators, they could also be deployed by system administrators in mission-critical responses where undisturbed capture of information/data off a target disk must be done delicately and in place without risk of over-writing said information, servers for example.  I can think of a number of cases where this application would be perfect for a Win FE disk and where removal of the target drive or use of a physical write-blocker would be impractical. And “forensic soundness” would be a non-issue.

I’ve learned very early on in IT, that one can never have enough tools, utilities, or options when serving and supporting systems.  Familiarity with the tools and how they work brings more options in responding to particular events and scenarios.

That gets back, full-circle, to the idea that everyone, sysadmins and forensic examiners alike, need to fully understand and validate just what the tools they depend on are doing.  Only in this manner can they successfully defend positions on observations made and actions performed with those same tools.

Most of my Win PE building disks will still be set to allow read/write access to attached storage devices, but now I am well versed in the options that my (now also always present) Win FE disk offers me, and how to make Win FE disks in particular.

Special words of thanks to the friends and professionals who have taken the time to elaborate and expand on my questions and Win FE posts.  You have my gratitude and respect.

--Claus V.