VPN-сервис Windscribe выпустил бесплатный open-source скрипт deGDID для удаления скрытого трекера GDID из Windows
Скрипт полностью стирает идентификатор GDID и блокирует его повторное создание через изменение прав реестра и файрвол
Применение deGDID ломает часть сервисов Microsoft — от входа через login.live.com до синхронизации OneDrive, — а старые ключи остаются на серверах компании
Windows не имеет встроенного переключателя для отключения GDID, который работает ниже уровня VPN и не скрывается при смене IP-адреса
Месяц назад стало известно о федеральном уголовном деле, в котором Global Device Identifier (GDID) — постоянный идентификатор устройства Microsoft — помог следствию привязать сетевую активность к конкретному компьютеру с Windows. Обвинение, рассекреченное 1 июля, было предъявлено 19-летнему гражданину США и Эстонии, которого следствие связывает с хакерской группировкой Scattered Spider: по версии обвинения, он причастен к взлому ювелирного ритейлера в мае 2025 года с требованием выкупа в 8 миллионов долларов. Следователи смогли проследить устройство через несколько стран и разные VPN-сервисы на протяжении примерно восьми месяцев именно благодаря привязке GDID к сетевой активности.
Несмотря на благую цель расследования, сам факт постоянного трекера, встроенного в Windows и не зависящего от IP-адреса, стало трудно игнорировать — и это стало переломным моментом, побудившим Windscribe принять меры. 27 июля компания выпустила открытый проект и скрипт под названием deGDID, который направлен на удаление GDID с ПК, но ценой нарушения работы некоторых облачных сервисов Microsoft.
Источник изображения — tomshardware.com
Как работает скрипт
Скрипт доступен на GitHub и запускается через PowerShell с правами администратора. Он полностью бесплатен, не изменяет системные файлы Windows и работает через управляемую блокировку сетевых путей регистрации устройства — с помощью правил файрвола и изменений в файле hosts. У deGDID четыре флага запуска:
- –Status — режим только для чтения, сообщает, активен ли GDID на системе;
- –Status –Redact — генерирует диагностические журналы со скрытым GDID, чтобы их можно было безопасно передать в поддержку;
- –Protect — полностью стирает GDID и предотвращает создание новых;
- –Unprotect — откатывает изменения и возвращает систему к состоянию по умолчанию.
Наибольший интерес представляет именно флаг –Protect. Сначала скрипт ищет выданные сервером ключи GDID в реестре, где они кэшируются, и удаляет их все — это, в принципе, можно сделать и вручную. Однако при ручном тестировании в Windscribe заметили, что ключи GDID молча создаются заново в фоновом режиме после перезагрузки или при следующем обращении Windows к серверам Microsoft. Более того, в компании проверили и другой возможный обходной путь — вход в систему через локальную учётную запись вместо аккаунта Microsoft: GDID всё равно появлялся.
Чтобы разорвать этот цикл, скрипт изменяет ACL (списки управления доступом) и права реестра, предотвращая повторную загрузку и создание ключей GDID операционной системой. Он также блокирует внутреннюю конечную точку DeviceAdd, отрезая службы идентификации Microsoft от возможности распознавать этот ПК как зарегистрированный в Windows. Этот двойной удар завершает процесс: существующие ключи GDID не только удаляются, но и возможность создания новых сводится на нет.
Источник изображения — tomshardware.com
Ограничения и что может сломаться
Старые ключи, уже находящиеся на серверах Microsoft, удалить невозможно — компания сохраняет к ним неограниченный доступ. Скрипт также работает только на неуправляемых системах с учётными записями администратора: если устройство состоит в домене или управляется организацией, deGDID откажется запускаться.
Поскольку скрипт блокирует конвейер DeviceAdd, часть служб Windows, зависящих от аутентификации через аккаунт Microsoft, перестаёт работать корректно. По имеющимся данным, среди затронутых функций:
- вход в Microsoft Store и сервисы Xbox;
- авторизация в клиенте Outlook;
- синхронизация OneDrive;
- биометрический вход Windows Hello и passkey-аутентификация, привязанные к облачному аккаунту.
Зачем вообще понадобился deGDID
Причина, по которой deGDID вообще нужен, в том, что Windows не имеет встроенного переключателя для отключения GDID. Идентификатор существует как постоянная метка устройства, которая может отслеживать пользователя без его согласия. Он работает независимо от IP-адреса и находится на уровне ниже того, где действуют VPN, поэтому никакое туннелирование сети не способно его скрыть — как показало и собственное тестирование Windscribe с локальными учётными записями. Это объясняет, почему компания решила создать deGDID — в противовес потенциально инвазивной системе слежения, которая в неправильных руках может привести к серьёзным последствиям.
Источник изображения — tomshardware.com
Результаты тестирования
Скрипт протестировали на компьютере с Windows 11, и он сработал как задумано. Флаг –Status показал несколько кэшированных GDID, которые затем были удалены флагом –Protect, и новый GDID не появился даже после перезагрузки. Как и ожидалось, некоторые приложения Microsoft начали выдавать ошибки соединения. Проверка учётной записи через login.live.com оказалась заблокирована во всех браузерах, хотя login.microsoftonline.com продолжил работать. Онлайн-игры и другие приложения при этом функционировали нормально.
В Windscribe подчёркивают, что deGDID — это исследовательский проект, который будет развиваться по мере получения новой информации о работе GDID. Пока же тот факт, что скрипт может нарушить работу ключевых служб и функций Microsoft, способен стать слишком большой жертвой для части пользователей. К тому же deGDID не гарантирует удаления всех экземпляров GDID, а у Microsoft уже есть ранее собранные ключи — так что это точно не идеальное решение, но хорошее начало борьбы со скрытыми трекерами.
