GDID: скрытый идентификатор Windows, который Microsoft использует для отслеживания устройств

GDID в Windows: внутреннее устройство, способы получения и почему подмена практически бесполезна​

Кратко (TL;DR)​

GDID представляет собой 64-битный идентификатор устройства (PUID), который хранится в реестре Windows в открытом виде как строковое значение (REG_SZ) в профиле пользователя. Его можно прочитать или даже изменить локально, однако реальная привязка устройства выполняется на серверах Microsoft с использованием аппаратных идентификаторов и сертификата устройства, защищенного TPM.

В этой статье мы разберем внутреннее устройство GDID, рассмотрим исходный код соответствующих компонентов и проверим, можно ли извлечь этот идентификатор из системы, а также заменить его другим.

Если вас интересует только исходный код, ссылка на репозиторий приведена в оригинальной публикации.

Цель статьи — разобраться в механизме работы GDID, научиться получать его из системы и проверить, возможно ли подменить его другим идентификатором.

Основы GDID​

Каждая установленная копия Windows получает собственный 64-битный идентификатор — GDID (Global Device Identifier).

При первом подключении компьютера к Интернету Windows обращается к login.live.com, получает этот идентификатор и сохраняет его в реестре в виде шестнадцатеричной строки из 16 символов, например:

0018AAAABBBBCCCC

Во внутреннем формате Microsoft этот идентификатор записывается как десятичное число с префиксом g::
g:6943049711865036
Именно такой формат используется внутри инфраструктуры Microsoft, а также фигурирует в судебных материалах.

Во внутреннем коде Microsoft данный идентификатор называется PUID (Passport Unique Identifier). Название сохранилось еще со времен сервиса .NET Passport, который впоследствии превратился в Microsoft Account.

Даже сегодня в документации .NET можно встретить класс PassportIdentity.HexPUID.

Фактически GDID — это публичное название PUID устройства, присутствующего во всех пользовательских версиях Windows начиная с Windows Vista.

Что означают первые байты​

Первые два байта определяют тип идентификатора.

• 0x0018 — идентификатор устройства.
• 0x0003 — идентификатор учетной записи пользователя.

Таким образом:

каждая установка Windows получает собственный GDID устройства;

• каждая учетная запись Microsoft, вошедшая в систему, получает собственный пользовательский PUID.

После переустановки Windows устройство получает новый локальный номер, однако серверы Microsoft по-прежнему способны определить, что речь идет о том же самом физическом компьютере, поскольку аппаратная конфигурация остается прежней.

Где хранится GDID?​

Registry output showing the LID value.

Основная копия идентификатора хранится в открытом виде.

Никакого шифрования.

Никакого DPAPI.

Никаких прав администратора.

Получить значение можно обычной командой:

reg query "HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties"

Результат:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
LID    REG_SZ    0018AAAABBBBCCCC

Как видно, это обычная строка (REG_SZ) длиной 16 шестнадцатеричных символов, расположенная в пользовательском разделе реестра (HKCU).

Любой процесс, работающий от имени данного пользователя, способен прочитать это значение.

Именно LID представляет собой PUID устройства в шестнадцатеричном виде.

На этой информации основаны:

• лицензирование Microsoft Store;
• активация Windows;
• Connected Devices Platform;
• Windows Notification Service (WNS);
• телеметрия и ряд других сервисов Microsoft.

Однако все они используют не только сам номер, но и соответствующий сертификат устройства.

DeviceTicket​

Второе место хранения значительно важнее.
HKCU\...\Immersive\production\Token\{AppContainerSID}\DeviceTicket
Здесь располагается защищенный DPAPI двоичный объект (REG_BINARY).

Внутри него содержится сертификат устройства X.509, которым wlidsvc подтверждает свою подлинность перед серверами Microsoft.

В этот сертификат встроен тот же самый PUID.

NegativeCache​

Третье место хранения:
HKLM\...\IdentityCRL\NegativeCache\<UserPUID>_<UserSID>
Названия подразделов связывают пользовательские PUID с локальными SID.

