Jump to content











Photo

Is WinFE Forensically Sound?


  • Please log in to reply
35 replies to this topic

#1 misty

misty

    Silver Member

  • Developer
  • 703 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

    Silver Member

  • Developer
  • 703 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
  • 13576 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

    Silver Member

  • Developer
  • 703 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 post some time ago - http://grandstreamdr...ally-sound.html - I would have linked to it in my first post however I couldn't find it earlier.

I can't find any confirmed instances of WinFE writing to a disk - other than when commands are executed manually - e.g. setting a volume as readonly. I think it's a shame that there seems to be a lack of any decent test results for what is potentially an invaluable tool - a tool that a lot of people could be discouraged from using due to what seems to amount to speculation only.

Regards,

Misty

#7 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 26 September 2013 - 10:06 PM

Hi Wonko,

I was posting a reply when you posted, and missed your message. Thanks for the response - it's a lot to take in and it's getting late so I'll read through it properly tomorrow.

Nighty, nighty!

#8 saddlejib

saddlejib

    Frequent Member

  • Advanced user
  • 270 posts
  •  
    United Kingdom

Posted 26 September 2013 - 10:19 PM

@ Wonko

I think you missed "Schrödinger's cat" in you're response. :boxing:



#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 September 2013 - 10:34 PM

@ Wonko

I think you missed "Schrödinger's cat" in you're response. :boxing:

Naah, the problem has been solved in the meantime, the cat is definitely alive.

 

Spoiler

 

:cheers:

Wonko



#10 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 27 September 2013 - 12:08 PM

@Wonko
Thanks (as always) for the interesting information and links. I do not have the forensic experience to comment on the "False Equations" that you mentioned -


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


It appears that my title for this thread may have been misleading. The point of the original post was just to get some clarification about in what circumstances writes are carried out to the disk - anything else is interesting but doesn't actually answer this question. My fault for such a poorly worded post - sorry.

Sadly I do not have all of the necessary tools to hand and cannot carry out the tests you suggested. I have instead done a few more tests of my own (all in QEMU) based upon some of your suggestions.

1] I created a raw disk image using dd (for Windows)

2] I booted a DOS (Windows 98 SE) boot floppy and partitioned and formatted the raw disk image.

3] After step 2, I checked the disk image for a disk signature (extracted the MBR with dd and used tinyhexer) - no disk signature was present.

4] Booted a WinFE ISO and closed it straight down without doing anything

5] After step 4, I checked the disk image for a disk signature (extracted the MBR with dd and used tinyhexer) - a disk signature had been created and the disks MD5 checksum had (not surprisingly) changed.

6] Carried out step 4 again (using the disk image from step 2 which I had backed up). This time I checked the MountedDevices registry key. There was an entry for an unmounted device ("\??\Volume{**.." type entry) that corresponded to the disk signature added to the disk. See attached picture.NOTE - No "\??\Volume{**.." type key/entry was present for the X: drive (the WinFE RAM Disk) - I haven't really noticed this in the past.

7] I carried out step 4 yet again, this time using the raw disk image from step 1 which I had backed up. No disk signature was added and there were no entries in MountedDevices.


Based on this experiment I conclude that in the case of a hard disk created on a Windows 98 system, that has never been attached to a Windows NT based system, a disk signature is written to the disk.

Regards,

Misty

Attached Files



#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 September 2013 - 01:07 PM

The usage of grub4dos was suggested because it would allow the checking of the boot signature "at boot time" (without need to shut down the VM, extract the MBR, check it in tiny hexer, etc.), but if you are OK with your more complex procedure, that's fine :fine:.

 

Maybe  I am mis-reading your report  :ph34r:

You are essentially saying that you did THREE times the SAME step #4 on the SAME image and that you got two SAME results and one DIFFERENT. :w00t:

 

Or the last time you attempted to connect a completely 00ed image? :unsure:

 

Of course if the latter was the attempt WinFE would not have done anything.

 

You see, a completely zeroed image corresponds to a "non-initialized" disk (the pop-up that will come out if you try opening disk manager).

 

Try again, with disk manager, this time after having written to the completely 00'ed image hex values 55AA to offset 510 of the MBR. ;)

 

Even with the disk "initialized" as above, the mount manager will find not any volume and most probably it won't write the disk signature. :unsure:

 

 

Then, you need to test again (the partitioned image BUT with signature set to 0) and check that ON THE SAME booting the disk signature is written AND that the keys are present.

 

