Introducing the Evorion documentation

Everything you need to integrate authentication, licensing, file delivery, and runtime protection into your native Windows application.

Installation

1. Download the SDK— Grab the latest release from the Evora dashboard. You'll get Evorion.h and Evorion.lib.
2. Drop into your project — Place both files alongside your source. The header handles all library linking via #pragma comment(lib, ...).
3. Get your credentials — In the dashboard, go to Settings → Credentials to find your App ID and Owner ID for the public SDK surface.

Quick Start

The simplest integration. Everything runs automatically:

#include "Evorion.h"

int main() {
    evorion::Client client(
        "OWNER_ID",
        "APP_ID",
        "1.0",
        evorion::TransportMode::Http,
        true,   // auto_init - calls Init() in constructor
        30,     // heartbeat every 30s
        500,    // anti-debug scan every 500ms
        true    // exit on tamper detection
    );

    if (!client.Initialized()) {
        std::cerr << client.LastError() << "\n";
        return 1;
    }

    // Session active. Heartbeat & anti-debug running in background.
    auto r = client.Login("user", "pass");
    if (!r.ok()) return 1;

    std::cout << "Welcome, " << client.User().username << "\n";
    client.Wait();  // blocks forever, keeps heartbeat alive
}

Developer Checklist

What you actually need to do, end to end, before shipping.

1. Create a developer account — sign up at the dashboard. Free tier (Core) is enough to evaluate; Pro adds server-decrypted sections and higher limits; Ultra adds attestation depth, seller tooling, and top quotas.
2. Create an application — in the dashboard, add an app and copy the app_id, app_secret, and (optional) public key.
3. Pick an authentication mode — license for license-key only, user_pass for username/password, or both. See Authentication Modes.
4. Drop the SDK into your project — add the headers and link the static lib. All you need is #include <evorion/evorion.h>.
5. Initialize the client — instantiate Evorion::Client with your app_id, app_secret, and version string. The constructor starts heartbeat and anti-debug automatically.
6. Wire your auth flow — call Login(), Register(), or License() based on your chosen mode. Inspect the Result for the outcome.
7. Configure version policy — set ok / warn / block rules per version in the dashboard so old clients can't bypass updates.
8. Enable integrity checking — turn on Anti-Debug, Anti-VM, and Integrity for your app. The SDK will register a golden image on first connect.
9. Wrap sensitive code with real protection primitives — EVORION_ENCRYPT_BEGIN/END for post-build code encryption (evora-protect CLI), EVORION_AUTH_PROTECT for auth-gated blocks, EVORION_LOCKED_INT for auth-gated constants, EVORION_DYNAPI to hide imports, EVSK() for compile-time string encryption, and the sscx function marker for MAX-tier server-side lift.
10. Test in transport modes you'll use — HTTPS works everywhere; WebSocket gives lower latency and server push.
11. Set up sessions and ban policies — pick concurrent session limits, ban triggers, and abuse detection thresholds in the dashboard.
12. Optionally use the Developer API — issue scoped API keys and automate user, license, or seller management from your own backend.
13. Ship it — release the build that uploads its own golden image, then push subsequent builds confidently knowing remote attestation will catch tampered binaries.

Common pitfalls

• Forgetting to bump the version string when you push a new build — the server will reject the new client until a matching golden image is registered.
• Hardcoding plaintext secrets — wrap every credential and API key with EVSK(). Plain string literals end up in your binary.
• Using license auth mode and then calling Login() — the SDK will refuse the call. Check your app's auth mode in the dashboard.
• Skipping Wait() in console apps — without it, the process exits and the heartbeat dies, which the server treats as session termination.
• Disabling Anti-Debug during development — fine while you're stepping through your own code, but never ship a build with it off.

Authentication Modes

Each application has an auth mode set in the dashboard. The SDK reads it after Init() and enforces it on login calls.

Calling a blocked method returns ErrorCode::AuthModeRestricted. Check the mode first to show the right UI:

std::string mode = client.GetAuthMode();

if (mode == "license") {
    std::string key;
    std::cout << "License key: ";
    std::getline(std::cin, key);
    auto r = client.License(key);

} else if (mode == "user_pass") {
    std::string user, pass;
    std::cout << "Username: "; std::getline(std::cin, user);
    std::cout << "Password: "; std::getline(std::cin, pass);
    auto r = client.Login(user, pass);

} else {
    // "both" - let the user choose their flow
}

Login

Authenticates with username and password. Populates User() on success. Blocked when auth mode is "license".

Leave totp_codeempty on the first attempt. If the account has two-factor enabled, or the app's policy requires it, the call fails with code TWOFA_REQUIRED — prompt for the six-digit code and call again with it filled in. The server only reports this after the password verifies, so a wrong password never reveals whether the account exists.

auto r = client.Login("user", "pass");
if (!r.ok()) {
    std::cerr << r.message() << "\n";
    if (r.error_code == evorion::ErrorCode::InvalidCredentials)
        std::cerr << "wrong username or password\n";
}

Register

Creates a new user account. Does not auto-login, so call Login() afterwards. Blocked when auth mode is "license".

auto r = client.Register("newuser", "securepass");
if (r.ok()) {
    // now login with the new account
    auto login = client.Login("newuser", "securepass");
}

License Key

Validates and activates a license key. Populates User() on success. Blocked when auth mode is "user_pass".

Key-only auth runs the same second-factor check as Login(). A license key is a bearer credential — anyone holding the string can use it — so it is the case where a second factor earns its keep. Handle TWOFA_REQUIRED the same way.

auto r = client.License("XXXXX-XXXXX-XXXXX");
if (!r.ok()) {
    if (r.error_code == evorion::ErrorCode::InvalidLicense)
        std::cerr << "key not found or already used\n";
}

Client

The main SDK class. Non-copyable, non-assignable. Two constructor variants:

Plaintext constructor

