Protecting your remote events from exploiters

  • Yes! You finally learnt how to use Filtering Enabled now! But an issue exploiters can fire those remote events now. How can you stop that? Well, this tutorial is supposed to teach you how to protect your remote events.

    Method 1
    A very easy method is making the server check for requirements example:
    A buy button is clicked and it fires a remote. Instead of the local script checking for the requirements you make the server check the requirements instead. This can stop many exploits.

    Method 2
    Use passwords on your remotes. The client will fire with an extra argument with the password Example:

    remoteEvent:FireServer("Argument 1", "Argument 2", "PASSWORD HERE")


    remoteEvent.OnServerEvent:Connect(function(arg1, arg2, password)
    if password=="PASSWORD HERE" then
    -- code here

    Remote spies can be a problem as they can see any arguments sent through a remote event. To combat this use ciphers and use a method called salting. This will combat all remote spies.

    Method 3
    Hide your remotes. This is probably a last ditch effort but hiding your remotes so exploiters cannot find it or access it. There are various methods of hiding remotes that I do not know as of YET.

    Remote spies
    A remote spy is a local script that an exploiter runs to access all remote events arguments when fired. This can be used to detect passwords or understand how a remote would work so they can fire them without any errors or exploit detection.

    A client is the player's Roblox window/application. Everything on the client cannot replicate over to the server unless they used remote events.

    The server is the main hub for connections between clients and manages the game. If something happens on the server it will replicate to all the clients connected to it.

  • Global Moderator

    Only method one is effective lol.

  • You do not use a salt in encryption and encryption is useless in this case since the client knows any secrets. Encryption is not used to secure the client side.

    Method 3 again is pointless since they have access to all of the memory and can find the remote events.

    Method 1 should already be in place and all developers know about this.

  • There's already a guide about using RemoteEvents properly as well.

  • yeah pretty clueless op. here's some real tips.

    1. Never trust the client. Common sense.

    2. Avoid remote-spys by networking in pure Lua as much as possible. event:FireServer() is always visible. event.FireServer is visible, but not if you do it while the client loads. The actual FireServer function is pure lua; invisible.

    3. The newest spys will see everything regardless. Obfuscate your remote names & your data arguments as GUIDS. event1:FireServer("a") is useless if a different server requires event2:FireServer("b"). Another technique is to flood spys with dummy logs. Not too fast or lag.

    Jailbreak does all of this amazingly.

Looks like your connection to Scripting Helpers was lost, please wait while we try to reconnect.