When using regripper, I'm presented with the following
\??\Volume{ddd55bc2-6913-11e4-a4df-806e6f6e6963}
Drive Signature = 66 bf 92 34
\DosDevices\C
Drive Signature = 66 bf 92 34
\??\Volume{0fea365c-78a2-11e4-82b7-00a0c6000012}
Drive Signature = 30 73 55 7d
\DosDevices\D
Drive Signature = 27 2e 0a c5
\??\Volume{5371ac20-7a2e-11e4-9e9f-8019346de8ee}
Drive Signature = 7f 29 e3 19
\DosDevices\E
Drive Signature = 7f 29 e3 19
\??\Volume{17d0b573-827e-11e4-bb62-8019346de8ee}
Drive Signature = a4 b5 73 00
\??\Volume{17d0b5ca-827e-11e4-bb62-8019346de8ee}
Drive Signature = 4e 15 7f fc
\??\Volume{338de6c2-9b9f-11e4-b227-8019346de8ee}
Drive Signature = 27 2e 0a c5
I'm assuming that I should match drive signature up to current drive signature that's assigned to the drive letter? For example, E
\DosDevices\E
Drive Signature = 7f 29 e3 19
Would mean that the volume
\??\Volume{5371ac20-7a2e-11e4-9e9f-8019346de8ee}
Drive Signature = 7f 29 e3 19
is the last usb device that was assigned this drive letter? Also, I'm trying to do some correlation, and I noticed that the volume guid above \Volume{5371ac20-7a2e-11e4-9e9f-8019346de8ee} doesn't match the Partmgr under USBSTOR for that volume, but it's close. Is there any documentation discussing why the partmgr id may be 5371ac1e-7a2e-11e4-9e9f-8019346de8ee but the volume guid begins with 5371ac20?
And finally, when regripper shows volumes that aren't associated to any device, is it safe to say that the drive was attached, but another drive was attached at a later date that overwrote the last association? If that's the case, why do I see multiple disk signatures as above that seem to be associated with that drive letter at one time?
Thanks!
Loosely, the assignment of a volume letter happens on a "first come first served" basis, so it is perfectly normal that when a drive letter is assigned to Volume #1 (on disk #1), but the disk is later disconnected and another one is reconnected, the same drive letter (that at the moment is "free") is assigned to the next connected volume (let's say Volume #2 on disk #2).
This plainly overwrites any assignment as \DosDevicesx of the drive letter (while the actual "Volume{GUID}" in \MountedDevices remains "sticky"), in other words normally you have more keys of the form "Volume{GUID}" than keys in the form "\DosDevicesx "in \MountedDevices.
The issue is sometimes that the behaviour is not always "constant", there are drivers that may make a drive letter "sticky" until a reboot is performed, and a drive letter may have been assigned to a volume on a different device (such as say a Ramdisk).
Also I personally (and most of the world BTW) call the signature a DISK Signature (as a Disk can have more than one volume) and the actual entries in \MountedDevices contain BOTH the Disk Signature AND the offset (in sectors) to the beginning of the volume, having a dump of the \MountedDevices would allow to list the volumes on multivolume disks. (at first sight it seems like all the volumes in your list were on disks with single volumes only, I wonder if this offset "omission" by RegRipper is "intentional" because of this or if the same happens on multi-volume disks).
It seems to me that the output you posted is a bit "confusing", I would try making a "pairing" between volumes and drive letters manually, the
\DosDevices\D
Drive Signature = 27 2e 0a c5
Seemingly corresponds to the last volume
\??\Volume{338de6c2-9b9f-11e4-b227-8019346de8ee}
Drive Signature = 27 2e 0a c5
but without the offset it could be another volume.
About GUID, check
https://www.forensicfocus.com/Forums/viewtopic/t=15034/
the mechanism to assign the GUID should be the same.
C\temp>uuid -d 5371ac20-7a2e-11e4-9e9f-8019346de8ee
encode STR 5371ac20-7a2e-11e4-9e9f-8019346de8ee
SIV 110916144342728347800235878150336014574
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2014-12-02 142011.500035.2 UTC
clock 7839 (usually random)
node 8019346de8ee (global unicast)
C\temp>uuid -d 5371ac1e-7a2e-11e4-9e9f-8019346de8ee
encode STR 5371ac1e-7a2e-11e4-9e9f-8019346de8ee
SIV 110916144184272022771707202963248113902
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2014-12-02 142011.500035.0 UTC
clock 7839 (usually random)
node 8019346de8ee (global unicast)
seemingly the "5371ac1e" happened immediately before "5371ac20", which makes sense, as there must be a very small delay between what the partmgr and the volume manager do.
jaclaz
Thanks jaclaz!
