|
| 25 Jan 2017 11:40 PM |
| what kind of exploits aren't stopped by FE on it's own and requires me to design my own countermeasures |
|
|
| Report Abuse |
|
|
|
| 25 Jan 2017 11:56 PM |
FE doesn't stop exploits, it just means that changes made from the client don't replicate to the server.
This sounds complex, but it just means that the players can't change anything for the whole server. Any changes made will only show up just for that one player, even if they kill somebody.
Since exploits are run locally, an exploiter cannot change the game for other people and thus the whole purpose to exploit is removed. There are some important things to note though.
First, exploiters can find your remote events. They can manipulate these to make changes to the server, but if you find somebody using them for bad you can easily change your code to fix it. Second, changes made to character movement replicate to the server. This means if an exploiter changes his walk speed, it will still show up for everybody else so you should look into it.
But basically, FE "filters" changes made by the client. |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 12:17 AM |
| right. I already took walkspeed exploits, teleportation and lagswitching locked down. I was just wondering what else I have to patch manually. |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:10 AM |
The same things they can do with FE off, it's just that *most* of their changes won't replicate to other clients. One notable exception, for example, is that the local player physics are handled, well, locally, and so most physics-related changes made to the local character will replicate.
Other than that, the main thing to be aware of is that exploiters can easily log the data being sent through your RemoteEvents and RemoteFunctions. If this is a problem, consider changing how your network model works so that the server is handling sensitive data, or add proper verification on the server.
A common example of how not to handle your network model is that of a shop. In a poorly set up network model, the client would detect when a user wants to buy the item, check if they have enough cash, and if so, fire the server. The server would then grant them the item. This is *TERRIBLE*.
Much better in this example would be to solely handle input on the client. Once user clicks on an item to buy, you should still check if the client has enough money to buy the item (to prevent unnecessary requests); but once the server has been fired with the requested item the server should again confirm the player has enough cash (but from the server), and if so, grant the item. This way, proper verification is being done on the server and unless you do something wrong, there is no way this shop could be exploited with the information available in the example. The moral of this is to not handle sensitive data on the client, and let the client be for input, feedback, and rendering.
|
|
|
| Report Abuse |
|
|
booing
|
  |
| Joined: 04 May 2009 |
| Total Posts: 6594 |
|
|
| 26 Jan 2017 01:20 AM |
A list of what is fairly easy to do (with a few exceptions):
1) (strike)Kill and teleport people with welds(/strike) This is no longer possible. Welds do not replicate in any spot that I know of anymore. I don't think many game devs even realized this was possible but it isn't anymore.
2) Do anything with your physics: teleport, fly, change walk speed, speed hack, etc.
3) Crash the server with around 1000 different ways
4) Manipulate remote events / functions or anything stored in client places
5) Crash other clients
6) Make any changes that apply only to yourself. As an example, an exploiter could delete the map. But nobody else would see the changes. If he or she fell through the air where a block was, other players would see he or she fall into a block.
There are some other global possible things but they are largely unknown / difficult to use. So just plan on those things being able to happen. |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:24 AM |
| no more killing through neck welds (: |
|
|
| Report Abuse |
|
|
| |
|
|
| 26 Jan 2017 01:24 AM |
| Oh @booing, is there a way to prevent people from crashing the server or others..? Probably not, but it'd be nice to know if there was a way to stop it... (In FE) |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:26 AM |
| Yes probably not. Crashing the server is as easy as sending a super long string through a remote event (assuming that still works) |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:35 AM |
| ^ Never knew you could send SUPER long string, I'd atleast assume there'd be like a 100 string limited per variable. |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:37 AM |
100 characters is hell short wtf?
|
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:39 AM |
| No, because you can send tables and what not for just one... :/ |
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:40 AM |
>wants to write a description for an in-game item that loads into a textlabel when script runs >description over 100 characters
|
|
|
| Report Abuse |
|
|
|
| 26 Jan 2017 01:41 AM |
| Why would you send the entire description? Kinda pointless, but none the less just send it as a variable. |
|
|
| Report Abuse |
|
|
| |
|