evorion::Client(
    const std::string& owner_id,
    const std::string& app_id,
    const std::string& version,
    TransportMode mode          = TransportMode::Http,
    bool          auto_init     = true,
    int           heartbeat_interval = 30,
    int           antidebug_interval = 500,
    bool          auto_exit     = true
);

Secure constructor

Uses SecureCredential for a compile-time-encrypted owner id. Recommended for production builds.

evorion::Client(
    const SecureCredential& owner_id,
    const std::string&      app_id,
    const std::string&      version,
    TransportMode mode          = TransportMode::Http,
    bool          auto_init     = true,
    int           heartbeat_interval = 30,
    int           antidebug_interval = 500,
    bool          auto_exit     = true
);

Parameters

Utility methods

Result

Returned by every API call. Check ok() first, then read details.

auto r = client.Login("user", "pass");
if (!r.ok()) {
    std::cerr << "Error: " << r.message() << "\n";
    std::cerr << "Code:  " << (int)r.error_code << "\n";

    if (r.blacklisted)
        std::cerr << "device is banned\n";
}

UserData

Populated after successful Login() or License(). Access via client.User().

Fields

Helper methods

auto& user = client.User();
std::cout << "User: " << user.username << "\n";
std::cout << "Plan: " << user.subscription << "\n";
std::cout << "Time: " << user.FormatTimeLeft() << "\n";

// read a custom variable set in the dashboard
std::string tier = user.GetVariable("tier", "free");

Error Codes

evorion::ErrorCode enum for programmatic error handling:

Init

Establishes a session with the server: device registration, session tokens, and app config. Only needed when auto_init is false.

evorion::Client client(owner, app, ver,
    evorion::TransportMode::Http,
    false  // auto_init off
);

auto r = client.Init();
if (!r.ok()) {
    std::cerr << "init failed: " << r.message() << "\n";
    return 1;
}

Check

Validates the current session is still live on the server. Useful for manual session verification outside the automatic heartbeat cycle.

auto r = client.Check();
if (!r.ok()) {
    // session died, re-authenticate
}

Heartbeat

Keeps the session alive. Runs automatically in a background thread (controlled by heartbeat_sec), but you can call it manually if needed.

GetVar

Fetches a server-side variable by name. Value is returned in Result::json.

auto r = client.GetVar("motd");
if (r.ok())
    std::cout << "Message: " << r.json << "\n";

SetUserVar New

Sets a per-user variable on the server. Each user has their own isolated key-value store scoped to your application. If the key already exists it will be overwritten, unless the variable was marked read-only by the developer in the dashboard, in which case the call fails gracefully. Keys can be up to 100 characters, values up to 10,000 characters.

// save a play count
auto r = client.SetUserVar("play_count", "42");
if (!r.ok())
    std::cerr << "set failed: " << r.message() << "\n";

// save a JSON config (values are strings)
client.SetUserVar("settings", R"({"fov":90,"sens":2.5})");

GetUserVar New

Retrieves per-user variables. Pass a key to get a single variable, or call with no arguments to retrieve all variables for the current user as a JSON object.

auto r = client.GetUserVar("play_count");
if (r.ok())
    std::cout << "plays: " << r.json << "\n";

// empty key = get everything
auto all = client.GetUserVar();
if (all.ok())
    std::cout << "all vars: " << all.json << "\n";
// output: {"play_count":"42","settings":"{\"fov\":90}"}

FetchOnline New

Returns the number of currently online users in your application. A user is considered online if they have an active session with a heartbeat within the last 5 minutes. The count is returned in Result::json as the online field.

auto r = client.FetchOnline();
if (r.ok())
    std::cout << "Users online: " << r.json << "\n";
// output: {"success":true,"online":17}

Ban New

Permanently bans the currently authenticated user. The server kills the active session immediately after. This is irreversible from the SDK. Only a developer can unban the user from the dashboard. Useful as a client-side anti-tamper response.

// detected something suspicious, ban and exit
client.Ban("Tamper detected by client");
std::exit(1);

InvokeWebhook NewPro / Ultra

Triggers a server-side webhook from the SDK. The webhook must be marked as SDK Callable in the developer dashboard. The webhook URL is never exposed to the client. Pass an optional JSON object as data_json to include custom data in the webhook payload. The server will POST to the configured URL with event details including user ID, IP, timestamp, and custom data.

auto r = client.InvokeWebhook(
    "wh-uuid-from-dashboard",
    R"({"event":"level_complete","score":9500})"
);
if (!r.ok())
    std::cerr << "webhook failed: " << r.message() << "\n";

client.InvokeWebhook("wh-uuid-from-dashboard");

DownloadFile New in v2.9.7

Downloads a file from the server by its file ID. The file must be uploaded through the dashboard under your application. On success, use Result::FileContents() for the raw binary data and Result::FileName() for the original filename.

auto r = client.DownloadFile("file-uuid-from-dashboard");
if (!r.ok()) {
    std::cerr << "download failed: " << r.message() << "\n";
    return 1;
}

std::vector<uint8_t> data = r.FileContents();
std::string name = r.FileName();

std::ofstream out(name, std::ios::binary);
out.write(reinterpret_cast<const char*>(data.data()), data.size());

auto r = client.DownloadFile("config-file-id");
if (r.ok()) {
    auto bytes = r.FileContents();
    std::string text(bytes.begin(), bytes.end());
    std::cout << "loaded " << bytes.size() << " bytes\n";
}

OnPush

Registers a callback for server-pushed messages. Only works in WebSocket transport mode. Common push types include "kill" and "ban".

client.OnPush([](const std::string& type, const std::string& payload) {
    if (type == "kill" || type == "ban") {
        std::cerr << "Terminated by server: " << payload << "\n";
        ExitProcess(0);
    }
});

Two-factor authentication

Your users can protect their account with any standard authenticator app — Google Authenticator, Authy, 1Password, Bitwarden. Evora implements TOTP (RFC 6238): six digits, thirty-second step, no third-party service in the path.

You choose the policy per application under Settings → Access policies → Two-factor authentication:

