How i can modify function/event

I need learn how to modify a function or maybe event. So like if player using custom function for example

local function test()
print("TEST")
end
test()

It would print “TEST”. Right?
But how i can modify it from beginning so ALL functions would do ADDED commands
for example same code, but it would print “TEST” and “Printed from modified function”.
im not so good at metatables and other hard stuff.

1 Like

Functions are immutable, so they can’t be changed. To avoid an xy problem, could you explain what you actually want to do?

1 Like

Making some sort of anti exploit. I found a way to detect from what it runnin (from original code or from exploit). So i need inejct this ‘check’ code to function. so if exploiter would use ANY function. this checker would run.

In other words i need override function or anything what can be overrided. anything. print() for example

So you check the function environment of whatever called the function. Ouch. The use of getfenv() disables some of Luau’s optimizations. Plus, exploiters can use secure_call or similar so that your checks think it’s from a game script and not exploiter script. Not really worth it.

If this is really necessary you might as well move that function to a server script depending on what it does.

Yes but it would stop of 70% of exploiters. Since not every exploit have secure_call

so how i would do it.
Btw this checker printint false/true depends WHERE it was runned.
If it runs from exploit it will print true
if from ORIGINAL code it will print false.

You are not understanding, an exploiter can simply spoof the environment it is called from and it would look like it it is from a game script.

Maybe force exploiter run this function somehow.

this is pointless, for many reasons:

  1. remote events should be designed to handle whatever an exploiter throws at them. Needing to have a check that requires the client to send data is bad design and should be avoided.
  2. Even if you get something working (ei; passing script as an argument, or something like that) you’ll run into issues with exploits, as they can just run code from any script and pass it off as that script running it; like in syn.secure_call(Module.FunctionToCall, LegitCaller, ...).

Anti exploits should focus on checking what a normal player cannot do and limiting to that, and have checks against what an exploiter can do and preventing that.
Any anti exploit that focuses on detecting exploits or determining if a function was called from an exploit is pointless, as exploiters will find a way around it. Focus on good design that makes remote events secure and non-exploitable for your game.

2 Likes

Editing a function will in no way stop exploiters, it would sound like you are trying to make one yourself.

Editing them is not useful, and even if you could it wouldn’t stop exploiters.

You can however monitor the dev console with a script so it can detect prints.
This means you can configure it to detect when players are printing things that shouldn’t be there, for example I know for certain that one of the exploits prints when a player starts flying.

That’s a waste of time, just secure your remote events.

Securing remotes its not only 1 thing to do. i secured them hard.
But my friend tested some things. and found many backdoors.
Like cloning localscript to run 50x times a remote (even with cooldown it will run somehow)

Any requests that are made before the cooldown kicks in will still go through. It means that if they are running at the same time cooldowns are bypasses.

It would be easier to check for things going on the client side.
You can check when a part is added and check what it is. This means that if they are trying to clone local scripts you can detect it, this also means that anyone trying to insert parts could be detected as well if you made a sort of instance.new manager between client and server.

This means nothing can be changed or added / removed without the server knowing about it, it does however require a bit of communication and securing your events.

You clearly didn’t secure your remote properly then.

Securing remotes is different for everyone, but securing them in general is very simple.