Windows GDID 完整技术报告发布

背景

2026年7月1日，美国司法部（DOJ）解封了一份针对Peter Stokes（涉嫌为Scattered Spider / Octo Tempest / UNC3944 / 0ktapus成员）的联邦刑事起诉书。起诉书中提到了一个关键证据：Global Device Identifier (GDID)，即Windows生态系统中一个持久性的、设备级别的标识符，用于唯一标识某台设备上的Windows操作系统安装。微软在协助FBI进行活动归因时使用了该标识。

根据起诉书（United States v. Peter Stokes, N.D. Ill., July 2026）第25段，一个名为“g:6755467234350028”的GDID被用来追踪嫌疑人的ngrok账户。起诉书还描述了该GDID的IP历史、浏览记录（如访问empirehotelnyc.com、Growtopia/Ubisoft登录URL）与嫌疑人登录账户之间的关联。起诉书附带脚注指出，一个微软用户可能拥有多个GDID。

围绕GDID，社交媒体上出现了大量不准确的说法，例如声称它是“128位标识符，由安装时的序列号生成”。本文基于对Windows 11（版本26200）的真实机器复现、公共符号（PDB）逆向以及法院文档，完整还原了GDID的生成、存储与传输机制。

核心内容

1. GDID的真实本质

GDID是微软内部使用的一个设备标识符，在微软公共文档（Azure Monitor / Update Compliance / Delivery Optimization）中被称为GlobalDeviceId。其值表现为g:前缀后接一个十进制整数，例如g:6755467234350028。该十进制数转换为十六进制为0x0018000FC8CB93CC，是一个64位的值，而非传闻中的128位。起诉书明确指出，重装Windows会产生一个新的GDID，因此它不是基于硬件序列号（如GPU）衍生的不可变标识。

2. 完整堆栈：从底层到上层

GDID的整个链路涉及四个主要组件，自底向上依次为：

• wlidsvc（Microsoft Account / Windows Live ID 服务）：是GDID的“铸币厂”。它通过调用login.live.com的Passport PPCRL SOAP接口，向服务器发送设备关联请求，从服务器返回的SOAP响应中解析出DevicePUID（Passport Unique ID，64位MSA标识符）。该PUID被存储在注册表中。wlidsvc.dll中包含CDeviceIdentityBase::CreateNewDeviceIdentity、DeviceAssociateRequest、DeviceIdStore::LogToRegistry等方法，以及BCryptGenRandom用于生成设备认证密钥（而非PUID本身）。客户端通过XPath从响应中提取/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped节点，解析为BSTR字符串。

• Connected Devices Platform (CDP)：以cdp.dll + CDPSvc + CDPUserSvc构成。CDP本身不计算GDID，而是一个消费者：它通过调用身份堆栈的GetStableDeviceIdFromProvider接口，等待底层提供者（即微软账户或AAD身份COM）返回一个字符串形式的设备ID。逆向分析显示，CDP的OnGetStableDeviceIdCompleted回调中直接执行了assign操作，将传入的device-id字符串存储到成员字段，然后设置等待标志，没有任何计算或拼接硬件信息。

• Device Directory Service (DDS)：微软的跨设备身份图谱后端（支持Phone Link、云剪贴板、“在电脑上继续”、Nearby Share等功能）。CDP通过DDS注册客户端（ddsregistrationclient.cpp等）将设备注册到dds.microsoft.com、fd.dds.microsoft.com等端点。注册后的设备ID格式即为g:<decimal>。

• Delivery Optimization (更新合规 / Update Compliance)：在UCDOStatus表中公开记录GlobalDeviceId列，作为“微软内部使用的全局设备标识符”。该列紧邻LastCensusSeenTime、ISP、City、Country等地理IP信息，但Delivery Optimization仅是报告者，不拥有该ID。

3. 可复现的观察结果

作者在真实Windows 11 (26200)机器上进行了复现实验。通过强制清除CDP本地状态并重启CDPSvc，捕获CDP自身的ETW（Event Tracing for Windows）提供者，观察到了完整的握手过程：

• DdsClient::RegisterUserDeviceAsync() 触发，注册原因为“Startup”，账户类型为MSA。
• DDS服务返回HTTP 200，并返回设备ID：deviceid: 0018XXXXXXXXXXXX。
• 该deviceid以g:<decimal>形式写入，其高16位为0x0018，与起诉书中的GDID属于同一命名空间（设备PUID命名空间）。

4. 常见误解与纠正

• 误解1：GDID是128位。事实：实际为64位，十六进制长度可证。
• 误解2：GDID由硬件序列号生成。事实：重装产生新ID，且CDP直接获取，无任何硬件序列号参与；wlidsvc中虽然使用BCryptGenRandom生成的是设备认证密钥，而非PUID本身；PUID完全由服务器端分配。
• 误解3：使用本地账户可以避免生成GDID。事实：CDP有一个匿名设备路径，即使没有连接微软账号（MSA），也会生成一个GDID。MSA登录只是改变账户关联路径，不阻止GDID存在。

5. 寻找自己的GDID

在注册表中可以找到GDID（具体路径在原文§7中有说明，本解读未展示具体步骤，但原文指出可通过一次注册表读取获得）。文章提供了完整的可复现方法学说明，包括使用公共PDB和ETW捕获等。

6. 暴露减少与限制

文章最后讨论了降低暴露的方法，但本文中仅提及“Reducing the exposure”作为标题，未提供具体细节（原文中该部分内容较少）。同时作者诚实列出了方法学的局限性：由于仅基于单次复现和静态逆向，可能存在未覆盖的边缘情况。

关键要点

• GDID是真实存在的遥测项，已在联邦刑事起诉书中被用作证据，其值为g:前缀后接十进制64位整数。
• GDID并非128位，更非由硬件序列号派生；重装系统会产生新GDID，彻底排除硬件固化可能性。
• GDID的源头是微软账户服务（wlidsvc），在设备首次向login.live.com注册时，服务器返回一个Device PUID（Passport Unique ID），该PUID被写入注册表。
• CDP（Connected Devices Platform）是GDID的消费端，它从身份堆栈中获取该标识符并注册到DDS（Device Directory Service）图谱，本身不进行任何计算。
• Delivery Optimization是GDID的公开报告端，其UCDOStatus表在Azure Monitor文档中明确定义了GlobalDeviceId列。
• 即使用户使用本地账户登录，GDID依然存在（通过CDP的匿名设备路径）。MSA登录仅改变了账户关联方式。
• GDID在Windows 11 (26200)上可复现，作者通过清除CDP状态、重启服务并捕获ETW事件，验证了完整的注册握手。
• 所有技术声明均附带可信度标签：[COURT]（法院原始事实）、[OBSERVED]（实机复现）、[STATIC]（二进制及PDB逆向证明）、[ASSESSED]（基于证据的强推断）。原始文章对每个标签的使用示例包括：
  • [COURT]：“根据补充起诉书第25段，GDID是g:6755467234350028。”
  • [OBSERVED]：“强制清除CDP状态后重启服务，捕获到DDS注册响应，设备ID结构与