no-gdid

Leggi, comprendi e metti a tacere l'identificatore globale del dispositivo Windows (GDID) — l'ID dispositivo nascosto legato all'account che ha aiutato l'FBI a localizzare un sospettato che usava una VPN.

⚠️ Disclaimer onesto fin dall'inizio: questo strumento non cancella il tuo GDID e non ti rende anonimo. Il GDID vive sui server di Microsoft, legato al tuo account Microsoft, nel momento in cui accedi. no-gdid impedisce alla tua macchina di ri-registrarlo e segnalarlo — non può annullare ciò che Microsoft ha già. Per una vera privacy in attività sensibili, l'unica risposta affidabile è non dipendere da Windows.

Ogni risultato qui riportato è stato riprodotto su una vera VM Windows 11 Pro (build 26200) prima di essere messo per iscritto. Nulla è teorico. Vedi docs/technical-writeup.md per le prove, classificate per livello di confidenza — e Come è stato realizzato per capire cosa comportava concretamente quella verifica.

La storia

Nel 2026 l'FBI ha rintracciato un sospettato di Scattered Spider che cambiava IP attraverso una VPN in tre paesi. A tradirlo è stato un GDID — un identificatore del dispositivo che Microsoft lega a un'installazione di Windows e condivide con le forze dell'ordine su citazione giudiziaria. Non cambia quando cambi il tuo IP. Questo repository smonta quell'identificatore e mostra cosa puoi fare concretamente al riguardo.

Cos'è davvero il GDID

Non è un hash hardware — è un PUID dispositivo MSA a 64 bit coniato da login.live.com, messo in cache localmente nel registro, registrato nel grafo del Device Directory Service di Microsoft e segnalato tramite 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)

Il LID del registro (hex) corrisponde al valore lato server g:<decimal>. Tutti i PUID dei dispositivi Windows rientrano nel namespace 0x0018… (verificato: il nostro valore di test e quello presente negli atti del tribunale lo condividono).

Avvio rapido

Tutti gli script sono PowerShell, solo ASCII, e funzionano con qualsiasi codepage. Apri una PowerShell elevata.

# 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

Prima testa su una VM con uno snapshot. La mitigazione disabilita i servizi di sistema.

Cosa fa ogni parte

Percorso	Scopo	Scrive?
`audit/Get-GDID-Audit.ps1`	Legge il tuo GDID + lo stato della catena dei 5 servizi	No
`audit/Get-GDID-Traffic.ps1`	Mappa gli endpoint di rete reali della catena	No
`mitigate/Block-GDID-Endpoints.ps1`	Blackhola gli endpoint DDS/DO in `hosts` (mantiene `login.live.com`)	Con `-Apply`
`mitigate/Disable-GDID-Services.ps1`	Disabilita `CDPSvc`/`DoSvc`/`CDPUserSvc` (mantiene `wlidsvc`)	Con `-Apply`
`mitigate/Revert-GDID.ps1`	Ripristina i servizi + pulisce `hosts`	Sì
`experiments/`	Probe con gate a snapshot usate per provare i risultati	Distruttive, con gate
`docs/`	Write-up tecnico con fonti + FAQ	—

Cosa abbiamo dimostrato (e cosa non funziona)

Leggere il tuo GDID funziona. È proprio lì nel registro.
Eliminarlo è solo un effetto cosmetico. Rimuovi la chiave, riavvia wlidsvc, tocca una qualsiasi app Microsoft — ricompare identico dal server. È ancorato al tuo account.
Disattivare la "telemetria" (DiagTrack) non serve a nulla. Il GDID viaggia tramite CDP/Delivery Optimization, non sulla telemetria classica. Quel consiglio così diffuso è sbagliato.
Puoi mettere a tacere la segnalazione senza disconnetterti. Disabilita i servizi CDP/DO e blackhola i loro endpoint; la catena tace mentre il tuo account Microsoft continua a funzionare. Avvertenza: DoSvc rifiuta Set-Service anche da amministratore — viene disabilitato impostando Start=4 nel registro (vedi il write-up).
Il passato è passato. Il PUID esiste già lato server. Bloccare riduce la correlazione futura; non ritira ciò che è stato inviato.

Compromessi

Disabilitare questi servizi rompe la cache peer di Delivery Optimization, Phone Link / "Continua sul PC" e la condivisione nelle vicinanze. wlidsvc e login.live.com vengono lasciati intatti, così l'accesso all'account Microsoft continua a funzionare.

Documentazione

docs/technical-writeup.md — l'intera catena, i percorsi del registro, gli endpoint e ogni affermazione classificata per livello di confidenza ([COURT], [OBSERVED], [STATIC], [NO-GDID VÉRIFIÉ]).
docs/FAQ.md — risposte brevi alle domande ovvie.

Come è stato realizzato

Questo progetto è stato indagato e scritto con un notevole supporto dell'IA (Claude). La cronologia dei commit lo dice, e lo dice anche questa sezione — non dovresti dover scavare per scoprirlo.

Cosa significa in pratica, onestamente:

L'IA ha guidato l'indagine. Ha letto il reverse engineering, ha mappato la catena dei servizi, ha proposto le ipotesi da testare e ha scritto gran parte del codice PowerShell e del testo che stai leggendo.
Ho eseguito io stesso ogni test, sulla mia VM. Windows 11 Pro build 26200 in VMware, con accesso a un vero account Microsoft, snapshot prima di ogni passaggio distruttivo. Il GDID negli screenshot è quello di quella VM, ed è per questo che non ho problemi a mostrarlo.
Le affermazioni importanti sono state verificate a mano, non accettate per fede. Eliminare la chiave LID e riavviare wlidsvc fa davvero ricomparire lo stesso identificatore non appena una qualsiasi app Microsoft lo richiede — l'ho visto accadere. DiagTrack era già stato fermato su quella VM e il GDID era ancora lì, ed è proprio questo che ha stroncato il consiglio "basta disattivare la telemetria". DoSvc rifiuta davvero Set-Service anche da amministratore, ed è per questo che lo script passa dal registro. Ognuna di queste è nata come ipotesi dell'IA e molte si sono rivelate sbagliate finché non sono state testate.
Ciò che non è mio, non lo rivendico. I miei test sono stati su Windows 11 Pro con un account Microsoft. Il caso dell'account locale era una questione aperta finché @Berbe non ha contribuito con l'osservazione su Windows 10 LTSC 19044.7417 (un LID/GDID esiste dall'installazione anche con il solo account locale). Il write-up registra da quale build proviene ogni risultato — se un'affermazione non riporta un numero di build, trattala come meno solida.

Se trovi un'affermazione che non regge sulla tua macchina, apri una issue con il tuo numero di build — per questo repository vale più del semplice consenso.

Riconoscimenti

Reverse engineering principale: SmtimesIWndr/gdid-reversal.
Osservazione sull'account locale su Windows 10 LTSC: @Berbe (PR #3).
Fatti del caso: United States v. Peter Stokes, N.D. Ill., luglio 2026.

Licenza

MIT. Strumentazione difensiva e orientata alla privacy. Usala su macchine di tua proprietà.

no-gdid — Updated!

Categorie