GDID Windows - Cut the tracker that follows you even under VPN - Korben<br>Aller au contenu principal

EN<br>FrançaisFR<br>EnglishEN<br>日本語JA

GDID Windows - Cut the tracker that follows you even under VPN<br>July 8, 2026 at 17:59<br>BY<br>KORBEN ✨<br>6 MIN READ<br>/Related categories

Listen to this article<br>~ 8 minAs I mentioned earlier, in April 2026, the FBI caught an alleged Scattered Spider member. The guy was hiding his traffic behind a VPN, with IPs across three different countries. And guess what? It wasn't a wrong move that gave him away - it was an identifier that your Windows carries 24/7 and that Microsoft hands over to authorities when asked: the GDID . I've already talked about it<br>in this article<br>, and after writing it, I started wondering whether we could get rid of it.<br>So I spun up a small Windows 11 Pro VM and dug in with the help of my favorite LLM - here's what I found. What works, and especially what doesn't work at all, you'll see.<br>First, you need to understand what the GDID actually is. It's not your motherboard's serial number, it's not a hash tied to your hardware. No - it's a 64-bit PUID, meaning an identifier that Microsoft's servers attach to your account the moment you open a Windows session. It's written in plain text in your registry, your machine registers it in a directory on Microsoft's side, and a service quietly sends it back up when needed. And if you change your IP with a VPN, it doesn't care. The GDID doesn't budge one bit.<br>Look your own tracker in the face<br>Let's start by seeing it with our own eyes. Open a PowerShell and paste this:<br>$lid=(Get-ItemProperty 'HKCU:SOFTWAREMicrosoftIdentityCRLExtendedProperties').LID<br>"g:$([Convert]::ToUInt64($lid,16))"<br>On my VM, it spat out g:6755487812206045. That's the one Microsoft can tie to everything I do. (In theory, mind you, because this is the code associated with my VM, so I don't care - which is why I'm showing it to you.)

You just read the label that's been stuck on your back.<br>Delete it? Forget it<br>Basic reflex: delete the key from the registry at HKCU:SOFTWAREMicrosoftIdentityCRLExtendedProperties and boom, no more tracker. That's what I tried first… I wiped the value, restarted the service that handles it, and nothing. Done? Nope. I opened the Microsoft Store for two seconds, and the GDID came back. Not a new one either - THE SAME ONE!!<br>That's the crazy part. Your GDID isn't stored on your disk - it's stored at Microsoft, firmly attached to your account like a barnacle on a rock. Your PC just re-downloads it again and again. Sure, if you reinstall everything, Windows gives you a new number, fine, but the old one and everything linked to it stays nice and warm on their servers. The past, you never get that back…<br>Disabling telemetry changes nothing either<br>Another piece of advice you see everywhere is to disable Windows telemetry. On my VM, the classic telemetry service was already stopped. And yet my GDID was right there, perfectly readable, and the services that send it back up were running at full speed. The tracker doesn't go through the telemetry you think you're cutting. It goes elsewhere - through the Connected Devices Platform and Delivery Optimization services.<br>You can click every privacy toggle in the settings, it doesn't give a damn.<br>Turning off the tap for real<br>Since we can't erase it, we're going to do the only thing within our power: stop it from getting out. And without logging out of the Microsoft account, so the PC stays usable.<br>For that, we have 2 levers. The first is to disable the services that register and report your machine's info. The second is to send Microsoft's servers into the void simply via the hosts file - so even if the snooping services are running, they can't reach anyone. And most importantly, we don't touch login.live.com, otherwise goodbye Microsoft account login.<br>There is one small catch, as you might expect… The service that reports the GDID, DoSvc, refuses to be disabled the normal way. Even as admin, Windows throws an "Access denied" at you. The workaround is to disable it directly in the registry, where the admin does have write access where the service manager blocks you.<br>Now, rather than dumping a ton of lines of code for you to copy-paste, I've bundled everything into clean, tested scripts, with a command to revert everything back to how it was.<br>The project is here:<br>no-gdid on GitHub<br>. First run the read-only audit to see where you stand, then the blocking scripts in preview mode, and only then with the option that actually applies changes. Test it in a VM with a snapshot before doing this on your real machine, because we are disabling system services after all. And if you just want to cut the network for a specific process without all this fuss, good old<br>ProcNetBlocker [FR]<br>already handles part of the job.<br>Alright, let's go!<br>Open a PowerShell as administrator, and the first time, do it in a VM with a snapshot so you can test things and get familiar with the commands. Step 1, clone the project:<br>winget install...