I’m unaware of this type of exploit. Does it affect the server? If it doesn’t, it most likely only occurs on the client, and therefore mostly useless.
4 Likes
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.
4 Likes
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.
3 Likes
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.
3 Likes
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.
2 Likes
So, i dont know if this is smart or not, but, try?
1 Like
you could deny access to PC users. 
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.
4 Likes
This exploit is nothing new to me. Anything on the client can be accessed and later decompiled or deobfuscated or even modified.
Your issue is you’re not securing your data network, hence the server side is also attacked.
8 Likes
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.
6 Likes
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.
1 Like
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.
1 Like
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.
4 Likes
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
1 Like
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.
3 Likes
The ammo issue is not the problem here, it’s been patched like I mentioned by just hard coding it in-line.
1 Like
Exploiters can change your code though, hard coding it won’t prevent this.
An example of what an exploiter could do is decompile the code, change the hard coded value, disable the original script, and rerun their own.
2 Likes