Jump to content











Photo

Is WinFE Forensically Sound?


  • Please log in to reply
35 replies to this topic

#1 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 26 September 2013 - 04:05 PM

The following comments have been copied from "The (Nearly) Perfect Forensic Boot CD" by Brett Shavers -
 
Page 3

Booting a non-Windows disk may cause writes to the evidence disk.  These changes are well documented and do not affect the integrity of the user data (WinFE is not going to create a user generated file…it may just write a disk signature). Of  course,  knowing  that  an  evidence hard drive  is non-Windows,  simply  choose  another method  to  capture  the  image, or document  the changes  that are knowingly made.  This paper does not provide any  testing data as  it  is merely a write-up on creating the WinFE boot CD.

 
Page 12

Setting a disk to read-only does not alter the hard drive.
Setting the volume to read-only does alter the disk.

 
Page24

There are several results of tests with the Windows Forensic Environment that can be found online.  Some of the tests show that Windows FE will write a signature to a disk that has not been connected to a Windows system prior.  This would include a new disk or non-Windows disk (that has not been connected to a Windows system).  At least one test shows that this may not happen all the time.

 
There are also some comments relating to Windows automatically adding or changing a disk signature here - http://reboot.pro/to...script-updated/
 
So, how forensically sound is WinFE?
 
Expanding on this question -
  • Does it depend on which WinPE/WinFE version (e.g. WinPE 3.1 - build 6.1.7601) is used as base (do different versions behave differently)?
  • Does it depend on which SanPolicy setting is used?
There seems to be various accounts on the internet of WinPE modifying a disk despite the WinFE registry settings being applied - but I can't find much evidence to support these comments.
 
I have carried out a few test using a very basic MistyPE build created from WinPE 3.1 and using QEMU as I don't have any spare hardware to play around with.
 
I mounted a raw disk image and booted WinFE, ran diskpart and checked the raw disk was online, then closed down QEMU. I then used dd to extract the MBR from the disk image - no disk signature had been added.
 
I then rebooted WinFE and created two partitions on the disk. I closed QEMU and took an md5 hash of the file and made a note of this.
 
I rebooted WinFE and played around but did not make any changes to the disk other then checking disk and volume attributes. On closing down QEMU the md5 hash of the disk image had not changed. Good news as far as I'm concerned.
 
I then rebooted WinFE and changed a volume attribute to readonly (I tried changing the disk attribute initially, however this could not be set as readonly!). On closing QEMU I found that the md5 hash of the disk image had changed - indicating a write to the disk. Interestingly I compared the MBR and VBR records both before and after changing the volume attributes and these had not changed.
 
Does anyone know where the readonly flag added?
 
This was a very quick and basic series of tests and needs to be redone - preferably on physical hardware. Any volunteers? It would be great to finally confirm whether WinFE does write to the disk and in what circumstances.
 
Regards,
 
Misty
  • llewis likes this

#2 bshavers

bshavers

    Frequent Member

  • Developer
  • 130 posts
  •  
    United States

Posted 26 September 2013 - 09:17 PM

This is the answer to WinFE's soundness:

 

Setting a disk to read-only does not alter the hard drive.
Setting the volume to read-only does alter the disk.

 

There were claims by some (online and most anonymous, through comments in various blogs...) stating that their tests showed WinFE not to be as forensically sound as, say, a commercial product..

 

It is forensic, based on every test I've done and read.  Also, even IF a disk signature was written and even IF you had to set a volume to read-only to perform a task on the evidence drive, that does not make it non-forensic IF setting the volume online was the most reasonable method to do what you had to do, such as running a triage program on the evidence machine, onsite, during a consent search as an example.



#3 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 26 September 2013 - 09:31 PM

...There were claims by some (online and most anonymous, through comments in various blogs...) stating that their tests showed WinFE not to be as forensically sound as, say, a commercial product..
 
It is forensic, based on every test I've done and read. Also, even IF a disk signature was written and even IF you had to set a volume to read-only to perform a task on the evidence drive, that does not make it non-forensic...


@bshavers
Thanks for the response. Whilst I appreciate that it might still be considered acceptable from an evidence point of view IF a disk signature was written, this is surely not desirable is it?

