Remote Protection


  • Filtering Enabled is great for stopping exploiters. If you don't know what Filtering Enabled go to this wiki. What many new scripters may not know is exploiters can still fire the remotes so if you forget to check for a vulnerability in your remotes then exploiters can use them. Luckily we can protect us from them multiple ways.

    Method 1
    Make the server side check if the requirements are met.
    This is very commonly used as it is the easiest and most reliable way of protecting your remotes from exploiters.
    For example, you just made a nice shop system and this is your code:
    Client:

    script.Parent.MouseButton1Click:Connect(function()
    if game.Players.LocalPlayer.leaderstats.Cash.Value>=200 then
    game.ReplicatedStorage.ShopRemotes.BuyItem:FireServer("100 meme cash")
    end
    end)
    

    Server:

    game.ReplicatedStorage.ShopRemotes.BuyItem.OnServerEvent:Connect(function(plr, buying)
    if buying == "100 meme cash" then
    plr.leaderstats["Meme cash"].Value = plr.leaderstats["Meme cash"].Value + 100
    plr.leaderstats.Cash.Value = plr.leaderstats.Cash.Value - 200
    end
    end)
    

    This script is easy to use to get free meme cash as the server does not do a check if the player has enough cash for it and is not using an exploit firing to just get free meme cash.
    Here is a better fix:
    Server:

    game.ReplicatedStorage.ShopRemotes.BuyItem.OnServerEvent:Connect(function(plr, buying)
    if buying == "100 meme cash" and plr.leaderstats.Cash.Value>=200 then
    plr.leaderstats["Meme cash"].Value = plr.leaderstats["Meme cash"].Value + 100
    plr.leaderstats.Cash.Value = plr.leaderstats.Cash.Value - 200
    end
    end)
    

    The only change I added is on line 2 I added " and plr.leaderstats.Cash.Value>=200" as the server checks if the player has enough cash to do the transaction. This method can be used with other methods to add the extra level of security

    Method 2
    Rename your remotes to something crazy every second.
    Example:
    Server script:

    while true do
    wait(0.5) -- ALWAYS PUT IT BEFORE
    game.ReplicatedStorage.RemoteEvent.Name = math.huge()
    end
    

    Then to obtain it without an error use this

    local event = game.ReplicatedStorage.RemoteEvent
    wait(2)
    event:FireServer("Test")
    

    This will stop exploiters as they cannot obtain the remote event to fire it.

    Method 3
    Use passwords. This is very inefficient as remote spies can read the passwords but still works if you know how to do it correctly. Make the client send a salted and hashed password so if an exploiter were to use remote spy they could not get the password then make the server decrypt the sent password. If it is correct it does the function if not it doesn't and either does nothing or kicks the player.

    Method 4
    Use dummy remotes. Make a bunch of dummy remotes tricking exploiters into firing them. They can be used to find exploiters and kick/ban them.


  • @iRexBot

    Nice, but I personally see Methods 2 and 3 useless.

    A hacker can access the object local variable and discover it very easily. Anyways, if you do that and change the name server-side it would error, because if a player joins after the script runs, it will error at line 1

    local event = game.ReplicatedStorage.RemoteEvent
    

    because the event will not have that name, as you already changed it.

    And at method 3, the hacker can see the "salty hashed" pass and use it, anyways.

    The most usefull ones for me are 1 and 4, specially 1.
    FE basically does that.
    "Never trusting clients"


  • @iRexBot

    Anyways nice post, upvote.


  • @Aimarekin Method 2 and 3 are usually last ditch effort but method 2 is effective.


  • @iRexBot

    But then, you need to have an object value reference instead of a local variable, because then we have got that glitch.

    Anyways all data is stored which means all data stored is easily accessible.


  • @Aimarekin

    And with an object value it is even easier to hack.


  • Adding your shop items into a table and adding a price is really efficient and nice. It's safe if you make it to where it checks if the item is in the table and is that said price.


  • @Aimarekin

    I understand the efficient and nice, but why safe?

    A hacker can access a variable no matter it is a table or not, or wether an object value or a local variable.
    (Of course, if it is locally)


  • Methods 2-4 are dumb.

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