Exploiters & Global Functions (On the client)

Help and Feedback Scripting Support
,
#1

I know that exploiters will be able to access Global Functions on the client through the script that creates them.

But what if the script that creates the global function gets deleted?

The global function would then just be in the clients memory, the exploiter wouldn’t be able to decompile the script that it was created in, as it wouldn’t exist anymore.

Example:

_G.CreateOutput = function(Message)
	if Message then
		print(Message)
	end
end

script:Destroy()

The local script above creates the function “CreateOutput”, it would get deleted after it’s finished loading the function. (Most of the time its done within 1 millisecond)

I know that exploiters will still be able to call the function, but how easy would it be for them to decompile & read it?

2 Likes
#2

iirc ModuleScripts were the most vulnerable script containers to decompilers because by nature they’re accessible by pretty much anything. _G would work the same way because it is literally the “global” environment. So really they should be equal to or easier to decompile than regular LocalScripts.

I’m sure other people have said this millions of times already, but deleting scripts isn’t a 100% safe solution to fighting decompilers. One thing you must remember is that exploiters have total control over whatever happens on their side. They can simply prevent the script from deleting itself by rerouting the :Destroy() method using hookfunction. And this hooking can be done way before anything else because they have control over their clients.

3 Likes
#3

Okay, that’s good to know

I’m aware that deleting scripts isn’t a 100% safe solution, because I’m aware they’re able to change it so they don’t delete themselves.

so to combat that, the server also deletes the script out from their inventory

On a side note, how would an exploiter decompile the global environment functions, is there a script that they automatically get stored in?

I just realised that the global environment is a table, so they can just loop through it

#4

I’ve just decided to move the scripts onto the server
It means it might lag sometimes, and not be timed correctly. But that’s better than an exploiter stealing my scripts

1 Like
#5

Are the scripts that important? Is it worth sacrificing user experience and server performance for their security? These are something you should ask yourself because a paranoid developer rarely succeeds

1 Like
#6

Yes they are, they’re the whole purpose of the game,
So if they get stolen, then other people can use them for profit and I don’t want that

The game works with them being on the server, I was just hoping that I found a decent solution to stop exploiters from being able to access the scripts

#7

To answer your question:
Exploiters can still access instances even after deletion. So this would not stop them from decompiling the script.

1 Like
#8

I’m guessing it gets stored in the clients memory?

#9

I’m not entirely sure if it is due to how Roblox handles deletion, or if the exploits sinply store the data even after deletion. I just know that it is true.

#10

Not always, there are some methods to stop this from happening.

Such as something like this.

script.Parent = nil
getfenv().script = nil

The exploiter cannot get the local script even using
for i,v in pairs(getgc(true) do end

#11

This does not stop exploiters. While it varies from exploit to exploit, take former exploit Synapse X as an example. That program kept track of instances even after deletion, and made them accessible through a function called getnilinstances. You cannot stop exploiters from accessing anything client-related.

1 Like
#12

It is not visible in getnilinstances().

Quotes from users prove this aswell.

1 Like
#13

The only thing you are doing here other than deleting the instance, is removing it from your own function environment. This should not affect exploiters. Even if it does somehow prevent Synapse X from accessing the script, this isn’t a sureway to achieve this, it is merely a loophole found in an exploit, which could easily be patched, making this approach redundant.

#14

How could it be patched? Here we are using the Lua Garbage Collector to our advantage. To prevent this they could either use getreg or getgc, although I can block skids from using both of them. lol!

#15

I never knew you could detect getreg, that’s quite interesting.

#16

It’s a matter of fact that you are trying to hide data from the exploiters. Data which they are in possession of, on their PC. No matter what you do, it will always be possible for exploiters to access the data. They may not have the tools to do it, but it is possible.

#17

With your logic you are basically saying “Let’s just not add another line of defense” which is a very bad mindset.

#18

This “other line of defense” complicates development and takes time away from productive development, with very little benefit. You are much better off just securing your game with proper design instead. And I simply answered the question which was asked, no this will not hide your code from exploiters, which is a fact.

#19

May you educate me on how a such “line of defense” complicates development? I don’t see how it does complicate development considering I have worked on multiple games’ anticheats.

Please define “proper design”.

I’d like to see where you got that “fact”, especially when I don’t mean “permanently hiding”, but rather an additional protection vector. You should be smart enough to know what I implicitly said.

#20

Guys calm down, classic DLL exploits are dead for a long time and new methods throught tampering local script’s can be easily detected even before exploiter would get access to execute scripts.

1 Like