Setup2FA

Begins enrolment. Returns a secret and an otpauth_uri: render the URI as a QR code, and show the secret as text for users who cannot scan. Pass the account password when the account has one — changing what it takes to get a session should not ride on a session alone. Accounts that authenticate by licence key have no password, so for those the argument is ignored.

Enrolment is not live until Confirm2FA() succeeds. The secret is held server-side for fifteen minutes and is never retrievable again.

auto setup = client.Setup2FA(password);
if (setup.ok()) {
    // otpauth_uri -> QR, secret -> manual entry fallback
    ShowEnrolmentScreen(setup.json);
}

Confirm2FA

Commits the enrolment, but only once a code proves the authenticator actually works. That ordering is the point: committing first would let a mistyped or mis-scanned secret lock a paying customer out of their own account.

auto done = client.Confirm2FA(userTypedCode);
if (done.ok()) {
    ShowBackupCodesOnce(done.json);   // backup_codes[]
}

Disable2FA

Turns the second factor off. A currently-valid code (or an unused backup code) is required — a session alone is not enough, because a stolen session is precisely what the second factor exists to stop. Refused outright when the app policy isrequired.

Get2FAStatus

Reports enabled, enrolled_at, backup_codes_remaining, locked and the app's policy, so you can render the right toggle. Never returns the secret or the backup codes.

Two-factor error codes

Wrong codes are counted per account, not per IP — an attacker with a proxy pool would otherwise have an unbounded budget. Five failures lock the account's second factor for fifteen minutes.

Logout

Ends the current session. With everywhere = true, ends every session the user holds on this application — the control to offer when someone suspects their account is compromised, or is handing back a shared machine.

client.Logout();          // this device
client.Logout(true);      // every device

ChangeUsername

Renames the account. Usernames are unique per developer and stored lowercased. The password is required when the account has one.

A thirty-day cooldown applies. That is not cosmetic: without one, rename is an impersonation primitive — release a recognisable name for someone else to take, or cycle names to outrun moderation. Previous names are retained so support and abuse work can still resolve them.

Password recovery

Recovery is deliberately a two-party flow: Evora issues and verifies the token, you deliver it.

• RequestPasswordReset() raises the request to you — a dashboard notification plus an app log entry — and returns success whether or not the account exists. It never returns a token. The uniform response is what stops this being a free account-enumeration endpoint against your whole user base.
• You issue a token with POST /users/:userId/password-reset and deliver it over whatever channel your customers actually use — commonly a Discord DM.
• ResetPassword() lets the customer redeem that token inside your app, so recovery never needs a web page. Every live session for the account is ended as the password changes.

// 1. in-app: user asks for help
client.RequestPasswordReset("username");
// -> always reports success; you receive a dashboard notification

// 2. you issue a token from the dashboard or developer API,
//    and send it to them yourself

// 3. in-app: they paste it
auto r = client.ResetPassword(token, newPassword);

FetchStats

Returns users, licenses, online and versionfor the application — the numbers behind a "1,204 users online" banner.

When a user loses their authenticator

Backup codes cover the ordinary case. When someone loses both their authenticator and their codes, reset them from Users → ⋯ → Reset two-factor, or DELETE /users/:userId/2fa on the developer API.

This is the only path that removes a second factor without presenting a code, which is why it requires your authenticated developer credentials and is never reachable from the SDK — a self-service "just turn it off" would defeat the feature entirely. The account's live sessions are ended with the reset, on the assumption that the reason for it may have been a compromise.

Security Notice — Read Before Shipping

What Evorion protects

• License validation — server-issued, HWID-bound, anti-replay.
• Session secrets — per-session AES-256 key material derived only when the license is valid.
• Payload distribution — encrypted blobs you serve to your users, decrypted at runtime only with a valid session.
• Binary integrity of the SDK itself — internal CFF + sealed cookies + integrity mesh detect tampering of the lib.
• Anti-replay — session secrets rotate via heartbeat; stolen tokens expire fast.
• Anti-emulation — best-effort detection of sandboxes and Unicorn-class emulators.

What Evorion CANNOT protect

Evorion is a library. It cannot protect what it never sees.

Recipe 1 — Replace your auth check with the consumer transfer flow

Wrong — vulnerable to a 1-byte jnz flip

auto r = client.License(key);
if (!r.ok()) return 1;
// success path — entirely your code:
auto blob = curlDownload("https://my-cdn.example/payload.bin");
for (size_t i = 0; i < blob.size(); ++i) blob[i] ^= kStaticKey[i & 15];
manualMap(blob, "TargetGame.exe");

Right — immune to byte patching (v3.6 transfer flow)

#include "Evorion.h"
...
auto r = client.License(key);
// NOTE: no early return on !r.ok().  the transfer below IS the gate.
std::vector<uint8_t> blob;
client.SessionFetch("https://payloads.evora.lol/" + r.payload_token(), blob);
std::vector<uint8_t> plain(blob.size() - 28);   // 12B nonce + 16B GCM tag
size_t plain_len = plain.size();
evorion::session::transfer(r, blob.data(), blob.size(),
                            plain.data(), &plain_len);
manualMap(plain, "TargetGame.exe");

If someone patches your jnz, the transfer produces zero bytes and manualMap crashes the target's remote thread. No payload loads. The success path exists only when the session is real; there is no boolean for the attacker to flip.

The transfer call is also tied to your calling site, so patches applied later — to your transfer call site itself, not just an earlier jnz— are detected by the SDK's automatic protection layers and result in an unrecoverable session.

For that case, the fix is not to try to force transferin — it is to identify what in your success path is worth gating on the session and route it through bind_key: a config that resolves your endpoints, a feature-flag decoder, the licence-check routine itself, a small piece of hot logic. Encrypt it at build time under a labelled bind_key derivation; at runtime, main() cannot function until a real session yields the same key. The point of both primitives is the same: make the success path structurally depend on cryptographic material only a genuine session produces, so there is no boolean between "got a session" and "did the work" for an attacker to patch.

