Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source Quake Causes Cheating?

CmdrTaco posted more than 14 years ago | from the gotta-hate-that dept.

Quake 474

Stargazer writes "Well, looks like people are having problems with Quake's release under the GPL. It's not a conflict with the license, but rather, mean-spirited people are now creating clients which give them an unfair advantage, to say the least. John Carmack ponders this problem in his .plan file, and offers, unfortunately, a closed-source solution. "

cancel ×


Sorry! There are no comments related to the filter you selected.

... (0)

Anonymous Coward | more than 14 years ago | (#1444003)

This is a very interesting problem I haven't seen addressed before (I'm sure it has and I've just missed it up to this point)... does "closed" source actually and truly make hacking harder?
Also, is anybody still playing Quake I?

What about Quake 3? (1)

MrHat (102062) | more than 14 years ago | (#1444004)

The .plan file talks at length about cheating related to the GPL'ing of the original Quake - and then goes on to talk about a Quake 3 source release. Is this just the virtual machine code? Can cheating be accomplished with a Quake 3 release also (be it the VM code or actual source)?

Sadness (2)

ZuG (13394) | more than 14 years ago | (#1444005)

This is really sad, guys. ID is one of the few companies who have really embraced open-source gaming, and what he says is going to have an effect on all gamers in the future. If he finds that there is no way around massive cheating other than to keep the source closed, then this will have a major effect on all other gaming companies, and he will follow suit. A few can ruin this for everyone. If you know someone who plays QIII under linux and uses a cheat, plead for them to stop, and have them plead for others to stop. This is one of the first attempts at OSS gaming, and it may well be the last if cheaters don't cut the crap.

Inevitible? (1)

uninerd (79304) | more than 14 years ago | (#1444006)

Surprise surprise... We suddenly have nothing holding us back but our conscience, and a few people abuse that.

bah (0)

Anonymous Coward | more than 14 years ago | (#1444007)

It goes back to plausible deniability, and baseline ethics... i.e. I will do it if I can get away with it. People who have no love for the pure game have always tried to find ways to destroy it. Up until the GPL of Quake, at least, it was hard enough that the practice wasn't widespread. JWitt

woohooo (1)

Anonymous Coward | more than 14 years ago | (#1444008)

Anyone got a client i could use? :) mite

This is a problem with OpenSource in general (2)

cronio (13526) | more than 14 years ago | (#1444009)

I'm not against opensource, in fact, I love it. I was ecstatic when I heard Quake1 was opensourced. However, this does present the challenge for everyone who wants to play the game as it used to be. This is a problem with basically any opensourced game that really, to my knowledge, has yet to be addressed. The question is, how do you know whether that guy who noone can beat is really good at the game, or hacked a version that auto-aims, auto-fires, etc? I think it's good that someone is finally addressing the problem, at least for one game.

Just my 2 cents.

Sad (1)

NightHwk (111982) | more than 14 years ago | (#1444010)

This shows a big problem with the concept of open source games. Back in the days of doom, there was dehacked, and I remember playing my friend in a modem game with my hacked exe loaded (i was using the ol superwep7 mod) so I had 10x firespeed and unlimited ammo, it was good for a laugh, and in an hour, we were both using the hack for a new twist on gameplay. But with quake1 opensource now, its barely a challenge to hack up your client to give you extra health points, more damage, etc. One could make it very subtle and go undetected, which is really a shame. Many people still play qw, its a great game (especialy a weekend game of creeper ctf =])
Looks like Carmacks gift to the Q1 community may be what finaly kills it in the end =[

this is a big deal (2)

RodStewart (13476) | more than 14 years ago | (#1444011)

i think this exposes a large hole if OSS development. not that open source develepment is bad, its just the now that quake is open source it has flaws. although the source release of quake may good for developers trying something new or leaaning opengl development. its opened a whole world of possibilities to them. it has completely destroyed quake1 culture. team fortress players, a segment of quake players that never really moved on to q2 or q3, after a bit of wanning of interest have finally got there death blow.

-no clear leader [carmack is certainly not gonna continue develepment]
-no standardation of versions

This is just sad... (1)

Anonymous Coward | more than 14 years ago | (#1444012)

Honesty is one of the things needed to make the GPL work for the long term. If the only thing people can think to do once they have access to the source is to cheat, then they have no place whatsoever in the world of the GNU Public License.

Always Happens (3)

Accipiter (8228) | more than 14 years ago | (#1444013)

There's always those select few assholes that have to ruin a Good Thing for everyone. That's not to say this problem with the Quake Open Sourcing wasn't was. The problem is that it's affecting more people then originally conceived.

ID Software does a Good Thing, and releases the source code to Quake. Then, we have this group of people that change the code to cheat in Quake, making the general public think the Open Source community generally does things like this. Now ID has to play "damage control" and fix the problem, and the community also has to repair the damage done by the cheaters.

Instead of looking for ways to cheat in the game, how about really giving the source a good look and maybe LEARN a couple of things. God knows ID programmers know what they're doing, and that code is bound to have a gem or two in there nobody thought of.

-- Give him Head? Be a Beacon?

Re:What about Quake 3? (1)

RodStewart (13476) | more than 14 years ago | (#1444014)

just the game code. the c vm game code.

I am a bot author - and I am outraged (3)

Mongoose (8480) | more than 14 years ago | (#1444015)

I am currently making a client cide interface that will work for all 4 versions of quake. I'm using my own network code on the client and server side of the games. How do you plan to use security by obsurity to block that?

You _can't_ - face it their a *legitamate uses for client side bots. I'm very interested in keeping them alive. Proxy cheat bots are only a small percentage of client side bots - also I've never seen a client side bot that really gave an advandage to the cheater.

John I was very disaapointed when my favorite programmer brought up legal action threats to stop client side bots. John we want to learn more about AI! Your games model real world phyics, so well and have so many variants... please don't do this!

- Mongoose ( from *old planetquake quakeC bot days )

Re:Sadness (2)

Qeyser (6788) | more than 14 years ago | (#1444016)

I don't think the solution that he proposes is that unsavory. The important parts of Quake the game can still be open; the closed part would only concern client/server negotiation. Its a sacrifice, true, but I'm not such a purist that I refuse to use a version of Quake that's closed in such a way. I mean, as long as I can make my rocket launcher look like a big twinkie, I'll be happy ; )


Re:Sadness (1)

cronio (13526) | more than 14 years ago | (#1444017)

you know someone who plays QIII under linux and uses a cheat, plead for them to stop, and have them plead for others to stop

This really doesn't affect Q3, at least yet (we don't know what code is going to be released, so it may not affect it at all).

Why... (1)

punkass (70637) | more than 14 years ago | (#1444018)

...would a closed source solution...any bad?

Just a thought...

It's the only way (3)

CentrX (50629) | more than 14 years ago | (#1444019)

I was actually thinking about this some time ago and I concluded that the only way to have no one be able to cheat is with a closed-source system of checking. A good system would make it possible for the server to add 'known good clients' i.e: clients that they know don't cheat.
Contrary to what some others are saying, this would not stifle open-source gaming as the only closed-source part would be the executable that checks to make sure there's no cheating. If only this were closed-source, the rest could be made open-source. I believe that this method would actually increase the proliferation of open-source games.

Chris Hagar

just have client version report more data (3)

poopie (35416) | more than 14 years ago | (#1444020)

I really don't think this is such a big deal... It's a game, for pete's sake! When people start earning salaries for their quake performance, then maybe we need to worry about this.

It's been my experience that cheating in these games really isn't much fun (unless your really stuck and about to give up on the whole game), and I don't think that others would want to play with cheaters unless they were cheating too, which would make the game fair again, I suppose.

With the source, it's pretty trivial to undo just about any protection and spoof any values the program expects to find, so why bother?

I fear that by putting in encryption and protection schemes, we'll be hindering potential development of new variations and play modes of quake and quake derivative games. If altered clients could be used to introduce a handicap factor into games, it might encourage gameplay between experienced and less experienced players.

Why not add a HANDIcAP FACTOR to the quake game, and have that be shown for each player when joining a new game? It's probably easier to deal with cheating by making it a defined feature than trying to protect against it ever happening.

An opportunity, perhaps? (2)

Brian Knotts (855) | more than 14 years ago | (#1444021)

Perhaps this is an opportunity to come up with an open source solution to this problem. I'm not sure what that solution is, but if there is one, I feel certain that someone in the Free Software world will find it.

So this is the benefit of Open Source eh? (1)

Dj (224) | more than 14 years ago | (#1444022)

The ability to make "Unlimited technical changes" is what Richard Stallman demanded for Java... Now here in another arena we see what that means. These are just technical changes so you can't deny people the option of doing them under the RMS ethos. Cheating? No no, just creating an advantage. Pity it destroys all the intangibles of the culture like "fair play". Oh, other people could "cheat" too but now we're in a fragmentory arms war. Carmack's solution of, well, nearly certifying games as fair/allowed to play is doubly ironic when mapped on the idea of a GPLing or Open Source (Debian OSD stlyee) Java.

Offtopic: Anyone heading a pure linux fork of QW? (0)

Anonymous Coward | more than 14 years ago | (#1444023)

I'm wondering if anyone has started a project for QW development. I'd like to help in getting fixes and code attentions into a "major" fork. I already know of a dozen people with different trees.

We need a major linux fork, before QW becomes as forked as BSD!

OpenProjects #debian - we love you

Re:just have client version report more data (1)

nubis (126403) | more than 14 years ago | (#1444024)

"Why not add a HANDIcAP FACTOR to the quake game"

Simply introducing a handicap feature wouldn't stop any of the cheating. People would simply modify the code so that their handicap gave them more of an advantage than normal.

What about Cryptographic solutions (2)

NateTG (93930) | more than 14 years ago | (#1444025)

There's got to be some way to verify the Quake exe using hashes etc. Maybee not the whole program, but just a small "subprogram" that can be verified directly via the connection, then it verifies that the whole .exe is untampered (for modded games, just compare MD-5's with each other) so that you know when the other guy has tampered with things.

Now, I suppose that this is not really a whole lot better since the verification system can be bypassed, but at least it should provide for some control mechanism which can then be altered, or improved untill it works.

This is NOT an Open Source problem (1)

AmirS (15116) | more than 14 years ago | (#1444026)

This is instead a problem in game design. The only realistic way to stop this is to design the game
and network protocol so that the server only allows valid events to happen.

Obviously this some glaring drawbacks, like the server suddenly needs more horsepower, and hacked/insecure servers are no use, but that's a problem anyway. Also, it's too late to redesign all of quake so the server prevents any cheating, but this should be kept in mind when designing future open source games.

Another idea to toy with (which obviously haven't thought about) is to use encryption systems to validate every event, but not being a crypto-god, I don't know how exactly this would be done. It should allow for distributed servers however to work together, as there would be much harder for a server to cheat. Obviously this would also require lots of computing power for servers and clients though.

In short, games can be designed so cheating can't happen, but (as far as I can see) this needs more computing power. A quick fix is to make the game closed source so it can't be easily hacked.
- c.f. security through obscurity and security through openess.

glibc2.1 build (1)

fsck (120820) | more than 14 years ago | (#1444027)

Can anyone get this to build on glibc2.1? How about setting up a contrib somewhere so those of use who cant, can play. (the retail release is libc5)

Re:Cheating is a Good Thing (c) (1)

Anonymous Coward | more than 14 years ago | (#1444028)

Cheating is bad because it destroys the community. Community is based on ideas like fairness and when you cheat you violate that idea. Cheating is good for people who do not want to live in a community, who are not able to use their own abilities and ingenuity. In short a cheater is lazy and care not for the good of others.

They tried to sue you ... (1)

Augusto (12068) | more than 14 years ago | (#1444029)

... is there more info on this ? I've never heard of this "episode".

The solution is "blessed" clients (3)

winterstorm (13189) | more than 14 years ago | (#1444030)

Does anyone remember Netrek? The same problem happened with that game. The solution is to cryptographically bless binaries that don't have cheats, and allow people to configure their servers to reject all "non-blessed" clients.

Quake1 players (0)

Anonymous Coward | more than 14 years ago | (#1444031)

Good maybe everyone still playing Quake1 will finally have a reason to stop.

Open Source is not the problem (5)

Python (1141) | more than 14 years ago | (#1444032)

Open Sourcing the Quake code is not what caused the cheating. If that were the case, no security flaw in any closed source product would ever come to light. And yet they do. I'm disappointed in slashdot for perpetuating such a myth. Opening the source does not create the security hole, it just makes it easier to find it and fix it.

So, this is really yet another example, in a long an sordid history, of why building a security model that depends on the client to be honest in a client/server model is a Bad Idea[TM] (can anyone say rexd?). Closing the source would be nothing more than security through obscurity. I guess its time to open that can of worms again and kick that dead horse around. There were cheats before they opened the source, their were cheats for UnReal and I'm sure their are cheats for other games as well. Anytime you rely on the client exclusively to report valid values you shift trust into an untrusted space. The users machine is not trusted, so why does it suprise anyone that someone would cheat? Why is it suprising that its possible? Its possible whether you open or close the source. This bears repeating, trusting an untrusted system (the client) to report trusted values is not possible! Thats the problem. Not the fact that the source is open, its the fact that the client is so implicitly trusted to report valid values.

Hopefully the ID folks will realize that if they want to stop cheating. Preventing cheating in the client alone is never going to work. It will of course take some more work on their part, but its been done correctly before and I'm sure they can do it too. If they're smart they'll embrace this and work with the open source community to get it fixed.

Re:What about Cryptographic solutions (0)

Anonymous Coward | more than 14 years ago | (#1444033)

Yeah, and then we could have another program that verifys that programs integrity, and then another meta-program for security and so on and so on...

"Causes Cheating?" (1)

gnubie (2277) | more than 14 years ago | (#1444034)

Open Source Quake makes it easier for a broader range of people to cheat. It's going to be mostly script-kiddie types using cheater clients, the rest of us who enjoy the game might try it once but will quickly grow tired of an unfair advantage.

Re:They tried to sue you ... (1)

Mongoose (8480) | more than 14 years ago | (#1444035)

Not me personally, but they did threaten client side authors with legal action. Search blues news for 'proxy cheat'. It should bring the press release up. If it doesn't I can find it and post it here.

Could encryption be the answer? (2)

dsplat (73054) | more than 14 years ago | (#1444036)

I haven't looked into the details of the cheating. Hey, I haven't even read the code in question. However, there are protocols that allow for fair games of chance over a network. Basically, a set of encrypted values are passed from server to client. The client picks and returns on to the server. The server uses it. Using public key encryption each party can verify that the other hasn't cheated. Presumably, the server is trusted in this particular case, but a protocol like this even leaves the option of verifying all of the options against their encrypted counterparts to ensure that the server didn't use a rigged deck.

This requires a significant amount of the control to be in the server. And to some extent for a workable game it requires that the server be trusted. All I can do in this case is point at a good reference, Applied Cryptography by Bruce Schneier, and ask whether such a solution is a viable alternative to locking up part of the source again.

The answer is Community, not Closed-ness (5)

pete-classic (75983) | more than 14 years ago | (#1444037)

No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear."

A real solution would be to build an actual community. This word is bantered around quite a bit, so allow me to explain further.

If people were positively identified by the server, they would be accountable to others on their server for their actions. I think that the Slashdot model would work very well in this situation, in fact probably better than it does on Slashdot.

You could, of course, only allow "known" players to login. You could also allow an "unknown" player to login, but allow any "known" player to, say, kick him out and ban his IP for 20 min.

This could be implemented as simply as a username and password, and as complexly as, say, you must send your username (player name) and the date and time signed by PGP.

"Oh, yeah, I know pete-classic. Naw, he doesn't cheat. Watch out when he has the Railgun though!"


The Pricetag... (1)

Danbo (17823) | more than 14 years ago | (#1444038)

Unfortunately, this is the price we have pay for open source- you are all right, ID does a great thing for the computer community, but much like the inherent freedom of the Internet, the prize of free speech comes with the price tag of flamers and anonymity. There must be a way for the login to detect altered source; like the new Mod-Chip proof Playstation games which, I am assuming work on the basis of an architecture encoded in the CD that MUST match the system or the process terminates; any ideas, guys?...I imagine this would only affect the game servers, b/c who gives a %$#& if someone cheats on their own?

Re:What about Cryptographic solutions (1)

Keeper ofthe Keys (48750) | more than 14 years ago | (#1444039)

The problem really goes back to the integrity and honesty of the players. A dishonest player can easily bypass a hash by simply generating it before doing any mods to the client engine, and using the old hash to fool any verification system.

A trust ranking, kind of like e-bay user comments would work some of the time, but there is no absolutely secure way to verify an open-sourced game. The only way to know you're playing fair is to trust the other player.

Maybe a new client/server model is needed here. (2)

Augusto (12068) | more than 14 years ago | (#1444040)

This is probably not a good answer now (slow networks) but maybe a solution, when everybody has faster connection, is to basically have servers that don't trust clients ?

For example, if somebody make a modification that allows unlimitted ammo, a better place would be to move the keep_ammo_count :) code in the server , not the client.

Another example would be a modification that allowed invalid movement (ex: going through walls, running too fast, flying). This could be countered by the server monitoring movement and enforcing the proper laws of physics in the virtual world.

Anyways, I think there might be other alternatives that keep the whole thing Open Sourced. After all, this (hacked clients) is not a new problem nor one exclusive to online gaming.

Imagine if in your websites you relied on your JavaScript code to do all the data validation and integrity checks and you had none on the server side ! It's like letting a user validate his/her credict card and your server just going "no problem"...

Like I always tell my coworkers here when we do distributed apps, never trust the client (code that is), it can always get hacked or spoofed.

Hate to say it, but... (3)

Tsuran (77127) | more than 14 years ago | (#1444041)

Sorry to say it, but this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model.

Simply put. If I dedicate my time, my effort, my life to making anything, a game, a SETI@home client, a utility, I'm not going to want people to pervert my hard work. That's what it comes down to, really. Why should I, as a potential product designer, want to release my code if the potential exists for misuse? Suppose that they opened up the source to SETI@home. Then you'd most probably be able to figure out the protocol, and how it sends 'alert' messages. And I guarantee you, someone will start sending fake data to SETI, and it'll totally defeat the purpose of the collaboration.

Now. If your argument is that in all of the community, there will be no bad apples who will misuse the source, that's naive, I'm sorry. No group can be completely without its bad element, and I would wager that most developers don't want to open themselves up to that element, however small. There's security in a closed-source model, and companies want security. I know I wouldn't want to risk my userbase, my name, and my job security for something like this, and I would imagine that most people who do this for a living would tend to agree.

Do I think that an open-source model is necessarily always bad? No. It has its place. Is that place in the world of commercial business? I don't believe so, no. Companies make products for money. Cheaters, exploiters, and all of that will always be there, and will always be a danger to any company. By keeping their source private, the chance of this element exploiting their work falls dramatically. It's just a fact of economics.

Well-written, thoughtful replies are, as always, welcomed. Flames are not.


Re:Sadness (1)

SendBot (29932) | more than 14 years ago | (#1444042)

This is one of the first attempts at OSS gaming, and it may well be the last if cheaters don't cut the crap.

It's not the first (Civ: CTP, Doom, everything at, and there's no way it will be the last. For one thing, imagine all the people who get drawn into game development when they find out they can cheat. Cheating's fun at first, but then they strive to make something better.
And cheating isn't bound to OSS games (remember diablo?). A product can be designed to be relatively cheat-resistant, but no online game is completely cheat-proof.
At least read the article before posting. He's not talking about closing the whole source, just by adding a closed source cheatguard.

Re:The solution is "blessed" clients (1)

/dev/zero (116295) | more than 14 years ago | (#1444043)

Yes, I remember that game. It's still active, though I'm not.

I think you've hit the nail on the head.

Blessed binaries are the way to go. Could someone moderate winterstorm's post up a few notches?


Quake Development (3)

Blue Lang (13117) | more than 14 years ago | (#1444044)

is continuing - see - Also, quakeforge is working closely with the quakeworld people, as well as some people from Loki games, to bring Q1 up to speed.

They have a development roadmap, and the cheating issue is addressed. They have already managed to merge QW/Q1 into a single client, port it to SDL, etc, etc, etc.. It's rocking along, and quickly.

To those of you saying "THIS is the problem with OSS.." - shut up and code. It isn't a problem, just a little bump in the road till things settle out. There are several solutions to it, including ones not mentioned by Carmack.

I am fairly certain that this does not spell Doom (hehe) for OSS id software. Get lives, and get over it, in the face of what's already been accomplished, it's really not that big of a deal.


Netrek (2)

Signal 11 (7608) | more than 14 years ago | (#1444045)

Netrek already addressed (and solved) this problem. Release the source to the clients under GPL or anything else - this is not a problem. HOWEVER, you use an encrypted key for each client (and each version) and the binary is compiled and encrypted. You can have servers in "open" mode where you can use untrusted clients, or closed, where only trusted (ie: binary only) clients are trusted. What's nice here is that the server operator can add keys for his newly-compiled client, ad nausuem. So if a binary ever gets hacked, simply yank the key and no more access. This requires that the server op be clued, but other than that it's a 1st class solution to this kind of hacking.

Why try to deny bots? Just give 'em there own servers...

Re:glibc2.1 build (1)

Mongoose (8480) | more than 14 years ago | (#1444046)

Yeah - read this:

I got it working, and I guess *I'll start the first fork if no one else will. I can't verify that the GL clients build correctly, as my Mesa development kit is screwed at the moment. I have the source reordered like a proper OS project and a new Makefile for QW - I'll post it on my site when it's ready.

FYI, another guy on OP #debian has it running - if you're running debian you'll have a time getting your development kit correct - you need both ggi mesa and mesa development kits. I'm working on a solution.

problem? maybe not... (4)

jlehrbaum (114650) | more than 14 years ago | (#1444047)

Like john said in his .plan, there have always been ways to cheat. Transparent maps that are not detected despite server-side mapchecking, proxies that allow (albeit very poorly implemented) auto-aiming, glowskins that let people seen through shadows easily, "spikes" that are built into the player model to let people know you are coming because they go through walls, and even proxies that allow a completely hacked up map.. there are numerous other cheats and hacks that are all possible with the original quake. Many of which are undetectable. The source code release lets people to much more obvious forms of cheating such as floating in the air, or zooming through the level like a cheetah on crack. But cheating has always been around.

what is really different now? The real problem is
that a) more people have been exposed to the possibility of cheating, and b) it is far more fun to cheat.
In my 3 years of playing quake up till now, I haven't used a cheat for more than 2 minutes, and then only to test it out. I believe in keeping the game pure and skilled. But with the release of the sourcecode, coders can play with a game they love. They can add special features, optimize code, and really just mess around. Its fun. It makes cheating a game all to itself, what cool feature can YOU code in? Its not the same type of cheating that plagued competitive and non-competitive gaming in the past. This cheating isn't being used to win at all costs, but to mess around. each successive build of quake becomes 'your' build, full of your customizations and features, not just something you download to get an edge.

The important question, is where will things go from here? In all reality, the ability to cheat has not suddenly appeared, it has always been here. The knowledge required to cheat has become mainstream, and has "come out of the closet" as it were. Will this rash of cheating continue, or is it merely a phase? Will it kill competitive match-play, or will the same people that cheated in competitions still do so, and everyone else will play by the rules.. Only time will tell

Re:So this is the benefit of Open Source eh? (1)

limpdawg (77844) | more than 14 years ago | (#1444048)

How does this make freeing java bad? You really can't cheat in java, you could make your vm faster but that benefits everybody if it's gpl'd because you have to release your changes.

possible work around... (1)

smash (1351) | more than 14 years ago | (#1444049)

I dunno if you could do this with the current "client" versions of quake out there, but what the server could do (for future), is this:

When a client connects, do a checksum of the connecting binary of quake (1/2/3/whatever) and compare that with a database of "known good" binaries. I don't see that there can be *that many* different checksums to support...

If it doesn't match, don't allow the client to connect, until the version of the client they are using to connect with can be verified. It's up to the serveradmin as to what binaries he will allow.

This would still keep the source available, but any modified binaries could be excluded from online competition unless they have been verified as "legal" (ie they dont cheat).


No "only way" (1)

Anonymous Coward | more than 14 years ago | (#1444050)

You obviously haven't thought hard about this. How can the server identify "know good" clients, considering that all of the information it gets comes from the client. Whatever the "known good" clients do to prove that they are "known good", I have my cheat client do the same thing.

You haven't even described the exact mechanism of this executable, but what I think you mean is fundamentally impossible.

Fundamentally wrong approach (1)

Anonymous Coward | more than 14 years ago | (#1444051)

JohnC's suggested solution to this problem is fundamentally the wrong thing to do. What he suggests is nothing more than a software arms race against cheaters. It has nothing to do with "open" and "closed" source -- there have certainly been cheaters before, and there will be more now that the source is out there.

It doesn't matter how sophisticated the anti-cheat technology is; as long as the client software runs on an untrustworthy client's system, there is a possibility of somehow subverting it in ways that make it possible to cheat. The problem of running trusted software on untrusted systems is an active area of theoretical research, and it shouldn't surprise anyone that it's not a problem that looks like it's generally solvable.

This is just like why software copy protection was a poor idea. It didn't matter how sophisticated the copy protection software got; the crackers simply got more sophisticated, too. And meanwhile, the innocent people get caught in the crossfire and really pay for it.

So what to do? How about exactly what's been done with cheaters before? If a player appears to be cheating, make a movie and make a judgement call. If there's good reason to suspect cheating, don't let that player play on your server. Social policing and a community understanding that cheating will not be tolerated seems to me to be a far more practical solution than an arms race.

no, no, it's a GOOD thing (0)

Anonymous Coward | more than 14 years ago | (#1444052)

Strictly speaking, under the GPL, wouldn't the cheaters have to make their code changes publicly available? When we all can "cheat" equally, we are again on a level playing field.

--removes rose-colored glasses--

Of course, any attempt to make the case that this is a drawback inherent in open source software would be just plain wrong. A cheat, in terms of Quake, translates to a technical advantage with other software. While a Quaker might be looking to squeeze off more rockets per second, a software vendor might be looking for faster database access, or better device drivers. The game environment insists that players observe essentially artificial limits, for the sake of sportsmanship. The real world environment has no such limits.

Re:They tried to sue you ... (1)

Augusto (12068) | more than 14 years ago | (#1444053)

"proxy cheat" resulted in zero records found at blue's I'll look around the other gaming sites, I've never heard of that.

Re:So this is the benefit of Open Source eh? (1)

Dj (224) | more than 14 years ago | (#1444054)

You can add non-standard extensions which applications demand and which have to be added to other peoples VMs... even releasing the code to them still leaves every VM maker in the world playing catch up.

No it doesn't (4)

color of static (16129) | more than 14 years ago | (#1444055)

Closed source doesn't make any code less hackable. All it does is make a protocol not designed against a malicous client effective against those not willing to go through any effort in hacking.

The real solution for this is to make the protocol in a way so the client can only make requests to the server. Any time the client describes itself to the server, those things that can be described can not be trusted. In this case a safer protocol is to have the client request motion. The server will then provide updated info back to the client. If you want the client to track objects, then you can cryptologically sign them, so theywould be unique to the game session and non repeatable. The crypto could use very small keys to keep the performance managable, and the game exportable. 32 bits would probably be enough.

Client/Server gaming (2)

Gleef (86) | more than 14 years ago | (#1444056)

If opening the source of the client made multiplayer cheating possible, then it was possible before the source was open, just harder to implement. The obvious solution isn't really a fix for Quake, but care in the design of multiplayer games.

In any multiplayer game, you have a server and at least two clients. Anything critical and cheatable should be on the server, anything computation intensive should be on the client. For example, the client determines the keyboard/mouse/joystick/whatever state, and sends it to the server. The server resolves the action, and sends a schematic of the situation to the client (health, ammo, layout of area, etc.). The client then handles the 3d rendering, sound mixing, and so forth. No amount of cheating on the client end (short of out of game attacks on the other's computers or networks) would affect any other players. Cheating could be done on the server end, but there will always be cheat-free servers available.


I spoke to soon! go here to join this source fork! (1)

Mongoose (8480) | more than 14 years ago | (#1444057)

binary integrity (1)

Emphyrio (125143) | more than 14 years ago | (#1444058)

As far as i know, the only way to check for non-cheating binaries is allowing a fixed set of binaries that are known to be non-cheating.
This is a Bad Thing (tm) - because who's going to check and verify them ?
The binaries would have to fulfill a couple of conditions:
  1. They are known not to cheat
  2. They have a valid checksum
  3. They have been entered into the closed source checking system.
As far as i know, only point 2 is manageable, and not bad for things.
How do you know a binary is not cheating ? - somebody would have to do a _really_ thorough source analysis (i.e. diffs), and analyzing diffs is not a fun thing to do.
Then there needs to be a trusting party, that allows trustworthy people to enter the trusted checksum into the closed source checking system, wich will be a slow, annoying process that will return on each new binary release. (public key encryption/gpg and stuff might make a difference, but it's _still_ annoying to have to have your source checked (and compiled!) by a trusted party before you can use it on the game servers...)

If anyone has a better idea - i can always miss something...

I think that playing games using cheats is just not fun anymore. I also think that cheating players can be easily identified and booted out by the server administrator; unnoted cheats don't make that much difference, and are not always a Bad Thing.

Using opensource game systems will (as far as i know) always allow cheating, unless there is a _server_ solution that identifies that somebody's cheating - and we will probably not have that until everybody runs around with huge origin2000-ish computers, and the server is 1000fold that.

Just my $.02..


Re:It's the only way (1)

Anonymous Coward | more than 14 years ago | (#1444059)

Actually, it's not the only way. Another solution is to give the client exactly the same information as the player's character should have. Similarly, the server must only allow the client to control actions that the character is able to perform. We're using this approach effectively in the MUGU Project [] (GPL code for both server and clients). I assume it wouldn't be practical to convert Quake to use this approach, but I offer it so anyone concidering a new Open Source game knows that other options exist. Note of course that the solution I offer requires extra computation on the server side, but I think the benefits are worth it. Kas (sorry, I don't have a /. login handy)

Re:... (0)

m3000 (46427) | more than 14 years ago | (#1444060)

I've seen this type of problem addressed before in Slashdot, or at least a thread or two about it. I forgot what the conclusion was, but this doesn't suprise me at all. As for playing Quake I, I play it at school since the computers really suck there, and we have lots of free time.

This isn't a new problem (1)

JamesKPolk (13313) | more than 14 years ago | (#1444061)

Ever heard of netrek? might help you if you haven't, or if you've heard the name, but know nothing about it (as I did yesterday).

Here's an open source game, with binary client distribution. Cheating problems get minimized, because they use the awesome power of mathematics to authenticate the clients (the FAQ calls it RSA, so I bet it's based on some public key cryptography).

GPL Quake could do the same thing.

Don't blame open source for the problem; look to open source for the solution!

Re:possible work around... (1)

Augusto (12068) | more than 14 years ago | (#1444062)

So what's to prevent the modified client from reporting the wrong binary checksum ? The solution is to remove validation from the client completely.

Ultima? (1)

Kaht (122157) | more than 14 years ago | (#1444063)

Correct me if I'm wrong, but didn't this happen with Ultima Online 8? I believe I heard that they had open-sourced it to try and get improvements made to it, and people used the source to find all the secrets and such.... like letting players on a MUD see the code to all the monsters.

Anyway, does anyone have any suggestions other than the depressing don't-open-source-stuff-no-more one?

Re:...[solution] (1)

Zurk (37028) | more than 14 years ago | (#1444064)

nope. closed source is just security by increases the time it takes to crack it.
Here's a simple solution (works with open or closed source):
[a] Take client A, a legitimate Quake client with no cheating. Compute a RIPEMD-160 signature for the client.
[b] Take client B, a hacked client.
[c] When A & B connect to legitimate server C, C passes a predetermined, randomly varying string to both clients which they load into memory. A snapshot is then taken which both clients have to pass back in the form of the computed RIPEMD-160 signature of their entire memory space (should take 1-2 seconds max) - and passing a 160 bit signature is negligible in terms of overhead.
[d] Server C knows what string it passed both clients and also know the signature of a legitimate client + random string. In this case, A will pass while B will fail.
[e] Server C denies B and allows A.
Since the string is set on the server and is varying randomly, it is very difficult for B to calculate the string dynamically at runtime in the length of time allotted. RIPEMD is open source , no patents and is stronger than MD5.

Re:no, no, it's a GOOD thing (0)

Anonymous Coward | more than 14 years ago | (#1444065)

The modified clients only need to be distributed in source if they are distributed in binary form. The user/author doesn't need to give out the source if they only use them for themselves. The affect of the GPL on distributed systems was discussed recently on gnu.misc.discuss.


Anonymous Coward | more than 14 years ago | (#1444066)


This is impossible to stop, so please grow up (4)

Terje Mathisen (128806) | more than 14 years ago | (#1444067)

I discussed this with John Carmack back in May, the real problem is that it is absolutely impossible to make a completely cheatproof system. This is because it will always be possible for a cheater program to load the original program along side itself, and then use this to reply to things like requests for a MD5 checksum of a random area of the executable. Closed source helps only in making it harder to reverse engineer the protocols used, it is no real solution. Terje


Anonymous Coward | more than 14 years ago | (#1444068)

Naturally because we all know that closed central command based systems are more efficient and less corrupt than open democratic ones. Without the high preists of the software industry to protect the average consumer what will stop the complete destruction of personal sovereignty and individualism. MS uber alles!

Re:It's the only way (2)

iCEBaLM (34905) | more than 14 years ago | (#1444069)

I was actually thinking about this some time ago and I concluded that the only way to have no one be able to cheat is with a closed-source system of checking.

You know I'm sitting here thinking about this and I don't think this is so.

That's one way to do it, however, another way would be to have all damage allocation from weapons, and all damage recieved to armor, health, etc, be done at the SERVER side and not the client. Offload all the cheatable stuff to the server, that way hacking the client is useless because the client isn't the one doing all the damage assessment.

I know this would totally break the Quake protocol and would require enormous rewrites to both the quake client and server, but it's doable, and you can keep everything open source, the only problem now is people having cheat servers. :)

It would probably increase lag aswell, as the client would have to check with the server to see if it was allowed to do anything (ie: walking [server wouldn't let client walk through walls], firing weapon [server would have to make sure client had enough ammo], etc.) but with broadband hitting almost everywhere now, maybe it won't be such a problem in the future.

-- iCEBaLM

Authentication (2)

robertchin (66419) | more than 14 years ago | (#1444070)

They should build a small scripting language into the code, and upon connecting to a server, a specialized authentication program could be downloaded off of the server. Ideally this would be a different authentication program, or a set of programs that are rotated. This program then would generate some sort of PGP-type signature of vital files, and return it to the server. The server would then look at the signature and see if it matches the signatures in its database, thus determining whether the client was a valid one or not. The scripting language would be limited on commands, to prevent any sort of abuse. Since the script sent by the server could be pseudo-randomly rotated, the client would never know exactly which response to send, if it were a hacked client with cheats.

This is not an Open source problem (5)

color of static (16129) | more than 14 years ago | (#1444071)

I have spent much of the last year developing systems/protocols for hostile client to trusted server connections. There are ways to do this, but it requires that the base protocol be designed with it in mind. I don't know the quake protocol, but I will try to describe a possible method.

The client connects to the server with a request for a unique ID. What comes back is a two part ID, one public, one private. The client then makes universe change requests (movement of client in the universe, firing, etc...) with the pub ID, request, and a hash of the above with the priv ID. The server then can verify it's the same person that requested the ID (PKI can be used to send the intial ID back if snooping is a problem). The server sends back universe updates along with the verification. If you want these can be signed with the priv ID.
If you want to do object tracking then the objects could have seperate signatures so they are unique and verifiable. Ammo could also be tracked with a sub object or something like that.

Basically any rule that you don't want broken need to handled on the server in this model.

Encryption could be cut down to a low level to prevent computaional slowness and export problems. Even a mild algorithm would be acceptable so long as the key secure until the end of the game against a single PC.

If you want to do peer to peer, or move more handling back to the client, then one would have to look into one of the many blind poker algorithms, but it to should be doable.

Re:this is a big deal (1)

Microlith (54737) | more than 14 years ago | (#1444072)

What a wonderful .sig

You do realize that's the only song they never officially published the lyrics to, and that's why?

Re:This is impossible to stop, so please grow up (1)

IMarshal (86565) | more than 14 years ago | (#1444073)

No, it's not impossible if you define your client-server protocol in such a way that the server ends up making all the decisions. In this way all input from the various "hacked" clients can be validated and the trust problem is greatly reduced.

Of course, for a game like Quake this isn't necessarily feasible because of performance and latency concerns. But for other types of games, like (for example) an Open Source Age of Empires, it could be easily done.

Re:...[solution] (1)

sunking (19846) | more than 14 years ago | (#1444074)

[c2] Client B has a slave legitimate Client (B2) for which it is the "server". It passes the random string to Client B2 and obtains a good RIPEMD-160.

Don't take my reply as meaning that I think your scheme was even reasonable in the first place - how could the server possible know what the ENTIRE memory space of the client should look like? That would include configuration options, models, player name, etc.


Damn cheaters (1)

jcs (90508) | more than 14 years ago | (#1444075)

All this time I thought I just really sucked at Quake and I find out they were cheating.

Joshua C. Stein
Superblock Information Systems

Re:Hate to say it, but... (2)

Guy Harris (3803) | more than 14 years ago | (#1444076)

Yes, there is a risk that, by making certain programs open-source, somebody could make use of the information made so available to, for example, commit fraud.

However, it's not clear that this possibility exists with all software that is sold commercially - yes, you could perhaps modify a digitized photograph to show Bill Clinton or Newt Gingrich having sex with Scary Spice by using the GIMP, but you could, as far as I know, do the same with the closed-source Photoshop.

If there were some mechanism to prevent tampering with digitized photographs, or to make such tampering detectable (e.g., some sort of digital signature), then there might be more of a risk with an open-source image editor that implements such a mechanism - but I don't know one way or the other whether no such mechanism can be implemented without keeping it secret. (And, no, that doesn't ipso facto mean that any company doing an image editor would be too afraid to do so - "I don't know one way or the other..." doesn't mean "nobody knows, it'll forever be a fear", it means "I don't know".)

Furthermore, it won't necessarily be the case that the cost of the sort of fraud, etc. that could be committed with an open-source program (or any other source of openness, e.g. published protocols, published file formats, published algorithms; this isn't just a question of open source vs. closed source) will be deemed greater than the benefits of openness. Yes, there have been cases where that sort of fear has dominated - see, for example, the policy of some governments, including but not limited to the US government, towards freely-available encryption technology - but that doesn't prove conclusively that this sort of fear will, of necessity, be dominant.

I.e., I've seen no evidence to suggest that the fear of misuse of a program must be so strong as to prevent any software developer from ever making their source available, so, whilst a more limited version of your conclusion might be valid, I see nothing to suggest that your quite sweeping conclusion ("this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model") is, of necessity, valid.

Interesting possibilities. Mostly questions. (1)

Greg Merchan (64308) | more than 14 years ago | (#1444077)

I haven't play networked games in a while and never more than a few people in the same real world room, so please flame me (on email, find it) if anything I suggest is too ignorant or stupid.

Could a peer-to-peer, instead of server-client, system be useful to stop cheating? I have no idea, but since the .plan mentioned trusted servers et al. I immediately thought of trusted peers.

Maybe a new gaming paradigm should be introduced. 'To the best coder go the spoils,' anyone? 5 words: Dual Alpha Beowulf Bot Army.

Is anyone working on a VR client that could turn the gaming environment into a sort of 'holodeck'? With the appropriate hardware and code, we could make our Quake-selves look like us (or otherwise) and mimic our realworld movements. Add to this the peer-to-peer setup and then I'll show you a real home page! (No tactile-feedback fighting, please.)

Didn't everyone else think they would have caught on the manipulating 'The Matrix' while in it?

Why Closed Source Is Uncrackable! (3)

chromatic (9471) | more than 14 years ago | (#1444078)

That's right. We all know that closed source projects like Diablo, Ultima Online, and IIS 4.0 are secure and uncrackable. Thank goodness for software like Windows 98 and Windows 95 which are immune to BackOrifice due to the superior protection of Security through Obscurity.

Can you *imagine* if someone like Alan Cox or Theo De Raadt had access to the source code? I mean, he might spend upwards of two hours fixing the security holes. That is plainly unacceptable.

It is a very good thing that reverse engineering and hex editing and asm disassembly are impossible and illegal, not to mention packet sniffing! Otherwise, our panacea of Ivory Tower software development might show some cracks.

Now if we can just rid the world of Computer Science classes and books, we can all hold hands and dance around. Huzzah!


Re:Always Happens (1)

itsme (6372) | more than 14 years ago | (#1444079)

I think it is an example of the Good opensourcing can do for a product, the security flaws in the quake protocol were already there before the code was released.
This is very similar to someone releasing an exploit to sendmail, and the sendmail people then having to fix it.
The nice thing about being torn to shreds in the cyberjungle, is that you can fix things and try again.


Possible solution perhaps (2)

gothic (64149) | more than 14 years ago | (#1444080)

As a non-quake player, I can't say for sure what exactly a client reports to a server.
Exactly how hard would would it be for the server to be a little more intelligent? If a cheating person is shooting someone with a machine gun doing 50 points of damage per shot, I *think* it wouldn't be hard for the server to notice that the gun is doing too much damage. Maybe have the server know what damage each gun does, how much health a person should have, and how quickly a certain gun fires/recharges. In my thinking, I wouldn't assume that would be hard to do, but I'm always ready for corrections.
If this was actually possible, perhaps a flag could be added to the server. Something like AllowPlayerCheat=On/Off ...If the server doesn't want cheaters, and it detects one, it can boot them off with a message of "Player 1 was cheating, and has been removed from the game"

To me, that's a pretty simple solution, but I also assume it would seriously bump up the required bandwidth, and also bump lag up. Again, I'm not sure what info is already passed to the server, but I'm assuming it will pass something about hit/miss fires from a gun, or how much health a user has left to drain.

In a scenerio like this, I assume you would just now have to rely on servers set to not allow cheat, or if they do, let people know. Anyone think of a way around that? I'm up for opinions, as this is pretty interesting.

On a side note, I don't think this actually damagages OSS, but proves at how quickly people can find paths that could damage your hard-worked program, amongst other pos. bugs...

Re:It's the only way (1)

Fizgig (16368) | more than 14 years ago | (#1444081)

But there are more ways to cheat than that. What if I adjusted the Quake client to have all bad guys appear as bright red, no matter what the lighting. You certainly can't handle that server-side, and it's definitely cheating.

No solution (2)

Hard_Code (49548) | more than 14 years ago | (#1444082)

There really is no way at all to prevent hacked clients as long as the server trusts the clients. The only way for the server not to trust the clients would be to offload everything to the server except inputs, which makes the client effectively just a remote viewer. Of course this is obviously impossible because it would render the game absolutely unplayable. Everything is "cheatable" basically, except the inputs. Making a closed source proxy won't work either, since the proxy can just be hacked. It is a stop-gap measure, but I think it won't really work. If the closed source proxy relies simply on a digest, it is trivial for any cracker, not to mention most pedestrian programmers, to hack the proxy to return one of a list of known valid digests, or simply use mechanisms of the os to fool the proxy (point it to a valid copy, but make it run the hacked one). There really isn't any way to stop it at all, except to just rely on the honesty of the Quake gaming community, and give a big fat walloping kick and ban to assholes found cheating. - the Java Mozilla []

Unfortunately, no (2)

/ (33804) | more than 14 years ago | (#1444083)

Unless the cheater is distributing his modified client to others, the GPL does not require him to release the source code to anyone. The distribute-the-source requirement isn't tied to the act of source modification -- it's tied to the act of distribution.

Re:Always Happens (2)

matroid (120029) | more than 14 years ago | (#1444084)

To play devil's advocate for a bit: it's the assholes like this that drive software development to new levels. The same thing is paralleled in many different areas:

In cryptography: The people who propose new protocols depend on the people who break protocols to make their proposals robust. (Without those crackers we could still be using XOR to encrypt files).

In Science: Science, at the most fundamental level, is about destroying the work of others. One takes a theory and try to find places where it doesn't hold thereby disproving it. Without this process, we would probably still insist the world is on the back of a tortoise.

In nature: Nothing accelerates evolution like preditors.

Cheaters are nothing more than a virus in the open source community. We have no mechanisms of immunity against them. Now is a chance to prove our evolutionary fitness to the rest of the world. Either we adapt and survive these cheaters, or we die out until a better organism for developing software comes along.

The beauty of open source lies in its evolution. Let's evolve.

Re:Hate to say it, but... (1)

Fnkmaster (89084) | more than 14 years ago | (#1444085)

Your argument is somewhat flawed. With respect to SETI@Home, I can conceive of a number of ways in which to prevent spoofed alert messages and punish those who would abuse the system (alert messages are verified, and if the verification rejects the alert, the IP address is banned from the SETI@home server). If somebody really wants to attack and abuse a system such as SETI@home, they probably could anyway, as I'm sure the client-server interactions can be reverse engineered enough to hack it in some way. The system should really involve client accounts, and authentication and an abuse punishment protocol.

The point is that a robust protocol is always preferable to a security or integrity through obscurity system. As far as games go, there is a case to be made for some type of closed source verification module. That is most definitely *NOT* a case against Open Source in general, nor against Open Source in the corporate world. There is a lot of room for Open Source software in the corporate world. Game software companies are a small segment of the software world and have particular concerns and a particularly dynamic market sector. Most of us hope for more Open Source gaming software, but don't legitimately think all game software should be free (besides which, a large part of any game is story line, graphics, sound, etc. stuff that isn't even part of the core software).

Re:Open Source is not the problem (2)

ARRAY(0x0) (83136) | more than 14 years ago | (#1444086)

Exactly. By closing the source, you simply make it harder to expose weaknesses to either the potential cheater and potential developer/auditor. Who do you think will make the extra effort? Remember the supposed "Russian super computer" on

Re:No it doesn't (1)

sjh (29820) | more than 14 years ago | (#1444087)

You don't unserstand the problem. They don't want
clients "helping" players, like aiming for them.
No protocol change can prevent that. nettrek has
the same problem, and the same solution.

Re:... (1)

ChazeFroy (51595) | more than 14 years ago | (#1444088)

It makes cheating a lot more difficult, but cheating in Quake I didn't (and doesn't) require changing the actual executable or engine: Having it open-sourced or closed-source makes no difference to most cheaters.

Back a couple of years ago, when Quake I was in its hay-day, there were tons of model and map hacks. I even designed some of these myself. Of course, these only worked in NetQuake because of the pak-file checking in QuakeWorld.

For player models, all one had to do was load whatever MDL file they wanted to alter into a 3D rendering program. The cheat that got the most press on IRC was the infamous "pak2" cheat (named so because Quake I only came with a pak0.pak and a pak1.pak, so this cheat was commonly put in a pak2.pak). This cheat had a modified player.mdl model in which bars would stick out of players in the x-, y-, and z-axis and colored by the player's pants (the color of pants used to determine the team). These bars would stick out approximately 4 times the height of the model, and these bars went through walls, floors, and ceilings. Anybody with half a brain and the reflexes of my dog could now keep up with players from Unforgiven or Clan Kapitol. Other "pak2" cheats came along, also: Modified Quad and Pent models making it easier to determine if they had spawned, player models that did not have the "bars" when they were standing still (to get around the screen-shot approach of checking to see if you had the original pak2 cheat).

Another aspect of cheating without changing the code of the engine/executable would be to change the maps. Quake I has a nice feature of being able to "vis" be able to see through it. Load up DM3: If you can't see the lightning gun at the bottom of the water, you don't have the water vis'd. The trick is to change the walls and floors to water, then vis them. "waterhack.exe" (I forget the actual name, it's been awhile :) under DOS would vis all entities of a map designated to be water. Now you can see through anything. With my modified DM3, I could see the red armor from quad and I could see the Pent from yellow armor (that's quite a distance and through many walls).

There are still a few clans that play Quake I. Check the enterthegame IRC network (, in #ck . A lot of people hang out there, and I'm sure a few still play or they can direct you to a clan that plays.

- k3nny, Clan Kapitol

Re:It's the only way (1)

ArsonSmith (13997) | more than 14 years ago | (#1444089)

How about if instead of all damage/movement/ammo/armor etc handled by the server what if the server just had a way of checking as the game was being played. then labeling someone as a cheater. this could acually be kind of fun if the server then had a way of lowering someones stats without their client knowing it and marking them with bright pink paint and a sign that says cheater on top or something.

Just my input on this

spelling is optional


Re:The solution is "blessed" clients (1)

osu-neko (2604) | more than 14 years ago | (#1444090)

...allow people to configure their servers to reject all "non-blessed" clients.

I'm confused. What prevents me from writing a non-blessed client that returns whatever response the server expects from a blessed client?


synchronization solution? (2)

onethirtyseven (129687) | more than 14 years ago | (#1444091)

One potential solution is to have all keyboard/joystick/etc. input be sent to all the other clients before any of it is handled. (This is like the client/server solution mentioned earlier, but treats everyone as servers.) As long as all the user input is applied synchronously at each client, and each client has the same set of deterministic rules, the game will proceed consistently. If anyone cheats (in any way that causes a change in the actions/properties of the objects in the game) then the game will lose consistency. To check this, simply have each client checksum their data every once in a while. If someone has a bad checksum, throw them out of the game (by a vote of the clients). If someone fakes a checksum, then they can continue playing, but they won't be seeing the same game everyone else is. One advantage of this method is that it does allow modification of the game source, as long as everyone uses the same set of modifications.

There is one game that attempts to use this mechanism (here [] ), but it is incomplete (mostly graphics issues currently). I'm not sure that this approach is viable in practice, but I think it works in well in theory.

no no no (1)

Siva (6132) | more than 14 years ago | (#1444092)

Strictly speaking, under the GPL, wouldn't the cheaters have to make their code changes publicly available?

what makes you think that someone who hacks up their client to give them an advantage is going to want other people to have that same advantage? exactly how do you think this is going to be enforced?

When we all can "cheat" equally, we are again on a level playing field.

what about those of us who WANT to play the game in its original form? i dont want to have to modify gameplay just to compete fairly with some fscker who doesnt want to play fair.


Keyboard not found.

Re:Hate to say it, but... (1)

Augusto (12068) | more than 14 years ago | (#1444093)

You are making an assumption that the SETI@home protocol is very difficult to hack under a closed source model. However, if a decent programmer was intent on screwing up the SETI data, I'm sure she or him could do it very easily right now.

Again, data should be validated on the server. Why would you trust arbitrary packets coming anywhere from the internet and not check for their validity on the server ? We don't do this with the HTTP protocol, and we shouldn't do this with any protocol out there.

In the case of SETI a good dose of server side validation and encrypted password protection and authentication would be a much better solution than , "you can't break me because you don't know how I work".

another pointless post (0)

Anonymous Coward | more than 14 years ago | (#1444094)

hehe...if it can be exploited, u can be sure it will be.

Re:This is impossible to stop, so please grow up (1)

AtrN (87501) | more than 14 years ago | (#1444095)

And how is the validation supposed to tell the difference between hacked clients and very good players? It's Turing's "Imitation Game" problem. There will be some things that are obviously wrong and can easily be detected but a skillful cheater will be able to game some advantage and remain undetected.

What's the problem (1)

seaportcasino (121045) | more than 14 years ago | (#1444096)

It's not cheating if everybody can do it? It's just another way of showing that brains, not brawn wins the battle. Somehow us old (20+) software engineers have to even the score against those 13 year olds with unbelievable reflexes and non-carpul wrists. Some of us didn't go to college for nothing you know.

Re:The answer is Community, not Closed-ness (1)

garcia (6573) | more than 14 years ago | (#1444097)

No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear."

I have been playing Quake1CTF for a little over three years now (steadily). My clan has been around for that long as well, and even though we are no superstar clan, we enjoy playing for fun. There have been proxy cheats around (that include teamplay support and even turn to your enemy when firing) for a long time now. Some servers can detect this and kick the user, but still some have advanced proxies that still let them in (and the cheating is obvious). There has been word of this "pak2 cheat" where I assume that the user has a modified pak2 where it seems to allow them more damage and unlimited ammo. I haven't seen this "pak2 cheat" but on some public servers it really does seem that they have like 200A/250H/resistance rune/regeneration rune all the time. They are nearly impossible to kill in a fight even w/8x rockets and lightning. I'm sorry, but you can only take a direct 8x rocket once...

My long, drawn-out shit here is just to say that no matter if the source was released or not, there will always (and was always) cheaters in Quake. Using either proxies or this myserterious "pak2 cheat". They only seem to be on public servers ( but I have to be weary of some CTF clans and their remarkable aim... I never accuse, but when two rockets are already heading in your exact direction before you even think of grappling there, I have to think that something fishy is going on...

Just my worthless .02

Re:Sadness (0)

Anonymous Coward | more than 14 years ago | (#1444098)

cheater cheater! cheaters are a funny folk arent they? Messing up all John's big plans hehe....

Just move more code to the server (0)

Anonymous Coward | more than 14 years ago | (#1444099)

The solution to this is ludicrously simple: move inventory and damage control to the server. When a client goes over an item, make it so that it can't automatically add that to inventory, but instead the server becomes aware, and informs the client it has more inventory at its disposal. It keeps track of rounds fired, etc. Instead of having the client monitor damage, similarly, the server would inform the client when it was hit. To cut down on bandwith traffic, the server and client could both keep track, and when the client requested items it didn't have, fired a weapon where it had no more rounds, or tried to keep going after it died, the server would not allow it. The client could show others being shot at all it wanted with whatever weapon the person wanted; it just wouldn't have any effect in the arena, because the server would know that it didn't make sense, and not show the cheat. This wouldn't be too difficult to implement, I would think, though it would increase the server's hardware requirements. However, it does have the advantage of being an effective open-source solution.

Excessive Trust In Game Design (5)

Effugas (2378) | more than 14 years ago | (#1444100)

No, no, no.

Most, *not all*, but most client side hacks work because the server is trusting the client to provide data that provides state data regarding a separate client not under the same security/permissions context.

For example--I shoot a rocket launcher at you, and the server lets me decide whether or not the rocket hits. It doesn't matter whether the system is open or closed source--this is a flaw. Give a dedicated opponent a day with TCPDump and rockets will be teleporting all over the place.

Any server, whether it is a game server, an IP Telephony Gateway, or a simple web proxy, must be designed to exclude all contexts but those that originate from the client from what content will be accepted from that client.

This is not an impossible endeavor. Starcraft, for instance, has binary modification software that changes unit commands. Even in a peer to peer two player game, the modifications work perfectly until they ask a unit to execute a command that unit cannot do. Then, the other client detects the cheat and the game is immediately cancelled.

The immediate response, of course, is that this peer to peer arrangement prevents information hiding. If your client is always verifying that other clients aren't cheating, then you can always watch the incoming datastream to know what's going on. Therein lies the reason why peer to peer isn't a particularly good topology for competitive gaming--there's no server to restrict the visible dataflow to that which the given client should see.

Interestingly enough, the most inevitable (and least fixable) hack involves changing not the game but the video card drivers. Metabyte, the dementedly gifted hackers that gave gamers the first multi-API stereovision solution(and the single-pixel-resolution-adjustment power for Voodoo 2's), had a single revision of their drivers out for one day that artificially forced transparency on all surfaces. They called it X-Ray--needless to say, it made shooting around corners quite a bit easier. It also got shouted of existence rather quickly ;-)

Reminiscent of Crypto, ain't it? Where's your trustable end point?

Yours Truly,

Dan Kaminsky
DoxPara Research

These guys need to do their homework! (1)

mangu (126918) | more than 14 years ago | (#1444101)

What is needed here seems to be the right authentication protocols. Security is not just encoded communications, without the right protocol, the best cryptographic algorithm is useless.

Recommended bibliography:
1) Bruce Schneier "Applied Cryptography"
2) Menezes, van Oorschot, Vanstone "Handbook of Applied Cryptography"
3) Michael Rosing "Implementing Elliptic Curve Cryptography"
just for fun:
a) Neal Stephenson's "Cryptonomicon"
b) Electronic Frontier Foundation "Cracking DES"

Of course, this is a made-in-USA game, and due to the NSA mandated secrecy around anything related to cryptography in the USA, that country seems to be lagging behind in this respect. Perhaps they should try to hire some consultants in Israel or Russia to teach them the tricks that were originally developed in the USA...

Re:Client/Server gaming (1)

Morlenden (108782) | more than 14 years ago | (#1444102)

This makes the server more expensive.

Another way to avoid cheating is to have both clients compute the "important" state and compare results between the two machines. The comparisons can be done on the clients.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>