HWID Spoofers Explained: SMBIOS, TPM, Disk Serials, and Why Hardware Bans Persist

"HWID banned" is the sentence a player sees after the account ban lands and the second account, created twenty minutes later on the same machine, also lands in the banned pile without ever loading a match. The mechanism behind it is not exotic. The anti-cheat driver read a handful of identifiers on the first session, hashed them, associated the hash with the banned account, and on the next session it recognized the machine before the game handshake even completed.

This post walks through what those identifiers actually are, where they live physically on the board, and what a HWID spoofer has to intercept to convince a ring-0 anti-cheat that it is talking to different silicon. The material is deliberately concrete. Every API, WMI class, and IOCTL named below is documented on learn.microsoft.com or in the T13 ATA/ATAPI Command Set. Nothing here is a secret. What is scarce is a clean explanation of how the pieces fit together.

The fingerprint anti-cheats actually build

An anti-cheat driver does not have one magic "hardware ID". It collects a set of identifiers, each anchored at a different layer of the platform, and hashes them together. The redundancy is the point. Spoofing one is easy. Spoofing all of them consistently, in a way that survives cross-checks, is the hard problem.

The identifiers in play across shipping anti-cheats (BattlEye, Easy Anti-Cheat, Riot Vanguard, Byfron/Hyperion, FACEIT AC) are a subset of this list:

The bottom row of that table matters. A Windows reinstall clears MachineGuid and any registry-backed telemetry, but the top rows survive because they live in flash on the motherboard, on the drive, on the NIC, and inside the TPM. That is the "why bans persist" answer in one sentence.

SMBIOS: what the BIOS hands to Windows

SMBIOS is a set of structured tables the firmware exposes at boot. Windows caches them and serves them back through the GetSystemFirmwareTable API and, more commonly for anti-cheats, through WMI. The classic query looks like this:

Get-CimInstance Win32_BIOS | Select-Object SerialNumber, Manufacturer, Version
Get-CimInstance Win32_ComputerSystemProduct | Select-Object UUID, Vendor, Name
Get-CimInstance Win32_BaseBoard | Select-Object SerialNumber, Manufacturer, Product

The Win32_BIOS and Win32_ComputerSystemProduct classes are the standard entry points. Win32_ComputerSystemProduct.UUID maps to SMBIOS type 1 offset 0x08, the sixteen-byte system UUID that OEMs are supposed to burn per unit. Win32_BaseBoard.SerialNumber maps to type 2 offset 0x07. Any anti-cheat that only queries WMI is trivially defeated by hooking NtDeviceIoControlFile for the WMI service, but no serious anti-cheat stops there. The kernel-side driver calls ExGetFirmwareEnvironmentVariable or reads the raw SMBIOS table via NtQuerySystemInformation with SystemFirmwareTableInformation, and cross-references the values.

A HWID spoofer that wants to lie about SMBIOS has three options, in ascending order of danger:

1. Hook the read path in memory. The spoofer sits above the anti-cheat driver in load order (which is difficult on HVCI systems), intercepts the SMBIOS table pointer, and returns a modified copy.
2. Modify the SMBIOS table at boot. Some boards let you override strings via the BIOS setup menu or a manufacturer utility. This is persistent and safe if the vendor supports it.
3. Reflash the BIOS with modified DMI strings. This works on many AMI and Insyde boards but bricks Gigabyte and MSI boards that verify DMI regions during flash. Do not do this on hardware you care about.

Option 3 is why the phrase "firmware spoof" appears in cheat forum posts and why boards get bricked shortly after. Writing to the SPI flash without exact knowledge of the region layout is a recipe for a black screen at next POST.

Disk serials and the SMART command path

Anti-cheats read drive serials through IOCTL_ATA_PASS_THROUGH or IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty. Both routes eventually issue an ATA IDENTIFY DEVICE (0xEC) command to the drive, which returns a 512-byte block whose bytes 20 through 39 contain the ASCII serial number. NVMe uses a functionally identical Identify Controller command with a different opcode.

Here is the minimum ioctl setup for the SMART path, which older Windows drivers still support:

SENDCMDINPARAMS in = {0};
SENDCMDOUTPARAMS out = {0};
DWORD returned = 0;

in.cBufferSize = IDENTIFY_BUFFER_SIZE;
in.irDriveRegs.bCommandReg = ID_CMD;      // 0xEC
in.irDriveRegs.bSectorCountReg = 1;
in.bDriveNumber = 0;

DeviceIoControl(hDrive,
                SMART_RCV_DRIVE_DATA,      // 0x0007C088
                &in, sizeof(in) - 1,
                &out, sizeof(out) + IDENTIFY_BUFFER_SIZE - 1,
                &returned, NULL);

Because the return path lands back in user or kernel buffers depending on caller, a spoofer that hooks IofCallDriver for the storage stack can rewrite the IDENTIFY response before it reaches the anti-cheat. That is the most common technique: intercept the completion routine, patch bytes 20 to 39 of the returned buffer, and let it return. The drive itself is untouched. On the next reboot, real reads return the real serial.

