VPN 隐藏了 IP，却没有隐藏 Windows：GDID 如何暴露一台电脑
VPN 可以换掉出口地址，却换不掉操作系统记住你的方式。
VPN 可以换掉出口地址，却换不掉操作系统记住你的方式。2026 年 7 月公开的一份刑事起诉材料里，一串g:开头的数字，把藏在不同账号和不同 IP 后面的活动重新拼回了同一台 Windows 电脑。
IP 消失之后
很多人对匿名的理解，停在网络出口。
打开 VPN，网站看到的是另一个国家的 IP；换掉浏览器，清空 Cookie；再注册一个没有用过的新邮箱。做完这些，屏幕上的自己看起来已经与昨天毫无关系。
但这只是浏览器看到的世界。
在它下面，Windows 仍然运行着账户服务、设备发现、诊断遥测、云同步和身份令牌。浏览器努力让你成为一个陌生人时，操作系统可能还在后台平静地说：这仍然是昨天那台机器。
2026 年 7 月公开的 United States v. Peter Stokes 起诉材料里，一个名为 Global Device Identifier 的 Windows 标识符——GDID——成为连接多段活动的线索之一。
VPN 隐藏了地址。
设备没有忘记自己。
一串 g: 开头的数字
案件材料中出现的 GDID 是：
g:6755467234350028
把十进制部分转成十六进制，结果是：
6755467234350028 = 0x0018000FC8CB93CC
这一步先排除了网上流传最广的两个说法。
它不是一个 128-bit GUID，而是能够装进
UInt64 的 64 位整数；它也不像是由 CPU、GPU 或硬盘序列号直接计算出的硬件指纹。起诉材料明确写到：Windows 更新后 GDID 保持不变，但重新安装 Windows 会得到新的 GDID。如果输入只是固定硬件序列号，重装后不应该自然产生另一结果。法庭材料能确认的事实只有三点：
- GDID 是 Windows 生态里的持久设备级标识符；
- 它绑定一次 Windows 安装，而不是简单绑定某块硬件；
- 一个 Microsoft 用户可以关联多个 GDID。
至于它在 Windows 内部是什么，公开逆向给出了一条更具体的解释：
0x0018 高位前缀落在 Microsoft Passport 的 Device PUID 命名空间；g: 只是服务端把这个 64 位整数转成十进制后的展示前缀。这仍然不是 Microsoft 的官方定义，却比“神秘硬件哈希”更符合现有证据。逆向者在 Windows 11 26200 上结合公开 PDB、静态分析和 ETW 复现了相同的数据路径，也在身份存储中找到了对应的 16 位十六进制值。
换句话说，GDID 更像一个由身份服务分配、被系统组件持久化并注册进设备图谱的安装编号。
它不是 Windows 临时算出来的一枚浏览器指纹。
它是这套 Windows 在云端身份系统里的名字。
GDID 在 Windows 里如何流动
真正有价值的不是某一个注册表键，而是从身份服务到设备图谱的整条数据路径。
根据当前公开逆向，这条链大致是：
login.live.com / Windows identity service │ │ 分配 Device PUID，并返回设备身份材料 ▼ wlidsvc.dll Microsoft Account / Passport 服务 │ │ 持久化 LID / DeviceId 与设备令牌 ▼ IdentityCRL / IdentityStore │ │ GetStableDeviceIdAsync() ▼ cdp.dll / CDPSvc / CDPUserSvc Connected Devices Platform │ │ RegisterUserDeviceAsync() ▼ DDS（Device Directory Service） │ ├── dds.microsoft.com ├── activity.windows.com └── 设备、账户与活动关系图
这里有三个值得拆开的技术点。
wlidsvc：身份的来源
wlidsvc.dll 是 Microsoft Account / Passport 身份服务。公开符号中能看到 CreateNewDeviceIdentity、DeviceAssociateRequest、DevicePUID 和 LogToRegistry 一类名称。逆向结果显示，客户端向身份服务完成设备注册后，从服务端响应中取得 Device PUID，再把它写入本地身份存储。因此，GDID 更像服务端分配的设备身份，而不是本地硬件序列号经过某个哈希函数后的结果。
CDP：身份的搬运者
cdp.dll 并不负责计算 GDID。它通过账户提供程序请求 GetStableDeviceIdAsync()，收到字符串后，将设备注册到 Device Directory Service。公开 PDB 中能看到 DdsRegistrationClient、GetStableDeviceIdFromProvider 与 OnGetStableDeviceIdCompleted 等符号。Microsoft 对 CDP 的公开协议说明也很直接：它负责发现、认证和验证用户与设备，并在云端或近场设备之间建立连接。手机连接、云剪贴板、跨设备活动等功能，都需要这种稳定的设备连续性。
Delivery Optimization：身份的另一个出口
Microsoft 的 Update Compliance / Delivery Optimization 数据结构中还存在
UCDOStatus.GlobalDeviceId 字段。也就是说，这个标识并不只在 CDP 的设备图里出现，还可以跟 LastCensusSeenTime、ISP、国家和城市等遥测字段处于同一类设备状态记录中。这正是 GDID 的取证价值：它自己不等于一个人，却能为账号、时间、IP 与服务活动提供稳定的连接键。
账号 A ──┐ VPN IP 1 ─┼── g:6755467234350028 ── 时间线 账号 B ──┤ 机房 IP 2 ┘
一个 VPN 出口只能证明有人用过它；一个临时邮箱也不等于真实身份。但如果几段活动共享同一个安装标识，原本孤立的日志就有了 JOIN 条件。
GDID 不负责完成归因。
它负责让原本不能相连的表，开始能够相连。
为什么 VPN 挡不住它
VPN 工作在网络路径上。它加密设备到 VPN 节点之间的流量，并用代理服务器的地址替换真实出口。
它不会替你完成下面这些事：
- 重置 Windows 的安装身份
- 退出已经登录的 Microsoft 账户
- 清除 OneDrive、Edge 或商店应用中的设备令牌
- 阻止系统组件提交诊断和设备信息
- 隔离浏览器配置、广告 ID 与应用指纹
- 改变时区、语言、作息和输入习惯
所以更准确的表达不是“VPN 没用”，而是它只解决了一层问题。
一台真实设备通常同时携带五套身份：网络层的 IP，系统层的安装标识，账户层的登录关系，应用层的 Cookie 与指纹，以及行为层的时间和操作习惯。只替换最外面的一层，其余部分不会自动失忆。
在本机验证这条链
与其寻找某个来路不明的“GDID 清理工具”，不如先确认自己的 Windows 是否暴露了对应设备 PUID。
在使用 Microsoft Account 的系统上，公开逆向给出的读取位置是：
$path = 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties' $hex = (Get-ItemProperty $path -ErrorAction Stop).LID [pscustomobject]@{ HexDevicePuid = $hex Gdid = 'g:' + [Convert]::ToUInt64($hex, 16) }
如果
ExtendedProperties\LID 为空，还可以检查令牌存储：Get-ChildItem ` 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token' ` -Recurse -ErrorAction SilentlyContinue | ForEach-Object { Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue } | Where-Object DeviceId | Select-Object PSPath, DeviceId
0018... 形式的 16 位十六进制值，转换成无符号 64 位十进制后，就会得到案件材料中 g:<decimal> 的结构。不要公开粘贴真实输出。 Device PUID、MSA CID 和 Windows SID 都具有识别价值。截图时至少遮掉完整 ID、账户名和租户信息。
再看设备注册与服务状态：
# Entra / Workplace Join、DeviceId、PRT 与 SSO 状态 dsregcmd /status # CDP 与诊断服务是否运行 Get-Service CDPSvc, CDPUserSvc*, DiagTrack, DoSvc ` -ErrorAction SilentlyContinue | Select-Object Name, Status, StartType # 检查系统是否注册了 CDP 相关 ETW Provider logman query providers | findstr /i "Microsoft.Windows.CDP ConnectedDevices Identity"
需要做实验验证时，可以用 ETW 观察 CDP，而不是只盯着代理抓包。CDP 的注册过程发生在系统身份栈内部，TLS 代理只能看到它连接了哪些端点，未必能直接得到设备 ID。
# 先枚举本机实际存在的 Provider，再按名称创建跟踪会话 logman query providers | findstr /i "Microsoft.Windows.CDP" # 示例：将找到的 Provider 名称填入 -p logman create trace CDPTrace ` -p "Microsoft.Windows.CDP" ` -o "$env:TEMP\cdp.etl" ` -ets # 重现设备服务活动后停止并转为 XML logman stop CDPTrace -ets tracerpt "$env:TEMP\cdp.etl" ` -o "$env:TEMP\cdp.xml" ` -of XML
这些检查只能验证本地身份存储、服务和事件路径，不能列出 Microsoft 服务端已经保存的全部历史。客户端证据与服务端数据之间，仍然隔着平台内部实现和保留策略。
真正有效的办法，是建立边界
如果目标只是减少广告追踪，没有必要把电脑改造成取证实验室。关闭浏览器同步，使用独立配置文件，限制第三方 Cookie，再配合 VPN，已经能挡住大量廉价的跨站关联。
如果目标是避免工作、测试与日常生活互相污染，就需要更硬的边界。
第一层：把账户分开
不要在同一个 Windows 用户和同一个浏览器配置里混用所有身份。
为工作、开发测试和日常使用分别建立浏览器 Profile；不导入彼此的密码与扩展；不让 Edge 或 Chrome 用同一个云账户同步。Windows 的“电子邮件和账户”与“访问工作或学校”中，也应删除不再需要的连接。
但要明确一个容易被误解的边界：本地账户不等于没有 GDID。 后续逆向显示，CDP 在没有 MSA 时仍存在匿名设备注册路径。使用本地账户的价值，是减少 MSA、OneDrive、Edge 同步和商店令牌带来的强账户关联，而不是让 Windows 失去安装身份。
它减少的是图上的边，不是删除图里的设备节点。
第二层：用 VM 把安装分开
GDID 追踪的是安装连续性，因此真正对应它的控制手段不是清 Cookie，而是建立新的 OS 安装边界。
对大多数人而言，最现实的方案是单独创建一台 Windows VM。可以使用 VMware Workstation、VirtualBox 或其他本地虚拟化软件，重点不在具体产品，而在于让 guest 拥有独立的系统盘、注册表、身份存储与应用数据。
一套够用的 VM 配置如下：
系统：Windows 11 干净安装 CPU：2～4 vCPU 内存：8 GB 磁盘：80 GB 动态扩展 网络：NAT；需要时在 guest 内连接 VPN 账户：本地账户，不登录日常 Microsoft Account 共享：关闭共享剪贴板、拖放与宿主机目录映射 快照：完成系统更新与基础配置后创建基线快照
不要直接克隆一台已经登录过日常账号的 Windows。更稳妥的做法是从官方 ISO 新建 VM，在安装阶段就保持身份隔离。Edge、Microsoft Store、OneDrive、Office 和浏览器同步也不要登录宿主机正在使用的账户。
完成安装后，可以在宿主机与 VM 中分别执行：
# 比较两套 Windows 的安装标识 Get-ItemPropertyValue ` 'HKLM:\SOFTWARE\Microsoft\Cryptography' ` -Name MachineGuid # 检查 VM 是否意外加入组织目录或工作账户 dsregcmd /status
两边的
MachineGuid 应当不同；VM 中的 AzureAdJoined 与 WorkplaceJoined 也不应因为复用账户而意外变成 YES。这里的目标不是“让 VM 没有 GDID”。VM 内的 Windows 仍可能获得自己的安装级标识。真正被切开的，是宿主机与 guest 的安装生命周期、令牌缓存、浏览器状态和应用数据。
如果 VM 又登录了同一个 MSA、打开同一个 OneDrive，并同步同一套 Edge Profile，那么两个 GDID 仍然可以在账户图谱中汇合。虚拟化只负责建立边界，是否跨过这条边界，最终取决于账户和数据是否被重新带了进去。
VM 不是隐身斗篷。
但它至少比日常主机里的无痕窗口，多了一堵真正存在的墙。
第三层：减少不必要的上报
Windows 11 可以在：
设置 → 隐私和安全性 → 诊断和反馈把诊断数据调整到版本允许的最低级别，并关闭不需要的个性化体验、活动历史、附近共享、手机连接和跨设备功能。
企业版或专业版还可以通过组策略统一设置：
计算机配置 → 管理模板 → Windows 组件 → 数据收集和预览版本 → 允许诊断数据
有些人会直接禁用
DiagTrack：Stop-Service DiagTrack -Force -ErrorAction SilentlyContinue Set-Service DiagTrack -StartupType Disabled
这会影响部分诊断与设备功能，而且不能删除已经存在于服务端的历史记录。它是一种减少后续信号的措施，不是身份重置按钮。
一套够用的落地配置
如果不想在几十个选项里反复权衡，可以采用下面这套组合：
- 日常主机继续正常使用，不把 VPN 当匿名保证。
- 为需要隔离的工作建立一台干净 VM 或独立系统。
- 隔离环境使用本地账户，不登录日常 MSA、OneDrive 和浏览器同步。
- 为该环境建立专用浏览器配置，不导入密码、书签和扩展。
- 将诊断、活动历史、附近共享和跨设备功能降到实际需要的最低范围。
- VPN 只在最后负责网络出口与传输加密。
- 保存基线快照，环境被长期使用后重新部署，而不是相信“清理工具”能抹掉所有痕迹。
顺序很重要。
先隔离安装和账户，再处理应用，最后才是 VPN。反过来做，就像换了车牌，却仍然开着同一辆装满定位设备的车。
不要迷信修改一个注册表键
在这类话题下面，最容易出现的答案通常是：找到某个键，删除它，重新启动，身份就消失了。
现实没有这么整齐。
设备身份可能同时存在于注册表、令牌缓存、应用数据库、诊断事件和服务端历史里。强行修改
MachineGuid、硬件序列号或未知的身份字段，还可能破坏系统激活、商店授权、设备管理与安全产品。更麻烦的是，即使本地值真的变化了，服务端仍然可以用账户、时间、网络和行为重新连接前后两段活动。
隐私工程真正可靠的原则从来不是“找到一个神秘 ID 并删掉”，而是让不同身份从一开始就不要共享同一套环境。
这既是安全能力，也是监控能力
稳定的设备身份并不天然邪恶。
它可以识别异常登录，阻止批量注册和优惠滥用，也能在凭据泄露后区分熟悉设备与陌生设备。企业风控依赖的许多能力，本质上都建立在某种设备连续性之上。
问题在于，同一种技术有两张脸。
能够识别“这还是昨天那台电脑”的系统，也能跨账号、跨网络和跨时间重新连接一个人。反欺诈需要稳定性，隐私则希望尽量减少关联。两者之间不存在一个自动正确的答案。
真正值得追问的是：标识符在什么条件下生成，被哪些组件读取，会保存多久，又能与什么数据合并。用户是否能看到它、撤销它，或者要求平台忘记它。
GDID 事件暴露的并不是 Windows 里藏着一串神秘数字。
它暴露的是现代计算已经从“使用一台电脑”，变成“让一台电脑持续加入云端身份系统”。安装完成的那一刻，本地设备就开始向远端服务介绍自己是谁、属于谁，以及之前是否来过。
这套机制平时安静得几乎没有存在感。
直到有人试图消失。
结语
Peter Stokes 案最终如何裁判，仍应交给司法程序。刑事起诉材料中的指控不等于定罪，公开逆向也不等于微软的官方实现说明。
但 GDID 留下的问题不会随着案件结束：当操作系统能够跨越 IP、账号和时间识别同一次安装，一台电脑究竟还是用户手中的私人物件，还是云端图谱里的一个长期节点？
VPN 当然仍然有价值。它能隐藏真实出口，减少本地网络窥探，也能保护公共 Wi-Fi 上的传输。
只是它从来都不是隐身斗篷。
VPN 可以替你换一条路。
真正需要隔离的，是一路上不断替你回答“你是谁”的那些系统。