It is 100% my priority and reverse engineering is a fat waste of time if it’s too difficult to where exploiters won’t even bother which is why im trying to make mine the best I possibly can
\it will be about as effective as treating the deadly psyllium disease.
1 Like
Hey I appreciate the baseless feedback man. Just makes it look great. Can’t give feedback on something you know absolutely nothing about 
The fact is that the client anti-cheat has fundamental limitations due to where it is executed. Everything that works on the client side can be changed or disabled by the player. This is not my opinion, this is the principle of the client-server architecture.
What’s to stop a cheater from just disabling your anti-cheat?
How are you going to protect your code from being modified by a cheater?
Do you realize that a cheat can literally substitute the values of variables?
A cheater can literally just disable your anti-cheat.
Nope R.I.P in detected 
It has a very complex handshake that completely prevents that from occurring
It already is protected and I’m gatekeeping any important info about it
the only fundamental limitations are the ones that the poor exploiters who try to bypass it will have after getting jumpscared and kicked from being detected 
Just saying that it is “impossible" is not enough
How do you protect the code? Obfuscation? It slows down, but it doesn’t stop.
1 Like
Dude I just said I’m gatekeeping any important info about it. I’m not stupid people obviously will look to figure out how it works in order to bypass it. The funny thing is I haven’t even completely bypassed it and I’m the developer of it Trust me when I tell you I know a LOT about exploits and I’ve already decompiled it to know what it looks like when decompiled. I pity anyone who actually manages to decompile it
correct me if I am wrong but don’t variable names become anonymous when decompiled?
for example, smt like this
local myString = "Hello"
local apples = 5
local Hello = function()
end
would be smt like this ?
local 0x10 = "Hello"
local 0x12 = 5
local 0x32 = function()
end
but variables values specifically strings would be non-anonymous unless you obfuscate them which would become useless when someone deobfuscates them
note that they can see the returned value from the example below
local mystring = `72 73`
local function simpleObfuscate(str)
local result = ""
for number in str:gmatch("%d+") do
result = result .. string.char(tonumber(number))
end
return result
end
print(simpleObfuscate(mystring)) -- HI
1 Like
yes they do and that’s what i’m trying to do. I’m trying to make it so that the decompiler gets completely cooked as much as possible lol
1 Like
You say you know “A LOT about exploits.” Great. Then you should understand that it is impossible to completely protect the client code from modification. The only thing you can do is make it harder. Obfuscation, encryption, and dynamic code generation are all useful tools, but none of them are silver bullets. And saying that you “keep an eye on any important information" is not a strategy. You need to prevent modification, not just react to information leaks. If you don’t understand these fundamental principles, then I’m afraid your anti-cheat is bound to fail.
- I don’t understand. You’re saying that you’re hiding information so that the cheaters won’t get the code? But doesn’t the client anti-cheat work on the client side? Doesn’t this mean that cheaters will see the code anyway as soon as they start playing? What’s the point then?
I don’t think that I can help much with that but here is some stuff that I know
use anonymous functions because they don’t keep their name when compiled
--do
local HI = function()
end
--instead of
local function HI()
end
try to avoid strings as much because they will be decompiled with the same on the client even when they are obfuscated the client can run the code that obfuscated them to DE obfuscate them
most importantly make sure to have a server anticheat in case the client anti cheat got bypassed
client anti cheats can stop a lot of exploiters but all it takes is 1 good to exploiter figure out how to get around the anticheat then he would release the exploit for people to use
3 Likes
absolutely not
Hey if they want a free chocolate chip cookie for bypassing mine… they deserve it after all of the torment they will have to go through to get there.
I appreciate your anonymous functions idea and I think it’s really smart so thank you for helping me!
I welcome all exploiters who decide to pen test my game and try to come up with a bypass.
Only the most daring of people will ever try and to be honest… unless they give it 100% of their time and effort they will likely fall short lol
1 Like
I think your curiosity is laced with some bad intentions but I felt like I need to clarify this one and the simple answer is no they cannot view it with dex explorer
I mean there is a method with saveinstance to get it to skip specific scripts, but hackers can still decompile it. Like for example all you have to do is get a normal script, and set the runcontext to local. it’ll work ig
1 Like
I forgot to mention, you can “hide” them with unicode (or utf8) sequences like apple will turn into \x61\x70\x70\x6c\x65 which when printed will return apple, so its a very slight deterrent but will make it annoying for less experienced exploiters.
I used this to encode UTF-8 Encode - Convert Text to UTF-8 - Online - Browserling Web Developer Tools
1 Like
Thank you so much! You have a brilliant mind 
No worries, the main reason I found out this quirk of roblox (and other systems possibly), was because I was looking into exploits people used with them for data roll-backs for utf8 strings and stuff.
1 Like
Had a similar predictment of protecting tables on the client a few years back and my idea was similar to what you’re thinking with encryption but slightly different. What i did was firstly make a table to string function then i took the output and hashed it with sha256 and sent that to the server along with its HMAC.
Then on the server I had an identical table which I also turned into a string and hashed the string which I then compared against the client and check the HMAC to make sure it wasn’t spoofed midcall + a step counter so if the client stopped the call the counter would be desynced between the client and server - see Valkyrie.
This is you’re best bet but if you want soley client sided protection you can check metamethod calls or use CRC integrity check and of course obfuscation.
1 Like
Both of you are very intelligent but @XoifailTheGod had the best answer because decompiling isn’t something I am afraid of as my anti cheat is very strong the only thing I needed is various ways of improving it further and I find his solution to be the most complex
While I don’t usually reply to the whole client sided debate and while you are techinally right that no client sided system can be made invulnerable but that doesn’t mean it’s useless. That’s the same logic as saying “locks can be picked, therefore doors are pointless.” In security, impossibility of perfection is not a reason to stop defense.
While yes, the client can be tampered with. This is not unique to Roblox. Every operating system, AAA game, and secure app in existence runs on a client side machine that is physically owned by the end user. Windows? You own the hardware. Riot Vanguard? You own the hardware. iPhone security checks? Local. The Secure Enclave, the TPM, the Secure Boot, and kernel level anti cheats, they all run on hardware physically owned by the attacker.
But so why do they work? Because they are part of a layered security model, often referred to as defense in depth. Their job is not to eliminate cheating; it’s to detect, slow down, or raise the cost of cheating, ideally enough that it becomes nonviable at scale.
Correct. But so can everything on a server, given physical access or a vulnerability. Your argument is about trust boundaries, not invincibility. The point of a client side anti cheat is to operate within the client trust boundary. You can’t detect injected memory manipulation from the server. You can’t detect hardware assisted aimbots or hypervisor level manipulation from the server. Only the client can see these behaviors in real time.
Not if the anti cheat watches for tampering. Not if its telemetry system notices missing heartbeats. Not if you combine server enforced heuristics, client side monitoring, and redundant code paths. Every commercial anti cheat knows this and they don’t stop trying just because a cheat can theoretically interfere. That’s the entire point of obfuscation, sandboxing, and integrity verification: not to be perfect, but to be effective enough.
The same point as encrypting your bank credentials before sending them across the network the attacker still sees the message, but they don’t understand it. Obfuscation and packing are delay-and-confuse tactics, not silver bullets. Every extra hour spent reversing is an hour less spent cheating.
Also: real client side systems dynamically mutate. Functions can self delete, unpack in memory, load from encrypted tables, verify each other’s behavior, and even set traps that intentionally crash the game under modification. This isn’t new tech this is what Vanguard, BattleEye, and Easy Anti-Cheat do every day. And they’re not made useless by the fact that they run on clients.
Let me put it this way: if clientsided anti cheats are so flawed they shouldn’t exist… then how come every major competitive game uses one? Why doesn’t Riot just do all their anti cheat on the server? Why does Windows Defender run on your machine, not in the cloud?
Because client sided security isn’t optional it’s essential. It’s imperfect, yes. But it’s still the first and most immediate line of defense against local manipulation, sure its alot harder in Roblox and 90% of what a kernel anticheat does can’t be done but that 10% is more than enough because just like how the client is never perfectly secure theres also no perfect hook + many exploits simply don’t have the techinal know how to bypass a well made anti cheat.
4 Likes