При проведении криминалистического анализа многопользовательской системы именно здесь можно определить соответствие между учетными записями Microsoft и локальными пользователями.

Кто управляет GDID?​

Вся логика реализована службой Microsoft Account Sign-in Assistant (wlidsvc), работающей из библиотеки:
C:\Windows\System32\wlidsvc.dll
Если извлечь строковые ресурсы из DLL, можно увидеть практически всю внутреннюю архитектуру:

DeviceIdStore::LoadFromRegistry
DeviceIdStore::GetRegistryPath
DeviceIdStore::LogToRegistry
CDeviceIdentityBase::CreateNewDeviceIdentity
CDeviceIdentityBase::BindDeviceToHardware
CDeviceIdentityBase::GetDeviceCert
CAssociateDeviceRequest::ParseResponseBody

Интересно, что в бинарном файле даже сохранился исходный путь проекта Microsoft:

onecoreuap\ds\ext\live\identity\ntservice\lib\svccommon\deviceidstore.cpp

wlidsvc.dll string table with device identity functions.

Отдельно стоит отметить, что многие из этих функций впервые были подробно описаны в исследовании SmtimesIWndr/gdid-reversal на GitHub.

Как Microsoft выдает GDID​

При первом подключении новой установки Windows к Интернету служба wlidsvc отправляет POST-запрос на:
https://login.live.com/ppsecure/deviceaddcredential.srf
Запрос представляет собой SOAP-сообщение, содержащее блок <DeviceInfo> с аппаратными характеристиками устройства.

Используются следующие дескрипторы.

Тег	Описание
4097, 4098	Производитель системы
4099	Модель устройства
4100	Версия
4101	Серийный номер SMBIOS
4102	UUID SMBIOS
4112, 4113	Серийные номера дисков
4128	MAC-адрес
4130	Имя сетевого адаптера
4144	Неизвестное 32-байтовое значение (предположительно SHA-256 или отпечаток сертификата)
8195–8197	Пока не документированные значения

Дополнительно отправляется открытый ключ TPM.

После обработки сервер Microsoft отвечает SOAP-сообщением вида:

<DeviceAddResponse Success="true">
    <success>true</success>
    <puid>0018XXXXXXXXXXXX</puid>
    <DeviceTpmKeyState>0</DeviceTpmKeyState>
    <License>...</License>
    ...
</DeviceAddResponse>

Именно элемент <puid> становится GDID устройства.

wlidsvc получает его через функцию:
CAssociateDeviceRequest:arseResponseBody
после чего вызывает
DeviceIdStore::LogToRegistry
и сохраняет значение в:
HKCU\...\IdentityCRL\ExtendedProperties\LID
После этого оно остается неизменным на протяжении всей жизни данной установки Windows.

Важно понимать, что клиент не вычисляет этот идентификатор самостоятельно.

Его назначает исключительно сервер Microsoft.

Именно сервер определяет, относится ли новый набор аппаратных характеристик к уже известному устройству.

Поэтому одинаковое оборудование будет распознаваться как одно и то же физическое устройство независимо от количества переустановок Windows.

Как Microsoft использует GDID​

После получения PUID и сертификата устройства эта пара начинает использоваться практически всеми сервисами Microsoft.

В частности:

• Microsoft Store — покупки, лицензии и установка приложений.
• Windows Activation — цифровая лицензия устройства.
• Connected Devices Platform — Your Phone, синхронизация буфера обмена и другие функции.
• Windows Notification Service — идентификатор включается в URI push-каналов.
• Delivery Optimization — используется как UCDOStatus.GlobalDeviceId.
• Телеметрия Windows — поле Device.ID присутствует практически во всех событиях Microsoft.Windows.*.
• Microsoft Edge — при включенной расширенной диагностике история посещений может отправляться вместе с GDID.

Именно использование GDID в телеметрии Microsoft фигурировало в материалах дела United States v. Peter Stokes (июль 2026 года), где Microsoft охарактеризовала GDID как постоянный идентификатор уровня устройства, предназначенный для уникальной идентификации конкретной установки Windows.

Получение собственного GDID​

Output

Репозиторий содержит три реализации одной и той же утилиты:

