Sure, people have written projectile aimbots in the past, but because of the way my game is designed it’s not an issue, aimbots can be played around because all the weapons are projectiles. Aimbots are no longer an issue in my game, even if everyone has one.
Fair enough. Anyways, imma go. Cya!
1 Like
I have a copy of the tutorial you stated however it’s A) translated into Welsh B) I’ve been asked not to share it.
The usage of passwords to secure remove events is not advised based on how easily it can be cracked. You may do so but be aware that it may not be secure.
1 Like
To clarify, not MAY not be secure, it isn’t.
Create a remote event the tells the server whether the clients in the minigame. When the client is in the minigame, restrict them from doing anything else on the server to avoid them putting it permanently into minigame mode then playing the game as normal. Throttle the rate at which the exp event can be triggered.
Not completely unhackable, players can still exploit it to ‘100%’ the minigame, but they will be able to do that always without some really advanced security algorithms, and it’s more secure in the long term than what’s being proposed here.
Using a key for your remotes isn’t the greatest practice, I wouldn’t recommend doing it at all. Exploiters can find out the key and send it to the event. Instead, validate client requests on the server.
i.e. Team Changer
Player clicks GUI button to change to red team, remote event is fired with Red team. Server sees if they are in group A and Red team isn’t full, then changes team if eligible to hop over.
People say don’t trust the client because that’s one of the few strongest methods of keeping an exploiter from running things in your game. So you can’t really push away that statement.
4 Likes
You could try having the client generate a password first thing and fire it to the server. The server can then assume that same password as long as the client stays connected.
local password = math.random()*1231*wait(1) -- or anything math
ReplicatedStorage.Network.Event:FireServer(password)
Of course no other scripts would have access to this password, and this relies on having the variables secured locally.
Hackers can read whatever is sent through a remote event, they’ll just take the password.
If you use a password for remotes at all, which isn’t recommended, have the server change the password every 30 - 60 seconds.
4 Likes
There is no good way to protect your remotes against exploiters. The only way to make your game secure is to never trust the client, as I’m sure you’ve heard before. Never assume that any data coming from the client is correct. That being said, you should also never try to retrieve data from the client. This is bad for several reasons.
Adding a key to your remote, regardless of whether it is a static or dynamic key, is a terrible idea. If your game is vulnerable, rewrite it. You shouldn’t expect protecting your game from exploiters to be easy.
4 Likes
Actually, exploits can both read and set local variables using a reimplementation of the debug library. They can also replace the function that is returned when you index FireServer, which can be used to “log” that key.
1 Like
Just have a function that scrambles the player’s and remoteevent’s name consistently so that the server can generate it and match it. And maybe make this function automatically change every hour or something. Dont need to do more than this because if a player can access the function that generates this password, they’ll be able to fire whatever they want anyway, so it comes down to not trusting the client.
In the end, all of this is for fun(and I do pointless stuff thats similar just for fun myself), but focus on never trusting the client, thats the real task.
2 Likes
Passwords are kind of useless as the client can see it getting fired as an argument. You should instead verify the parameters on the server-side are the right type of value(I’ve had experience where exploiters would spam fire remotes with nil argument and crash the server due to the nil values causing errors). You should then do a a check on the server to verify that the client is telling the truth.
Example:
Bad idea: BuyItem:FireServer("ItemName",200) --don't trust the client to change their own money
Good idea: BuyItem:FireServer("ItemName") --have the sever check the cost of the item the client wants to buy and verify on the server that the client has enough currency for it
10 Likes
I saw a thread a few months ago, I can’t find it, and someone on there was describing what they were using for security. From what I can remember the password was “(Hower Many Times The Client Has Fired A RemoteEvents In This Server)*A Huge Number” And that would essentially make pretty good security as the exploiter will never know how many times the client has fired remote events. I would still use good security and checks on my remote events, this is just another wall of defence I wanted to have.
2 Likes
This stops people using remote event trackers, NOT people reading your code.
I suppose in this case you have to trust the client. Just ensure the player can’t get more XP than possible, so exploiters, could only get the maximum XP, no better.
1 Like
I actually did this in one of my older games before I found out better options you can always hide a password if you need to access it client side then I advise hiding it deep inside of players folder somewhere and name it value create it as a number value then use math.random(100000000,999999999) when the server loads up and anytime that the value has been seen by a player. Exploiters will only see the random number and will not have a path to that value they won’t know what it is
Other then this I advise you to put all your shop items inside of replicatedStorage as long as you have an FE game and to add values of the shop items inside of each item with the price of the item. You can resend the shop weapon price to the server if you wanna catch exploiters and kick them for attempting if you want by checking if the price was increased or decreased from the real value from the price you set into the item. Alternatively instead of simply kicking the player you can set a value that goes through datastore one the attempts that the player has exploited and if the number goes above 3 then use plr:Kick(“The system has detected that you were exploiting and you have been perm banned”).
Note that people can’t force others to exploit they can only exploit themself as long as your game is FE.
2 Likes
“Three strikes and you’re out” is how most Roblox games do it. I set it to overdrive. Mess up once, you’re perma banned, and you don’t even get a good message saying what you did wrong. I run extensive unit testing on my remote events to make sure an innocent client can never be caught.
3 Likes
A fun thing to do is to create a remote called EnableGodMode or something and then just kick anyone that calls it. It’d be really fun to track it and see how many players fall for it.
12 Likes
Shhh…don’t give away my secrets 
(I have a lot of honeypot things like that, my game’s not out yet to have any data on them, but I’ll make sure to release them in a long blog post! Shhh)
3 Likes
Found a model that may interest you, maybe you could see how it works and then generate your own strings/passwords.