I made a powerful anti-exploit. Looking for feedback!

Help and Feedback Creations Feedback
#1

The guy I was working with cancelled the commission so here’s what I have made so far.

It’s really difficult to decompile because each time the client needs to fire to a separate remoteevent that gets created and the localscript is like 500,000 lines long.

Should check it out.

2 Likes
#2

Seems great! Studio almost crashed after trying to open “w”, but other than that, after reading through a bit I don’t see any real problems :slight_smile:

#3

Seems cool, just wondering though, how does it work?

#4

Quite confused on why the localscript is filled with pure whitespace? It doesn’t seem to be contributing to the actual anticheat itself, and all the logic seems to be housed within the server script.

EDIT: I did some analysis on the anticheat itself and i’ve come to a few conclusions on areas which require improvement/adjustments (I intend this to only be constructive criticism for future works and hope you take it as such)

  1. Doing things that cannot be done on the server
    (e.g Trying to find BodyGyro in the player)
    Note: This would be plausible on the client but not on the server. 
if table.find(listofstuff,"BodyPosition") and not Player.Character:FindFirstChild("BodyPosition", true)  then
  1. The use of remotes for checking
    (e.g Awaiting a remote every 30 seconds or so to see if the client is responding correctly)
    The main issue with using remotes is that they can be easily exploited by the client (e.g send fake values over to the server, or prevent them completely) But what i’m seeing here is that you are giving the client 30 seconds to respond to the remote, and if they don’t you ban them. This can be extremely frustrating for users on slow connections and an exploiter could send a fake walkspeed over to what they actually have and completely bypass the walkspeed checks altogether.
Listen = Route.OnServerEvent:Connect(function(Player, key, listofstuff, walkspeed, hipheight)
    -- .... code for checking here
end)

wait(30)
if GotResponse == false then
    -- handling ban...
  1. Unncessessary whitespace in the localscript
    The whitespace in the localscript I assume serves as to
    make it:

However, I believe most modern decompilers used by exploiters will not have whitespace when viewing as the compiler roblox uses ignores whitespace and converts it into bytecode, which an exploiter will use a decopmiler to convert that bytecode back into a readable format which means the whitespace added will not contribute anything to the decompile script. If anything it just makes it harder to develop/read.

  1. It just plain doesn’t seem to work
    I couldn’t seem to trigger the anticheat in studio, I’m not sure if this is the anticheat failing to detect me or i’m doing something not within range but when I set my walkspeed it didn’t seem to affect anything, nor did setting a part to cancollide = false and walking through it.

(Testing the noclip detection)
https://streamable.com/yopy0m

(Testing walkspeed detection)
https://streamable.com/tnkicd

3 Likes
#5 
getnilinstances().w.Disabled = true

Would completely disable your client side detections.

game.Players.LocalPlayer.Character.HumanoidRootPart.TouchInterest:Destroy()

Would completely disable your server side anti-noclip.

Here’s some information to help you improve:

Clients control some server side events like .Touched, .MouseClick, and .PromptTriggered. If it’s possible to detect something server-side, do it. When people say to never make a client-side anti-cheat, I disagree. You can make one, just don’t waste all your time on it. At the end of the day, cheaters with little knowledge of Lua can disable client-side detections.

To improve on your anti-noclip, I suggest making a loop and recording the last valid position of the player, and then the next time the loop runs, compare the last position to the new one. Draw a Ray from the last position to the new one, and see if the Ray hits anything. Check if the part is whitelisted (collisions off, etc), and then rubberband the player back to the last position if needed.

1 Like
#6

listofstuff is the table of stuff fired from client to server

#7

The main issue with that is that it’s fired via a remote (which I explain their flaws in section 2.)

The main issue with using remotes is that they can be easily exploited by the client (e.g send fake values over to the server, or prevent them completely)

I don’t see any valid reason why an exploiter would send over a bodygyro through this remote. (They can entirely spoof all values sent through it)

#8

Maybe i should just tie a part toe the character and make that part serversided.

Then I do sanity checks on the movement of that part to figure out how it got there…

actually nvm exploiters should just go work for nasa, they won the battle

#9

99% of the exploiters probably just download exploits from sketchy websites. Not NASA worthy.