• get_gdid.exe (C);
• gdid.exe (Rust);
• BOF-версии для Cobalt Strike.

Все они выполняют одинаковую задачу.

Пример вывода:

gdid.exe
Утилита отображает:

[+] Windows GDID + hardware descriptor report
    wlidsvc.dll -> HKCU IdentityCRL\ExtendedProperties\LID

[*] Passport Unique ID  (HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID)
    LID (hex)            : 0018AAAABBBBCCCC
    PUID (dec)           : 6943049711865036
    Namespace            : 0x0018 (device PUID)
    GDID                 : g:6943049711865036

[*] Neighbouring identifiers
    MachineGuid                  : 12345678-1234-1234-1234-123456789abc
    SQM MachineId                : {12345678-1234-1234-1234-123456789ABC}
    IDCRL version                : 8.0.26100.8521
    Login URL                    : https://login.live.com
    Device DNS suffix            : .devicedns.live.com

[*] User PUIDs  (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache)
    0003DEADBEEF1234  dec=1089262744179252  sid=S-1-5-21-1111111111-2222222222-3333333333-1001

[*] SMBIOS  (GetSystemFirmwareTable 'RSMB')
    SMBIOS version       : 3.5
    Manufacturer  (4097) : <Your PC Manufacturer>
    Product       (4099) : <Your PC Model>
    Version       (4100) : 1.0
    Serial number (4101) : SN0123456789ABC
    UUID          (4102) : ABCDEF01-2345-6789-ABCD-EF0123456789
    SKU                  :
    Family               : <Your PC Family>

[*] TPM Endorsement Key  (Microsoft Platform Crypto Provider)
    EKPub blob size      : 283 bytes
    EKPub SHA-256        : deadbeefcafefeeddeadbeefcafefeeddeadbeefcafefeeddeadbeefcafefeed

[*] Physical disks  (IOCTL_STORAGE_QUERY_PROPERTY)
    PhysicalDrive0  serial=EXAMPLE_NVME_SERIAL_1234   model=<Sample NVMe SSD>
    PhysicalDrive1  serial=EXAMPLE_SATA_SERIAL_5678   model=<Sample SATA SSD>

[*] MAC addresses  (GetAdaptersAddresses)
    eth    00:00:5E:00:53:11  Ethernet
    wifi   00:00:5E:00:53:22  Wi-Fi

Для работы не требуются права администратора.

Используются исключительно стандартные API Windows.

Если нужен только GDID, достаточно трех строк PowerShell:

