no-gdid

Lies, verstehe und bringe den Windows Global Device Identifier (GDID) zum Schweigen — die versteckte, kontoabhängige Geräte-ID, die dem FBI half, einen Verdächtigen zu finden, der ein VPN nutzte.

⚠️ Ehrlicher Hinweis vorab: Dieses Tool löscht deine GDID nicht und macht dich nicht anonym. Die GDID liegt auf Microsofts Servern, verknüpft mit deinem Microsoft-Konto, sobald du dich anmeldest. no-gdid verhindert nur, dass deine Maschine sie erneut registriert und meldet — es kann nicht rückgängig machen, was Microsoft bereits hat. Für echte Privatsphäre bei sensibler Arbeit ist die einzige verlässliche Antwort, nicht von Windows abhängig zu sein.

Jede Erkenntnis hier wurde auf einer echten Windows-11-Pro-VM (Build 26200) reproduziert, bevor sie aufgeschrieben wurde. Nichts ist theoretisch. Siehe docs/technical-writeup.md für die Belege, gekennzeichnet nach Vertrauensgrad — und Wie dieses Projekt aufgebaut wurde für das, was diese Verifizierung tatsächlich beinhaltete.

Die Geschichte

Im Jahr 2026 verfolgte das FBI einen Scattered-Spider-Verdächtigen, der seine IP-Adressen über ein VPN in drei Ländern rotierte. Verraten wurde er durch eine GDID — eine Gerätekennung, die Microsoft an eine Windows-Installation bindet und auf Vorladung an Strafverfolgungsbehörden weitergibt. Sie ändert sich nicht, wenn du deine IP änderst. Dieses Repo zerlegt diese Kennung und zeigt, was du tatsächlich dagegen tun kannst.

Was die GDID wirklich ist

Kein Hardware-Hash — sondern eine 64-Bit-MSA-Device-PUID, die von login.live.com geprägt, lokal in der Registrierung zwischengespeichert, in den Device-Directory-Service-Graphen von Microsoft eingetragen und über Delivery Optimization gemeldet wird.

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)

Der Registrierungs-LID (hex) wird auf den Serverwert g:<decimal> abgebildet. Alle Windows-Geräte-PUIDs liegen im Namespace 0x0018… (verifiziert: Unser Testwert und der aus der Gerichtsakte teilen ihn).

Schnellstart

Alle Skripte sind PowerShell, rein ASCII, und laufen unter jeder Codepage. Öffne eine PowerShell mit Administratorrechten.

# 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 zuerst in einer VM mit einem Snapshot. Die Gegenmaßnahme deaktiviert Systemdienste.

Was die einzelnen Teile tun

Pfad	Zweck	Schreibt?
`audit/Get-GDID-Audit.ps1`	Liest deine GDID + den Zustand der 5-Dienste-Kette	Nein
`audit/Get-GDID-Traffic.ps1`	Ermittelt die tatsächlichen Netzwerk-Endpunkte der Kette	Nein
`mitigate/Block-GDID-Endpoints.ps1`	Leitet die DDS/DO-Endpunkte in `hosts` ins Leere (behält `login.live.com`)	Mit `-Apply`
`mitigate/Disable-GDID-Services.ps1`	Deaktiviert `CDPSvc`/`DoSvc`/`CDPUserSvc` (behält `wlidsvc`)	Mit `-Apply`
`mitigate/Revert-GDID.ps1`	Stellt Dienste wieder her + bereinigt `hosts`	Ja
`experiments/`	Durch Snapshots abgesicherte Sonden zum Belegen der Erkenntnisse	Destruktiv, abgesichert
`docs/`	Belegte technische Dokumentation + FAQ	—

Was wir bewiesen haben (und was nicht funktioniert)

