Hello, I am currently working on an anticheat system, and as a punishment I want to crash a player. If I do it in a local script, aka “while true do end” then the exploiter might just remove the local script.
And since exploiters can’t affect server scripts in almost any way, I would like to know how would I be able to crash them right from the server script. Thanks.
3 Likes
What’s wrong with just kicking the player?
You realize there will be a small minority of false positives in your anti-cheat system, so it’s best not to aggravate this small minority of wrongfully accused players by crashing their game.
5 Likes
In my case, my anticheat will be always 100% right. And yeah, its just the way I want to punish the player, I don’t want to make it obvious.
1 Like
There isn’t any way that wouldn’t lag the server. Maybe have a ClientEvent hidden in a very important local script that would break their game if deleted. Then you can do :FireClient(player) in your anticheat and have that client idk do a while true do loop or spam instance.new(fire) or particles
You can also tie it to a very important remote. Lets say you have a very important remote event or client event in your replicated storage thats called “Attack” and is used to basically play the game. You can then tie it to a local script via Client Event and add a second argument that checks from which script its being fired from. If its fired from the main server script then it will work as nornal, if its fired from the anticheat script then it would crash that person.
1 Like
you don’t need to crash on the server, put the client function inside a very essential script for the gameplay since they cant edit scripts if they delete it, they punish themselves. i don’t think any exploiter would take the time to make something to counter this.
3 Likes
if its vital to the game the exploiter can just recreate it without the crash part.
but the most optimal way, although still preventable, would be to have a localscript in serverstorage which crashes them and you just insert it inside the player. if it crashes them fast enough then they wont have time to remove it or figure out where the script is / what it does so they cant counter it.
But either way its still possible to counter this method but very unlikely if u can crash them instantly.
Also on an unrelated note I respect your ideas of punishing exploiters like that. You should also add loud sounds on top of the crashing just to make it really miserable for exploiters as crashing + loud sounds goes great together since you have to force close roblox.
Just out of curiosity, do you know if the LocalScripts are all streamed as the player loads? This only works if the scripts are streamed only when they become visible to the player.
Client is irrelevant here because the contents of ServerStorage does not replicate to them. Even if it was somehow relevant, streaming is a term for parts and not for code. Code doesn’t need to be streamed unless you meant something else when you said stream.
Yeah I made a small error but you can put it in replicated storage instead of server storage. I’m pretty sure it wont run and worse case you can just wait until the parent is changed before it runs the crash.
Edit: I forgot exploiters can view replicated storage, allowing them to view the script prior to it being placed inside of them. You can just have a blank localscript and set the source.
Another Edit: u actually can store localscripts in serverstorage. Ignore what I said lol. I mixed it up for server script service.
localscript.Source = "print('Insert code here!')"That post was meant for Jarod not you. Regarding this post that you’re replying to me with, there’d be virtually no difference in which storage service you use because the client would either be deleting their own copy or not have a copy of the script to begin with. Wouldn’t matter too much where you put it.
Regarding your edit, see above text in relation to replication, the client would only be tampering with their own copy so it wouldn’t interfere with the server’s capability to give the client the script. The only issue is the code sample edit you made: Source cannot be set at runtime.
For the thread itself, the second post here is a good answer - you should never have a need to crash players regardless of which environment you’re doing it from. There’s a better option already built in which is to use Kick. It’ll do its job of removing the client from the server. Crashing is pointless.
1 Like
Yeah you are right. There will always no matter what be a 100% way to bypass the crash its just incredibly unlikely if you create a new localscript, set the source, set the parent. But even then if an exploiter were to bypass it they would have full anti-cheat immunity unless you did something like wait(30) and if they are still in-game just kick them it would probably be fine. it is most optimal to just kick but the idea of unique punishments and crashing isn’t a bad one as if someone is trying to create a GUI for your game and they keep getting crashed while trying to work around the anti-cheat it would be irritating for them.
Only downside would be if there is a false positive in your game a player would assume they are just crashing rather than triggering the anti-cheat. But in his case its 100% accurate according to him.
Also im pretty sure u can change the source of a localscript before its parented to anything.
If you use instance.new it should work.
Again though, you can’t set the Source of scripts at runtime. Just read the documentation. It plainly says that it’s not usable outside of the command bar and plugins. Instancing it doesn’t make a difference because developer code doesn’t run at a sufficient security context level to access that property.
Even if you could set the Source at runtime, there’s no point in obscuring your process like that because they can reroute memory addresses and jump over your code when it gets parented. Golden rule is that you don’t win on the client’s machine. Client-side anti-exploit measures are good for additional security but the primary focus should be from the server’s end.
1 Like
That makes much more sense thanks for clarifying.
Also I agree with everything you said so far, crashing definitely shouldn’t be a way to get a player out of a server since you can only do it from the client. You should always kick the player afterward if ur gonna crash them.
Unless the code for the LocalScripts are replicated just because they’re LocalScripts. That’s my question here.
1 Like
I imagine it would work the same way as copying a ModuleScript from ServerStorage to the client. Roblox must not replicate the bytecode until the script is a descendant of a service that replicates, otherwise that would be a huge security issue.
2 Likes