Slashdot Log In
Open Source Quake Causes Cheating?
Posted by
CmdrTaco
on Sun Dec 26, 1999 01:04 PM
from the gotta-hate-that dept.
from the gotta-hate-that dept.
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. "
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Sadness (Score:2)
This is a problem with OpenSource in general (Score:2)
Just my 2 cents.
this is a big deal (Score:2)
disadvantages:
-no clear leader [carmack is certainly not gonna continue develepment]
-no standardation of versions
-cheating
Always Happens (Score:3)
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?
I am a bot author - and I am outraged (Score:3)
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 (Score:2)
-V
It's the only way (Score:3)
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 (Score:3)
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? (Score:2)
What about Cryptographic solutions (Score:2)
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.
The solution is "blessed" clients (Score:3)
Open Source is not the problem (Score:5)
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.
--
Python
Could encryption be the answer? (Score:2)
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 (Score:5)
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!"
-Pete
Maybe a new client/server model is needed here. (Score:2)
For example, if somebody make a modification that allows unlimitted ammo, a better place would be to move the keep_ammo_count
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... (Score:3)
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.
--Tsu
Quake Development (Score:3)
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.
--
Blue
Netrek (Score:2)
Why try to deny bots? Just give 'em there own servers...
problem? maybe not... (Score:4)
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
No it doesn't (Score:4)
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 (Score:2)
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.
----
This is impossible to stop, so please grow up (Score:4)
Re:It's the only way (Score:2)
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 (Score:2)
This is not an Open source problem (Score:5)
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:Hate to say it, but... (Score:2)
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.
Why Closed Source Is Uncrackable! (Score:3)
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!
--
Possible solution perhaps (Score:2)
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
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...
No solution (Score:2)
Jazilla.org - the Java Mozilla [sourceforge.net]
Unfortunately, no (Score:2)
Re:Always Happens (Score:2)
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:Open Source is not the problem (Score:2)
synchronization solution? (Score:2)
There is one game that attempts to use this mechanism (here [cmu.edu]), 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.
Excessive Trust In Game Design (Score:5)
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
http://www.doxpara.com
Abstraction Layers (Score:2)
If you wanted to get fancy, you could create a mechanism so that when a client logs in, it recieves a set of variables as the "ruleset" for what everything does. (IE how much damage a specific type of ammo does, how fast bullets move etc.) In that ruleset, if something isn't defined, it just uses the default, taking up less bandwidth.
In my scheme class, we actually just wrote a basic AI game player to play a game that's kind of a cross between 21, and cross-four. It was implemented very similar to above, but on a much simpler scale. I think it would work for something like quake, but I'm still not sure what the overhead on the server would be to check everything that the player is trying to do. It also wouldn't eliminate the problems of nightvision type stuff. Maybe we could implement a system were in the shadows, the server reports a 50% chance of "seeing" a client being there, and it's the job of the client to render that in whatever way it can do best. So if someone always draws a player being there with a 50% chance of him not being there, and that player fires, he tells other people were he is, and they know where to shoot.
Re:The solution is "blessed" clients (Score:2)
But doesn't that defeat the whole point of releasing the Quake source? I mean, how many people are going to make really cool Quake modifications if they have to jump through hoops to get their code signed so that it can actually be used?
I don't know if cheating is really such a big problem... Does anyone really know? It seems to me that there's no point to playing the game if you're going to cheat. It is, after all, just a game. "You're only cheating yourself". I doubt there's much prestige in the title "World's Best Quake Player When Cheating". And if you get used to cheats, you'll just suck all the more when you play at LAN parties where your cheats are unavailable.
Re:I am a bot author - and I am outraged (Score:2)
Wrong. VERY wrong. Proxy cheats, a low ping, and *some* skill (this *some* means being able to strafe and dodge incoming fire) will net you a game (that ends at 150 points) where you win by sometimes 60 to 100 points (with decent players). I have used the "stooge" bot before on public CTF servers (not trying to seem good, and only playing under an "assumed name" just testing it). You just see your weapon firing, and you don't know who at. You could be underwater and it will just launch at the nearest person w/the most number of points. If you are a decent player you can rack up several hundred points in only a few minutes (if you are running the flag as well).
Most of the proxy bots depend on ping. You can tell the bot to use some sort of restraint to compensate for high pings, but if you are on DSL or cable, the bot is unstoppable. They NEVER miss. The only way around it is to circle strafe the bot and hope it can't keep up. It normally can.
One workable solution (Score:5)
Ideally, the server would check all of the client's requests to see whether they comply with the laws of physics, but that is unfortunately unworkable with today's hardware and bandwidth. It is possible to go half-way on this one, though.
If the server simply audits the client's behavior, that is, verifies the client's requests at random intervals, fair play can be insured. Remember: all it takes is one bad request for the client to be banned as a cheater. If the auditing is done at random intervals, then the client can't adapt by spacing its valid requests with the correct interval.
All that's left is for someone to code a server to do this, and then for people to play on only trusted servers. The need for trust can't be eliminated, but it can be lodged solely in the server, where it belongs.
Re:The solution is "blessed" clients (Score:3)
Re:Possible solution perhaps (Score:3)
As long as the client knows everything about the world, these sort of exploits will be possible. I think the current protocals maintain a state in the client and then sync that state frequently. The client "knows" the state though. The only option is for the client
Jazilla.org - the Java Mozilla [sourceforge.net]
Some more depth (Score:5)
For the most part, a cheating client can't make their character do anything that couldn't happen as a result of normal game interaction.
The cheating clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully.
The "more information" part can take a number of forms. A reletively harmless one is adding timers for items and powerups. Good players will track a lot of that in their heads, but a simple program can "remind" players of it.
Media cheating provides more information. Changing all the other player skins to bright white and removing all the shadows from a level give players an advantage not within the spirit of the game. Some would say cranking your screen brightness and gamma way up is one step on that path.
More advanced clients can make available information that is not normally visible at all. The server sends over all of the entities in the potentially visible set, because the client can move around a fair amount between updates. This means that the client is often aware of the locations of players that are around corners. A proxy can display this information in a "scanner window". The server could be changed to only send over clients actually visible, but that would result in lots of players blinking in and out as you move around or turn rapidly.
The worst cheats are the aim bots. In addition to providing more information, they override the player's commands to aim and fire with very high accuracy. The player usually "drives" around the level, and the program aims and shoots for them. This is usually extremely devestating and does ruin the game for most people.
There are many possible countermeasures.
There are server-side countermeasures that look for sequences of moves that are likely to be bot-generated and not human-generated, but that is an arms race that will end with skilled human players eventually getting identified as subtle bots.
Media cheats can be protected by various checksums, as we do in Q3 with the sv_pure option. This is only effective if the network protocol is not compromised, because otherwise a proxy can tell the client that it's hacked media are actually ok.
If the network protocol is not known, then the extra-information cheats generally can't happen unless you can hack the client source.
Q3 performs various bits of encryption on the network protocol, but that is only relying on security through obscurity, and a sufficiently patient person with a disassembler can eventually backtrack what is happening. If only they would find something more usefull to spend their time on...
With an open source client, the network communication protocol is right there in the open, so any encryption would be futile.
Any attempt at having the client verify itself isn't going to work out, because a cheating client can just always tell you what you want to hear. People have mentioned nettreck several times, but I don't see how a completelty open source program can keep someone from just reporting what it is supposed to for a while (perhapse using a "real" copy to generate whatever digests are asked for), then switching to new methods. Anyone care to elaborate?
I think a reasonable plan is to modify QW so that to play in "competition mode", it would have to be launched by a separate closed-source program that does all sorts of encryption and verification of the environment. If it just verifies the client, it would prevent the trivial modified client scanners and aim bots. It could verify the media data to prevent media information cheating. To prevent proxy information cheating and aim bots, it would have to encrypt the entire data stream, not just the connection process. That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends.
In the end, it is just a matter of making it more difficult for the cheaters. If all it takes is editing and recompiling a file, lots of people will cheat. This is indeed a disadvantage of open source games. If they have to grovel over huge network dumps and disassemblies to hack a protocol, a smaller number of cheats will be available.
Even if the programs were completely guaranteed secure (I havem't been convinced that is possible even in theory), an aim bot could be implemented at the device driver level.
It would be a lot more work, but a program could be implemented that intercepts the video driver, the mouse driver, and the keyboard driver, and does bot calculations completely from that.
Kind of sucks, doesn't it?
John Carmack
Problem has already been solved! Stop babbling. (Score:5)
As several others have pointed out, Netrek solved this problem a LONG time ago. I'm responding where I am so that this post gets, hopefully, seen by everyone who hasn't read yet, so we don't get any more vague, unclueful debate on this.
The solution is very simple. ID compiles a 'vanilla blessed' server. ID compiles a 'vanilla blessed' client. They create an encrypted binary key for the 'blessed' client, based on the client binary itself. They distribute this key with the vanilla server. They allow server gods to add any additional compiled keys they want - and to turn off or on whether key checking is used.
Now, every single server will be able to be accessed by the vanilla blessed client, no matter what. It all works out of the box. Turn on key checking, and no hacked binaries or recompiled clients will work on your server. Want to make a mod? Compile your modified client binary and distribute a matching encrypted server key for it. Server gods add your key if they like your client. It's that simple. If you want to run a "chaos" server, turn off key checking. Anyone can come in and do what they want - and THAT is often pretty fun.
It works great. People have been trying, and failing, to make 'borg' clients for Netrek for quite a long time now. There are some very good borgs that used to play on the Chaos servers. But they don't and CAN'T get into the vanilla servers.
You could still make it work ... (Score:3)
Anyways, I think the general point you were trying to make (and very valid) is that waiting for the server to "approve" an action might take too long, and you're right. Unless we get really fast network connections, the only other way around this would be to use a hybrid approach hwere the server sortof trusts the clients, but then "audits" some players (randomly, or top players) and even if it let's actions go through (for speed) it might still reserve the right to analyse them and kick you out later. Once a cheater has been detected , his/her actions could be undone or simply ignored and the player is kicked out/banned from the server.
John doesn't want to be Linus (Score:3)
Re:this is a big deal (Score:3)
heh.. bringing up the question.. what if Carmack did it this way on _purpose_..?
i mean think about it.. now that it's OSS all these Q1 holdouts have had their game ruined. So what? So, they have to upgrade to Q2 or Q3. Meaning Carmack gets more money.
I don't honestly think this is the reason Carmack went open-source, and i think that the way ID is willing to let go of intellectual property they no longer use is wonderful.. but still, interesting to think about. Excessive paranoia is fun!
-mcc-baka
listen to your heartbeat delete beep beep BEEP.
Re:Open Source is not the problem (Score:3)
What you're concerned about is actions... Bots can shoot better, and dodge better (theoretically) than humans. How does the server tell it that perfect spin while holding the lightning on a guy who ran by was Thresh, or a bot?
Similarly, the client can change the way information is displayed. Perhaps they change the Z sorting for items, so that all players that are drawn are drawn in front of walls, even if they'd normally be behind... Throw in a simple GL effect to indicate the difference between an X-Ray view and a non-X-Ray view and you've got a way to avoid ever being suprised at corners.
It's impossible to stop cheating in an environment with untrusted clients. Even with black boxes like console systems, it just raises the bar, making it harder to cheat.
What is cheating? (Score:3)
Would targetting computers and nightscopes be cheating if everyone used them? Of course not. It's only cheating when people don't agree on the rules.
You might think that robot/cyborg players were cheating unless your goal was to see how good you were playing against the AI. Or unless you were competing with other humans to see who could build the best robot.
So making it impossible for the game to have bots and timers and other add-ons isn't necessarily the best approach, since that eliminates the potential for whole new forms of gameplay among consenting participants.
That's why this is and will always be a social problem, not a technical problem. And it's one with a simple solution: don't play with jerks.
It's just like Usenet: it used to be a nice place, but then it got overrun by idiots, and so newer, smaller communities like Slashdot appeared. If you are playing Quake and there are a lot of cheaters and idiots around, chances are your community got too big (and thus lost the elements of it that made it actually be a community) and you need to find or create a more intimate one.
Re:Well-Known Solution (Score:4)
Unfortunately, this isn't true.
When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender.
To oversimplify: you can know who I am, but you can't know that I'm telling you the truth.
Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using.
This is all very similar to the general copy-protection problem [counterpane.com] as well as the fundamental impossibility of DVD encryption [counterpane.com].
A comment from the current Netrek keys maintainer (Score:3)
Absolutely nothing. We just make it as difficult as we can. Someone with enough determination can (and has) spoof us.
Let me introduce myself. I am the current netrek client KEYGOD. I am the one who edits and serves the keyring that go to all the servers who wish to validate keys. How does it work? Not by open source. Well, not very open source.
The people who own the RSA patent have given us permission to use a version of their algorithm for authentication purposes only. That source snippet is not included with any server OR client source tarball. Neither gets it, so the source isn't really "out there" or open-source. Who gets it and how are things blessed? Well, here's where trust comes in.
The source for the RSA verification is relatively tightly controlled for US export, and patent and copyright reasons. There's a US version and a non-US version. You get the RSA source by becoming an established client developer or Server God. You ask us, who run the metaservers to give you the key to unlock the source tarball and include it in your source compilation.
For a server, you're done, it will go fetch the keys from the keyring automatically. For the client, the verification source generates a public/private key pair stores it in about 20 different variables in random order and random .o files. Each .o file is randomly linked in to the final binary, and symbols are stripped. No binary CRC checking is done. Multiple binaries can be compiled with the same key, and yes, you read that right, the key IS stored in the client binary. The client maintainer will then offer the client public key to me, and I have a fixed set of criteria for accepting or denying a key.
We, the server gods, client developers, and I, have to trust each other for this system to work. We have to trust that someone didn't compile a borg using the same key as a non-borg. Hell, we have to trust that someone didn't out and out try to bless a borg outright since it is practically impossible for us to check all the clients. Server Gods have to trust me to not slip in my own or my buddy's borg. The players have to trust the Server God to not put in server side cheats for himself. But there are recourses. Someone can cry foul on rec.games.netrek and we can investigate and yank a key. Server Gods can add their own keys of people they trust, and can reject keys from the keyserver.
Maybe I'm overemphasizing this, but at some point, people ARE going to try to cheat. There is nothing anyone can do about that. You have to hope that that number is small and trust that people are generally going to Do The Right Thing. Barring that, we try to make it as difficult as possible for the casual cheater to succeed. Heck, the non-casual cheater doesn't even need to hack the binary. They can twiddle with the IP stack. They can even write something under X to send X events to the client, I'm sure you can do the same under Windows.
Another level of trust is with the client developers. We have always been adding new features and new clients. Every once and a while a feature introduced by a client developer may be deemed borgish. A flame-fest/discussion occurs on rec.games.netrek, and if a feature IS declared borgish, we have to trust that the client developer retracts that feature.
If you want to see how we discuss this, do a Deja search on rec.games.netrek. Keywords like "New Client" and "borg" will hit most of those discussions.
Now to find a moderator to moderate this up...
Re:Open Source is not the problem (Score:3)
I completely agree. This has nothing to do with open source or closed source. It is just simply impossible to stop cheating in an environment with untrusted clients. If you force clients to be trusted somehow (which won't work anyway) by only releasing "blessed" clients, then you have just lost the benefit of open source, and made a humongous pain in the ass for
All sorts of solutions and fervent discussion is flying around about how to make it secure. It always resolves down to security through obscurity. In the end any "security" system in place will just make it harder on decent players. Because of the simple fact that any system that trusts the client is unsafe, it will never be a absolutely safe game (unless
Jazilla.org - the Java Mozilla [sourceforge.net]