Which hardware identifiers actually get read
Motherboard and disk serials, SMBIOS UUID, MAC addresses, TPM, GPU UUID, volume IDs and the registry MachineGuid: where each one lives and what a kernel-level spoofer can and cannot change.
Short answer
Software reads a correlated set rather than one HWID: motherboard and disk serials, SMBIOS UUID, MAC addresses, TPM state, GPU UUID, volume IDs and MachineGuid. A kernel-level spoofer can change what Windows reports for most of these, but not values held in signed firmware.
On this page10
- Is there a single HWID?
- Where does each identifier live, and can it be spoofed?
- What does a kernel-level spoofer change?
- What can a kernel-level spoofer not change?
- Why do mismatched values stand out?
- Can one missed identifier undo the rest?
- What identifies you besides hardware?
- Should you edit these values yourself?
- Common questions about hardware identifiers
- Sources
Is there a single HWID?
No. HWID is a convenient shorthand for something that does not exist as a single value. What exists is a set of identifiers, each read by different means and each with its own origin and lifetime. Software that wants to recognise a machine reads several of them and stores the combination, often hashed together. That design is why partial changes are so weak: the remaining values are usually enough to match the set.
Where does each identifier live, and can it be spoofed?
In the last column, spoofability means what a kernel-level tool can change in what the operating system reports. It never means that the physical value inside a chip has been rewritten.
| Identifier | Where it lives | Read via | Typical spoofability |
|---|---|---|---|
| Motherboard serial | SMBIOS tables in the board's firmware | Win32_BaseBoard | The reported value is commonly changed at OS level. The value stored in firmware is not |
| System UUID | SMBIOS system information, set at manufacture | Win32_ComputerSystemProduct | Commonly changed at OS level. Widely read, so often part of the set |
| BIOS serial and version | Board firmware | Win32_BIOS | Reported value commonly changed; a value inconsistent with the board model is itself a signal |
| Disk serial numbers | The drive's own firmware, returned by the SATA or NVMe identify command | Win32_DiskDrive, storage APIs | OS-reported value commonly changed. The drive still knows its real serial |
| Volume serial and volume GUID | Filesystem metadata on the partition, created when it is formatted | vol, Get-Volume, volume APIs | Changes on a format and is commonly regenerated. Easy to read, so easy to correlate if missed |
| MAC addresses | The network adapter's EEPROM, with an OS-level override layer above it | getmac, Win32_NetworkAdapter | The reported address is commonly changed. The burned-in address remains in the adapter |
| TPM identity and attestation keys | The TPM chip, with keys certified by the vendor | Win32_Tpm, platform attestation APIs | Not forgeable. A vendor-signed key cannot be invented by software, though TPM state can be cleared or the device disabled, each with its own consequences |
| GPU UUID | The graphics card's own firmware, exposed by the vendor driver | Vendor tooling and driver APIs | Generally not changed by an OS-level spoofer. Read through the vendor driver rather than through SMBIOS |
| Registry MachineGuid | A registry value created when Windows is installed | The Cryptography key under HKLM | Purely an operating-system value: changes on a clean install and is commonly regenerated |
| Windows install and product identifiers | Registry, written during installation and activation | Registry and licensing APIs | Operating-system values, reset by a clean install |
| CPU identification | The processor itself | CPUID | Reports a model, not a per-unit serial on consumer parts, so it is a weak identifier and rarely the deciding one |
| Monitor serial in EDID | The display's own firmware | Display APIs and the registry's display key | Not a machine identifier as such, but it is readable and it does not move when you change PC parts |
The table shows where values live and how they are read. It is not a list of things to edit, as the warning about hand-editing explains.
What does a kernel-level spoofer change?
A kernel-level tool sits below the APIs that normal software uses. When a client asks Windows for a disk serial or a board serial, the answer it receives is the one the tool supplies. That is genuinely powerful, because nearly everything that reads identifiers reads them through those paths. But it is also all that is happening: the tool changes an answer, not a chip.
What can a kernel-level spoofer not change?
Three kinds of value resist it. The first is anything held in signed firmware, most importantly what a TPM certifies. These values cannot be forged, because the signature comes from a key the tool does not have. The second is values read through a path the tool does not cover, so a GPU identifier fetched through a vendor driver comes back unchanged. The third is physical values, which stay physical. The drive still knows its serial, and the network adapter still knows its burned-in address, whatever Windows reports above them. A tool that claims otherwise is describing marketing, not mechanism.
Info
Why do mismatched values stand out?
A set of identifiers that do not fit together is more distinctive than the originals were. Think of a laptop board serial on a desktop chipset, or a disk serial in a format that manufacturer never used. A board model that does not exist, or values that change on every single read, stand out in the same way. Each of those is a pattern in its own right, which is why random values are not the same as safe ones. It is also why a tool's choice of plausible values matters more than the number of fields it touches.
Can one missed identifier undo the rest?
If the recorded set was eight values and seven of them now read differently, the eighth can still match the old record. Whether it does depends on how the vendor correlates values, which is not published, so assume the weakest link decides the outcome. That is the practical argument for verifying every value you can read rather than trusting a summary screen.
What identifies you besides hardware?
People buy a hardware tool expecting it to deal with these, but it does not, and neither does any other local tool.
- The account itself, and anything the platform has recorded against it
- The email address and phone number attached to that account
- The payment method used to buy the game or the platform balance
- Your IP address, your ISP and the network you play on
- How you play: aim traces, timing, statistical outliers, report volume
- The friend graph and who you queue with
- Anything you tell people about yourself in a public channel
Warning
Should you edit these values yourself?
No. Do not edit these values by hand, either in the registry or in a board's firmware. Hand-editing risks an unbootable machine, lost activation and a warranty dispute. It can also leave an identifier set so inconsistent that it stands out more than the original did. If you want to see what your machine reports, the verification guide lists read-only commands. Modification is the tool's job, and only a tool built for it should do it.
Common questions about hardware identifiers
Which identifier do anti-cheats actually use?
That is not published, it differs by vendor, and it changes over time. Everything circulating about specific weightings is community inference, so plan for the whole set rather than for one value.
Does changing my disk fix a hardware ban?
Not reliably. If the recorded set included board, UUID, MAC or TPM values, a new disk changes one element and leaves the rest matching.
Does a clean Windows install change my HWID?
It changes operating-system values such as MachineGuid, the install identifiers and volume serials, but it does not touch anything in firmware. On its own, it is not a change of hardware identity.
Is the TPM a problem?
It is the hardest element to address honestly, because its keys are vendor-certified and cannot be forged. What is possible with TPM state depends on your board and your tool, but anyone claiming to forge an attestation is overstating it.
Do MAC address changes matter if I use Wi-Fi?
Every adapter, wired or wireless, has its own address, and any of them can be read. Check all adapters rather than assuming the one you connect with is the only one visible.
Sources
Apart from the EDID serial, the table is bench work: the team read these values on their own machines. No vendor publishes which ones an anti-cheat uses.
- 01VESA E-EDID standard, release A2
the serial number a monitor carries in its own EDID data
glenwing.github.io
Read next
Still stuck? Open a ticket on Discord
All guides