How Anti-Cheat Detects Hardware (2026)

Anti-cheat detects hardware by reading identifiers from your motherboard firmware, storage devices, network adapter, Windows installation, and security hardware, then combining them into a composite fingerprint. It does not depend on one universal HWID. The resulting values can be hashed and compared server-side, so changing one component may leave enough of the original machine visible for a match.

What a "hardware ID" actually is

HWID is shorthand for a bundle of facts about a PC. A motherboard supplies an SMBIOS/BIOS serial and motherboard UUID, a drive supplies a firmware serial, a filesystem supplies a volume serial, and a network adapter supplies a MAC address. Windows adds installation-scoped values such as MachineGuid. Newer checks can include TPM 2.0 attestation material and Secure Boot state.

If you need the vocabulary before the internals, what a hardware ID is in plain terms separates device identifiers from account IDs and software identifiers. The key point here is that no single field has to carry the decision. A fingerprint remains useful even when one value is missing, blank, or changed.

The collection side usually has more than one route to the same source. A normal Ring 3 process can query Windows Management Instrumentation, registry values, and documented device APIs. A signed kernel driver at Ring 0 can request data closer to the device stack, where a user-mode substitution cannot control the answer. Memory scanning, virtual-machine detection, and cheat signatures are separate inputs; this page stays with hardware collection.

Collection also comes before enforcement. The separate guide to how a detection turns into a hardware ban covers the later decision and ban pipeline without treating every collected identifier as proof of cheating.

Where the numbers actually come from

Windows exposes convenient inventory interfaces, but convenience is not authority. Anti-cheat software can compare an easy, high-level answer with a lower-level answer from firmware or the device stack. A mismatch can be as informative as the serial itself.

The motherboard: SMBIOS Type 1 and Type 2

WMI exposes the baseboard through Win32_BaseBoard.SerialNumber and the system UUID through Win32_ComputerSystemProduct.UUID. Those values originate in SMBIOS rather than in your Windows user profile. SMBIOS Type 1 holds System Information, including the system UUID and system serial; Type 2 holds Baseboard Information, including the motherboard serial.

There is a second path. A Windows component can call GetSystemFirmwareTable with the RSMB provider and parse the raw SMBIOS table. Changing only what a WMI query returns does not alter that firmware table. A kernel component can also obtain firmware-backed data without relying on the user-mode WMI service, which is why a one-layer substitution is fragile.

Storage: two serials that people confuse

The physical disk serial belongs to the drive controller and firmware. A component can send IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty through DeviceIoControl, then read a STORAGE_DEVICE_DESCRIPTOR. Its SerialNumberOffset points to the serial reported for that device. Formatting a partition never rewrites this drive-level value.

The volume serial is different. GetVolumeInformationW returns the filesystem's volume serial, often called VolumeID and shown by the vol command. Formatting creates a new filesystem and therefore a new volume serial.

It leaves the physical disk serial intact. This distinction explains why a formatted SSD can look new in one utility and unchanged to a device query.

Network: current MAC versus permanent MAC

At user level, GetAdaptersAddresses returns adapter records whose IP_ADAPTER_ADDRESSES.PhysicalAddress contains the MAC address currently presented by the interface. A registry NetworkAddress override may change that current address. It does not rewrite the address programmed into the network controller, and a driver can inspect lower-level adapter data. A permanent-versus-current disagreement can therefore become another fingerprint signal.

Windows-generated identifiers

Windows Setup creates MachineGuid at HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid. Setup and device discovery also create installation-scoped values such as the hardware profile GUID. These values can change during a clean install because Windows owns them. They are useful members of a fingerprint, but they are weaker anchors than identifiers stored in motherboard or drive firmware.

Firmware and newer identity axes

A modern inventory can include RAM module serials exposed by Win32_PhysicalMemory and SMBIOS Type 17, monitor EDID data under HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY, Secure Boot state, and TPM presence. Through TPM Base Services and the Tbsi_* API surface, software can confirm that a TPM exists and request attestation-related material. A TPM 2.0 endorsement key is hardware-rooted, so it belongs to a different trust layer from MachineGuid.

