no-gdid

Lisez, comprenez et faites taire l'identifiant global d'appareil Windows (GDID) — l'identifiant d'appareil caché par compte qui a aidé le FBI à localiser un suspect qui utilisait un VPN.

⚠️ Avertissement honnête d'emblée : cet outil n'efface pas votre GDID et ne vous rend pas anonyme. Le GDID vit sur les serveurs de Microsoft, lié à votre compte Microsoft, dès que vous vous connectez. no-gdid empêche votre machine de le ré-enregistrer et de le signaler — il ne peut pas effacer ce que Microsoft détient déjà. Pour une véritable confidentialité sur un travail sensible, la seule réponse fiable est de ne pas compter sur Windows.

Chaque constat présenté ici a été reproduit sur une vraie VM Windows 11 Pro (build 26200) avant d'être consigné. Rien n'est théorique. Voir docs/technical-writeup.md pour les preuves, étiquetées par niveau de confiance — et Comment ce projet a été construit pour ce que cette vérification impliquait réellement.

L'histoire

En 2026, le FBI a suivi un suspect de Scattered Spider qui changeait d'adresse IP via un VPN dans trois pays. Ce qui l'a trahi, c'est un GDID — un identifiant d'appareil que Microsoft associe à une installation Windows et partage avec les forces de l'ordre sur subpoena. Il ne change pas quand vous changez d'adresse IP. Ce dépôt démonte cet identifiant et montre ce que vous pouvez réellement faire à ce sujet.

Ce qu'est réellement le GDID

Pas un hash matériel — c'est un PUID d'appareil MSA 64 bits émis par login.live.com, mis en cache localement dans le registre, enregistré dans le graphe du Device Directory Service de Microsoft, et signalé via Delivery Optimization.

wlidsvc  ── mint ──►  PUID from login.live.com
   │                  cached at HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID
CDPSvc / CDPUserSvc  ── register ──►  Device Directory Service (dds.microsoft.com)
   │
DoSvc  ── report ──►  UCDOStatus.GlobalDeviceId  (Azure Monitor)

Le LID du registre (hex) correspond à la valeur serveur g:<decimal>. Tous les PUID d'appareils Windows se situent dans l'espace de noms 0x0018… (vérifié : notre valeur de test et celle de l'acte judiciaire partagent cet espace de noms).

Démarrage rapide

Tous les scripts sont en PowerShell, ASCII uniquement, et s'exécutent sous n'importe quel codepage. Ouvrez une PowerShell élevée.

# 1. See your own GDID and which parts of the chain are active (read-only, safe)
powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1

# 2. Preview what the mitigation would change (no changes yet)
powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1

# 3. Apply it: stop the report chain + blackhole its endpoints, keep MSA working
powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply

# Undo everything
powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1

Testez d'abord dans une VM avec un snapshot. La mesure d'atténuation désactive des services système.

Ce que fait chaque élément

Ce que nous avons prouvé (et ce qui ne fonctionne pas)

• La lecture de votre GDID fonctionne. C'est juste là, dans le registre.
• Sa suppression est purement cosmétique. Supprimez la clé, redémarrez wlidsvc, utilisez n'importe quelle application Microsoft — elle revient à l'identique depuis le serveur. C'est ancré à votre compte.
• Désactiver la « télémétrie » (DiagTrack) ne change rien. Le GDID circule via CDP/Delivery Optimization, pas via la télémétrie classique. Ce conseil courant est faux.
• Vous pouvez faire taire le signalement sans vous déconnecter. Désactivez les services CDP/DO et mettez leurs points de terminaison en trou noir ; la chaîne se tait pendant que votre compte Microsoft continue de fonctionner. Attention : DoSvc refuse Set-Service même en tant qu'administrateur — il est désactivé via le registre Start=4 (voir la documentation).
• Le passé est révolu. Le PUID existe déjà côté serveur. Le blocage réduit la corrélation future ; il ne retire pas ce qui a été envoyé.

Compromis

Désactiver ces services casse la mise en cache entre pairs de Delivery Optimization, Phone Link / « Continue on PC », et le partage à proximité. wlidsvc et login.live.com ne sont pas touchés afin que la connexion au compte Microsoft continue de fonctionner.

Documentation

• docs/technical-writeup.md — toute la chaîne, les chemins de registre, les points de terminaison, et chaque affirmation étiquetée par niveau de confiance ([COURT], [OBSERVED], [STATIC], [NO-GDID VÉRIFIÉ]).
• docs/FAQ.md — des réponses courtes aux questions évidentes.

Comment ce projet a été construit

Ce projet a été investigué et rédigé avec une forte assistance de l'IA (Claude). L'historique des commits le dit, tout comme cette section — vous ne devriez pas avoir à creuser pour le trouver.

Ce que cela signifie concrètement, en toute honnêteté :

• L'IA a piloté l'investigation. Elle a lu le reverse engineering, cartographié la chaîne de services, proposé les hypothèses à tester, et rédigé la majeure partie du PowerShell et du texte que vous lisez.
• J'ai exécuté chaque test moi-même, sur ma propre VM. Windows 11 Pro build 26200 dans VMware, connecté avec un vrai compte Microsoft, snapshot avant chaque étape destructrice. Le GDID dans les captures d'écran est celui de cette VM, c'est pourquoi je peux le montrer sans inquiétude.
• Les affirmations importantes ont été vérifiées à la main, pas acceptées telles quelles. Supprimer la clé LID et redémarrer wlidsvc fait vraiment revenir le même identifiant dès qu'une application Microsoft le demande — je l'ai vu se produire. DiagTrack était déjà arrêté sur cette VM et le GDID était toujours là, ce qui a tué le conseil « il suffit de désactiver la télémétrie ». DoSvc refuse vraiment Set-Service en tant qu'administrateur, c'est pourquoi le script passe par le registre à la place. Chacune de ces affirmations a commencé comme une hypothèse de l'IA et plusieurs d'entre elles se sont révélées fausses à l'épreuve des tests.
• Ce qui ne vient pas de moi, je ne le revendique pas. Mes tests ont porté sur Windows 11 Pro avec un compte Microsoft. Le cas du compte local était une question ouverte ici jusqu'à ce que @Berbe apporte l'observation sur Windows 10 LTSC 19044.7417 (un LID/GDID existe dès l'installation même avec un compte local uniquement). La documentation indique de quel build provient chaque constat — si une affirmation n'est accompagnée d'aucun numéro de build, considérez-la comme moins fiable.

Si vous trouvez ici une affirmation qui ne se vérifie pas sur votre machine, ouvrez une issue avec votre numéro de build — cela vaut plus pour ce dépôt qu'un simple accord.

Crédits

• Reverse engineering principal : SmtimesIWndr/gdid-reversal.
• Observation sur compte local sous Windows 10 LTSC : @Berbe (PR #3).
• Faits de l'affaire : United States v. Peter Stokes, N.D. Ill., juillet 2026.

Licence

MIT. Un outillage défensif, orienté confidentialité. Utilisez-le sur les machines qui vous appartiennent.