Has anyone actually experienced this writing of a new disk signature or is it just an unconfirmed rumour? Right now it all seems a bit vague ...might ...if

Regards,

Misty

#4 bshavers

bshavers

    Frequent Member

  • Developer
  • 130 posts
  •  
    United States

Posted 26 September 2013 - 09:46 PM

You might get a disk signature written if you boot a non-Windows (Linux as an example) machine.  But I've not seen it, only read claims by some commenters to blogs. 

 

And if it does happen, even if it were to happen to a Windows machine (never saw that happen either..), it may be the only method of capturing best evidence as in the case of a SSD where WinFE is about the least intrusive compared to just about any other method.

 

I've tested WinFE by booting Windows, Mac, and Linux machines and tried to modify the disks.  I've not had a failure.  However, with any boot system, you can purposely circumvent the protection if you really wanted to.  But that is not the intended use of WinFE or any Linux forensic disc, all of which can access and modify the evidence drive if you try.



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14910 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 September 2013 - 09:52 PM

Misty,
you seem to be missing some "basics" (or at least "previous state of the art").

By extrapolating sentences on a book without being fully aware of this you are seemingly mixing things.

Forget for one moment WinFE.

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:

  • the disk signature
  • the Volume PBR offset on that disk

See this (ONLY seemingly unrelated):
http://www.911cd.net...showtopic=19663
 
ANY disk that contains at least one volume and that has EVER been connected to a NT based systems will have a Disk Signature.
An existing Disk Signature is changed ONLY in two cases:

  • the existing Disk SIgnature is all 00's (i.e. there is NO Disk Signature)
  • the existing Disk Signature is a duplicate of the Disk Signature of another disk connected AT THE SAME time to the NT based OS AND with at least one Volume mounted.

Since the disk signature is 4 bytes, the theoretical probability of a collision is 1/(256^4-1)=2.33E-10 i.e. 0,0000000002328 or 1:4294967295.

Due to some particular behaviours observed in the (semi-random generated) attribution of the Disk Signature (at least on NT 3.x, 4.x and 2K), the above VERY improbable event is actually more frequent:
http://thestarman.pc...br/Win2kmbr.htm

The digits shown in the disk editor view above are only an example and could be anything; but we've noticed a high tendency under Windows 2000/XP for the first and third and the second and fourth bytes to be the same digits, as in the example above: A8 E1 A8 E1. In other NT-type MBRs, we've observed signatures such as these: "87 04 88 04" and "6B 40 6C 40" and "84 1A 85 1A". So there's a high probability that at least the 2nd and 4th bytes will almost always be the same and that some kind of algorithm is being applied by the OS to create these digit patterns. However, we've also seen NT-type MBRs with no discernible pattern at all, such as: "ED 19 EB BF" and "80 EF A0 FB," so we have no idea exactly how these OSs 'decide' to write these kind of Disk Signature digits versus those having patterns as seen above.)

 

Still, even if we VERY prudentially assume that ALL NT based systems will have the most unfavourable repetition pattern, we still 1/(256^2-1)=1/65535

Considering that a single machine may - at the very most - image/access 3 or 4 disks per day, i.e. on a 220 days/year between 660 and 880 disks per year, to have certainty of a collision that same machine should work for more than 70 years. (if we take the earlier estimate the number of years become more than 4.800.000  :w00t: :)

 

The only cases ever recorded of a collision have been related to the accidental connection/mount of a cloned disk (or disk image).

 

So that is NOT a "real" problem.

 

As well, the change of 4 (four) bytes on a disk (because the disk has NEVER been connected to any NT OS) is NOT a "real" problem.

There are NO consequences of ANY kind coming from this change.

 

For the record it is years that there are DOS based or Linux based cloning/imaging solutions that DO NOT alter those 4 bytes, nonetheless a large part of the Forensics community used, uses and will continue to use either hardware duplicators/imagers or hardware writeblockers, even when using such software, notwithstanding the fact that imaging through a writeblocker slows down the process.

 

For the record, for years it has been thought that a hardware blocker is "guaranteed" to block writes until a buggy firmware on a Tableau device demonstrated how this was not true (though the probability of an actual write happenng were very, very, very low).

 

More details you can find here:

http://www.forensicf...ewtopic/t=8679/

