HWID-Guard
Quickstart

First check in five minutes.

What you embed, what stays on your server, and the two lines that make it work. Read once, ship today.

The mental model: your client embeds a collector (from the SDK) that reads device signals and hashes them. Your server holds the API key and calls /v1/check. Only hashes ever leave the machine — the raw hardware ID never does.
Who blocks?

The SDK never blocks by itself — it's a messenger. The verdict comes back to your server, and your login code is the door. That's deliberate: a patched client can't skip a check that lives where the attacker can't reach.

Player's app SDK: collects & hashes Your server the door HWID-Guard API weighs & decides 1 · login + hashed signals 2 · POST /v1/check 3 · verdict ALLOW login completes — in BAN refused at the door 4 · the block happens here in your login — never in the SDK
1 Before you start

You'll need

An API key (we send it, or self-serve in the panel). Use a check-scope key — never ban in a distributed client.
The SDK for your stack: .NET · Unity · C++ · TypeScript · Python · Electron · FiveM — or the zero-code gateway.
Five minutes.
2 Collect & check

Two lines: gather the device, ask for a verdict

The collector reads the hardware signals and hashes them. You send that to /v1/check. Pick your stack:

var guard = new HwidGuardClient("https://sigelis.cruxsacra.com.br", apiKey);
var r = await guard.Check(HwidCollector.Collect()); // collector = one call

if (!r.IsAllowed)
  BlockLogin(r.Reason); // BAN / DENY / REVIEW
from hwidguard import Client, collect

guard = Client("https://sigelis.cruxsacra.com.br", api_key)
r = guard.check(collect())
if not r.is_allowed:
  block_login(r.reason) # BAN / DENY / REVIEW
import { HwidGuard, collect } from "@hwidguard/sdk";

const guard = new HwidGuard("https://sigelis.cruxsacra.com.br", apiKey);
const r = await guard.check(await collect());
if (!r.isAllowed) blockLogin(r.reason);
# from YOUR server (the key lives here, not in the client)
curl https://sigelis.cruxsacra.com.br/v1/check \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"identifiers":[{"type":"smbios_uuid","hash":"a1f…"}]}'
# -> {"verdict":"ALLOW"|"BAN"|"DENY"|"REVIEW", ...}
# run the gateway in front of your app — zero client code
HWID_GUARD_URL=https://sigelis.cruxsacra.com.br
HWID_GUARD_GATEWAY_KEY=hg_xxx # the key stays in the gateway
HWID_GUARD_UPSTREAM=http://127.0.0.1:9000 # your app
HWID_GUARD_MODE=monitor # observe before blocking
3 Handle the verdict

Three outcomes

ALLOW

Clean device. Let the login through.

BAN

Banned device. Block it — even inside a VM.

REVIEW

Flagged, not blocked. Your call / step-up.

Start in monitor mode. Run it observe-only first — you get the verdict in your logs (X-HWID-Monitor-Verdict) but nothing is blocked. Watch who would be caught, then flip to enforce when you're confident. Zero risk to test.
4 Ban a device

From your moderation tool — server-side

When a moderator flags a cheater, ban the device from your backend with a separate ban-scope key — never the client's check key. After that, every new account on that hardware gets BAN at /v1/check.

curl https://sigelis.cruxsacra.com.br/v1/bans \
  -H "Authorization: Bearer $BAN_KEY" \
  -d '{"device_id":"…","reason":"cheating"}'
5 Keep it safe

The rules that protect you

Key stays server-side. A key embedded in a distributed client (game/app) gets extracted — call /v1/check from your server or the gateway.
check-scope for the client path, ban-scope only on your backend.
Only hashes leave the machine. The collector never sends the raw serial/ID.

Stuck? We'll wire it up with you.

Pilot support is hands-on — send a message and we'll get your first check live together.