TL;DR

[!NOTE] Ce qui suit est vrai, mais il manque certaines informations. Que vous soyez connecté avec un compte Microsoft ou non, vous AUREZ un GDID. Je ne l’avais pas réalisé au moment de la publication, mais j’ai vérifié. CDP possède un chemin d’appareil anonyme utilisé si aucun compte Microsoft n’est connecté. Le système sous‑jacent est toujours correct factuellement, mais il manque quelques éléments.

• Le GDID est un élément de télémétrie réel. Il apparaît dans la plainte pénale fédérale américaine (United States v. Peter Stokes, N.D. Ill., juillet 2026) sous la forme Global Device Identifier g:6755467234350028.
• C’est un « Device PUID » de compte Microsoft. Un identifiant unique Passport (PUID) de 64 bits attribué à une installation Windows lorsqu’elle s’enregistre auprès d’un compte Microsoft, écrit dans le graphe des appareils sous la forme g:<décimal>.
• Les affirmations sont erronées. Il n’est pas « 128 bits » et pas « généré à partir de numéros de série ». Le document judiciaire lui‑même indique qu’une réinstallation produit un nouveau GDID, ce qui exclut qu’il soit dérivé de numéros de série matériels comme ceux de votre GPU.
• La pile, de bas en haut : wlidsvc (service de compte Microsoft) provisionne l’appareil auprès de login.live.com et reçoit un PUID d’appareil -> le stocke dans le registre -> la plateforme d’appareils connectés (cdp.dll / CDPSvc) le lit et l’enregistre dans le graphe Device Directory Service (DDS) -> Delivery Optimization le rapporte sous la forme documentée UCDOStatus.GlobalDeviceId.
• Tout a été reproduit sur une machine Windows 11 (26200) réelle avec les symboles publics. Vous pouvez trouver votre propre GDID en une seule lecture du registre (§7).

[!NOTE] Étiquetage de confiance. Chaque affirmation est étiquetée pour que vous puissiez en juger par vous‑même : [COURT] fait avéré de source primaire, [OBSERVED] reproduit en direct sur ma machine de test, [STATIC] prouvé à partir des binaires et des PDB publics de Windows, [ASSESSED] inférence solide à partir des preuves.

Sommaire

1. Contexte : ce qu’a réellement dit le tribunal
2. Démontage des mythes viraux
3. Où le GDID apparaît : Delivery Optimization
4. Qui le possède : Connected Devices Platform vers DDS
5. Comment CDP l’obtient : il consomme, il ne calcule pas
6. La source : MSA Device PUID (wlidsvc)
7. Trouver votre propre GDID
8. Réduire l’exposition
9. Méthodologie (reproductible)
10. Limites et mises en garde honnêtes

1. Contexte : ce qu’a réellement dit le tribunal

Le 1er juillet 2026, le DOJ a dévoilé une plainte pénale contre Peter Stokes, un membre présumé de Scattered Spider (alias Octo Tempest / UNC3944 / 0ktapus). L’affidavit décrit comment Microsoft a aidé le FBI à attribuer une activité à un appareil.

[!IMPORTANT] [COURT] Extrait de la plainte modifiée (¶25, p.34), textuellement :

« le compte ngrok a été créé avec Global Device Identifier g:6755467234350028 (le 'GDID'). Selon un représentant de Microsoft, un Global Device Identifier dans l’écosystème Windows est un identifiant persistant au niveau de l’appareil, conçu pour identifier de manière unique une installation du système d’exploitation Windows sur un appareil… Un GDID est un identifiant global unique lié à l’installation de Windows sur un appareil. Un GDID reste cohérent entre les mises à jour du système d’exploitation Windows sur un appareil, mais une réinstallation de Windows… sera liée à un nouveau GDID unique. »

Une note de bas de page ajoute qu’un même utilisateur Microsoft peut avoir plusieurs GDID. L’affidavit corrèle ensuite l’historique IP du GDID et la navigation (par ex. empirehotelnyc.com, une URL de connexion Growtopia/Ubisoft) avec les comptes sur lesquels le suspect était connecté.

Deux éléments portent le reste de cette analyse :

