Removing the check should not unlock anything.
Most licensing asks the server whether a key is valid and trusts the answer. That answer is one boolean, and it is exactly what gets patched out. KeyAuth keeps your DLL, driver or asset on the server and hands it over only after a key authenticates.
- AES-256-GCM
- sealed envelopes
- C++17
- zero dependency SDK
- 0 KB
- payload in your binary
keyauth::Client client(keyauth_config::make());
client.initialize();
client.login(userKey);
// the payload arrives with the login
for (const auto& f : client.files()) {
std::vector<std::uint8_t> payload;
client.download(f.key, payload);
}
// decrypted · inflated · SHA-256 verifiedHow it works
Four steps, and your client no longer carries anything worth stealing.
Create an application
You get a public id and a 32 byte secret. Every key, file and log belongs to it alone.
Upload a release
Group your files under a version and give each one a JSON key such as core or driver.
Issue keys
Generated from a mask you design, with expiry, level, device and login limits.
Ship the SDK
Download a C++ SDK already carrying your credentials. Your loader stays a few lines long.
What you get
Versioned releases
Swap the binary behind a JSON key and every client picks it up on the next login. Keep the old release to roll back.
Hardware locking
Bind keys to machines using CPU, MachineGuid, volume serial or the computer name, with a device limit you control.
Anti sharing
Concurrent session caps, login budgets, device limits and IP or hardware blacklists checked on every request.
Sealed file delivery
Compressed, split into chunks, each chunk with its own AEAD tag bound to its index. Small files ride along with the login.
Encrypted variables
Keep endpoints and tokens out of your binary and change them without shipping a new build.
Logs and audit trail
Every client action and every dashboard action, including key reveals and secret rotations.
Nothing usable crosses the wire
One endpoint, one method, one envelope shape. The action name lives inside the ciphertext, so an observer cannot tell a login from a heartbeat. Encryption keys are derived per message with HKDF and are never transmitted.
- Responses are bound to the request that asked for them, so a captured response cannot be reused.
- Requests and responses use separate key directions, so neither can be replayed as the other.
- Nonce cache, timestamp window and layered rate limits.
- Keys are stored as an HMAC lookup plus ciphertext. No column holds a usable key.
salt = SHA-256("KA1" 0 app 0 sid 0 nonce 0 binding)
encKey = HKDF-SHA256(secret, salt, "KA1|c2s|enc", 32)
macKey = HKDF-SHA256(secret, salt, "KA1|c2s|mac", 32)
ct,tag = AES-256-GCM(encKey, iv, payload, aad)
sig = HMAC-SHA256(macKey, aad + iv + ct)What this cannot do
Two limits no product page usually mentions. You should know both before you build on this.
The secret inside your binary is recoverable
Your client signs requests, so it has to hold the application secret. The SDK masks it with a fresh XOR pad on every download, which defeats a strings dump, but a determined reverse engineer will find it. No client side scheme avoids this.
So enforcement lives on the server: bans, device limits, concurrency caps, rate limits and short session lifetimes. If a secret leaks, rotate it and ship a rebuilt loader.
A CPU hardware id is not per machine
CPUID reports the processor model, not an individual chip; per chip serials were removed after the Pentium III. Two customers with the same CPU produce the same hardware id, so a device limit cannot separate them.
So enable MachineGuid or the volume serial when you need a real per installation lock. Every source is a switch you control.
This design does not try to make your binary un-crackable, because that is not achievable. It makes cracking pointless by keeping the valuable part on the server: an attacker who fully reverses your loader still needs a live, unbanned key to obtain the payload, and every request is logged against that key.
Run it on your own server
PHP 8.3, MySQL and a document root. No third party service sees your keys, your files or your customers.