I’m making a FPS game and ive found some hackers who have been firing remote events, like “Hit” which handles damage. Does anyone have good ways of verifying remote events or, at least making it harder for them to fire? (making confusing parameters is useless because the hackers have gotten into the clients script)
Implement sanity checks on the server to verify if what the client sends even makes sense.
For example:
Is there a direct line of sight between the character and the target? If no, then do no damage.
Is the client firing the event more often in a short period of time than the gun the player uses has ammo? If yes, the kick the client.
Is the player character suddenly moving hundreds of studs within one frame? If yes, kill the player.
Also ideally you want all game logic to happen on the server and only make the client move the character and do the visuals.
11 Likes
You can’t stop them, but you can make your remote events smarter. You shouldn’t really allow your remote events to do things such as damaging anyone it wants for this reason. If you have a sword, apply a damage on touched code on the handle from the server. The same thing goes for projectiles. If other players can already see them, then you can just go ahead and manage them from a regular script on the server without the use of remotes. You could use CollectionService instead to tag the projectiles and then apply the proper code to them as they’re created.
If you feel that you’re for some reason in a situation where you absolutely need to use remote events to apply damage (can’t really imagine why) then have it check if the firing client has a proper weapon equipped and is actually in a situation where they’re capable of hitting the other player.
You should always apply the proper checks to your remote codes. If, for instance, a player gets into a vehicle and presses a key to turn on the lights, you should have the server script check for whatever vehicle the player is in rather than allowing the client to pass on any vehicle it wants to the function (I have a friend that did this. Don’t do it!)
29 Likes
I think this is a fun way to do it
on top of your LocalScript
script.Parent = nil
this will make it a lot harder for Exploiters to read your LocalScript 
And also always check on both Server and Client not only for Security but for performance
RE - RemoteEvent
let’s say a pistol is 100 $
instead of sending a RE to the Server you should check in the Client first if the player has enough Money so the ServerScript is not disturbed when it’s not necessary.
7 Likes
Don’t fire events to handle damaging. You should do all checks from the server, rather than telling the server to damage something. You should tell the server where the player’s mouse was and handle checking from there, rather than the client checking it and telling the server to damage a player.
6 Likes
A lot of people just have open events with no validation allowing for this type of exploit.
2 Likes
Exploiters don’t have to read your code to find out what events they can fire. They can just look at ReplicatedStorage and then they’ll know the names of all of your events. From there, they can use a RemoteSpy script to see how to fire it correctly.
script.Parent = nil will hide your script from most people, but will not stop firing of events.
1 Like
This is actually a complete myth; it’s only used on modules to prevent stealing, but that’s because of how they’re handled to begin with.
3 Likes
Yeah but the point is that they don’t know what key to use
Example
RE:FireServer(‘BuyItem’,Item)
etc
if they can’t read the script they will never know what the key is, correct me if I am wrong tho idk how remote spy works.
I only have 1 RE and 1 RF for my entire game and I use Keys to determine what function to call when the Remote is fired.
I thought the OP was using “Hi” as a key so I didn’t explain further but I missed read, “Hi” is the name of the RE.
1 Like
So they can still read my scripts from nil?
how does it work, I believe all of us would like to know more about this.
I thought that, since the script is parented to nil there is no reference to the script so how can they reparent it back to a readable place or even read it?
1 Like
As long as it exists somewhere in memory exploiters can find it
2 Likes
Oh you are right, but it’s really really hard right?
I mean the only place I can think of that has a reference to the script itself is the script itself, if you don’t know what I mean then
even if you do script.Parent = nil
you can still do script.Parent = (anywhere that is not nil)
but other than that how can the Exploiter find a reference to the script in nil with another script?
1 Like
I’m not sure about all of the details but i think some exploiters can dump upvalues and sources of scripts (some even say that they can access nil itself as a parent (see nil’s children))
3 Likes
That’s really scary but I think it’s Super Difficult or even Impossible to do, right?
I mean out of All Roblox dedicated Exploiters how many of them would be able to do this?
Do you knows someone who would know more about this? I would love to learn more, I don’t want my scripts to be stolen.
1 Like
Not very difficult at all. Most exploits nowadays have a feature to read all instances from nil, so even the basic script kiddie could get it.
Bottom line: all LocalScripts/ModuleScripts that ever touch the client can be stolen.
6 Likes
that’s really bad, so the only true way of preventing my scripts from being stolen would be using a Private Module?
2 Likes
Server scripts can’t be stolen (via conventional means). If the private module is ever used in the client though it can also be stolen.
As for the remote spies stuff I’m fairly sure it doesn’t need to know where your scripts are to get your key.
2 Likes
I am not really concern about Exploiting my RE because I always check on the Server.
I don’t want my LocalScript and Modules to be stolen tho, how can I prevent this?
What are you methods?
(Sorry if this is getting off topic but it’s still kinda the same thing here, we are trying to prevent Exploiting)
1 Like
There are no practical methods for it, sorry. It’s just something that as developers we have to put up with anyways.
More on topic to this post, the most you can do is to practice a proper client-server model.
1 Like
Anything that’s on the client has to be in the client’s memory, and anything in the client’s memory can be read by an exploiter. The only way of preventing localscripts and level geometry from being stolen is to not have any.
1 Like