Yeah, that would work for you, just sadly it’s not a solution for everyone. My solution would probably be the best way to protect your source code if you simply cannot parent it to nil without breaking the functionality of your game.
However, as I previously stated, most of the exploit users tend to not know how to do these things as much, the exploit itself makes it fairly easy just to pass an instance to it and decompile the bytecode to save to your computer. Just, if they wanted to get the source of a script without a physical instance, they’d need to provide a pointer to it without a physical instance, that’s where it’s more complicated but it is possible.
It’s kinda a shame really, since personally, these exploits are actually very advanced in how they work and by viewing the source and playing around and having the general knowledge to create such things, it’s not something you can do in 10 minutes. A lot of time is put into finding these things plus every Wednesday when Roblox update their client, they then need to find the memory addresses and replace them which is fuuuuuuunnnnnn to do.
Just, if people were to use exploits for the better of people such as testing to find things to report and have fixed, we wouldn’t have much of an issue. This is what I tend to do, I like to test things and find things out so I can find ways to fix them so other people who have just bought the exploit to go around and ruin the experience for others can’t do it as easily.
i go over this in the post, but i still think the only way to truly, absolutely ensure your game is safe is by handling your network code responsibly. there really isn’t any way to make a 100% foolproof solution to exploiting solely on the client alone. while i think there are certainly a lot of things we can do to make it a lot harder to exploit the games, because sites like vermillion have created a market for these exploits, any anti-exploiting methods that are fully reliant on client will eventually be bypassed in some way or another. yes, we can make it hard, yes, we can make it miserable, but we can’t make it impossible.
the only way to do that is by reducing the amount of authority the client has in making final game decisions.
I am going to bump this because how important/relevant it is still but I’m not currently developing in FE. I am still learning about FE (I’m hoping me laying the foundation down for it should be an easy flick on). I feel I have it down but I’m still having minor issues about getting the PlayerGUI/Camera and some performance issues.
I want to make something extremely clear: exploits being level 7 doesn’t mean what you think it does. You can do everything listed in this post with level 2 (the context of normal scripts). Most exploiters rarely ever use anything past level 2 context. The term you’re looking for is “script injector”.
Apologies to anyone that this may disturb since this is reviving the topic, but I think I may be on to something.
I’ve been at wits with many an exploiter especially old friends, so I already have known of auto executing code, and I really would like some confirmation on this. @crossStarCross said in the above quote that the auto executing functionality loads prior to client logic. Can anyone confirm that this is in-fact the case, or still the case?
Interesting. Thinking of some anti-exploit methods that in itself become rather simple to update, but at the same time remain difficult for exploiters to break through. I might make a post, or surf through some discords to see if I can find an answer for this as well, but I’m also curious to know if exploits can read exact values sent to the server. I understand that they can read client side code, but I’m curious to see if they can read what values are sent in specific to the server.
One if the best methods you can do is called honey potting
Most of these kids see San event called apply dmg that looks hidden are gonna fire it. And boom you gotten.
Do not name all your functions in a way to indicate if they are down pipe or up pipe.
This way you can easily server side wrap the real ones and honey pots with…hey no ones ever suppose to use this.
Second:
Deterministic data.
This is easier than it sounds. Do all cert checks on the client and the server the same and do some extra on the server.
This let’s you. With absolute certainty know, yo your not a shadow mage, you clearly injected to get past that block.
Flag them. Restrict them from economy and let the hammer drop on next place jump. So they cant associate an action with the ban. For flavor, put a timer too random like 30 to 2hrs then next place login boom done
Yes - clients can see what gets sent to the server.
Any exploiter dedicated enough and with the right tools can see it. This is what makes anti-exploiting hard - they can copy legitimate requests and look exactly the same as legit requests.
This works only for a little while. Word will get out very quickly that “x event will cause a ban and you should actually fire y”
It is a valid strategy but not very effective for long.
This is why you move and rename frequently, and again. If you follow the time law it’s much harder to figure out.
The time law also creates and allows you to take something from exploiters that they cant get back.
Time. Once flagged they banned accounts walking who just dont know it yet. Of course you cant just leave your honeypots the same. That would be psychotic.
The trick is silence you dont respond directly immediately cuz you didn’t take the time from them. Any amount of immedabt retroactive bans will get sniffed out easily. Which is again always delay punishment and disable their ability to interact in the economy if you have an economy. Kind of like for some strange reason the trade always fails right at the end.
I could go about this more in depth but we employed these in eve online to great effect.
By this, you mean them reading the local script code to see what’s being sent?
I’m trying to see if I can send let’s say a randomly generated value to the server, and then an exploiter read that value when it gets sent? I know they can substitute their own code to replace and send those request themselves.
If you want to do random number safety you have to do a decoupling of who is signing it.
This is actually do able.
What you must do is create a random object on the server
Random.new(seedvalue)
Send the seed value to the client and the client makes a seperate random object.
The trick here is that when the client sends and input say punch, the client runs the next value and the server runs the next value.
To clarify the server and the client never pass any random numbers the idea is that any time the client sends an event that the server can assume it used next and follow in suite. You can get a lot more advanced with this but it also is easy to blow your foot off.
Because they share a seed their outcome will always be the same. The hard part is keeping them in sync can be tricky but not impossible. I do it alot because it allows for a lot of cool things.
Another fun trick with this as long as you are ensuring the syncs
You can be calling this in a lot of not logical locations and then you could pass the results those random say on dmg and cert check server and if the exploiter tried to adjust the number or predict the random they would have had to track down every single call and know every single time up to that point to know at what that value would be.
This is not a method by which to secure client side trust but a method to detect a player being naughty
Something I’ve not talked about is the best deturant of exploiters is fear and uncertainty.
You want to develop systems that make them go “is it worth the risk” that’s more powerful than anything.
I also suggest when you do cert someone cheated and you have caught them post their name on a bored of cheaters, public shame is strong motivator to avoid bad behavior.
Of course this is all predicated on that you have reliable methods. So you will need to test these into the ground and then some.
There are also other methods I could go into but that would be a longer talk
