Settings: Runtime protection
Defensive checks that run inside your program, and what each one does when it trips. They are on by default; this page only loosens one that disrupts your program.
Open it now:Settings, Runtime protection
What this page is for
Atlas runs these checks in your program's own process to catch tampering while it runs: a debugger, patched code, hooked calls, injected code. They are defensive: they inspect and answer for your program and nothing else. Every check is on by default, and for almost every program that is the right setting.
Change a check only when it disrupts or faults something your program is meant to do, such as a script engine, a plugin loader, an overlay, or a debugger during testing. Make the narrowest change that fixes it, and have a reason you can name: a relaxed check lets one kind of tampering pass unnoticed.
The checks
Nine checks, in four groups. Each one is set to End app, Report, Off after sign-in or Fully off. Every check starts on End app.
| Group | Check | What it catches | Default |
|---|---|---|---|
| Debuggers | Debugger attached | Windows and remote debugger flags, and the common ways to hide them. Full in JavaScript and Python programs; a C++ program relies on the next check. | End app |
| Hardware breakpoints | DR0 to DR3 breakpoints, which stop on a read or write without touching the code. | End app | |
| Code changes | Code integrity | The program's code changed after it loaded: NOP patches, inline hooks, code caves. | End app |
| Import table | Windows calls redirected to other code by swapping the program's import table. | End app | |
| API hooks | Hooks on the Windows functions the SDK itself calls. | End app | |
| Writable and executable memory | Memory inside the SDK's own modules that is both writable and executable. Packed programs sometimes do this legitimately. | End app | |
| Added code | New executable memory | Executable code that appears after sign-in and is not a Windows or signed library. Script engines and plugin loaders can trip it. | End app |
| Injected threads | Threads that start in memory no loaded library owns. Honest programs start threads inside a library. | End app | |
| Stalled checks | Watchdog alive | The SDK's own check threads stop answering each other. A laptop going to sleep or a frozen program lands here. | End app |
At the top of the page a bar shows the nine checks as nine segments, blue for End app, amber for Report, grey for Off after sign-in and red for Fully off, with the count of each. A relaxed check also gets a coloured mark on its row. A change appears at once and is saved in the background; if the save fails the old setting comes back and a message says so. Click a check to read what it does and what you lose by relaxing it.
End the app, report, or turn off
| Setting | What happens |
|---|---|
| End app | The check runs all session. On a detection the program closes shortly after, and the detection is recorded. |
| Report | The check runs all session. On a detection the program keeps running, and the detection is recorded in Logs as Client detection. |
| Off after sign-in | The check runs until sign-in succeeds, then stops running for the rest of the session. Nothing is checked or recorded and the program is never ended by it. |
| Fully off | The check does not run, from the moment the program learns its settings (the first call to Atlas, before sign-in). Nothing is checked or recorded and the program is never ended by it. The few checks the SDK makes while loading, before it has talked to Atlas, cannot be switched off. |
Use Off after sign-in when a check false-flags a program that is fine once it is running, and a report is no use to you. Use Fully off when a check false-flags your program before it even signs in, such as a packer or a protector that rewrites memory at start. Use Report when you want to see how often it fires before deciding.
Every detection is a row in Logs, not on this page.
Neither setting bans anyone. To react to detections, add an Automation rule for the Client detection event: it can notify you, or ban the license, the hardware or the address.
Switching a check to Report asks you to confirm first, except for Writable and executable memory, Injected threads and Watchdog alive. Switching any check to Off after sign-in or Fully off always asks.
What this does not do
The protection that holds is on your server. Keep what is worth stealing in variables, files and entitlements, which a cracked program cannot reach without a valid session, and treat runtime protection as the part that keeps that session honest. The Atlas Obfuscator makes the program itself harder to read and patch, which is what keeps checks like these useful.
When to change it
- Your program builds code while it runs, such as a script engine or a plugin loader: set New executable memory to Report or Off after sign-in.
- You test builds under a debugger: use a separate test application with the two Debuggers checks on Report or Off after sign-in. Do not relax them on the application your customers use.
- A check reports on machines that look honest: read the Client detection rows in Logs first.
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 |
|---|---|
| Enforce | Refuses the sign-in, or ends the session a few seconds later. This is the default for a new application. |
| Log only | Recorded as a warning in Logs. Nobody is refused. |
| Off | Not checked. Only the hash decides. |
- Only builds marked Proof on file are judged. To record the code of an older build, drop its
.exein again under Builds. - 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.
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.
When it applies
The program reads its settings from Atlas when it starts, before it signs in, and again with every heartbeat. A check set to Fully off never reacts from that first read. Report and Off after sign-in take effect after a successful sign-in; before that every one of those checks runs and ends the program. If the setting cannot be read, or stops arriving, every check goes back to ending the program. If detections appear in three different checks in one session, every check goes back to ending the program for the rest of that session, including the ones set to Off after sign-in or Fully off. A check set to Off after sign-in still runs until the first setting arrives, so a program that trips it while signing in is ended.
A session that keeps running after a detection that should have ended the program is ended by the server. The SDK also refuses to connect to an auth-server address that resolves to the machine it runs on, which blocks the hosts-file redirect most crack tools use. Neither is configurable.