Automatic protection

The SDK arms a set of runtime protections the moment Evorion.lib is linked into your build. There is nothing to call, configure, or enable. These layers are the safety net for integrations that ship without the post-build packer — they raise the cost of a scripted crack from seconds to hours plus detection risk. They do not substitute for shipping through evora-protect for high-value binaries.

Tamper detection at your call sites

When your code calls into any Evorion gate, the SDK ties the check to the surrounding bytes of your calling code. If those bytes are modified later — a static patch of your binary, an in-memory hook, or a runtime rewrite — the session becomes unrecoverable and the process is retired unpredictably. You do not need to know when or how; the check is continuous for the lifetime of the process.

Anti-dump

Standard process-dumping tools that scan memory for a binary's signature, reconstruct its import table, or rebuild a runnable file from a paused process do not succeed against an Evorion-linked build. Attempts to attach and dump produce broken output that will not run. Repeat attempts do not converge on a working dump — the protection is re-applied continuously in the background.

Anti-debug and anti-instrumentation

Debuggers, memory scanners, and known reverse-engineering tools observed alongside the protected process cause it to become unrecoverable. This begins before your main()runs, so an attacker cannot "attach before the checks start." Detection is silent — there is no message box, no clean exit code, no stack trace back to a check site.

What these layers do not replace

The automatic layers are runtime defences. They do not:

• Protect inline plaintext logic in your loader's .text (see Recipe 2).
• Substitute for post-build packaging via evora-protect, which additionally rewrites call sites, encrypts sections at rest, and lifts sscx-marked functions to server-side execution.
• Defend against kernel-mode attackers with unlimited time. See Limitations below.

Recipe 2 — Refactor inline sensitive code out of your loader

If your sensitive code is inline C++ in your loader's .text, the SDK physically cannot protect it. Someone who flips your jnz reaches your inline instructions directly, with no encryption to defeat.

Lift it:

• Move the sensitive logic into a separate DLL or position-independent shellcode.
• Encrypt the blob at build time with a session-derived key (any AES-GCM tool; the key material is your business — the SDK never sees your build-time blobs).
• Serve it from your CDN behind a signed URL your server issues per-session.
• At runtime: Client::SessionFetch → evorion::session::transfer(r, ...) → VirtualAlloc PAGE_EXECUTE_READWRITE → memcpy → call.

Someone who patches your jnz gets garbage instructions in RWX memory; the process crashes on the first call.

Recipe 3 — Configure heartbeat for resident loaders

evorion::Client client(
    owner_id, app_id, "1.0.0",
    TransportMode::Http,
    /*auto_init=*/true,
    /*heartbeat_interval=*/30,   // seconds — keep ≤ 30 for live sessions
    /*antidebug_interval=*/500,
    /*auto_exit=*/true);

Heartbeat rotates session_secret. Mid-session license revocation invalidates the secret on the next tick — anti-replay is automatic. Server-side OnPush callbacks for kill/ban terminate the session out of band on the same channel.

Do — explicit list

• Use evorion::session::transfer(r, ...) to deliver any server-issued content the customer's success path actually uses. It is the right answer for "receive authenticated bytes and use them" — but only when your success path is coupled to those bytes. If it isn't, see Recipe 1's architectural note.
• Use evorion::session::bind_key(r, label, len, out) when you ship encrypted assets bundled with your build — encrypt at build time with the same label, decrypt at runtime with the returned key. This is the ONE right answer for "session-bound derived key."
• Use Client::SessionFetch(...) for all downloads (in-process TLS, cert pinned).
• Wrap sensitive code with EVORION_ENCRYPT_BEGIN/END for post-build encryption, EVORION_AUTH_PROTECT for auth-gated blocks, and EVSK() for compile-time string encryption.
• Auth-gate sensitive constants with EVORION_LOCKED_INT. .load() consults live session state — a bypassed session returns a zero-initialized value.
• Set heartbeat_interval ≤ 30 seconds for live / resident loaders.
• Strip symbols, PDB paths, and debug info from release builds.
• Build with deterministic linker flags (/Brepro) so leaked timestamps don't fingerprint your machine.
• Ship optimized release builds (-O2 at minimum) — unoptimized code preserves function shapes and symbol structure.
• Implement Recipe 1 even if you don't think you need it — it costs 5 lines.
• Keep evora.lol account credentials in a hardware-backed secret store.
• Rotate license keys quarterly.
• Monitor your owner dashboard for unexpected HWID changes and failure-rate spikes.

Don't — explicit list

• Don't hardcode XOR keys, AES keys, or salts in your loader.
• Don't write static URLs to payload CDNs (use SessionFetch + server-issued URL).
• Don't use popen / system / ShellExecute / CreateProcess for downloads.
• Don't use curl -k (insecure flag disables TLS validation — defeats the entire chain).
• Don't gate your success path on if (r.ok()), if (client.Authenticated()), or any other if (some-boolean-derived-from-auth). The pattern is the vulnerability; the compiler will warn you at every such call site. The right shape is to make the success path structurally depend on cryptographic material only a real session can produce — via session::transfer (server-issued content) or session::bind_key (build-time-bundled content), whichever matches your app. See Recipe 1 for the case where neither naturally fits.
• Don't compare an HMAC or key you derived from the session against an expected value in an if. If you find yourself writing if (memcmp(computed, expected) == 0) work();, you have re-created the same patchable branch. Use the derived value as key material for whatever comes next (bind_key + your own AEAD).
• Don't store sensitive code inline in your loader's .text as plaintext.
• Don't log r.session_secret() bytes — not to stdout, stderr, files, debug output, or anywhere persistent.
• Don't cache decrypted payloads on disk — they're in RWX memory only.
• Don't ship debug builds (EVORION_VERBOSE defined) to customers — log strings leak everything.
• Don't compile with PDB paths reachable from the binary's .rdata (use /PDBALTPATH:%_PDB%).
• Don't ship OutputDebugString calls in release builds — debuggers attach silently to read them.
• Don't bundle evr_diag.log / evr_crash.dmp in your release artifacts.
• Don't roll your own anti-debug on top of textbook checks — the SDK already covers anti-debug automatically and layered ad-hoc checks are trivially bypassed while adding maintenance cost.
• Don't reuse license keys across customers (the server rotates on misuse).

