When E2EE is enabled on a license product, all API responses (both success and error) are encrypted with AES-256-GCM. Your software decrypts the response locally using a shared encryption key.Documentation Index
Fetch the complete documentation index at: https://docs.rmz.gg/llms.txt
Use this file to discover all available pages before exploring further.
Why Use E2EE
Without encryption, an attacker can intercept or modify the API response before it reaches your software. Common attacks include:- Man-in-the-middle — intercepting and tampering with the response in transit
- Local proxy spoofing — setting up a fake local server that always returns
"success": true - Response sniffing — reading license details, plan info, or activation data
Setup
Copy the encryption key
After saving, copy the encryption key — a 64-character hex string (representing 32 bytes).
Encrypted Response Format
When E2EE is enabled, the API always responds with this structure (regardless of success or error):| Field | Description |
|---|---|
encrypted | Always true when E2EE is active |
payload | Base64-encoded AES-256-GCM ciphertext |
nonce | Base64-encoded 12-byte initialization vector |
tag | Base64-encoded 16-byte authentication tag |
Decryption Steps
- Base64-decode
payload,nonce, andtag - Convert your 64-character hex key to 32 raw bytes
- Decrypt using AES-256-GCM with the key, nonce, and tag
- Parse the resulting plaintext as JSON — this is the same response you would get without E2EE
Decryption by Language
- Node.js
- Python
- PHP
- Lua / FiveM
Uses the built-in
crypto module. No dependencies needed.Key Rotation
You can rotate the encryption key at any time from the product edit page in your dashboard. When you rotate:- A new 64-character hex key is generated
- The old key stops working immediately
- You must update the key in your software and push a new version to your users
Security Considerations
What E2EE protects against
- Intercepting and modifying API responses in transit
- Setting up a fake local server that always returns
"success": true - Sniffing license details, plan info, or activation data from the network
What E2EE does not protect against
- Reverse engineering your compiled binary to extract the encryption key or bypass the check entirely
- Memory dumping at runtime to read decrypted responses
- Patching your binary to skip the verification call
Recommendations
- Obfuscate your code — make it harder to read and reverse engineer
- Embed verification deep in your application logic, not in a single easily-patchable function
- Use native compilation (not interpreted scripts) when possible
- Combine license verification with other integrity checks
- Don’t store the encryption key as a plain string — derive it at runtime from multiple values