1. La valeur est g: suivie d’un entier décimal (g:6755467234350028). En hexadécimal, cela donne 0x0018000FC8CB93CC, soit un nombre sur 64 bits.
2. Une réinstallation donne un nouveau GDID. Il ne peut donc pas être simplement une fonction du matériel immuable.

2. Démontage des mythes viraux

Le résumé des médias sociaux affirmait que le GDID est « un identifiant de 128 bits généré à partir des numéros de série lors de l’installation ». Les deux moitiés sont fausses :

[!NOTE] Après avoir approfondi le reverse du CDP, j’ai fourni une information erronée. Utiliser un compte local n’empêche pas un GDID. CDP possède un chemin d’appareil anonyme qui est emprunté si aucun compte Microsoft n’est connecté. Gardez cela à l’esprit en lisant.

3. Où le GDID apparaît : Delivery Optimization

[STATIC] La documentation publique Azure Monitor de Microsoft définit une colonne GlobalDeviceId dans la table UCDOStatus (Update Compliance / Delivery Optimization) :

GlobalDeviceId (string) : « Identifiant global d’appareil Microsoft. Il s’agit d’un identifiant utilisé en interne par Microsoft. »

Elle se trouve juste à côté de LastCensusSeenTime, ISP, City, Country, donc un identifiant d’appareil aligné avec la géolocalisation et l’IP. C’est le seul endroit où Microsoft nomme la valeur dans la documentation publique. Mais Delivery Optimization se contente de la rapporter. Il ne la possède pas. Remontez en amont et vous arrivez sur la Connected Devices Platform.

4. Qui le possède : Connected Devices Platform vers DDS

[STATIC] C:\Windows\System32\cdp.dll (la Connected Devices Platform, services CDPSvc + CDPUserSvc) contient le symbole GlobalDeviceId et tout un sous‑système d’enregistrement Device Directory Service :

ddsregistrationclient.cpp   ddsregistrationmanager.cpp   ddsregistrationinfo.cpp
DdsRegistrationClient   RegisterUserDevicesObserver   DdsRegistrationInfoProviderForCDP
endpoints: dds.microsoft.com  fd.dds.microsoft.com  aad.cs.dds.microsoft.com  cdpcs.access.microsoft.com
chaîne de format d’identifiant d’appareil : "g:%s"

DDS = Device Directory Service, le graphe d’identité multi‑appareils de Microsoft (le backend derrière Phone Link, presse‑papiers cloud, « Continuer sur PC », Nearby Share). CDP est le client Windows qui enregistre l’installation dans ce graphe, où elle est indexée sous la forme g:<décimal>.

4.1 Capturé en direct

[OBSERVED] En forçant un enregistrement frais (redémarrage de CDPSvc après avoir effacé son état local) et en capturant les fournisseurs ETW de CDP, j’ai obtenu toute la poignée de main :

DdsClient::RegisterUserDeviceAsync()   RegistrationReason: Startup   Account Type: MSA
DDSClient: Registration response received. HTTP status code: 200
OnRegisterUserDeviceComplete
GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX

Ce deviceid, écrit g:<décimal>, correspond structurellement à celui de la plainte :

Les deux sont des valeurs 64 bits dans le même mot haut 0x0018 (l’espace de noms des PUID d’appareil, voir §6). Le préfixe g: n’est que cet entier en décimal.

5. Comment CDP l’obtient : il consomme, il ne calcule pas

[STATIC] Avec le PDB public (cdp.pdb), le chemin de l’identifiant d’appareil dans cdp.dll n’est qu’une demande et une attente vis‑à‑vis de la pile d’identité. CDP ne calcule jamais l’identifiant lui‑même :

flowchart TD
    A["GetStableDeviceIdFromProvider<br/>0x0A3140"] --> B["provider.GetStableDeviceIdAsync<br/>(vtable +0x48)"]
    B --> C["OneCoreAccountProvider::<br/>GetStableDeviceIdAsync 0x0C8370"]
    C --> D["IWebAccountBackedAccountProvider<br/>(MSA / AAD identity COM)"]
    D --> E["OnGetStableDeviceIdCompleted<br/>(const char* deviceId) 0x06CEA0"]
    E -->|"assign() string, signal flag"| A

Le callback qui le reçoit le rend évident. L’identifiant arrive sous forme de chaîne et est simplement stocké :

