How Windows Tracks You: Inside the GDID Identifier and Extraction Tool

What GDID Is

GDID (Global Device Identifier) is a 64‑bit number assigned by Microsoft to each Windows device. It is stored as a 16‑character hexadecimal string, e.g., 0018AAAABBBBCCCC, and when referenced internally it is prefixed with g: (e.g., g:6943049711865036). In Microsoft source code the value is called PUID (Passport Unique Identifier).

Where GDID Is Stored

Three registry locations hold GDID‑related data, managed by wlidsvc.exe (Microsoft Account Sign‑in Assistant):

Layer 1 – Plaintext LID : HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID (type REG_SZ). Any user‑level process can read it.

Layer 2 – Device Certificate :

HKCU\...\IdentityCRL\Immersive\production\Token\{AppContainerSID}\DeviceTicket

(type REG_BINARY). This DPAPI‑encrypted blob contains an X.509 certificate and private key that embed the PUID.

Layer 3 – User PUID ↔ SID Mapping : HKLM\...\IdentityCRL\NegativeCache with sub‑keys named <UserPUID>_<UserSID>.

All three layers survive normal reboots, and the plaintext LID can be displayed with a single reg query command.

How Microsoft Allocates GDID

When a brand‑new Windows device first connects to the Internet, wlidsvc.exe sends a SOAP POST to https://login.live.com/ppsecure/deviceaddcredential.srf. The request body contains a <DeviceInfo> block with multiple <Component> tags (the same set used by Windows Autopilot hardware hash) such as manufacturer, product name, SMBIOS UUID, MAC address, and a TPM public key. Microsoft’s server processes the data (algorithm undisclosed) and returns a SOAP response containing a <puid> element. wlidsvc.exe writes this value to the registry as the GDID.

Key point: GDID is not generated on the client; it is assigned by Microsoft’s backend.

Where GDID Is Used Inside Microsoft

Microsoft Store – every purchase, license and app install is tied to the device PUID.

Windows activation – digital licenses are indexed by PUID.

Connected Devices Platform – CDP calls GetStableDeviceIdFromProvider to retrieve the PUID (prefixed with g:) and reports it to dds.microsoft.com.

WNS push notifications – the channel URI contains the PUID.

Delivery Optimization – the service reports the GDID as UCDOStatus.GlobalDeviceId.

Telemetry – most Microsoft.Windows.* ETW events include the GDID in the Device.ID field.

Microsoft Edge – enhanced diagnostics send browsing history tagged with the GDID (used as evidence in US v. Stokes, 2026).

GDID‑Extractor Tool

The GitHub project https://github.com/5mukx/GDID-Extractor provides three binaries: get_gdid.exe (C, PE executable) – quick, standalone extraction. gdid.exe (Rust, PE executable) – full‑featured extraction. get_gdid.x64.o / get_gdid.x86.o (C, COFF objects) – intended for Cobalt Strike/COFFLoader.

Running gdid.exe yields output such as:

[+] Windows GDID + hardware descriptor report
[*] 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}
[*] User PUIDs (HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache)
    0003DEADBEEF1234 dec=1089262744179252 sid=S-1-5-21-...
[*] SMBIOS
    Manufacturer (4097)  : <Your PC Manufacturer>
    Product (4099)       : <Your PC Model>
    Serial number (4101): SN0123456789ABC
    UUID (4102)          : ABCDEF01-2345-6789-ABCD-EF0123456789
[*] TPM Endorsement Key
    EKPub SHA-256        : deadbeefcafefeed...
[*] Physical disks
    PhysicalDrive0 serial=EXAMPLE_NVME_SERIAL_1234
[*] MAC addresses
    eth 00:00:5E:00:53:11
    wifi 00:00:5E:00:53:22

The extraction works without administrator rights, using standard Windows APIs.

Can GDID Be Spoofed? – Four‑Layer Experiment

ZeroTrace Lab tested four spoofing levels, each corresponding to a defense layer.

Layer 1 – Overwrite LID only : Using gdid-patch.exe to write any 16‑hex LID changes the visible GDID locally, but the encrypted DeviceTicket still contains the original PUID. wlidsvc detects the mismatch on the next network call and restores the original LID. Result: cosmetic, not accepted by Microsoft.

