Last Updated on January 4, 2023 by rudyooms
The first blog of 2023 will be about me staring, gazing, and trying to explain the funny parts of the OfflineDeviceID. While trying to explain I will also try to point you in a direction that could be useful for the next blog in this series.
I will divide this blog into multiple parts
1. Introduction
In one of my latest blogs, I showed you how a device would reach out to login.live.com to perform some Device Authentication when the device was being enrolled with Autopilot
Fetch the Autopilot Profile with PowerShell and a token (call4cloud.nl)
This Device Authentication is a requirement for getting the Device Token that is needed for fetching its Autopilot Profile. In that Device Authentication part, I stumbled upon Component 4144 AKA the OfflineDeviceID (ODUID)
Component 4144… almost sounds like COD Zombies Element 115.. but I guess that’s another story to tell
2. The OfflineDeviceID
While looking at the screenshot you would probably have noticed that the device sends out way more information than the “required critical” fields from the Hardware Hash. In this blog, I will focus a bit more on only one of them, the OfflineDeviceId!
When taking a look at the HardwareHash itself as shown below, we will notice that this OfflineDeviceID is also mentioned in it!
As the ODUID is mentioned in the hardware hash, I guess the best place to start searching for this OfflineDeviceID is by taking a look at the Autopilot.DLL file with the wonderful IDA tool.
When looking at the Autopilot.dll we will notice that the OfflineDeviceID is indeed mentioned in the GetOfflineDeviceUnqieIDFromTPM function
From TPM…from TPM… (if you have a TPM of course otherwise it would mention UEFIEK)
It sounds like UEFI all over again… let’s fire up PowerShell and try to find the OfflineUniqueIDEKPub. As shown below, it mentions the same Base64 String which we spotted in the HardwareHash with the use of the OA3Tool
After using google a bit and taking a closer look at it, I need to assume that the “offlinedeviceuniqueID” is SHA256(salt.identifier) where the “identifier” is one of the following:
TPM public endorsement key
I hoped that decompiling or decrypting that OfflineDeviceId showed me something more. Something like the Zero Touch Device ID (ZTDId) so I spend some time to find out if I could decode it. How the hell are we going to decode this ODUID?
Luckily we still have good old clippy (CLIPC.DLL and CLIPSVC.DLL).
I guess we are all now wondering, what the hell Clipsvc.dll has to do with Autopilot? Let me save that for a later blog as that “poo” is really important.
After searching on the Internet for “GetOfflineDeviceUniqueID” and in combination with CLIPC., I stumbled upon this GitHub page showing me the exact code I wanted to use
clipc!GetOfflineDeviceUniqueID PoC. (github.com)
Converting that CS file from GitHub to an executable and executing it on my own device got me a nice device-unique id
Okay… No idea what I can do with those numbers (for now) or what it exactly mean. Let’s dig further!
When digger deeper and taking a better look at the ClipSVC.dll we will notice that this OfflineDeviceID is added to the COA3Payload.
COA3Payload, sounds a bit like the OA3Tool doesn’t it?
“OA 3.0 tool on a manufacturing line to create a hardware association that joins a single Microsoft-issued Windows product key to a single computer.”
Creating a “Hardware Association“… When looking at the other “stuff/Components” it adds to the Payload to create the Hardware Association I am noticing a lot of similarities with the components we noticed in the Device Authentication.
Could it really be that ensuring your device is licensed has something to do with Autopilot?
Conclusion
When digging into the OfflineDeviceID 4144 that was sent out in the DeviceAddRequest, I am noticing Licensing all over the place. I am starting to wonder what Licensing has to do with Autopilot… Do you know? If not stick tuned for my next blogs
The entire Autopilot stack was initially built on top of Windows Activation so it should come as no surprise that there are licensing-related bits involved here. In fact, the whole MSA device ID process was initially used for “Genuine Windows” validation way back in Windows XP.