Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

carb

How to avoid cheating in open source games?

This topic is 5562 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, here''s an interesting discussion for you guys. I''m currently working on a project which aims to clone Subspace, an online 2D space combat game which pits dozens of players against each other online, which was released way back in 1997 by the now defunt Virgin Interactive. It still boasts a moderately vibrant community. (http://www.subspacedownloads.com) It''s my goal to create an open source clone that can be further modified by the community. There''s a plethora of benefits to this. For one, Subspace is currently Win32 only - Torrent (temporary project name, subject to change) is currently platform independent (written in SDL), and could be ported to just about any platform with a little effort. Subspace''s current net code is pretty weak and deprecated - robust testing and debugging could improve this, make for servers which support more players, etc. Allright, I''m breaking away from the main point of this post. If I post client and server code online, I''m basically "giving the keys" to potential cheaters. I mean, all it takes is to go in there, change some values, recompile, and voila. Now obviously, there''s a limit to what they can do depending on how I structure the code and client/server relationship. If all the processing is done on the server side (not good), this won''t be a problem. But for a game that hopes to host around 100 players per server, that''s not much of an option - or is it? Surely there are other OS games that have considered this. I''d like to hear thoughts and opinions, if you would. Sincerely, - Ben

Share this post


Link to post
Share on other sites
Advertisement
CRC or MD5''s or something
what you could do is if the exe is modified, dont let them play, and add some packet monitoring for un-realistic values for speed and other stuff that would give away a cheater

have a release management system so if someone wants to change
something or add something to the game, they have to pitch the idea
and everyone has to apporve to code it into the next release and
update the server code as needed.

hope that helps
-- silvermace

Share this post


Link to post
Share on other sites
actually, checking checksums for EXEs doesn''t work ... cause the compromised EXE can simply LIE about it''s checksums ... since they have the source, they can find the functions which do the work and stub them in with others ...

so, you must abandon any system which is based upon establishing trust with another computer, since any computer can fake this trust gathering stage in many ways ...

instead, you must establish TESTS for validity for each and every packets content''s validity. this is often easier and simpler than you think ...

for example, instead of allowing the client computer to compute and tell you what they hit, how much damage, and when they die or don''t ... you have them tell you where they we''re, and when ... and what they did and when ... then - since the server is also running the game / simulation code, it simpy tests this information for plausability (is the client computer within the margin of error from the server? If so, accept their orders, follow the simulation on the server, and then resync the client to the server (tell the client that they did or didn''t really hit the enemy, or how much damage they did, or if they died ...

then all a cheater can do is lie to themselves ... and of course run things like aim bots (but that''s a different problem) ... as the server will verify that all aspects of the official game (the one which all clients are constantly being resynced to) follow the rules in IT.

now none of this stops someone running a cheating (hacked or changed) server, but that''s often a good thing, as diff servers with diff rules can be fun. And if they wanted to, the clients could also check the servers data for reasonable behavior, and if the numbers get too far out, report to the client a cheating server (perhaps a server never makes certain people die) ...

the key is always in, who or what can you (do you have to) trust. If you can get away with trusting NOTHING on any other computer, then they can only cheat if they modify YOUR PROGRAM ... not theirs ... and that''s usually good enough protection.

Share this post


Link to post
Share on other sites
Use another program as a loader, which is not open-source. this program will load the game app, but first it will check that it''s not cracked.


.: My Site :.
[640k Should Be Enough for Anybody - Bill Gates]
[Death to the gaming industry! Long live games - The Scratchware Manifesto]


/*ilici*/

Share this post


Link to post
Share on other sites
making it open or closed source will not change the ability for hackers to cheat in your game whatsoever. You release it as closed source, they decompile and still hack the code. Granted it takes a little while longer, but an insignificant amount of extra time for anyone skilled in reading hex and assembly.

Therefore, read up on techniques for safe guarding any game (open or closed source). The principles are entirely transferrable, as they are intended to solve exactly the same problem.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Netrek used a system where you had to have a "blessed" client to play on most servers. That is, the client had an encrypted key that had to be sent to the server. If you didn''t have this key, you couldn''t play.

Of course, there were also "chaos" servers where anything goes and you''d see all types of hacked clients, "borg" clients that automatically hit you, etc etc.

http://www.netrek.org/

Ahh.... the good ol'' days.

Share this post


Link to post
Share on other sites
Just a thought:
What about a democratic system where the majority of clients decide if one client cheats?

[edited by - Julius on September 26, 2003 7:39:04 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Being open source has no bearing on cheating. Closed source will just slow people down a little as they have to reverse engineer things.

If the client and server are both untrusted, you can''t prevent cheating, and you shouldn''t really want to.

If the server is trusted and the client is untrusted, then you can secure things that happen on the server. In the case of a game like subspace, you would send the equivalent of the movement commands to the server, and do all the simulation server side. Dead reckon it on the client side so it is smooth, but data incoming from the server should pre-empt client data if there is a mismatch.

Since it''s an open source project, what you really need is a "reliability" system so that players can vouch for a server as trustworthy. Something as simple as a web page that lets players add servers and rate them like eBay ratings or something would probably be enough, or you could go with something more elegant like the trust metric proposed by advogato.org.

Good Luck, subspace is a cool game, I''d love to play an updated version.

Share this post


Link to post
Share on other sites
If you''re going to write a client to use the Subspace protocol you should really contact the people who are working on Continuum. I know that they have modified the protocol enough that you have to have Continuum in order to connect to a server and play. IIRC, the original protocol used some simple XOR based encryption but I would imagine that Continuum would have changed this.


Colin Jeanne | Invader''s Realm

Share this post


Link to post
Share on other sites
Hey, thanks all for comments ...

I''m aware of Continuum. It''s just that it''s seemingly closed-source, with only a few peeps who have access to it ... and they''re terribly hard to get a hold of.

- Ben

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!