This is a bad and incorrect advise, os.time should not be used for calculating delta times as it is only accurate up to an integer.
@Reapimustime() should be used in favor of tick(). It is constantly updated per physics simulation frame as it is based on physics simulation. So if physics slow down in your game, time will also update slowly which is ideal for calculating delta times as you’ll be taking in account of low physics frame rate when calculating delta time and thus helping out a bit in preventing false positives.
in the case of the speed check, yes that would certainly be a better choice, I definitely believe that os.clock is the better choice in the case of a cooldown period for an attack or skill usage of some form because I don’t believe it is slowed down by performance issues.
I made this one and it’s about anti-speed/teleport (and noclip). Though the code is messy, it achieves what it promises to do. An unbypassable, high accuracy detection for games that do not have anything that pushes the player (other than walkspeed).
Emphasis on unbypassable because it’s probably the reason why it’s listed. Though yes, the script uses data given by the client, if you understand how it works, you will say otherwise. Every data from the client is validated on the server at some point, they can’t be modified, which also means, it’s unbypassable. Other than this, I can’t seem to think why it was listed.
It has it’s own problems because of the client. If your game starts getting frame drops, I noticed that you had a higher chance of getting kicked, also that when there was network lag it kept spamming “Detected” in the output.
the problem still lies that you are relying purely on the client to provide this data, the client is able to manipulate any and all data it sends, it doesn’t matter if it is being validated on the server, the fact that the server is trusting that the data sent from the client is the issue.
This was a fact I specifically called out in my explanation of what exploits can access. Don’t underestimate the power exploits wield over the data on their clients.
In this case, they are not relying/trusting on the client.
Using information≠Trusting information.
Sending data through remotes is no different than having it directly replicate via physics, it doesn’t matter how the data is replicated, it matters how it’s handled.
This \ / ignores basically everything about security, you have to always use some information from the client, if you don’t then its impossible to connect to a server.
Sending the data through a remote is no different than sending it directly through physics, if we use your argument here, then all server sided anti-cheats would also by “bypassable”, because they “rely” on the Roblox physics data which is sent from the client.
If we take this argument to the extreme, then a player wouldn’t be able to even connect to a Roblox server because apparently “it doesn’t matter if it is being validated on the server”.
His anti-cheat is no different than any other “fully serversided” anti cheat, because both use the same physics data, other is replicated directly via physics, other via remotes. Both verify the data. (It doesn’t matter how the the data is replicated, what matters is how its handled.)
While this is a good post and I very much admire it.
This one doesn’t really have that much problems. And it definetly doesn’t have a core issue. Yes it did have some bypasses but those were patched, and it also sometimes false detects.
However I think you are sort of misunderstanding what trusting the client really means (or you didn’t check out his anti cheat thoroughly).
I suppose that is so but my point may have been misunderstood just a small bit, the issue I see with his is that the server is trusting the client to send a legitimate character position, and on top of that, trusting that the client’s connection is near flawless and otherwise causes too many false positives if they are lagging as was pointed out by @Judgy_Oreo in his reply
The thing about purely checking from the server-side and relying on the position of the player’s character and information only the server controls is that it leaves no room for the client to lie and no room for the client lagging to cause that many false positives.
As far as I’ve seen, looking through the code for their anti-cheat, is that it never validates the truthfulness of the position the client is providing, meaning that all the exploiter would need to do to effectively bypass it is start making the client-sided ended of it send only the last position it was at, effectively tricking the server into believing they just aren’t moving at all
I can’t say for 100%, but I am pretty positive that they can’t just erase a few lines of the code. Although, they are able to completely read/delete the whole localscript.
they can most definitely do this, all they need to do is copy the source of the localscript, modify that, and then create an exploit that deletes your localscript and replaces it with their own. As stated in my guide, you should only be using a client-side anti-cheat if it is also being supported by a server-side anti-cheat.
I do believe it is a common misconception that placing the anti-cheat code within important client-side code will protect it, security through this method or obscurity is never actual security.
local suspicious = {}
game:GetService('RunService').Heartbeat:Connect(function()
for i, player in pairs(game.Players:GetChildren()) do
local humanoid = player:WaitForChild('Character'):FindFirstChild('Humanoid')
local speed = humanoid.WalkSpeed
-- If they are going too fast:
table.insert(suspicious, player)
-- This is more like 2 step verification where the server adds them to a table and keeps checking to see if the problem persists.
-- You can loop through the suspicious table via while wait() loop outside the RunService function. You can double check through the other for i, v... loop and then kick the player.
end)
I’ve never tried this but just asking.
Is a script in StarterCharacterScripts considered client sided?
Theoretically, as long as you don’t freeze so hard that no data was sent to the server for 30 seconds, you wouldn’t get kicked. Also theoretically, network lag can’t cause a false positive on anti walkspeed/tp. It might be the anti noclip firing that.
Then again, this anticheat is for games without moving parts that pushes the player (on the new version, it takes account in collision group)
The reason why the method specified for checking the player’s speed uses math to calculate their speed based on the distance traveled since the last check is because any changes the client makes to it’s own WalkSpeed is purely on the client, the server merely sees the effects of changing this because the client owns the physics for their own character.
As for this, by all technicalities, a server script inside that location is on the server, however, as far as I am aware, the client is able to delete anything in their character model and this deletion will replicate to the server as well for some odd reason, meaning that the client can easily disable this script unless some sort of fail-safe is put in place such as this script contacting a server script in a place the client has no influence over (such as ServerScriptService)
I was just hopping around the map with a youtube video playing, without any moving parts. Also, it seems to sometimes not account for respawning, I died at one point and it printed “Detected” when I respawned.
