[ad_1]
My previous post was to figure out the format of an Autopilot (OAv3) hash. But there’s more to that intellectual exercise than the exercise itself, because I wanted to be able to create a hash myself, from scratch. When you know the format, you can “invent” your own machine. For example:
And then I should be able to import that as a new Autopilot device:
Other than creating entertaining devices, that doesn’t achieve much though — it’s not like I can actually deploy that device. It’s more interesting if I can create an Autopilot hash that works with a real device, because then I can play around with different combinations of information to see the minimum amount of data needed or different combinations of data that can be used.
Going back to the first blog post, here’s the list of “values that matter”:
ProductKeyIDSmbiosSystemManufacturerSmbiosSystemProductNameSmbiosSystemSerialNumberSmbiosSkuNumberSmbiosSystemFamilyMacAddressSmbiosUuidDiskSerialNumberTPMEkPub
After messing around with various combinations, I still haven’t been able to actually make one work, and at present I’m don’t have time to play with it any more. But if you’d like to experiment yourself, try out the AutopilotUtility PowerShell module that I posted to the PowerShell Gallery. It includes two cmdlets:
- ConvertFrom-AutopilotHash. This decodes one or more Autopilot hashes, like OA3TOOL can do. I covered this one in the previous blog post.
- New-AutopilotHash. This creates as brand new hash with the information specified, as shown above.
They aren’t 100% complete (obviously, since they don’t generate a working hash), but they show the logic being used.
Here are a few things that I tried:
Just an EKPub
Let’s see if we can create a hash that contains a “real” EkPub but bogus data for manufacturer, model, and serial number, just to see if that EkPub by itself is enough to identify the device. Of course to do that, we have to first know where to get the EkPub from, a task that isn’t particularly obvious. Here’s what this data looks like from a “full” hash generated via Get-WindowsAutopilotInfo.ps1 on the device:
I could obviously just copy that TPM EkPub value into a new hash, but I’d like to understand how to gather that piece of information myself. In the previous blog, I noted that the TPM info appears to come from UEFI, so that’s probably a good place to look. Using my UEFIv2 module, I can look through what variables are available:
The OfflineUniqueIDEKPub looks useful, so let’s see if we can twist that into a value that matches the real hardware hash:
That’s an exact match, so let’s build a hash with just that piece of “real” info:
I imported that hash without any issue. Interestingly, the “real” device hash is also imported, so these two devices are really the same:
So whatever detects a duplicate hash didn’t detect this as a duplicate. Regardless, I’ll remove the device with the “2094” serial number and then boot the device up to see if it finds an Autopilot profile. No luck, the device didn’t receive an Autopilot profile. So, it looks like we need more “real” info.
Manufacturer, Model, Serial
Adding some additional details to the previous hash:
Trying to import that hash gets an 806 error, device already assigned:
(Looks like it still can’t tell me the line number of the error. Fortunately, my CSV only has one line.). So it is detecting a duplicate with the previous hash that I imported. Imagine behind the scenes that Autopilot is trying to register the device with MSA/Passport.net to get its unique ID, and finding that it returns a unique ID that is already registered to another computer. That’s somewhat good and somewhat bad, as it probably means this attempt will fail on the client as well (since there was no duplicate detected when I imported the previous hash). But I’ll try it anyway, removing the Bert Ernie hash and re-importing my expanded one. No difference, as expected: the device still doesn’t receive an Autopilot profile.
Adding an SMBIOS UUID
OK, let’s try to add the SMBIOS UUID, as that’s not a hard one to do:
After removing the old entry (have to wait 30 minutes for whatever reason) and importing the new one and waiting for it to have an Autopilot profile assigned in the console, we’re ready to try again. Again, no change.
SKU and family
Let’s add the SKU number and system family:
Nope, no difference.
TPMVersion
Next up, we’ll add the TPMVersion information. I probably should have done this earlier, but I couldn’t find anything that reported the string in the needed format — the raw information appears to be there, either from the Get-TPM cmdlet or from the Win32_TPM WMI class. Before trying to build it, I saved some time and just copied the value from the original hash. It didn’t matter, the device still didn’t get an Autopilot profile.
What’s left?
I haven’t done much with the MAC/network information, the disk information, and the product key ID. And there are a few miscellaneous bytes here and there that aren’t obvious. At some point, I’ll revisit this and see if I can generate a hash that actually works…
[ad_2]
Source link