starting from around here:

http://www.forensicf...r=asc/start=42/

 

Back from this digression, the test that you should make is very simple.

Boot a Qemu VM from a DOS virtual floppy (with a completely blank or 00'ed hard disk image).

Use fdisk and format to create one or two partitions on the hard disk image.

Install DOS to first active primary partition (so that you can boot the VM with just that hard disk image connected, add to the DOS install grub.exe from grub4dos.

Run grub.exe and at the grub prompt use the command:





cat --hex --skip=440 --length=4 (hd0)0+1

that will show you the disk signature.

Now try attaching a second hard disk image with a "normal" WinPE (or use a CD/DVD image, even "better").

Try booting from the latter.

Do the partiition(s) on the "Dos" disk get a drive letter assigned?

If yes, check the Registry of the booted PE, the relevant keys are under HKLM\System\MountedDevices\DosDevices, as in here:

http://www.911cd.net...ndpost&p=130963

Is the first part of the key value 4 00's or something else?

If they are all 00's, try attaching another hard disk image (WITH a disk signature, *any* you may have handy will be good for the test).

Try rebooting again and check those keys.

What happens?

Try again booting from the DOS and run the grub4dos command.

What happens?

 

Repeat the test with the WinFE (i.e. *any* PE with the "proper protective keys" in the Registry).

 

Fiddle with it until you find which particular diskpart command creates the Disk Signature.

As bshavers just posted in the meantime, it will be a "volume related" command and not a "disk related" one.

 

Now, let's get to practice.

 

For a Disk to NOT have already a signature ONLY three possibilities exist:

  1. the Disk has NEVER been connected to a NT based machine (and thus in 99.99% of cases it has been accessed by a non MS OS, be it Linux, BSD or *whatever* - the number of people still running Dos/win9x/Me are very little)
  2. the Disk signature has been there (because the disk, at least once in it's life has been connected to a NT system) BUT, for any reason it has been (intentionally or non-intentionally) deleted BEFORE you got the disk to examine (and ONLY the disk signature has been deleted or set to 00's)
  3. the Disk signature has been there BUT, due to a corruption, hardware or software issue, etc. the whole MBR has been wiped or is corrupted

If #1 examining it on a Windows NT system makes very little sense and the ONLY thing that can (and should ) be done through a WinPE is to image the disk, but anyway if just the Disk Signature is changed it has NO consequences whatsoever.

If #2 there are three cases:

  1. the disk contains a "bootable" NT based OS, AND there is a valid Registry for it, then you can rewrite the correct Disk Signature taking it from the Registry before fiddling with diskpart and similia
  2. the disk contains a "bootable" NT based OS, AND there is NOT a valid Registry for it, then you can write *any* "random" disk signature before fiddling with diskpart and similia
  3. the disk contains NOT a "bootable" NT based OS, and you are in the same #2.2 case above

If #3 you are not anymore in "pure forensics" but rather in "data recovery", again you'd better just image the disk "as is", but if you really-really want to fiddle with diskpart, you can, just like #2.2 write *any* "random" disk signature

 

All in all, if you find that a disk has a disk signature of all 00's, then you can write to it *any* "random" or "correct" disk signature and then rewrite to it all 00's.

 

Or if you prefere, you can make a backup of the MBR from a "surely safe" OS like DOS or even the grub4dos environment before even booting the PE, and then restore it afterwards.

 

Think of a car accident, you take photos, you mark on the road where the vehicles are, you take measures and sketches, then you move the vehicles to allow the reopening of the road.

The day after you may decide to re-close the road for a few hours, put back the vehicles exactly where you found them to better understand the dynamics of the crash.

 

As long as the procedure is adequately documented, it is perfectly "forensically sound".

 

What I think are "common" false equations are

 "forensically sound"="untouched"

 "forensically sound"="identical"

 "forensically sound"="unmodified"

 

I see "forensic sound" also something that has been "touched", "modified" or "moved", as long as this has been done along a procedure and of course a "proper" and repeatable procedure.

 

:cheers:

Wonko

 



#6 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 26 September 2013 - 10:00 PM

@bshavers
My test was pretty limited - using a raw disk image and QEMU. I didn't notice any writes to the disk.

I also read this