Executable Hash Whitelist

Why it exists

Once a binary is in the wild, attackers will patch it. The whitelist rejects any build whose SHA-256 isn't on the list - no license, no account, no path forward. The check happens during the handshake, so a patched binary never reaches the post-auth code path.

How to use it

1. Build a release.
2. Open Dashboard → Settings → Builds and choose Add hash.
3. Drop the .exe on From binaries. The dashboard computes the SHA-256 in your browser - the file never leaves it - and authorizes it. Drop several at once to authorize a batch. Building in CI? Choose Paste hash and paste the value from:
   Terminal

   Compute the SHA-256

   # Compute the SHA-256 of a built binary on Windows.
   Get-FileHash "C:\Path\To\myapp.exe" -Algorithm SHA256 | Select-Object Hash

4. Ship the binary. Whitelisted builds authenticate; everything else is dropped.

What gets hashed

The SDK hashes the file the OS sees as the current process - GetModuleFileNameA(NULL). Under C++ that's your .exe, so there's nothing to do. Under Node and Python it's the host interpreter unless you package the app into a single .exe: pkg, electron-packager and PyInstaller each produce one, and that .exe is what gets hashed. C++ never needs to do anything.

// C++ - Atlas computes the hash from your .exe automatically on Startup.
// Whatever Atlas reads becomes the apphash that travels with every request.
// No SDK call needed. Rebuilds produce new hashes - add each one.

Atlas.dll also exports Atlas_SetAppHash(hex64) and Atlas_SetAppHashPath(path) for hosts that call the C ABI directly. The JS and Python bindings don't wrap them. Atlas_SetAppHash takes exactly 64 lowercase hex chars - empty, uppercase or wrong-length input is rejected, so there's no bypass path that nulls the hash and skips server whitelisting. Both setters lock after Startup(). See Runtime & Build.

Per-binding gotchas

• JS / Electron: whitelist the hash of the packaged .exe from electron-packager, not node.exe or Electron.exe. The DLL is copied into process.resourcesPath at build time. The hash covers the exe, not app.asar or your JavaScript.
• Python / PyInstaller: whitelist the hash of the single-file .exe PyInstaller produces, not python.exe.
• C++: the hash is of your own .exe - whatever Atlas's startup fingerprint reads. Rebuilds produce new hashes; add each one before cutting a release.

Rotation

One hash per release is the convention. Old hashes are not auto-revoked - keep them on the list until you've confirmed the migration. Then remove them from the dashboard and the server stops accepting them.