The safer alternative is to sit between the anti-cheat and the storage class driver in the device stack via a filter driver. Microsoft documents this pattern under Storage Filter Drivers and it is the same technique legitimate encryption and endpoint products use.

MAC addresses, EDID, and the smaller identifiers

MAC addresses come from GetAdaptersAddresses in Iphlpapi, which reads them from the NDIS layer, which reads them from the NIC EEPROM. Realtek and Intel both expose vendor tools that let you overwrite the EEPROM MAC, and Windows lets you spoof at the driver level via the NetworkAddress registry value under the adapter's class key. Anti-cheats know about the registry override and often walk the NDIS OID chain directly with NdisRequest(OID_802_3_PERMANENT_ADDRESS), which returns the burned-in address regardless of the registry.

EDID is the 128 or 256 byte block your monitor hands to the GPU over the DDC channel. Windows exposes it through the registry at HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\*\Device Parameters\EDID. It contains a manufacturer ID and a serial number that some anti-cheats hash. Spoofing EDID is a matter of intercepting the registry read, since no game asks the monitor directly.

Windows MachineGuid is a GUID under HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid. It is generated at install time and it is trivially rewritable if you have SYSTEM privileges, which every ring-0 spoofer does. It is included in fingerprints mostly as a tiebreaker, not as a primary anchor.

TPM: the identifier that broke the model

The TPM Endorsement Key certificate is the reason HWID spoofing in 2026 looks nothing like it did in 2020. The EK is a 2048-bit RSA key (or a 256-bit ECC key on TPM 2.0) that is generated inside the TPM at manufacture time. The private half never leaves the chip. The TPM ships with a manufacturer-signed certificate binding the public half to a specific TPM part, and that certificate lives in NV storage at handle 0x01C00002 (RSA EK) or 0x01C0000A (ECC EK). The Trusted Computing Group's TPM Library Specification is the canonical reference for the command set and NV layout.

Reading it is straightforward with the TPM Base Services API:

TBS_CONTEXT_PARAMS2 params = { 0 };
params.version = TBS_CONTEXT_VERSION_TWO;
params.includeTpm20 = 1;
TBS_HCONTEXT ctx;
Tbsi_Context_Create((PCTBS_CONTEXT_PARAMS)&params, &ctx);

BYTE cmd[] = {
    0x80, 0x01,                         // TPM_ST_NO_SESSIONS
    0x00, 0x00, 0x00, 0x0E,             // command size
    0x00, 0x00, 0x01, 0x7B,             // TPM_CC_NV_ReadPublic
    0x01, 0xC0, 0x00, 0x02              // EK cert NV index
};
BYTE resp[4096];
UINT32 respLen = sizeof(resp);
Tbsip_Submit_Command(ctx, TBS_COMMAND_LOCALITY_ZERO,
                     TBS_COMMAND_PRIORITY_NORMAL,
                     cmd, sizeof(cmd), resp, &respLen);

There is no software path to change what the TPM returns, short of physically desoldering the chip. That is the whole point of a hardware root of trust. Riot Vanguard extended its TPM 2.0 requirement to League of Legends in Patch 14.8 (Philippines pilot, April 17 2024) and rolled it out globally in Patch 14.9 on May 1 2024, following the same pattern Valorant took at launch. The requirement is Windows 11 only. Windows 10 systems are exempt from the TPM gate for LoL, and Riot cited older-hardware compatibility as the reason it did not also enforce Secure Boot on LoL the way it does on Valorant. If the anti-cheat can pin the ban to an EK cert, no software spoofer on the market defeats it. The player has to buy a new motherboard or add a discrete TPM header module. What Riot Vanguard actually watches for has the deeper walk-through of vgk.sys and its verification chain.

The cost side matters. Requiring TPM 2.0 excludes older hardware, and Riot ate that criticism deliberately. From an anti-cheat vendor's perspective the tradeoff is obvious: one immutable identifier is worth ten spoofable ones. Riot's June 2026 "Vanguard On-Demand" update, which lets the driver stay dormant until a Riot game launches on Windows 11 25H2 boxes with Secure Boot, TPM 2.0, IOMMU, VBS, and HVCI all enabled, doubled down on that bet by using the same TPM-anchored attestation to prove nothing hostile ran while Vanguard was off.

Persistence, cross-checks, and the reason "just reinstall" fails

The naive user model is that a Windows reinstall gives you a clean machine. It does not. Reinstalling Windows resets MachineGuid, resets the Cryptography\MachineGuid, wipes registry-based telemetry, and rotates a handful of OS-generated identifiers. It touches zero bits of firmware. SMBIOS strings, MAC EEPROM, drive serial, TPM EK, and monitor EDID are all intact. The ban follows the hardware.

The cross-check problem is what makes persistent spoofing hard even for people who know the surface well. An anti-cheat that reads SMBIOS through NtQuerySystemInformation and also reads it through GetSystemFirmwareTable can compare the two. A spoofer that hooked one path but not the other reveals itself instantly. Worse, some drivers (BattlEye's kernel component BEDaisy.sys is documented to do this) parse the raw ACPI DSDT and pull motherboard identifiers from a second location entirely, then compare. Every hook you install is a place where inconsistency can leak.

The Apex Legends ban tracker at cheat ban waves and the anatomy of a detection pass covers the timing side. A per-boot spoofer has to survive the initial fingerprint read at game launch, a re-read on match join, and for some titles a periodic re-read during play. DMA hardware readers, which live on a separate PCIe device and never touch the target machine's CPU, have their own cross-check problems documented in DMA cards, PCILeech, and the hardware-cheating economics.

Per-boot vs persistent spoofing

There are two operational models. Persistent spoofing modifies the identifiers at rest: reflashed BIOS, rewritten NIC EEPROM, physically replaced drive. It is what someone with a spare bench and no fear of a $200 board loss would do. It is also what gets you a bricked machine when the SPI write fails partway through.

Per-boot spoofing loads a driver early, hooks the read paths, and returns whatever fingerprint the user configured. It is safer because nothing on the physical device changes, but it is fragile because it has to defeat every cross-check path the anti-cheat uses. KyTech's approach falls into this category and it is why the beta is Apex-only: cross-check coverage is a per-game engineering problem, not a solved-once problem.

The comparison is roughly:

Notice the last row. Per-boot spoofing does not solve the TPM EK problem because Tbsip_Submit_Command returns a signed blob from the chip. A spoofer that rewrites the response invalidates the signature and the anti-cheat notices at the first verification step. This is the sense in which Vanguard-class anti-cheats have "won" the identifier race for the titles that require TPM. How to think about picking a cheat provider in 2026 treats that constraint as a first-order filter, not a footnote.

Detection vectors worth understanding

Anti-cheats catch spoofers in a handful of well-known ways. Understanding them clarifies why building a real spoofer is closer to writing a small operating-system subsystem than to running a registry patcher.

• Cross-source mismatch. SMBIOS reported through WMI does not match SMBIOS parsed from the raw table. Microsoft's SMBIOS bringup documentation enumerates the tables the OS reads and where they are cached.
• Timing anomalies. IDENTIFY DEVICE takes microseconds on real hardware. A user-mode hook that reformats the buffer adds measurable latency.
• Unhooked syscalls. Anti-cheats manually parse ntoskrnl and reconstruct the SSDT to bypass any hook installed on the standard entrypoints.
• Signature checks on driver load. HVCI-enforced systems refuse unsigned kernel modules outright, which is why cheat drivers ship with leaked or purchased WHQL signatures and why Microsoft's driver block list grows every quarter.
• TPM attestation. If the anti-cheat requests a signed quote from the TPM, no software layer can forge the response.

Windows 11 24H2 added another wall specifically relevant to cheat authors. MiShowBadMapper now refuses non-cached alias mappings to write-back kernel pages, which killed a broad class of signed-third-party-driver chains that walked page tables from user mode to read protected memory. Spoofers were not the primary target, but they were caught in the same net. Getting a modern spoofer to load on a fully patched 24H2 machine with HVCI on is significantly harder than it was in 2023, and the ARM64 build of EAC that Epic shipped in EOS SDK 1.17.1.3 (August 2025) as the launch anti-cheat for Fortnite on Snapdragon Windows on ARM devices closes yet another surface. Anything that was "just a matter of porting the x64 hook" now needs a second port.

How KyTech handles this

KyTech was founded in 2025 by two engineers with backgrounds in Windows internals and reverse engineering. Our product line covers Apex Legends, Counter-Strike 2, Overwatch 2, Black Ops 7, Forza Horizon 6, and Roblox, each with its own kernel driver tuned to the specific anti-cheat in the target title.

The KyTech Apex product is the only build that currently ships with the HWID spoofer beta enabled. That scoping is deliberate. Spoofer work is per-game and per-anti-cheat because the cross-check surface differs across BattlEye, EAC, Vanguard, and Byfron. We do not sell a "universal HWID spoofer" because no such thing exists in a form that would survive contact with modern cross-check code, and shipping one would be a way to burn user accounts.

Our approach is per-boot. The KyTech loader installs the spoofer before the anti-cheat driver initializes, hooks the SMBIOS, disk, MAC, and EDID read paths, and returns a per-user fingerprint stored in the loader configuration. We do not touch flash. We do not write to NIC EEPROMs. We do not attempt to spoof the TPM EK, because the math does not work and we will not sell a feature that we know will fail. Users on titles that require TPM attestation (Valorant, League of Legends since May 2024 on Windows 11) will not find a KyTech offering, and that is the honest answer.

If the HWID spoofer beta is what brought you here, the Apex product page has the current build notes and the list of tested motherboard vendors. See the full product lineup for current availability.