TL;DR

[!NOTE] 以下内容属实，但缺少部分信息。无论是否使用MSA登录，你都会拥有一个GDID。我发帖时并未意识到这一点，但后来查证了。CDP有一个匿名设备路径，如果未连接MSA则会使用该路径。底层系统在事实上仍然是正确的，只是缺少了一些内容。

• GDID是真实的遥测项。 它出现在美国联邦刑事起诉书（United States v. Peter Stokes，伊利诺伊北区，2026年7月）中，显示为Global Device Identifier g:6755467234350028。
• 它是一个Microsoft账户“设备PUID”。 一个64位的Passport唯一标识符，当Windows安装注册Microsoft账户时分配，在设备图中记录为g:<十进制数>。
• 声明是错误的。 它不是“128位”，也不是“由序列号生成”。法院记录本身表明重新安装会产生新的GDID，这排除了它由硬件序列号（如GPU）派生的可能性。
• 自底向上的堆栈： wlidsvc（Microsoft账户服务）向login.live.com注册设备并获取设备PUID -> 存储在注册表中 -> Connected Devices Platform（cdp.dll / CDPSvc）读取并将其注册到设备目录服务（DDS） 图中 -> Delivery Optimization将其报告为文档化的UCDOStatus.GlobalDeviceId。
• 所有过程均在实机Windows 11（26200）上使用公开符号复现。你可以在一个注册表读取中找到自己的GDID（§7）。

[!NOTE] 置信度标记。 每个声明都带有标签，供您自行判断：[COURT] 主要来源事实，[OBSERVED] 在我的测试机上实机复现，[STATIC] 从二进制文件和公开Windows PDB中证明，[ASSESSED] 基于证据的强推理。

目录

1. 背景：法院实际说了什么
2. 驳斥流传的神话
3. GDID出现在哪里：Delivery Optimization
4. 谁拥有它：Connected Devices Platform到DDS
5. CDP如何获取：它消费，而非计算
6. 铸造者：MSA设备PUID（wlidsvc）
7. 查找你自己的GDID
8. 减少暴露
9. 方法（可复现）
10. 局限性与诚实说明

1. 背景：法院实际说了什么

2026年7月1日，美国司法部解封了一份针对Peter Stokes的刑事起诉书，他涉嫌是Scattered Spider（又名Octo Tempest / UNC3944 / 0ktapus）的成员。宣誓书描述了微软如何帮助FBI将活动归因到一台设备。

[!IMPORTANT] [COURT] 来自补充起诉书（¶25，第34页），原文如下：

“ngrok账户是通过全局设备标识符 g:6755467234350028（‘GDID’）设置的。根据微软代表的说法，Windows生态系统中的全局设备标识符是一个持久的、设备级别的标识符，旨在唯一标识设备上某个Windows操作系统安装……GDID是一个全局唯一标识符，与设备上Windows的安装绑定。GDID在设备上的Windows操作系统更新期间保持不变，但重新安装Windows……将绑定一个新的唯一GDID。”

脚注补充说，一个Microsoft用户可以有多个GDID。宣誓书接着将GDID的IP历史记录和浏览记录（例如empirehotelnyc.com，一个Growtopia/Ubisoft登录URL）与嫌疑人登录的账户关联起来。

这里有两件事支撑了整份报告：

1. 该值是**g:加上一个十进制整数**（g:6755467234350028）。十六进制为0x0018000FC8CB93CC，所以是一个64位数字。
2. 重新安装会产生新的GDID。 因此它不可能仅仅是固定硬件的函数。

2. 驳斥流传的神话

社交媒体上的总结声称GDID是*“一个由安装时的序列号生成的128位标识符”*。两个部分都是错误的：

[!NOTE] 在对CDP进行更多逆向分析后，我提供了一些错误信息。使用本地账户并不能阻止GDID的产生。CDP有一个匿名设备路径，如果未连接Microsoft账户则会采用。阅读时请记住这一点。

3. GDID出现在哪里：Delivery Optimization

[STATIC] 微软公开的Azure Monitor文档在**UCDOStatus**（更新合规 / Delivery Optimization）表中定义了一个GlobalDeviceId列：

GlobalDeviceId（字符串）：“Microsoft全局设备标识符。这是Microsoft内部使用的标识符。”

它与LastCensusSeenTime、ISP、City、Country相邻，因此一个设备ID与地理位置和IP相关联。这是Microsoft在公开文档中命名该值的唯一地方。但Delivery Optimization仅仅报告它。重要的是，它并不拥有这个标识符。向上游追踪，你会落脚于Connected Devices Platform。

4. 谁拥有它：Connected Devices Platform到DDS

[STATIC] C:\Windows\System32\cdp.dll（Connected Devices Platform，服务为CDPSvc + CDPUserSvc）包含GlobalDeviceId符号和一个完整的设备目录服务注册子系统：

