It’s the issue with chat spamming. I’ve been able to shield other players entirely from crashing but the server still takes a massive blow cutting off all network connectivity.
So until Roblox creates a patch for this from their side, this is the best I’ve been able to do.
Take a look at this:
You can probably use it to combat this.
Surely an exploiter could just delete this script?
1 Like
Not with how I have it set up. There’s 2 scripts. Each protects the other from being deleted or disabled.
The SetCore still doesn’t seem to be working regardless so that’s a rip.
You are underestimating the client.
You should first read many of the posts on the developer forum about exploitation.
This solution to a post is great Remote Security [Other than Checks]
And this Tutorial: Properly Validating User Input
I have read what you are trying to do. And I do not know much about the Roblox chat modules, but making a custom chat is always an option. Then, preventing spam is as easy as ever. Anyway, don’t try to make anti exploits on the client.
2 Likes
You need to pcall the SetCore call as I did in my code, as DeveloperConsoleVisible may not be available immediately.
1 Like
Okay I have locked the script then disabled it, does your server-side script still work?
If your solution is to simply create a new localscript then congratulations, I’ve just DoS’d your server
I’m just going to put this out here that trying to stop them from entering the console is most likely a waste of your time. Trying to put good security and checks in your remotes and other objects is objectively better than trying to hide the console. If the exploiter has access to the lua environment and the memory they can gain access to script errors, edit variables, read variables, anything that uses the memory. While synapse might not have a console a competent exploiter can go around this quite easily.
3 Likes
I am highly aware of the capabilities of the client and I’ve done what I can on the server.
Remote security is the last thing I’m worried as I know exactly how the usage of RemoteEvents and Functions works.
I lack the capabilities to modify the Roblox engine to stop remote spam. It has nothing to do with the security behind the events.
I took the pcall off just to find the error.
I don’t think it’s an issue with it being available immedietally since I got a few thousand errors spammed into the console before closing the game.
Remote security has nothing to do with stopping an exploiter. I can’t simply stop them from spamming events. That’s Roblox’s problem, not mine. I’m not worried about experienced exploiters showing up and exploiting. I’m worried about those script-kiddies who just take other’s scripts and have the basic knowledge to take a look at the console and simply change the name of the event they’re spamming.
I’ll put an emphasis on this. These are Roblox core events. Not mine. I have no capabilities to stop the client from spamming the events. Best I can do is scramble the event name here and there to throw them off. Their script will still show the error in the console.
I’ve done spam protection. It’s not an issue with what I’ve done regarding the events. It’s an issue with how roblox will allow a client to send 100+ requests to a single event in under a second and not even attempt to stop it causing an overload that the server just cannot handle. These aren’t even my scripts I’m modifying to try and stop this from the server.
I can’t stop it from the server. Once the events start flowing in, the server won’t even be able to process them fast enough. All I’ve been able to do is cut the other players off from receiving communication with the server (which would cause them to lag).
All I can do is tell the client that what they’re trying to do doesn’t work. They’ll still get the error and anyone with basic for loop knowledge could easily spot the scrambled name and try using that.
A script-kiddie isn’t going to notice their console should be working. Some don’t even know what the console is letalone where to find a script for one.
Interesting, it seems I did not understand your post. Now I do, and I have a lack of knowledge, but possibly a way to help.
And this…
Which makes me wonder how the exploiters are passing the limit.
This is very much your problem. You absolutely should take every measure you can to protect your remote events from abuse, especially spam. You can prevent unexpected issues such as server crashes by simply adding a debounce to code connected to the events.
How would they see that in the console in the first place? You can’t run code on the client side. They’re using third party tools to figure out how your remote events work. You cannot prevent that.
Yeah, you do. And I fail to see how blocking the dev console will help you here.
Script kiddies get their tools from their script daddies my man. And the daddies will definitely distribute means to get around a weak workaround like hiding the developer console.
1 Like
The Roblox Chat Modules getting spammed until the server can’t handle it isn’t my problem. This is a Roblox-wide problem. I’m not the only one having issues. Hundreds of games are experiencing this issue if not more.
A single exploit script could literally crash a baseplate game.
Synapse^X, one of the most popular exploit clients, works like any other LocalScript. You execute anything that throws an error, the console will report on that error. You very very very very much can run code on the client with an exploit. An exploit is the 3rd party tool. And it can run anything like you put it in your game for the client to use.
Like I said above, any and all errors are reported. If you’re using the only way possible to execute code through the Roblox engine externally, you can’t avoid Roblox’s error outputs. Which means that every error is reported there. Just like you or I use the console output to solve programming errors, they can do the exact same thing for their scripts. No console would slow them down and they’d have to go find their own console. I’m not that worried about that aspect since I’ll probably catch their error and try kicking them for it. But as a different approach, hiding the console can also benefit for those who give up easily (generally those who don’t know how to program). If you ask me, a for loop just to find the new name then replacing some text isn’t that hard. Anyone with some basic knowledge could do that.
Overall, hiding the console would just be something nice to include. Maybe I wan’t to replace it with an error reporting panel when someone hits F9 or types /console.
You should make a big report then. And it is still your problem, whether you like it or not. Roblox cannot handle all of your game’s security, even if there is a vulnerability with their own features.
You misunderstood me. I’m referring to executing code client-side via the developer console.
Again, hiding Roblox’s console is going to do nothing to aid your security.
Why would you reinvent the wheel?
Blocking the dev console is a bandaid fix. I’d recommend spending time developing actual security measures for the best results.
1 Like
Try changing DeveloperConsoleVisible to DevConsoleVisible.
Though as everyone else is saying this is a weird prevention of hacking that can be bypassed easily or replaced easily and will also damage actual players’ ability to report bugs to you.
There it is - an XY problem has made its debut. And it makes a lot of bold assumptions.
Rehashing some things already said and adding a few new ones (I would hope):
-
This is a silly idea. Period. You’re wasting valuable production time on something that amounts to absolutely nothing.
-
Exploiters are most likely checking their own console, not Roblox’s, for errors with their own code.
-
How are custom consoles not as reliable as Roblox’s? You can easily make a better console or directly copy the behaviour of the Roblox console because the code isn’t closed source. It’s right in your file system.
-
You’re hampering the ability for users to check and report issues with your game which is awful UX. Enjoy many DMs about the game being broken and getting unnecessary frustrated by a problem you ultimately caused (unspecified behaviours, no logs, so on).
-
This can just be disabled. Please do not counter this with something about another script doing a check-in on it because that’ll be disabled too and so on. You don’t win a fight on another client’s machine.
Fix your game and stop trying to do this.
7 Likes
This is risky as a mess up with your script can go terribly wrong, but you can make a script which kicks/bans a player upon receiving a local error. It’d slow down their progress as well as might prevent them from figuring out the cause.
1 Like