Problem: I have an Anti-Exploit that changes the names of some things to cause exploit scripts to throw errors. Only issue is, any good exploiter will check the console to see why their script isn’t working. And just by doing this, they can ask themselves these basic questions:
At what point does the script cause an error?
Is the error caused by something not found in the directory I’m checking?
What is in that directory if I print out all the contents?
That last question would cause the downfall of my Anti-Exploit when it comes to changing names. Now, I’m aware an exploiter can just get themselves a custom console. But those aren’t always as reliable as the built-in Roblox console. If someone was dedicated to finding what the error was, I could live with that. However, for the basic error finding and logging, getting rid of that would mean my Anti-Exploit would achieve a higher success rate.
So I guess my question is, is there any way to hide the console when it’s shown or just loop hide it?
I do believe there was a way to open the old console when they released the new console and this same exact question might already exist. I’ve just been unable to find it.
I’m also aware that there are RemoteSpies. Those are something else I’m working on combatting by constantly changing the event name.
Any solutions would be a major help to me slowing down or even eliminating some exploits from the games I work on.
Note on solution: Change DeveloperConsoleVisible to DevConsoleVisible
You can repeatedly call starterGui:SetCore("DeveloperConsoleVisible", false)starterGui:SetCore("DevConsoleVisible", false) from a local script to achieve this functionality:
local runService = game:GetService("RunService")
local starterGui = game:GetService("StarterGui")
local InputService = game:GetService'UserInputService'
local StarterGui = game:GetService'StarterGui'
if a.UserInputType == Enum.UserInputType.Keyboard and a.KeyCode == Enum.KeyCode.F9 then
Which uses the same thing as what you provided. However yours is going to keep it hidden for everything such as /console.
I’ll use yours instead since that’s gonna be more effective for my use case.
(Found the script online by searching how to get the old console to show, which doesn’t work anymore regardless)
I know almost certainly Synapse doesn’t provide their own console where you can see outputs an errors. And Synapse users are the main people attacking games I work on. This just slows them down while I improve the Anti-Exploit so they can’t track what type of progress I’m gaining on it or the path I’m taking.
As I tell everybody, dont look at exploiting the wrong way. Slowing down someone from exploiting your game does absolutely nothing as in the end they will always get through these type of protections (Client sided protections) instead of blocking the people who trigger the problem, block the problem.
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.
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.
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.
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.