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
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:
- 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)
- 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)
- 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:
- 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
- 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
- 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.
Wonko