Last Updated on January 12, 2023 by rudyooms

In this blog, I will be focussing a bit more on the DeviceAddRequest command which the device performs in the background when turning on your device. I will divide this blog into multiple parts

1. Introduction
2. DeviceAddRequest
3. Blubbb and me
4. The Goold Old XP Days

1. Introduction

After I was done with my previous blogs, in which I explained how you could determine if the device is capable to fetch the Autopilot profile and how the OfflineDeviceId was used, I decided to take a closer look at the first step in the whole process.

So I will advise you to read the blog below to better understand the complete flow.

In this blog, I am going to focus a bit more on the DeviceAddRequest and where it originates from

2. DeviceAddRequest

As I was mentioning in the blog I mentioned in part 1, the device first reaches out to login.live.com to perform the Device Authentication

This Device Authentication will be performed by executing the DeviceAddRequest operation.

Looking at the screenshot above, you would probably be wondering about the Membername and its password. To get an answer to that question we need to focus on login.live.com and LiveIDs a bit more. When we need to know what is going on with Windows Live IDs/Microsoft Accounts we need to start looking at the corresponding DLL file: WLIDSVC.dll (Windows Live ID Service/ Microsoft Account Sign-In Assistant service)

Looking at the wlidsvc.dll code, it pretty much looks like its generated randomly

Almost forgot to mention, but this DeviceAddRequest is also logged in the LiveID event log. As shown below it showed me the exact same request. So we are again stuck with the good old Live ID!

When scrolling through that same WLIDSVC.DLL, we will notice that the DeviceAddRequest is mentioned a lot in the AddCredentialRequest wlidsvc.dll function…

I decided to start searching for some keywords like “DeviceInfo” in that DLL file. That search showed me how the SOAP request was built. until something funny caught my eye…

The function name itself!!!!: It is mentioning the name: UpdateDeviceLicenseRequest. Again the word License is in it and responsible for DeviceAddRequest….. Whoop Whoop…. I guess I need to mention it again UpdateDeviceLicenseRequest…

Take one guess, from which DLL this “LicenseRequest” function is being imported? As Shown below… CLIPC!

Every time that same word is mentioned! License, License, License, License!!! Maybe that’s why we also got license information in the SOAP response?

Even Procmon was showing me the same behavior when the device first connects to the Internet. ClipSvc is being mentioned a lot…. and I mean a lot!

It almost can’t be a coincidence that I stumbled upon clipsvc.dll when trying to decode the OfflineDeviceID in this blog below!

Digging into the HardwareHash and the OfflineDeviceID (call4cloud.nl)

Besides the Procmon trace, at the exact same moment, the SOAP request is performed, we will notice that the ClipSVC is being started

Mmmm, ClipSVC, and again the Wlidsvc being mentioned… that rings a bell or two… Looking back at one of my earlier blogs. Windows Pro doesn’t upgrade to Enterprise with E5 license (call4cloud.nl) we will also notice the mention of the Wlidsvc and the wonderful MSA ticket in it

Let me ask you a question, did you read the part about license authentication?? Did you?

3. Blubbb and me

I guess we need to do some assuming now and start combining the “Windows License Activation” information from my own blog with the word “Autopilot”. When we do we will end up with this Microsoft article mentioning the Windows Activation Services as a hard network requirement when using Windows Autopilot

As mentioned above, Windows Autopilot “Requires” Windows Activation Services. When using some GoogleFu ChatGPT functionality on it, this is what we get.

“The Windows Activation Process (WAP) will let your device generate a unique ID. That unique ID is based on its configuration. Windows will send out a summary of the hardware you have installed in combination with the Windows Product Key (PKID) to the Microsoft Service. The Microsoft service will link those two in their database. This ties your particular license key to your PC, ensuring that any attempt to use that license to activate Windows on another machine will fail”

Let’s combine the information from above, with some screenshots below…..

+1 One good old Windows XP Genuine Microsoft Software Notification

With those 2 screenshots in the back of our minds, let’s take a look at the good old days when Windows XP needed to activate itself to become genuine

4. The good Old XP Days

In the good old XP days when you were installing Windows XP. we also needed to perform Product Activation. This product activation could be done by using the Internet !!! WOWWW!..

To activate Windows XP, the device needed to hand over The Installation ID to Microsoft. This “Installation ID” was based upon the Hardware Hash (sounds familiar right?) and the Product ID. Let’s start with the Hardware Hash. The HH was calculated during the installation of Windows XP. This Hardware Hash was based upon some components

Once you needed to perform product activation, this data (Hardware Hash) and the Product ID needed to be sent over to the Microsoft Activation servers in a binary format over a nice secure SSL connection. This activation should happen without any issue as long as you didn’t exceed the maximum number of allowed “Hardware” changes.

Mmmm that does ring a bell or two doesn’t it?

*When there is a significant hardware change you couldn’t activate Windows XP.

*When there is a significant hardware change Autopilot isn’t working…

Conclusion

Troubleshooting Windows Autopilot is always fun but having a better understanding of what process, Autopilot is built upon is way better.

Windows Autopilot relies on the good old Windows Activation Process (Windows Xp Genuine Hardware) for its Hardware information. There you have it!! Boom!!!