Where can I learn more about this? I never really thought it was a bad idea until you mentioned it.
Well, having a remote which actually adds money for real would allow an exploiter to give themselves money by firing it. Think about exploits like they create invisible LocalScripts in your game, they can do anything your LocalScript can do, and even more (to the extent that they can basically modify any of your LocalScripts without it being possible to detect)
Personally, If I’m 100% sure that the client is hacking, I’d just play a cutscene of me beating them up, and then if they try to rejoin they’ll just die instantly, forever
2 Likes
Do you detect exploits that are parented to CoreGui?
I don’t know of the ways that this is currently done, but client-sided anti-exploit can be bypassed easily, which is the main point I wanted to make when I made this post. Really you shouldn’t want or need to detect UI in CoreGui.
2 Likes
Unless exploiters can prevent local scripts from being inserted from the server to the client, then I presume some client-sided anti-exploits could work. For example, the server could insert an anti-exploit local script every 60 seconds to check if BodyMovers exist in the player’s character to establish if they are flying using BodyMovers.
Once the local script(s) are inserted into the client, they will not be able to disable it before the code executes.
Unfortunately, this is not the case (also, sorry for such a long reply, I got carried away, but, I do hope maybe you might find it helpful 
). All local scripts of course have to go to the client since they run on the client, so any modifications an exploiter makes to the client are also going to effect any new local scripts.
There’s nothing you can do to avoid this since typical exploits have essentially full control over the engine and the way your code will execute before it even executes at all, and, in fact, they don’t actually need to run any new code at all even if you yourself run new code, because, well, they can just change how said code runs in the first place.
All Instances are, to put it simply, a lot like a table, just without any keys/values. They are userdatas (just with some special tagging and stuff in Roblox’s code to keep track of the fact that they are an Instance). They have a metatable (which you can add to tables with the setmetatable function) with various functions on them, like __index and __newindex which control what happens when you do various things. Exploiters have the ability to modify the metatables of Instances without you being able to detect it at all, which is actually one of the oldest major features I can recall existing in exploits, aside from the ability to run lua scripts.
This allows them to for the most part change how particular instances work and it allows them to spoof/fake things, replace functions, and prevent you from setting properties, and plenty more.
Most exploits can also modify the globals your code may use, which applies to all scripts, including ones that are running, and ones which have yet to run at all (like new ones you create on the server). All globals, such as game, workspace, print, pcall, etc, even functions they can completely replace.
Some exploits even have some very powerful features for replacing the insides of existing functions so that even if you try to use fancy trickery to compare two functions, you won’t detect it, since they’ve modified the actual function itself.
Exploits essentially have complete control over how/if every piece of your code executes, to a very remarkable extent. A very skilled exploiter is able to circumvent anything you do, and, often times, exploits make it fairly easy for lower skilled exploiters too.
The real problem with client-side anti-exploit and the reason all of that is possible in the first place is because exploits aren’t actually at all bound by Roblox, or lua, or anything like that, it’s simply more convenient and much less work for them to re-use almost everything Roblox does, but then make their own modifications on top by providing special functions like getrawmetatable (which is not a Roblox function, it is one commonly added by exploits to modify locked metatables). Someone writing an actual exploit tool (not a lua script that would run in an exploit) could really write a function that could do anything to anything, it’s just that they often don’t because it’s easier to take other easier approaches by using Roblox’s code more.
Really when you abstract down enough a LocalScript is just a bunch of data in your computer’s RAM, and the code on it is also just a bunch of data. All of the other things that code may interact with is also just a bunch of data too. And, well, if an exploit wanted, it could modify that data in any way, or even just run Roblox’s own code to do the exploit’s bidding (which is basically exactly what they do all the time)
Even Roblox themselves couldn’t put any code in that could stop exploiting, because exploits could just remove it.
The reality is that client-side anti-cheat may place a sort of “skill gate” but it will never actually stop exploiting. Once someone with the skills inevitably comes along and writes up some code to circumvent that, your client-side anti-cheat no longer stops them at all, and they are free to do anything on the client they want.
That’s why it’s so important to design everything as if any player can do anything in your code, as if they have edit access to your client stuff. You want to assume that any random exploiter could have full access as if they have defeated all of your client anti-exploit, because that tells you what an exploiter can do (and higher-skilled exploiters will inevitably somehow allow lower-skilled ones to do that stuff too, either by sharing their code, or selling it). Once you’re in your server code, however, exploiters can only do what you allow, they no longer have access to the stuff that’s there, and they can only take advantage of what your code does, and what your code doesn’t take into account (e.g. giving a remote stuff you don’t expect)
4 Likes
I really appreciate your reply, helps a lot. Yes, I never write client-sided anti-exploits for obvious reasons but I just wanted to throw that idea out there to see what you thought about it. That being said, I never appreciated that they can control how your code will execute before it actually executes. This is really important to know and just emphasises the importance of writing your anti-exploits on the server.
1 Like
If you don’t mind offering some advice, I have an issue with anti-cheat.
So I have a game where everything is invisible and pitch black. There are also hostiles in the game that are also invisible.
Since its all on the client and so are the parts, because they are replicated from the server, couldn’t the client just make everything non-transparent and be able to see again? I don’t see a way that this could be undone very well.
1 Like