They can just delete the antihack local script.
1 Like
Iâm sure that can be detected too.
1 Like
And the detectors can be deleted too.
Not really. Any local script antihacks can be stopped.
3 Likes
Have you read my solution?
1 Like
I doubt it very much, I think everything should be Client-Side, making requests to the server all the time seems to me to be very inefficient and a waste of memory, you can make the Anti-Exploit to be in an important script that if deleted nothing in the game would work.
Itâs not making requests all the time.
Also server is a vital part of a game.
Doing everything client side is an EXTREMELY bad practice which most old Roblox games (before FE) did which is why they were so prone to hackers.
1 Like
A client can do anything. Pretend that an exploiter has access to a command line and all your scripts + maps you give it. This means they can do the following
- See all descendants of services they have access to (Workspace, PlayerGui, etc)
- Execute their own scripts
- See any remote event/function requests you are sending and hijack them, essentially
- See any remote event/function requests the Server fires
This can have a result of the following:
- Delete other scripts (such as anti-exploit
- Steal map models or GUI models
- Change transparency of other parts
- Change their local characterâs properties
1 Like
The server can put objects into PlayerGui
@AyeeAndrxw is right, your current design is not easy to keep secure. What sort of advantage would an exploiter have if they could see outside their range?
Letâs get back to the image of the OP:
If the exploiter has acess to the whole map, they can also see where the other players are, even if out of their range.
Since the players are stationary (they canât move), itâs then very easy for the exploiter to send a barrage of projectiles in their direction (aka sniping) knowingly that in the early game there are no proper defences.
1 Like
Couldnât an exploiter already see the location of other playersâ characters in workspace as AyeeAndrxw mentioned?
However, since they are stationary, you could do what @ITBV said and have the server reveal to the client more objects as their base increases. This wouldnât have the cache issues that were addressed earlier since once itâs revealed itâs revealed forever.
The players are stationary, the projectiles evidently are not.
The goal is to the Workspace not to replicate from the server, if possible, if not, weâre discussing the alternatives.
If the client doesnât get the other playerâs location replicated from the server in the first place then they cannot see it.
1 Like
As long as you donât expect clients to lower their FOV then that part should be fine. You can easily have the server and client communicate to create localized parts. As long as the FOV isnât changing super quickly there shouldnât be much performance issues.
I would think the projectiles would just been handled by the server and replicated to everyone, that way players know who/what killed them and the server doesnât have to work with any spoofed client information/parts.
If you put script.Parent = nil the script will still work, and it canât be deleted.
I think that the topic is being derailed to a discussion about exploiting.
It is a fact that there isnât a foolproof method to stop exploiting only using client-sided methods. Refer to @AMD_chanâs Exploiting Explained for more information.
The problem here is:
- I donât want to let the client to see the serverâs Workspace. Period. I would then handle Workspace replication my way.
- If I let the client see the serverâs workspace, I have no guarantee I can delete the unallowed parts from the client. This is a particular case where I canât really implement sanity checks.
- I still want the Workspace to dynamically calculate physics, so moving it to
ServerStorageis not an option unless I like to waste time recoding the collision solver on a platform that is less efficient.
1 Like
If youâre concerned about exploiters seeing more than they are supposed to, just kick() whenever an object thatâs isnât allowed being replicated onto the players client is found.
That means that the server would literally kick everyone: The server replicates everything in the Workspace by default, so every client would see something they shouldnât.
That is false information. I donât really want to derail away from this topic, but the code will still execute, and therefore can be edited (I believe it goes into the RAM, but donât quote me).
There is no way to stop exploiters from viewing everything - besides not giving them it
What you are doing is making it harder to find the script, but if you really try, you can find the script one way or another.
Sidenote,
script = nil
Removes all references towards the script, and is probably better for what you sound like you want to do.
1 Like
Personally, iâm not sure if exactly what youâre asking for is possible (without using some of the hacky methods stated above), as such it might be worth making a feature request instead.
Why ServerStorage ?
Sure it helps with security, but having the replication being done via remotes etc could possibly lower overall game performance. Mind you, Iâm no expert, personally I would put the game map in ReplicatedStorage and have a localscript handle the replication manually.
Does this pose a security risk ? Yes.
Can you patch them ? Yes.
Can your patch be exploited ? Yes.
On the topic of security, no matter what exploit you encounter, thereâs always a way to patch it. Likewise, no matter what patch you write, there will always be a way to exploit it. This is the reality that you have to face security-wise. Thereâs no ultimate patch for anything.
OP wants to avoid direct server replication, this isnât about security so why speak of it right ? However one could argue that efficiency and quality does come to mind on any programming topics.
Surely security matters, but before we get to that, letâs look at a couple pros and cons,
1) ServerStorage
- More secure than clientsided method handlers [ PRO ]
- Slower than clientsided method handlers [ CON ]
2) ReplicatedStorage
- Replication can be done without having to go through possible latency delays [ PRO ]
- Easily exploitable [ CON ]
This brings us back to the old debate of Security vs Gameplay, personally I would suggest handling them on the client side, because statistics. You have to consider this, with server handlers, youâre looking at a guaranteed gameplay-affected experience for all players in your game.
On the other hand, with client-handlers, youâre looking at the issue of Security and Exploiters, the possibility of ruined gameplay experience for some players.
Between this two, itâs better to pick the latter, statistic wise. In no way am I saying that security is mediocre and redundant. In fact, security is always something I think about first when Iâm programming, but while doing so. One must never sacrifice general gameplay for improved security.
With every method thereâs flaws to account for. And in your case, thatâs the only suggestion I could think of really. In no way will this be the best solution, it is simply my humble opinion. Someone else may stumble upon this and suggest a method unknown to us, and in that event we shall learn and improve ! 
13 Likes