Official LibreAuth SDKs handle wire auth, nonce, and signatures automatically. Custom clients (raw HTTP or third-party forks) must implement each requirement manually — see Client Integration.
Temporary maintenance mode. Blocks new init calls while keeping the app record and settings intact. Different from App Status — paused apps show a user-facing maintenance message.
When to enable
Deploying updates, database maintenance, or pausing sales temporarily. Toggle off when ready to accept logins again.
Client requirements
No client changes — users see: Application is currently paused…
Existing sessions are not automatically killed — combine with session kill if needed.
Binds each user account to a hardware ID. First successful login stores the HWID — subsequent logins from a different machine are rejected until reset.
When to enable
Desktop tools, licensed game utilities, or any license you want locked to one PC. Always pair with a real HWID generator in your client.
Client requirements
Send the same hwid string on login, license, register, and check.
Validates client executable MD5 and/or SHA-256 against a server whitelist on init and check. Soft when whitelist is empty; hard kill when ≥1 entry. Pass if any sent candidate matches the whitelist (MD5-only clients still work when the list also has SHA-256). Prefer sending both. Matched hash binds to the session when Redis is available.
When to enable
Native C++ / C# builds distributed as binaries. Drag-drop the final build after obfuscation/seal so both SHA256 and MD5 land on the whitelist.
Client requirements
Send MD5 as hash and SHA-256 as sha256 on init/check (either is enough if whitelisted).
C++/C#: ExeMd5Hex() + ExeSha256Hex() — compute after SecureLoader seal / final obfuscation.
Panel → Hash Management: drag-drop adds both hashes; or Seller API addhash.
On reject: Panel → Recent rejected hashes (MD5 or SHA256) — add to whitelist.
Errors
E04 / hash_rejectHash required — send hash/sha256 on init
E05 / hash_rejectNo sent candidate matches the whitelist
E48E0A5Not a hash error — Invalid license key after init succeeded
When Hash Check rejects a client with a clear crack signal, ban that HWID and linked users. Reason prefix hash_auto_ban:. Does not sweep IPs (safer on shared NAT). Does not auto-ban on no_whitelist (empty whitelist = seller forgot hash). On API v2 soft init/check, does not auto-ban until the session is validated (license/login) — so a mismatch before the key prompt cannot blacklist the machine. Bans on mismatch, or hash_not_sent only when whitelist already has entries (and session is validated or hard-fail path). Default OFF.
When to enable
Production apps with Hash Check ON and MD5/SHA256 whitelist populated — crack / patched builds should not keep retrying after license.
Client requirements
No extra client work — server calls BanMachine after reject when allowed.
Pair with Hash Check + whitelist (prefer SHA256+MD5) after every release build before enabling this toggle.
Already-banned HWIDs stay banned until you unban in HWID Bans.
Errors
BlacklistedHWID banned after hash mismatch on a validated session — unban in HWID Bans if false positive (e.g. forgot to whitelist new build)
Policy flag on init. When ON, client should call type=ban (Ban / BanAsync) after Hardening trips (CE / IDA / UD / debugger / emulator / AI). Default OFF.
When to enable
Ops / native clients that run RunChecks in a loop and can report self-ban.
Client requirements
Read policy.tool_auto_ban from Init (Authority stores it).
On Hardening fail: Ban("tool:" + FailName) then exit.
Unvalidated Ops sessions may self-ban only their bound_hwid (server ignores forged HWID).
Errors
Session not boundInit first so session has bound_hwid
Master session integrity layer. Enables duplicate-request blocking, optional IP binding, HWID session lock, and Token File validation when that sub-toggle is on.
When to enable
Production apps using LibreAuth SDK or a custom client that sends consistent HWID and respects session rules. Default ON.
Client requirements
Send identical hwid on every request after login.
Do not replay captured requests in rapid succession.
Sub-toggles (Nonce Chain, Bind Session IP, Token File) only apply when Anti-Tamper is ON.
Errors
E10Session IP mismatch — Bind Session IP is on
E12Duplicate request — wait before retrying the same payload
Challenge-response chain: each API response includes a nonce. The next request must echo that exact nonce. Prevents simple request replay from packet captures.
When to enable
Custom SDKs or high-value targets. Official LibreAuth SDKs send nonce automatically. Enable only when your client implements it.
Client requirements
Store nonce from every response.
Send it as nonce on the next request (before server issues a new one).
Missing or wrong nonce → Invalid nonce / E11.
Errors
E11Send nonce from previous response on every request