Licensing and binary protection for Windows software.
Atlas Authenticator locks license keys and accounts to the buyer’s PC and keeps checking while your app runs. Atlas Obfuscator turns the compiled .exe or .dll into a file that is hard to read.
Free plan, no card. SDKs for C++, JavaScript and Python.
- Atlas AuthenticatorSDK for C++, JavaScript and Python
The most complete authentication platform there is: six enforcement layers, a sixteen-source hardware fingerprint, a custom virtual machine running tamper checks inside the client itself. Twelve checks on every login. One ban holds for good. Live control over every session.
- Atlas ObfuscatorWindows .exe and .dll, x64 and x86. No SDK
A full binary-protection engine: tamper folds straight into the decryption key, nested VMs run two disjoint instruction sets, handlers decrypt only at the instant they run. A debugger derives the wrong key and quietly fails. Dumps recover ciphertext, never a runnable image.
- Sixteen-source hardware fingerprint
- Patch it and the key breaks
- Two virtual machines, nested
- A new key on every request
- Code re-keys itself every call
- Nothing readable to dump, ever
- A debugger derives the wrong key
- Built to outlast cracking tools
- One ban covers key, IP and PC
- Message, disconnect or kill a session live
- Two threads watch each other for tampering
- Checked for tampering every few seconds
- Catches hardware breakpoints mid-session
- Catches injected code mid-session
- No readable strings in the file
- Never fully decrypted, even paused
- Roll out an update to 10% first
- A fake server can’t fake the reply
- Every packet checked, no timing leaks
- Login floods stopped before they start
- Credits and features on one license
- Block by country, VPN or device count
- No hookable system calls
- No function names to find in the file
- Invisible to debugger thread lists
- A patched login token still fails
- Session id stays encrypted in memory
- Out-of-bounds reads crash, not leak
What it enforces
Six layers. A request that fails one fails the whole login. Every request runs the same stack in the same order, cheapest check first.
- 01
Transport
Every packet carries a fresh nonce and a keyed tag, every request derives its own keys from the machine and the build, and a proof-of-work gate runs before any license logic. A replayed request has no window to land in.
BeatsInterception, replay, floods - 02
Identity
Sixteen hardware sources, each kept on its own, so changing one never clears a ban on the rest.
BeatsSpoofing one component - 03
Session
The session id is kept encrypted in memory. The auth token is derived from the live session and the machine, then split across four separate fragments that all have to be right at once. Flip one value and nothing opens.
BeatsCheat Engine, boolean patching - 04
Client integrity
Debugger, hook, injection and hardware-breakpoint detection, import-table and code checks, threads hidden from debuggers, two threads watching each other. All of it runs for the life of the process, not only at login.
Beatsx64dbg, WinDbg, IDA, Frida - 05
Server proof
Every approval is signed over the client’s own nonce, the license and the session. A fake server cannot say yes, and the client exits on a missing signature, with no fallback and no retry.
BeatsNulled and cracked servers - 06
Server rules
Executable-hash whitelist, VPN and proxy checks, per-IP rate limits and session caps, served from an in-memory cache the dashboard invalidates the instant you change anything.
BeatsPatched builds, abuse, sharing
Hardware identity
Spoof one. We catch the rest. A fingerprint is sixteen values, each kept on its own. Change one component and the fingerprint shifts, but every other component is still on the ban list.
Banned machine recognized.
Choose any component to change it. Values here are placeholders.
One ban covers the license, the hardware, the IP and, for accounts, the email address.
Rules engine
Banned machines, patched builds and VPNs never reach the license check. Cheapest checks first, and the first one that trips ends the request. Country rules, seat caps and hardware locks follow.
Every denial is logged with the rule that caused it.
- 01Cracked builds die at the door
- The server checks the SHA-256 of the connecting executable against your whitelist before a session exists. A patched, repacked or cracked copy has a different hash and never gets one.
- 02Rules that act on their own
- A rule trips and Atlas bans the license, the hardware and the IP together, and can queue an email or post to your Discord. Nobody has to be watching.
- 03A leaked key stops being shared
- Cap how many machines can run one license at once. The second copy is refused the moment it connects.
- 04Datacenter and VPN traffic refused
- Each address is checked for proxy and VPN use and the verdict is cached for up to six hours, so real users pay nothing for it.
- 05Limits you set per app
- Hardware and address binding, tight or loose, and country allow and block lists.
Server-side secrets
Secrets stay on the server. Keep anything valuable in server variables and files. They are served only to a live, verified session, so a cracked client still has nothing to read.
std::string url = Atlas::Variables::Fetch("update_url");auto blob = Atlas::Network::Download(2);
- Variables
- Named values you set per app in the dashboard, fetched with one call after sign-in.
- Files
- Upload to a slot, download at runtime. The bytes go only to a signed-in session.
- Tied to the session
- A copy of your client with no valid session gets nothing back, however it was patched.
Updates
Ship a patch. Everyone runs it. Builds you have not authorized cannot sign in, so an old or modified copy stops working when you promote the next one.
- 01
Upload
Add the new build in the dashboard. Atlas computes its SHA-256.
- 02
Promote
Make it the current version, or pause one that should stop reaching users.
- 03
Clients update
Running clients fetch it at Startup, verify the SHA-256, swap the executable and relaunch.
- 04
The library updates too
The Atlas library can swap its own DLL under a live JavaScript or Python host, so a fix to the library reaches running apps without a manual step.
Defense suites
Six suites, each aimed at one class of tool. Pick a suite to see the tools it is built against, what it does to them and why it holds.
Opened in a decompiler, it yields nothing usable.
- Built against
- IDA Pro / Hex-Rays
- Ghidra
- Binary Ninja
- radare2
- Tigress
- Triton
- What it stops
IDA Pro / Ghidra initial autoanalysis - the pass that recovers functions and cross-references the instant a binary is loaded.
How it worksThe file is seeded with tens of thousands of look-alike function starts that lead nowhere, so the analyzer’s work queue grows faster than it can clear.
Why it holdsDisabling autoanalysis means analyzing by hand - the work the tool exists to remove. The cost is paid by the analyst, every time.
Evidence
Real captures, not mockups. Four WinDbg sessions of protected builds, verbatim from the debugger.
A real protected build, stopped at its own entry point under WinDbg. The byte at RIP is 4F - an invalid opcode (???). The .text section is AES-128-CTR ciphertext until the instant it executes, so there is no valid instruction stream to disassemble, and the return chain past BaseThreadInitThunk dissolves into non-symbolic noise.
(7904.8330): Access violation - code c0000005 (!!! second chance !!!)
triage_code_encrypt+0x1284
- ???
- The debugger found no valid instruction at that address.
- noise
- A stack frame that resolves to no module and no symbol.
Integration
Two calls to integrate. Full control after. Set the API key, call Startup, call Login. The SDK runs the handshake, the hardware fingerprint and a signed heartbeat on its own threads.
- Licenses or accounts
- License keys, or usernames and passwords locked to the machine. Sellers choose per app.
- Hardware binding
- The first login binds to hardware: sixteen identifiers, each kept separately.
- Emailed codes
- Emailed 8-digit sign-in codes on the policy you pick, from never to every sign-in.
One SDK in three languages for Windows x64. C++ static library and header, @atlassecurity/auth on npm, atlas-auth on PyPI.
Atlas::API_KEY = "YOUR_API_KEY";Atlas::Startup();if (!Atlas::License::Login(key)) return 1;// a signed heartbeat now runs in the backgroundAtlas::Network::CheckAuthentication();
And this is what you watch it from.
| User / License | IP | Location | HWID | Last seen | Actions |
|---|---|---|---|---|---|
maya.ktrusted [email protected] | 1s ago | Kill | |||
ATLAS-7F2C-91B8-E04D | 3s ago | Kill | |||
noah.r | 2s ago | Kill | |||
ATLAS-2B90-C5E1-7A36 | 4s ago | Kill |
Pricing
Start free. Scale when you ship. Both products have a free tier. Premium lifts the volume limits and unlocks no features.
Swipe to compare plans
Pay with PayPal, or BTC, ETH, LTC, BNB, USDT and USDC. The price shown is the price charged.
Compare every featureQuestions
What buyers ask before they ship.
Windows x64 and the Authenticator SDK in C++, JavaScript or Python. C++ links a static library and a header. JavaScript loads the DLL through @atlassecurity/auth on npm, and Python through atlas-auth on PyPI. Create an app in the dashboard, copy its API key, then call Startup and Login.
Not answered here?
The docs cover every call and status code. For anything else, write to the team or ask in the Discord.
Join the Atlas Discord
Ask questions, get help setting up your app, and see every update first.
931 members70 online
Ship software that stays yours.
Free to start: three applications, 300 users per app, and the full protection engine. Create an app, copy its API key and call Startup.
- Free to start, no card
- SDK for C++, JavaScript and Python
- Windows x64