Overview
A snapshot of your application.
Products
The things you sell. Each product can have several pricing tiers.
Your products
A license key always unlocks exactly one product. Any active license transitively grants the hypervisor binaries and the universal API; CS2 ESP / CS2 Radar DLLs require a license for that specific product.
Builds
The actual file customers download — your DLL or EXE. Upload a new one and it replaces the live build instantly.
Builds are encrypted the moment they arrive and never stored in the clear. Each download is re-encrypted under a one-time key, so a captured file is useless without that download's key.
Pricing tiers
How long access lasts, and what it costs. "1 Month", "Lifetime".
License keys
Generate keys to sell. A customer redeems one to unlock a product.
Issued keys
Keys are stored hashed — shown once at creation and never again.
Customers
People who redeemed a key and can log into your software.
Accounts
Each account locks to one machine on first login.
Active access
Who currently has access to what, and when it runs out.
Live sessions
Clients running right now. One session per customer — a second login kicks the first, which is how key sharing becomes visible.
Activity log
Every login, key redemption and admin action. Append-only.
Binaries
Addressable files the loader streams — each gated by an active license. Baseline binaries unlock for any active sub; product-specific binaries require that product's license.
Catalog
What /api/user/binary/<name> can serve, and the entitlement check it enforces.
Signed configs
Ed25519-signed JSON blobs clients fetch via /api/user/config.
Rotate often — a stale dump of a client's config goes 409 the next build.
Published
Newest first. One build per product is live at a time.
Watermark lookup
Paste 16 bytes from a leaked binary and resolve them back to the paying customer.
Resolve a leaked tag
Base64 or hex. The server stores every binary fetch with the per-session watermark; a leaked copy traces back to the download.
Connect your app
What your client software needs to talk to this server.
Connection details
Paste these into your client.
—
—
This is an identifier, not a password. It ships inside your binary and anyone can extract it — that is expected and safe. Your customer's password and their license key are the secrets.
—Desktop clients must send a matching version or the server refuses the login. That is your forced-update switch.
Verification keys
Bake these into your client. The Ed25519 pubkey verifies every signed
/config. The RSA pubkey wraps the per-login HWID fingerprint. Both are safe to ship.
—
—
Stratum loader snippet
Our reference loader (loader_dx11/) reads this file at build time and
XOR-obfuscates every value into the exe. The real file never ships to customers —
they just run StratumLoader.exe.
Login request
What your client sends to authenticate a customer.
How it fits together
- Application — your software business. Holds the keys. You need one.
- Product — a thing you sell. A key unlocks exactly one.
- Binary — a named file the loader can fetch. Each is gated by a product entitlement; baseline ones unlock for any active license.
- Tier — duration and price. "1 Month", "Lifetime".
- License key — what you sell. Redeemed once, then dead.
- Customer — an account in your software, locked to one machine.
- Access — what a customer unlocked, and its expiry.
- Session — a client running right now.
- Signed config — Ed25519-signed JSON clients verify at runtime. Rotate per build for staleness.
- Watermark — per-session tag baked into every binary fetch. Leaked bytes resolve back to the download.