no-gdid

Leia, entenda e silencie o Identificador Global de Dispositivo (GDID) do Windows — o ID de dispositivo oculto por conta que ajudou o FBI a localizar um suspeito que estava usando uma VPN.

⚠️ Aviso honesto desde já: esta ferramenta não apaga o seu GDID e não torna você anônimo. O GDID reside nos servidores da Microsoft, vinculado à sua Conta Microsoft, no momento em que você faz login. O no-gdid impede que sua máquina se registre novamente e o reporte — ele não pode desfazer o que a Microsoft já tem. Para privacidade real em trabalhos sensíveis, a única resposta confiável é não depender do Windows.

Cada descoberta aqui foi reproduzida em uma VM real do Windows 11 Pro (build 26200) antes de ser documentada. Nada é teórico. Consulte docs/technical-writeup.md para as evidências, marcadas por nível de confiança — e Como isto foi construído para saber o que essa verificação realmente envolveu.

---

A história

Em 2026, o FBI rastreou um suspeito do Scattered Spider que alternava IPs por meio de uma VPN em três países. O que o entregou foi um GDID — um identificador de dispositivo que a Microsoft vincula a uma instalação do Windows e compartilha com as autoridades mediante intimação. Ele não muda quando você muda seu IP. Este repositório desmonta esse identificador e mostra o que você pode realmente fazer a respeito.

O que o GDID realmente é

Não é um hash de hardware — é um MSA Device PUID de 64 bits gerado pelo login.live.com, armazenado em cache localmente no registro, registrado no grafo do Device Directory Service da Microsoft e reportado por meio do 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)

O LID do registro (hex) mapeia para o valor do servidor g:<decimal>. Todos os PUIDs de dispositivos Windows ficam no namespace 0x0018… (verificado: nosso valor de teste e o do processo judicial compartilham o mesmo namespace).

Início rápido

Todos os scripts são PowerShell, somente ASCII, e executam sob qualquer codepage. Abra um 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

Teste em uma VM com um snapshot primeiro. A mitigação desativa serviços do sistema.

O que cada parte faz

Caminho	Finalidade	Escreve?
audit/Get-GDID-Audit.ps1	Lê o seu GDID + o estado da cadeia de 5 serviços	Não
audit/Get-GDID-Traffic.ps1	Mapeia os endpoints de rede reais da cadeia	Não
mitigate/Block-GDID-Endpoints.ps1	Anula os endpoints DDS/DO no hosts (mantém login.live.com)	Com -Apply
mitigate/Disable-GDID-Services.ps1	Desativa CDPSvc/DoSvc/CDPUserSvc (mantém wlidsvc)	Com -Apply
mitigate/Revert-GDID.ps1	Restaura os serviços + limpa o hosts	Sim
experiments/	Sondas protegidas por snapshot usadas para provar as descobertas	Destrutivo, protegido
docs/	Relatório técnico com fontes + FAQ	—

O que provámos (e o que não funciona)

• Ler o seu GDID funciona. Está mesmo ali no registo.
• Eliminá-lo é cosmético. Remova a chave, reinicie o wlidsvc, abra qualquer aplicação da Microsoft — ele volta idêntico a partir do servidor. Está ancorado à sua conta.
• Desligar a "telemetria" (DiagTrack) não faz nada. O GDID viaja no CDP/Delivery Optimization, não na telemetria clássica. Esse conselho comum está errado.
• Pode silenciar o reporte sem terminar sessão. Desative os serviços CDP/DO e anule os respetivos endpoints; a cadeia fica silenciosa enquanto a sua Conta Microsoft continua a funcionar. Ressalva: o DoSvc recusa Set-Service mesmo como administrador — é desativado através do registo Start=4 (ver o relatório).
• O passado já foi. O PUID já existe do lado do servidor. O bloqueio reduz a correlação futura; não retira o que já foi enviado.

Compromissos

Desativar estes serviços quebra a colocação em cache de pares do Delivery Optimization, o Phone Link / "Continuar no PC" e a partilha de proximidade. O wlidsvc e o login.live.com são deixados em paz para que o início de sessão da Conta Microsoft continue a funcionar.

Documentação

• docs/technical-writeup.md — a cadeia completa, caminhos de registo, endpoints e cada afirmação etiquetada por confiança ([COURT], [OBSERVED], [STATIC], [NO-GDID VÉRIFIÉ]).
• docs/FAQ.md — respostas curtas às perguntas óbvias.

Como isto foi construído

Este projeto foi investigado e escrito com forte assistência de IA (Claude). O histórico de commits diz isso, e esta secção também — não devia ter de o procurar.

O que isso significa na prática, honestamente:

• A IA conduziu a investigação. Leu a engenharia reversa, mapeou a cadeia de serviços, propôs as hipóteses a testar e escreveu a maior parte do PowerShell e da prosa que está a ler.
• Eu executei todos os testes, na minha própria VM. Windows 11 Pro build 26200 em VMware, com sessão iniciada numa Conta Microsoft real, snapshot antes de cada passo destrutivo. O GDID nas capturas de ecrã é o dessa VM, e é por isso que me sinto à vontade para o mostrar.
• As afirmações que importavam foram verificadas à mão, não aceites. Eliminar a chave LID e reiniciar o wlidsvc faz mesmo voltar o mesmo identificador assim que qualquer aplicação da Microsoft o pede — vi isso acontecer. O DiagTrack já estava parado nessa VM e o GDID continuava lá, o que foi o que matou o conselho de "basta desligar a telemetria". O DoSvc recusa mesmo Set-Service como administrador, e é por isso que o script passa pelo registo. Cada uma destas começou como uma hipótese da IA e várias delas estavam erradas até serem testadas.
• O que não é meu, não o reivindico. Os meus testes foram em Windows 11 Pro com uma Conta Microsoft. O caso da conta local foi uma questão em aberto aqui até @Berbe contribuir com a observação em Windows 10 LTSC 19044.7417 (existe um LID/GDID desde a instalação mesmo apenas com uma conta local). O relatório regista de que build vem cada descoberta — se uma afirmação não tiver número de build, trate-a como mais fraca.

Se encontrar aqui uma afirmação que não se verifica na sua máquina, abra uma issue com o seu número de build — isso vale mais para este repositório do que concordância.

Créditos

• Engenharia reversa primária: SmtimesIWndr/gdid-reversal.
• Observação de conta local no Windows 10 LTSC: @Berbe (PR #3).
• Fatos do caso: United States v. Peter Stokes, N.D. Ill., julho de 2026.

Licença

MIT. Ferramentas defensivas e orientadas à privacidade. Use-as em máquinas que você possui.