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