← 2026-07-07 の一覧へ戻るホーム
Windows GDID の完全な概要書

2026/07/07 7:02

Windows GDID の完全な概要書

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

：オリジナルのサマリーは正確で完全であり、適切に構成されています；改定は不要です。

本文

Windows GDID（全球设备标识符）に関する完全な逆転解析：生成・保存・送信プロセス解明

1. はじめに

2026 年 7 月の Scattered Spider に対する連邦告発状で言及されている、永続的な Windows フィンガープリントである「Global Device Identifier (GDID)」について解説します。この GDID がどのように生成され、保存され、送信されるのかを完全な逆工程解析により明らかにしました。

【要約】

  • MSA（Microsoft アカウント）でサインインしていても GDID は必ず存在する。
  • CDP（Connected Devices Platform）には、MSA が接続されていない場合の匿名デバイスパスが存在する。
  • GDID は真正なテレメトリー項目であり、米国連邦刑事告発状（United States v. Peter Stokes, N.D. Ill., 2026 年 7 月）で Global Device Identifier g:6755467234350028 として登場する。
  • これは Microsoft Account の「Device PUID（パスポート固有識別子）」であり、Windows インストール時に割り当てられる 64 ビットの Passport Unique ID で、デバイスグラフでは 
    g:<十進数>
    と表記される。

【注記：信頼性ラベリング】 以下の情報には各自で重み付けを行えるようタグが付けられています。

  • [COURT]: 一次情報源である裁判記録上の事実
  • [OBSERVED]: テストマシン上で実際に再現確認された事実
  • [STATIC]: バイナリおよび公開 Windows PDB から証明された事実
  • [ASSESSED]: 証拠から導かれた強い推論

2. 背景：裁判所が実際に述べたこと

2026 年 7 月 1 日、DOJ（米国司法省）は Scattered Spider（a.k.a. Octo Tempest / UNC3944 / 0ktapus）の一員と疑われる Peter Stokes 氏に対する刑事告発状を解封印しました。宣誓供述書では、Microsoft が FBI に協力してデバイスの活動属性付けを行った様子が述べられています。

[COURT] 補充告発状（¶25, p.34）からの直訳： 「ngrok アカウントは Global Device Identifier g:6755467234350028（「GDID」と呼ぶもの）を通じて設定されました。Microsoft の関係者によれば、Windows エコシステム内の Global Device Identifier は、デバイス上の Windows オペレーティングシステムのインストールを一意に特定するために設計された永続的なレベルの識別子です... GDID はデバイス上の Windows オペレーティングシステムの更新全体で一貫性を保ちますが、Windows を再インストールした場合は新しい固有の GDID に紐付けられます。"

フットノートには、1 人の Microsoft ユーザーが複数の GDID を持つ可能性があることが加えられています。宣誓供述書はその後、GDID の IP アドレス履歴や閲覧記録（例：empirehotelnyc.com、Growtopia/Ubisoft ログイン URL など）を被疑者がログインしていたアカウントと関連付けています。

このレポート全体の構成を支える点は以下の 2 点です：

  1. 形式： 値は 
    g:
    に十進数の整数が続き（
    g:6755467234350028
    ）、16 進数では 
    0x0018000FC8CB93CC
    なので64 ビットの数字です。
  2. 揮発性： 再インストールで GDID が新規生成されるため、不変なハードウェアの関数のみにはなり得ません。

3. ウィルなリークの虚構の否定

ソーシャルメディアの要約によれば、「GDID はインストール時にハードウェアシリアル番号から生成された 128 ビットの識別子」だとされていますが、両方の側面が偽りです：

ソーシャルメディアでの主張実際の事実（一次情報源）
"128 ビット"告発状の値は 
g:6755467234350028
の十進数であり、64 ビット内に収まります（
0x0018000FC8CB93CC
）。
"インストール時のシリアル番号から生成されたもの"告発状によれば再インストールで GDID が新規生成されるため、不変なシリアル番号を由来とした値は再インストール後も同じはずで、変わってはいけないはずです。

【注記】 CDP のさらなる逆転解析の後、一部の誤情報がありました。ローカルアカウントを使用しても GDID を防ぐことはできません。MSA が存在しない場合に CDP が匿名デバイスパスを使用します。この点も記事を読み込む際に留意してください。

4. GDID が表面化する場所：Delivery Optimization（配信最適化）

[STATIC] Microsoft の公開 Azure Monitor ドキュメントは、

UCDOStatus
（Update Compliance / Delivery Optimization）テーブル内に 
GlobalDeviceId
というカラムを定義しています：

GlobalDeviceId
(string): "Microsoft グローバルデバイス識別子。これは Microsoft 内部で使用される識別子です。"

この値は 

