How to know on the client if the environment of an exploit required a module script

Help and Feedback Scripting Support
#1

Seeing the environment of exploiters.

Hello everyone,
recently I talked to an exploit script “developer” and he told me that apparently you could see the whole environment of exploiters from module scripts if they require() them. (and not from localscripts they aren’t require()d). Can anyone confirm or deny this? And wouldn’t this be a fix for a few problems because you can tell 101% that they are exploiting if this is true.
Best Wishes,
ExitusActaProbat

#2

Can you please define what is enviroment of exploiters?

#3

I am pretty sure he meant coregui. But now that I think about it you can access that from a localscript. I am not exactly sure that’s why I asked if anyone knew exactly. I think I know what he meant. When you require the module script from an exploit that you then can see the whole environment of the exploit that required the script.

#4

Exploiters can see CoreGui, also when an exploiter does “print(require(module location))” they can see inside that module script if that is what you meant.

#5

The following code should not be used as “anti cheat” because it is easily bypass-able by exploiters.

This is an example of how you are able to detect if an exploiter called your own function.
getfenv() returns the environment of your script. Each script has a script variable (global) by default, stored within a dictionary table assigned to each script when it runs (known as script’s env). getfenv allows you to access it. getfenv can take a function or a number as argument. I’d like to call them “levels”.

  • getfenv(1) – returns current env.
  • getfenv(2) – returns env of the func that called the current func
  • and so on.
--// ModuleScript in ReplicatedStorage
return function()
local env = getfenv(2); --// grab env that called our func
if not env.script or not env.script.Parent then --// if script cannot be retrieved or script parent is nil, and you don't destroy your scripts, then this should be fine
return print'exploiter called my function';
end;
print'legit called my function';
end;

And for the exploiter side

require(game:GetService'ReplicatedStorage':WaitForChild'ModuleScript')();

Per total: it shouldn’t be used in your games because it cannot be “safely used”. Proper anti-cheats are designed to run in the server-side.

The best “anti cheat” is protecting your own remotes.

7 Likes
#6

This is actually true no cap. btw who was the exploit script “developer”?

#7

so here you can actually figure out that there is an exploiter and ban him if he calls anything in a module script??? Considering you could code every function to ever exist in a module script (on the client) and you could always know if it is an exploiter and then ban them?

#8

Yes, they can actually require your modules and change the values inside it just using for example: local Configs = require(game.Players.LocalPlayer.PlayerGui.Settings); Configs.Damages = 50. They can also overwrite the functions inside it. It depends how you use your modules, if using a remote that send module script data from client to server the server will see the changes and apply them. So i’d recommend to check on server if the module script data (require the same script on server like on client) matches with the data sent from client, or kick the player for exploit.

#9

It doesn’t really matter how you would make the server know that it’s a cheater. If you hide it in a big module script you could easily require (from a module script) an id of another module script and that module script would teleport the local player to then get him banned. Any number of possibilities at this point. Considering they won’t be able to require the script because they would get banned before reading the contents of it.

#10

How would you detect if a client is indexing the ModuleScript + use ‘require’ on it ? Any exploiter can easily bypass this detection.

#11

Let me right a quick example. I am pretty sure what I am going to try should work. As soon as I get the opportunity to open Roblox Studio (Roblox is down…).

1 Like
#12

Exploits run on clients you cant do anything about it lol

#13

You can explain your solution here.

#14

You can prevent a ton of exploits, but they use functions and “difficult” methods to bypass the detections which make them undetectable.

#15

exploits run on client and theres alot of ways to bypass client sided anti cheat the only way to secure game is doing checks on server

making client sided anti-cheat is just waste of time

#16

So basically you hide this

local idofsomemodulescript = 973746926678965456789
return function()
local env = getfenv(2)
print(env.getrawmetatable) --> function if called from an exploit, nil from your scripts
if env.getrawmetatable ~= nil then
      local a = require(idofsomemodulescript)
      a:DoSomethingToGetBannedOnServer(someplayer)
end

I am pretty sure you would have to require it before you could read it/decompile it. To read it in the first place and figure out there is an anti-cheat

#17

If you are using anything to make communication between client and server (RemoteEvent RemoteFunction ect…), exploiter can intercept it very easily using metamethod “__namecall” to find for anything indexing your remote and using the method “FireServer” on it then return nil or a fake remote to bypass the FindFirstChild("Remote") == nil detection.

#18

Im not doing that. I am going to unexpectedly teleport the player making him getting banned on the server. There are any number of possibilities. You force him to break a rule that the server moniters.

#19

@ExitusActaProbat Exploiters can get the approximate source code of any script you have in the game, and the exploits themselves have protection against such measures as you are suggesting. Developing a client-side anticheat is the worst game of cat and mouse you can play. Roblox itself does as much as it can already, and you can see how well that works.
Don’t kid yourself into thinking that you can somehow do better than Roblox itself.
Of course, server-side anticheat is the best course of action that you can do yourself.

2 Likes
#20

No, if a modulescript has already been required once, it will be cached and return the same value. The modulescript will not run every time it’s required.
But yes, you can determine on whether the caller of a function originates from an exploit environment or not - but this is easily spoofable. I made a secure_call implementation in pure lua a long while ago that spoofed almost everything to seem like it was called from a normal game’s script - be it from error traces, function environment, context level and so on. You can see it here:
https://paste.sh/LXGoFSKx#J3LdLvHczREMwv2RkH2gxuHW