This really won’t help. Just don’t write your code in a way that can be exploited. Use the server to do anything that you can’t trust a client to do, there shouldn’t be a reason to obfuscate your remotes honestly. A good design is one that the client can’t exploit.
What’s the use case, exactly? I mean, if your code is secure on the server.
This could easily be bypassed if you know what you are doing, that being said most exploiters have no idea what they are doing. Obfuscating your remote names only does so much, using a GUID does just about as much as setting the remote name to an empty string " ". Just don’t be surprised if it gets bypassed quickly.
At the end of the day you shouldn’t really have to worry about doing this but if it makes you feel more secure then by all means.
With this I’m trying to make it as annoying as possible for exploiters to try interacting with my remotes, I am aware they can really if they want to just loop through ReplicatedStorage and fire all objects that are RemoteEvents. As stated above my server & client interact in a way which does not make it possible to server-sided exploit the game in any way.
This system is really just so people “waste” their time trying to exploit my remotes & because I was bored and tried out some stuff 
Sorry but like
This seems pretty useless to me, I’ve made a system where you’ll need a key for each request and that key gets regenerated every minute or even seconds depending on how I want on runtime.
Also forces them to use my module to actually fire a remote so they’ll have to grab that aswell ( have fun doing that). Then again client security isn’t something you should rely on
Great server security + some bit of client security is good enough. I also did it for fun shrug
In games like Jailbreak for example the client is a heavily dependent feature for the game - some things are obviously local scripts. The main issue with game development is that it’s hard to “write a script in a way that it won’t get exploited” as the issue with exploiting is that they always try to find a way to exploit something. Unfortunately as the client is a component of the game engine which connects to the server - and the client is stored on the exploiters computer it can be relatively hard to stop every attack they can create, it’s a shame really because it really can ruin a games experience.
As for in terms of protecting your games I’ve always wondered if you could use an encryption / cipher is scramble the name of the remote event. Periodically allowing for the client to change the name however the only issue with this method is that the exploiters can see your coding on the client side and so the decrypted would thereby be compromised (and if anyone knows the rules of having a secure encryption you’d find that an encryption is only truly secure if only either party know)
Encrypting the remote names is completely useless as they can be grabbed either by upvalues, waiting for the remote to fire and matching the arguments somehow, and many many more methods. If you really wanted to, you could encrypt your remote arguments but that is a waste of time.
As you have already said, your game is secure. Wasting your time with client side remote scrambling is useless and a bad use for your time which could be spent on other things 
Edit: You are not the original poster, my bad. I wasn’t paying attention. However, my point still stands.
Don’t rely on this. Secure remotes server side, don’t trust the client.
A good thing to do is to have all the important things (anti exploits too) in one local script, and then obfuscate it. The exploiter can’t do anything to this as 1, if they stop the localscript it they will mess up their own gameplay, 2, they have no idea what it actually does as they can’t read the code and develop decent exploits.
However, exploiters apparently can’t decompile local scripts anymore and haven’t found a fix yet. If this stays then y a y.
Exploiters are still able to decompile local scripts, it’s just that due to the new VM all old methods are broken and need to be redone. It’s also slightly more difficult.
Additionally, it breaks many exploits because of the new bytecode structure but also because we no longer embed local variable names in the bytecode. (worth noting is that fundamentally the VM isn’t more secure aside from that and we expect exploiters to catch up)
Client security is not a good use of your time.The client can just replace these protection scripts with their own and basically tell the server “hey, everything is ok”, while abusing the remotes. Literally everyone has said this, but securing the server and not trusting the client is the way to go.
Synapse already has a functioning decompiler for Luau (the new lua vm). It’s not released yet but I’ve seen it in action.
Because the new VM removes local variable names so the decompiler has to come up with random ones. So if I have the variable name “local hello = ‘hi’” it would become “local variable1 = ‘hi’”. You get the gist.
Yeah this makes sense, it was expected. However no one has ever decrypted Ironbrew, and they’ll give $700 to anyone who does. It’s $20 for unlimited use so I suggest it to anyone who wants to protect their important client scripts. It has no flaws/slowness about it as far as I know.
Yeah I recommend Ironbrew. Creator of it is the guy making the Luau decompiler and I bought the source of Ironbrew off of him for my current project.
While it’s indeed close to impossible to deobfuscate ironbrew, it doesn’t mean you can’t do anything with it. Afterall it’s still regular lua code, just broken down to the simpliest instructions.
There are various common and less common methods which people use on ironbrew and other obfuscators, such as:
most of which you can do at runtime with exploits too, without editing the code.
It is very hard to do this though, and lets be honest vast majority of exploiters don’t know much about code. They just injects basic exploit scripts off places.
Not really. As I said, even if you recreate the lua vm in lua, it still has to perform everything with lua. Meaning if you compile a == b, then the vm will have to use == operator at some point in the code. Same for calling functions and so on.
That’s actually not entirely true either. A lot of exploiters know how to script decently, and they are the ones people like OP are trying to protect against.
Debug information is also stripped from the bytecode meaning all variable, upvalue, function, etc names are not included. It is basically minified code.
Exploiters can also take the obfuscated ironbrew code and run it in a sandbox. Writing a sandbox is quite easy to do as well. It takes a few metatables, some helper functions and you’re basically done. That lets you track literally everything a script does and even change functionally and spoof values.
I did say at the end it would be pointless seeming as an exploiter can literally see the events 
Thinking about it though what would be the best method of stopping an exploiter locally. Because obviously you can use unique names which can vary themselves but it’s not enough is it seeming as nothing really stops an exploiter from as you said waiting for the remote to fire. Also a big shame that you can’t do two sided encryption but as long as people don’t make functions with limitless potential then at least it will only be one sided exploits. Thank goodness they can’t control the servers, I don’t get why they find exploring fun though - I prefer to actually play games like Lumber Tycoon 2 instead of ruining it for everyone
The best way to fight exploits on the client is to not allow them to leverage important systems in your game. Client-side anti-exploit is for if you want to attempt to further secure your game. Focus on making your server secure first.
hey rvvz where i can find ironbrew https://obfuscator.aztupscripts.xyz/Home if t this then i cant acces to site sorry for late reply 