Re-check attentively that the WinFE settings are correct,  as I see it if the key \DosDevices\D: (in your case) is present, it means that the volume has been mounted AND attributed the drive letter D:, i.e. you can open a command prompt and run in it a DIR D: and have the listing of the files on the volume, whilst the essence of a WinFE is that that partition/volume should NOT be mounted at all.  :dubbio:

If you prefer, if the WinFE is actually correctly set, you won't have a drive D: accessible in it.

 

BTW, you didn't really read attentively my previous post :w00t:, I left a nice loophole/trap in the probability calculations which I expected you would have detected.

 

:cheers:

Wonko

 



#12 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 27 September 2013 - 05:07 PM

Maybe I am mis-reading your report

You are essentially saying that you did THREE times the SAME step #4 on the SAME image and that you got two SAME results and one DIFFERENT.

Or the last time you attempted to connect a completely 00ed image?

Of course if the latter was the attempt WinFE would not have done anything.

Just to confirm that the last test was with a raw (00'ed) image.
 

Re-check attentively that the WinFE settings are correct, as I see it if the key \DosDevices\D: (in your case) is present, it means that the volume has been mounted AND attributed the drive letter D:, i.e. you can open a command prompt and run in it a DIR D: and have the listing of the files on the volume, whilst the essence of a WinFE is that that partition/volume should NOT be mounted at all.


\DosDevice\D: is a CD drive - or more accurately the mounted ISO image file that WinFE was booted from. In the attaced picture -

  • 1st entry = \??\Volume{b32b... = Mounted ISO file
  • 2nd entry = \??\Volume{b32b... = hard disk image - with newly created disk signature (48 87 21 af)
  • 3rd entry = \DosDevices\D: = Mounted ISO file (same as 1st entry)
  • 4th entry = \DosDevices\X: = WinFE system drive
     

BTW, you didn't really read attentively my previous post , I left a nice loophole/trap in the probability calculations which I expected you would have detected.

Sleep deprivation is affecting my ability to take in information. I'll read it again when I've had a rest. For now it looks like you have set me more homework ;)

Regards,

Misty



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 September 2013 - 05:54 PM

\DosDevice\D: is a CD drive - or more accurately the mounted ISO image file that WinFE was booted from. In the attaced picture -

  • 1st entry = \??\Volume{b32b... = Mounted ISO file
  • 2nd entry = \??\Volume{b32b... = hard disk image - with newly created disk signature (48 87 21 af)
  • 3rd entry = \DosDevices\D: = Mounted ISO file (same as 1st entry)
  • 4th entry = \DosDevices\X: = WinFE system drive

Good :), then it means that a disk signature is needed anyway.
 
As I see it the "correct procedure" is to have the WinFE boot through grub4dos, have it check the disk signature being 00's and also the presence of the "Magic Bytes" and of at least one valid partition/volume) and warn the user, allowing him/her about the possible issue and allowing to decide to continue booting to the WinFE (and thus write a new disk signature).
What is needed is a "matrix", like:

  1. IF Disk Signature is 00's AND Magic Bytes are 55AA AND at least one volume/partition is in the MBR <- in this case a new Disk Signature will be written for sure, as demonstrated by your experiment
  2. IF Disk Signature is 00's AND Magic Bytes are 55AA AND NO volume/partition is in the partition table <- behaviour to be tested, but a warning about the fact that most likely a data recovery is needed should be issued IMHO
  3. IF Disk Signature is 00's AND Magic Bytes are NOT 55AA AND at least one volume/partition is in the partition table <- behaviour to be tested, but a warning about the fact that most likely a data recovery is needed should be issued IMHO
  4. IF Disk Signature is 00's AND Magic Bytes are NOT 55AA AND NO volume/partition is in the partition table <- behaviour to be tested, but most probably this is akin to the "all 00's" and thus nothing will be changed BUT a warning about the fact that most likely a data recovery is needed should be issued IMHO
  5. IF Disk Signature is NOT 00's <- In this case nothing will be changed and there is no need to warn the user

So, the output of the little grub4dos batch could be something like (example):

Disk Signature: 01 02 03 04

Volume(s) Found: (hd0,0), (hd0,1)

Magic Bytes: 55 AA

 

 

And we could use summing variables:

We could assign:

 the Ds variable a value of 100 if the Disk Signature is valid and of 0 if NOT valid (all 00's)

the Vs variable a value of 10 if at least one volume is found, otherwise 0

the Mb variable a value of 1 if 55AA, otherwise 0

Ds=0

Vs=10

Mb=1

then something like this (pseudocode):

set /a points= %ds%+%Vs%+%Mb%

if %Ds%==0 Echo Warning Disk Signature all 00's!
if %points%==11 Echo Warning by proceeding booting WinFE a new Disk Signature will be written && goto :next
if %points%==111 Echo Everything seems cool... & goto :next
if %Vs%==0 Echo Warning NO volume found!
if %Mb%==0 Echo Warning Magic Bytes NOT OK!
:next

could do....

:cheers:

Wonko

 



#14 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 27 September 2013 - 07:18 PM

@Wonko

2.IF Disk Signature is 00's AND Magic Bytes are 55AA AND NO volume/partition is in the partition table <- behaviour to be tested...


I started with a raw disk image (all 00's) and added the Magic Bytes (55AA) to offset 0x01FE

Booted WinFE - no entries were visible in the MountedDevice key, other than the expected ones for the CD and WinFE system drive.

Behaviour tested - twice (just to be sure) - on both occasions a signature was written to 0x01B8.

 

3.IF Disk Signature is 00's AND Magic Bytes are NOT 55AA AND at least one volume/partition is in the partition table <- behaviour to be tested...



Used a disk image containing one partition entry for a partition created using a Windows 98SE based DOS boot disk. This did not contain a disk signature (all 00's). Then 00'd the Magic Bytes.

Booted WinFE - no entries were visible in the MountedDevice key, other than the expected ones for the CD and WinFE system drive.

Extracted the MBR and checked for a disk signature - NONE had been added. The MD5 hash of the file remainded the same before and after booting WinFE with the disk image attached.

Regards,

Misty

#15 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 September 2013 - 11:17 AM

Very good :),

so, as expected, the "qualifying" is connected to the 0x55AA Magic Bytes being there or not (which is the same thing the triggers the "the disk needs to be initialized").

 

This would allow us (as an alternative, when the disk signature is missing) to - for imaging the PhysicalDrive only - to pre-boot overwrite the 55AA in the MBR with 0000 to have - for all the WinFE knows, a "non-initialized" disk, and prevent it from writing the disk signature. :dubbio:

 

Another possible approach would be, in the case of a situation where the WinFE would write a signature, besides "warning" the user, to offer him the possibility of writing the 01020304 one while still in the pre-boot environment. :unsure:

 

 

:cheers:

Wonko



#16 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 28 September 2013 - 06:05 PM

After some further testing I have more results to report.

It's important to note that I used a WinFE based on Windows 7 SP1 (WinPE version 3.1). This build/version of WinFE does not appear to set the disk or volumes as readonly. It does not auto mount any internal partitions/volumes and sets volumes on the internal disk as offline. I've not tested external disks and do not know how this version of WinFE handles them.

My test platform was QEMU. I used a hard disk that had been partitioned and formatted using a DOS bootable floppy (a Windows 98 SE boot disk). The disk image was only 1GB in size and the only partition was formatted as FAT32 and spanned the whole disk.

The disk image was then attached to a system from which WinFE was booted - a disk signature was consequently written to the disk as it had not previously had any disk signature. As mentioned in previous posts in this thread the writing of the disk signature appears to be automatic and unavoidable. All tests below were carried out using this same disk image.. My base image was therefore a hard disk image containing a valid disk signature and one FAT32 formatted partition.

After each of the tests were carried out, I checked the MD5 hash of the disk image file to monitor if any changes had been made.


1st test
Attached the disk and booted WinFE again, then closed the system down immeadiately after it had finished booting.


2nd test
Attached the disk and booted WinFE again.
Started Diskpart and ran the following commands -
* sel vol 1
* online vol
* exit
Shut down WinFE


3rd test
Attached the disk and booted WinFE again.
Started Diskpart and ran the following commands -
* sel vol 1
* online vol
* assign letter=s
* exit
Shut down WinFE


4th test
Attached the disk and booted WinFE again.
Started Diskpart and ran the following commands -
* sel vol 1
* online vol
* assign letter=s
* exit
On this test I checked the contents of the S:\ drive using the DIR command at a command prompt.
Shut down WinFE



Results
The MD5 checksums of the disk image file following the tests listed above were as follows -
* 05e626ca29290317c2e78f7eade03f1e - prior to any tests
* 05e626ca29290317c2e78f7eade03f1e - after 1st test
* 05e626ca29290317c2e78f7eade03f1e - after 2nd test
* 05e626ca29290317c2e78f7eade03f1e - after 3rd test
* a9f3b389a57de07236d452328b98ecb0 - after 4th test




Conclusion

Someone better qualified than me should consider doing some proper testing! At the very least someone else should verify my results.

As you can see from the results above, the physical act of mounting a parition does not in itself appear to make any changes to the disk (see test 3). For some reason mounting a partition and then viewing the contents of the mounted partition appears to somehow change the underlying disk structure - as evidenced by the MD5 checksum having changed (see 4th test). I repeated the 4th test, but this time used a43 File Manager to view the contents of the mounted partition. This again resulted in a changed MD5 checksum.

I then completed a new test using the same setup. This time I avoided using diskpart altogether and used the excellent wprotect.exe (Colin Ramsden's Write Protect Tool). I set the disk as readonly by running "wprotect.exe -i" > mounted the disk via the wprotect UI > browsed the mounted (and now read only) partition using a43 file manager > then shut down WinFE. The disk image file's MD5 checksum was not changed - indicating that no writes were carried out.



Observations/Thoughts

Someone better qualified than me should consider doing some proper testing! At the very least someone else should verify my results.

For some reason it was not possible to set the disk as readonly using the diskpart command line. It would have been useful to set the disk attributes as readonly in diskpart before carrying out the 4th test (mounting the partition and viewing it's contents).

If a partition is mounted, at what point is a Recycle bin ($Recycle.bin) created in WinFE/WinPE as this could create a write to the disk.

From what I recall, WinFE based on WinPE 4.0/5.0 automatically sets the disk as Readonly due to a different SanPolicy value being used. It may therefore be safer to use these versions.

Avoid using a 64-bit WinFE as the wprotect.exe will not run in an x64 environment. (Wonko will be pleased).

Regards,

Misty

#17 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 September 2013 - 06:29 PM

For some reason it was not possible to set the disk as readonly using the diskpart command line. It would have been useful to set the disk attributes as readonly in diskpart before carrying out the 4th test (mounting the partition and viewing it's contents).

This is what sounds "strange". :unsure:

It should be one of the "features".

Can you post the exact (Registry) WinFE settings in your build an the exact diskpart commands you issued (and their feedback)?

It seems to me like your WinFE build has this issue, or maybe it is "specific hardware dependent" :w00t:, compare with:

http://reboot.pro/to...kpart-problems/

 

:cheers:

Wonko



#18 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 28 September 2013 - 06:58 PM

I checked in the registry in the booted WinFE and the registry settings were present and correct -

HKLM\SYSTEM\ControlSet001\Services\mountmgr - NoAutoMount - 1
HKLM\SYSTEM\ControlSet001\Services\partmgr\Parameters - SanPolicy - 3

Following is my output from DiskPart -
Microsoft DiskPart version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: MINWINPC

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online         1024 MB      0 B

DISKPART> sel disk 0

Disk 0 is now the selected disk.

DISKPART> detail disk


Disk ID: 408B3C95
Type   : ATA
Status : Online
Path   : 0
Target : 0
LUN ID : 0
Location Path : PCIROOT(0)#PCI(0101)#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

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 1                             Partition   1023 MB  Healthy    Offline

DISKPART> sel vol 1

Volume 1 is the selected volume.

DISKPART> detail vol

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
* Disk 0    Online         1024 MB      0 B

Read-only              : No
Hidden                 : No
No Default Drive Letter: No
Shadow Copy            : No
Offline                : Yes
BitLocker Encrypted    : No
Installable            : Yes

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.

DISKPART> attribute vol
Read-only              : No
Hidden                 : No
No Default Drive Letter: No
Shadow Copy            : No

DISKPART> attribute vol set readonly

Volume attributes set successfully.

DISKPART>
Regards,

Misty

#19 bshavers

bshavers

    Frequent Member

  • Developer
  • 130 posts
  •  
    United States

Posted 28 September 2013 - 07:02 PM

You should try using Colin Ramsden's write protect app.  It's easier to use than Diskpart and handles drive toggling much better.



#20 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 28 September 2013 - 07:35 PM

You should try using Colin Ramsden's write protect app. It's easier to use than Diskpart and handles drive toggling much better.


I did mention the following in a previous post in this thread -

.....I then completed a new test using the same setup. This time I avoided using diskpart altogether and used the excellent wprotect.exe (Colin Ramsden's Write Protect Tool).


This is a fantastic tool, however it won't work in 64-bit builds. Not a problem for most people admittedly, and to be honest not a problem for me as I don't work in the forensic sector and just have an interest.

 

Also I've become a bit fed up with all the vague comments about WinFE in terms of when/if it performs any writes to disk and thought I'd try and seek some clarifiction - hence this thread. Little did I know I'd end up doing so much of the bl***y work - thanks Wonko :P

 

:cheers:



#21 bshavers

bshavers

    Frequent Member

  • Developer
  • 130 posts
  •  
    United States

Posted 28 September 2013 - 09:51 PM

Take a look at Colin's WinFE Lite at

 

On the testing, that is just the way it works with every tool....anyone that doesn't test their tools, especially their forensic boot discs, INCLUDING any of the freely downloadable Linux iso's from the Internet are taking a risk that the system will work as marketed.  I can give specific and personally known examples of examiners assuming something is working when they didn't test it or validate it, and ended up being wrong.

 

One thing to remember on any forensic boot disc, even a floppy boot disc (yes...a floppy...), is that given the right effort, you can circumvent write protection.  Even hardware write protection devices can be circumvented.  If you know what can circumvent write protection, then you know what not to do when using it.  That is just as important to know what to do when using them.



#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 September 2013 - 01:40 PM

@bshavers

With all due respect :), besides the very nice app by Colin, it would be interesting to (hopefully) get to understand WHY exactly diskpart commands seemingly sometimes work and sometimes don't, especially because the WinFE "docs/howto's" that you wrote cite the diskpart commands to be working.

If you prefer, if you reduce the matter as "use Colin Ramsden tool, that works better", the only thing we can do is to conclude that the "standard" WinFE is far from being a "safe" Forensic app, 

And no, while of course everyone should validate himself/herself a tool, it's Author should at the very least ensure that the advertised features work, i.e. this:

 

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

 

Should be written more or less as:

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

For unknown reason setting the disk as read-only through diskpart commands does not work sometimes, there is a nice app by Colin Ramsden that appears to work more consistently, but only for 32 bit WinFE.
Setting the volume to read-only does alter the disk.

 

 

 

@Misty

And you did some very good work, now we know something more about WinFE. :)

 

:cheers:

Wonko



#23 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 29 September 2013 - 02:34 PM

@bshavers
With all due respect :), besides the very nice app by Colin, it would be interesting to (hopefully) get to understand WHY exactly diskpart commands seemingly sometimes work and sometimes don't.....

  :good:  :good:  :good:

In my search for answers it looks like I've set my self a lot of work :loleverybody:
   

@Misty
And you did some very good work, now we know something more about WinFE. :)

Thank you.

I had originally planned to test the different WinPE/FE versions (2.*/3.*/4.0/5.0) but unfortunately they don't all boot on the QEMU test system I was using. I have therefore just moved on to using Virtual Box (a portable version I already had - can't remember which version/build) using a fixed sized .vdi file. Fingers crossed I'll be able to compare how the different WinPE/FE versions function.

 

The MBR appears to be at sector 16 in the fixed .vdi file with a header preappended to the disk image - is this standard, or does the offest of the MBR change?
 



#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 September 2013 - 03:50 PM

The MBR appears to be at sector 16 in the fixed .vdi file with a header preappended to the disk image - is this standard, or does the offest of the MBR change?
 

AFAICR it is not a "fixed" position, but I may well be wrong, it is a lot of time I don't check .VDI images (a "stupid" format, if I may, the most "intelligent" one being some of the VMware ones and the Microsoft .vhd - not because of the good MS guys, but only because they used the same "smart" idea of the Connectix guys, to append a sector, making static images identical to RAW ones).

http://reboot.pro/to...offset/?p=14502

http://www.911cd.net...pic=19155&st=22

 

:cheers:

Wonko



#25 misty

misty

    Silver Member

  • Developer
  • 703 posts
  •  
    United Kingdom

Posted 30 September 2013 - 07:11 AM

I have some very good news to report!

Following a series of tests similar to those I carried out using WinPE 3.1 it appears that WinFE based on WinPE 4 and 5 DOES NOT WRITE A DISK SIGNATURE (x86 builds 6.2.9200 and 6.3.9431 tested).
 
Using a disk image without a signature there were no changes to the disk image before or after booting WinFE - as evidenced by the files MD5 checksum.
 
The disk was flagged as readonly on booting WinFE and was write protected. It was not possible to "ONLINE" the disk in diskpart - this command failed. It was therefore not possible to mount any partitions on the disk, however they were accessible using third party tools for imaging purposes.
 
In a subsequent test I manually wrote a disk signature to the disk image and rebooted WinFE. It was possible to ONLINE the disk in diskpart and mount the partition when the disk signature was present on the disk. I checked the MD5 hash of the modified disk image before and after booting WinFE and it remained unchanged.
 
In another test with a 00'd disk signature it was possible to use the Write Protect Tool to online the disk (after removing the readonly flag in the wprotect UI) and mount the partition - a disk signature was written as part of this process.
 
I used a SanPolicy value of 4 during these tests.
 
I'm in the process of writing up the results and will report back when this is finished - probably in a couple of days.

Regards,

Misty




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users