no-gdid

读取、理解并消除 Windows 全局设备标识符（GDID）——这个隐藏的按账户设备 ID 曾帮助 FBI 定位一名使用 VPN 的嫌疑人。

⚠️ 先坦诚声明： 本工具不会抹除你的 GDID，也不会让你匿名。GDID 存在于微软的服务器上，在你登录的那一刻就与你的 Microsoft 账户绑定。no-gdid 阻止你的机器重新注册并上报它——但它无法撤销微软已经掌握的信息。对于敏感工作而言，若想获得真正的隐私，唯一可靠的答案就是不要依赖 Windows。

这里的每一项发现都在真实的 Windows 11 Pro 虚拟机（版本 26200）上复现过，之后才被记录下来。没有任何内容是理论推测。证据见 docs/technical-writeup.md，并按置信度标注——至于验证过程究竟涉及哪些内容，见本工具是如何构建的。

---

背景故事

2026 年，FBI 追踪一名 Scattered Spider 嫌疑人，此人通过 VPN 在三个国家之间轮换 IP。暴露他的正是一个 GDID——微软将其与 Windows 安装绑定、并在收到传票时与执法部门共享的设备标识符。它不会因为你更换 IP 而改变。本仓库拆解了这个标识符，并展示你实际能对它做些什么。

GDID 究竟是什么

它不是硬件哈希——而是一个 64 位 MSA Device PUID，由 login.live.com 生成，缓存在本地注册表中，注册进微软的 Device Directory Service 图谱，并通过 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)

注册表 LID（十六进制）映射到服务器值 g:<decimal>。所有 Windows 设备 PUID 都位于 0x0018… 命名空间中（已验证：我们的测试值和法院 文件中的值共享该命名空间）。

快速开始

所有脚本均为 PowerShell、仅含 ASCII 字符，并可在任意代码页下运行。请打开一个提升权限的 PowerShell。

# 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

请先在带快照的虚拟机中测试。 该缓解措施会禁用系统服务。

各部分的作用

路径	用途	是否写入？
audit/Get-GDID-Audit.ps1	读取你的 GDID 以及 5 服务链的状态	否
audit/Get-GDID-Traffic.ps1	映射该链路的真实网络端点	否
mitigate/Block-GDID-Endpoints.ps1	在 hosts 中将 DDS/DO 端点黑洞化（保留 login.live.com）	使用 -Apply 时
mitigate/Disable-GDID-Services.ps1	禁用 CDPSvc/DoSvc/CDPUserSvc（保留 wlidsvc）	使用 -Apply 时
mitigate/Revert-GDID.ps1	恢复服务并清理 hosts	是
experiments/	用于验证发现的、受快照门控的探测脚本	破坏性，受门控
docs/	有来源的技术说明 + FAQ	—

我们证明了什么（以及什么不起作用）

• 读取你的 GDID 是可行的。 它就在注册表里。
• 删除它只是表面功夫。 删除该键、重启 wlidsvc、打开任意 Microsoft 应用——它会从服务器原样回来。它锚定在你的账户上。
• 关闭“遥测”（DiagTrack）毫无作用。 GDID 依附于 CDP/Delivery Optimization，而非经典遥测。那条常见建议是错误的。
• 你可以在不注销的情况下让上报静默。 禁用 CDP/DO 服务并 黑洞化其端点；该链路会安静下来，而你的 Microsoft 账户继续 正常工作。注意：DoSvc 即使以管理员身份也拒绝 Set-Service——它通过 注册表 Start=4 被禁用（见技术说明）。
• 过去已无法挽回。 PUID 已在服务器端存在。阻断只能减少未来的 关联；它无法撤回已经发送的内容。

权衡

禁用这些服务会破坏 Delivery Optimization 对等缓存、Phone Link / “继续在 PC 上操作”以及就近共享。wlidsvc 和 login.live.com 保持不动，以便 Microsoft 账户登录继续正常工作。

文档

• docs/technical-writeup.md — 完整链路、注册表 路径、端点，以及每条按置信度标注的论断（[COURT]、[OBSERVED]、 [STATIC]、[NO-GDID VÉRIFIÉ]）。
• docs/FAQ.md — 对显而易见问题的简短回答。

本项目是如何构建的

本项目在大量 AI 辅助（Claude）下完成调查与撰写。提交 历史说明了这一点，本节也是如此——你不应该需要自己去挖掘。

这在实践中意味着什么，坦白说：

• AI 主导了调查。 它阅读了逆向工程资料，梳理了 服务链，提出了待检验的假设，并撰写了大部分 PowerShell 以及 你正在阅读的这些文字。
• 每个测试都由我本人在自己的虚拟机上运行。 VMware 中的 Windows 11 Pro build 26200，登录真实的 Microsoft 账户，每个破坏性步骤前都做快照。截图中的 GDID 就是那台虚拟机的，这也是我放心展示它的原因。
• 关键论断都经过人工核验，而非直接采信。 删除 LID 键并重启 wlidsvc，确实会在任意 Microsoft 应用请求时带回同一个 标识符——我亲眼看到了。那台虚拟机上 DiagTrack 早已停止，而 GDID 仍然存在， 这正是“只要关掉遥测”这条建议被推翻的原因。DoSvc 确实会以管理员身份拒绝 Set-Service，这也是脚本改走注册表的原因。这些起初都是 AI 的假设， 其中若干在测试前是错误的。
• 不属于我的，我不冒认。 我的测试环境是 Windows 11 Pro 加 Microsoft 账户。本地账户的情况在这里原本是个未解问题，直到 @Berbe 贡献了在 Windows 10 LTSC 19044.7417 上的观察（即使仅使用本地账户，安装时也会存在 LID/GDID）。技术 说明记录了每条发现来自谁的构建——如果某条论断没有附带构建 号，请将其视为较弱。

如果你发现这里的某条论断在你的机器上不成立，请附上你的 构建号提交 issue——这对本仓库比赞同更有价值。

致谢

• 主要逆向工程：SmtimesIWndr/gdid-reversal。
• 在 Windows 10 LTSC 上的本地账户观察：@Berbe（PR #3）。
• 案件事实：United States v. Peter Stokes，N.D. Ill.，2026 年 7 月。

许可证

MIT。防御性、注重隐私的工具。请在你拥有的机器上使用它。