Hiding the Developer Console if it's opened

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

6 Likes

You cannot do this as it’s in the CoreGUI and the CoreGUI is not accessible from scripts. You can read more about the CoreGUI here, on the developer hub!

I’m not super sure on this considering it’s CoreGUI, but is there the possibility I could override the keybinds for the console and just have them lead to an empty function?

I don’t think you can, as you can’t override keybinds set from the CoreGUI

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")

runService.Heartbeat:Connect(function()
    pcall(function()
        starterGui:SetCore("DevConsoleVisible", false)
    end)
end
15 Likes

Alternatively I just tried

local InputService  = game:GetService'UserInputService'
local StarterGui    = game:GetService'StarterGui'
InputService.InputBegan:connect(function(a)
   if a.UserInputType == Enum.UserInputType.Keyboard and a.KeyCode == Enum.KeyCode.F9 then
       StarterGui:SetCore('DevConsoleVisible', false)
   end
end)

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)

2 Likes

There is no point in doing this as most exploits have their own console built-in, instead work more on your anti-exploit (remember there is no way you can 100% remove exploiters)

4 Likes

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.

2 Likes

You can EASILY make your own console script to work with games like what MineDevs said

remember there is no way you can 100% remove exploiters

2 Likes

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.

Take a look at this:

You can probably use it to combat this.

So this worked in studio… However throws this error in-game:

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.