USB Devices and the...
 
Notifications
Clear all

USB Devices and the Windows Registry

11 Posts
4 Users
0 Likes
2,312 Views
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

All,

Cory Altheide and I are conducting some research into USB devices and the Windows Registry. In doing so, I've been trying to get in contact with folks at Microsoft to answer some questions with regards to the creation of certain Registry keys…most of the contacts have been several layers removed from me.

I'd like to ask the questions here, as well, to see what kind of response I can get back from the community.

Our basic questions are these:

1. When you connect a USB storage device to a Windows system (2K, XP, 2K3), Registry keys are created. If they don't already exist, the HKLM\System\CurrentControlSet\Enum\USBStor key is created. Beneath that key, a subkey containing the vendor name is created, and beneath the "vendor key", a key with a unique name is created for each device (I'll call this the "unique key"). On a test XP system, it looks like this:

HKLM\System\CurrentControlSet\Enum\USBStor
\Disk&Ven_LEXAR&Prod_DIGITAL_FILM&Rev_/W1.
\7&276114a5&0&______________040719030000008093F300000000000&0

According to some scant MSDN documentation, the final key name is unique to the device…each time the device is plugged into the Windows system, the same name will be used. Also, if the device is plugged into other Windows systems, the same name will appear.

The question is, how is this key name created? If something specific is pulled from the device, what is that artifact? How is it retrieved; ie, via what API and data structure? How is it then processed to develop the name of the "unique key"?

2. Within the "unique key", there is a value called "ParentIdPrefix". How is this value derived? What API/data structure is used? How does the system then subsequently use this value?

Thanks. Any assistance, along with cited sources, would be greatly appreciated. Cory and I do intend to make the final results of our research public.

Thanks,

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

 
Posted : 01/02/2005 12:48 pm
(@gmarshall139)
Posts: 378
Reputable Member
 

I have verified what you are stating, a unique id is assigned to every device attached in the registry. It is indeed the same id assigned by another operating system for the same device. That only leaves us with determining how that happens. It's in the firmware for the device. The way to verify this is to flash a device's bios and check for a change in the value in the registry.

I don't have anything I want to flash right at the moment, however, on one of my forensic machines I had a zip 750 connected via USB. I had to update the firmware due to a conflict with the motherboard. It is the only zip 750 that has ever been attached to this machine. There are two values in the registry under the zip 750 folder. They have different "unique keys" and different "parentidprefix". The only different value is the "capabilities" key, on one its 0 and the other is 16. I don't know what that key is for.

By the way, this is all from a 2000 system.

 
Posted : 01/02/2005 1:31 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

Greg,

Thanks for the reply.

That only leaves us with determining how that happens.

That's exactly what I'm asking.

It's in the firmware for the device.

Correct. As I stated in my initial post, I'm trying to discover the API calls and data structures used within Windows systems to handle this.

The way to verify this is to flash a device's bios and check for a change in the value in the registry.

You're correct that this goes towards verifying that the data being used is pulled from the firmware, but it doesn't address the question posed in my initial post at all.

If you go back and look at my initial post, I asked:

The question is, how is this key name created? If something specific is pulled from the device, what is that artifact? How is it retrieved; ie, via what API and data structure? How is it then processed to develop the name of the "unique key"?

I'm aware that the information is pulled from the firmware, but what I'm looking for is what artifact is retrieved from the firmware.

Also, you said:

The only different value is the "capabilities" key…

For the sake of clarity, the Capabilities value isn't a key, it's a value. Keys are what you're referring to as "folders". This is an important distinction, not only for the sake of the conversation, but also do to the fact that Registry keys have a value referred to as the LastWrite time (analogous to the last modification time on a file), while values do not. I've already written a Perl script to correlate information from within the Registry, as well as display the LastWrite times.

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

 
Posted : 01/02/2005 4:37 pm
(@gmarshall139)
Posts: 378
Reputable Member
 

I apologize for not answering your questions, it's just that I don't have the answer either, at least not beyond what you've already discovered. I just thought I would provide an example for the benefit of others who may currently, or in the future, reference this post.

In the practical application of computer forensics, it may well be sufficient to know that these things happen, know a little about why these things happen, and know how to apply that knowledge to help prove the facts in a particular examination. That being said I do appreciate your motivation to look further into the problem.

 
Posted : 01/02/2005 6:15 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

