Thanks much - your foo is strong 😉
You said that the image was of a freshly formatted thumb drive. Depending on what was used to format the drive, there may still be significant data on the system…later versions of Windows have switch for format that will overwrite with zeros. If this was not used, you may be able to get something of value via file carving or strings.
Part of the issue here is that when a thumb drive (as opposed to a ext HDD) it connected to a system, the data retained in the Registry does not include the volume serial number. Most of what is used to track thumb drives is contained in the device descriptor, which is NOT part of memory.
Another important component for tracking thumb drives is the ParentIdPrefix value.
Here's what I did…I formatted a thumb drive FAT16 via Windows XP (drive G\, volume serial number 6403-CD1C) , and opened the physical drive in FTK Imager 2.7. Checking the offsets, I verified that the file system is FAT16, and I also verified the volume serial number.
Now, the problem is that this information actually exists in the Registry, but only on the live system…the path is in the NTUSER.DAT, under
Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\
Volume\{GUID}
Beneath this path, the Data value contains information from the device itself…but the CPC key itself is volatile. Within the Data key, at offset 0x294, the DWORD contains the volume serial number…but again, the contents of this key are volatile.
So, at this point, we can map thumb drives between the System and NTUSER hive files, but it would appear that key information about the devices are not saved.
I'd suggest carving the FAT16 image, and running strings, as well as running regslack against the hives, and see what you have available.
The image file, what file system is it, some systems actually embede a volume label within the image file depending on the format. however the volume name is not a required field of the Fat32 or Fat12/16 FS so I am not sure if that would be the best route. There are programs to load the registry and parse it to allow compairisons and looking at the image's first 1k of bytes may help identify the drive image.
I hope it helps I may be wrong about the above i remembered it from reading Brian Carriers book (File Systems Analysis) on Fat12-32.
As mentioned, the volume serial number, label and format is maintained in a volatile key within the NTUSER.DAT file.
Any chance of getting copies of the files?
Harlan,
Just a clarification I question I have
So we know that the firmware holds the serial number so the reg keys get stamped.
In your book you wrote (ch.4 206-219) about USB devices and the interfaces with the registry. You do mention the MBR containing the drive signature. I should be testing this instead of posing the question, but do other partition areas contain any drive signatures in hex that can be matched to the MountedDevices key - or is it just in the MBR?
As mentioned, the volume serial number, label and format is maintained in a volatile key within the NTUSER.DAT file.
Any chance of getting copies of the files?
You can still sign up for the Challenge lol
Doug,
Just a clarification I question I have
So we know that the firmware holds the serial number so the reg keys get stamped.
This is correct. The device descriptor/firmware may contain a serial number…while required for the Windows Logo program, it's not required to function. If the device descriptor does not contain a serial number, the PnP Manager creates one, which is identified by the second character being "&". Note that this is NOT the ParentIdPrefix, which is a Registry value, but rather it is the pseudo-serial number assigned and is a key name.
In your book you wrote (ch.4 206-219) about USB devices and the interfaces with the registry. You do mention the MBR containing the drive signature. I should be testing this instead of posing the question, but do other partition areas contain any drive signatures in hex that can be matched to the MountedDevices key - or is it just in the MBR?
The MBR contains a drive signature, which is specific to ext HDDs and NOT thumb drives.
As to partitions, as I mentioned above, the volume serial number can be extracted from the partition(s) on a thumb drive, along with format, etc, and added to the MountPoints2\CPC\Volume\{GUID}\Data value, but again, the CPC key appears to be volatile.
This is correct. The device descriptor/firmware may contain a serial number…while required for the Windows Logo program, it's not required to function. If the device descriptor does not contain a serial number, the PnP Manager creates one, which is identified by the second character being "&". Note that this is NOT the ParentIdPrefix, which is a Registry value, but rather it is the pseudo-serial number assigned and is a key name.
wink
hi all Sorry for miss the interesting discussion.
I dont think every device has its particular number.
For this
pbobby
You'd better check out the ID (http//
Then you compare them
(HEKY_L_M…SYSTEM…ControlSet001…Enum…USBSTOR)
I dont think every device has its particular number.
No, not every device does. Many thumb drives don't have serial numbers, hence the explanation of how one is created by the Windows PnP Manager.
Also, thumb drives have the ParentIdPrefix…external drives generally do not.
keydet89
Thanks a lot .
Could you recommend me some courese/papers about how to decode registry data .
You know , we can use "ROT13" to see the information of times, but the data which I think is aslo the key point.
I appreciate that if you can.