Easiest way is to use a minifyer. This does not prevent people from “stealing” it per se, but makes the script illegible.
Also, they can only “steal” client side code. Anything server-side is safe, unless you have open SFTP/FTP access for some crazy bad idea.
/// edited /// 20 char
so what is this server event security tokens ? if server side is safe ?
From the OP:
…
Unrelated to the tokenizer(sorry, gramps!) but regarding the discussion of protecting client scripts, I was thinking about this last week. I imagine it would be possible to modify or create scripts that would keep skeleton functions on the client side but that would require server to pass the meat and potatoes of the functions over on connection, wouldn’t it? In my mind, I imagine something that required an initial var to be passed, one that contained the contents of that function to be passed over which would then be used. Without those vars, I picture the client scripts providing even a more incomplete picture of the script than just missing the server side.
Would that be something possible without huge performance losses?
No worries. All good discussion.
Yes, that would be possible. I have thought about that as well: having the server deploy scripts on client load. If I get a stable solution for it, I’ll share. I actually think it would be relatively easy to do, but fear that someone could just create their own listener and still get the script. It could be implemented in a similar way to this tokenizer resource to generate unique events everytime a player joins to attempt to mitigate that.
Ultimately, it’s best to do everything you can server side. Obviously you can’t do UI, etc. server side, but lots of logic can be easily offloaded to the server and protect it. That reduces performance hits on the client while also protecting your scripts from being stolen and from being exploited.
This resource looks pretty solid for syncing data between the client and the server. It could be a good start to syncing scripts.
when i revive player. i get banned. because of invalid token. i event dont use for ambulance script.
Then whatever the ambulance job is triggering isn’t inside of the ambulance job resource. Turn on verbose server logging and you’ll see the impacted resource.
So now practically, there would be no way for a cheater with serious intents of cheating, of bypassing this? after all these changes
If implemented correctly, a cheater cannot trigger server events.
So, what your saying is, there is absolutely no way for a cheater to trigger events using a LUA injector? (accept magically guessing the tokens)
They cannot trigger SERVER events without somehow guessing a 24 character string. They can still trigger CLIENT events.
so es_admin’s ban event would be a server event right?
I would imagine so. I don’t use es_admin, but that should be server side.
great to finally see a full proof solution to lua injectors on FiveM. Great work Salty 
does this also work for Vmenu, since it is written in c#? (apparently a cache decrypter picks up c# server events which can apparently be triggered by the lua injector)
You should be able to use Lua exports in C#. It will require modifying vMenu. I don’t think that’s needed since vMenu allows you to configure permissions. But I don’t use it so I don’t know for sure.
Working?
Sure is.
