He is talking about the obfuscator genius
2 Likes
You know what I meant when I said it “uses getfenv”. When obfuscating Luau scripts with Luraph, it always ends up giving obfuscated results that contain uses of getfenv.
1 Like
Yeah fair enough, I felt like you might be but some reading made me realize that.
2 Likes
I believe I didn’t said it wasn’t deprecated
However, this is a serious problem since it will lead users of Luraph on Roblox to experience decreased performance.
3 Likes
it reminds me of this post
I do like this tutorial though, I will rely on both client and server sided anti cheats (though exploiters are more powerful than us developers)
5 Likes
I wouldn’t use any methods here. They are unstable and can be spoofed easily. Honeypotting only works once before everyone finds out.
6 Likes
Hackers can hook on events sent by a localscript, so with a local anticheat, hackers can’t be banned using kick. An attempt to let a script kick the player by using a remote instead can be blocked too by hooking it and returning wait(9e9).
Correct me if i’m wrong, but to me it looks like local anticheat isnt gonna do its job with these possibilities for hackers.
3 Likes
This method makes the whole script variable nil, was this intentional?
2 Likes
Are exploiters able to read the contents of a script that does this?
2 Likes
Yeah it was, to hide the script
Believe us or not, it actually works
3 Likes
Well if they can’t find the script in the first place it would be a little complicated, wouldn’t it be?
1 Like
Client code is hidden and the server sends and tells the client to run it’s compiled version instead.
1 Like
Yes, they can indeed do that. They can indeed yield the script. However, the handshake will see that the script isn’t sending remotes anymore and will kick them. The same case applies to errors. However, you can also detect them and not just wait for the handshake. Take this simple script, for example:
local Players = game:GetService("Players")
hookfunction(Players.LocalPlayer.Kick, newcclosure(function(...)
return
end))
A possible way to detect this would be:
local Success, Error = pcall(function()
Players.LocalPlayer.Kick(workspace)
end)
if Success then
print('Detected hook!')
end
or this hook:
local Old
Old = hookmetamethod(game, "__namecall", newcclosure(function(self, ...)
local Method = getnamecallmethod()
if self == LocalPlayer and Method:lower() == "kick" then
return
end
return Old(self, ...)
end))
Can be detected by using
local Success, Error = pcall(function()
Players.LocalPlayer:KICK()
end)
if Success then
print('Detected hook!')
end
5 Likes
Yes, this is indeed intentional; it allows the script to be hidden from the environment itself. This also hides it from getnilinstances(), dex explorer, and such.
5 Likes
I’m interested in how you’d go about introducing keys and encryption to the handshake events, as there is no built-in cryptography modules and it’s possible for the client to just read the keys or the code on how to construct the key.
I’m not a cryptography pro by any means, so I apologise in advance if I seem unsure
1 Like
The keys should, of course, be dynamic, so an exploiter couldn’t just RemoteSpy, get the key and replicate the handshake.
You could make your own encryption and decryption functions in order to use them (or you could find one one the dev forum)
3 Likes
I’m aware yeah, they should be dynamic, but even then, could they not bypass the getfenv removal of the script in the environment, and then get the method for creating the key?
1 Like
The key itself should be created on the server, given to the client, and sent back to the server in an encrypted version; I would guess you meant getting the key.
They could tamper with the getfenv function to prevent the script from deleting itself; however, most environment hooks I know of just do not return the script itself when calling getfenv, so you could detect it by checking if getfenv().script.Parent errors.
1 Like
I’ve created a rough concept, with the same idea, so it’ll generate a GUID using httpservice on the server, and when the player joins they get sent it and every time they send the handshake, it checks with their token they sent and the one the server has. It seems to work but I feel like if someone made a listener for the event the token could be caught.
Essentially it will work up until the point where the exploiter has enough time to make a listener script and then sends that event periodically. A method to catch this (although clunky) could be to time how long it takes to send the event, and if it doesn’t line up with how it should, you could kick them. However this does rely on the user’s performance in terms of internet bandwidth and client performance as they could be slower/faster depending on those factors.
Sounds good.
3 Likes
What about saveinstance()? Does it also get around that or?
2 Likes