Client Side Anti-Exploits

Help and Feedback Scripting Support
#30

The problem in this situation is I am not trying to read my own anticheats. I know how it works and operates and i’m practically never touching it. The real goal is to stop exploiters from reading it.

#31

Worth the time really depends on cost/benefit. We can both agree writing solid server code is the priority!

2 Likes
#32
  • It will be deobfusticated
  • Exploiters will spoof the handshake return value
  • That doesn’t exist on roblox
#33
  • not if you use an anti decompiler
  • not if they cant decompile the code
  • yes it does
1 Like
#34

Listen bro the code you get is a computer generated re-compiling of the bytecode from your scripts. when it’s trying to read obfuscated code it’s guaranteed to return broken code.

That most definitely exists. It all depends on the exploit you’re using and how it recompiles the code

#35

Was outlining that the original poster had mentioned other devs disliking client-sided antiexploits…

I was speaking about the general hatred towards client-sided antiexploits that is (now) evident in this thread… was not implying that anyone specific in this thread had mentioned them being useless

Also wanted to point out that I was not replying to you but rather the original post

1 Like
#36

What was the point of you outlining that? There are ways to keep your code running using threads.

Of course this can also be tampered with if you mess with the garbage collector, but that’s too much effort.

#37

What you are doing is something called Security through obscurity. Sure, the code will stop exploits but only for a limited time. It only takes one exploiter to find out what your script does and exploit it. And then all of the exploiters who don’t know what they’re doing will also know how to get through your obscurity.

The best way to make any kind of anti-cheat is to just make simple sanity checks on the server. For example, if a player wants to pick on an item, you should use the server to check if the item actually exists and if the player is in range of the item.

4 Likes
#38

Of course server sided checks come before client sided checks. However, the problems that I’m solving on the client are strictly client sided effects like saveinstance and dex explorer.

#39

In the end of the day, you will never be able to truly stop client-sided exploits. You simply don’t have the tools to do so. Kicks from the client can be bypassed, Dex-Explorer’s GUI takes on a random name so there is no good way to detect that either (at least not that I know of).

You should build your game in a way that even if they use Dex-Explorer or saveinstance exploiters still would not be able to completely exploit your game.

1 Like
#40

You do this by like I’ve said above, using server-sided checks, not trusting the client with anything, ensuring nothing important can be accessed by the client, and more.

#41

Let me clear this up this debacle. I am all for server sided sanity checks, but the full dismissal of client sided checks is completely naive and foolish.

The whole point of my client sided checks were to make it more difficult for exploiters to even reach my server sided checks, let alone view the way my games work.

Also:

I do not do client sided kicks

There’s no way to detect it like that. I will not be disclosing my method, but you have to detect the behavior of the GUI instead of the GUI itself.

1 Like
#42

I’d like to mention it is not possible to write unreadable code. Hard to read, yes, but if the computer can read it so can a sufficiently able human. Currently the most commercially available and very popular anti-tamper obfuscator is probably Denuvo, and even that is bypassed after a while.

#43

Hi. The computer generated output from the bytecode is not always accurate and going through the bytecode manually is a pain in the butt. Nobody is that dedicated.

#44

You would think! They do exist! Probably not for less than the highest bounties though. Cracking as a subculture has existed for as long as software protection.

2 Likes
#45

My awful opinion: try to ruin their experience, this will likely depend on what kind of game you’re making, for example:

Let’s say that your game is heavily based on UI’s, put all the code that functions the UIs into 1 single local script, and put a client-side anti-exploit inside the local script.

The exploiters will try to delete that local script that has the anti-exploit inside it, but that will make the game unplayable, thus making the exploiter leave.

I am unaware of ways this could be bypassed so if there is a way, please let me know.

1 Like
#46

This actually seems like a good idea, although my game is a fighting game so I doubt there will be much difference because the exploiters can just fire the remotes anyway. Although if the server can somehow detect that the local script is disabled, that’d be great.

#47

Any changes made in the client can not be seen by the server, but that excludes changes to some properties of the character/humanoid such as

walk speed, JumpPower, Character’s CFrame, Animation (I’m not sure), and some more.

So unless there is a hacky way that I don’t know, you can’t detect whenever a local script has been deleted or disabled.

#48

Sadge, but it would be nice though. I’ll try finding some other solutions for anti-exploits, thanks for the answer though.

1 Like
#49

Hey, I quickly read through your question and here’s a plain answer. If a exploiter got put up against this detection this is most likely the first thing that’d pop up on their mind:

for i,v in pairs(getconnections("script path")) do
    v:Disable()
end

But this isn’t the most stable bypass for an exploiter to run since Disconnected connections is detectable. That’d simply force the exploiter to do this:

local namecall = nil
namecall = hookmetamethod(game, "__namecall", function(self, ...)
   local NamecallMethod, Parameters = (getnamecallmethod or get_namecall_method)(), {...};
   
   if NamecallMethod == "AncestryChanged " and self == "script path" then
       return 
   end
   
   return namecall(self, unpack(Parameters));
end)

the best way to prevent local scripts from being disabled is to make them run in memory. Disconnect them fully from the client(Well not fully since it runs in mem but partially), Its not possible to disable memory or a script that’s running in memory

1 Like