How a Windows machine gets fingerprinted.

Notes from reversing how modern anti-cheats and licensing systems identify a specific machine, and where the identifiers they read actually live. Written up so it reads straight, not as a pitch.

01The identifiers in software reach

Most of what identifies a Windows machine is ordinary software state. It sits in the registry, in a driver's answer to a query, or in a filesystem field, and it can be read by anything with the right handle:

• MachineGuid: a per-install GUID under SOFTWARE\Microsoft\Cryptography, read straight from the hive.
• Disk and volume serials: the disk serial comes back through IOCTL_STORAGE_QUERY_PROPERTY at the storage layer, not from the friendly name a UI shows.
• MAC address: per-adapter, exposed by the NIC and overridable in the adapter's registry key.
• Computer name: mirrored across four places at once: NetBIOS, ActiveComputerName, the Tcpip hostname, and the NV hostname. Read one, they should all agree.
• Product and hardware-profile IDs: string values in the current-version and profile keys.

The important detail is the layer. A tool that only changes the value shown in Settings, but not the value a driver returns from an IOCTL, leaves the two disagreeing. A collector that reads the lower layer sees straight through it.

02Reading past the cache

Not everything that looks like a registry value is a registry value. The system UUID is the clearest example. Windows keeps a copy under HardwareConfig, but the real number lives in the SMBIOS table in firmware, and GetSystemFirmwareTable('RSMB') reads it directly, past any cache. Parse SMBIOS Type 1 and you get the firmware UUID no matter what the registry copy says.

This is why the firmware UUID and a cached copy can diverge, and why a collector that wants ground truth calls the firmware path. It is a different class of value: produced by the board, not by the OS.

03The TPM changes the game

The bigger shift is hardware attestation. A TPM holds an Endorsement Key that is generated inside the chip and never leaves it. From it, an Attestation Identity Key can be derived and enrolled with a service. When an anti-cheat asks "is this the same physical machine I banned," it is not comparing a serial string. It is asking the TPM to sign a challenge with a key that is bound to that one piece of silicon.

Kernel anti-cheats have moved this direction. A hardware ban keyed to a TPM-attested identity is not answering a registry read, so nothing at the registry or driver layer moves it. That is the line worth understanding before anyone claims otherwise.

04Enclaves and remote attestation

On top of the TPM sit virtualization-based security and its enclaves. Their measurements are extended into TPM PCRs at boot and can be attested remotely through a service such as Microsoft Azure Attestation. The machine presents a signed measurement; a server decides whether to trust it. The device cannot present a measurement it did not actually produce, because the signing happens below the OS.

The TCG measured-boot log works the same way: it is only meaningful because the PCR values that sign it are extended by the TPM during boot, in order, and cannot be rewound.

05Where the line sits

Put together, the picture is two layers. One is software state: the registry, driver responses, and filesystem fields, which software can read and, with care, rewrite and restore. The other is produced by firmware or the TPM and, in the enclave case, verified by a service the machine cannot lie to.

The first layer is where machine fingerprints and most ban lists have historically lived. The second is where hardware attestation lives, and moving it requires operating below the OS, which is a different tool with a different risk profile entirely. Knowing which layer a given check reads from is the whole game. Everything else is marketing.