Keeping your Game Secure: Part 1, Protecting Remotes

Keeping your Game Secure

Hmm what does that mean? Keeping your Game Secure (KGS) means protecting your remote calls, proximity prompts, preventing backdoors, etc. This guide/tutorial will teach you the basics of server-side protection for your remote events.

Preface

You have probably heard the saying from experienced developers, “never trust the client”. The reason why you never trust the client is because exploiters and cheaters can modify and manipulate what the client can see or have. This is why server-sided checks are so important, you can make sure the client isn’t manipulating things.

Protecting Remotes

Remote Events are the most commonly exploited, and most easily exploitable. The client can fire any of these events, because Remote Events were designed for clientserver and vice-versa. How do we protect our remotes? It’s pretty easy actually, and I’ll start with the most common example of this.

Preventative Action

Store System

A user clicks a button to purchase an item, now if you did the checks if they have enough money on the client, the user could easily just make it seem like they have more money than they really do and just purchase any items they want. This is why we have to check on the SERVER if they have the money.

Take this example of using the server to check:
Some code may be arbitrary, but this is just an example

-- Client

local btnPurchaseItem: TextButton = some.path.to.button
local reEvent: RemoteEvent = some.path.to.event

btnPurchaseItem.MouseButton1Click:Connect(function()
    reEvent:FireServer(item.Name)
end)

Now we do not want to pass the cost of the item through the event, because again the client can manipulate the cost rather than manipulate their money. The exploiter likely wouldn’t change the name of the item because it wouldn’t do anything for them.

So we check on the server what the cost of the item would be then check if they have enough money for it.

Example:

-- Server
local reEvent: RemoteEvent = some.path.to.event
local itemPrices: {...any} = {...}

reEvent.OnServerEvent:Connect(function(player: Player, itemName: string)
    local itemCost: number = itemPrices[itemName]
    local playerMoney = -- Code to get the player's money

    if playerMoney >= itemCost then
        -- Code to purchase // Give the item
    else
        -- Do nothing here, or tell the player they don't have the money.
    end
end)

As you can see in this example we are making sure the player has the money and making sure we grab the amount of money the player has on the SERVER, and NOT on the CLIENT. This way we can make sure the client doesn’t modify anything in order to purchase just anything they want without working for it like everyone else playing. Although this won’t detect cheaters, it will discourage and prevent them from cheating the store.

I will be writing more guides on different ways to keep your server secure so keep an eye out. This is just my first one and I want to see how it’s recieved before I spend more time writing out another one. I understand that this is a short tutorial.

EDIT: Apparently there’s a lot of people complaining about this post which sucks. However this several part tutorial is for newer developers who are just getting into scripting. This is not for the advanced people who already know all of this. Do keep in mind that if this goes over what you already know then it’s not for you, either post something positive, add to the discussion or don’t comment at all. It’s getting a little tiring seeing all the negativity on posts like these just because you guys assume that no one else needs these guides. Who cares if there’s a thousand other guides? My guides are going to go more and more in-depth as we go on.

tldr; don’t comment unless you’re going to be positive in some way. being consistently negative hurts the community and makes you look dumb.

14 Likes

orrrr just put ur entire game in an actor in replicatedfirst and parent it to nil and 99.9% of people will give up instantly

8 Likes

What is the 0.1%?

.

2 Likes

people that know about the method, remotes wont be visible on their remote spy so they will think the entire game is serversided and even if they do know about it they cant do anything since no executors can find the script or do anything to stop or view it

2 Likes

I want all the details, this sounds interesting

2 Likes

i dont have all the details related to the reason why actors disappear after being parented to nil but the reason remote spys dont work is because actors have their own game metatable and functions so hooks do nothing

2 Likes

This is supplementary to having actual checks. There isn’t really an “or”, if you only do obfuscation methods like messing with actors to get multiple Lua states inevitably your game will be hit hard once a single person figures it out.

OP’s approach is more robust.

5 Likes

Just remember this is just Part 1, I will be going over many more options on how to protect your game in the future. It will get more and more advanced as I go, this is just to get beginner devs interested and educated in the basic concepts of security.

2 Likes

no one will be able to figure it out without a auto execute faster than replicatedfirst doing more things on the client is better than doing stuff on the server, that method is universal + unbypassable (as of now) even synapse couldnt find the actor with v2, v3 could but thats discontinued actors are the way to stop exploiters completely

3 Likes

everything fun and games until getnilinstances and decompile comes in (and because exploits are dead there are barely any mobile exploits with decompile function so ggs you kinda still won and defeated mobile exploiters)

2 Likes

getnilinstances wont show the actor

1 Like

This causes bad inconsistency with script parents for some reason. I think it’s because scripts are special when it comes to actors. I found that the script’s parent is nil randomly when in the resumption cycle of reparenting the actor to nil. This would hurt your game more than exploiters.

This is kind of insensitive. There are so many new scripters starting all the time. They will not know this!

3 Likes

easily can be searched on the dev forum “How to protect your Remotes?” There doesn’t need to be millions of posts about this.

1 Like

This is the first of the series, so unless you actually have something constructive to add don’t comment.

1 Like

Let is be the last of the series as well. There’s too many of these posts regarding this. What’s the point of making another post that’s basically the same information.

It makes no sense!

1 Like

it will still be linked to the actor even if script.Parent is nil + actors were made for performance so idk how it would hurt your game

1 Like

To be honest, after reading all of these “anticheat post”

I can conclude that only the best exploiters can make the best anticheats

2 Likes

It caused random errors only in public servers, so I can’t use that anymore.

1 Like

what errors were they ive never seen one from doing it

1 Like

The script parent is momentarily nil for some scripts that were in the actor, even if that seems impossible.

image

1 Like