So now your average run of the mill script kiddies are running around hacking games using getsenv. Which if they’ve decompiled your code and know your variables and functions, they can set them to whatever they want during runtime. Literally modify any code they want.
How are developers supposed to defend against something like this? Is there some kind of method I’m not aware of, or should I wait for roblox to do something about it?
It only affects the server if your client scripts can communicate with the server, which in most games they do. I had a function for updating ammo count, and another function for making gun recoil in my FPS game, and this script kid literally did this:
local scr = getsenv(myscript)
scr.Recoil = function() end
scr.Ammo = function() end
Gave him infinite ammo and no recoil just like that. It’s only a matter of time before smarter exploiters start modifying functions that fire events and the like. In order to patch it, I just removed those two functions and hardcoded it in-line whereever it was called. But obviously this is horrible and makes it a lot harder for me to modify my own code.
I would suggest putting your scripts in ServerScriptService, because from what i noticed, scripts that are in it, just “disappear”, like things in ServerStorage.
I know this could affect the game a lot, as you probably would need to make lots of variables.
my script in that example is a local script. It runs on the client, regardless of if I store it in serverstorage, and then distribute it later in runtime, it doesn’t change anything at all. The exploiter can still decompile it, read it, modify it, and do whatever they want.
In addition they can also access nil and all of coreui.
Evidently it’s available to anyone with 20$. From what I know most of the publicly available paid exploiting software can do that now. The guy who made that script isn’t even like a really skilled programmer or anything, he’s literally just a normal guy with an easy to obtain tool.
lol im joking, everyone knows that’s not an option to get a popular roblox game…
but all in all, they can only change client-sided objects, so try to handle most of your important things in the server. (besides renders/animations/input etc.) and then use Remote Events to become the middle man, but make sure you handle these with a lot of THOUGHT, remote events can be exploited if you give any vulnerable data to the client.
Exploiters are only able to get your script’s env with getsenv. Simply don’t use global variables and they won’t be able to change them easily.
Also if them changing your variables is this big of an issue, perhaps you should consider reworking your set up, as anything on the client shouldn’t have a lot of influence on the server or its sanity checks.
I do, my events are very protected through a key system AND a custom data encoder. HOWEVER, this makes literally no difference, because they can access ALL clientsided code, variables, functions, etc. They can just call my own functions whenever they want, and there’s nothing I can do to stop them.
i recipher my remote event keys everytime theyre used, maybe you can try something like that?
this wouldn’t help much though considering the decode function will have to be on the client as well.
You aren’t supposed to stop them from calling your local functions. You’re supposed to make them calling the functions have no influence on the gameplay.
I.e. it doesn’t matter if they get your Reload() function if you still check the ammo on the server.
Just don’t handle ammo on the client so they can’t make their ammo infinite on the client. You should also not have remote events that allow this, key systems do not prevent anything.
You can’t prevent this type of exploit all you can do is have good server checks.
As I mentioned above, my network is super protected. But that only assumes that the exploiter is trying to call the event themselves. My script’s however, still need to fire events. So they just simply modify my own script to call the event for them, with all the necessary key and compression included.
You shouldn’t have events that allow this behavior in the first place. Events are only needed when data from the client has to be sent to the server, you shouldn’t allow the client to call an event to change game behavior, such as changing ammo.
but i mean it shouldn’t even be a problem because they should only be able to change ammo every X amount of time based on the gun they have, AND who cares if they change ammo with code? they can do it faster and easier with input.
Clever, there is no event for changing ammo. They are simply modifying my own code directly during runtime to give themselves ammo. You also mentioned there shouldn’t be any events that allow them to do this stuff, but it’s an FPS game, I 100% need to pass data back and forth to handle shooting and playing the game in general.
Ammo shouldn’t be handled on the client then. It can be fully handled on the server and each time the client shoots it will call an event that allows them to shoot, which deducts ammo on the server.
I’ve contributed to an FPS game known as Rovive myself and it did not have these problems. I think that you’re trying to let the client handle too much that the server can handle. Edit: My point here is that you’re giving the client far too much control than it should have, it seems like most of what you’re stating can be simplified to let the server handle.