Our dumper works within the player’s loaded files, transferring your client.lua files securely to the server for approval. By doing so, we prevent dumping and ensure that specific natives read the code, thereby restricting access to files like client.lua.
Support us by giving a star on GitHub to ensure continued content!
Advanced Anti-Dump Protection:
Safeguard your scripts from unauthorized access and modifications
Easy Integration:
Seamlessly integrate into your existing FiveM server setup
Regular Updates:
Stay protected with frequent updates and enhancements.
This doesn’t make any sense to me, you transfer “client.lua” files to the server for “approval”? What? How does this work if the client needs to read the files in some fashion anyway?
Not even that, that isn’t stopping dumping. Dumping is just basically downloading client side files, so that whole system doesn’t even touch a dumper. The client file is still there, it’s not magically gone and for it to work on the client it still needs to run there.
In our tests, we noticed that when the file is read, it interacts with specific player data. Therefore, this method ensures that the job.lua code example in the filter is sent to the client as soon as the script runs, ensuring processing occurs within the script itself rather than on the player’s side. This approach prevents obtaining an empty folder when dumping, as load(v) is executed even if the script is stopped and an attempt is made to manipulate operations. I hope this clarifies it better.
No, for instance, remove Lua definitions in your policejob script and execute them within the dumper filter. This method ensures data flow between codes in the file, meaning players won’t download the file, resulting in empty dumps. We’ve tested this on several executors, and our loyal customers still use it. Of course, we can brainstorm and make additions as needed. “client.lua”
The only way to “protect” your stuff is to use escrow. As long as you load readable code its still possible for the client to get it. Sure its harder to get the code but its not a protection at all.
Unfortunately, when you join the server, you are loading files that remain stored. Dumpers can extract these loaded files. Here, we are not loading files. We transfer the code to the client and load it. We might be able to separate the code with json.encode, but the problem is that the executor needs to send a request to the trigger, which we prevent. Once the game is loaded, it won’t enter the if statement again, so it can’t retrieve the code from the server unless the script is restarted. Therefore, what you mentioned is not very feasible. However, escrow is indeed a good protection, and a ready-made core could also be a good option.
I think you don’t get the point. As long as the client can recive unprotected code (yes even if you load it from the serverside), its still possible for the client to get access to it. Its simple. So everything you send to the client = unprotected. As long as you don’t use any encryption (escrow) its not protected at all. You just build a workaround so the client files don’t get streamed, but the client still recives open code even with your loader.
In essence this is literally pointless then, adding overhead of hot-loading logic instead of actually doing it the intended way, while adding nothing to security. Good job lol
Other posters are correct, if it’s on the client at all, even if hot-loaded, it can still be access and dumped; while this may prevent some specific dumpers, it doesn’t prevent the issue overall. Using Escrow for your client-side code is about the best one can do, you can in theory get the bytecode, but that’s considerably harder to do anything with.
Dump Blockers:
Support us by giving a star on GitHub to ensure continued content!Advanced Anti-Dump Protection:
Easy Integration:
Regular Updates:
