How would I hide my functions and tables from the exploit function known as getgc()? Some people I know have already managed to do it, so I know its possible. If anyone has a method, please send it here. Thanks.
Why do you want to hide them in the first place? You shouldn’t store or load anything important on the client because they can’t be trusted. For example, instead of having all your modules in ReplicatedStorage that makes them accessible to the client, you can have the serious ones that handle stuff like anti-cheats, HTTP requests, player data, etc on the server(ServerScriptService).
I think this whole “hide from exploiters” thing is similar to the “client anti-cheat” scenario. Both of them can be completely avoided if the game doesn’t have design flaws.
As far as I know that’s not possible considering that function basically grabs everything in the game that has some sort of reference to it, I may be wrong but the best way to find a method if one exists is to study the function and find out what it actually does
I have a lot of experience in making client anti exploits. I have had dozens of exploiters attempt to bypass my anti exploit, and fail.
My best guess would to simply alter the environment of the function, but I’m not sure which ways I would need to alter it. (Using getfenv and setfenv)
I don’t think that would work, if I think what you’re trying to say is what I think it is then that’d hide scripts from something else
Client anti-exploits are pretty much a cat-and-mouse race. They aren’t reliable because an exploiter can bypass them if they can outsmart you(which they might do if they get interested/curious enough, have the tools to examine your code, and also have some knowledge). However, they’re a good solution to skids trying to mess with your game, as long your game isn’t big enough for actual exploits to be specifically developed against it.
1 Like
To be honest the cat and mouse game is what makes it fun because all they’re doing is helping you patch vulnerabilities in your anti-cheat
You can use local functions and variables instead of global ones. Functions and variables declared with the local keyword are not exposed to the global environment and are thus harder to access with getgc(). Additionally, you can use nested functions and closures to further protect your code.
1 Like
None of that matters if they can use getgc() to get the script itself and then just decompile it
With a couple things like anti decompile, anti hookmetamethod, anti hookfunction, and server-client encryption and decryption, you can make your anti exploit as hard as possible to bypass. The last step I need is to hide script functions from getgc().
This may work at first, but its only a matter of time.
GetGC effectively grabs the memory of a global state, you can’t prevent it entirely
Your best bet is to put the localscript inside of an Actor and then only synapse users will be able to grab the info out of getgc because actors run under entirely different global states
How an exploiter could still grab it
for i,v in next, getactors() do
for i,v in next, getgc() do
--do stuff
end
end
Most exploiters don’t use actors so if you just want to prevent the majority of them, use an actor.
(Create an Actor in replicatedfirst, put your localscript in that actor, profit.)
I’m wanting to prevent it outside of parallel Luau, so I am still able to detect hookmetamethod and hookfunction, which cannot be done inside an actor.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.