; OnGetStableDeviceIdCompleted
mov  rbp, r9                 ; r9 = chaîne device-id fournie par le fournisseur d’identité
lea  rcx, [rsi+0xD8]         ; champ membre CDP
mov  rdx, rbp
call assign@basic_string     ; stocker, pas de calcul, pas de numéros de série
call Set@CdpWaitableFlag      ; débloquer l’attente

En résumé : le GDID est frappé en dessous de CDP, dans la pile d’identité Windows, et remis à CDP comme une chaîne opaque. Cela pointe vers le service de compte Microsoft.

6. La source : MSA Device PUID (wlidsvc)

[STATIC] C:\Windows\System32\wlidsvc.dll, le service de compte Microsoft / Passport (Windows Live ID), est le seul binaire d’identité qui contient le littéral GlobalDeviceId, et il détient toute la machinerie de provisionnement d’appareil :

CDeviceIdentityBase::CreateNewDeviceIdentity / Provision / BindDeviceToHardware / GetDeviceCert
DeviceAssociateRequest      (Passport PPCRL SOAP -> login.live.com)
<ps:DevicePUID> ... </ps:DevicePUID>
DeviceIdStore::LogToRegistry
BCryptGenRandom / CCryptRandom::GenRandom     (clé de l’appareil, PAS l’identifiant)

L’identifiant est un Device PUID (Passport Unique ID), un identifiant MSA de 64 bits. Le BCryptGenRandom présent génère la clé d’authentification de l’appareil que BindDeviceToHardware épingle à la machine, pas le PUID.

6.1 Il est attribué par le serveur

[STATIC] Le client extrait le PUID de la réponse SOAP du serveur, avec un XPath dans le corps de la réponse :

/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped

CAssociateDeviceRequest::ParseResponseBody et les méthodes ParseResponse associées lisent les nœuds XML de la réponse dans des BSTR. Donc le flux est : le client provisionne l’appareil -> login.live.com attribue et renvoie le PUID d’appareil -> le client le stocke. C’est exactement pourquoi une réinstallation produit un nouveau GDID (nouveau provisionnement, nouveau PUID attribué par le serveur), et pourquoi ce n’est pas un hachage matériel.

6.2 Il est stocké en clair

[OBSERVED] Le magasin d’identité du compte Microsoft conserve la valeur directement dans le registre, dans votre propre ruche utilisateur :

HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
    LID = 0018XXXXXXXXXXXX

HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}
    DeviceId = 0018XXXXXXXXXXXX

Octet pour octet, la même valeur que CDP a enregistrée dans DDS en direct. Le PUID de votre compte utilisateur est un nombre différent stocké ailleurs sous puid = 0003... (par ex. 00034002XXXXXXXX). Il existe aussi une clé de cache dans HKLM nommée d’après le PUID (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\<PUID>_<userSID>), mais celle‑ci est réservée à SYSTEM, donc vous lisez la valeur dans HKCU.

[!NOTE] Le préfixe vous dit ce que c’est. Les PUID d’utilisateur sont de classe 0003, les PUID d’appareil sont de classe 0018. Le GDID du tribunal (0018000FC8CB93CC) est dans l’espace 0018 des PUID d’appareil, tout comme le mien.

6.3 Il authentifie les endpoints du graphe

[OBSERVED] Le cache de jetons MSA (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\...) contient des jetons d’appareil dont la portée correspond exactement aux endpoints utilisés par CDP :

scope=service::dds.microsoft.com::MBI_SSL_TOKEN_BROKER
scope=service::activity.windows.com::MBI_SSL_SA_TOKEN_BROKER

Ainsi, le service de compte Microsoft distribue les informations d’identification d’appareil qui authentifient l’enregistrement DDS et les téléchargements d’activité qui transportent le GDID.

6.4 La chaîne complète