ddsregistrationclient.cpp   ddsregistrationmanager.cpp   ddsregistrationinfo.cpp
DdsRegistrationClient   RegisterUserDevicesObserver   DdsRegistrationInfoProviderForCDP
endpoints: dds.microsoft.com  fd.dds.microsoft.com  aad.cs.dds.microsoft.com  cdpcs.access.microsoft.com
device-id format string: "g:%s"

DDS = 设备目录服务，微软的跨设备身份图（Phone Link、云剪贴板、“在电脑上继续”、Nearby Share的后端）。CDP是Windows客户端，负责将安装注册到该图中，并以g:<十进制数>的形式作为键。

4.1 实机捕获

[OBSERVED] 强制进行全新注册（清除CDP本地状态后重启CDPSvc），并捕获CDP自己的ETW提供程序，产生了整个握手过程：

DdsClient::RegisterUserDeviceAsync()   RegistrationReason: Startup   Account Type: MSA
DDSClient: Registration response received. HTTP status code: 200
OnRegisterUserDeviceComplete
GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX

那个deviceid以g:<十进制数>形式写入，与起诉书中的值在结构上匹配：

两者都是位于相同0x0018高字类别（设备PUID命名空间，参见§6）中的64位值。g:前缀只是该整数的十进制形式。

5. CDP如何获取：它消费，而非计算

[STATIC] 借助公共PDB（cdp.pdb），cdp.dll中的设备ID路径仅仅是对身份栈的请求和等待。CDP自身从不计算该标识符：

flowchart TD
    A["GetStableDeviceIdFromProvider<br/>0x0A3140"] --> B["provider.GetStableDeviceIdAsync<br/>(vtable +0x48)"]
    B --> C["OneCoreAccountProvider::<br/>GetStableDeviceIdAsync 0x0C8370"]
    C --> D["IWebAccountBackedAccountProvider<br/>(MSA / AAD identity COM)"]
    D --> E["OnGetStableDeviceIdCompleted<br/>(const char* deviceId) 0x06CEA0"]
    E -->|"assign() string, signal flag"| A

接收它的回调函数显而易见。该ID以字符串形式出现，并且只是被存储：

; OnGetStableDeviceIdCompleted
mov  rbp, r9                 ; r9 = device-id STRING handed in by the identity provider
lea  rcx, [rsi+0xD8]         ; CDP member field
mov  rdx, rbp
call assign@basic_string     ; store it, no computation, no serials
call Set@CdpWaitableFlag      ; unblock the waiter

结论： GDID在CDP之下铸造，位于Windows身份栈底层，作为不透明字符串传递给CDP。这指向了Microsoft账户服务。

6. 铸造者：MSA设备PUID（wlidsvc）

[STATIC] C:\Windows\System32\wlidsvc.dll，Microsoft账户/Passport（Windows Live ID）服务，是唯一包含字面值GlobalDeviceId的身份二进制文件，并且拥有完整的设备注册机制：

CDeviceIdentityBase::CreateNewDeviceIdentity / Provision / BindDeviceToHardware / GetDeviceCert
DeviceAssociateRequest      (Passport PPCRL SOAP -> login.live.com)
<ps:DevicePUID> ... </ps:DevicePUID>
DeviceIdStore::LogToRegistry
BCryptGenRandom / CCryptRandom::GenRandom     (device KEY, not the id)

该标识符是一个设备PUID（Passport唯一标识符），一个64位的MSA标识符。其中的BCryptGenRandom生成的是设备身份验证密钥，由BindDeviceToHardware固定到机器上，而不是 PUID。

6.1 由服务器分配

[STATIC] 客户端从服务器的SOAP响应中提取PUID，使用XPath定位响应体中的元素：

/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped

CAssociateDeviceRequest::ParseResponseBody及相关的ParseResponse方法将响应XML节点读入BSTR。因此流程是：客户端注册设备 -> login.live.com分配并返回设备PUID -> 客户端存储。 这正是为什么重新安装会产生新的GDID（新注册，新服务器分配的PUID），以及为什么它不是硬件哈希。

6.2 以明文持久化存储

[OBSERVED] Microsoft账户身份存储将该值直接保存在注册表中，位于你自己的用户配置单元中：

HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
    LID = 0018XXXXXXXXXXXX

HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}
    DeviceId = 0018XXXXXXXXXXXX

与CDP注册进DDS时的值逐字节相同。你的用户账户PUID是一个不同的数字，存储在其他地方，格式为puid = 0003...（例如00034002XXXXXXXX）。还有一个以PUID命名的HKLM缓存键（HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\<PUID>_<userSID>），但那个只能由SYSTEM访问，因此你从HKCU读取该值。

[!NOTE] 前缀告诉你它是什么。 用户PUID为0003类别，设备PUID为0018类别。法院的GDID（0018000FC8CB93CC）位于0018设备PUID空间中，与我的相同。

6.3 它验证图端点

[OBSERVED] MSA令牌缓存（HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\...）包含范围限定为确切CDP所使用的端点的设备令牌：

scope=service::dds.microsoft.com::MBI_SSL_TOKEN_BROKER
scope=service::activity.windows.com::MBI_SSL_SA_TOKEN_BROKER

因此，Microsoft账户服务发放的设备凭据可以验证DDS注册以及承载GDID的活动上传。

6.4 完整链路

flowchart TD
    subgraph MSA["MSA身份层: wlidsvc.dll"]
        A1["向 login.live.com 注册设备<br/>(Passport PPCRL SOAP)"] --> A2["服务器分配设备PUID<br/>&lt;ps:DevicePUID&gt; / HWPUIDFlipped"]
        A2 --> A3["存储 DeviceId / LID = PUID<br/>HKLM\...\IdentityStore"]
        A3 --> A4["为 dds.microsoft.com 和 activity.windows.com<br/>发放设备令牌"]
    end
    subgraph CDP["设备图客户端: cdp.dll / CDPSvc"]
        B1["GetStableDeviceId -> 接收PUID字符串"] --> B2["RegisterUserDeviceAsync -> DDS<br/>OBSERVED: HTTP 200"]
    end
    subgraph SRV["服务器: 设备目录服务"]
        C1["将 g:PUID 键关联到 MSA 账户，<br/>活动及 IP 历史"]
    end
    subgraph REP["报告层"]
        D1["Delivery Optimization -><br/>UCDOStatus.GlobalDeviceId"]
    end
    A4 --> B1
    B2 --> C1
    C1 --> D1

起诉书中关于“GDID”的一切：每次安装持久、随更新保留、重新安装后变新、绑定Microsoft账户、可跨IP和浏览记录追踪——所有这些都符合它作为一个服务器分配的MSA设备PUID，由CDP注册到设备图中的特征。

7. 查找你自己的GDID

[OBSERVED] 在登录了Microsoft账户的机器上，从你自己的用户配置单元做一个注册表读取，无需管理员权限：

(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

这将给出你的设备PUID，格式为16位十六进制数字（例如0018XXXXXXXXXXXX）。要以服务器端显示的g:<十进制数>形式查看：

$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($hex,16))"

如果你的机器上ExtendedProperties\LID为空，相同的值位于HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}\DeviceId下。

[!WARNING] 不要发布你自己的值。 你的设备PUID、你的MSA CID（0003...）以及你的用户SID都可以匿名识别你。在任何公开报告中都要打码。唯一可以引用的安全值是法院的那个，因为它已经是公开的。

8. 减少暴露

GDID的存在是因为你的设备注册到了Microsoft账户设备图中，并且Connected Devices Platform保持同步。要削弱它：

• 终止Connected Devices Platform（CDPSvc、CDPUserSvc）并关闭活动历史记录（设置，隐私，活动历史记录）以停止图同步和活动上传。
• 删除%LOCALAPPDATA%\ConnectedDevicesPlatform只会擦除本地的CDP状态。PUID会从身份存储中重新出现，所以仅此一步无法解决问题。
• 重新安装会给你一个新的GDID（起诉书如此说），但一旦再次注册，它又会绑定到一个全新的GDID。

9. 方法（可复现）

以上全部来自一台标准的Windows 11（构建26200）机器。

• 实机捕获： 通过logman捕获CDP的TraceLogging ETW提供程序（Microsoft.Windows.CDP.*），同时强制进行全新的CDPSvc注册，并用tracerpt解码。
• 注册表和令牌缓存： IdentityStore和IdentityCRL下的HKLM\SOFTWARE\Microsoft。

ETW和静态分析是实际有效的方法。使用代理只会浪费你的时间。

Microsoft.Windows.CDP.Core                    {7762de0c-b0a6-571a-68d3-c018bf009496}
Microsoft.Windows.CDP.Core.Error              {a1ea5efc-402e-5285-3898-22a5acce1b76}
Microsoft.Windows.CDP.CDS                     {dfa6e32a-095f-5f57-d025-0887d33507a1}
Microsoft.Windows.CDP.Aggr                    {bc1826c8-369c-5b0b-4cd1-3c6ae5bfe2e7}
Microsoft.Windows.CDP.AFS                     {5fe36556-c4cd-509a-8c3e-2a547ea568ae}
Microsoft.Windows.CDP.OnecoreAccountProvider  {4ee5bf9a-3e8f-540b-8bfb-12457a2854b6}
Microsoft.Windows.CDP                          {9f4cc6dc-1bab-5772-0c71-a89954718d66}

[!NOTE] NullZeroX在推特上告诉我，即使设备未登录Microsoft账户，GDID也会被发送。我不确定这个说法的真实性，但值得注意。