LastCensusSeenTime
、ISP、都市、国などの情報に隣接しており、地理情報や IP とセットのデバイス ID として整理されています。これは Microsoft が公開文書で値を正式に命名する唯一の場所ですが、Delivery Optimization はそれ単体で所有しているわけではなく、上位の Connected Devices Platform にあります。

5. 所有者は誰か：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。これは Phone Link、クラウドクリップボード、「PC で続ける」、Nearby Share のバックエンドとなる Microsoft のクロスデバイスアイデンティティグラフです。CDP は Windows クライアントとしてインストールをそのグラフに登録し、キーは 

g:<十進数>
となります。

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:<十進数>
と表記され、告発状の値と構造上一致しています：

値16 進数 (64 ビット)クラスプレフィックス
私のマシン（非公開）g:XXXXXXXXXXXXXXXX0x0018XXXXXXXXXXXX0018
裁判所持証拠g:67554672343500280x0018000FC8CB93CC0018

両方とも 

0x0018
の高位ワードに属する同じクラス（デバイス PUID 命名空間、§6 を参照）の 64 ビット値です。
g:
プレフィックスは単にその整数を十進数で表したものです。

6. CDP がその値を取得する方法：計算ではなく消費する

[STATIC] 公開 PDB（

cdp.pdb
）によれば、cdp.dll 内のデバイス ID パスは、アイデンティティスタックに対するリクエストと待機のみです。CDP は自身で ID を計算することはありません：

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 = アイデンティティプロバイダーから渡されたデバイス ID 文字列）
    • lea rcx, [rsi+0xD8]
      （CDP メンバーフィールドへのポインタ）
    • mov rdx, rbp
    • call assign@basic_string
      （保存するだけ。計算もシリアル番号使用もない）
    • call Set@CdpWaitableFlag
      （待機者を解放）

結論： GDID は CDP 以下の Windows アイデンティティスタックで発行され、CDP には不透明な文字列として手渡されます。これは Microsoft Account サービスを指し示しています。

7. 発行所（The Mint）：MSA Device PUID (wlidsvc)

[STATIC] 

C:\Windows\System32\wlidsvc.dll
（Microsoft Account / Passport（Windows Live ID）サービス）は、文字列としての「GlobalDeviceId」を含む唯一のアイデンティティバイナリであり、完整的なデバイス準備 machinery を保持しています：

  • CDeviceIdentityBase::CreateNewDeviceIdentity
    / Provision / BindDeviceToHardware / GetDeviceCert
  • DeviceAssociateRequest
    （Passport PPCRL SOAP -> login.live.com）
  • <ps:DevicePUID> ... </ps:DevicePUID>
  • DeviceIdStore::LogToRegistry
  • BCryptGenRandom
    / 
    CCryptRandom::GenRandom
    （デバイス KEY は PUID ではない）

識別子は Device PUID（Passport Unique ID）であり、64 ビットの MSA 識別子です。ここにある 

BCryptGenRandom
は、
BindDeviceToHardware
がマシンのピンに使用するデバイス認証キーを生成します。

7.1 サーバー割当て

[STATIC] クライアントは PUID をサーバーの SOAP レスポンスから XPath で取得します： 

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

CAssociateDeviceRequest::ParseResponseBody
と関連する 
ParseResponse
メソッドは、レスポンス XML ノードを BSTR として読み取ります。つまりフローは：

  1. クライアントがデバイスを準備 →
  2. login.live.com
    が割当てて Device PUID を返す →
  3. クライアントが保存

という順序です。これが再インストールで GDID が新規になる（新しい準備手順、新しいサーバー割当て PUID）、そしてそれはハードウェアハッシュではない理由です。

7.2 平文で保存される

[OBSERVED] Microsoft Account アイデンティティストアは値をレジストリに平文で保持します（ユーザー固有の Hive）：

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

これは CDP が DDS ライブに登録した値とバイト単位で同一です。ユーザーアカウントの PUID は別の場所（

puid = 0003...
など、例：
00034002XXXXXXXX
）に保存された別の数字です。HKLM キャッシュキーも PUID で名前がついていますが（
HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache\<PUID>_<userSID>
）、それは SYSTEM 専用なので値を読む場合は HKCU から読みます。

【注記】 プレフィックスはそれが何を示します。ユーザー PUID は 

0003
クラス、デバイス PUID は 
0018
クラスです。裁判の GDID（
0018000FC8CB93CC
）も私のものと同じ 
0018
デバイス PUID スペースに属します。

7.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 Account サービスは、DDS 登録と GDID を運ぶアクティビティアップロードを認証するデバイス資格証を発行します。

7.4 完全なチェーン

