Windows GDID に関する完全な解説

Windows GDID に関する完全な解説 Windows GDID（Global Device Identifier）の完全な逆アセンブル。 Microsoftの「Global Device Identifier」が、2026年7月のScattered Spiderの告発で名指しされた永続的なWindowsフィンガープリントが、実際にどのように生成、保存、送信されているか。 TL;DR 以下は真実ですが、情報が一部欠けています。 MSA（Microsoftアカウント）でログインしているかどうかにかかわらず、GDIDは必ず存在します。投稿時には気づきませんでしたが、調査しました。 MSAが接続されていない場合、CDP（Connected Devices Platform）は匿名デバイスパスを使用します。根本的なシステムは事実上正しいですが、いくつかの点が欠けています。 GDIDは実際のテレメトリ項目です。 米国連邦刑事訴状（United States v. Peter Stokes, N.D. Ill., July 2026）でGlobal Device Identifier g:6755467234350028として登場します。 これはMicrosoftアカウントの「Device PUID」です。WindowsのインストールがMicrosoftアカウントに登録された際に割り当てられる64ビットのPassport Unique IDで、デバイスグラフにはg:<10進数>として書き込まれます。 主張は間違っています。「128ビット」でもなく、「シリアル番号から生成される」わけでもありません。 裁判記録自体が、再インストールで新しいGDIDが生成されると述べており、GPUのようなハードウェアシリアルから派生する可能性を排除しています。 スタック（下から上へ）： wlidsvc（Microsoftアカウントサービス）がlogin.live.comを通じてデバイスにプロビジョニングし、デバイスPUIDを取得してレジストリに保存します。 Connected Devices Platform（cdp.dll / CDPSvc）がそれを読み取り、Device Directory Service（DDS）グラフに登録します。 Delivery Optimizationが、文書化されたUCDOStatus.GlobalDeviceIdとして報告します。 すべて、公開シンボルを持つライブのWindows 11（26200）マシンで再現されました。 自身のGDIDを見つけることができます（§7）。 注：信頼性ラベリング。 すべての主張にはタグが付いているため、各自で重み付けできます。 [COURT]：一次情報源の事実 [OBSERVED]：テストマシンでライブ再現 [STATIC]：バイナリと公開Windows PDBから証明 [ASSESSED]：証拠からの強い推論 目次 背景：裁判所が実際に述べたこと 誤った神話の否定 GDIDが現れる場所：Delivery Optimization 所有者は誰か：Connected Devices PlatformからDDSへ CDPはどのようにGDIDを取得するか：消費するのであって計算しない 発行元：MSA Device PUID (wlidsvc) 自身のGDIDを見つける 露出を減らす 方法論（再現可能） 制限と正直な注意点 1. 背景：裁判所が実際に述べたこと 2026年7月1日、DOJ（米国司法省）は、Scattered Spider（別名Octo Tempest / UNC3944 / 0ktapus）の alleged メンバーであるPeter Stokesに対する刑事訴状を公開しました。宣誓供述書は、MicrosoftがFBIにデバイスへのアクティビティを帰属させるのをどのように支援したかを説明しています。 重要 [COURT] superseding complaint（補足訴状）（¶25, p.34）から、 verbatim（逐語）： 「ngrokアカウントはGlobal Device Identifier g:6755467234350028（「GDID」）を通じて設定されました。Microsoftの担当者によると、WindowsエコシステムにおけるGlobal Device Identifierは、デバイス上のWindowsオペレーティングシステムのインストールを一意に識別するために設計された、永続的なデバイスレベルの識別子です... GDIDは、デバイス上のWindowsインストールのインストールに関連付けられた、グローバルに一意な識別子です。GDIDはデバイス上のWindowsオペレーティングシステムのアップデートを通じて一貫性を保ちますが、Windowsの再インストール...は新しい一意のGDIDに関連付けられます。」 脚注には、1人のMicrosoftユーザーが複数のGDIDを持つ可能性があると付け加えられています。 宣誓供述書は、GDIDのIP履歴とブラウジング（例：empirehotelnyc.com、Growtopia/UbisoftログインURL）を、容疑者がログインしていたアカウントと相関させています。 この文書の残りの部分で重要なのは次の2点です。 値はg:に10進整数が続く形式（g:6755467234350028）です。16進数では0x0018000FC8CB93CCであり、64ビットの数値です。 再インストールで新しいGDIDが生成されるため、固定ハードウェアの関数だけではありえません。 2. 誤った神話の否定 ソーシャルメディアの要約では、GDIDは「インストール時にシリアル番号から生成される128ビットの識別子」と主張されていました。両方の部分が誤りです。 | 主張（ソーシャルメディア） | 現実（一次情報源） | |---|---| | 「128ビット」 | 訴状の値はg:6755467234350028であり、64ビット（0x0018000FC8CB93CC）に収まる10進数です。 | | 「インストール時にシリアル番号から生成される」 | 訴状では、再インストールで新しいGDIDが生成されると述べています。固定シリアルから派生した値は、再インストール後も同じになるはずであり、変化しません。 | 注：CDPのさらなるリバースエンジニアリングの後、一部誤った情報を提供しました。ローカルアカウントを使用してもGDIDは防止されません。MSAが接続されていない場合、CDPは匿名デバイスパスを取ります。これを読み進める際に念頭に置いてください。 3. GDIDが現れる場所：Delivery Optimization [STATIC] Microsoftの公開Azure Monitorドキュメントでは、UCDOStatus（Update Compliance / Delivery Optimization）テーブルにGlobalDeviceId列を定義しています。 GlobalDeviceId（string）： 「Microsoftのグローバルデバイス識別子。これはMicrosoftが内部的に使用する識別子です。」 これは、LastCensusSeenTime、ISP、City、Countryのすぐ隣にあり、IPと地理情報と関連付けられたデバイスIDです。これはMicrosoftが公開ドキュメントでその値を名付けている唯一の場所です。しかし、Delivery Optimizationはそれを報告するだけで、所有はしていません。これを上流にたどると、Connected Devices Platformにたどり着きます。 4. 所有者は誰か：Connected Devices PlatformからDDSへ [STATIC] C:\Windows\System32\cdp.dll（Connected Devices Platform、サービスCDPSvc + CDPUserSvc）には、GlobalDeviceIdシンボルと、Device Directory Service登録サブシステム全体が含まれています。 ddsregistrationclient.cpp ddsregistrationmanager.cpp ddsregistrationinfo.cpp DdsRegistrationClient RegisterUserDevicesObserver DdsRegistrationInfoProviderForCDP エンドポイント： dds.microsoft.com fd.dds.microsoft.com aad.cs.dds.microsoft.com cdpcs.access.microsoft.com デバイスIDのフォーマット文字列：「g:%s」 DDSはDevice Directory Serviceであり、MicrosoftのクロスデバイスIDグラフ（Phone Link、クラウドクリップボード、「PCで続ける」、Nearby Shareのバックエンド）です。CDPは、このグラフにインストールを登録するWindowsクライアントであり、そこでg:<10進数>としてキーが付けられます。 4.1 ライブキャプチャ [OBSERVED] 新しい登録を強制し（CDPSvcをローカル状態をクリアして再起動）、CDP自身のETWプロバイダーをキャプチャすると、ハンドシェイク全体が生成されました。 DdsClient::RegisterUserDeviceAsync() RegistrationReason: Startup Account Type: MSA DDSClient: Registration response received. HTTP status code: 200 OnRegisterUserDeviceComplete GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX このdeviceidは、g:<10進数>として書き込まれ、構造的に訴状の値と一致します。 | 値 | 16進数（64ビット） | クラスプレフィックス | |---|---|---| | 私のマシン（編集済） | g:XXXXXXXXXXXXXXXX | 0x0018XXXXXXXXXXXX | | 裁判記録の証拠 | g:6755467234350028 | 0x0018000FC8CB93CC | どちらも同じ0x0018上位ワードクラス（§6で説明するデバイスPUIDの名前空間）の64ビット値です。g:プレフィックスは単にその整数を10進数で表したものです。 5. CDPはどのようにGDIDを取得するか：消費するのであって計算しない [STATIC] 公開PDB（cdp.pdb）を使用すると、cdp.dll内のデバイスIDパスは、IDスタックに対する単なるリクエストと待機です。CDP自体はIDを計算しません。 フローチャート 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 IDスタック内で発行され、不透明な文字列としてCDPに渡されます。これはMicrosoftアカウントサービスを示唆しています。 6. 発行元：MSA Device PUID (wlidsvc) [STATIC] C:\Windows\System32\wlidsvc.dll、Microsoftアカウント/Passport（Windows Live ID）サービスは、リテラルのGlobalDeviceIdを含む唯一のIDバイナリであり、それは