Hacker prevention

I played a game recently which really defined how important hacker prevention is. Greifer prevention is important too, but letting hackers play god is absolutely devastating to both the players and the success of the game. In another sandblocks game, on the official servers, hackers fly around dropping mobs on you for fun and eventually ban you from the world when they have had their fun. It is an utter nightmare. I would be devastated if that happened to Oort.

Please make sure that hacking will be prevented, especially on the official servers. I do not care if people want to mod their own worlds into a hack festival, but no mods and no hacks for the official worlds please.

Hacking is not prevented by accident, it has to be a fundamental approach to the design.

5 Likes

Ha. I donā€™t mind if a player owns the world and they troll for fun as long as they restore or pay for their mischief after they are done.

But hackers nope. :stuck_out_tongue:

1 Like

:persevere: Seriously?

No, Iā€™m SURE that they were going to make Oort the most hacker permissible game ever but now theyā€™ll make it hacker proof instead :unamused: /Sarcasm

Nobody PLANS to let hackers ruin their game
Next time try to have an actual suggestion, something constructive, not just whining about hackers but something that can be done about it
IF you put it in the ā€œSuggestionsā€ section
Otherwise I suggest putting it in the ā€˜General Discussionā€™ section

Iā€™m sure they can detect players who play the game that is not the way it should not be played and take action depending on the offense.

If a game is designed without consideration to hackers, odds are it will be hacked. For example, if too much control is in client, hacking is all but guaranteed. It is very temping to put a lot of things into the client because it makes the game more impressive and responsive, not having to synchronize with the server.

On top of that, there are companies that provide hacker ā€œdeterrentā€ extensions which games can incorporate. But doing so, could be a sign that the game was not designed correctly to start with.

Not intending to support hackers is the obvious thing. Actually actively preventing it is a whole different thing. The later wins and the former dies a horrible death.

All the coolest features in the world are worth the price of a steamy pile of poo if there is a hacker present.

2 Likes

tl;dr we keep these things in mind all the time, and the current state of Oort is not open to those sort of hacks without actually gaining access to dev accounts or server machines directly.


Long story:
The only things that could be hacked as it stands (with varying degrees of difficulty) that I am aware of would be:

  1. Automating input (can be done in any game, no matter what really) aka writing a bot that does mouse movements and WASD for you (not really hackingā€¦). Everything the client does is predictive, when you move around, or when you change things in your inventory or craft, or when you place and remove blocks or fire weapons it is all just prediction on the client. The server is absolutely authoritive and the only thing it receives from clients is input data (like state of WASD keys and mouse movements)
  2. Monitoring network activity / inspecting memory directly (again, canā€™t be prevented) to gather information sent by server about nearby entities which would allow writing bots that could aim at entities themselves.
  3. Monitoring network activity / inspecting memory directly to search for resources in-game for the nearby chunks you have data for, eg for the 100-200m around you (depending on terrain detail) search for ores underground to get their locations.
  4. Injecting arbitrary data into packets sent to server to attempt to put server into an invalid state where it may crash (Was an issue in the past when my friend was trying to write a bot for oort following what Iā€™ve said in 1. and getting things wrong!) Though we havnā€™t done stringent tests to ensure the server is definitely not crashable by invalid data, it is very robust to it and any data sent by a client is well checked for validity before accepting it or otherwise disconnecting the client.

The first two can only be guarded against by trying to detect player behaviour that is non-human likeā€¦ which is not exactly a trivial task to even define, never mind detect and generally leads to false-positives if made too strong.

The third one we could do more to guard against if it became a problem by doing something like wiping information about blocks that are more than say 2-3m into solid geometry so that you would not be able to inspect the entire chunk, but that would be rather difficult to get right, since depending on what tools players have, and what blocks are in a region of the geometry you would be able to dig at varying speeds into the ground, and the client needs to know what is underneath the ground to keep mining/remeshing responsive. This would also make the server-side a lot more expensive by having to maintain these partial chunk views and continuing to send data as necessary to keep clients having a large enough buffer for mining. Even more expensive for the servers would be for them to run the occlusion culling algorithms used in rendering to decide what data to send to clients in the first place (So you wouldnā€™t even get send information about caves beneath you if server determined that you could not possibly see them on your screen, same for entities). But again, that is an even more complex task than the rendering occlusion culling since it would need to try and maintain a buffer again so that if a client is moving quickly he always has enough data to render the world he should be seeing.

6 Likes

Thanks for the detailed response and the peace opf mind. :slight_smile: