Free Lua obfuscator with script auth and key hosting

How a secure loader controls payload delivery

Use a managed loader when distributing a static file URL is not enough: you need an access decision and a selected payload before delivery. Obfuscation transforms code; authorization checks access; delivery hands over the result. Your enabled components determine which checks happen.

1. 1. Check the enabled access rules. A keyed run checks the project, license state and expiry. Enable HWID binding for one-device access and device bans for hardware-denial rules; FFA and keyless modes have different access behavior.
2. 2. Select the payload. A keyed run can use its Key Group's payload. Ungrouped keys can use the project default. If no override is configured, the entry loader's own payload is used; a configured override that is unavailable or invalid can deny delivery rather than silently substitute content. Keyless retrieval uses the entry loader's payload. The entry loader's saved release pin selects delivery policy, not a mapped payload's pin.
3. 3. Deliver authorized keyed output. The keyed route issues a signed download link lasting about 60 seconds. The loader retrieves the selected payload. Share the stable dashboard snippet, not that temporary link.
4. 4. Optionally renew authorization. Enable session leases when a run must keep checking access. Presence reports activity but does not provide the same continuing enforcement.

Setting key_check: false makes retrieval public to holders of the URL, subject to any other enabled controls. With every runtime component off, the URL serves the final payload directly, without a generated stub. Off/passthrough is not source secrecy. A later ban or lease denial cannot retract bytes already delivered.

Follow the loader setup instructions and Key Group routing rules.

Anti-dump, environment-hook detection and encrypted delivery

Vampauth's loader protection has three distinct layers: code transformation, runtime-environment checks and encrypted transport. Here is what each does and which settings apply.

Choose components for the job

New modular loaders default to Full payload protection, key checking, presence, HWID binding, device bans, fingerprinting and runtime guards; leases start off. Project settings and key policy still apply. Key checking is required for the lease and HWID-binding components.

Licensed standard edition

Keep key checking, HWID binding and device bans on. Choose Full for VM-based payload transformation. New Light publishing is unavailable. Add leases if access must be renewed during a run; presence is useful for observation independently of leases. No measured speed or FPS difference is promised.

An already-obfuscated payload

Choose Off/passthrough to preserve submitted bytes, including external obfuscation. Keep key checking and the other required runtime controls on; a newly published stub still uses Full VM. Test the submitted code in your supported client rather than assuming every external output is compatible.

Public hosted release

Disable key checking only when keyless retrieval is intended. Turn off all runtime components for direct final-payload serving. You may still choose Full VM or Off/passthrough for that payload; a transformed file alone does not enforce a license.

Presence and fingerprinting help you observe activity; fingerprints are client-reported, advisory signals, not identity proof or an access gate. Runtime guards add checks against runtime-context tampering; they do not guarantee support for every executor. See publishing documentation and runtime variables and helpers for integration details.

Session leases limit runs, not devices

A one-time entry check decides whether to deliver now. Enabled leases renew roughly once a minute with a 150-second lease window. The project's concurrent-run limit allows 1–10 active keyed leases per key, default 1; it does not let a bound key use extra devices. An old run can retain its slot until release or expiry. Keyless runs do not use keyed leases.

On denial or an unrenewed lease, the runtime can cancel the root task. Child tasks you start should cooperate with VAMPAUTH.is_active() or VAMPAUTH.assert_active(). Database-backed advisory presence survives app restarts until expiry, but it is observation, not lease enforcement or a deduplicated user count. Read sessions and concurrency.

Test a harmless payload before distribution

This is an illustrative test recipe, not a recorded successful game-client run. Create your project and a manual test key, publish this original example, then copy the actual snippet from your dashboard into a supported client.

print("Vampauth demo payload reached")

• With key checking and binding enabled, verify the valid non-FFA key on its allowed device. The print marker confirms that line was reached, not that an entire application completed.
• Try an invalid, expired or banned test key. Confirm denial before the payload marker. If testing first-use expiry, account for when the timer actually starts.
• Try a different device ID with the bound test key; expect a mismatch. An authorized reset permits a new binding without renewing the key.
• For group routing, use harmless distinct Standard and Premium markers and test both keys plus an ungrouped key.
• If leases are enabled, test a denial during the run and verify both the root task and your cooperating child tasks stop as intended. The single-print payload alone cannot prove that.

Record actual client/version, enabled settings and observed outcomes; redact keys, device IDs and tokens. Diagnose loader errors before changing the access policy. Network or compatibility failure is not a successful denial test.