no-gdid

Lee, comprende y silencia el Identificador Global de Dispositivo (GDID) de Windows: el ID de dispositivo oculto por cuenta que ayudó al FBI a localizar a un sospechoso que usaba una VPN.

⚠️ Aviso honesto desde el principio: esta herramienta no borra tu GDID y no te hace anónimo. El GDID vive en los servidores de Microsoft, vinculado a tu cuenta de Microsoft, en el momento en que inicias sesión. no-gdid evita que tu máquina lo vuelva a registrar y reportar; no puede deshacer lo que Microsoft ya tiene. Para una privacidad real en trabajos sensibles, la única respuesta fiable es no depender de Windows.

Cada hallazgo de aquí se reprodujo en una VM real de Windows 11 Pro (build 26200) antes de escribirse. Nada es teórico. Consulta docs/technical-writeup.md para ver las evidencias, etiquetadas por nivel de confianza — y Cómo se construyó esto para saber qué implicó realmente esa verificación.

La historia

En 2026, el FBI rastreó a un sospechoso de Scattered Spider que rotaba IPs a través de una VPN en tres países. Lo que lo delató fue un GDID, un identificador de dispositivo que Microsoft vincula a una instalación de Windows y comparte con las autoridades mediante una citación. No cambia cuando cambias tu IP. Este repositorio desmonta ese identificador y muestra qué puedes hacer realmente al respecto.

Qué es realmente el GDID

No es un hash de hardware, sino un PUID de dispositivo MSA de 64 bits emitido por login.live.com, almacenado en caché localmente en el registro, registrado en el grafo del Device Directory Service de Microsoft y reportado a través de 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)

El LID del registro (hex) se corresponde con el valor del servidor g:<decimal>. Todos los PUID de dispositivos Windows se encuentran en el espacio de nombres 0x0018… (verificado: nuestro valor de prueba y el de la presentación judicial comparten ese espacio).

Inicio rápido

Todos los scripts son de PowerShell, solo ASCII, y funcionan con cualquier página de códigos. Abre un PowerShell elevado.

# 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

Prueba primero en una VM con una instantánea. La mitigación deshabilita servicios del sistema.

Qué hace cada parte

Ruta	Propósito	¿Escribe?
`audit/Get-GDID-Audit.ps1`	Lee tu GDID + el estado de la cadena de 5 servicios	No
`audit/Get-GDID-Traffic.ps1`	Mapea los endpoints de red reales de la cadena	No
`mitigate/Block-GDID-Endpoints.ps1`	Bloquea (blackhole) los endpoints DDS/DO en `hosts` (mantiene `login.live.com`)	Con `-Apply`
`mitigate/Disable-GDID-Services.ps1`	Deshabilita `CDPSvc`/`DoSvc`/`CDPUserSvc` (mantiene `wlidsvc`)	Con `-Apply`
`mitigate/Revert-GDID.ps1`	Restaura los servicios + limpia `hosts`	Sí
`experiments/`	Sondas controladas por instantánea usadas para demostrar los hallazgos	Destructivas, controladas
`docs/`	Informe técnico con fuentes + FAQ	—

Lo que demostramos (y lo que no funciona)

Leer tu GDID funciona. Está ahí mismo, en el registro.
Eliminarlo es cosmético. Elimina la clave, reinicia wlidsvc, toca cualquier aplicación de Microsoft — vuelve idéntico desde el servidor. Está anclado a tu cuenta.
Desactivar la "telemetría" (DiagTrack) no hace nada. El GDID viaja por CDP/Delivery Optimization, no por la telemetría clásica. Ese consejo tan común es erróneo.
Puedes silenciar el reporte sin cerrar sesión. Deshabilita los servicios CDP/DO y bloquea sus endpoints; la cadena se queda en silencio mientras tu cuenta de Microsoft sigue funcionando. Advertencia: DoSvc rechaza Set-Service incluso como administrador — se deshabilita mediante el registro Start=4 (consulta el informe).
El pasado ya pasó. El PUID ya existe en el servidor. El bloqueo reduce la correlación futura; no retira lo que ya se envió.

Contrapartidas

Deshabilitar estos servicios rompe el caché de pares de Delivery Optimization, Phone Link / "Continuar en el PC" y el uso compartido cercano. wlidsvc y login.live.com se dejan intactos para que el inicio de sesión de la cuenta de Microsoft siga funcionando.

Documentación

docs/technical-writeup.md — la cadena completa, las rutas del registro, los endpoints y cada afirmación etiquetada por nivel de confianza ([COURT], [OBSERVED], [STATIC], [NO-GDID VÉRIFIÉ]).
docs/FAQ.md — respuestas breves a las preguntas obvias.

Cómo se construyó esto

Este proyecto se investigó y se escribió con una fuerte asistencia de IA (Claude). El historial de commits lo dice, y esta sección también — no deberías tener que rebuscar para encontrarlo.

Qué significa eso en la práctica, con honestidad:

La IA dirigió la investigación. Leyó la ingeniería inversa, mapeó la cadena de servicios, propuso las hipótesis a probar y escribió la mayor parte del PowerShell y de la prosa que estás leyendo.
Yo mismo ejecuté cada prueba, en mi propia VM. Windows 11 Pro build 26200 en VMware, con sesión iniciada en una cuenta de Microsoft real, instantánea antes de cada paso destructivo. El GDID de las capturas de pantalla es el de esa VM, por eso me siento cómodo mostrándolo.
Las afirmaciones que importaban se verificaron a mano, no se aceptaron. Eliminar la clave LID y reiniciar wlidsvc realmente hace que vuelva el mismo identificador en cuanto cualquier aplicación de Microsoft lo solicita — lo vi ocurrir. DiagTrack ya estaba detenido en esa VM y el GDID seguía allí, que es lo que desmontó el consejo de "solo desactiva la telemetría". DoSvc realmente rechaza Set-Service como administrador, por eso el script usa el registro en su lugar. Cada una de estas comenzó como una hipótesis de IA y varias eran erróneas hasta que se probaron.
Lo que no es mío, no lo reclamo. Mis pruebas fueron en Windows 11 Pro con una cuenta de Microsoft. El caso de la cuenta local fue una cuestión abierta aquí hasta que @Berbe aportó la observación en Windows 10 LTSC 19044.7417 (existe un LID/GDID desde la instalación incluso con solo una cuenta local). El informe registra de qué build proviene cada hallazgo — si una afirmación no lleva número de build, trátala como más débil.

Si encuentras aquí una afirmación que no se cumple en tu máquina, abre un issue con tu número de build — eso vale más para este repositorio que el acuerdo.

Créditos

Ingeniería inversa principal: SmtimesIWndr/gdid-reversal.
Observación de cuenta local en Windows 10 LTSC: @Berbe (PR #3).
Hechos del caso: United States v. Peter Stokes, N.D. Ill., julio de 2026.

Licencia

MIT. Herramienta defensiva y orientada a la privacidad. Úsala en máquinas que sean tuyas.

no-gdid — Actualizado!

Categorías