Das Lesen deiner GDID funktioniert. Sie steht direkt in der Registrierung.
Das Löschen ist nur kosmetisch. Entfernst du den Schlüssel, startest wlidsvc neu und berührst eine beliebige Microsoft-App, kommt sie identisch vom Server zurück. Sie ist an dein Konto gebunden.
Das Abschalten der „Telemetrie“ (DiagTrack) bewirkt nichts. Die GDID wird über CDP/Delivery Optimization übertragen, nicht über klassische Telemetrie. Dieser weit verbreitete Rat ist falsch.
Du kannst die Berichterstattung zum Schweigen bringen, ohne dich abzumelden. Deaktiviere die CDP/DO-Dienste und leite ihre Endpunkte ins Leere; die Kette wird ruhig, während dein Microsoft-Konto weiter funktioniert. Einschränkung: DoSvc verweigert Set-Service selbst als Admin — es wird über die Registrierung Start=4 deaktiviert (siehe die Dokumentation).
Die Vergangenheit ist vorbei. Die PUID existiert bereits serverseitig. Blockieren reduziert künftige Korrelation; es zieht nicht zurück, was gesendet wurde.

Kompromisse

Das Deaktivieren dieser Dienste bricht den Peer-Cache von Delivery Optimization, Phone Link / „Continue on PC“ und die Umgebungsfreigabe. wlidsvc und login.live.com bleiben unangetastet, sodass die Anmeldung mit dem Microsoft-Konto weiter funktioniert.

Dokumentation

docs/technical-writeup.md — die vollständige Kette, Registrierungspfade, Endpunkte und jede Behauptung mit Vertrauensgrad ([COURT], [OBSERVED], [STATIC], [NO-GDID VÉRIFIÉ]).
docs/FAQ.md — kurze Antworten auf die offensichtlichen Fragen.

Wie dieses Projekt aufgebaut wurde

Dieses Projekt wurde mit starker KI-Unterstützung (Claude) untersucht und geschrieben. Die Commit-Historie sagt es, und dieser Abschnitt auch — du solltest nicht danach graben müssen.

Was das in der Praxis bedeutet, ehrlich:

Die KI hat die Untersuchung vorangetrieben. Sie hat das Reverse Engineering gelesen, die Dienstekette kartiert, die zu testenden Hypothesen vorgeschlagen und den Großteil des PowerShell-Codes und der Prosa geschrieben, die du gerade liest.
Ich habe jeden Test selbst auf meiner eigenen VM ausgeführt. Windows 11 Pro Build 26200 in VMware, angemeldet mit einem echten Microsoft-Konto, Snapshot vor jedem destruktiven Schritt. Die GDID in den Screenshots ist die dieser VM, weshalb ich sie unbesorgt zeigen kann.
Die wichtigen Behauptungen wurden von Hand geprüft, nicht übernommen. Das Löschen des LID-Schlüssels und ein Neustart von wlidsvc bringen tatsächlich die gleiche Kennung zurück, sobald eine Microsoft-App danach fragt — ich habe es beobachtet. DiagTrack war auf dieser VM bereits gestoppt und die GDID war immer noch da, was den Rat „einfach Telemetrie abschalten“ erledigt hat. DoSvc verweigert Set-Service tatsächlich als Admin, weshalb das Skript stattdessen über die Registrierung geht. Jede dieser Erkenntnisse begann als KI-Hypothese, und einige davon waren falsch, bis sie getestet wurden.
Was nicht meins ist, beanspruche ich nicht. Meine Tests liefen auf Windows 11 Pro mit einem Microsoft-Konto. Der Fall mit lokalem Konto war hier eine offene Frage, bis @Berbe die Beobachtung unter Windows 10 LTSC 19044.7417 beigetragen hat (eine LID/GDID existiert bereits ab der Installation, selbst mit nur einem lokalen Konto). Die Dokumentation hält fest, von welchem Build jede Erkenntnis stammt — wenn eine Behauptung keine Build-Nummer trägt, behandle sie als schwächer.

Wenn du hier eine Behauptung findest, die auf deiner Maschine nicht zutrifft, eröffne ein Issue mit deiner Build-Nummer — das ist für dieses Repo mehr wert als Zustimmung.

Danksagungen

Primäres Reverse Engineering: SmtimesIWndr/gdid-reversal.
Beobachtung zum lokalen Konto unter Windows 10 LTSC: @Berbe (PR #3).
Fakten zum Fall: United States v. Peter Stokes, N.D. Ill., Juli 2026.

Lizenz

MIT. Defensive, datenschutzorientierte Werkzeuge. Nutze sie auf Maschinen, die dir gehören.

no-gdid — Updated!

Kategorien