Thank you! Also that’s a good question! It honestly depends… Minification is unecessary (renaming variables to the most basic thing they can be and removing whitespace) since it’s basically already done by the compiler, but if the obfuscator isn’t just minifying code and it’s changing the structure of the code then that structure will be maintained in the bytecode.
If the obfuscator is making strings harder to read somehow than it may help a little bit but at the end of the day you shouldn’t really rely on an obfuscator to keep your code safe since there are other methods of figuring out how these scripts actually work (such as looking at the content of variables and hooking function calls).
The only time I think an obfuscator might be useful is when sharing code you want to keep secure legally… People can figure out how it works but that doesn’t mean they can recover the original code you worked with or modify it.
In my opinion, I really don’t find obfuscators that much use at all. Sure, they can slow down the process of finding the actual content behind the obfuscation, but commit half an hour to using Ctrl + F and replacing stuff and you land yourself with the fully functional script.
If the script is not properly debugged, obfuscation methods can also make debugging 5000% more miserable since you have no clear cause of the issue without having to go through the process of deobfuscation yourself.
I feel like some of these resource threads and discussions are often heavily imbalanced: you have people who talk about Lua, then those who just talk about the C-side and technical details. There’s no real middle ground and I find following conversation a muddled process. I appreciate that you took the time to summarise some of those concepts when addressing them rather than assuming readers have that kind of knowledge off the bat.
I had a read through it and it’s definitely got a beginner feel to it. I don’t quite know about intermediate though, seems to be more like a refresher and fact check sheet, but overall I don’t mind. TIL categories of anticheats (no seriously, before I didn’t look into it and I didn’t care much either).
A good way to catch loads of exploiters is to make lots of different fake events and then you know when someone is an exploiter if they fire one of them.
Another way to honey pot is if any parameter passed to a remote is missing or wrong but wouldn’t be if it was a real request then you know that it’s an exploiter.
Yeah, I guess it depends on your idea of intermediate. I tried to keep the explanations simpler so that it would be easier for beginners to understand it while getting a lot of the information across. Also those anticheat categories are more of my own classification I guess. I’m glad I taught you something though!
@grilme99 That’s a good thing to mention. I was sort of trying to include the second part of that but I guess I didn’t get to the first part.
Would you consider returning to this thread with some examples? I feel like you and Colbert both have the right of it but I’m not worried about what I should reply when someone asks me - are you beginner or intermediate? - I think it’s more important to know whether or not I understand what’s being discussed or looking at a subject that I already know about in a new way.
Your example about how to consider using tables is really interesting and relevant. I’d love to see more step by step examples of that if you were whiling to dive deeper into the example.
There are many ways to do it but often you’ll see people looping through all the players/characters for example, checking for odd differences in speed/height. As-well people usually handle some of this inside their remotes to check for false info sent from the clients, this is usually indicative of an exploiter trying to fire a remote manually. Thats kinda the basis for how the checks work if this is what you were referring to.
The problem is, they always come with new alt-acc’s back. Try to find a way to distract their interest on your game. Pain them passively with things like Data-Bombing that raises their pings and fps, so (artificial) lagging occurs.
No one likes (massive client-)lagging games. If they decide themself to leave, they don’t come back.^^
I’ve updated this article! I’ve added a few code examples, honey pots (as suggested by @grilme99), and rephrased a few things slightly just to make them clearer.
Also I apologize for SPACES but I typed this on mobile. I’ll make sure to update it when I can.
IP bans have been discussed previously and personally I disagree with this. An IP address is only linked to the router. On public WiFi, or shared WiFi you could be banning potentially hundreds of people. By accident. Also, IP addresses can actually be changed relatively easily. Some routers allow you to do this in their settings I think (although I’m not positive) and I know for a fact you can simply contact your ISP. That’s mostly a way for people to stop DDOS attacks.
So if I’m understanding this correctly, the fact a local variable cannot be decompiled makes it easier for the exploiter? Sorry I’m not quite understanding this sentence, could you elaborate?
Sorry, thank you for pointing that out! I’ll reword that.
I’ve updated the post with this:
That means any information which is not included, like local variable names and comments also cannot be decompiled. This absent information would make the decompiled code much easier for an exploiter to read.
It would depend on the decompiler but they would see something along the lines of this:
local var1 = 5
local var2 = 10
print(var1+var2)
Note: Globals like print, game, workspace, etc along with properties and table functions will still be decompilable since these are either constant (for Globals) or rely on strings (for tables/instances)
I do a thing where I track how often an event is fired by a player and how often it could possibly be fired. If an event is fired at unreasonable speeds(clicking something 10 times a second when my client coding doesn’t allow it for than a couple times a second), I will usually kick the player.
Even though my events are fully logic protected(to my knowledge of course), I don’t want exploiters to even have a good chance to tamper with them, so I kick them for even trying to spam them.
I think I would suggest simply ignoring clicks which are too fast. Some people can click extremely fast. I can click over 10 times a second easily and I don’t think I’d like to be kicked for clicking too fast personally.
Also that’s a good question! It honestly depends… Minification is unecessary (renaming variables to the most basic thing they can be and removing whitespace) since it’s basically already done by the compiler, but if the obfuscator isn’t just minifying code and it’s changing the structure of the code then that structure will be maintained in the bytecode.