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.

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 we 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 looking 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 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 what it has to do? If not stick tuned for my next blogs