Limitations — what happens if you skip each recipe

If you suspect a crack

• Don't panic — file a ticket at [email protected] with the leaked binary if you have it.
• Check your build — verify Recipes 1 + 2 are in place; ~95% of cracks are missing Recipe 1.
• Check telemetry — your owner dashboard shows per-license HWID counts and failure-rate spikes; a sudden spike usually precedes a public crack by hours.
• Rotate — push a build with new payload encryption keys and new license issuance keys. Old cracked builds stop working on the next session refresh.
• Report indicators — share tool signatures with evora.lol; we update the global blocklist.

Reporting a vulnerability in the SDK itself

[email protected]. PGP key in your owner dashboard. Bounty program details on the Trust page.

Glossary

The two consumer primitives

Every legitimate customer use case maps to one of these two. If you are reaching for anything else, you are either rebuilding the patchable-boolean pattern by hand or duplicating what one of these already does.

Supporting API

Legacy — do not use in new integrations

These names are still callable so existing integrations compile and existing payloads decrypt. All emit compiler deprecation warnings at the call site; migrate to session::transfer or session::bind_key.

Anti-Debug & Anti-TamperPro / Ultra

The SDK runs anti-debug scans in a background thread at the interval you specify. Detections are reported to the server. When Auto-Ban is enabled in the dashboard, the device gets blacklisted immediately.

evorion::Client client(
    owner, app, ver,
    evorion::TransportMode::Http,
    true,   // auto_init
    30,     // heartbeat
    500,    // anti-debug scan every 500ms
    true    // auto_exit - kills process on detection
);
// anti-debug is now running. nothing else to do.

What it covers

• User-mode and kernel debuggers attached to the process.
• Runtime code and API hooking.
• In-memory tampering with the loader's code.
• Emulator and virtualisation environments used to bypass runtime checks.
• Manual mappers and other non-standard module loading.

Binary Integrity & Remote AttestationPro / Ultra

Server-driven memory attestation verifies that your application's code hasn't been modified at runtime. The server holds a "golden image" of your binary's .text section and periodically challenges connected clients to prove their in-memory code matches.

How it works

1. Upload. Upload your compiled binary (or pre-extracted .text section) to the dashboard. The server extracts and stores the .text section encrypted with AES-256-GCM.
2. Enable. Toggle integrity checking on for your application in Binary Integrity settings.
3. Challenge. During heartbeats, the server picks random regions of .text and sends an attestation challenge with a fresh nonce.
4. Proof. The SDK reads its own memory at those offsets, computes HMAC-SHA256(regions || nonce, BUILD_SECRET), and returns the proof.
5. Verify. Server verifies the proof against its golden image. Mismatch → IntegrityViolation.

Dashboard setup

Navigate to your app's Binary Integrity page. Two upload modes:

SDK integration

Remote attestation is fully automatic. Once integrity checking is enabled and a golden image is registered for your version, the SDK handles challenges during heartbeats with zero extra code on your part.

// no special code needed, attestation runs inside Heartbeat()
EVORION_CLIENT(client,
    "OWNER_ID",
    "APP_ID",
    "1.0.0",
    evorion::TransportMode::Http,
    true, 30, 500, true
);

if (!client.Initialized()) return 1;
auto login = client.Login("user", "pass");
if (!login.ok()) return 1;

while (running) {
    auto hb = client.Heartbeat();
    if (!hb.ok()) {
        if (hb.error_code == evorion::ErrorCode::IntegrityViolation)
            std::cerr << "Integrity violation detected\n";
        break;
    }
    Sleep(30000);
}

Attestation protocol

Golden image self-registration

When your app connects for the first time and no golden image exists for its version, the SDK automatically extracts its own in-memory .text section and uploads it to the server. No manual upload needed for every build.

Golden image CLI tool

For CI/CD pipelines, use the extract-golden-image.mjs tool (shipped in sdk/tools/) to extract and upload golden images as a post-build step:

# Extract from compiled binary and upload
node extract-golden-image.mjs MyApp.exe <app_id> <version> --api-key <key>

# For packed binaries: dump at runtime, then upload the dump
MyApp.exe --dump-golden golden.bin
node extract-golden-image.mjs golden.bin <app_id> <version> --raw --api-key <key>

# Extract only (don't upload)
node extract-golden-image.mjs MyApp.exe <app_id> <version> --dump-only

Hardware ID

Generates a stable hardware fingerprint for the current machine. Used internally for HWID lock, but you can also use it for your own device tracking.

std::string hwid = evorion::hwid::Generate();
std::cout << "Device: " << hwid << "\n";

Secure Credentials

Plaintext strings sit in the binary at rest. SecureCredentialencrypts them at compile time so there's nothing to find in a hex editor or string dump.

EVSK macro

The fastest way. Wrap your owner id or any other sensitive literal into a SecureCredential with compile-time encryption:

evorion::Client client(
    EVSK("your-owner-uuid"),
    "your-app-uuid",
    "1.0"
);

EVORION_CLIENT macro

All-in-one shorthand that wraps the owner id automatically and forwards the remaining constructor arguments:

EVORION_CLIENT(client, "owner-uuid", "app-uuid", "1.0", evorion::TransportMode::WebSocket);

SecureCredential class

Transport Modes

The SDK supports two transport modes:

Version Management

The server checks the SDK version and your app version on every Init(). Configure version policies per-application in the dashboard:

Code ProtectionPro / Ultra

When someone reverse engineers your program, they open it in a disassembler (like IDA Pro or Ghidra) and read the compiled instructions to understand what your code does. Code protection makes that harder. Every macro below does actual work — either at build time (server-side encryption via evora-protect) or at auth-tied runtime (auth gates + dynamic API resolution). Runtime-only CFF wrappers were removed in R70 — they added noise without a post-build lift.

