I use GetSystemIdForPublisher() to identify machine IDs. According to the documentation they are unique, but I have a handful of machines which return the same ID. These machines are completely unrelated and have no common history. They are located in different countries and belong to different users. The Windows version of these machines is the latest Windows 1909 10.0.18363 update.
The documentation clearly states:
The method will first attempt to use the Trusted Platform Module
(TPM), if present, to get an ID. If a TPM is not present, the method
will try to get an ID from the Unified Extensible Firmware Interface
(UEFI). If neither of these sources is available, this method will
return an ID that is backed by the Windows registry. In the case of
the Windows registry, the ID will not satisfy all the above
guarantees. For example, if a system does not have a TPM or UEFI
support, and thus an ID was obtained from the registry, a clean
install of Windows will result in a new, different ID being returned.
Callers of this method should refer to the Source property of the
returned SystemIdentificationInfo to determine where the ID was
obtained from in order to understand the guarantees provided.
As far as I can see, none of these statements explain to me what is happening here. Does anyone else have an idea whats going on? Any help is highly appreciated!
Addendum:
we got feedback in form of a cpu-z report from 2 persons on 2 different continents with the same machine id:
user A:
Mainboard Model Z87M Extreme4 (0x00000444 - 0xECE9B6D4)
UEFI Yes
BIOS Vendor American Megatrends Inc.
BIOS MSG 63-0100-000001-00101111-1xxxx5-Chipset
BIOS Date 12/10/15
Mainboard Vendor 000001
user B:
Mainboard Model 151-BE-E097 (0x0000025D - 0x0A74C7F0)
UEFI Yes
BIOS Vendor American Megatrends Inc.
BIOS MSG 63-0100-000001-00101111-0XXXX5-Chipset
BIOS Date 09/10/15
Mainboard Vendor 000001
both got the same identifier when calling GetSystemIdForPublisher():
XlPRXXXlAPXk-yFXXXJUv3-XXXXXXXXXXXXX = [source is UEFI, ]
==> X included for obfuscation
We have around 60 customers worldwide whose computers return this exact ID.
Related
Lets take the 1st step when the CRTM measures the Bios it extends the hash value to the PCR located in the TPM. Before passing control to the bios it must be a verification of hash values. My question is there an agent (third party) to commit this verification? or PCRs has a default set, so each time extending hash values these values must correspond to the PCR default hash before passing the control to bios?
It depends. In some implementations, the CRTM is a part of BIOS, so you have to implicitly trust the first boot block of BIOS to be loaded, which then verifies the rest of the BIOS. In other implementations, such as with Intel's AMT, the CPU measures the BIOS independently.
What you asked is the PCR values from so-called "golden measurement" or "baseline measurement", which can be conducted by the platform manufacturer such as DELL or platform administrator like your department IT. Those values are saved and used for verification by TPM. This is part of the "provisioning process".
Please check the book "TCG TPM v2.0 Provisioning Guidance" for section 10 and section 11.
I have a kmdf bus driver PCI\VEN_XXXX&DEV_XXXX that creates two statically enumerated PDOs with serial numbers: 217 and 218; one for each Ethernet port. The PDO hardware id is ROOT\MY_NIC_PORT so I can install a NDIS Miniport driver on them.
The bus driver passes SDV and Verifier; but, on reboot two more PDOs get enumerated. On the next reboot I get a duplicate pdo crash.
The toaster example used the device class guid as part of the hardware id. When I tried that my NIC ports no longer showed up in device manager.
Any debug suggestion or work around idea would be appreciated?
pnpCaps.LockSupported = WdfFalse;
pnpCaps.EjectSupported = WdfTrue;
pnpCaps.Removable = WdfTrue;
pnpCaps.DockDevice = WdfFalse;
pnpCaps.UniqueID = WdfTrue;
pnpCaps.SilentInstall = WdfTrue;
pnpCaps.SurpriseRemovalOK = WdfTrue;
pnpCaps.HardwareDisabled = WdfFalse;
pnpCaps.NoDisplayInUI = WdfFalse;
pnpCaps.Address = SerialNo;
pnpCaps.UINumber = SerialNo;
************************************************************
Driver Verifier detected violation:
A driver has enumerated two child PDO's that returned identical Device
ID's.
CulpritAddress = FFFFF8025ED309C4, DeviceObject1 = FFFFE3882FB2F300,
DeviceObject2 = FFFFE3882EBF88D0.
************************************************************
There are a few versions of the toaster bus sample -- assuming you started with this one, then note that it saves its list of child PDOs in the registry. My guess is that your driver is both loading PDOs from the registry, and trying to dynamically create some too.
Set a breakpoint on your driver's version of Bus_PlugInDevice, and see how often it's getting called. Make sure it's never getting called 2x with the same Instance ID.
To clear up a bit of the naming thing: a device setup class is a GUID that is totally unrelated to its hardware ID. For NICs that want to interoperate with the OS's networking stack, you must use the NET setup class, {4d36e972-e325-11ce-bfc1-08002be10318}. You can put anything you want into your hardware ID. I don't really encourage you to put "ROOT\" in there, since that could be confused with a root-enumerated device (which your devices are not). Instead, you can use "yourcompany_yourdevice\port1" as a hardware ID.
While you're thinking about naming things, there are a few things to note about hardware IDs:
Once you assign a HWID, it's rather difficult to change it in a future driver update, without breaking customers who had already installed your device. So get it right the first time.
Once you assign an Instance ID, don't change or reuse it for the lifetime of the device. Otherwise you'll cause this bugcheck, or cause IP addresses to bounce around / get reset. The OS ultimately uses the Instance ID to figure out which NIC port to bind an IP address to.
Think about what happens if someone plugs 2 of your device into a system. Make sure your Instance ID is unique across all ports. You can do this by encoding into the Instance ID the PCI device serial number (if it has one) or by falling back to the PCI bus:device:function.
Don't lump together different types of hardware under the same hardware ID. For example, if the deluxe version of your device supports checksum offload, but the regular version does not -- you should use 2 different hardware IDs for these two different devices. Otherwise it gets difficult to write a single INF that has keywords for both.
I am trying to configure SNMP on Ubuntu 14.04. There is a step where I have to edit the community string along with sysLocation and sysContact but I am not sure what goes there. What are the sysLocation and sysContact objects in the snmpd.conf file and how I can get those values for my machine?
All SNMP devices share the following common configurable parameters:
sysLocation
sysContact
sysName
Read-write and read-only access
community strings (and frequently, a trap community string)
Trap destination
sysLocation is the physical location for the device being monitored. Its definition in RFC 1213 is:
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The physical location of this node (e.g., 'telephone closet,
3rd floor')."
::= { system 6 }
RFC 1213's definition of sysContact is similar to that of sysLocation:
sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person for this managed
node, together with information on how to contact this person."
::= { system 4 }
sysContact is a DisplayString. It's fairly obvious what it's used for: it identifies the primary contact for the device in question. It is important to set this object with an appropriate value, as it can help your operations staff determine who needs to be contacted in the event of some catastrophic failure. You can also use it to make sure you're notified, if you're responsible for a given device, when someone needs to take your device down for maintenance or repairs. As with sysLocation, make sure to keep this information up to date as your staff changes. It's not uncommon to find devices for which the sysContact is someone who left the company several years ago.
source: http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch07_01.htm
SysLocation and SysContact are simply arbitrary SNMP string variables that are part of SNMPV2-MIB and can be fetched with SNMP get.
OID 1.3.6.1.2.1.1.4 == SysContact
OID 1.3.6.1.2.1.1.6 == SysLocation
Most sites I have been involved with use SysLocation as a decription of the location of the SNMP managed network device, and SysContact as the contact details of somebody who is in some way responsible for the device.
Warning: SysContact also has a habit of becoming out of date without being modified when staff changes.
To get sysContact using snmpget command line:
snmpget -v1 -c public localhost system.sysContact.0
where "public" is your community string, and "localhost" is the ip address of the machine you want to send the SNMP query to.
These values are defined by the administrator. Common formats include:
syslocation Rack, Room, Building, City, Country [GPSX,Y]
syscontact Your Name <your#email.address>
If all the equipment you monitor is in the same country you can use the format google maps uses: "street, city, state zip". For example searching google maps for the white house returns:
1600 Pennsylvania Ave NW, Washington, DC 20500
syslocation is often used my monitoring applications to generate visual maps.
There are various ways to retrieve the Windows "Device Name" of a HID device, GetRawInputDeviceInfo with RIDI_DEVICENAME being one way to do it.
Given the example name:
\?\HID#VID_FEED&PID_DEAD#6&3559c8ea&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}
I'm wondering if there is any documentation whatsoever on what is what in this string?
\?\HID#VID_AAAA&PID_BBBB#C&DDDDDD&E&FFFF#{GUID}
So the obvious ones are A(VID), B(PID) and the GUID on the end. What I'm wondering is what EXACTLY are C, D, E and F?
It seems that C and D are unique even if you plug in two of the exact same HID devices which is great for my problem, but I'd feel more comfortable if I could know exactly how this is determined on a per OS basis, or at least that it follows some known format.
I have been googling like a madman trying to figure this out, am I missing something obvious?
Thanks in advance
According to a similar MSDN post, the value represents a unique device instance ID:
the device instance ID is unique and constant for the physical
location the device is plugged into, but it is also opaque and should
not be parsed. that means it can be used for string comparison, but
not for interpretation.
It is actually device interface instance id (symbolic link name). And yes, its unique and persists across system restart. Some details also here.
You can use CM_Get_Device_Interface_Property or SetupDiGetDeviceInterfaceProperty on interface instance id with DEVPKEY_Device_InstanceId to get device instance id (one device can have multiple interfaces).
In your example - you have a HID device. Its device id format is described here.
Info on general USB devices id format is here.
After you have device instance id you can use CM_Get_DevNode_Property or SetupDiGetDeviceProperty with DEVPKEY_NAME to get localized friendly name of a device (which is shown in Device Manager).
To sum up:
\\?\HID#VID_203A&PID_FFFC&MI_01#7&2de99099&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd} - is device interface id (also referred as "device interface path" or "device name" in docs). This is path in virtual device file system.
{378de44c-56ef-11d1-bc8c-00a0c91405dd} - device interface class guid (GUID_DEVINTERFACE_MOUSE in this case. It determines which IOCTLs can be called on this device. IOCTL_MOUSE_QUERY_ATTRIBUTES in this case)
HID\VID_203A&PID_FFFC&MI_01\7&2de99099&0&0000 - is device instance id
NOTE: exact device interface id format is not documented, each device interface can generate file name it want. I don't recommend you to parse it - it could be changed in later Windows version, better aquire device instance id - it is documents at least.
How to uniquely identify computer (mainboard) using C#(.Net/Mono, local application)?
Edition. We can identify mainboard in .Net using something like this (see Get Unique System Identifiers in C#):
using System.Management;
...
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_MotherboardDevice");
...
But unfortunately Mono does not support System.Management. How to do it under Mono for Linux? - I don't know :(
Write a function that takes a few unique hardware parameters as input and generates a hash out of them.
For example, Windows activation looks at the following hardware characteristics:
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
You can pick up a few of them to generate your unique computer identifier.
Please see: Get Unique System Identifiers in C#
You realistically have MotherboardID, CPUID, Disk Serial and MAC address, from experience none of them are 100%.
Our stats show
Disk serial Is missing 0.1 %
MAC Is missing 1.3 %
Motherboard ID Is missing 30 %
CPUID Is missing 99 %
0.04% of machines tested yielded no information, we couldn't even read the computer name. It maybe that these were some kind of virtual PC, HyperV or VMWare instance, or maybe just very locked down? In any case your design has to be able to cope with these cases.
Disk serial is the most reliable, but easy to change, mac can be changed and depending on the filtering applied when reading it can change if device drivers are added (hyperv, wireshark etc).
Motherboard and CPUID sometimes return values that are invalid "NONE", "AAAA..", "XXXX..." etc.
You should also note that these functions can be very slow to call (they may take a few seconds even on a fast PC), so it may be worth kicking them off on a background thread as early as possible, you ideally don't want to be blocking on them.
Try this:
http://carso-owen.blogspot.com/2007/02/how-to-get-my-motherboard-serial-number.html
Personally though, I'd go with hard drive serial number. If a mainboard dies and is replaced, that PC isn't valid any more. If the HDD drive is replaced, it doesn't matter too much because the software was on it.
Of course, on the other hand, if the HDD is just moved elsewhere, the information goes with it, so you might want to look at a combination of serial numbers, depending what you want it for.
How about the MAC address of the network card?