AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Roblox hacks client2/5/2024 ![]() This is a very simple example of a handshake a more advanced one will, as mentioned already, use keys and encryption to make sure an exploiter won’t just be able to replicate it cough cough aston v1 cough cough Conclusion Player:Kick("Communication Timed out") -> The client was most likely disabled or the event was blocked If tick() - PlayerData.Handshake > 30 then > In a while loop check PlayerData if the handshake time is over lets say, 30 seconds PlayerData.Handshake = tick() -> Reset Handshake Tick Remote.OnServerEvent:Connect(function(Player) Remote:FireServer() -> You would normally use keys and encryption to aovid exploiters just replicating this loop However, this is a simple example, so it will be a simple FireServer. Usually, you would use keys and encryption so that exploiters aren’t just able to replicate the handshake. Here’s a simple example on how to implement this: If the server doesn’t receive the RemoteEvent within a few seconds, the client will get kicked. This is where handshakes come into play.Ī handshake is basically the client sending a RemoteEvent to the server every few seconds to validate its still alive. While the environment hide feature can take care of preventing it from being disabled or deleted via DEX, exploits are still capable of hooking a function that the script uses and causing it to yield. One of the most common reasons client-side anti-cheats receive criticism is due to how easily they can be disabled or deleted. It is also not visible in getnilinstances() Handshakes This script will no longer show up in Dex Explorer, and it also cannot be accessed in order to disable or destroy it. The following code deletes the script from its environment. Print("Hello World!") -> This will still run! Environment HideĪ simple method to hide the environment of the script would be as follows: getfenv().script:Destroy() ![]() ![]() Let’s start with a simple method that prevents the anti-cheat script from being displayed in Dex Explorer and being disabled or deleted. So the point of this tutorial is to show you how the client-side can be secured. I bet that 90% of the DevForums users who make these claims have never actually attempted to create an anti-exploit system themselves. However, it is worth noting that some individuals on the DevForums may make such statements without having practical experience in developing anti-exploit measures. Now, I am not going to say that this claim is 100% false the client should indeed be considered as a secondary defense, with the server being the main focus for security. If you’ve been on the devforum for a while, you’ve probably already seen the saying, “Never Trust the Client”, alongside multiple reasons why you shouldn’t develop a client-sided anti-cheat.
0 Comments
Read More
Leave a Reply. |