This… might be really dumb,but would it be good to secure events and place them on a secret parent?
to prevent exploiting?
Or this is actually not a good way
1 Like
It wont really do anything, since they have access to everything in the explorer except places the client can’t reach.
2 Likes
But, for example, attempting to hide it?
Or still nothing ;/
2 Likes
arent remote events and such supposed to prevent exploits?
1 Like
A lot of the time the attacker either:
- has explorer access, in which case this may slow them down but won’t stop them.
- is reading code that is obfuscated anyway (a gross oversimplification) in which case it doesn’t really matter where in your game the RemoteEvent is.
If you’ve secured your game right the attacker can’t do anything with your RemoteEvent anyway.
1 Like
I’m not good AT ALL with exploiting, I only know some stuff like RemoteSpy, but, a client can always fire a remote event with the proper argumemnts?
1 Like
I’d recommend changing the remote events name every frame. Makes exploiting it a lot harder
1 Like
But than, how am I supposed to call them?
I would have to store them on a table with the names of em and fire the events from there?
like
local ALLEVENTS = {
'hi' = game.ReplicatedStorage.event -- before changing name?
}
1 Like
With any arguments in fact. That’s why, on the server, you should be verifying everything independent of the client.
This is an awful idea - it’s adding n operations every second, and is really easy to overcome by simply storing the address of the RemoteEvent in memory, rather than accessing it by name each time. Do not do this.
2 Likes
Yeah, but there’s stuff I might need to pass arguments on, like a shop, or, well a lot of stuff, never tried to make anti cheat or similar.
1 Like
How can they store the address if they can’t even get the path in the first place?
1 Like
Simple answer: Don’t trust the client, check everything on the server. Cash all that stuff
1 Like
Again, to reiterate, do not follow the advice @jake_4543 gave there. However, you should be storing the RemoteEvents in variables anyway, rather than calling them by name each time - it’s far more efficient if you reference them at least twice.
Reading https://developer.roblox.com/en-us/articles/Roblox-Client-Server-Model and then https://developer.roblox.com/en-us/articles/Remote-Functions-and-Events should give you a solid understanding of how this all works, and therefore how to make it secure.
Don’t think of this as writing an anti-cheat. You want the system to be secure by design, not by cobbling together some exploitable code and then throwing band-aids on it.
They can get the address the same way the client-side scripts do, because the creator would have to create some way to find the RemoteEvent for the game to actually work. Whatever workaround the creator uses, the hacker uses.
Hey so,
I’ve read this before, but this wouldn’t do much, as the client can still fire a remote event,or do more exploiting aswell
Could you suggest a way to attack that particular model?
It still stops them from getting items for free.
And remote events and remote functions automatically pass through the player so use that player to get the data, cause if you don’t they could take money out of someone else
I’m doing same for a lot of Server side, I’ll do checks only server side,but for example, try to fire a remote event on bloxburg, even if you have the proper arguments, it bans you
it’s like, they knew where is it coming from, if it’s from a gui, from outside, it’s amazing.
They might have some sort of detection logging, I’m not sure like as soon as you want to fire a remote event it logs is then if it fires and the log isn’t found it bans you maybe I’m not sure? But I’ll try figure out how they do that.
My friend made a system like that but I sadly lost contact with him around a year ago