> The problem with an md5sum on a completely free program is that someone > could simply modify their client to send the correct md5sum. Even if the > server changes how its summed each time, you can simply keep a clean > copy of the binary elsewhere on your disk and sum that instead of the > actual running executable. The server has no way of trusting that the > client didn't lie. > > Some games have tried having a secret string or algorithm in the > "official" binary that does not exist in the free source code to achieve > what you are proposing. A client based on the free code would only be > able to connect to servers that allow it. That may work reasonably well > if you ignore how difficult it would be to hide your string/algorithm > from anyone who examines the executable. The problem is that your game > is now non-free. You would need special permission from any contributors > to let you distribute a binary without the source code that was used to > generate it. > > > Brandon >
A more important problem than free software politics is that even if you have a proprietary fork that the binary uses that sends a md5 of itself, a motivated enough person could probably just as easily use a packet sniffer to reverse engineer the process, and make a fork of the free version that works on the servers that only accept the non-free version. Now, with free-software in mind; as said by Brandon; having two versions, a proprietary one that works, and an open source one that doesn't really is missing the point of having the open source version. >From my own experiences, the only good answer to the problem of people cheating by modifying the game client is to not put anything important to game physics within the game client. I think there are some surefire benefits to this that don't have the usual hypothetical chains of cause and effect for the scenarios of when someone really is motivated enough to step up to the challenge of circumventing your security measures. First one is; when you don't give them anything to modify, they can't modify it. You can do this easily with a server-side physics engine, and use client-side for rendering information from the server and sending information from the player to the server. Second one is; you're not using the same canned engine that everyone else uses (ODE). Its not hard to design a simple physics engine to do what you need for your game, and you can use pretty basic math to do it. I think the only argument against handling physics serverside is the assumed load it would put on the server; and my honest belief is that when that actually is a problem, its 2 parts bad design, and 1 part being overly elaborate. _______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