$lid  = (Get-ItemProperty -Path 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties' -Name LID).LID
$puid = [Convert]::ToUInt64($lid, 16)
"LID  : $lid"
"PUID : $puid"
"GDID : g:$puid"

Можно ли помешать отслеживанию?​

Что сделать	Последствия	Помогает?
Отключить wlidsvc	Магазин, активация, UWP, CDP и WNS перестанут работать	Да, пока не выполнен вход в Microsoft Account
Заблокировать login.live.com	Аналогично	Да
Удалить LID и перезапустить службу	Практически ничего	Нет
Переустановить Windows	Чистая установка	Нет
Полностью заменить оборудование	Дорого	Да

Локальный номер можно менять сколько угодно.

Однако после первого обращения wlidsvc к серверам Microsoft устройство снова связывается с тем же аппаратным профилем.

По мнению автора исследования, наиболее практичный вариант — использовать Windows внутри виртуальной машины.

Можно ли подменить чужой GDID?​

Наиболее интересной частью исследования стала проверка различных способов подмены идентификатора.

Архитектура Microsoft состоит из четырех уровней:

1. LID в реестре.
2. Сертификат устройства.
3. Аппаратные идентификаторы.
4. Серверная база соответствий Microsoft.

Были протестированы четыре сценария.

Попытка №1. Подмена только LID​

Утилита gdid-patch.exe позволяет заменить значение LID в реестре.

C:\tools> gdid.exe

[*] Passport Unique ID  (HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID)
    LID (hex)            : 0018AAAABBBBCCCC
    PUID (dec)           : 6943049711865036
    GDID                 : g:6943049711865036

После копирования значения с одной машины на другую локальные инструменты действительно начинают показывать новый GDID. Однако сертификат устройства остается прежним.
При следующем соединении с серверами Microsoft обнаруживается несоответствие, после чего wlidsvc автоматически восстанавливает исходное значение.

C:\tools> gdid.exe

[*] Passport Unique ID  (HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID)
    LID (hex)            : 0018AAAABBBBCCCC
    PUID (dec)           : 6943049711865036
    GDID                 : g:6943049711865036

Результат:

Работает только локально и самостоятельно отменяется через несколько минут.

Попытка №2. Перенос сертификата устройства​

Следующий шаг — перенести не только LID, но и сертификат DeviceTicket.

После импорта сертификата локально все выглядит корректно.

Однако при следующей аутентификации Microsoft сравнивает аппаратные характеристики устройства с теми, которым принадлежал сертификат.

Несовпадение приводит к выдаче нового PUID.

Результат:

Работает только до первого обращения к серверам Microsoft.

Попытка №3. Подмена оборудования виртуальной машины​

Далее автор попытался подделать:

• UUID SMBIOS;
• производителя;
• модель;
• серийные номера;
• MAC-адреса;
• дисковые идентификаторы.

Все это сравнительно легко реализуется средствами гипервизора.

Однако остается TPM.

Закрытый Endorsement Key никогда не покидает физический чип TPM.

Поэтому сервер Microsoft способен проверить, что устройство действительно владеет соответствующим закрытым ключом.

Без полноценной ретрансляции запросов к физическому TPM этот этап преодолеть невозможно.

Именно TPM становится главным криптографическим препятствием.

Попытка №4. Полная очистка IdentityCRL​

Последний эксперимент:

Stop-Service wlidsvc
Remove-Item 'HKCU:\SOFTWARE\Microsoft\IdentityCRL' -Recurse -Force
Remove-Item 'HKLM:\SOFTWARE\Microsoft\IdentityCRL' -Recurse -Force
Start-Service wlidsvc

После повторной регистрации Windows получает новый PUID.

Однако сервер Microsoft снова связывает его с тем же самым физическим устройством.

Итоги экспериментов​

Попытка	Что изменяется	Работает локально	Проходит проверку Microsoft
Только LID	Уровень 1	Несколько минут	Нет
Сертификат	Уровни 1–2	До первого подключения	Нет
Сертификат + подмена оборудования	Частично уровни 1–3	Да	Неизвестно (TPM остается препятствием)
Полная повторная регистрация	Новые уровни 1–2	Да	Нет — сервер связывает устройство повторно

Главная проблема заключается в четвертом уровне.

Источником истины является серверная база Microsoft.

Все данные, находящиеся на компьютере пользователя, представляют собой лишь локальный кэш.

Заключение​

Наиболее необычная особенность GDID заключается не в самом существовании подобного идентификатора — аналогичные механизмы есть практически у всех современных операционных систем.
Гораздо интереснее то, насколько открыто Microsoft хранит его локальную копию.
Это всего лишь строка из шестнадцати шестнадцатеричных символов в разделе HKCU, доступная для чтения любому пользовательскому процессу без повышения привилегий.
Уже более десяти лет этот идентификатор сопровождает практически все взаимодействия Windows с инфраструктурой Microsoft — от телеметрии и активации до Microsoft Store и push-уведомлений.

Получить собственный GDID можно за несколько секунд с помощью gdid.exe.
Столь же быстро его можно изменить при помощи gdid-patch.exe.
Однако это никак не влияет на информацию, которой располагает Microsoft, поскольку реальные сведения об устройстве хранятся не в реестре Windows, а на серверах компании.

И последнее.

Настоящий GDID не стоит публиковать в открытом доступе. Это постоянный идентификатор устройства, который Microsoft способна предоставить правоохранительным органам по официальному запросу. В сочетании с SMBIOS UUID и TPM Endorsement Key он формирует практически уникальный отпечаток аппаратной платформы.

Изучить его стоит. Но распространять — нет.

Источник