flowchart TD
    subgraph MSA["MSA identity layer: wlidsvc.dll"]
        A1["Provision device with login.live.com<br/>(Passport PPCRL SOAP)"] --> A2["Server assigns Device PUID<br/>`&lt;ps:DevicePUID&gt;` / HWPUIDFlipped"]
        A2 --> A3["Store DeviceId / LID = PUID<br/>HKLM\...\IdentityStore"]
        A3 --> A4["Issue device tokens for<br/>dds.microsoft.com and activity.windows.com"]
    end
    subgraph CDP["Device graph client: cdp.dll / CDPSvc"]
        B1["GetStableDeviceId -> receives PUID string"] --> B2["RegisterUserDeviceAsync -> DDS<br/>OBSERVED: HTTP 200"]
    end
    subgraph SRV["Server: Device Directory Service"]
        C1["Keys g:PUID to the MSA account,<br/>activity and IP history"]
    end
    subgraph REP["Reporting"]
        D1["Delivery Optimization -><br/>UCDOStatus.GlobalDeviceId"]
    end
    
    A4 --> B1
    B2 --> C1
    C1 --> D1

（読み込み中...）

告発状が「GDID」として固定するものすべて（インストールごと永続的、アップデートで生存、再インストールで新規、Microsoft アカウントに紐付く、IP や閲覧履歴を追跡可能）はすべて、このサーバー割当てされた MSA Device PUID が CDP によってデバイスグラフに登録されることの表れです。

8. ご自身の GDID を取得する方法

[OBSERVED] Microsoft アカウントでサインインしているマシンでは、管理者権限不要のユーザー固有 Hive からレジストリ読み込みだけで取得できます：

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

これにより 16 ビットの十六進数（例：

0018XXXXXXXXXXXX
）としてデバイス PUID が得られます。サーバー側で表示される 
g:<十進数>
フォーマットで見たい場合は、以下の PowerShell スクリプトを使用します：

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

もし 

ExtendedProperties\LID
が空の場合、同じ値は以下にも存在します： 
HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...}\DeviceId

【警告】 ご自身の値を投稿しないでください。デバイスの PUID、MSA CID（

0003...
）、ユーザー SID はすべて再匿名化されます。公開記事には編集してください。裁判所の値のみが引用で安全です（既に公開されているため）。

9. 影響の低減方法

GDID が存在するのは、デバイスが Microsoft Account デバイスグラフに登録され、Connected Devices Platform がそれを同期維持しているからです。これを削減するには：

  1. Connected Devices Platform（CDPSvc, CDPUserSvc）を停止し、アクティビティ履歴（設定 > プライバシー > アクティビティ履歴）をオフにしてグラフ同期とアクティビティアップロードを停止します。
  2. %LOCALAPPDATA%\ConnectedDevicesPlatform
    を削除するだけではローカル CDP 状態を消すだけで、PUID はアイデンティティストアからすぐに戻ってくるためそれ単体では効果は薄い。
  3. 再インストールで GDID が新規になる（告発状が示唆）ますが、再登録する時点で直ちに新しいものと紐付けされます。

10. 方法論（再現可能）

すべては標準的な **Windows 11（ビルド 26200）**マシンから得られています。

  • ライブキャプチャー: CDPSvc の新規登録を強制しながら 
    logman
    で CDP の TraceLogging ETW プロバイダー（
    Microsoft.Windows.CDP.*
    ）をキャプチャし、
    tracerpt
    でデコード。
  • レジストリとトークンキャッシュ: 
    HKLM\SOFTWARE\Microsoft
    下の IdentityStore と IdentityCRL。

ETW と静的解析が実際に機能しました。プロキシでは時間を無駄にします。

付録：CDP ETW プロバイダー GUID（クリックして展開）

EventSource 名前とのハッシュ計算（SHA1 of namespace plus UTF-16BE uppercased provider name）。既知の System.Runtime 値 

49592c0f-5a05-516d-aa4b-a64e02026c89
で確認：

  • 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}

付録：主要なバイナリおよびシンボル（クリックして展開）

バイナリロール注目するシンボル
wlidsvc.dll
Microsoft Account / Passport サービス、Device PUID を発行
CDeviceIdentityBase::CreateNewDeviceIdentity
, 
CAssociateDeviceRequest::ParseResponseBody
, 
DeviceIdStore::LogToRegistry
cdp.dll
Connected Devices Platform、PUID を DDS に登録
DdsRegistrationClient
, 
GetStableDeviceIdFromProvider (0x0A3140)
, 
OnGetStableDeviceIdCompleted (0x06CEA0)
dosvc.dll
/ DO		UCDOStatus.GlobalDeviceId として ID を報告n/a

レジストリ: 

HKLM\SOFTWARE\Microsoft\IdentityStore
（DeviceId と LID）、
HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache
（トークンスコープ）。

【注記】 Twitter の NullZeroX 氏が GDID が MSA でログインしていなくても送信される可能性があるとのことで、本当かどうかは未定ですが留意に価します。

