Jump to content
Posted 29 June 2013 - 12:55 AM
Posted 29 June 2013 - 03:03 AM
Posted 29 June 2013 - 03:16 AM
I guess the OP is talking about someone unpacking the game's assets and script assemblies, and modifying the script bytecode to call Network.Destroy. I would think that cannot be prevented. You could rather use a 3rd party networking library such as Lidgren to do all the networking yourself, in which case you build all the network messages yourself and can do more extensive verification on the server against hacking.
Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...
Posted 29 June 2013 - 09:10 AM
Someone with access to your client code will be able to modify the game state. There's no way around this.
Think about it: Instead of calling Network.Destroy(), the function, your attacker could simply inject a network packet that looks like the packet usually sent when Network.Destroy() is called.
This is why game rules need to always be enforced on the server side if you want to have a chance of reducing the surface area available to a cheating attacker.
Posted 29 June 2013 - 10:16 PM
So I guess Unitys built in networking is completely useless for any serious project? Guess I'll have to switch to Lidgren.
Every networking scheme has exactly the same vulnerability.
If the Client isn't supposed to be able to destroy an object, you need to block that functionality at the Server.
Posted 30 June 2013 - 12:14 PM
Posted 02 July 2013 - 09:07 AM
It does appear to be a significant flaw in Unity's networking model, to be honest.
Switching to an external solution is probably the best bet.
Posted 02 July 2013 - 02:18 PM
Yeah, based on that, I'd say avoiding Unity's networking is a good idea.