Code Encryption (EVORION_ENCRYPT)Pro / Ultra

This is different from the above. Instead of transforming the structureof your code, it encrypts the actual bytes in the binary with AES-256-GCM. The decryption keys live on the Evora server, not in the binary. At runtime the SDK fetches keys from the server and decrypts each section in memory automatically when execution reaches it. This is server-controlled code protection. If someone dumps your binary, the encrypted sections are unreadable without server access. You can revoke a build's keys at any time, permanently disabling that version.

How it works

1. Mark code sections with EVORION_ENCRYPT_BEGIN / EVORION_ENCRYPT_END in your source. The markers compile to harmless jumps, so the code runs normally before protection.
2. After compiling, run the EvorionShield CLI tool on your binary. It finds the markers, encrypts each section with AES-256-GCM, uploads the keys to the Evora server, and patches the markers into decrypt stubs.
3. At runtime, call EVORION_SHIELD_INIT after authentication. This registers the auto-decrypt callback. From that point on, when execution reaches an encrypted section the SDK automatically fetches the key and decrypts in-place.
4. The section is decrypted in memory only. The binary on disk stays encrypted.

// after authenticating, init the shield runtime
EVORION_SHIELD_INIT(client);

EVORION_ENCRYPT_BEGIN;
    do_critical_work();
EVORION_ENCRYPT_END;

EVORION_ENCRYPT_BEGIN;
    EVORION_AUTH_PROTECT(client, my_algo)
        run_sensitive_algorithm();
    EVORION_PROTECT_DONE(my_algo)
EVORION_ENCRYPT_END;

Call EVORION_SHIELD_SHUTDOWN(client)when you're done to clean up the shield connection.

Encrypted Strings

Strings are one of the easiest things to find in a binary. SecureStr eliminates this attack surface entirely with two layers of protection:

• Compile-time encryption removes the plaintext from the binary. The string never appears in .rdata or any other section.
• Runtime encryption keeps the string sealed in DPAPI-encrypted, VirtualLock'd memory. Plaintext only exists during a scoped access window, then is wiped immediately.

auto url = SecureStr("api.evora.lol/v3/auth");

// plaintext exists only inside this scope
{
    auto v = url.access();
    http_get(v.ptr());
}
// plaintext wiped from memory here

// one-liner (wiped after the full expression)
http_get(url.use());

For wide strings, use WSecureStr(L"..."). Same protection, same API.

auto path = WSecureStr(L"C:\\secret\\config.dat");
{
    auto v = path.access();
    load_config(v.ptr());
}

SecureStringPool

If you have multiple strings used in hot paths and want to avoid DPAPI + VirtualAlloc overhead on first use, pre-allocate them at startup with a pool:

static evorion::sstr::SecureStringPool<3> urls;

void Init() {
    urls.set(0, skCrypt("api.evora.lol/v3/auth"));
    urls.set(1, skCrypt("api.evora.lol/v3/heartbeat"));
    urls.set(2, skCrypt("api.evora.lol/v3/validate"));
}

void SendAuth() {
    http_get(urls.get(0).use());
}

Auth-Protected Blocks (EVORION_AUTH_PROTECT)

EVORION_AUTH_PROTECT wraps a block in a runtime-verified auth gate. At entry, it calls _evr_vc(client, site_id) — a live-session validity check computed against the current heartbeat state and mesh entanglement. If the session is invalid (server kill, blacklist, heartbeat expiry, mesh trip), the block calls FailClosed immediately. Patching the auth flow at any earlier point does not defeat the gate — the vc is computed fresh at every entry.

Usage

void run_premium_feature(evorion::Client& client) {
    EVORION_AUTH_PROTECT(client, premium)
        do_premium_stuff();
        apply_results();
        save_state();
    EVORION_PROTECT_DONE(premium)
}

Pair with EVORION_PROTECT_DONE(name) to close. The block runs only when the session is genuine; on invalid auth the process fail-closes rather than silently continuing.

Companion primitives

Dynamic API hide your imports

Strip Win32 functions from your binary's import address table without rewriting your code. The SDK already does this for ~185 common APIs automatically; for anything else, one macro covers it.

What it does

• Function and DLL names hashed at compile time. No plaintext strings in your binary.
• Resolution walks the loaded-module list + target DLL's export table directly (no GetModuleHandle/GetProcAddress in your IAT).
• Resolved pointer cached per call-site in an XOR-obfuscated slot keyed on a per-process secret from the system PRNG.
• Cheap anti-hook prologue check rejects pointers redirected via JMP rel32, MOV RAX imm64 / JMP RAX, INT3, etc.
• Failed resolutions retry after a short timeout instead of becoming permanent nulls.

Primary usage — automatic via header

Just include <Evorion.h> and write normal Win32 code. The header macro-shadows ~185 functions across kernel32, user32, advapi32, ntdll, bcrypt, winhttp, crypt32, dbghelp, gdi32, gdi+, shell32, shlwapi, ws2_32, iphlpapi, ole32, oleaut32, psapi, tbs, and more. None of those calls leave an IAT entry.

#include <Evorion.h>

void DoSomething() {
    Sleep(1000);                            // de-imported automatically
    HANDLE h = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, 4);
    IsDebuggerPresent();
    CloseHandle(h);
}

Escape hatch — APIs not pre-shadowed

For any export the SDK does not auto-shadow, use the EVORION_DYNAPImacro. The function's declaration must already be visible (e.g. you included the right Windows header) so the compiler can deduce the type and calling convention. You never write the typedef yourself.

#include <Evorion.h>
#include <wininet.h>     // declares InternetCheckConnectionW

void NetCheck() {
    auto p = EVORION_DYNAPI(wininet.dll, InternetCheckConnectionW);
    if (p) p(L"https://example.com/", FLAG_ICC_FORCE_CONNECTION, 0);
}