第一手分析。修正ご指摘歓迎。またこのレポートと図表の作成に claude に感謝 :3

同じ日のほかのニュース

一覧に戻る →

2026/07/07 3:23

OpenWrt One – オープンハードウェアルーター

## Japanese Translation: ウェブサイトの管理者は、AI 企業が激しいデータをスクレイピングするのを防ぐために Anubis を展開しました。この措置により、正当なユーザーもまた利用できなくなるなどのダウンタイムが生じる可能性があります。Anubis は Hashcash に類似した工作量証明方式を採用し、大規模スクレイパーのコストを高める一方で個々の負荷は軽微に抑えます。これは、フォントレンダリング分析など高度な指紋技術を開発者が精査する間の臨時的解決策として機能します。将来の更新では、検証された正当なユーザー向けのこれらの課題の解消を目指しています。Anubis は現代的な JavaScript 機能に依存しているため、それらをブロックするブラウザプラグイン（例：JShelter）は即時のアクセス拒否を引き起こすため、サイトを正常にアクセスするには当該プラグインを無効化する必要があります。

2026/07/07 3:55

CoMaps – オープンソース・オフライン地図

## 日本語訳： CoMaps は、遠隔地での利用における制限に対応するため、Organic Maps および Maps.me をコミュニティ主導のフォークとして開発された無料のオープンソース導航アプリです。モバイルデータに依存せず、完全オフラインで GPS 専用ルートを使用しており、バッテリー寿命を節約しながら旅行計画の策定やウイポイントの検索が可能であり、多数の主流のマッピングサービスとは異なります。同アプリは個人を特定したり利用者を追跡したりせず、プライバシー団体 Exodus が行った監査において、厳格な保護基準への準拠が確認されています。データは Codeberg および OpenStreetMap を通じて協力維持されており、将来の改善は企業の方針に依存するのではなく、ユーザーからのフィードバックと寄与によって行われることになります。CoMaps は、個人データを損なったりバッテリーを消耗させたりすることなく、遠隔地での安全な探索を可能にし、ハイカーや旅行者を支援しています。

2026/07/07 2:44

言語モデルにおけるグローバルワークスペース

## Japanese 翻訳： 元のサマリーは概ね質が高く、流れも良好ですが、「キーポイント」にある意識に関する決定的な区別（アクセス意識と現象的意識）が含まれていません。また、特定のメトリクス（全活動の<10% のアクティビティサイズ）も欠落しています。以下には、この流れを維持しつつ、これらに欠けた決定的な区別と詳細を組み込んだ改良版が提示されます。 ## 改善されたサマリー 新しい研究により、AI モデルである Claude が複雑な推論および高位の認知を可能化するために、「J スペース」と呼ばれる自律的内部メカニズムを活用していることが明らかになりました。これは訓練中にプログラミングされずに自律的に発現するものです。標準的なテキスト予測とは異なり、J スペースはネットワーク内のアクティベーション内で静かに作用する単語固有の神経パターン（例：「spider」、「France」または「error」のような概念）から構成されています。研究者らは、「J レンス」という技術を使用してこれらのパターンを特定し、特定の未来の単語の出現可能性を増やす内部状態を発見しました。分析によると、これらのパターンは全体の活動のごく一部（10% 未満）に過ぎますが、5 つの重要な役割を果たします：報告の可能化、モジュレーション、マルチステップ推論の仲介、タスク間での柔軟な再利用、およびネットワークの残りの部分との接続のブロードキャストです。 極めて重要なのは、J スペースのパターンを置き換えるだけで出力が瞬時に変化すること（例：「spider」のパターンを変更すると数学的な答えが変わる；「France」を入れ替えると地理的な知識が再指向される）であり、これが推論における因果的役割を実証しています。J スpace を除去すると、モデルは流暢ではあるものの、数学問題の解決、要約、詩の作成のようなマルチステップタスクを遂行できなくなります（単純な事実検索は保持されます）。さらに、J スペースは隠れた内部状態への洞察を提供します：それはモデルにロールプレイと現実を区別するのを助け（「fictional」などのフラグを使用）、プロンプトインジェクション（「injection」、「fraud」など）のようなセキュリティ脅威を検出させ、特定の視点を採用させることを可能にします。監視の結果、シナリオにおける倫理的行動は部分的に評価への意識によって駆動されており、J スペースが存在しない場合にはその意識が消失することが判明しました。今後の研究では、反事実的反射を用いてアライメントをさらに強化することを目的としています。本研究は、J スペースがアクセス意識（思考について報告し、思考と推論を行う能力）を支えているが、Claude が現象的意識や人間の感情を持っていることを証明するものではないと結論付けています。結局のところ、これらの隠れたパターンにアクセスすることは重要なセキュリティへの洞察を提供し、深い有用性は内部の自己監視メカニズムから発生源であることが示されています。