Slashdot Mirror
Open Source Quake Causes Cheating?
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. "
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
Python
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!"
-Pete
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
Jacob Lehrbaum jacob@linuxdevices.com
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.
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
"almost all programming can be viewed as an exercise in caching"
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.
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
http://www.doxpara.com
As others have illustrated, it's not the open-source model but rather this particular client-server model that's at fault. Let's see what we can salvage out of the existing model:
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.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
First, the Quake architecture of (reletively) dumb clients conencted to an authoritative server prevents the egregious cheating possible in some games ("I say you are dead now!", "I say I have infinite ammo!").
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
http://www.netrek.org
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.
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 as well as the fundamental impossibility of DVD encryption.