flowchart TD
    subgraph MSA["MSA identity layer: wlidsvc.dll"]
        A1["Provision device with login.live.com<br/>(Passport PPCRL SOAP)"] --> A2["Server assigns Device PUID<br/>&lt;ps:DevicePUID&gt; / HWPUIDFlipped"]
        A2 --> A3["Store DeviceId / LID = PUID<br/>HKLM\...\IdentityStore"]
        A3 --> A4["Issue device tokens for<br/>dds.microsoft.com and activity.windows.com"]
    end
    subgraph CDP["Device graph client: cdp.dll / CDPSvc"]
        B1["GetStableDeviceId -> receives PUID string"] --> B2["RegisterUserDeviceAsync -> DDS<br/>OBSERVED: HTTP 200"]
    end
    subgraph SRV["Server: Device Directory Service"]
        C1["Keys g:PUID to the MSA account,<br/>activity and IP history"]
    end
    subgraph REP["Reporting"]
        D1["Delivery Optimization -><br/>UCDOStatus.GlobalDeviceId"]
    end
    A4 --> B1
    B2 --> C1
    C1 --> D1

Tout ce que la plainte attribue au « GDID » (persistant par installation, survivant aux mises à jour, nouveau lors d’une réinstallation, lié à un compte Microsoft, traçable entre IP et navigation) découle du fait qu’il s’agit d’un PUID d’appareil MSA attribué par le serveur que CDP enregistre dans le graphe d’appareils.

7. Trouver votre propre GDID

[OBSERVED] Sur une machine connectée à un compte Microsoft, une seule lecture du registre dans votre propre ruche utilisateur, sans droits administrateur :

(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

Cela vous donne votre PUID d’appareil sous forme de 16 chiffres hexadécimaux (par ex. 0018XXXXXXXXXXXX). Pour le voir sous la forme g:<décimal> telle qu’elle apparaît côté serveur :

$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($hex,16))"

Si ExtendedProperties\LID est vide sur votre machine, la même valeur se trouve sous HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}\DeviceId.

[!WARNING] Ne publiez pas votre propre valeur. Votre PUID d’appareil, votre CID MSA (0003...) et votre SID utilisateur peuvent tous vous désanonymiser. Masquez‑les dans toute publication publique. La seule valeur qu’il est sûr de citer est celle du tribunal, car elle est déjà publique.

8. Réduire l’exposition

Le GDID existe parce que votre appareil est enregistré dans le graphe d’appareils du compte Microsoft et que la Connected Devices Platform le maintient synchronisé. Pour le réduire :

• Désactivez la Connected Devices Platform (CDPSvc, CDPUserSvc) et désactivez l’historique des activités (Paramètres, Confidentialité, Historique des activités) pour arrêter la synchronisation du graphe et les téléchargements d’activité.
• Supprimer %LOCALAPPDATA%\ConnectedDevicesPlatform efface seulement l’état local de CDP. Le PUID revient immédiatement du magasin d’identité, donc cela seul ne suffit pas.
• Une réinstallation vous donne un nouveau GDID (la plainte le dit), mais il est lié à un nouveau dès la prochaine inscription.

9. Méthodologie (reproductible)

Tout cela a été fait sur une machine Windows 11 (build 26200) standard.

• Capture en direct : fournisseurs ETW TraceLogging de CDP (Microsoft.Windows.CDP.*) via logman en forçant un nouvel enregistrement de CDPSvc, décodé avec tracerpt.
• Registre et cache de jetons : IdentityStore et IdentityCRL sous HKLM\SOFTWARE\Microsoft.

L’ETW et l’analyse statique sont ce qui a réellement fonctionné. Un proxy ne fera que vous faire perdre du temps.

Microsoft.Windows.CDP.Core                    {7762de0c-b0a6-571a-68d3-c018bf009496}
Microsoft.Windows.CDP.Core.Error              {a1ea5efc-402e-5285-3898-22a5acce1b76}
Microsoft.Windows.CDP.CDS                     {dfa6e32a-095f-5f57-d025-0887d33507a1}
Microsoft.Windows.CDP.Aggr                    {bc1826c8-369c-5b0b-4cd1-3c6ae5bfe2e7}
Microsoft.Windows.CDP.AFS                     {5fe36556-c4cd-509a-8c3e-2a547ea568ae}
Microsoft.Windows.CDP.OnecoreAccountProvider  {4ee5bf9a-3e8f-540b-8bfb-12457a2854b6}
Microsoft.Windows.CDP                          {9f4cc6dc-1bab-5772-0c71-a89954718d66}

[!NOTE] NullZeroX sur Twitter m’a dit que le GDID est également envoyé que vous soyez connecté ou non avec un compte Microsoft sur votre appareil. Je ne sais pas si c’est vrai, mais ça vaut la peine d’être noté.