as for Fire Server bypass it seems to try to get the parameters and compare them to Cardinal event which will work of course your script can be easily bypassed
as for IsClient umm the module script is in serverstorage i put most of MS in server storage
and the remaing ones are not that damaging just some info
but why is there some event called cardinalEvent
does this stops teleporting scripts in server the code looks super invasive and you got to edit it to use it in your game
The client simply has too much power, most if not all checks on the client can and will be bypassed eventually. Try focusing more on your server end of things.
Greetings. Your approach to use a server-sided script to handle the detection of cheats is excellent.
Server-sided anti-cheats have the advantage of being unable to be tampered with, read or generally bypassed, unlike client-sided ones (which are a waste of time). You could tailor it to your game more by introducing checks for flying, floating, etc. (Potentially achieved with Region3 or Raycasting, if you wish).
What I do not understand, however, is your use of the security on the ModuleScript. Simply put, it is not necessary. ModuleScripts technically run on whatever script that required it. It would run well if it was required on a server script, as it would have the environment of a server. Clients, however, cannot access DataStoreService. If one was to require your script even through an exploit, it would do them no good. There is no need to introduce a check on whether the ModuleScript is being ran by a server script or a local one, as ModuleScripts are merely containers for code. If you wish that it was not accessible by clients, you can always place your modules in ServerScriptService.
Hope this helps.
Your quite right about the module checks not really being needed, its just an extra thing I have because if I know the client should never access it and it gets accessed it means that player is definatly exploiting.
It wont catch out any decent exploiters but it would certainly catch a few who just try using random modules and functions.
As for the anti fly ill have to add that as it is definatly a good idea, ill prob check the player rotation and also cast a ray for this.
While I think that using such a method as a honeypot is a bit underwhelming and borderline unnecessary, I get what you’re saying. As for secondary checks to do on the server, I would not recommend rotation or casting rays (generally) unless you know what you’re doing. It is expected physics behavior that the player can sometimes trip or be standing on a ledge, where raycasting and rotation detection is ineffective. (Raycasting can still, however, be used for other checks such as detecting noclip).
If you are attempting to check whether the player is standing on a surface, the option that I would personally recommend you is:
Region3 is a data type that can potentially be used to create a 3D space around the player, in which you could check if there are any valid parts that the player could be contacting (indicating that they are standing on a surface). There are helper modules for this, such as Rotated Region 3 Module
Simply put, you can create a region under the player to check whether they are standing on anything, and attempt to justify it if they are not (in case of jumping, falling, etc). And relying on graceful handling if they are not, to alleviate the consequences of false positives in case your system is not perfect.
You can also always use the physics Touched event.
Cheers.
Ill definatly read through the scripts, I like doing everything myself cos I learn from it and can get it to work for the way I want to use it.
Thanks
You can’t detect empty returns as it’s the same what FireServer does on it’s own it just never fires the remote to the server and instead redirects it back just like normal and for the module I simply bypassed the detection method you used by hooking RunSerivce.IsClient and always returning false if a module script calls it
This script does not require the modulescript but it just bypasses all the ban methods you have in place
I simply bypassed what he put down, he stores the ban remote within replicated storage and I check when FireServer is called then I redirect it without ever the remote getting to the server as for IsClient the module script seems to be located on the client as else there should be no reason to check IsClient in the first place
Thanks for explaining but UNO REVERSE CODE
I simply bypassed what you did, i stored the ban remote in ServerStorage(Client can’t use it)
Also i stored the module in ServerStorage because you seem trying to stop server calling it by blocking it
local IsClient
IsClient = hookfunction(game:GetService("RunService").IsClient, newcclosure(...)
if getcallingscript() and getcallingscript():IsA("ModuleScript") then
return false
end
return IsClient(...)
end)
Respect+++
I have Fixed @Skylersnips Bypass please try to keep all resources out of client’s Evil hand
the best place to store is ServerScriptService And ServerStorage
100% Server Only allowed
please check the reply above me it has Some Instructions to fix current problems
I don’t believe you fully understand what you are doing. An exploiter can easily decompile your ModuleScript and modify it as they like, and then use it. Which still ignores the point that such security measures protect nothing. ModuleScripts modified on the client do not replicate to the server, they also do not have access to server-only resources, such as DataStoreService.
Storing RemoteEvents or RemoteFunctions in ServerStorage of ServerScriptStorage is an utterly nonsensical act, as the client cannot access these locations neither are they replicated to it. The event in use by OP is supposedly designed to be called by the client (which cannot occur if the event is in a non-replicating location). The purpose of RemoteEvents and RemoteFunctions, as the names imply, is for remote communication. If server-server or client-client communication is needed, BindableEvents and BindableFunctions fit the role. It is also bad practice to store scripts inside of ServerStorage, as ServerScriptService is meant for that role.
All of this is purely utter nonsense. Not sure why ones are fighting over being able to “take hold of” ModuleScripts with exploits while others are trying to prevent that. This achieves nothing, exploits win at the end of the day as they are always on top in the client and there is absolutely nothing you can do. Thankfully in the case of ModuleScripts there is nothing that they can achieve by being able to require this module, as they cannot use it to save or alter data in the datastore regardless.
I rather do not use the bulk of my anti scripts to communicate to the client i will choose to make a server script which handles it anyway
–The point
umm didn’t i told you that I rather edit the entire script and keep it out of client range, remote events work in server storage, i will put modules in server storage and the scripts in serverscriptservice
of course i know the client always wins and i can only put pillows on his path so he cant achieve it easily
OP requests for a proper review and how to improve his practices, not your “put pillows in the way” bloated & waste of time method. Both Skyler and you fail to answer his request in any meaningful way. Your response was to introduce exploit-specific code to the module and to “keep all resources out of the client’s Evil hand”, ignoring the obvious truth that is the client’s inability to achieve any game-breaking or even game-altering behavior through being able to require a modulescript in use by the server. The only factually true statement you’ve made was that it should be kept in ServerScriptService, you however, failed to mention the obsolescence and impracticality of OP’s security decision.
Then there would be no use for the remote as remotes are used for client-server communication, and I didn’t stop the server from calling but instead, I made it useable for the client even though the client has no use for it
I think you fail to realize that I gave him a example of how stupid it is to trust the client with anything & I did not bypass the ban remote to start a fight it was simply to demostrate a example, you can go through extreme lengths to protect the client if really needed as there are exploit vulnerabilities u can abuse but almost all anti-exploit should be made on the server, but as we all know network ownership and remotes are the jackpot for exploiters as they can abuse them freely if they do not have any protection that is why it’s always useful to at least somewhat protect them from the more inexperienced exploiters and add as much logic checks on the server as possible
That’s a great reply, and I don’t have much against that, you should however add some context for OP. Providing a bypass for his current method does not inform him about the obsolescence of his measures, and the course that is needed for him to correct his practices.
For fly you could also check the FloorMaterial of the character’s humanoid as it replicates to the server if its FloorMaterial is set to Air for a long duration it would definitely mean their either falling or their flying and to make sure which one is correct u could just check if the humanoid state is Freefall and there isn’t much more to it but that doesn’t invalidate your method of course, it’s just another pov of how you could handle it
Oh yeah haha it seems like I totally forgot to give any feedback and possible improvements, it was last night and I was pretty tired. I will make sure to edit it thanks for telling me
It is not recommended to use FloorMaterial, from my time testing the value of it is retrieved from the client (and so it can be spoofed or take in the client’s values if parts were inserted).