Lazy variant — late-loaded DLLs

For a DLL that may not be loaded yet at the call site, use EVORION_DYNAPI_LAZY. The DLL is loaded from %WINDIR%\System32 only — never from the application directory — so DLL planting cannot redirect the call.

#include <Evorion.h>
#include <wincrypt.h>

void DpapiRoundTrip(BYTE* buf, DWORD len) {
    auto p = EVORION_DYNAPI_LAZY(crypt32.dll, CryptProtectMemory);
    if (p) p(buf, len, CRYPTPROTECTMEMORY_SAME_PROCESS);
}

What it does NOT protect

• Not a sandbox. Once you have the function pointer, the call is a normal Win32 call.
• A dynamic analyst running your binary in a debugger sees every call. The function pointer is hidden, the execution is not.
• Hiding the import buys you obscurity, not invisibility. Behavioral patterns still telegraph intent.

Performance

First call per slot: ~200–500 ns (PEB walk + export-table scan). Subsequent calls: one XOR load — same cost as a normal function-pointer call. Per-process secret seeding is a one-time cost at SDK init.

Custom API domainPro / Ultra

By default your app talks to api.evora.lol. A custom domain lets you serve the exact same API from a hostname you own — auth.yourgame.com— so your users' traffic never names Evora. Two things this buys you: if an ISP or network firewall blocks evora.lol, your app keeps working; and a casual look at your binary or its network traffic no longer reveals which auth provider you use.

What you need

Connecting a domain

Open your application, go to Settings → Custom Domain, and enter the hostname you want to use. Leave off https:// — just the bare name.

1. Enter auth.yourgame.com and click Connect domain. The panel shows a status of Waiting on DNS.
2. Add the DNS records the panel shows you at your registrar (details below). There is one CNAME that does the routing, and usually one TXT that proves you own the domain.
3. Come back to the panel. It re-checks every few seconds — you do not need to refresh. Status moves to Verifying while the certificate is issued, then Live.
4. Point your app at the new hostname (see below) and ship an update.

The DNS records

The exact values are generated per domain and shown in the panel — copy them from there. They take one of these shapes:

How long it takes

DNS changes are usually visible within a few minutes but can take up to an hour depending on your registrar. Once the records are found, the certificate is typically issued within a minute or two. If a domain sits on Waiting on DNS for more than an hour, re-check that the record Name and Value match the panel exactly — a trailing dot or an extra .yourgame.com appended by your registrar is the usual cause.

Using it — REST API

Once the domain is Live, swap the base URL everywhere you call the API. Nothing else changes.

- https://api.evora.lol/api/v1/auth/login
+ https://auth.yourgame.com/api/v1/auth/login

Every endpoint, header, API key, request body and response is identical. If you keep a base URL in a config value, this is a one-line change.

// before
const API = "https://api.evora.lol/api/v1";

// after — your own domain
const API = "https://auth.yourgame.com/api/v1";

const res = await fetch(`${API}/auth/login`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ app_id, key: licenseKey }),
});

Using it — C++ SDK

The SDK talks to api.evora.lol by default. Call Client::SetApiHost() once, before you construct your client, with the bare hostname. That is the whole change.

#include "Evorion.h"

int main() {
    // Route through your connected custom domain. Bare hostname — no
    // "https://", no path. Call this BEFORE constructing the client.
    evorion::Client::SetApiHost("auth.yourgame.com");

    evorion::Client client("OWNER_ID", "APP_ID", "1.0");
    if (!client.Init()) return 1;
    // ... everything else is unchanged
}

Certificate pinning still works — automatically

The Evorion 4 Umbra SDK pins the TLS certificate chain for defence in depth. You do not need to change, rebuild, or ship anything for pinning to keep working on a custom domain: the SDK pins the long-lived chain anchors (the certificate authorities), not the short-lived leaf certificate. The certificate issued for your hostname chains to the same authorities, so it validates against the existing pins with nothing to rotate.

No silent fallback

If your custom domain stops resolving, the SDK does not quietly fall back to api.evora.lol — doing so would leak the very hostname you are paying to hide. Init() fails instead. Ship a build you can update, and treat a connect failure as a signal to check your domain rather than something the SDK papers over.

To confirm a custom host actually took effect in a diagnostic build, read it back:

evorion::Client::SetApiHost("auth.yourgame.com");
// prints "auth.yourgame.com"
std::printf("api host: %s\n", evorion::Client::GetApiHost().c_str());

Disconnecting

Remove a domain from Settings → Custom Domain. The hostname stops answering API requests immediately, so ship an update that points back at api.evora.lol first— any build already in your users' hands that still points at the removed domain will break. Re-connecting the same domain later re-issues its certificate from scratch.

Developer API

HTTP API at https://api.evora.lol/api/developer-api for the same operations as the dashboard: users, licenses, webhooks, stats, and more. Every route requires a valid API key with the right scopes.

Base URL

https://api.evora.lol/api/developer-api

Quick start

curl -H "Authorization: Bearer ag_sk_YOUR_KEY" \
  https://api.evora.lol/api/developer-api/users

# generate 10 licenses, 30 days each, level 1
curl -X POST https://api.evora.lol/api/developer-api/apps/YOUR_APP_ID/licenses \
  -H "Authorization: Bearer ag_sk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"amount": 10, "duration": 30, "expiry": 86400, "level": 1}'

# ban a user
curl -X POST https://api.evora.lol/api/developer-api/users/USER_ID/ban \
  -H "Authorization: Bearer ag_sk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"reason": "TOS violation"}'

Response shape

Responses are plain JSON objects; most list endpoints return their collection at a named key (for example { apps, total, page, limit }). Errors use standard HTTP status codes with { error: '...' }, and several endpoints add a stable code field you can branch on.

Rate limits

A fixed 300 requests/minute per-key ceiling, plus your plan's requests-per-minute quota — the latter is the limit you'll normally meet. Over either, you get 429 with retry_after (seconds). Expired or over-quota subscriptions return 402.

