(SOLVED) Hackers are taking over my game

Help and Feedback Scripting Support
#84

I am currently using the one from ForeverHD.

#85

could you please share the kick player remote code with us so we can narrow down the reasons?

#86

Ohhh, there is a script for your game published 14 hours ago on v3rm…
They can kick anyone using ReplicatedStorage.KickPlayer remote.
Remove it asap.

#87

Are you sure it’s an account and not a group named “ForeverHD”.

#88 
local mess = "whatever message here"
local repsto = game:GetService("ReplicatedStorage")

for i,v in pairs(game.Players:GetPlayers()) do
   if v.Name == game.Players.LocalPlayer.Name then
   repsto.KickPlayer:FireServer(v.Name, mess)
   end
end
#89

Even if it’s the real model it doesn’t mean it’s 100% hack-proof. Get rid of it until they fix it.

#90

we are aware but i cant assist if i do not know the faulty code first

#91

so there is a message, that means the kick player remote is the one getting abused

#93

You already said this, you don’t have to repeat yourself.

#94

we are aware, we are trying to assist him to fix it

#95

@eatabler0ck Could you read my PMs? I have some information.

#96

Just remove ReplicatedStorage.KickPlayer for now to stop the exploiters, then you can add sanity checks and fix the vulnerability.

#97

I removed the KickPlayer event, I really hope this works.

1 Like
#98

You can easily fix this problem to check if its you who fired the remote event.

#99

It would work, but you can still fix it without taking things to these measures. I believe that there is indeed an error in your server script which is connected to the KickPlayer event, that is allowing exploiters to get through it (the script is not properly checking if the userId of the player who fired the event is yours).

#100

If the exploiters are using the kickevent to kick everyone, you can do checks to ensure that only you (and other admins) can use the command. In a serversided script, put your userId into a table and when the event is called, loop trough that table. If the user id of the player who called it isn’t found in the table, then you can prevent the command from firing and ban them (if you have a ban system). Otherwise you can kick them I guess?

#101

Guys, it’s fixed! I removed the KickPlayer remote and am now using HD Admin for admin commands. Thank you all for the help and support!

6 Likes
#102

I’d recommend a singular LocalScript for your entire game framework as it is safer and more reliable in helping the stop in exploiters. Your choice of checking ScreenGui children in the PlayerGui is inefficient because it allows the LocalScript to simply be destroyed.

ScreenGui objects are typically greated under CoreGui or in a custom UI service that is hidden from the DataModel.

You’re also handling your command script from the client. It’s good you checked the UserId on place start, but now other players can see the source & see the event firing from there. Though not all exploits support a decompiler, Synapse X does (which is the most popular at the moment) and obviously players will eventually find it (though not very hard if your script is located in PlayerScripts). This all goes back to my original proposal, you’d want to create a singular LocalScript and try to manage the entire game through that. While it may not be trivial to do so, you’ll have to keep in account for all the potential bugs that could occur.

2 Likes