The Loader & Delivery

How the tiny script your buyer runs turns into a validated, HWID-locked, server-gated delivery of your real obfuscated code — and why the real source never lives at a URL anyone can open.

The snippet your buyer runs

When you publish a key system in your client area, Quark gives you a raw loader URL of the form https://quarkexploits.com/raw/YOUR-ID.lua. You hand buyers a two-line snippet; the only thing that changes per buyer is their own license key:

script_key = "THEIR-LICENSE-KEY"
loadstring(game:HttpGet("https://quarkexploits.com/raw/YOUR-ID.lua"))()

The first line sets a global named script_key. The second line fetches the loader stub from your raw URL and runs it immediately. That stub is not your real script — it is a small published bootstrapper that holds no secret. Its only job is to authenticate the buyer, prove their machine, and (only if everything checks out) pull down the real, obfuscated payload from the server.

Why script_key is required

The loader stub reads the global script_key before it does anything else. If that global is missing, empty, or shorter than four characters, the stub aborts on the spot with a warning — it does not contact the server and it does not deliver code. There is no anonymous path through the loader.

This matters for two reasons. First, the key is the entry ticket: no valid license, no execution. Second, it keeps the raw URL useless on its own. Someone can read the stub all day, but without a real, active key bound to their machine, the stub has nothing to give them.

The /api/v1/loader/auth handshake

Once a key is present, the stub gathers a hardware ID plus telemetry about the run and POSTs a JSON body to /api/v1/loader/auth. This single endpoint is the gate that decides whether real code is ever returned.

POST /api/v1/loader/auth
{
  "raw_id":     "YOUR-ID",
  "script_key": "THEIR-LICENSE-KEY",
  "hwid":       "<hardware id>",
  "meta":       { "player_name": "...", "user_id": 0,
                  "game_id": 0, "executor": "...", ... }
}

The endpoint always responds with HTTP 200 so the loader can read the decision from the body. The body is one of:

{ "ok": true,  "payload": "<obfuscated Luau>" }   // authorized
{ "ok": false, "reason": "hwid-mismatch" }        // denied

On ok: true the stub runs loadstring(payload) and executes your real script. On ok: false it warns with the returned reason and stops.

What the server checks, in order

The endpoint runs these checks and returns on the first failure:

1. Well-formed request. The body must be valid JSON and carry both a raw_id and a script_key, or it is refused before anything else.
2. Rate limit. Attempts are throttled per key, per IP to stop brute-forcing a key. Too many attempts in a short window are refused.
3. Key system + license. The raw_id must map to a published key system, and the script_key must be a real license inside it.
4. Status. The license must be active — a banned, paused, or expired key is refused. A key with no expiry is a lifetime key and passes the expiry check. (An unexpired key found past its date is flipped to expired on the spot.)
5. HWID. A hardware ID is required on every request. On the first successful run the server binds the reported HWID to the license; on every run after that the incoming HWID must match the bound one. A missing or mismatched HWID is refused.
6. Published payload. The key system must actually have an obfuscated build to serve, or the request is refused as not-published.
7. Deliver & record. Only when everything passes does the server increment the execution count, record the last run time and IP, write an execution log row, fire the Discord webhook, and return your obfuscated payload.

Denial reasons

Every ok: false response carries a machine-readable reason. These are the values the loader can surface to a buyer:

HWID binding (anti key-sharing)

Alongside the key, the stub reports a hardware ID. The HWID is what makes a license machine-bound, and the lifecycle is simple:

• First execution binds it. The first time a valid key runs, its HWID is recorded and locked to that license.
• Later executions must match. The same key from a different machine is refused with hwid-mismatch — that is the point.
• Resets clear the binding. When a buyer legitimately changes hardware, the bot’s /reset command (which carries a cooldown to stop abuse) or a reset from your client area clears the bound HWID so the next run re-binds to the new machine.

Server-side webhook logging

The Discord webhook is fired by the server, not the buyer’s machine. You supply the webhook URL once, when you create the key system, and it is stored server-side. Both authorized and denied executions are logged, so you see grants and rejected attempts alike — with player, game, and client details plus the denial reason.

This design is deliberate, and it is more secure than logging from the client would be:

• The webhook URL is never in code the buyer can see. The stub never holds the URL and the server sends the notice itself, so there is nothing in the delivered code for a buyer to extract, spam, or delete.
• The log is trustworthy. A client-fired webhook can be blocked, faked, or stripped out by whoever controls the machine. A server-fired webhook reflects what the server actually authorized, so your execution log is authoritative.

Because the website is the single source of truth, these logs and the license state behind them stay consistent across your client area, the API, and the Discord bot — a reset or a ban you apply in one place is reflected everywhere.

Why the real source is never at a public URL

The raw URL only ever serves the loader stub, and even that stub is not your real script. Your actual code is only returned as the authenticated response from /api/v1/loader/auth, and only after a valid key and a matching HWID clear the gate. There is no address where your real source sits waiting to be fetched.

On top of that gating, the payload the server returns is obfuscated with the tier you chose when publishing — anything from the source-based tiers (Standard, Strong, Maximum, Hyper) up to the Quantum VM tier. So even the authorized response is not plain, readable Luau. See Obfuscator & Tiers for how each tier protects the build.

Content-restricted page vs. a runtime request

A natural question: the raw URL looks public, so what happens when someone just opens it in a browser? The two contexts are treated differently.

• A browser sees a content-restricted page. Opening the raw URL in a normal web browser returns a locked notice, not runnable code — a browser is not a runtime request carrying a valid key and HWID. (The exception is you, the signed-in owner, who may read your own stub.)
• The runtime gets the loader, then the gated payload. When your buyer’s HttpGet fetches the URL, it receives the loader stub, which then runs the authenticated handshake above and pulls the real obfuscated payload only if the key and HWID pass.

So opening the link by hand reveals nothing worth having, while a legitimate, licensed run flows straight through. The public-looking URL and the real code delivery are two different things.

End-to-end flow at a glance

1. Buyer runs the two-line snippet with their key.
2. The stub checks for script_key; if missing or too short, it aborts.
3. The stub collects the HWID plus player, game, and hardware telemetry.
4. It POSTs raw_id, script_key, hwid, and meta to /api/v1/loader/auth.
5. The server validates the request, key status, and HWID (binding on first run).
6. On success it records the run, fires the webhook, and returns the obfuscated payload.
7. On failure it returns ok: false with a reason — no code, and the attempt is logged too.

Related

Your loader URL, obfuscation tier, and webhook are all configured when you create and publish a key system — see Create a Key System. HWID resets and license states are covered on Licenses & HWID, and the protection tiers on Obfuscator & Tiers. If a buyer hits a loader problem, the two most common causes are a missing script_key line and a key whose HWID is bound to a different machine. Questions? The community Discord is at https://discord.gg/AvfJCzRgUz.