The deeper explanation of TPM 2.0 and Secure Boot checks covers what those features attest and what they do not. Neither feature is a magic universal HWID by itself.

One common claim needs correcting: a modern x86 CPU does not expose a unique per-chip serial through CPUID. The old processor serial-number feature disappeared after the Pentium III era. CPUID can identify vendor, family, model, and stepping, which describes a class of processors rather than uniquely identifying your chip.

Why anti-cheat matches a set instead of one number

A composite fingerprint tolerates ordinary hardware changes. Drives fail, network adapters are replaced, and firmware vendors sometimes leave serial fields blank. If enforcement depended on one field, a routine repair could either break every match or falsely merge many PCs with the same placeholder value.

Think of the stored record as hashed members plus a match threshold, not as a readable list attached to your account. On a later launch, the service can score how many stable members overlap and how much weight each one carries. The exact weighting is product-specific and is not public, but the model explains why partial changes are unreliable.

Suppose you replace only the SSD. Its disk serial changes, and a new filesystem has a new volume serial. The SMBIOS/BIOS serial, motherboard UUID, MAC address, MachineGuid, RAM serials, TPM 2.0 endorsement key, Secure Boot state, and monitor EDID still describe the same PC. Two changed fields do not make the remaining overlap disappear.

The same anti-cheat engine can derive comparable hardware fingerprints in several games, but publishers administer account bans separately. An Easy Anti-Cheat ban in one title does not automatically ban every account you use in every EAC title. The exposure comes from presenting the same machine values again, which can support re-flagging or cross-title enforcement where the relevant publisher or engine policy applies.

Why the read moves into the kernel

Ring 3 code asks Windows services and libraries for data. Ring 0 code runs inside the kernel and can issue device requests, inspect loaded drivers, and see system state that a normal process cannot reliably verify. This does not make every answer infallible, but it removes many easy places where user-mode software could substitute a result.

Named engines use signed kernel components: Easy Anti-Cheat's kernel driver is commonly installed as EasyAntiCheat.sys, BattlEye uses BEDaisy.sys, and Riot Vanguard uses vgk.sys. Load timing differs. Vanguard is designed around a boot-start trust chain, while other drivers may become active around game launch.

Driver signing lets Windows decide which kernel modules may load. PatchGuard, also called Kernel Patch Protection, guards critical kernel structures against unsupported modification. Anti-cheat drivers work within that environment while combining hardware inventory with memory scanning, driver blocklists, virtual-machine checks, and process telemetry.

DMA hardware adds another boundary: a PCIe device can access memory without following a normal game-process path. Device enumeration and IOMMU state help assess that surface, but they are not hardware-identity fields in the same sense as a motherboard serial. See why the driver runs at Ring 0 for the trust model rather than a second primer here.

What survives a reinstall, and what does not

The storage location decides persistence. Windows Setup can regenerate values owned by the operating system or filesystem. It does not normally alter firmware stored on a motherboard, drive controller, NIC, RAM module, TPM, or monitor.

Only MachineGuid and the volume serial in this table are expected to change during a clean reinstall. The other firmware-level members remain available for comparison, so wiping Windows does not give the machine a new hardware identity.

You can check which identifiers your machine is currently exposing without treating the result as proof that a specific engine uses every field. If you are deciding whether a wipe is useful cleanup, the focused answer on whether formatting Windows helps at all keeps that decision separate from hardware collection.

What actually breaks the old match

A durable change has to address the stable inputs that made the old composite recognizable. Replacing one part or regenerating one Windows value leaves the rest of the record intact. A temporary user-mode interception is also weak because a resident driver may read through a different path before that interception exists.

TraceX Spoofer rewrites the supported identifiers themselves as a one-time change. You run TraceX once, keep the rewritten values permanently, then delete the tool. There is no daemon or per-session process that must keep racing the anti-cheat driver after every boot.

If an HWID ban is the confirmed problem, rewrite those identifiers once. Do not use this as a substitute for an account appeal, and do not assume a hardware rewrite removes account-side enforcement. It changes what the machine presents; it does not erase a publisher's account record.