Layer 2 – Import Device Certificate : With SYSTEM privileges, the attacker decrypts the DeviceTicket blob, re‑encrypts it using the local DPAPI key, and writes it back together with a modified LID. The system accepts the certificate until the next authentication request, when the server sees hardware descriptors that do not match the certificate and forces a re‑registration, issuing a new PUID and invalidating the imported cert. Result: works briefly, then fails.

Layer 3 – Certificate + VM Hardware Spoofing : In addition to the previous step, the attacker configures a virtual machine to present forged SMBIOS UUID, serial number, manufacturer, model, MAC address, and disk serials. The TPM endorsement key (EK) cannot be forged because the physical TPM’s private key never leaves the chip. The server challenges the TPM, and the virtual TPM’s EK cannot satisfy the challenge. Result: cryptographically impossible – hard wall.

Layer 4 – Clear IdentityCRL to Force Re‑registration : Stopping wlidsvc, deleting the registry keys under HKCU\SOFTWARE\Microsoft\IdentityCRL and HKLM\SOFTWARE\Microsoft\IdentityCRL, then restarting the service causes Windows to generate a new local PUID. However, Microsoft’s backend maps the new PUID to the same device record based on hardware fingerprints, so the identity remains unchanged. Result: local change only; server still sees the original device.

Summary of the Four‑Layer Defense

Layer 1 (LID) – stored in cleartext HKCU; no protection; can be changed instantly but auto‑reverts.

Layer 2 (Device Certificate) – DPAPI‑encrypted blob; can be extracted and re‑imported, but hardware verification fails.

Layer 3 (Hardware Descriptors) – sent to Microsoft; TPM/EK cannot be forged; VM can spoof most fields, but TPM remains a hard wall.

Layer 4 (Server‑side Record) – stored in Microsoft Azure identity database; inaccessible from the client; cannot be altered.

The fundamental issue is that all client‑side data are merely caches; the authoritative identity lives on Microsoft’s servers.

Privacy Implications

GDID is a low‑profile identifier: a 16‑hex string stored in plaintext, readable by any user process, present for over a decade, and attached to every outbound Microsoft request. Most users are unaware of its existence until legal cases expose it.

Effectiveness of common mitigations:

Disabling wlidsvc or firewall‑blocking login.live.com stops Store, activation, UWP, CDP, and WNS, but logging back into a Microsoft account re‑enables them.

Deleting LID and restarting the service has no lasting effect; a new PUID is written automatically.

Re‑installing Windows gives a clean local slate but the server still recognises the same hardware.

Replacing motherboard, disk, and network card is the only reliable way to break the tracking, at the cost of hardware.

The most practical protection for ordinary users is to run Windows inside a virtual machine, isolating the GDID from the host.

POC – gdid‑patch Source (Rust)

// gdid-patch.exe core logic: overwrite HKCU\IdentityCRL\ExtendedProperties\LID
// from https://github.com/5mukx/GDID-Extractor
const IDCRL_EXTPROPS: &str = r"SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties";
const VALUE_NAME: &str = "LID";
fn write_lid(new_value: &str) -> Result<(), u32> {
    // Open key, set value, close key …
}
fn validate(v: &str) -> Result<u64, String> {
    if v.len() != 16 { return Err("LID must be exactly 16 hex characters".into()); }
    let n = u64::from_str_radix(v, 16).map_err(|_| "LID must be hex")?;
    let ns = (n >> 48) as u16;
    if ns != 0x0018 && ns != 0x0003 {
        return Err(format!("namespace tag 0x{:04X} not valid", ns));
    }
    Ok(n)
}

Usage example:

# Show current GDID
gdid.exe
# Overwrite with any valid LID
gdid-patch.exe 0018AAAABBBBCCCC
# Sample output
# before: LID = 0018111122223333  (GDID = g:6755468662874931)
# after : LID = 0018AAAABBBBCCCC  (GDID = g:6943049711865036)

Disclaimer: The tool is provided for educational and research purposes only. Using it on unauthorized devices may cause authentication failures with Microsoft services.

Conclusion

GDID demonstrates that Microsoft tracks each Windows device with far more granularity than most users realise. It is a documented system feature that has been active for years. For security researchers, GDID‑Extractor is a valuable reconnaissance utility. For regular users, understanding GDID is essential for informed privacy decisions, and running Windows in a virtual machine offers the most practical mitigation.

Sources: ZeroTrace Lab blog (https://zerotracelab.com/blog/gdid-windows-tracking) and the GDID‑Extractor GitHub repository (https://github.com/5mukx/GDID-Extractor).