Recipe: a Discord bot

The bot holds the API key on your server and never exposes it. A typical purchase-to-access flow is three calls: create the customer, generate a key, redeem it for them.

const API = 'https://api.evora.lol/api/developer-api';
const H = {
  'Authorization': `Bearer ${process.env.EVORA_KEY}`,
  'Content-Type': 'application/json',
};

// 1. Create the customer account (password is required, 6+ chars)
const { user } = await fetch(`${API}/users`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ username: discordName, password: generatedPassword }),
}).then(r => r.json());

// 2. Redeem a key on their behalf — server-to-server, no password needed
const res = await fetch(`${API}/users/${user.id}/redeem`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ licenseKey: keyFromCustomer }),
});
const body = await res.json();

if (!res.ok) {
  // Stable codes: INVALID_KEY, KEY_BANNED, KEY_PAUSED, ALREADY_REDEEMED,
  // NOT_FOR_THIS_USER, HWID_MISMATCH, NO_BENEFIT, QUOTA_EXCEEDED
  return reply(`Could not redeem: ${body.error}`);
}
reply(`Activated ${body.data.subscriptionName} until ${body.data.expiresAt ?? 'forever'}`);

Redemption here behaves exactly as it does in the loader and the account panel — same validation, same no-benefit protection, same events. Point a webhook at your bot to hear license.used regardless of where the redemption happened; the payload's source field tells you which surface it came from.

Linking Discord accounts

There is no built-in Discord ID field. Store it as a per-user variable and look users up by username:

# tag the Evora user with their Discord id
curl -X POST "$API/apps/$APP_ID/users/$USER_ID/variables" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"var_key": "discord_id", "var_value": "123456789012345678"}'

# later: resolve a customer by name
curl "$API/apps/$APP_ID/users/lookup?username=someuser" -H "Authorization: Bearer $KEY"

Recipe: a customer panel

Your panel's backend holds the API key and proxies every call. The browser must never see an ag_sk_ key — CORS blocks direct browser calls precisely so this mistake is hard to make.

// Verify the customer's credentials against Evora
const r = await fetch(`${API}/apps/${APP_ID}/users/authenticate`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ username, password }),
});
const data = await r.json();
if (!data.authenticated) return renderLoginError();

// Evora does not issue a browser session — you mint your own cookie here.
req.session.evoraUserId = data.user.id;

// data.subscription: { level, name, expiresAt, hwid, paused, active }
// The "active" flag is false when expired OR paused — the same verdict the SDK reaches.

To let a customer launch the protected app straight from your panel, mint a one-time, HWID-bound exchange token and hand it to your loader, which trades it for a real SDK session. Your panel never handles the customer's password.

// 1. Panel backend mints the token (TTL 30-300s, one-time use)
const { exchange_token } = await fetch(
  `${API}/users/${userId}/issue-session-token`,
  { method: 'POST', headers: H,
    body: JSON.stringify({ appId: APP_ID, hwid: clientHwid, ttlSeconds: 120 }) },
).then(r => r.json());

// 2. Your loader posts it to the SDK proxy endpoint to obtain a session
//    POST /api/v2/proxy/login-by-token  { exchange_token, hwid }

Recipe: a panel for a license-only app

If your app uses auth_mode: license, your customers have no username or password — their key is their credential. Authenticate them with the key instead; everything after that point is identical to the user/password panel above, because both endpoints return the same user and subscription envelope.

const r = await fetch(`${API}/apps/${APP_ID}/licenses/authenticate`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ licenseKey: keyFromCustomer }),
});
const data = await r.json();

if (data.authenticated) {
  req.session.evoraUserId = data.user.id;   // your own session, as before
  render(data.subscription);                // level, name, expiresAt, hwid, paused, active
} else if (data.code === 'LICENSE_NOT_ACTIVATED') {
  // Valid key, never used in the app yet. data.license has status/level.
  render('Key valid — launch the app once to activate it.');
} else {
  render('Invalid license key');            // 401, or 403 if banned
}

Once you have data.user.id, HWID reset, subscription lookups and issue-session-token SSO all work exactly as they do for user/password apps. HWID reset and ban also accept a raw license key in place of the license id, if you would rather not resolve the user first.

Password reset

Evora issues and verifies; you deliver.There is no "forgot password" email sent from our side — your customers are yours, and most of them have no email address on file anyway. Instead you mint a single-use token and send it over whatever channel you already use (a Discord DM, your own mail provider, a link on your panel), then fulfil it.

const r = await fetch(`${API}/users/${userId}/password-reset`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ ttlSeconds: 1800 }),   // 5 min – 24 h, default 30 min
});
const { reset_token, expires_at } = await r.json();

// Deliver it yourself — it is NOT retrievable again.
await discord.users.send(discordId,
  `Reset link: https://lunar.com/reset?token=${reset_token} (expires ${expires_at})`);

await fetch(`${API}/password-reset/fulfil`, {
  method: 'POST', headers: H,
  body: JSON.stringify({ token, newPassword }),
});
// -> { success: true, userId, username, sessions_terminated }

Freezing a subscription

Freezing banks the remaining time and stops the clock; resuming converts the banked seconds back into a fresh expiry. Enable allow_subscription_pause on the application first, or the pause call returns PAUSE_NOT_ENABLED.

Resuming is intentionally not gated on the app flag, so turning the feature off never strands customers who are already frozen. A paused subscription reports active: false from both authenticate endpoints, matching what the SDK does.

Self-service actions

Applications

Scopes: apps:read / apps:write

Two fields on PUT /apps/:appId govern the end-user account surface:

Statistics

Scope: stats:read

Users

Scopes: users:read / users:write

Licenses

Scopes: licenses:read / licenses:write

Bulk actions

This endpoint performs actions on existing licenses; it does not create them (to generate many at once, use amount on POST /licenses). Send an action plus its required fields. Unknown actions are rejected with 400.