I’m just curious, since using exploits is obviously against the rules, how do people create anti-exploit scripts? I know they can probably replicate their own “exploits” by creating un-recognized guis or whatever in their game, but what if someone wants to specifically test that this works on an exploit for sure? I know nothing about how exploits work, so I wouldn’t really know what to look for and remove in a game for exploit prevention,
Exploit GUIs are usually inserted into CoreGUI and retain the same function as normal GUIs. You can easily figure this out by looking at some of the open source scripts on V3rmillion and other sites. Other exploits are made by ‘exploiting’ (as the name implies) certain vulnerable game features, such as unprotected events in the case that you can just fire the event and get free money without any sort of checks on the server to make sure the player deserves this money.
1 Like
They really don’t.
Even ones by PF and other games always seem to get bypassed.
There’s far too many things an exploiter can do to their client, and trying to track all of this with a LocalScript just doesn’t work.
Don’t focus on making anti-exploit scripts, but instead focus on making sure you never trust the client, and verify things server-sided.
8 Likes
I second this, and I also think depending on the game you could go as far as adding extra checks on the server. For example if your game has out-of-bounds areas or your players shouldn’t ever be moving faster than a certain speed, have a script that teleports them back if they break these expectations. But the general rule is that anticheat scripts—especial client side ones—are like band-aids for open wounds. A properly configured game doesn’t need one.
1 Like
Never trust the client and always have in mind what the client can and can’t do.
2 Likes
Every client anti cheat is practically useless with the limitations roblox has. The best you can do is try and detect exploits when they inject, secure remotes, and prevent your scripts from being decompiled.
1 Like
13 posts were merged into an existing topic: Off-topic and bump posts
Please do not name-drop or veer off-topic in support threads.
It isn’t an easy task to create anti-exploits. My suggestion would be for you to secure your games remotes. As you probably already know, exploits are client sided and anyone can modify the client so it’s not really productive to target the exploit themselves, instead, you should just work on securing your games remotes.
One main rule you should always follow is to never trust the client. And when I say never, I really do mean never. Anything can be read, modified, and changed on the client so you really shouldn’t trust it. Some bad practices that go against this rule include: invoking the client, localizing currency checks for in-game shops, checking walkspeed on the client, etc… The best way you could think about this is think whenever a player joined your game, a GUI popped up that showed all of your game’s remotes, arguments, and a fire button.
TL;DR Secure your remotes. Never do local checks, always do server checks.
3 Likes
You can’t stop scripts from being decompiled. On a game that was built with proper client-server interactions in mind, it doesn’t matter if an exploiter has your game’s LocalScripts, it doesn’t help them.
1 Like
Yes you can stop them from being decompiled. You cannot prevent them from grabbing bytecode.
I heard about you stopping Rovive from being decompiled aswell as just stopping injections in general for Ripull
If an exploiter has your bytecode, they can decompile it. You can put hurdles in the way, but if the code executes, it can be decompiled. Never assume it can’t be.
Edit: Actually let me expand on this more.
There have always been a few open source Lua decompilers out there, and generally when an exploiter is decompiling scripts, they’re using one of those decompilers but repurposed for Roblox bytecode. Decompilers like this are usually known to have bugs and edge cases where putting certain things in your scripts will outright break or confuse the decompiler.
However now in 2018/2019, more and more cheaters are writing their own decompilers. That or the cheats they’re using are growing more advanced. They tend to have decompilers built into them that were written specifically for Roblox. They get updated when something doesn’t work correctly. Vulnerabilities in the decompiler don’t stay like they did before this became more common.
Always assume the people cheating on your game have access to tools that surpass anything you can do to slow them down. It is possible to make a game that’s exploit-proof with proper client/server code. You don’t need to prevent decompilation or write a good anti-cheat. There are no secrets. Just trust the server foremost and validate everything coming from the client.
2 Likes
It doesn’t matter if they have local scripts, never trusting the client is the only thing you should care about when it comes to security.
Even if it doesn’t actually affect the gameplay if they have the localscript, it would still be nice if all the work you put into making the UIs aswell as camera manipulation and other client-sided things wouldn’t be instantly stolen by someone.
As far as I know, the script sources are sent to the client where they are compiled, meaning it should be readable. Although it’s possible that it’s the bytecode which is sent, which would align with @bmcq_12 's explanation.
Also, if I was him, I wouldn’t release either.
It’s like calling for exploiters.
Byte code obfuscation (with debug data removed) would prevent someone from getting the direct source code of a script, but a determined exploiter could still just re-assemble the source from viewing an assembler of the byte code. (ie reverse engineering)
There’s lots of projects that do this kind of thing, the most notable one I can think of is LBI:
Its sad that localscripts can be stolen so easily and there is literally no way to fully block it, there is some amazing client-sided stuff I’ve seen that just really doesn’t deserve to be stolen at all
I thought it was against the rules to use v3rmillion?
If you really want to prevent your localscripts from being stolen do some research on what luadec and unluac is and learn how they work. If you can learn how they work then you can find flaws in how they work. Find the flaws and abuse them to the fullest extent possible
I didn’t say use it, I said just read some of the open source scripts to see some of the concepts that exploiters use to make their scripts.