Settings: Builds and updates

Only builds you authorize can sign in. This page authorizes them, checks that the code running is the code you uploaded, and updates your customers to the next build.

Open it now:Settings, Builds

Why builds must be authorized

Every sign-in carries the SHA-256 hash of the program that sent it. Atlas compares it with the list on this page and refuses anything not on it. A cracked or modified copy has a different hash, and a copy built by someone else for your API key is refused too. The idea is explained in Build authorization.

Authorize a build

Press Add hash (the empty list offers Authorize your first binary). Two ways:

Drop the file. Drop one or several .exe or .dll files. Your browser works out each SHA-256 and extracts the file's code section, and sends only those two things. The file itself never leaves your computer.
Paste a hash. Paste the 64-character SHA-256 and, if you like, a label to recognise the build.

With a single file, tick Also publish as the latest version to authorize the build and make it the update for your customers in one step. It needs a version label such as 1.4.2. The choice is remembered.

Each authorized build shows its hash, its label, when it was added and a tag: Proof on file when its code is on record, or Hash only. Remove takes a build off the list; its customers are refused at their next sign-in.

Running-build proof

A hash alone is just a string: anyone holding your original file can send it from a patched program. With the code of a build on record, Atlas can also ask the running program to prove its loaded code matches. The program proves it at sign-in and, every few seconds, during the session. A changed byte of code, a replayed answer or another machine's answer all fail.

Mode	A failed proof
Off	Not checked. Only the hash decides.
Log only	Recorded as a warning in Logs. Nobody is refused. This is the default.
Enforce	Refuses the sign-in, or ends the session a few seconds later.

Only builds marked Proof on file are judged. To record the code of an older build, drop its .exe in again.
A program that rewrites its own code at start, which includes one packed by the Atlas Obfuscator, does not match its file. Keep those applications on Log only.
JavaScript and Python programs hash their script or app archive, not an executable, so they have no code to prove and are never judged.
It needs an SDK version that includes the feature; a program built with an older one answers nothing and is only counted.

This raises the cost of patching a build. It cannot stop someone who controls the whole machine from answering from a clean copy, so keep valuable things on the server, in variables and files.

Versions and updates

Versions lists the builds you uploaded for update. Upload new version takes a build, a version label and the filename the updater gives it on the customer's disk. One upload is one version, and an uploaded version is authorized to sign in automatically, so you never add its hash twice.

Control	What it does
Promote to latest	Makes this version the one older machines update to the next time they start.
Who gets it first	A share of machines from 0 to 100%. Each machine sits in a fixed group chosen from its hardware ID, so it always gets the same answer. Raise the share as you gain confidence.
Mandatory	Every older machine updates at its next start, whatever the share says, and older builds are refused until they do. Use it for security fixes.
Roll back	Promote an older version. A rollback ignores the share and is mandatory, so everyone moves to it, including machines on the newer build.
Deauthorize	Stops a version from signing in. Do this to a bad build after you roll back.
Seen, 7 d	How many different machines signed in on that build in the last 7 days.

Every change is written to the version history. How the program updates itself, including what the customer sees, is in Updates.

Was this page useful?