Custom KeyAuth engine
A from-scratch, self-hosted licensing and authentication backend, plus a client SDK. Written to be stronger than KeyAuth in the specific places KeyAuth historically falls down: server-authoritative trust, signed replay-proof responses, and no recoverable secrets in the client binary. In active development.
Nothing is uncrackable. That is not the goal.
Any client that runs on the user's machine can, in principle, be disassembled and patched. The realistic and achievable goal, and the one that actually matters, is to make a cracked client useless: keep the valuable logic and data on the server, and release it only to a properly authenticated live session.
That framing decides the whole architecture. The client is not trusted, it never was, and it never will be. Every design choice below flows from that.
A short list of well-known failure modes.
KeyAuth has been cracked repeatedly and the cracks tend to share shape: a client-side if (success) that a patcher flips to true, an API secret extractable from the binary, and responses that are not bound to a session or a nonce, so a locally-run "fake server" replays a canned success payload and the client accepts it.
Each of those is a specific mistake with a specific fix. This engine fixes all of them by construction, then documents its remaining honest limits instead of pretending they do not exist.
The four properties, in plain terms.
- Server-authoritative. The client never makes the final security decision. A patched client that skips the check gains nothing, because what it is trying to unlock is delivered by the server, only to an authenticated session.
- No recoverable secrets in the client. The binary ships a public verification key and a pinned certificate. There is no private key, no API secret, no symmetric master key embedded in the client to extract.
- Signed, replay-proof responses. Every server response is Ed25519-signed over a server-issued nonce, a timestamp, and a binding to the request that triggered it. A captured "valid" response cannot be replayed. A fake local server cannot forge one without the private key.
- Per-session payload encryption. Protected resources and configuration are delivered encrypted under a key derived from the live handshake. Never stored on disk in usable form, never the same twice.
Signed envelope, bound to this exchange.
Every response from the server rides inside the same envelope shape. The nonce is issued by the server at handshake time, so the client cannot pre-request signatures for later replay. The request binding is a hash of the exact request that triggered this response, so a signed "success" for one call cannot be pasted onto another.
The signature is Ed25519 over the concatenation of every field in the envelope, including the payload. Verification is one call on the client, using the pinned public key.
// Wire shape (Go server, C++ SDK deserialises the same thing) type Envelope struct { Version uint32 // wire version, monotonically bumps Nonce [32]byte // server-issued at handshake, one-shot IssuedAt int64 // unix ms, checked against skew window RequestHash [32]byte // SHA-256 of the client's request bytes Payload []byte // AEAD-encrypted, session-keyed Signature [64]byte // Ed25519 over all fields above }
Treated as the crown jewel.
Parameterised queries, hashed secrets, least-privilege service accounts, audit logging, structured key rotation, rate limiting on every endpoint that touches a credential. The server is the only piece that can leak the whole system, so it is the piece that gets reviewed the hardest.
The full threat model, including the parts this design intentionally does not defend against, is documented alongside the code. That document is what any real evaluator wants first, and it is written to be read by one.
"The interesting question is never 'is this uncrackable.' It is 'what does a crack of this actually get you.' If the answer is a useless client, the system has done its job."
Server crypto and SDK, next is the admin panel.
Current: Ed25519 signing, session key derivation, nonce store with replay protection, password and HWID handling on the server; C++ SDK on TweetNaCl doing the client side of the handshake. All covered by unit tests.
Next: the admin surface for managing keys, subscriptions, HWID resets, and ban list, then the hardened client-side counter-measures (integrity self-check, anti-debug, obfuscation) framed honestly as cost-raising rather than as guarantees. Source and design docs available on request.