In the practical application of computer forensics, it may well be sufficient to know that these things happen,

In a sense, you're right. But what I'm trying to do is not only map this information, but back it up with documentation, as well, so that this information can, in fact, be used to support cases. After all, you can't expect an agent to go to court based on information he read off of a web site someplace.

Guess I'll keep looking…

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

 
Posted : 01/02/2005 8:20 pm
(@gmarshall139)
Posts: 378
Reputable Member
 

After all, you can't expect an agent to go to court based on information he read off of a web site someplace.

When I worked the road, and did a lot of radar, we were occasionally challenged in a similar way. To operate the radar I need to understand a bit about the theory of it's operation, ie. how it works, but I don't need to know how to build one. The courts have backed this up many times.

But again I commend you for your effort. If an entire case hinges on this very issue, the examiner will be glad you took the effort to get to the bottom of it. I'm suprised by how much of the Windows operating system is really not well understood by anyone, including those who wrote it.

 
Posted : 01/02/2005 8:46 pm
(@jeffcaplan)
Posts: 97
Trusted Member
 

Just out of curiosity, your research wouldnt have anything to do with something like this now, would it? If so, I appreciate the research.

Jeff Caplan

 
Posted : 01/02/2005 11:44 pm
 Andy
(@andy)
Posts: 357
Reputable Member
 

Don't jump over this post if I am wrong….. But is it possible the value you have identified is something to do with the GUID issued by NTFS (v 3.0 + 3.1 - i.e. Windows 2k & XP), whenever a volume is detected? GUIDS are logged within the $Objid metadata file. The GUID is used to spot volume tracking changes……

I will do some research and get back with what I find….

Again I might be barking up the wrong tree, and the $Objid may be just for tracking files, I just don't know enough about it - but its a suggestion.

Andy

 
Posted : 02/02/2005 12:42 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

Jeff,

No, the research doesn't have to do with write blocking technologies. What Cory and I are trying to do is show/verify footprints of USB-connected devices on Windows systems.

Andy,

…is it possible the value you have identified is something to do with the GUID issued by NTFS (v 3.0 + 3.1 - i.e. Windows 2k & XP)

It may be possible, as there is a GUID associated with the mounted devices. However, it's not clear where these values…the GUID you mention, and the values I'm asking about…are computed.

Also, what do you mean when you say "…NTFS (v 3.0 + 3.1 - i.e., Windows 2k & XP"? Are you trying to say that NTFS version 3.0 is what's running on Windows 2000? Check this out:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q186750&ID=KB;EN-US;q186750

Windows NT 4.0 was running NTFS 4.0. Windows 2000 runs NTFS version 5.0.

thanks for the replies, guys. I think some useful stuff has been mentioned for the group at large, but the responses also demonstrate the difficulty I'm having in supporting my research…there just doesn't seem to be a great deal of information available.

Thanks,

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

 
Posted : 02/02/2005 11:39 am
 Andy
(@andy)
Posts: 357
Reputable Member
 

Harlan,

Versions of NTFS: -

NTFS v.1 = Used with Windows NT 3.x with support for FAT 12, 16, NTFS (itself)
v.1.2 = Used with Windows NT 4.0 with support for FAT 12, 16, NTFS, CDFS, HPFS
v.3.0 = Used with Windows 2000 with support for FAT 12, 16, 32, NTFS, CDFS, HPFS
v.3.1 = Used with Windows XP (as above)

I think the version 5 reference is a misnomer, often used (even by some Microsoft staff) incorrectly. If you want to check what version NTFS you are running (i.e. Windows XP = NTFS version 3.1) open a command prompt and type: -

"fsutil fsinfo ntfsinfo <volume>:" (without the quotes)

<volume> is obviously the volume where your Windows OS resides.

Check this out: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q310749

There is a handy 'Note' halfway down the page that say's "Microsoft Windows 2000 uses NTFS 3.0. NTFS 3.0 and 3.1 have compatible on-disk formats, so volumes upgraded to NTFS 3.1 by Windows XP can continue to be accessed by Windows 2000 or by Windows NT 4.0 with SP4 or later"

In any case back to the GUID/HKey thingy - I'll ask some of my colleagues and contacts about the registry naming convention, and how the calculation is made.

Andy

 
Posted : 02/02/2005 12:22 pm
Page 1 / 2
Share: