How to verify a spoof actually applied
Read the identifiers before and after, then compare the two lists instead of trusting a success dialog. Includes what a partial spoof looks like and read-only Windows commands.
Short answer
Read the identifiers before you spoof and again afterwards, then compare the lists, since a success dialog is not evidence. If only some values changed, the spoof is partial, and one unchanged serial can be enough to link the machine to its old identity.
On this page9
- Why is a success message not enough?
- How to compare before and after
- Read-only commands to check your identifiers
- What does your comparison mean?
- Which values should stay the same?
- What causes a partial spoof?
- What to check before you launch anything
- Is a clean comparison a safety guarantee?
- Common questions about verification
Why is a success message not enough?
A spoofer's success message only reports that its own routine returned without error, not what your machine now tells other software. The two can differ, because a driver may have failed to load or the tool may not cover that field. A service may also have cached the old value already, or a reboot may have reverted a per-boot change. All four produce a cheerful dialog and an unchanged identifier. The only evidence that counts is a value you read yourself, before and after, through the same path other software uses.
How to compare before and after
One run takes five minutes and turns a guess into a fact. Do it on the machine being spoofed, in an elevated prompt, with the game and every launcher closed.
- Boot the machine cleanly, before running anything else
- Run the read-only commands below and save the output to a file named for the moment it was taken
- Run your spoofer as its documentation instructs, changing nothing else
- Run exactly the same commands again and save the output to a second file
- Compare the two files line by line and confirm which fields changed and which did not
- Check that the changed values look plausible rather than random. A board serial should follow the maker's own format, and a disk serial should match that manufacturer's style
- Only then start the launcher and the game
Read-only commands to check your identifiers
Every command below only reads state: none of them modify an identifier, a registry hive or firmware. Save everything above the final fc line as inspect.cmd. Run it before spoofing and again after, then compare the two outputs with that fc line.
REM Save a snapshot. Run the same block again after spoofing into after.txt
REM inspect.cmd > before.txt then inspect.cmd > after.txt
REM Motherboard
powershell -c "Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer, Product, Version, SerialNumber"
REM System UUID and the OEM identifying number
powershell -c "Get-CimInstance Win32_ComputerSystemProduct | Select-Object Name, Vendor, UUID, IdentifyingNumber"
REM BIOS
powershell -c "Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, SerialNumber, ReleaseDate"
REM Physical disks and their serials
powershell -c "Get-CimInstance Win32_DiskDrive | Select-Object Index, Model, InterfaceType, SerialNumber"
REM Volume identifiers
powershell -c "Get-Volume | Select-Object DriveLetter, FileSystemLabel, UniqueId"
vol C:
REM MAC addresses for every adapter, not just the one you are using
getmac /v /fo list
powershell -c "Get-CimInstance Win32_NetworkAdapter -Filter 'PhysicalAdapter=true' | Select-Object Name, MACAddress"
REM TPM presence and manufacturer, read-only
powershell -c "Get-CimInstance -Namespace root\CIMV2\Security\MicrosoftTpm -ClassName Win32_Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, SpecVersion, IsEnabled_InitialValue"
REM GPU, and the vendor UUID where the vendor tooling exposes one
powershell -c "Get-CimInstance Win32_VideoController | Select-Object Name, PNPDeviceID, DriverVersion"
nvidia-smi -L
REM The registry MachineGuid - a query, which only reads
reg query "HKLM\SOFTWARE\Microsoft\Cryptography" /v MachineGuid
REM Compare the two snapshots
fc before.txt after.txtWhat does your comparison mean?
Find the row that matches your two files. A partial spoof is the dangerous case, because the tool will still have reported success.
| What the comparison shows | What it means | What to do |
|---|---|---|
| Every identifier the tool claims to cover has changed, and the new values look plausible | The spoof applied as intended | Proceed with the rest of your sequence. Keep both files as a reference for next time |
| Some fields changed, others are identical to the before file | A partial spoof. One unchanged serial can be enough to match the previous set | Do not launch anything. Re-read the tool's documentation on what it covers, and raise the uncovered fields with its support |
| Nothing changed at all | The tool did not take effect: it needed elevation, a driver failed to load, or something blocked it | Reboot, run it again on a clean boot with nothing else started, and verify again |
| Values changed, then reverted after a reboot | A per-boot spoof behaving exactly as designed | Treat boot, spoof, verify as one routine every session |
| Values changed but look implausible or contradictory | Inconsistent identifiers are their own signal, and more distinctive than the originals | Use the tool's own generated profiles rather than arbitrary values, and ask its support what the fields should look like |
| Values change on every read of the same command | Something is generating a fresh answer per call | Stop and ask, because this is not the behaviour software reading these identifiers expects and it is highly visible |
Info
Which values should stay the same?
Verification is about the fields your tool claims to cover, not about getting as many differences as possible. Your Windows build, CPU model, GPU model and installed RAM are expected to stay the same. A tool that reports a different CPU model from the chip in the socket has produced an inconsistency, not an improvement. Do not expect the TPM manufacturer line to change either: you read it to learn whether a TPM is present and enabled at all.
What causes a partial spoof?
A partial spoof usually has one of four causes. The first is that the tool does not cover that identifier and never claimed to. The second is that the value is read through a path the tool does not sit on, which is common for GPU identifiers. The third is a service that started before the spoof and cached the old value. The fourth is a reboot after which a per-boot change quietly went away. All four are visible in a before and after comparison but invisible in a success dialog.
What to check before you launch anything
- The before snapshot was taken on a clean boot, before any launcher was started
- The after snapshot was taken with exactly the same commands
- Every field the tool claims to cover shows a different value
- The new values look plausible for real hardware, not like random strings
- Nothing that should stay constant, such as the Windows build, CPU model or RAM size, has changed
- All network adapters were checked, not only the one currently connected
- You know whether your spoof survives a reboot, and you have tested that by rebooting and reading the values again
- Both files are saved somewhere you can find them next time
Warning
Is a clean comparison a safety guarantee?
No. A clean comparison proves that your machine now reports different values. It does not prove that no identifier remains, that a vendor cannot correlate you another way, or that a ban will not follow. It checks that the tool did what it said, which is the only part of this you can establish for yourself. That check is worth doing precisely because everything after it is outside your control.
Common questions about verification
Do these commands need administrator rights?
Most of the CIM queries work as a standard user, and all of them only read. Run them in an elevated prompt anyway, so the before and after snapshots are taken under identical conditions.
Can I use wmic instead of Get-CimInstance?
The old wmic equivalents return the same fields, but wmic is deprecated and missing on current Windows builds. Use the CIM commands instead, so the same block keeps working.
The tool says success but nothing changed. Which one is right?
Your comparison is right, because a dialog reports the routine's own return value, not what your machine tells other software. Reboot, run the tool on a clean boot, and verify again before launching anything.
Should I verify every session?
Verify every session if your spoof is per-boot, since it reverts on restart. For a permanent spoof, verify after it is applied and again after any Windows update or hardware change.
Is there a single command that shows my HWID?
No, because there is no single HWID. You need to read the whole set, which is why the inspection commands are a list rather than one line.
Sources
The commands are standard Windows ones and the routine is the team's own. Nothing published describes what a partial spoof looks like.
Read next
Still stuck? Open a ticket on Discord
All guides