Keep in mind, this is only a handshake demonstration, and none of the anti-cheat detection features are currently active. Your objective is to either disconnect or bypass the anti-cheat without triggering a server kick, send a false positive to the server, or replicate the handshake process to delete the anti-cheat from the client. Client-side anti-cheat logs can be accessed by pressing F9.
I’ve recently come up with a new idea for an anti-cheat system that combines client-side and server-side measures. Now, I know what you’re probably thinking: “Client-side?! That’s risky!” But hear me out this isn’t your typical client-side anti-cheat. I’ve put a lot of thought into this and developed a custom encryption system that makes it much harder to exploit.
How It Works
Here’s a quick breakdown:
1. Encrypted Communication:
The client sends data to the server via Remote Events, but every message is encrypted with custom encryption.
The server decrypts and verifies these messages, and any instructions sent back are also encrypted.
2. Integrity Verification:
To prevent exploiters from tampering with the Remote Event (like deleting or manipulating it), the server sends an encrypted “ping” every 2 seconds.
This ping contains custom instructions that the client must encrypt and send back, proving that the client-side anti-cheat is active and responding.
If the server doesn’t receive a valid response with the correct encrypted instructions, it will terminate the player’s session. This ensures that even if an exploiter deletes the client-side anti-cheat script, the server will detect the lack of response and take action.
3. Client-Side Monitoring:
By operating partially on the client, the anti-cheat can monitor several aspects in real-time (e.g., movement speed, tool usage, etc.).
When suspicious behavior is detected, the client sends an encrypted message to the server for verification and possible action.
4. Obfuscation:
To protect against reverse engineering, the client-side script is obfuscated, making it significantly harder for exploiters to view or replicate the encryption logic.
Why This is Different
This approach ensures that, even if the client-side script is accessed, it’s not straightforward to break. The constant ping-and-response system means the server is actively checking for a live anti-cheat presence, which is challenging to bypass without deep knowledge of the custom encryption and obfuscation.
Open to Feedback
I’m really excited about this idea and would love to hear your thoughts! Are there any potential bypasses or weaknesses I may have overlooked? I’m looking forward to any suggestions or feedback, as I’m eager to improve this system.
This seems like a very solid attempt of making an anticheat. However, I’m concerned about the naming of the Remote Functions. Are they encrypted so that the exploiter can’t write they’re own code that fires the Remote Functions?
The remote functions do not need to be protected as all the information being passed to the server has to be encrypted by the custom encryption so all the information being passed to the server is encrypted. therefor the remote functions do not need to be protected.
Encryption is great. Using complex algorithms that are very difficult to replicate are also great. If you are really just sending information to the server in a couple big sweeps with encrypted data… that will not work and will be easily bypassed. You will need vast quantitative data with large amounts of remote events and other instances being spawned and deleted to prevent the client from understanding how your anti cheat works. Otherwise it is fair game. Remember… anything a legitimate player can do, an exploiter can also do and then take that information and do it in a way that benefits them more than any legitimate player.
Its not bypassable because the server pings the client every 2 seconds and if the client doesnt respond with a message encrypted with custom encryption that follows the prompt that the server sent then the player gets kicked
that’s good but a lot can happen within two seconds you know. Exploiters that open dex explorer cannot see instances that delete themselves in less than 1 second and encryption makes it so the person can’t read the names of things. My idea is better because exploiters can still copy the encrypted data by copying the string and number values you use. Replication is your best friend. The only thing they could do is put a for loop over all folders of the game and check to see what’s being created and deleted. But keep in mind that is likely to lag their game extremely bad and where are they going to possibly hold all that information without a flood making it impossible to read(There’s a common theme here… spamming anything the exploiter can read = more impossible for them to bypass)
That wouldnt matter as they couldnt for example in 2 seconds idk destroy the entire map for the entire server and if they could do that then my game would have severe vulnerabilities that would need to be fixed. also as i stated before the anti-cheat cannot be bypassed as when it stops responding with an encrypted message to the servers encrypted ping requests the player will be kicked
Thank you for the explanation! I think the idea is absolutely genius. I had to think that through for a minute. I totally get how it works now. Absolutely great idea. The only thing you need to be worried about at all costs is that they don’t find a way to bypass it because if they do… I can promise you that they will go all in on your game because anytime a game uses a strong anti cheat(like the game Jailbreak), the cheater’s get very angry and want to do terrible things to your game because of it.
I think making a client sided script is a bad idea. Players can modify anything on their PC. I think the ping fix that (hopefully). An approach I’d do is that once a player joins, I’ll immediately attach a part thanks to a script, since players can’t modify anything other than their own data, they won’t be able to tamper the part. I’d be able to check everything (speed exploit = higher part velocity, fly exploit / super jump exploit = part in the air on an extended period of time, etc…)
How does the remote encryption works ?
I’m scared that they won’t need to find the encryption to exploit. They’ll try every remotes that they find until they find the correct one. For example I don’t need to find the encryption to give myself infinite money, I just open a Remote Spy, gain some money, the remote spy tells me that the remote and data is lekhh0:FireServer(OOIeuhh), I make a script out of this giving me infinite money.
The ‘CanSecurity’ remote event doesn’t need to be hidden because the server only responds to messages encrypted with custom encryption, so any attempt by an exploiter to send information through it will fail if it’s not properly encrypted. I referred to it as ‘unbypassable’ to emphasize that direct bypass attempts won’t work. I’m also not concerned about modification attempts since the client-sided anti-cheat will be obfuscated, and if a player doesn’t respond to the ping (encrypted with the custom encryption) in time, they’ll be kicked.
Yes but won’t the remote spy automatically detect and show the encrypted version of the data sent to the server sided script, thus making it uneffective ?
Also I suggested the idea of attaching part because then you won’t have to send a ping everytime, since it’s server sided.
He’s absolutely right because in the event someone discovers a bypass to this anti cheat system, it will not be related to encryption. I can tell you exactly what it will do. Theoretically speaking it would fully spoof the connection between the client and the server to make the server think that it’s still pinging the client every 2 seconds when it isn’t. Exploiters have the upper hand… the only upper hand you have as the developer is the complexity, the length of time, and the measure of how vast your quantitative data is with your anti cheat.
I don’t understand.
You want to send data to the server.
The data must be encrypted by the client.
Then the script will decipher it.
Then the remote will execute.
Now if I have the encrypted version of the data and I send it to the script, won’t that execute the remote ?
Custom encryption? I would use a known solid ciphering algorithm if I were you. If you want something lightweight, XOR encryption should be enough. However if you wait a little bit, @daily3014TheGod and @XoifailTheGod will release an AES 256 ECB algorithm in pure Luau, using buffer and other Luau-only features.
Additionally, if you want to obfuscate your script, make sure you use a good Luau obfuscator such as Luraph, or if you have good knowledge about the Luau virtual machine, and have time on your hands, try to write one yourself.
The server periodically sends a “ping” request to the client, which includes an encrypted, randomly generated 92-digit code and instructions for the client to return this exact code within a specified timeframe. Upon receiving the request, the client verifies that the request is encrypted, then decrypts it to retrieve the code. The client then re-encrypts the code and sends it back to the server. This system ensures that exploiters can’t simply mimic or replay responses, as each ping request uses a unique code that must be accurately returned in its encrypted form. This prevents exploiters from intercepting and responding to the ping requests without proper decryption, adding a layer of security to the interaction.