Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMBIOS UUID Does not Match WMI UUID - Appears Inaccurate #18

Open
thinlaunch opened this issue Jan 27, 2018 · 3 comments · May be fixed by #29
Open

SMBIOS UUID Does not Match WMI UUID - Appears Inaccurate #18

thinlaunch opened this issue Jan 27, 2018 · 3 comments · May be fixed by #29

Comments

@thinlaunch
Copy link

If I issue wmic csproduct get uuid (WMI get SMBIOS UUID) it returns the following string:
81462904-7B5D-E111-ADCD-2C27D725B21D

Delphi uSMBIOS returns: 042946815D7B11E1ADCD2C27D725B21D

The last 16 bytes are always the same but the first 16 and different.

For example:
814629047B5DE111-ADCD2C27D725B21D
042946815D7B11E1-ADCD2C27D725B21D

Can you please assist? Is this a bug?

@thinlaunch
Copy link
Author

It appears the first (3) fields are encoded in little-endian for SMBIOS Ver >=2.6. Here is the info from the document and a suggested order:

Although RFC4122 recommends network byte order for all fields, the PC industry (including the ACPI,
UEFI, and Microsoft specifications) has consistently used little-endian byte encoding for the first three
fields: time_low, time_mid, time_hi_and_version. The same encoding, also known as wire format, should
also be used for the SMBIOS representation of the UUID.
The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented as:
33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
If the value is all FFh, the ID is not currently present in the system, but it can be set. If the value is all 00h,
the ID is not present in the system.

The array order would be:
first 8 bytes: p[3], p[2], p[1], p[0], p[5], p[4], p[7], p[6],
last 8 bytes:p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]

I will work on a patch for the PAS file.

@GitStorageOne
Copy link

I will work on a patch for the PAS file.

Still WIP?

@caryyu caryyu linked a pull request Dec 28, 2024 that will close this issue
@caryyu
Copy link

caryyu commented Dec 28, 2024

It appears the first (3) fields are encoded in little-endian for SMBIOS Ver >=2.6. Here is the info from the document and a suggested order:

Although RFC4122 recommends network byte order for all fields, the PC industry (including the ACPI, UEFI, and Microsoft specifications) has consistently used little-endian byte encoding for the first three fields: time_low, time_mid, time_hi_and_version. The same encoding, also known as wire format, should also be used for the SMBIOS representation of the UUID. The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented as: 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. If the value is all FFh, the ID is not currently present in the system, but it can be set. If the value is all 00h, the ID is not present in the system.

The array order would be: first 8 bytes: p[3], p[2], p[1], p[0], p[5], p[4], p[7], p[6], last 8 bytes:p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]

I will work on a patch for the PAS file.

Thanks for your explanation, here's the PR to resolve: #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants