Security Model

What Atlas protects

Atlas is built for the case where users actively try to bypass the licensing on a paid Windows binary. The threat is:

• Patch the .exe to skip the auth check.
• Patch the .exe to swap in a leaked license key.
• Hook recv / send to forge server replies.
• Replace the entire .exe with a stripped binary.
• Run the binary under a debugger, dump memory, lift the session key.
• Replay a captured successful handshake to extend a session.
• Run a stripped null server locally and feed it forged payloads.

Every layer below is in service of making each of those fail - or at minimum, expensive.

The seven layers

1. Static Atlas Auth.lib linking (C++). The library is in your address space at compile time. There's no sidecar to rename or replace. JS / Python ship Atlas.dll as a sidecar: one file next to your binding.
2. Per-process X25519 ECDH handshake. A fresh symmetric key every session. The session key is derived with the HWID mixed in - a stolen session token doesn't work from a different machine.
3. Ed25519-pinned server keys. Three keys are pinned inside the SDK (primary, backup, emergency). The server signs its handshake reply with one of them. A nulled local server can't produce a valid signature. Verified locally before any application data is decrypted.
4. Per-request nonce. Every message carries a fresh nonce. Replays are dropped.
5. Continuous heartbeat re-authentication. License sessions use a persistent socket; account sessions poll every 5 s. Every check the client passed at login runs again, on a loop.
6. Runtime binary verification. The DLL continuously re-hashes the loaded .exe. If anything in the executable image changes - inline hook, code patch, injected module - the session ends.
7. Network-family import scan. The DLL watches the ws2_32 / wininet / winhttp imports for inline hooks. A hooked recv that returns forged data is treated the same way as a patched .exe.

The debugger check

Atlas::Startup() refuses to run with a debugger attached, treats it as tampering, ends the process shortly after, and can report a ban against the license or HWID. This is the most common integration trip - and the easiest layer for an attacker to remove.

It's also the most replaceable layer. Atlas Auth.lib has multiple independent integrity checks; removing the debugger check still leaves the import scan, the binary hash, and the signed-handshake verification in place. The cost of patching out one check is the work of finding the others - and Atlas is built so finding them costs real time.

// Atlas refuses to run under a debugger. Patching out the check is the
// first thing any reverse engineer does - but the SDK has multiple
// integrity checks, not one. Removing the debugger check leaves the
// import-scan, hash-whitelist, and signed-server-handshake still in play.

What Atlas deliberately doesn't defend

Atlas protects a software license - not the contents of the binary, and not the user's machine. Concretely:

• The application's own code. Once the binary is authenticated, Atlas doesn't try to obfuscate the rest of the code. That's the sibling product, Atlas Obfuscator's job.
• The user's data. Atlas doesn't encrypt anything on disk. The keys, files, and config your app stores are your problem.
• Reverse engineering for compatibility. A determined attacker with enough time can produce a clean-room compatible client. Atlas raises the cost of that work - it doesn't make it impossible.
• The script code you ship (JavaScript, Python). Atlas hashes and watches the native process. Script files and app.asar sit outside that hash. Ship script apps as a packaged .exe, and protect the script itself with a bundler or obfuscator.
• Anything outside Windows x64. Atlas supports native Windows x64 applications only. WSL, Docker, macOS, and Linux aren't supported (per the JS README).

What the dashboard can do

The dashboard isn't a marketing surface - it's the kill switch. Once a session is live:

• Message - push a one-shot note to the running binary. The next heartbeat delivers it.
• Kill - flip the session row. The binary ends within a few seconds.
• Ban - mark the user record (and/or HWID, and/or IP). Permanent unless created with a duration; lift it from Bans.

See Sessions & Live Control for the full surface.