GitHub - yegors/deGDID: Deletes all instances of Microsoft's GDID and prevents minting of new ones · GitHub
/" data-turbo-transient="true" />
Skip to content
Type / to search
Sign in<br>Sign upAppearance settings
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
yegors
deGDID
Public
Notifications<br>You must be signed in to change notification settings
Fork<br>25
Star<br>585
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>20 Commits<br>20 Commits
docs
docs
tests
tests
tools
tools
.gitignore
.gitignore
LICENSE
LICENSE
README.md
README.md
degdid.ps1
degdid.ps1
View all files
Repository files navigation
degdid
Last updated: 2026-07-16
Research and practical hardening for Microsoft's Global Device Identifier (GDID) , a server-assigned installation identifier that Windows can acquire even when the interactive user has only a local account.
The repository documents the wider GDID lifecycle. The shipped degdid.ps1 has a narrower operational objective:
On a supported Windows target, remove real server-issued GDID state from the known local stores and keep the DeviceAdd path continuously blocked.
That is a GDID completion gate. It is not a general telemetry, browser-privacy, or court-record-channel suppression claim.
Why it exists
GDID is a server-assigned 64-bit Device PUID that Windows can mint through<br>Microsoft's DeviceAdd infrastructure and retain across several local identity<br>stores. A local Windows account does not prevent that machine-level mint.
Court reporting in 2026 established that Microsoft held a GDID-to-URL/time/IP<br>association in one investigation. The public record does not identify the Windows<br>component or network channel responsible; this tool makes no claim to block that<br>unknown channel.
Is this for my PC?
The mutation path is designed for an unmanaged personal Windows installation with<br>one loaded human profile:
Windows 10 22H2/build 19045, or Windows 11 build 22000 or newer;
no domain, Entra, workplace, or MDM enrollment; and
an elevated 64-bit Windows PowerShell session.
Windows 11 25H2/build 26200 is the fully lab-validated line. Other accepted builds<br>warn. Managed systems, ambiguous users, and multiple loaded human profiles are<br>refused instead of guessed at.
Status can still inspect unsupported systems. See the<br>usage guide for the complete eligibility rules.
Quick start
Open an elevated PowerShell window:
.\degdid.ps1 -Status<br>.\degdid.ps1 -Protect<br>.\degdid.ps1 -Status
ProtectedNoRealGdid is the only complete result. Re-run Status after major Windows,<br>firewall, security-product, or hosts-file changes.
To remove degdid's network controls:
.\degdid.ps1 -Unblock
Unblock allows Windows to mint a real GDID again. See the<br>usage and CLI reference for every command, verdict, exit code,<br>DryRun behavior, pre-first-online setup, and recovery details.
What Protect does
Protect:
applies a dual-stack hosts block and checks the actual DeviceAdd path;
refreshes firewall defense-in-depth where policy allows it;
clears known GDID copies and device-identity rehydrate sources from the target<br>user, .DEFAULT, and SYSTEM; and
waits, rechecks the network gate, and refuses success if identity state returns.
The network gate is applied before identity mutation. If a required check fails, the<br>script stops instead of continuing with a partial protection state.
Canonical protection uses Wipe. Decoy mode exists for research but is not considered<br>a clean completion state. Technical mutation details live in<br>countermeasures.md and<br>surfaces.md.
What success means
ProtectedNoRealGdid means the supported environment was readable, no real-shaped<br>PUID remained in the known inventory, and the DeviceAdd gate verified. It does not<br>mean Microsoft deleted historical records or that unrelated telemetry stopped.
Status intentionally displays full local account, profile, PUID, and g:<br>values. Treat its output as private machine-identifying data.
Lab evidence and limits
The completed Windows 11 25H2/build-26200 lifecycle includes:
prevention before first network access;
natural mint, Protect, reboot, and repeated identity triggers;
more than 33 hours protected on the local-account lab VM;
Unblock, observed remint, reprotect, and clean reboot; and
an MSA-connected field run that remained protected through sign-out/in,<br>sleep/resume, reboot, and 18 hours.
The evidence is bounded to the recorded machines and windows. Windows 10 and other<br>Windows 11 builds are accepted with warnings, not equivalent lab claims. See the<br>experiment index for the failures, fixes, timings,<br>and limitations that produced the current design.
Expected compatibility impact
Blocking login.live.com, account.live.com,...