Security Architecture
AuthlyX is built so that authentication and software protection work as one. Version control, hash validation, replay defense, signed responses, and hardware locking each cover a different angle � and together they make it genuinely difficult to bypass your access controls.
What the SDK Handles
Authentication is only part of what the SDK does. Before it ever sends a request, it checks the environment your software is running in. Debuggers, tampered DNS, and intercepting proxies are dealt with at the SDK level � not left for you to handle manually.
On Windows, the SDK checks whether a debugger is attached to the process at initialization. If one is detected, the process terminates immediately. This applies to both user-mode debuggers and system-level debugger presence checks via the Windows API. You can disable this during local development using the antiDebug: false option.
Before every request, the SDK resolves authly.cc via DNS and checks whether the returned address is a private or loopback IP. If it is, the process exits. This prevents local hosts file manipulation and DNS redirection attacks that would route SDK traffic to a fake server.
The SDK pins the TLS certificate for authly.cc. Connections that present an unexpected certificate are rejected outright, regardless of whether the certificate is otherwise trusted by the OS. This blocks man-in-the-middle proxies even when the attacker has installed a root CA.
SDK logs are written to the console only � nothing is written to disk or stored on the machine. When logging is enabled, sensitive fields like session_id, secret, password, license_key, hwid, and signature headers are automatically stripped before output. Credentials never appear in plaintext anywhere, even in debug mode.
After a successful login, the SDK starts a background timer that re-runs the debugger detection check every 60 seconds. A user cannot simply attach a debugger after startup and stay connected � the check runs for the entire lifetime of the process.
Immediately after a successful login or license activation, the SDK calls the blacklist endpoint to check both the hardware ID and IP address. If either is flagged, the SDK terminates the process. This runs automatically � you do not need to call it manually, though a public CheckBlacklist() method is available if you want to check on demand.
Replay Defense & Signed Responses v2 only
The v2 API adds a second layer of transport security on top of TLS. Every request the SDK sends includes three pieces of metadata that the server validates before processing anything.
request_id
A unique identifier generated per request. The server records it and rejects any duplicate that arrives within a time window. Even if a request is captured in transit, replaying it will be denied.
nonce
A cryptographically random value attached to every request. Combined with the request ID, it ensures that no two requests share the same identity, even within the same session.
timestamp
The server checks the timestamp of every incoming request against the current server time. Requests that fall outside an acceptable clock skew window are rejected. This limits the period during which a captured request could even attempt a replay.
Sensitive responses � login, license activation, session validation, variables, and others � are signed server-side using an Ed25519 private key. The SDK verifies the signature before accepting the response. A tampered or forged response will be rejected before your code ever sees it.
Security Controls You Configure
The following protections are available per application from your dashboard. They are not on by default for every app � you decide what your application needs.
Every SDK call includes the application version you set at initialization. On the server, you configure a minimum required version per application. When a client's version falls below it, the server can respond in one of three ways:
- Block � reject the login entirely and return an update-required message. The user cannot proceed until they update.
- Remind � allow the login but return a flag the SDK surfaces as an update prompt. Use this for softer rollouts.
- Allow � temporarily permit all versions regardless. Useful when you are mid-release and do not want to break existing installs.
Version control is one of the simplest ways to force users onto patched builds. If a version of your software is compromised or cracked, you increment your minimum version and the old build stops working immediately � no binary changes required.
The SDK computes a SHA-256 hash of its own executable at startup and sends it to the server during Init(). You register approved hashes in the dashboard. If the hash does not match any approved entry, the server rejects the request.
This means only builds you explicitly approve can authenticate. A cracked, patched, or reverse-engineered binary that modifies even a single byte will have a different hash and will be blocked before it can reach the login step. When you ship a new build, add its hash and optionally retire the old one.
After login, the active session is tied to the user's hardware ID and IP address. The SDK exposes a ValidateSession() method you call manually at any point to confirm the session is still valid server-side. The recommended pattern is to call it before any sensitive operation in your application � rather than assuming the session from startup is still good hours later.
If a user gets banned, their license expires, or their subscription changes while the application is open, ValidateSession() will catch it the next time you call it. How often you call it is up to you � the method is there and ready, it is not run automatically in the background.
You can control access at the IP level per application. There are two separate lists:
- IP Blacklist � block specific addresses or ranges. Requests from blacklisted IPs are rejected regardless of credentials.
- IP Whitelist � when a whitelist is populated, only addresses on the list are allowed through. Every other IP is blocked automatically.
On higher plans, you also get VPN detection and country-level blocking. VPN detection rejects requests coming from known datacenter or proxy ranges. Country blocking lets you restrict access to specific regions entirely.
Every SDK request includes a hardware identifier � on Windows this is derived from the Security Identifier (SID) of the system, providing a stable machine fingerprint that survives most user-level changes. You can manage these at the application level:
- SID Blacklist � ban specific machines. Useful when you identify a machine being used for abuse, sharing, or cracking attempts.
- SID Whitelist � restrict your application to a closed set of machines entirely. Only whitelisted hardware can authenticate.
SID rules operate independently of user or license banning. You can block a machine even if the account itself is not banned, which is useful when the machine is the problem rather than the user.
Each user account and license has a configurable device limit. When a user attempts to log in from a new machine that would exceed their allowed device count, the login is rejected before any session is established. This prevents credential sharing across multiple machines without any action needed from the user.
For applications that need device-level authentication instead of (or in addition to) user accounts, AuthlyX provides dedicated device auth endpoints. A device can be registered, assigned a subscription tier, and authenticated independently. Device sessions follow the same hardware locking, expiry, and ban rules as user sessions.
Global Blacklist
Separate from IP and SID rules, AuthlyX maintains a global blacklist across hardware IDs and IP addresses. When a user or license logs in successfully, the SDK automatically checks this list in the background. A match terminates the process immediately � the user is not shown an error, the application just stops.
This is distinct from banning a user account. The blacklist is designed for cases where you want to block a specific machine or address permanently, across all accounts and applications on your owner ID.
Protecting Your Binary
AuthlyX handles the authentication and licensing side. What it cannot do is prevent someone from decompiling or disassembling your application itself. For .NET software in particular � C# applications built with WinForms, WPF, or console projects � the IL bytecode is straightforward to reverse without additional protection.
Pairing AuthlyX with a code protection tool is the complete setup. We recommend XerinFuscator for .NET applications. It applies obfuscation, control flow mangling, and string encryption to your compiled output, making static analysis and reverse engineering significantly more difficult. Used together, AuthlyX enforces runtime access control while XerinFuscator raises the bar on anyone trying to understand or modify the binary before it reaches that point.