HWID spoofer rotation detection via SMBIOS + ACPI cross-reference

Hardware ID banning — issuing a ban tied to a set of hardware identifiers rather than an account — is a standard anti-cheat escalation for repeat offenders. The premise is that hardware is harder to replace than an account. The HWID spoofer ecosystem exists to defeat this assumption by rotating identifiers at the software layer, without buying new hardware.

First-generation spoofers targeted the obvious registry values: MachineGuid at HKLM\SOFTWARE\Microsoft\Cryptography, network adapter MAC in HKLM\SYSTEM\CCS\Control\Class\{4D36E972...}\NetworkAddress, and the drive serial via an IOCTL filter driver that intercepts IOCTL_STORAGE_QUERY_PROPERTY and substitutes a randomised serial. This was sufficient when anti-cheat HWID collections were limited to those three sources.

Modern anti-cheats collect significantly wider identifier sets, and the spoofer ecosystem has grown to match — but the growth has been asymmetric. Spoofers are good at the Windows API surface; they are bad at the firmware surface. We exploit that gap.

We classify hardware identifiers into four tiers by their writability from usermode software:

Tier 3 and 4 identifiers are our signal surface. Tier 1 and 2 are noisy — they are cheap for both the spoofer and the anti-cheat to play with. The interesting forensic question is whether the Tier-3/4 identifiers are internally consistent with the Tier-1/2 values being presented.

We reversed five publicly-distributed HWID spoofer builds (October 2024 through January 2026) and documented their artifact coverage:

• SMBIOS Type 1 (System Information) — contains UUID (field offset 0x08, 16 bytes), Product Name, Serial Number, SKU Number, and Family. Readable via GetSystemFirmwareTable(RSMB, 0, ...). Two of five spoofers hooked this API in usermode. Three left the firmware table untouched because hooking it kernel-side requires either a hypervisor shim or a BIOS modification.
• SMBIOS Type 2 (Baseboard) — Manufacturer, Product, Serial Number, Asset Tag. None of the five spoofers we examined targeted Type 2. The baseboard serial is a high-fidelity anchor on machines where SMBIOS is otherwise spoofed.
• ACPI _UID (Unique ID objects) — integer or string UIDs assigned to devices in the ACPI namespace (accessible via IOCTL_ACPI_EVAL_METHOD or direct ACPI table parse). Not targeted by any spoofer we observed.
• EFI NVRAM variables — accessible via GetFirmwareEnvironmentVariableEx. The EFI SystemUUID variable and NIC-specific EFI GUIDs are stored in NVRAM and survive OS reinstalls. One spoofer partially targeted EFI variables but corrupted the NVRAM on two test machines, making the approach self-defeating.

The detection does not require any single identifier to be clearly fake. Instead, it checks for internal inconsistency across domains — a pattern that is structurally impossible on a machine that has never been spoofed:

On machines with a TPM 2.0 module (mandatory for Windows 11, present on the majority of recent gaming hardware), the Endorsement Key (EK) provides the strongest available anchor. The EK is an asymmetric key pair generated inside the TPM's isolated execution environment at manufacture; the private key never leaves the chip. The EK certificate, issued by the TPM manufacturer (Intel, STMicroelectronics, Infineon), binds the public EK to the specific chip serial number.

Reading the EK certificate from Windows requires NCryptOpenStorageProvider with the Microsoft Platform Crypto Provider, or the lower-level Tbsi_Get_TCG_Log + NCryptGetProperty path. Once retrieved, the certificate's Subject Alternative Name contains the TPM manufacturer and chip serial. This value:

• Cannot be spoofed without replacing the physical TPM chip (soldered on modern laptops and consumer motherboards, socketed only on older enterprise boards).
• Survives OS reinstall, MachineGuid rotation, disk replacement, and NIC spoofing entirely unchanged.
• Correlates with the SMBIOS Type 1 UUID via the TPM manufacturer's EK provisioning process — a fabricated UUID will not pass a consistency check against the EK certificate's embedded identity.

When a TPM EK is present and readable, we treat it as the canonical machine identity and derive all inconsistency signals relative to it. On TPM-less machines, the ACPI/EFI NVRAM path above serves as the fallback anchor.

rule HWID_Rotation_CrossDomain
{
  meta:
    severity    = "medium"
    category    = "identity"
    confidence  = 0.91

  inputs:
    smbios      := read_firmware_table(RSMB)
    acpi        := eval_acpi_method("\\_SB._UID")
    efi_uuid    := get_efi_variable("SystemUUID", EFI_GLOBAL_GUID)
    efi_nic_mac := get_efi_nic_guid()
    ndis_mac    := get_ndis_mac()
    tpm_ek      := get_tpm_ek_cert()     // null if no TPM

  match:
    sys_uuid    := smbios.type1.uuid
    board_sn    := smbios.type2.serial_number
    sys_sn      := smbios.type1.serial_number

    // Signal A: SMBIOS UUID diverges from EFI NVRAM UUID
    sys_uuid != efi_uuid

    // Signal B: EFI NIC MAC diverges from NDIS MAC
    or mac_from_efi_guid(efi_nic_mac) != ndis_mac

    // Signal C: TPM EK chip serial inconsistent with SMBIOS UUID
    or (tpm_ek != null and
        not tpm_ek_consistent_with_smbios(tpm_ek, sys_uuid))

    // Signal D: Baseboard serial unchanged, system serial changed
    // (requires two scans or server-side historical comparison)
    or (board_sn == prior_scan.board_sn and
        sys_sn   != prior_scan.sys_sn)

  emit:
    artifact {
      machine_guid   = read_machine_guid()
      smbios_uuid    = sys_uuid
      efi_uuid       = efi_uuid
      ndis_mac       = ndis_mac
      efi_mac        = mac_from_efi_guid(efi_nic_mac)
      tpm_ek_subject = tpm_ek.subject_alt_name
      signals_fired  = matched_signals
      rotation_type  = classify_rotation(matched_signals)
    }
}

The rule is designed to be signal-additive: each signal is independently meaningful, and the combination of two or more signals raises confidence to High. Signal C (TPM EK inconsistency) alone is treated as High because the TPM anchor is hardware-bound and the inconsistency cannot arise from legitimate OS configuration.

The 11% of spoofer-active machines that evaded detection were exclusively machines where the operator had performed a BIOS flash to replace the SMBIOS tables wholesale. This is a significant technical step — the operator must source a BIOS image and accept the risk of a failed flash. On those machines, the TPM EK (where present) was the only remaining anchor. Of the 178 spoofer-active machines, 31 had neither a TPM nor a BIOS-accessible SMBIOS anchor, and we could not positively detect the rotation from firmware sources alone.

• Motherboard replacement. A legitimate motherboard replacement changes SMBIOS UUID, baseboard serial, and (on TPM-less machines) the ACPI anchor. This is indistinguishable from a BIOS-level spoof without the TPM EK. Server administrators can note the replacement in the ban-review log; we recommend a brief appeal window rather than an automatic ban on SMBIOS rotation alone.
• OEM zero-serialisation. Some budget OEM systems ship with SMBIOS fields set to "Default string" or "To be filled by O.E.M.". These machines are not spoofed but will not pass a SMBIOS consistency check. We suppress rotation signals on machines where >3 SMBIOS fields are placeholder values and fall back to the TPM and ACPI paths only.
• Virtual machines. Hypervisors synthesise SMBIOS, ACPI, and EFI tables and do not present a host TPM to the guest. VM-presence detection (Hyper-V CPUID leaf, VMware backdoor port, KVM CPUID bit) suppresses this false-positive class before the HWID rule runs.