Slashdot Mirror
ESR on Quake 1 Open Source Troubles
The following was written by ESR. You know who he is already ;)
The case of quake cheats The open-source community got a lump of coal in its Yule 1999 stocking from renowned hacker John Carmack, the genius behind id Software and such games as Castle Wolfenstein, Doom, and the Quake series. Carmack's .plan file noted a problem that has swiftly emerged since the Quake 1 source was released under GPL; it seems that some people have used their ability to modify the Quake client as a mechanism for cheating.This may at first sight seem a trivial issue -- who cares if a few testoterone-pumped teenagers cheat at a shoot-em-up game? But in today's internetworked world, countermeasures against Quake cheating arguably provide an important laboratory model for cases that are decidedly not trivial, such as electronic commerce, securities trading, and banking.
The Quake model is made particularly relevant by its open-source connection. Open source advocates (including me) have been making a strong argument over the last two years that open-source software such as Linux and Apache is fundamentally more secure than its closed-source competitors. Cryptographers have long understood that no encryption system can really be considered well-tested until it has been energetically and repeatedly attacked by experts who have full knowledge of the algorithms it uses. Open-source advocates argue that there is nothing special about cryptography but its high stakes -- that, in general, open peer review is the only road to systems which are not merely accidentally secure by obscurity, but robustly secure by design.
Carmack, therefore, caused a bit of a flutter on Slashdot when he went on to to suggest that only a pair of closed-source encryption programs could solve the Quake-cheating problem. The problem, as he correctly pointed out, is that asking the open-source client to verify its own correctness won't work; a sufficiently clever cracker could always write a client that would simulate the right kinds of responses and then cheat.
A debate ensued, with several people pointing out that trusting the client half of a client-server pair is bad security policy whether the client code is open or closed. Fundamentally, there's no way for the server to be sure it isn't talking to a clever simulation of `correct' behavior. Thus, opening the source to Quake 1 didn't create security problems, it merely exposed one that was already present (and exploitable, and for all anyone knew already secretly exploited) in the design of the game.
Carmack weighed in to make clear that the Quake-cheating problem is subtler than many of the debators were assuming. It's not possible for a cheating client to give a player infinite ammunition or life points; the server does not in fact trust the client about these things, and manages them itself. This is correct design; whether or not it's open-source, a bank should not depend on a customer's client software to tell the bank what the cutomer's balance is!
Carmack observes that "the [cheating] clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully."
The serious "more information" cheats depend on a performance hack. In order to hold down the number of updates of the Quake world it has to pass to the client, the server gives the client information about the location of objects and opponents that the player can't yet see, but might be able to see before the next update. The server then counts on the client not to make those things visible until they "should" be (e.g, until the user gets to a particular location in the maze the client is simulating). A cheating client can reveal an opponent seconds before the player would turn the corner and expose himself to fire.
The "more skillfully" cheats substitute the computer's speed and accuracy for tasks that the server and other players expect the player's hands and brain to be performing. Carmack talks about "aim bots" which automatically lock the player's gun onto visible opponents and fire it with inhuman accuracy.
And indeed it's hard to see how either of these sorts of cheats can be prevented given an open-source client and no way independent of the client itself to check that the client is honest. Thus Carmack's suggestion of a closed-source Quake-launcher program that would take a checksum of the client binary, communicate with the server to make sure the binary is on an approved list, and then handle communication with the server over a cryptographically-secured channel.
Carmack's argument seems watertight. What's wrong with this picture? Are we really looking at a demonstration that closed source is necessary for security? And if not, what can we learn about securing our systems from the Quake case?
I think one major lesson is simple. It's this: if you want a really secure system, you can't trade away security to get performance. Quake makes this trade by sending anticipatory information for the client to cache in order to lower its update rate. Carmack read this essay in draft and commented "With a sub-100 msec ping and extremely steady latency, it would be possible to force a synchronous update with no extra information at all, but in the world of 200-400 msec latency [and] low bandwidth modems, it just plain wouldn't work." So it may have been a necessary choice under the constraints for which Quake was designed, but it violates the first rule of good security design: minimum disclosure.
When you do that, you should expect to get cracked, whether your client is open or closed -- and, indeed, Carmack himself points out that the see-around-corners cheat can be implemented by a scanner proxy sitting between a closed client and the server and filtering communicatiuons from server to client.
Closing the source of the client may obscure the protocol between client and server, but that won't stop a clever cracker with a packet sniffer and too much time on his hands. Carmack confirms that even without the packet sniffer or access to source there are a variety of ways to flush out anticipatory information, ranging from tweaking the gamma and brightness on your screen to banish shadows to hacking your graphics card's device drivers to do transforms of the world model (such as making walls transparent).
We're back in familiar territory here; the history of computer security is littered with the metaphorical (and in some cases maybe literal) corpses of people who thought security through obscurity was sufficient. Crackers love that kind of naivete and prey on it ruthlessly.
The aim-bot cheat is trickier to prevent. The difference between human and aim-bot actions is measured only in milliseconds of timing. Changing the protocol to stop it from leaking information won't banish aim-bots; it would take the server doing statistical analysis of player action timings to even detect them, and (as Carmack points out) "that is an arms race that will end with skilled human players eventually getting identified as subtle bots."
Fortunately, the aim-bot cheat is also much less interesting from a general security point of view. It's hard to imagine anything but a twitch game in which the client user can cheat effectively by altering the millisecond-level timing of command packets. So the real lesson of both cheats may be that a closed-source program like Carmack's hypothetical secured program launcher is indeed a good idea for security -- but only if you're a hyperadrenalized space marine on a shooting spree.
(Any computer game at which computers are better than most humans has analogous cheats, some of which aren't even detectable in principle. Carmack observes "correspondence chess has been subverted from its original intent by players using computers." This isn't something security design can fix.)
If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers.
Open source keeps designers honest. By depriving them of the crutch of obscurity, it forces them towards using methods that are provably secure not only against known attacks but against all possible attacks by an intruder with full knowledge of the system and its source code. This is real security, the kind cryptographers and other professional paranoids respect.
It's the kind of security the Linux kernel and the Apache webserver have, and the kind people victimized by the Melissa and Chernobyl viruses and Back Orifice and the latest Microsoft-crack-of-the-week don't have. If you're betting your personal privacy or your business's critical functions on the integrity of software, it's the kind of security you want, too.
To recap, the real lessons of the Quake cheats are (a) never trust a client program to be honest, (b) you can't have real security if you trade it away to get performance, (c) real security comes not from obscurity but from minimum disclosure, and most importantly (d) only open source can force designers to use provably secure methods.
So, far from being a telling strike against open source, the case of the Quake cheats actually highlights the kinds of biases and subtle design errors that creep into software when it's designed for closed-source distribution and performance at the expense of security. These may be something we can live with in a shoot-em-up, but they're not tolerable in the running gears of the information economy. Avoiding them is, in fact, a good reason for software consumers to demand open source for anything more mission-critical than a Quake game.
CmdrTaco, you got it wrong. Quake3's source wasn't GPLed; it was Quake1 you're thinking of.
Get fragged @ Lone Star Quake
South Texas' premier Quake server
I think it's a great idea to open source quake. It allows programmers like myself to learn tricks of game programming from the masters. It's sad that we have people in this world that would take something like open source and use it to cheat in the game. What fun is a game that you know you're going to win anyway?
=======
There was never a genius without a tincture of madness.
Oh, it's not a bug. It's a feature. Thanks.
-----------
"You can't shake the Devil's hand and say you're only kidding."
This is not a new problem! Netrek solved this problem years ago. It was explained in the previous discussion on this, but to be brief: you have 'blessed' binaries which are compiled using some sort of public/private key pair. One aspect of the key is stored in a list on the server side, configurable by the administrators so they can add and remove blessed clients as they desire. Only blessed clients in the given list can use the server. If somebody cracks the key out of a blessed client--a new one is made and the key is removed from the server lists. Simple.
Quake was written for single player and for multiplayer over a lan like doom. When internet play became an issue and quake's inability to do it well, especially for modem connections, quakeworld was written. Keep in mind that Quake wasn't designed with internet play in mind. It was hacked in afterwards.
Once again, ESR astounds me by coming up with a viewpoint I didn't know I agree'd with. Closed source is just as hackable as open source, it just protects itself by luck. Peer review has always been, is now, and may always be the best way to make something totally flawless, or at least come as close as possible.
Restating the obvious since nineteen aught five.
As a long-time Quake player who knows the inner workings of Quake quite well, I saw this coming. In fact, I posted a request for an 'ask slashdot' a bit under a year ago about this topic, but it never got posted on the webpage. Guess I should have written Quake for it to have been valid.
I wonder if this was foreseen by ID before the code was released. ( I say ID because Carmack gives credit to others for doing the grunt work of making the code releasable. ) If so, the protocol should have been modified or ripped out of the clients that were OSS until someone DID take these security measures, at which time ID would re-release the real source tree.
If someone does make this cheating verification software, I recommend that they make it more open ended than for just Quake. I think this sets a precedent for Open Sourcing network games, and if a solution is readily waiting, people will be more open to open their code.
. . . but wasn't this what everyone else was saying the other day? I mean, it's good that it's coming from someone respectable in the Open Source world (oh, hush Stallman ;-), and predictably it seems written to use a trivial(?) example to serve as evangelitical text to the non-believers. But at any rate, is this the place for it? I know I weigh Slashdot discussion (-inanities of course) almost as much as words from a "spokesman" for the community. I agree with what he says, but I'd have thought us discussing it would be all the swaying we need. I don't need top-level affirmation that what I believe is right.
;-)
I personally think (and hope ESR does too) that this is the sort of thing you post to a non-community news source. Let's face it, a good percentage of Slashdot readers are Open Source people. No need to preach to the converted. It's a great parable for the benefits of Open Source, but we know all that already.
Oh, and is this affecting Q3 too? I thought it was just relevant in Q1 (the game with the open source). I don't know; I'm a Drakan player
Bad things often happen to good people,
It is up to them to see that they remain good.
My thoughts exactly ESR! Who really cares if Q1 clients are bastardized? The more important issue is can a malice-proof Quake client be created entirely in open source? I think it can and like I said yesterday the solution will have far reaching implications for secure networking.
He is right showing the problem is an exchange between performance and security. But we must think if we want Quake's server to become slower, creating a lesser quality game in the network, or if we mantain the same characteristics on the server and let some hackers take the advantage out of it when coding the client(I think they deserved it. It's not anyone who can do this type of hacks!).
Of course that softwares who are used in systems who need more security(like web servers, financial systems, etc.) must surely trade performance for a better protection against clever client coders.
"Learning, learning, learning - that is the secret of jewish survival" -- Ahad A'Ham
A) This is the Quake 1 source Rob, not Quake 3
B) ESR states: I fail to see how if Quake had been open source software from the beginning, how the situation would be any different. Quake is a fast action game that is often played over connections with high latency, the dependency on "millisecond packet timing" is inherent to the game itself due to how quickly entities manuever in the game world. Similarly, trying to build aim bot detection into the server from the beginning, as you suggested, would run into the same wall its hitting now: some players have enough skill that some form of statistical analysis would conclude they are using an aiming proxy.
:wq
I think ESR's calling the release of Q1 src a lump of coal in hacker's stockings is a bit extreme.
Even the ensuing debate over multi-user game/world security models is very significant for future development.
Now that Q1 src is opensourced, what's to stop those of us who are so unhappy with the network play model from re-implementing it??
If we can come up with a better, faster, tighter, cross-platform, secure model for network gameplay, I'm sure that many game developers would be interested in adopting it.
so, let's start designing and implementing the new protocols for networked online worlds!
Thanks to John Carmack for the Q1 src which has fueled so much thought about gaming, AI, virtual communities, new user interfaces.... and much more.
... and thanks for the linux port when all the other game companies were writing to Windows only.
Fortunately, the aim-bot cheat is also much less interesting from a general security point of view. It's hard to imagine anything but a twitch game in which the client user can cheat effectively by altering the millisecond-level timing of command packets. So the real lesson of both cheats may be that a closed-source program like Carmack's hypothetical secured program launcher is indeed a good idea for security -- but only if you're a hyperadrenalized space marine on a shooting spree.
Uh, with all due respect, THAT IS THE MAJOR PROBLEM!! You in essense admit that this problem is unsolvable, then go on to say that it's really not a problem that anyone that's important (to you) cares about. Well, trivializing the problem by mocking quake fans doesn't make the problem go away, and it doesn't change the fact that open source has made the problem infinitely worse.
Then, of course, you go on to conclude that open source is the ultimate answer (while giving no evidence).
ESR, normally I'm with you, but this essay was major smoke and mirrors.
---
I first thought, who the hell cares about a bunch of punks cheating in a shoot-em-up? For me, when I first heard it about it I thought, hey, let them cheat, it's not relevant to the Open Source community anyway.
ESR proves me wrong. Again. He sees things that would normally escape the naked eye. I guess that's why he's our No.1 spokesman, right?
- JoJo
Forget generation X, now there's the open source cheater's generation! Finally, the lie of open source is being exposed for what it is. The real truth will come once the open source bubble bursts, and I can't wait till it does.
Traditionally this problem has been handled in a closed source world with a public key/private key sort of setup with the private key (for decryption) and encryption algorithm embedded in the compiler binary somewhere.
This leaves the IP provider's product at the mercy of the vendor of the CAD tool
A few years back this all fell apart for Verilog, a popular simulation compiler, for various reasons the language runtime is extensible, it was also interpreted - this left a version of the compiler which contained symbols. An anonymous poster to comp.lang.verilog pointed out how to write a gdb script that set a breakpoint in 'yylex' and extracted the decrypted token from IP.
All hell broke loose .... eveyone who'd ever sent encrypted IP to customers was now open to the world...
So - back to the topic - does anyone have any idea how one can do this sort of thing in an Open Source world - send people secret stuff to be used by an OS program without giving away the secret? Given that the only schemes I've seen to do this rely on security-by-obscurity (as above) I suspect it just can't be done.
Yeah, if you repeat that to yourself long enough you'll start believing it too! Open Source does work, maybe not for you, but it does work (Linux).
I've been thinking a lot of how to make an aimbot impratical. It reall boils down to limiting the control responses (movement of the players) and increasing the external stimulous to the system. If the movement was limited to what a star player should be expected to do, then maybe we could design the response to external disruptions (being hit) such that they would throw a classic linear control system off enough to make it non competitive. This is an inverse control theory problem. Find a settling time and characteristic for classical control systems that makes the aimbot suck. Then change the game enough to make sure this happens.
If the cheater then wants to use a non linear control system, or some really good linear multivariable control system let them develop it. With the right plant to design for this could be made into something that if someone implemented the program for it I'd be willing to let them use it just from the impressivness of the work.
Maybe the coders could add a filter that automatically would automatically throw away any "first post" worthless crap.
peace favor your sword
It was the original Netquake v1.06. You know, with no client-side prediction and lag on your movements. The trade offs that John Carmack and crew made were made to make the gameplay better, not to make it so you can't cheat. I for one would rather risk the remote chance that I would be playing against someone who rewrote part of the code to cheat, than play with a 250ms delay to all of my input on the game again.
One thing that isn't really taken into account in all the stories are that most quake servers (Mine included) have a steady base of regular players, and that player base pretty much stays the same. We are all good friends who play and wouldn't play with cheat things like that and if they did we would know shortly after they started because they would get instantly better than they were the day before. Improvments like that don't happen in games like this.
I would say that ESR doesn't play quake much, and just wants to get his jabs in to give the closed source development sceme a blacker eye than it already has.
Do you Gentoo!?
ESR is right when he says the problem is in the program design, and has nothing to do with open source. If you need reliable security, use proven security tools like encryption, not security through obscurity.
ESR almost touches on an interesting point, that bots can win because they use all the available info passed to the client, and not just the stuff that is then passed on to the human player.
Why not put hooks into the Quake client code for players to create their own bots? Make hooks for all the available info, and then play will change from who has the fastest fingers to who has the best bot.
You work around the problem that someone has more info than another (you could call the early warning of other players 'radar' for theme) and turn the game back into a close fought competition.
Experienced coders could compile their own clients that gather info from the code hooks, and a benevolent coder could build a scripting package that uses the same hooks for the less technical crowd.
If you can't outlaw cheating, make those the rules.
-Red
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
This is a nice little essay on why the people who wrote Quake were stupid, but it provides no solutions or even suggestions at where a solution may lie. You can say "So, in future, let's do this instead of this" but that doesn't help the problem at hand. The problem at hand is, idiots are screwing around on Quake.
Devilled Eggs - A disturbing little creation of mine.
I am not a huge quake fan, but i thought it would be pretty cool if they had quake games hosted just for hacked clients. so if someone comes up with a client that can see through walls, you have to come up with a hack which makes you invisible. then someone comes up with a hack which makes you see invisible players. if someone creates a hack that gives them impenetrable armor, than someone else has to come up with a hack that can destroy that armor. who it would a 3D hack-fest to see who has the best kung-fu. instead of a game that you win by purely being able to aim and shoot faster than others, have it where those with the best programming skills win.
You should consider reading the article before you criticize it. (Who moderated this guy up?)
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
"If Quake had been designed to be open-source from the beginning..."
...it would have changed nothing.
To make Quake secure, you would not be able to trust the client. To make Quake playable over modems, you have to trust the client (lack of bandwidth and latency issues).
Adversary
Open the source, close it, print it up and wallpaper your cubicle with it. Its still not feasable to have the server do all the work. So surprise, it won't be secure.
Closed source doesn't prevent bad people from doing bad things.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
This just highlights the real problem - Running untrusted client side code is still an area of theoretical CS. its still being worked on and other than forcing the clients to do only minimal things and using authentication/encryption, there is very little that can be done. and yes, i know there are workarounds around that too.
I'd like to point out that interplay's star trek multiplayer which is closed source was hacked so efficiently and throughly that cheats cropped up at the rate of nearly 5 a *day* -- proving that closed source is just as fallible. Hell - i did some of the hacking myself (just use excel to change values for starships in the text file - dead easy) and was running cheat only server games for a while.
It seems to me that the thing that was most widely praised about half-life was the creative AI players. It will be fun to see what people can come up with for Quake. Could make Quake 1 worth playing again.
(song tuneof="spam spam spam spam" title="Things Quake's/QW's networking implementation was designed to deal with, in descending order")
m kind of thing. It's a game. It's a game that has a player community that consists of 60% people who love the game, and 40% qu4k3 k1dz. They are irrelevant as their penises are tiny. (the k1dz penises, not the true players) This article is a rehash of plans and posts with a not-technically-sophisticated-enough explanation that doesn't fully describe the complexity of the situation and the target audience consists of people who are bored at work and will read any goddamn thing that floats across the web. I hereby piss on someone else's well-intentioned, well-written and well-executed effort to explain things to people.
Ping lag latency noise
Dropped packets loss loss accuracy sampling rate issues
Ping lag latency noise
Fun lag latency noise
dropped packets noise noise
ping lag latency noise
security
buy a ferrari
marry the receptionist
(/song)
Moral: Quake is not a mission-critical-eCommerce -iEnabled-Me.Personal-Electronic-FinanceSecure.co
I am now just mutilating whitespace. My job is so boring. I have seven win peecees at my disposal that break a lot. They can't be fixed. Noone wants to fix them. There is no money or interest in fixing them. Yet I am paid to watch them. Someone end my empty horribly empty life. I am a total twat with no life. Kill me. Moderate me. Please.
-troll taker
but ESR didn't add anything new to the discussion it just looked like the comments that were already posted under Q1 release and then rehashed. I think everyone agrees that security through obscurity is a bad idea but as Carmack explains in the world of modems you don't really have a choice, you need the performance to sell games. Now if some e-commerce site decided to do this then I would be worried but this is just a game we are talking about. I could see if e-bay had released their source code and people had decided to hack it so that they could cheat but this is just silly.
Vidi, vici, veni. (I saw, I conquered, I came)
Before we all get up in arms about what JC said about closed-source client/agents and ESR's response, let's keep something in mind: what's important to ESR and the Open Source world is, in this very case, different than what's important to Carmack.
Don't forget, it was Carmack who made the decision to move away from FPS's and into Arena, which is clearly an Internet-gaming gamble. So now the issue with cheats in Q1 probably doesn't affect his plans *today*, but what about later? Could the techniques developed in Q1 hacks become tomorrow's monsters that keep "everyone" from playing Arena online? That's gotta worry JC, I would think. That problem would adversely affect the (so far) enthusiastic yet also reserved acceptance of the gaming community to the changes in Arena.
So this is a problem that Carmack must now solve, it along with it's closed-source baggage that caused the problem to begin with. Is this our problem? Should we care?
I think ESR's saying, "I'm an open source advocate, and I will remain one. John Carmack's problems are his own." That's my read on it.
-- "In order to have power, I must be taken seriously." -Mojo Jojo
how about proving what you're saying instead of making sweeping declaratiosn without backing them up?
There is no way to make software that runs on the client side totally secure. It is always possible to hack the client to your advantage because it runs on your computer, and you can fiddle the bits in your computer any way you want.
No matter what kind of proxy or checksummed client they use it'll be hackable because it's runnable. It's the same reason that copy-protection, secure audio formats and DVD can all be cracked... at some point code has to be executed that the user can change.
Even if Carmack does as ESR suggests and only send full world updates, that will not prevent a proxy that jumps every time a rocket is fired at your feet or any number of other subtle helpers.
The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again.
I didn't say it would be easy, just the only way to make it truly secure.
You imature slashdotters just don't get it!! ESR said if quake 1 was open source from the beginning problems like this would not have happened. The speed would STILL have been there, the security would have been there and even better. It would have gone thought rounds and rounds of peer review. Clients would not have the ability to cheat no matter how good the programmer was.
Open sourcing software that has been closed source from it's birth is the flaw. Now implimenting a quick open or closed source security fix would slow down the game. I am hopeful the collective minds of the open source community will solve this. As more and more people want to open up once closed source this will beceome and even more important issue.
Quake is a game. We can try bunches of things, since we can afford to blow it. What do we do when serious programs need similar protection and we can't afford to fail?
With a game, we don't have to get it right the first time! We can try things and incrementally evolve the correct solution. Different people will have different pieces of the puzzle, and enter in at different points in time.
I propose that what you really want for Quake is to see the source your opponent is using. So you want authentication and revocation. Some cheats will be cool, and evolve the client. Some cheats will be stupid and/or pointless, and you will want to revoke them.
One possible approach is to have people register their sources to trusted authentication servers which will hand them back authenticated binaries whose signatures quake servers can accept or deny. If I think someone is cheating, then I can go look at their sources. And perhaps have some sort of voting scheme where some clients are declared "stupid cheats" and their access to quake servers denied.
My idea needs work, but it's a good starting point. I'm trying to stay brief, so am not going into a lot of detail.
I definitely think Carmack had the right intentions and open source IS indeed the way to go. It's just that maybe releasing THIS particular souce was a little premature. I believe most people are good at heart, but there are always a few bad apples to a barrel that spoils things for everyone else. So what is the solution? I have no idea, except maybe waiting until Quake and other games of the like get so out of date that releasing the source would be like Apple Adventure to Everquest. Well, I just hope this doesn't discourage other companies from trying to do the same for their products. I am certain that there are ways to solve this current problem. Just a little more time is needed to think of a solution. Imagine if (unlikely) Microsoft released their source. The bugs and code would be exploited to no end. But I'm sure that having it open sourced would be better than MS trying to fix them all on their own.
It seems everyone is forgetting that this *IS* just a game.
Something you do for entertainment.
Now, if some people find creating an auto-aming robot, or even a fully AI player entertaining, then fine. (after you have killed so many mobs, so many ways, writing a program to do it can be entertaining)
And if you find aiming by hand to be entertaining, fine.
No one says you have to play with Bender, the auto-gunning robot. Or Tinny-Timmy, the manual-aimer. Go play with people who agree to paly the same way you do.
The mud community has for years had issues with bots or response-enhanced scripted players. In the end, rather than create an ulcer for yourself over these issues, its better to just remember:
It *IS* a game.
If it was said on slashdot, it MUST be true!
Why do we listen to this whacked out gun-toting hippie anyway?
I suppose that creating a day-trading bot that gives the user massive advatages in terms of spotting good stock would be bad?
Think of it - all your adrenaline slurping marine buddies sitting at a bank of computers send rapid-fire orders for stock. Seizing companies left and right, leveraging your ammuntion supplies...
Now, is this cheating or good buiness (Assuming it works) -- I'm quite sure that if anyone ever gets any good at it there's some masssive repercussions to be had, either SEC sanctions or stock market crashes. Of coure if you had that sort of day-trading client would you use it over the normal one?
Of course there's more security on the server side for day-trading, but the same issues are relevant there. I suppose we ought to be thankful that Quake doesn't actually have massive effects on our economy, and that hakers are leery of dealing with money things because the penalties for getting caught are larger.
I'll reply to this probably seconds before you get moderated as a Troll, but that's ok. Open Source works just fine. It worked before people wanted an alternative to MS and it will work when MS isn't an issue any more. Open Source is a "Good Idea" in most cases, if not all. The entire Patent office is an Open Source system -- without the freedom to use the ideas. If you just want to be a Troll, no evidence will convince you; the point is, some of us disagree with good reason.
- Michael T. Babcock (Yes, I blog)
Carmack's right; the only realistic solution at this time is to keep at least part of the verification module closed-source. Why is this such a problem? Who the hell cares if there's some obscure part of the code you can't get at? Why would this be worth sacrificing decent game play?
Look, if you don't like the closed source stuff, go ahead and play without it and contend with all those Z-bot asswipes who get a kick out of ruining the fun for everyone else. Me, I'll take the closed-source module that Carmack's offering and actually enjoy the game.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
The solution there was to distribue the source as Open Source, but only allow "blessed" binaries to connect to "blessed" servers.
This hasn't been fool-proof. Plenty of people have cracked Netrek's security, and whilst it's good at keeping the drearier riff-raff out, all that really does is give you a better class of riff-raff. It doesn't solve anything.
How, then, to prevent cheating? That depends on how much the client does, and what counts as cheating. The server can always prevent cheating, with anything under it's direct management, by simply controlling throughput. No more than N operations per unit of time effectively prevents souped-up clients with super-human reflexed, for example.
Controlled throughput also gives you much better Quality Control, as you can effectively ensure that no connection suffers undue lag at your end.
As for anything else, this calls for the ability to access points in the code by address. If you can do that, then the server can call routines to check for validity in a way that can't easily be bypassed by simply rigging the checks.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Of course. Public-key Crypto. Much like the ssh install, first time you run the progam, a public key is created for you. When you want to tranfer files, a connection is established (maybe even over ssh), public keys are exchanged, and off you go. The are excellent open source programs to do this already (OpenSSH, GnuPG, etc). The wheel has been invented, now its time to use it!
(The even easier solution is not build it into the CAD program, just have people mail files securly with GnuPG/PGP. Why make CAD programmers deal with encryption, its not their baliwick!).
Two closed source programs in addition to the q1 source. They are not closing the q1 source. (First Myth Debunked) Verification programs should not be open source. Espically if you are not making any money on the program anymore (for instance if you are working on say, q3.) and you have roughly six or seven hours a month to spend on the project. (Which is why they GPL'ed it.)
This is the defination of an insane frenzy. People don't even read the stories now. Drives me crazy. So hence I remind everyone the first rule of positive posting: Read the story first (doi doi doi). The Second rule is: Put yourself in the shoes of the woozle. (Woozle; as in kill the woozle, for instance putting yourself in Carmack's shoes, or Amazons, etc.)
NOTE: If you seriously have a problem with this, NOTHING is stopping programmers from editing the source in such a way that the two closed source proggies would not be necessary, and the game could still be cheat-free.
I honestly don't see Why everyone is opposed to this bandaid fix until open source itself can fix the problem. Unless of course the code is too big and we run into whatever the law is that says, "The Bigger the code, the fewer people want to _start_ work on the monster.".
Frustrated.
-[ World domination - rains.net ]-
I've actually been working on this concept in my spare time, and I came across the answer:
It can't be done in software. Period. It needs hardware.
What is needed is part of the kernel implemented in hardware. You have to have something along the lines of ram that is physically locked and cannot be accessed by even the (software) kernel - only by itself; or, a plug-in card which simulates such an effect. In both cases there will also need to be a hardware implementation of public key encryption, wherein any software can read the public key and no software can read the private key.
The process would basicly consist of the client and the server sending the other an encrypted checksum binary, which can only be run by the process it is sending to, in its privileged memory space, encrypted with the public key of the other. The hardware device decrypts the binary and runs it (with read-only access to the memory space, almost all other access cut off, to avoid a major system security risk), re-encrypts the packet with the sender's public key and its own private key, and then returns it to be sent. This way, both the client and server can be guaranteed that the checksum program they sent was actually run honestly and the data returned is truly from the program. And, as the loaded program is unable to be accessed by anything but itself, no program can modify it after it has been started. There are a few other details I have omitted (such as being able to query to make sure the program is in such a memory space), but this is the basics of it.
I went over every angle of doing it in software, and there is no other possible way that doesn't involve the fatally flawed "security through obscurity". If anyone thinks I am in error, please let me know, I'll be glad to discuss it with you.
- Rei
(spurius@earthling.net)
P.S. - there is a moral consideration of such hardware. It makes it possible to have software that is physically un-pirateable, if done correctly. Just so you know.
When was the last time you ran anywhere? I mean with your own legs, not by pressing 'X'?
c) real security comes not from obscurity but from minimum disclosure.
A lot of code was opened up in the past 2 years that was originally developed "in the dark". Starting from Mozilla. All of them (except the ones to which nobody really paid any attention) suffered from a similar problem: as soon as the code was out, chaos started, on account of all the crud that crept in due to the closed development. As ESR wisely points out, it's the open development proccess that does the magic; developers tend to think in different ways when they know people will be reading the source. This way leads to real power. On the other hand, developing in the dark, with no prospects of ever opening the source up, and then later opening it, leads to embarassment and insecurity. as Q1, Mozilla and others kindly proved us. And of course, leads to months of reimplementation (witness Mozilla/Gecko and QuakeForge).
So in short: it's cool that companies are seeing some light and opening up code. But it will be REALLY cool only when they see the whole light and start developing in the open to begin with. And here I pause to cheer the people behind AbiWord, XDBM, Conglomerate and other company-owned, yet openly-developed-from-start (or almost) projects.
Slightly off topic, but the company I work for makes quite a bit of money by using 'bots to decide on stock/option/future trades to make. It's been doing it for over a decade, and is nothing new in the industry.
also, day traders == fools to most of the people in the know around here (in a bull market they get short term wins, but forget the long term or when the market gets bearish).
Here: I'll win your "Kung Foo" match. I delete the functions which count off damage and replace them with new functions which basically affirm "Health = 250". I compile and run this modified client in my machine.
There. Now I can't be hurt, no matter what incredible feat of programming someone else does. My client isn't capable of subtracting health. Boy, this is fun.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
I totaly agree, I have had ringers come in to what was a friendly game, and everyone quit. If they where cheeting or just better I do not know nor care.
Regular players have good days or bad, worlds they like and don't.
Systematic and regular domination does not happen.
Quake for me is a community of regular players with their own style and failings.
I do not think a cheater would be wellcome, and probably very easy to pick out.
"Think of it as evolution in action."
Quake was designed with the Internet in mind from the beginning, but Carmack underestimated the effect of modem latency. His infamous plan update went something like, "well, I have a T1 to my house, so I didn't realize how bad modems were." or words to that effect. :)
---
Uhm, coming from an old binary hacker, Closed source *is* as hackable as Open Source... Once you understand the Architecture of the system you're running on, and get to know it's Assembly language, you can modify *ANY* binary to do what you like. Hence the numerous dongle cracks / reg key bypassers that are out there for many Closed source programs. (I remember ads for dongle's calling them "uncrackable")
With open source, you have to look into the source code and try to determine what this particular algorithm does... then you have to know how to re-work the algorithm (or determine the ramifications of removing that part completely) to get it to do what you want.
With a closed source binary all you have to do is run a traceable debugger on the binary, and then you get down to the nitty gritty of what's happening. It can be as simple as inserting (in x86 terms) a JMP statement or a NOP...
"Fuzzy Wuzzy was a bear, Fuzzy Wuzzy had no hair... Fuzzy Wuzzy wasn't fuzzy was he?"
Forgive me if I'm misunderstanding you, but aren't you just moving the obscurity to hardware? After all, anything that can be processed in hardware can be processed in software (only slower).
---
Ah - but remember the premise - the end-customer must not be able see the secret information - it's purely for use with a tool that sees the encrypted file and performs some action on it that in itself does not reveal the secret to the end customer
My God!!! You guys are acting like the original poster asked everyone to do something horribly immoral. Perhaps he/she doesn't have much experience with Quake. So instead of being a bunch of arrogant assholes, maybe post some information in a positive manner so he/she could learn something. But than again, why should you? I am sure you guys are the master of everything, and never came up with a stupid or undoable idea in your life.
I know what you are going to say, "He/She should have done his homework." I really doubt if someone is going to download the source, look through it, try it out, and then post his/her idea. but that time it would days from now, and the story will have been long forgotten. All that work just because someone thought they had a cool or interesting idea about a game?
Stop active so fscking 31337.
I think ESR has got it wrong, the AimBot is by far a much worse problem than a player being able to see around corners - a good player essentially can tell where people are anyway based on sound cues or knowing how far behind him someone was. It might give a slight advantage, but not the godlike ability to clean out a room that an AimBot gives.
However, I thought of a possible solution - one way to stop AimBots might be for the server to send a few "fake" players to the client with either transparent skins, or embedded in the walls, or perhaps randomly "clone" the user just behind himself every now and then. A real player would never see these "shadows" but an AimBot would fire at these pahntom targets and that could trigger the server to shut him down.
As an added bonus, an AimBot set to use the rocket launcher firing at a fake target a foot away would bring a little justice to the bot user.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Cheating in Quake will always be possible. I'm pretty sick of reading posts on these two threads where someone who doesn't even recognize the problem is trying to offer solutions. BY FAR the most troublesome cheat you can do with any Quake, open source or not, is use an Aimbot. You CANT STOP aimbots with any fancy autorization system. YOU CAN'T. NOT EVER. You can only obsecure protocols. Even if you coded algorithms on the server that detected "bot-like movement", a coder could just make his bot algorithm differ from what the server considers BOT-LIKE. This would be even easier if the server source was open source as well! Hell, you could even write a proxy bot that doesn't move the crosshair aim for you, it just shoots when it can draw a ray between your gun origin and an enemy. In this way, all the bot does is pull the trigger when you sweeep your railgun across an enemy. Try detecting that on the server. Its impossible. All you can do is use some half-baked fuzzy logic that says "Well Player-X is too good, he must be a BOT!". Which is not security at all.
Even without source to the client open source of other system components can cause problems...NVidia/3dfx have open source OpenGL drivers under Linux? Cool .. why not write a program which sits between the mouse driver and the opengl driver, takes information from both and use that to cheat? Harder than hacking open source client, but still entirely possible.
This whole issue doesn't speak badly of Open Source, nor does it (as many people here think) speak badly of how Quake was implemented. Its just the way things are. If someone wants to try to create a "secure client/server" chess system that someone sitting next to Big Blue running his chess program can't cheat at, please get back to us when you figure out how. The serious Quake cheats are in the same category as this, and just can't be solved without using some security through obsecurity.
Will we ever see open source commercial games in the mainstream? Not any time soon. Where would the financial incentive be if you were going to release a game, and give away the source for it? Assuming you had a good product, you'd end up competing with a bunch of other companies, each with their own distrubution of your game. RedHat Quake, Suse Quake...no..somehow I just don't see this happening. Has ESR taken into consideration that id is in the game business to...gasp...make money?
Open Source is fine, but sometimes I wonder if we're delusional to think that it can solve any software problem. I mean, if my steak isn't cooked well enough, I just send it back to the chef. I don't pass it around to all my chef-buddies to see if they can cook it better.
He mentions aim-bots, but as I understand it, much of the game's behavior is determined by the client side, so in a hacked client, the aim-bot would be one of the more subtle cheats possible. Worse ones could be the ability to pass/see through walls, teleport instantly anywhere on a map, get additional health/armor/weapons/ammo, fly, and probably any number of other hacks. Adding code to detect aim-bots would be like installing a sump-pump in your basement when there's a 15-foot flood on its way. The core of the problem is that the client side has all this control (a requirement in light of performance/bandwidth demands) which makes it inherently insecure. ESR is wrong, though, to dismiss this issue as one of "millisecond packet times" only relevant to twitch gamers. Surely there are other client-server situations that call for (or would benefit from) more client-side control? Is there any way to create a truly trusted client in an open-source environment? The best solution here would be to find a completely open-source solution.
You are just making it more obscure .... and raising the bar for people who want to break it.
BTW you should read up on 'skipjack' proposed by the NSA a while back - it also had 'tamper proof' packaging - which to my mind really means 'costs more to break'
This is directly analogous to the DVD software decoder problem. If the binary is available, the algorithm and all the keys are available.
Having, shall we say, "studied", my share of copy protection schemes I can attest that very little of a binary must actually be understood to coerce it into changing its answer.
And just so its all out on the table, here's my roadmap for launcher breakers. Please note that none of this has been tried, I just dashed this list off with 2 minutes thought.
Note: any apparent confessions in the above post were merely a "youthful indiscretion" and have certainly passed the appropriate statue of limitations.
If the security model of closed source fails, it will not fail immediately. The next security model will take time to crack next. In the end the latency of closed source security for software being cracked will have a given time, say 3-5 months average.
If software relies on closed source for security and it is made open, such as the opening of Quake, then all of the security weaknesses can in essence be exploited simultaneously. Software that is from the beginning open is inherently more secure than closed source software given the source code.
So, the question becomes what effect would opening Windows source code have on Windows security?
There have been so many back doors found in the past six months that I can only imagine that a metric ton of them would be found. Since the Justice department sees open source Windows as an option to cure the Microsoft monopoly, couldn't this be counter productive for average Windows users--ill equipped to install software, much less a patch--in the short term?
Are (potential) long term benefits of this worth the short term cost?
If the client is (not) displaying the "shadow warriors", then the client knows they are shadow warriors. The Aimbot can just look at the skin to see if it's transparent, for example.
The Aimbot is going to know everything a human player knows, only more.
---
Quake doesn't work that way. All accounting *IS* on the server. The only things cheats can give you is superhuman reactions and/or the ability to see therough walls.
I specifically recall seeing ESR at a local appearance where he was asked if games should be open sourced. His answer was an emphatic *NO*, and he explained why. I don't recall all of his explanation, but basically he whittled down all of the logical reasons to have a game open sourced, stating that the benefits would be minimal. For more info, I'm sure (if cornered) ESR would have no choice but to re-explain this stance.
Furthermore, I thought that one of the great things about open sourcing software was that holes could be plugged. Rather than discussing plugging holes, all I see people doing here is bitching about how this open sourced Quake I offering isn't as plug-and-play as some would have wished. Have open source advocates gone full swing in the other direction and decided that things like Quake I need to be fully cooked right off the FTP site? If so, and nobody is planning on doing any work with the sources, I have to ask:
WHY THE FSCK SHOULD ANYONE BOTHER OPENING SOURCE CODE??
Whiners... Stop bitching, grab GCC, and FIX it. Otherwise, get out of the way and let closed source software stay closed.
(Yes, I'm an open source advocate. I'm disgusted with what open source advocacy is becoming, though: a bunch of me-too kiddies who don't have the first clue what open sourced software is all about. Kind of a Linux-One thing but from a user standpoint. Get real.)
To make Quake run on slow networks and modems it had to make trade offs...saying these wouldn't have existed if open source is bullshit. People would have just taken advantage of it earlier on. What really irks me is he just try's to push open source for everything. Its his own agenda. He is famous, he likes the attention. Multiplayer games should NOT be open source for this reason. Think about it, even if you let the server decide everything, you still need to send actions (Move forward, etc) to the server....this can be sent the wrong way, so with a minimal client you still could crack the game. Whats the advantage of closed source? Easier to PREVENT major hacking and cheating groups. So what if one person hacks it? Its a lot better than the hundreds if not thousands doing it right now. ESR should pull his head out of his ass and realize or atleast tell his faithful followers that not everything is nessecarly a good thing to open up, or if so, maybe the Quake graphics engine should have been all....
www.atacomm.com - The Leader in VoIP Product Distributi
This is basically making the bots akin to the 'reboot' UN*X program some systems had way back...
From a technical or 'community' standpoint (think ebay feedback ratings), e-commerce and e-games face a similar security and trust issues.
But, the fundamental basis of e-commerce is still several hundred (thousand?) years of laws governing contracts and commercial transactions. If the technical security model breaks (as it has many times on Ebay), the legal security model will jump in, along with various police agencies, courts, lawyers, banks, collection agencies, insurance firms, and so on.
When the "e-game" model breaks, there's no real higher power you can beseech. Thus, people are more likely to break the rules, because there are few if any negative consequences. So, while you can put preventative mechanisms in (reputation systems, certificate verification, signed binaries, and so on), it really comes down to the other users, and how much you are willing to trust them.
(Think of blackjack -- you might play in Las Vegas where the Casino is supposedly trusted, or you might play your trusted friends, but you would be less likely to go into some random basement and play an illegal game because the deck could be loaded and you have little recourse if it is.)
--
Business. Numbers. Money. People. Computer World.
Quake, as I am sure you are aware, has a set of predictable rules that govern success. Running a client to enhance speed and accuracy to enhance success is only possible once you have these rules and are experiencing success.
In the short-term, there are no "rules" to "winning" in the stock market. Sure, there are ways to increase the odds in your favor, but in the end, it is a crap shoot. Either your pick wins or it doesn't, and it is much more likely that you will lose, trading in the short-term, than win -- go take a look at the success rate of day traders to see a case in point. The linked article states - after conducting some exploratory research: "All trading in the accounts was analyzed and evaluated (4,093 trades in 26 accounts). Seventy percent of the accounts lost money and were traded in a manner that realized a 100% Risk of Ruin (loss of all funds)." While 26 accounts is not a representative sample, I think you will find that many (read at least more than 50%) day traders are losing money. The only thing automating this process would accomplish is increased efficiency in their ability to lose cash.
Breathe easy. The implications of Quake 1's GPL isn't going to end the world as we know it.
Although I do feel fine.
So then public key cryptography is used where the keys are stored in hardware. This means either that each piece of hardware has to be different because each has a separate key ingrained in hardware somewhere, which will be totally impractical to manufacture, /or/ that the key is stored in ROM, which, although it is harder, is still accessible.
/trust/ them. If I don't trust them, I can't give them something sensitive. Now, all sorts of "trust proxies" can be put in place, but it will eventually resolve to me trusting somebody. And the only secure endpoint is somebody's brain. So there will always need to be a brain-brain trust. Hardware and software just proxies it for us.
Also the hardware would have to entirely take over the CPU...this means the addition of a super-monitor level that can only be activated by hardware, over and above the software-level monitor state (kernel). If this is done, how is authentication achieved to allow the hardware to do this? Can any piece of hardware do this? If so, then the crypto hardware is compromised. If not, yet another scheme must be invented to authenticate the crypto hardware, which may lead back to manufacturing individual CPUs to recognize a certain key, which is again impractical.
If there is no hardware-level monitor, what is stopping a rogue kernel from just dumping memory?
I think this may end up a philosophical question. If I give somebody something, I must
Jazilla.org - the Java Mozilla
It's 10 PM. Do you know if you're un-American?
Go over to BotShop to keep up with the progress.
I'm looking to support every version of quake with my own net code for the AI.
1. The aimbot issue is irrelevant to a discussion of security for business purposes. For example, nobody who is selling products online will care if the order is placed manually or by a bot so long as the order and billing information are valid.
2. Selecting closed source or open source as your development method does not alter physical constraints; what Carmack and Raymond both say indicates that even if Quake had been developed as open source software it still would need to send some information in advance in order to attain acceptable speed.
3. A business application differs from a networked game. Everyone playing the game has access to both the client and server programs and can modify them, whereas a business has its server software on its own system where nobody can mess with it (unless they manage to break into that system), so even if the source code is widely available there is still a measure of security.
4. The consequences of breaking security on systems implementing commercial transactions are far more serious than those of someone cheating on a game.
So it seems to me that the analogy between games and online business muddies the waters rather than clarifying security issues. Mentioning issues unrelated to the main topic of discussion (see comment 1 above) adds to the confusion.
--- Brian
...is just something that has never worked, will never work, and cannot work. Every now and then someone tries to use it (the DVD Consortium for example), arguing that ``yes, in general security through obfuscation is bad, but in this particular case it will work''; wrongo: it always fails.
This is made abundantly clear in Bruce Schneier's famous book on cryptography.
This is not an open source vs. proprietary software problem, it is a disclosed source vs. obfuscation problem. This is not an ethical issue, it is a completely practical one, and it seems that the lesson needs to be learned one more time.
Carmack's suggested closed-source binary loader can be spoofed much more easily than by using a proxy. Indeed, it contains an obvious race condition: how is the loader to check that the program hasn't been altered between the time it is checksumed and the time it is run? A simple ptrace() should do the trick for that, and, in fact, anything invented along similar lines.
As another poster pointed out, what we need is to have Quake clients act as simple 2D rendering clients. But that means the server would have to perform all the 3D calculations and that is hopeless. We want the client to perform the calculations without being able to spoof them; so the problem amounts to the following:
(``Computing in `hostile environment' ''). You are given a powerful computer and you want to use it to perform a computation. However, you cannot trust the computer. You want to perform the computation in such a way that the computer should be (a) unable to fool you (i.e. give a wrong answer and make you think it is the right answer), and (b) unable to learn anything from the computation (in the Quake case, learn more than the final, 2D, result). The computer can refuse to carry out the computation, of course, and you cannot prevent this, but it cannot make you think it carried out the computation whereas in fact it is fooling you.
This is a purely theoretical problem, and it has been studied. A cryptologist told me (but was unable to give a reference, unfortunately) that the problem is solved in the theoretical sense: computation in hostile environment is possible (using strong crypto). This makes it theoretically possible to have a solution to the problem using just one secret key, stored on the server and everything else being disclosed (basically: the server sends the encrypted computation to the client, the client performs the computation without knowing what it is calculating, sends it back to the server, the server verifies that the computation was correctly carried out, and sends the decrypted result to the client). Unfortunately, this solution is completely unpractical (the bandwidth required is simply too large).
So, the Right Thing fails. IMHO, this is not, however, an excuse to do the Wrong Thing. If the problem has no solution, then the problem is not a problem!
I think you are right, that is what we will see eventually. But it won't be until the average person has cable, DSL, or some other high-bandwidth, low-latency connection to the net that it will be technically feasible.
But with the average player trapped behind a modem, the kind of tricks Carmack used are necessary for the game to be playable. ESR mentioned Carmack's reply in his article, but did not comment on it, and appeared to pass it off as unimportant because the design should have been "done right" in the first place. Obviously, ESR has never played Quake on a modem against players on low latency connections.
My other comment on the article was that there were no direct statement of ESR's point. From reading the comments here, it seems many people got entirely different meanings out of it. Pretty poorly written, IMHO.
Quake! http://lonestar.intcomm.net
Chat! http://openverse.org
-- OpenVerse Visual Chat: http://openverse.com
Interesting thing about coal, you put enough pressure on it for long enough, and you get diamonds.
I am heavily involved in e-commerce. ESR points are valid and well made. However, I think the issue can be taken into another venue which is not far from Quake: "The Art of War", Sun Tzu. Cheating is exactly what you want to achieve in a war using any means possible to achieve them: limited disclosure, deception, technology, etc. The issue is the same that ESR makes regarding open source; if you know all the cheating that goes on prior to, and in the midst of a battle, it ...changes the behavior of developers. Which may then change the game, because the rules (requirements) are no longer the same.
E-commerce communities must war/defend against any entity, hostile or otherwise, that would encroach on the territory established for commerce.
So many comments, so little time.....
"There is nothing new. Everything is just smaller, faster, and cheaper, with more layers of the protocol stack at no additional cost." csfenton
Guess what would happen if the windows source code suddenly became open? All kinds of cracks would appear. We've just proven it.
They open the source for Quake1, and within days, there's people out there playing cheat clients. It wouldn't take even hours for the world's windoze boxes to all be cracked if they opened the source code. Anyone depending on windoze would simply be out of business.
You can't go from 'security' through obscurity to open source. That is the main problem. All of this other stuff about the details of how people cheat when it happens are not the core issue. The core issue is that the development model cannot change from closed to open source without exposing all of the security flaws. Suddenly there are thousands of eyes looking at the code for weaknesses where before there were only dozens (who were mainly interested in functionality, not security. Why should they care; it's closed source?)
So, how do we fix it? We could develop games entirely open source. Who's going to pay for that? People don't buy support contracts for games; they rarely buy the manuals.
We could try to convince Carmack to release the code in stages. Release the server code first to get all of the bugs and cracks worked out. Then release the clients after most of the hacks have been anticipated. This is still suboptimal, with optimality being the unlikely open-source case. Anyone have any better ideas?
Yes, I know, there are plenty of open source projects. They usually only have a dozen developers at most. I doubt they would pass a security audit. I know most open source net games are crackable, I've done it myself.
Maybe in the future they will give the code a security audit before they release it. They're doing this as a publicity stunt anyway, they might as well get the most out of it.
you should the previous post ("No Stupid"), and then learn more about computers before you post your idiotic comments. maybe you've watched "Hackers" or "The Net" to much.
I know Tribes does not have its source code published under the GPL, but how does the Tribes engine work out the "who's the nearest player" information sent from the server to the client?
--
Jeff
I think there is esentially no real way to do that, if you want to run the software on a client's computer.....
if you run the software on your server, and display it on the client's computer, then its possible to protect the data from the client
hope thats somewhat helpful
Need a Catering Connection
This whole quake cheating thing is a non issue. People have been cheating in mutli-player games since day 1. Whether they've been closed source or open source. I remember people cheating in Doom for god's sake. But who cares? Everyone quickly learns who the cheaters are and refuses to play with them. Issue Resolved.
Whenever you play multi player games that let the clients decide the outcomes there will be cheating. Diablo was a good example of this. There were cheats that allowed you to kill a player while in town - something that wasn't supposed to happen. There were ways to create magical items that didn't exist. None of this mattered. Blizzard handled this easily by saying you shouldn't trust anyone. And it was so true. If you play with your friends you'll never have to deal with cheating anyways. If you want to play with random people then you need to learn to make friends and associations that will prevent cheaters from playing with you.
On the other hand, I hear Ultima online and Everquest are good code bases for cheatless systems. From what I understand the client only displays the world and allows users to send known commands back to the server which can be checked server side against the user's character which is only stored on the server and not allowed to be modified by the client.
Joseph Elwell.
Good point! Let's hear ESR's explanation of this. What's the difference between "obscurity" and "minimum disclosure"?
Criminalize spam and telemarketing!
One would think that, should the IP designer actually get hauled into court they'd be able to at least say "we built the chip and it worked", if not actually be able to prove that the client changed the design.
But there are problems that encryption, or any technology, can solve- if I can get it in plaintext at anypoint, I can break the encryption and change things to my hearts content (or copy things, as the record and movie companies are learning the hardway). Even hardware doesn't help- poke around on http://www.counterpane.com/ for some possibilities for breaking hardware-based encryption. Leaving the debug symbols in the code (or the unprotected keys, as happened with DVD recently) just makes the reverse engineer's job easier.
A suggestion for quake players: have reputation servers. This is not a perfect solution (can the reputation servers be hacked?), but it does give you a _social_ mechanism to discourage cheating. And it's the best you can do.
. . . is that programs that are designed with closed source or protocol as part of the security scheme aren't likely to hold up well (without major changes) once they're open sourced.
(Sorry if I double posted this, I suck)
'I ain't a liar, baby, and I ain't proud I just want what I'm not allowed.' -- Violent Femmes, 36-24-36
Also, if you miss a packet or two and that 'phantom' winds up visible, it would be really disorienting to the player using the current protocols.
The only really nice thing about this proposed partial fix is it could be done on a server with no client side changes.
Sanity is a sandbox. I prefer the swings.
A number of game development projects have been working at exactly this; it might be worthwhile for those interested in working on such a protocol to see what's already in the pipeline. Freetrek and Netspace both have just recently started development on 3D protocols for space-flight. WarForge, Phoenix, Lycadican, Cyphesis, and Belchfire are all using WorldForge's "Atlas" 3D RPG protocol (libatlas2 was just completed last week).
OpenSource security issues aside, it sounds like it would be very cool to play Quake against people who have hacked at the source code (as long as I have, too). The game would be "Who hacks the best Quake client?" rather than a simple shoot-em-up video game. It would certainly offer a new type of challenge.
Dave
http://www.chaos.umd.edu/~dsweet
There will always be people who can hack any game (quake, starcraft, diablo, us banking system). Given a reasonable amount of security (ie, more than any game out there, but not 100% secure), the number of people who can (and who actually will) undetectably hack the game is very small. Add to this that most talented hackers are also responsible hackers, and that they probably get a bigger kick out of making the hack than using the hack, and the problem is almost nonexistent. So what if a few people test out an aimbot in quake 9, or for that matter if they steal a few million from the banking system (hey, if they pull it off undetected, they deserve the $$).
The problem is not that these people hack the game, it's that they make their work available to everyone (further evidence that they are not interested in using the hack. If they want to benefit from it, why give it away to everyone??). The multitudes of people who download the hack and use it irresponsibly are the problem. The Diablo fiasco (bearing in mind that the diablo hack was *very* easy. However, had there been encryption and other safeguards, it would have been difficult enough that only a small percentage of people could have done it) illustrates this point. The problem wasn't that one guy hacked the game and got some gold, it was that the hack got distributed, and anyone download a patch and got free gold.
Anyway, the point to all this is that it is useless (and unnecessary) to stop hacking. With a *reasonable* amount of security, only a few people will be able to hack the game. Their impact on the game will be minimal. Instead, we need to go after the people that download the hacks. If we get rid of them, the problem goes away. So rather than waste time trying to make a hack proof system, we need to waste time trying to stop hack proliferation. So, how can we detect known hacks? And what do we do to the users? (easy on a persistent online game, just ban the account. What about games like sc and quake? blacklist? ban ip?)
http://go.to/aimbots/
They are proxies that sit between the closed-source client and the closed-source server.
Yeh, there seems to be aimbots for Quake 1, 2 and 3, plus QuakeWorld. (They seem to be for Wincrap, and if they are .exe distributions, as they probably are, they very probably carry a horde of viruses too...so I wouldn't recommend trying them out...)
I've been playing all the ID games, and done fairly well, EXCEPT in last year with the Quake2. For example, I am camping in the perfect place with my trigger-finger ready, and suddenly I'm blown to pieces with a railgun by someone whom I didn't even have time to see. Or I'm running, making evasive actions, and someone again blows me dead with a railgun from the other side of a hall. Repeatedly. And I can't hit almost anyone with the railgun. Maybe the Q2 players are just inhumanely good, I don't know. Also, some people run unnaturally fast (yeh, I've heard there's such a crack too).
I guess making "aimbot detectors" isn't possible. Once you know what the criteria are, you can make a bot that circumvents the criteria somehow, and makes the player look just like a f*king good player.
Nevertheless, I agree with the fact that closed-source software *slows down* finding obvious holes, and prevents it quite well if the application is such that no one bothers to crack it. But, if one can make megabucks of money with it, or get better score in a game, or get high status as a cracker, you can bet that it'll be cracked in a week...
..to point out somne real advantages of open source game protocols. Specifically, human evolution via improved computer interfaces! We should not be doiing things to discurage these ``cheats'' we should be doing things to incurage structuring and sharing them.
The aim-bots are a peerfect example of a good cheat.. as they consist of using a computer to improve a humans performance. Shure they take a little bit of the skill out of the game, but they give the human more time to think about stratagy and the importent things that only a human can do.
I am a great fan of StarCraft/WarCraft/CC/etc. but the truth is these games have crap for a user interface. Who wants to spend all their time commanding individual units to attack specific targets during the conflict. Yet, this is what the game rewards. The truth is the only way to fix these games is an easy to use scripting langauge.
Video games are a great oppertunity for human computer interactions research.. and the mechinism for this research is to write the tools to allow people to easily make the computer do more of the work. Scripts and bots are the pefect opertunity to help illiminate mindless repetitive action in video games and let us focus on the imprortent part of the game.. stratagy.
Jeff
BTW> I know some moron who only read the first paragraph ofthis post is going to reply about how unfair it is to be able to see arround corners in quake. Clearly, protocol based cheats like that are NOT what I am talking about here. I pretty much agree with ESR on protocol based cheats.. and I accept the possible need for blessed clients untill ping times are faster. It might even be reasonable to have blessed clients which shared your scripts with your opponent.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Closed source has the potential to be as hackable as open source, however on the average it is not.
Most people don't want to spend their time wading through assembly code to figure out what is going on in a game as complex as Quake.
That explains why this problem has just come to light.
I agree, over time an open source solution becomes pretty darn secure. However, by keeping source code closed, it makes it MUCH harder to hack it.
I guarantee you, the average hacker/programmer does not know assembly language, and as time goes on, and software/computers become more complex, they wont care to learn it either.
The problem with open source, is there will always be ways to hack/crack a system. I think it helps developers put security in the front of their mind, however it is not the end-all solution to security. It's a tradeoff.
Easier to hack vs. Developers increasing the priority of security issues.
Most cheaters won't mess around with their kernel. We can build security of some sort into the kernel, like a library function that checksums a file and sends that checksum, encrypted with public key encryption. This won't stop serious cheaters, but it will stop casual cheaters. It's still a completely open source solution.
Another possibility is the Net-trek like blessing system, with an auto-bless util, that allows servers to create clients that are blessed by them. The blessing would be done on a binary level, and would involve automatic obfusication:
shr eax, 8
becomes
ror eax, 8 and eax, 0xFFFFFF
This could become arbitrarily complex, and there would be a strong incentive for hackers (in the RMS sense) to try and create better obfusication algorithms. It would be a contest, but it just might be a contest that players could win.
-Dave Turner, AC of convinience
You should ask Bill Gates to unclench his buttocks, so you can pull your head out.
God, MS plants piss me off.
To quote Dilbert:
"Pressure makes garbage more compact!"
What about keeping the source for the game itself open source, but create a module in the source that handles encrypting and decrypting data sent back and forth between the server using an internally stored and signed key.
The admin of Quake server foo would compile thier server And Client using thier own pair of key pairs (one pair for upstream, one for down), and distribute said binaries on thier website.
Thus, to play quake on the foo server, you would need to foo quake binary, whose source is open, but whose key is not. Then the whole issue becomes one of convience (who wants to download 50 binaries for 50 diffrent servers?) and the strength of the encryption used. Of course, signed server binaries and clients wouldnt be limited to use on one server machine, quake world, for example, could with a reasonably sized encryption key, use the same binary for all of thier quake servers, and thus to play on any quake world server you would only need to make one download of the quake world client... of course, quake world could publish the source of thier client and server if they modified it, but they just wouldnt include thier key pairs in the source...
Thus, we mix the power of open source for the development process, and the power of public key encryption with internal signed keys, by using distributed binaries for actual play. of course, it could always be a compile option to use the encryption (it would slow things down) - but if you dont have the proper keys in your binary, you cant play on anyone`s server(s).
Of course, this also stops aim-bots, but it leaves several things that are hard to deal with:
- Server admins would need to either be able to make thier own binaries on all platforms they wanted to support (how many people actually have a linux box, a bsd, a win9x, a winNT, and a mac, all with compile tools just laying around?), or purchase/obtain pre-compiled binaries from a trusted source.
- Anyone who did have the tools, or only wanted to support one or two platforms, could compile cheats into thier own clients at the same time that they created the clients to be distributed to the public... or sell 'upgrades' to the standard clients that included the proper keys for thier server And cheats...
- Players would need to download several sets of binaries if they are active deathmatch players - wasting time and bandwith...
Anyone else have an idea that is a open source solution...???
man is machine
Distributed.net has a similar problem with keeping a hostile client from supplying
bad results. There solution is basically the same as Carmacks: keep some bits of the code private. Here is what they say:
Why is distributed.net still not completely open-source with all parts of its source code?
Doesn't this simply change the rules of the game? Where playing "fair" is simply a matter of trust (as it always has been in real life)? Now, the object, for example, would be to create DodgeBots or movement randomizers (ie the user moves normally, but the computer constantly computes an odd path) to combat the AimBots. Or checks to see if the shot is, for example, rail shot, then you are 200 health suddenly. Back in my Side/Side fighter days, there were all sorts of "ultimate fighting techniques" that some people would learn. A skilled person doing this would be considered in "bad form". So what. Ego was built on doing it in "good form". A real skilled person learned techniques to combat the "cheats". It's all part of the game. As for parallels to real world...the performance vs security issue is prime. You want security AND performance, you wait until the software can give you both and not rely on kludgy solutions (closed security, obfuscated protocols). The BeerBaron
Second, cheats really have to be divided into two types - breaking the rules of the game world, and providing additional assistance to the player. Quake is reasonably well protected against type-one cheats, because it's server-centric. Only type-one cheats are game-killers. It's worth noting, incidentally, that even if you have to make some key decisions like "did bullet hit player" in the client for latency reasons, you can check them in the server later and detect cheating without hurting latency. The TEN people (Total Entertainment Network, a defunct low-latency Internet for gamers killed by cheap bandwidth) did that. So type-one cheating is preventable, even in games more distributed than Quake. Look up the Byzantine generals problem for a theoretical analysis.
Quake's particular problem is that some information known to the client is supposed to be hidden from the player. The client needs that data before the player does for latency reasons. So a type-one cheat the involves "peeking" at client data is possible. There's no obvious technical solution to this problem, and it impacts game design. One solution is to provide a "scanner" window to all players showing the hidden information. This changes the game, but puts all players on an even footing.
Third, trying to prevent all type-two cheats is fundamentally hopeless. Even if the game server sent out video streams, a screen-scraper and image-processing program, like Agre's classic Pengi (which played Pengo) could act as an aiming 'bot. So you can't keep a good 'bot down.
Fourth, only in recreational software is type-two cheating an issue; no one objects if I have massive computer power helping me on eTrade. So this is strictly a gamer issue; it doesn't affect E-commerce.
So the problems raised by open-source Quake can, with difficulty, be solved, and the issue doesn't affect non-game open-source software.
Even Carmack's comments are predicated on yet another assumption - an environment of primarily statically loaded entities. Even through the use of extensive preprocessing and highly efficient resource management, it can take hundreds (or thousands) of milliseconds to load and initialize geometry before it comes into view. Quake can avoid this with small level size, low entity count, large memory footprint, local large disk or CD cache, and long level setup time.
If VR applications are to move past the common set of constraints Quake imposes (which are completely acceptable for its genre of gameplay), then more issues are introduced.
Very large worlds running across many distributed servers, clients utilizing continuous level of detail and realtime streaming preloading make it possible to wander around infinite sized worlds and never have to wait for a "loading" screen to interrupt the "suspension of disbeleif" so important in games. ESR's simple "fix" breaks this.
If you want to prevent information cheating, you have code at the servers which examine user actions and determine if they appear to be acting on more information than they should have according to the game policies and the distributed master clock. This works for people shooting at targets on their way around corners, as well as aim bots. Simple heuristics can filter out false positives, such as lucky shots.
Use digital certificates for robust user authentication with a difficult to automate "create new user" system and you've raised the price for cheating. Cheaters can be locked out, or even better, placed into games with each other seperate from the non-cheating players.
I agree that Open Source is the way to go - security by obscurity is why most systems calling themselves "secure" are laughable to those who work in the field. But it is not a magic bullet.
ESR's lessons: (a)Never trust a client program to be honest - This is absolutely correct, and I'd add that servers shouldn't be trusted to be honest either - clients should watch servers, and servers should watch each other.
(b) you can't have real security if you trade it away to get performance, - I agree with this truism.
(c) real security comes not from obscurity but from minimum disclosure, No, real security also comes from protecting information and actively monitoring for compromises. Minimum disclosure only works in a small subset of security models. If I hide a spreadsheet column that is too sensitive, and that column is needed, then no work will get done with that spreadsheet even if the client is open source.
(d) only open source can force designers to use provably secure methods. I hate to berate open source, but I must, as this comment is the pulpit speaking. I would argue that "peer review" has worked just fine in many situations - the NSA has done quite well providing strong ciphers for its clients (by this I mean the ones it cares about actually protecting) without open source. Open source is a superset of classical "peer review" in this regards.
There are some interesting lessons in this source base release. I hate to see them abused as a pulpit for incorrect information, especially when it hits near home (I run an open source massively distributed VR project).
If anyone wants to learn more about the few hundred other cool technical problems in online VR, a recent book ("Networked Virtual Environments" ISBN 0-201-325577-8) provides a great overview, its the first I've seen that was written by people who knew what they were talking about.
I'm sorry if I sound näive, but if it's such a problem, why not rewrite the source for the server and the client in order to eliminate the possibility of this problem occuring, then posting the binary for both win32 and linux clients, and eliminate the possibility of older clients from connecting. If it's open source it can be changed and fixed.
Stupid is as stupid dies.
Put down the crackpipe - just because someone is pro-MS on a particular topic does not make them a "plant". Lay off the X-files for a while, huh?
Well, it becuase people who play the game simply download the latest version of their favourite port and play it. If they don't like it, they go get another port.
And if they want to develop Doom further, they either join a source-port project that exists already, or use, one as a code base. If their port lets them cheat, it won't get hosted on the large Doom sites (like Doomworld). Sure, people can still find and use cheatable versions, and make DoomServ clients for it, but why go to that much work so that you can beat people at a game? People who you don't even know? And especially, people who will notcie within the first 5 minutes of gameplay that you aren't getting hurt by their rockets and you can fly.
Conclusion: People should start "source port" (please come up with a better name) projects, and define strict sets of rules for your projects. Client side cheating will Always be possible simply becuase of the way the game works. But if people simply download an open-source client and use it, without modifying it, we should be fine.
I think I've said just about everything.
Note: most, if not all, of these "source ports" are open-source and probably GPL'd. Lots of them have Linux versions, too. Go get some! Doom is a great game... and you haven't played it till you've played DoomGL with the Eternal Doom levels (get them at TeamTNT).
I think the first problem can be solved by encrypting non-visible data on the server site before sending it to the client. When it become visible server just can send a key to the client.
Second problem can be solved on the server site by allowing client to disapear for the couple of seconds or possibility to ask a server to produce a large number of triangles covering player. It will makes this auto-targering much more difficult to implement.
Server can also produce more dynamic environment (moving walls, doors, elevators and so on...) plus do not give client enouth information about objects in the shadow preventing from possibility to distinguish monsters, human friends and human enemies.
ESR is viewing life through increasingly narrow blinders these days. The real problem is *security design*. When you design a protocol, you must have in mind a particular threat model and some cost factors. When Quake was designed, single-player single-machine play was what was in mind. QuakeWorld hacked in network support, but security was obviously not a huge priority -- it's a *game* not a *bank*, for pete's sake -- so just enough protection was added to keep 99% of the script kiddies from cheating. Besides, there were some major performance constraints on the hardware; anything else would have been overkill given the threat model.
*OBVIOUSLY* open source brings with it a different threat model, a stricter and tighter one. The quake situation just proves that it is *very difficult* to retrofit security into a design. The protocol must be designed from the get-go with your security goals in mind. (I will hand-wave at the 'Jabber' open source chat client as another example of a protocol that was designed without security in mind. 'Open source' has little to do with it.)
The standard for e-commerce apps should be set much higher than that for a first-person shooter like quake, and I agree with ESR that "security through obscurity" should *never* be considered adequate when Real Money is on the line. But there are many ways other than full source disclosure to banish security through obscurity: open standards, for example, or publishing full details on wire protocols. I don't necessarily need to give out my implementation to promote confidence in my design, and indeed, if my design is truely secure, details of the protocol should be all that is required to convince me of the fact. [Note that in some cases -- for example, NIST's digital signature standard -- there are subtle protocol insecurities that might prompt me to take a look at the implementation to ensure that these gaps aren't exposed in practice; but in most cases protocol details are enough.]
The bottom-line is: computing with insecure clients *is* possible, as are "dumb client" approaches which concentrate the security in the server. Perhaps neither of these are applicable to the tight performance constraints of networked gaming. That simply means that the client *must* be trusted in some way -- which means we need to integrate authentication capabilities and Web Of Trust stuff like, say, PGP has to implement that trust. This has very little to do with "Open Source", littler still to do with Free Software, and everything to do with practical security engineering. Bruce Schneier would be qualified to comment on the issues. ESR is not.
[
I guess the money making argument is similar to Microsoft Open Sourcing their code and then feeling they are unable to sell their product because too many people would 'pirate' their software. I dunno, what do you think?
I also don't like the tone ESR takes on id, scolding him for releasing the game as it is, and chastising him for the design decisions he made. He did what needed to be done, and may have made compromises for performance. That is how game engine creators squeeze more fps and features out of a computer, by making compromises. It is design and use of the compromise that makes engine designers the game gods they are. I'm sure if Carmack were designing firewalls his compromises would have been different.
id released the source in good faith to the Open Source community because they have made their money and gotten the recognition they desired. They have given us the source code to a great game as a gift. Be thankful, instead of a jerk...
/ k.d / earth trickle / Monkeys vs. Robots Films /
Large print giveth, and the small print taketh away
1024x768, 32bit color, 60fps.. (By the time this is feasible, you can expect MUCH higher resolutions and frame-rates than this.)
Since I wouldn't tolerate any lossy compression on my Quake3 video signal, that requires 1440Mbits/sec. That's 960 T1s per user.. For a decent game of CTF, the server would have to be a large cluster of powerful workstations, and have more bandwidth than the entire east coast of the U.S.
And, there's the problem. An untrustable system being expected to run a trusted program. It's theoretically impossible, even given perfect implementation.
If they want this to work, they'd need to sell black-box PCs, which exist for this purpose only, and can be passed an encrypted file, decrypt it, check for bugs, and return a 'yes' or 'error in area x,y'...
The system doesn't need to be, and in fact, shouldn't be, closed source.
It just has to be designed in such a way that any tampering with it will render it unoperable before it's opened to the point where data can be read off of it. Nothing is 100%, so they'd need to set a target budget, like the model that is simply encased in black plastic is rated to take $100k to break, the model shipped in plastic, in a safe, guarded by the marines, is estimate to take $5M to break, etc.
But the machine can't be modifiable by anyone 'untrusted' at any point. All modification need to be done by the trusted vendor of the product, who one expects to be bonded and insured, etc etc..
Only then can trusted programs be run on the system and be expected to be safe.
Since no one seems to really know netrek's anti-borg system works, I'll put it down in detail.
When a new client binary is created, the person compiling it makes a public/secret RSA key pair. The public key is sent to the keyserver (Carlos V), while the secret key is compiled into the client. The code to create these keys, as well as the client/server (they are the same) routines to do RSA aren't in the client or server source. This is because of export restrictions. Anyone can download the RSA source from a certain FTP server in Europe, which is what I did when I released my netrek client. The RSA source isn't widely distributed, but there isn't anything closed about it. The only thing secret is the secret key, which only the person compiling the client knows.
After the client connects to the server, the server sends a cookie of random data to the client. The client sticks the IP address of the _server_ (via getpeername()) in front of the cookie, and encrypts it with the secret RSA key inside the client. The server gets the response, and if it decrypts properly with the client's public key, the client is allowed.
There are several weak points to this method. The most obvious, but not the easiest, is to somehow extract the secret key from the client. This was how DVD was cracked, by extracting a secret key from the Xing player. The secret key isn't actually in the client as raw data, rather C code is generated that performs the operations needed to do the RSA encryption with the key. With the C code in front of me, it's not trivial to tell what the key is, figuring it out from the compiled code would be very difficult indeed.
Another weak point is binary hacks. The client does NOT perform a binary hash (checksum, CRC, md5, etc.) of any kind, so you can take a hex editor to it at will. There really is no way to stop this; if you put in a checksum, someone can just hack the checksum code. With the complexity of programs like netrek and quake, adding new features with a hex editor is a difficult task. Not as easy as fiddling a few bytes on console systems with a game genie or the like. Netrek does all game mechanics in the server, so "no damage", "infinite ammo", "shoot through walls", cheats just aren't possible.
The easiest way to get around this system is a man in the middle attack. You have a real client connect to server via your cheat proxy. The proxy understands the game protocol, and can cheat in a number of ways. For instance, it could allow the normal client to connect to the server and authenticate isself, then pass control over to a fake client. Netrek trys to make this hard by putting the IP address of the server inside the cookie. If the real client thinks the server is at 127.0.0.1 put the server is really at 1.2.3.4, the RSA response will be bad. You can get around this with a dynamic library hack to getpeername() or a kernel level hack for static binaries. Or have a tranparent proxy that can intercept packets.
I think what we have here is a case of people bitching about cheating. In contrast to actual cheating, which I doubt in the case of the release of the quake 1 code is really widespread problem.
Cheating is a lot less of problem than people think.
Yes, aimbots exist. Yes, hacks of various sorts exist for quakeworld. However, there also exists people with seemingly inhuman skill.
Open forum, in depth bitch-fests about the 'problem' of cheating based on unsubstantiated fluff really just creates more problems then it solves. This is because it creates fodder for accusations and finger pointing when someone feels that the only way said player can beat them is by cheating.
Some people have this mentality that one can not reach a certain skill level without using cheats of various sorts. Anyone who was any good at quake has run into situations of being accused of cheating at various times.
What happens is that as soon as someone discovers that people can cheat the first thought that enters their mind when they are getting beaten is "that person is cheating".
'People cheat' is just a lame excuse. I remember one occasion of being accused of somehow 'cheating' in quake 3. My lightning gun was 'too good'. Basically what that comes down to is ego motivated whining and pouting.
I've come across a number of hacks and bots for quakeworld and for the most part, the map and model hacks don't help a whole lot, and someone using a bot is pretty obvious. There is always resorting to specing someone you think is cheating or asking them for a demo, etc... And this is really moot anyway because everyone should understand that very few people cheat and chances are that if some guy is ass kicking your ass, he's just kicking your ass.
Some of us have been playing FPSs for a long time and derive some sort of satisfaction from actually being good, without any help at all. And considering that really the only reward to playing is self satisfaction I don't think cheating will ever be a huge problem. I can think of one very amusing occasion where a fairly well know player was being beaten badly by someone who was using a bot. But that person was using the bot for the comic value and it _was_ very funny. Other then that bots get boring pretty darn quick. I mean running around pressing a button while the computer aims for you isn't exactly fun, and it only help for some weapons anyway.
In any case, if the middle echelons of mediocre quakers think that everyone who is good must cheat then the danger is that those people will start cheating under the premise that they believe that they are leveling the playing field. So really what all you people should do stop your lame hypothetical speculation on how it may be possible to cheat when having no proof of particular individuals cheating at all.
Assuming you work (or worked) in IT, you've probably gotten a bogus request from sombody who means well, but dosen't understand current capabilities. They want to print metal foil with their inkjet printer, but they don't want to buy a new printer, or they want you to make it so that somebody can read a database but not write to it, when it's a flat file format accessed with a closed source client.... and do it now, before they get back from lunch.
Both of these can be addressed given enough money (in the first case) or time (in the second case), but a condition of doing each is that you don't have the time or money.
I'm not familiar with Quake code beyond what appeared in this forum, but it seems that the problem could easily be solved just by requiring each player to be on a LAN or have a T1 minimum.
Simple solution, eh?...
But it won't work - because I don't think *anyone* is willing to pay for a T1 just so they can play Quake. So you have to adjust the paramaters... but Quake can't be coded to be a fun, responsive game without enough low-latency bandwidth.
PHB says: "I don't care. Make it work over a 33.6 modem connection with security".
Smart coder says: "You can have server-side security, or make it work over a 33.6 modem, but not both".
Guru coder states the solution: "I can make it fun for 33.6 users, and make it step up to a secure connection for people with less than 120ms ping times. Ask Carl in the art department for two little icon that tell the user if they are running a cheat-proof game or not, and tell Emily in docs that she's going to have to figure out how to explain this 'feature' to the users".
The problem is there if it is open source or not (although the solution is easier to find if you have 13,000 people thinking about it)... the problem is in the specs and assumptions.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Your point is that there are applications that can never be implemented. To a determined hacker obscurity only delays the inevitable. I CAN reverse a binary.
Seriously. Read the whole post before you hit the keyboard. Of course closed source is hackable. But not by an Joe who just fell off the turnip truck. Open Source on the other hand.....
Geeess. open souce - Give 'em a map and then get pissed that they found a way...
Yes, I am an MS plant. Gees. A bit too much of the x-files there crackhead.
Mmmm. Why is it that Open Source/Linux advocates loose creadibility. Oh yes, it's because they open their mouths..
If you have an arguement fine, but otherwise shutup.
The client needs to have a checksum checker or something, right? And the client can't be given the opportunity to checksum itself, but it must be done by a closed-source binary code, right? Ok...
Solution: the server generates the executable that checks the client, encrypts it, and sends it to the client. The checker decrypts itself, checks the client, and sends a secured message back to the server. This could happen in perhaps one to ten seconds, so the client isn't really able to fuss much with the checker. And the checker's source would be open.
This is just a quick thought, so I'm not really sure if this would work or be secure. But perhaps it could be a starting point for a solution.
The idea is that, if "closed source" is evil, why let evil people code it? Why not make a code-generator (for example with encryption) that is open-source, but generates closed-source code.
But, this solution of course brings another security problem: the "checker" could be a troyan. Thus, it has to run in a virtual machine. I'm not sure what kind of code this "Quake C" generates, but if it's opcode runnable in a VM, then the checker could be safe in that way.
(Another solution to the troyan might be using trusted Quake signature servers. Safe as long as the trusted servers really are safe...)
But, perhaps the client could have a hacked VM and let the checker see wrong code segment, and actually run on another. This gets very complicated now, and I'm not any longer at all sure if this can be solved. *shrug*
Or perhaps the checker could run all the time. Perhaps it could copy the client into a data segment, and require it to run from there, and make some modifications to it. Perhaps it could fulfill some crucial function in the communication that can't be circumvented (such as encryption). Or download the entire client... OR SOMETHING!
Why not use binary builds of the executable files digitally signed by the builders, and have the servers check the signatures against a trusted certifying authority?
Someone suggested this in the first article, and it still seems like a sensible solution. You can muck around in the source code all you want, even enhance it -- but when it comes time to play, the server enforces a standard set of binaries to play on.
If someone comes up with a serious gee-whiz enhancement, s/he releases the source, but also a binary patch to a "reputable" build. Hopefully, s/he also sends the patch (as source) to the project issuing the build, so it can be rolled into their project.
There are a few technical issues left open -- building a binary from which to divine a patch seems challenging, for instance. But pirates and trainer-builders have been doing this sort of thing for years.
Opening the source doesn't mean everyone gcc's their own copy of the game. Use this encryption thing we talk about so often on here, and only play using trusted binaries. It should solve things to everyone's satisfaction.
phil
Wouldn't ranked play (aprox. equally matched opponents) solve the problem? You'd need a centralized server to hold rankings for each CD-key. If someone cheats they get bumped up to a higher rank until they no longer have an advantage. The very top rank might be called Bot Hell. :) The only way for a cheater to reset their rank is to buy another copy of the game (which helps other players a little by funding the next version).
So, how do we fix it? We could develop games entirely open source. Who's going to pay for that? People don't buy support contracts for games; they rarely buy the manuals.
How about differentiating between the Engine and the Game? The engine should be open but the game's content (graphics, sounds, etc.) could be paid for! The engine itself is small compared to the rest, it could be easily downloaded, but if the contents are huge (bigger than a DVD) it's well worth buying it. The engine would be like the Operating System, definitely Open Source, and the contents could be free or proprietary. This would give open source developers an advantage, a free engine, a great toy. And the engine itself, improved by hackers world-wide, would benefit the content producers and game creators as well. A Win:Win situation...
-- Eavy (: Linux Is Not UniX
What is to stop someone from simply writing a kernel module to pretend that it has this 'mythical' piece of hardware?
Plain and simple, if your computer can read data well enough to do something with it, you can read & copy it. This is an old maxim of computing, goes at least back to the Apple ][ days, and it's still just as true. As in your example, closing the source does not make the system any more secure in the long run, someone motivated enough can figure out how to read it, copy it, whatever they want to do with it. There is no way to safely send a customer something that their computer will be able to read but not the customer.
The answer for companies who want to give customers this sort of access is simple, don't send it. Improvements in network bandwidth allow the vendor to set up a black box on the internet. Customers would be able to log on to the black box, and access the simulation with no access to the data used to create the simulation. They just will see the interface.
----
----
Open mind, insert foot.
Guess what would happen if the windows source code suddenly became open? All kinds of cracks would appear. We've just proven it.
This might start to sound like flamebair but I don't particularly think this is a Bad Thing(tm).
There is no shortage of Windows cracks/hacks/"security" subversions/DoS attack programs, etc as it is now, a few million more wouldn't hurt so bad, MS would just sell everyone a service pack for $59.95.
More people might wake up to how crappy MS software is and demand better instead of just putting up with it as they seem to be.
Not to mention it might force MS to write better code in the future, but I doubt it. I mean think about it for a second, if MS coded the best OS in the world now, free of bugs, rock solid stable, secure as the US Federal Reserves in NYC, what would they sell next? Its part of the corporate business model to make sure they still have a product later, something Open Source doesn't suffer from.
It'd be a huge wake up call, thats for sure. Something MS desperately needs if you ask me.
-- iCEBaLM
Did you really expect to just plonk a dedicated quake server on your computer and have it automatically prevent cheating and other nasty stuff?
What this situation really needs are, like in the MUD world, active server deities or wizards. When a confirmed cheater is found, normal players just rat about him/her to the wizard, maybe vote to temporarily ban him, and the wizard can banish people permanently if that is really needed. Possibly add a mandatory registration with the server to be able to play, which will probably cut down on the amount of cheaters by itself.
Of course, the cheaters could just re-register after having their score table zeroed out or removed altogether, but that kind of thing can be reduced by setting a "waiting period" before the registration becomes effective, for certain IP ranges. How patient is the average power-hungry script kiddie? Probably less patient than the server owner, who can keep increasing the waiting period until the kiddie in question loses interest. If nothing else, this will at least let the honest players keep slaughtering each other until the kiddy returns.
If you ask me, the problem of power-hungry script kiddies can't be solved effectively with technology alone. More power to the $DEITIES, on the other hand...
taniwha wrote:
really my point I think that there are classes of applications that can't be addressed by Open Source at all
This application cannot safely be addressed by Closed Source software easier, as in the orignal example. It is impossible to make something secure from the user, but accessible to the user's local CPU. The only safe solution is to never give the information to the local machine at all. This solution will work at least as well with Open Source software as it will with Closed.
Never fall into the fallacy that Closed Source software allows Security through Obscurity to work, it never will work in a security critical environment.
----
----
Open mind, insert foot.
Especially when it comes to aim-bots, it's difficult to guarantee that a player isn't cheating. Statistical analysis might be useful for finding suspicious patterns, but any detection can be spoofed, and truly skilled players might look like aim-bots. (However, a real player might have more realistic hit accuracy and standard deviations -- if the accuracy is too consistent, this may be suspicious.)
The real solution, of course, is community. If honest players refuse to play with cheaters, then the cheaters can't ruin the game. Authentication of players would be necessary, and a community could have procedures to eject cheaters when identified. Calculated statistics from the server could help to identify suspects, and leave it to the community to ascertain whether the suspect is a cheater or a highly-skilled player.
Chances are that highly-skilled players won't be easily ejected as cheaters, and there's always the possibility of such a player proving his/her skill by playing in the physical presence of a trusted community member using a trusted client...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Before there was open source, there was closed source software which the cheaters cracked. Now that the source is open there are more cheaters. But since the source is open, the cheaters really aren't cheating.
Who cares about cheating? The gaming industry cares about cheating. JC must be feelin' awfully bad about this one. Who cares about cheating? Games developers care about cheating. Who'll want to play their games if it's so easy to cheat. Once upon a time, games were about skill and good sportsmanship. Now games, including athletic ones, are about drugs that give you a competitive advantage. Or, in this case, how many ways you can alter the source to give you a competitive advantage. The world has gone totally to pot!
And, yes, highly talented people, many who don't "fit in" in conventional environments, the talented ones like JC actually find a niche and make their living by creating games. I'm sure most of the people who've posted on slashdot, as well as most of the people who are open source developers have attempted at least a time or two to make a game. Did the game become popular and take them out of their humdrum lives. NO! It takes a special person, it takes a team, that is market-driven to make great computer games. It takes innovation. And, there's no innovation in open source, only duplication.
Yes, it would. Bandwidth is definitely the limiting factor, and in fact is the reason Carmack went with the "insecure" design.
:-). And if that's the case, a pair of 400kb/s just might do it.
Something like streaming MPEG can probably cut the bandwidth by a factor of 100 without any notificable effects. Only 9.6 T1s per user then
Not that far off, when you think about it.
There is an extra cost beyond the price of making lots of black box PCs, and convincing all your possible customers to put up with the inconvenience.
:)
While you're doing it, your competitor sends out his unprotected design for zero cost, the customers review it on their generic PCs, and Mr. Paranoid gets locked out of the market. What will your VC think of that business plan.
I'm cool like a fool in a swimming p-p-pfft-pool
This is the only solution. As long as people keep playing games with the source code, they'll be cheating and abuse. Everyone knows that computers games cause violent impulsive and irrational behavior. And, now we're seeing how open source promotes dishonest behavior. This concerns me. Why can't people stop playing games, and start playing the games honestly.
The private key, of course. No ticky, no shirty
Yeah you! Use those points.
I agree about the possibility of splash damage to somene who "accidentally" hit one of the phantoms, but that's why you'd only place them "just" behind the person so they couldn't hit them - no other players would have that phantom sent to their client so it wouldn't matter. The only problem then would be it might act as a shield, at least as far as the client was concerned - but I had thought that the two clients told the server if someone got hit, and it would decide the final outcome (or it might not work that way at all!! I make no claims to having looked over the code). I am agreed that perhaps placing a phantom right behind the user might have too many issues to work out, but it is only one of many pssible placements.
As for the transparent skins being detected by the bots and worked around - perhaps that would be possible, but if you threw enough variable ways that could happen (phantoms just behind a pillar, phantoms embedded in a window, normal skinned phantoms in a pit of lava, phantoms with "preditor" skins of the wall benhind them [perminent invisibility], etc.) that it might make it very hard to write an AutoBot client - or at least a client that wouldn't have enough direct hits on phantoms to trigger the server that something was amiss (I agree that accidentaly firing a shot at a few of the phantoms shouldn't trigger a cheat detector).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Make Q1 non-free again, just like the GNUstep icons.
Wha...a GNU project non-free? Nah....
Stating on Slashdot that I like cheese since 1997.
He wasn't moderated up. His web client is cheating! :D
*groan*
Closed source is no better. The end user can allways run the closed source on a fast emulator that logs everything the software does. That can also be done in hardware. Back in the Apple ][ days, a cracker's favorite tool was a 'bus rider' which could dump a log ef everything it saw on the bus. From that, it was just a matter of following the thread of execution, and dumping out a binary image of the loaded software.
Later software got a little more cleaver, but never got to the point of actually making copying impossable. Given the nature of the problem, it never will. Any process environment can be simulated.
Yet more irrelevant bilge gushes forth from the mouth of the self-appointed prophet of the Church of Opensourceology. Nobody cares about the blindingly obvious implications of the Quake problem in the world of e-commerce -- no similar problems exist in that area. The issue is cheating in Quake, and ESR, despite all his words, has spectacularly failed to address that. The conclusion stands: a closed source program is the only useful countermeasure.
ESR states 'If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered'. Roughly translated, this says 'If Quake had been designed to be open-source from the beginning, it would have been unplayable over the Internet for the majority of users'. Great - a triumph for OSS, then. What a talented advocate Mr Raymond is.
If Eric Raymond had ever written anything more challenging than a mail forwarding utility, maybe he'd have something worthwhile to say about this issue. Of course he hasn't, but having little of value to say hasn't stopped him holding forth in the past, so why would he stop now? When your life is devoted to spouting dogmatic drivel about programming, rather than actually doing any real programming, can you really be expected to know what you're talking about?
>> (Any computer game at which computers are better than most humans has analogous cheats, some of which aren't even detectable in principle. Carmack observes "correspondence chess has been subverted from its original intent by players using computers." This isn't something security design can fix.) << This comment touches on what's really the most important thing to think about in playing games online or off, which is, do you trust your opponents? People cheat at Quake and at correspondence chess the same way they cheat at poker. Coding an aim bot is no different than hiding an ace up your sleeve, and when you play against dishonest opponents, you should expect either. The ultimate solution is not to try to force players not to cheat, but simply for honest players not to play against cheaters. Then the cheaters can play against the other cheaters, and see how they like it.
[We Have No Product] [The Swindle
Here's my go at a solution that leaves everything open-source:
The basic premise is that the server would compile (and download) a unique "client binary" for each user that wishses to play (as they join)...that client would be signed and incorporate semi-random events like: "send me the magic number after every 4th frag" and the client would be time-limited (would expire/not be serviced by the server at the end of every map, etc)
Yes, it's not completely secure, but assuming you have enough bandwidth and CPU power to compile and download such clients, it would make hacking such clients pointless.
It seems to me the nature & quickness of a game of Quake and an online e-transaction represent the same kind of thing.....by forcing the hostile client to download a new "client executable" every time they want to play/pay and embedding checks within it along with tight time limitations, you can pretty much solve the problem and leave the baseline code open source....yes, the server ops will have their "secret code" they never disclose....and this leads to the question of trusting the server ops....
Which can be solved by taking the model one level up....the server ops create their server source with their own flavor of client security and then they submit them to a trusted organization (id software). Id inspects the code (to be sure there are no server-side cheats built-in) and then their system compiles the server code (with a similar kind of signing/magic number checks like the client code) and ships it to the server ops just like the server ships clients to the users....with embedded checks and time-limitations.
At that point, you could log onto id's site and view the "server list" and see which servers are currently authenticated. People could still run "unauthenticated" servers but you would be taking your chances if you played on them.
Doesn't this seem workable? (well, maybe in a few years when bandwidth is a bit wider for everyone, but, hey, it's viable under the right conditions isn't it?)
The point being that the "client" changes after every map/transaction and by the time you hack the client, the game/transaction is over/voided making the hacking effort moot. Yes, server ops would have to change their client "security" often so that people couldn't analyze previously downloaded clients and build cracks for them, but with sufficient randomness built into the client binaries, I think you could nearly eliminate the cheating problem...and leave everything open source.
I have said a couple of stupid thing in my time. Fortunatly, during my 'newbie' computer period (1982) Everybody in the community would tell why something wouldn't/didn't work they I thought it should.But now, everytime you post something anywhere, a bunch of jackass's have to tell you how stupid you are.
I feel sorry for kids entering the field now. I can't imagine become interested in a community that is becoming as hostile as this one.
I think a large aspect of this, which does actually go back to Mr. Raymond's comment on trading performance for security, is that Netrek is designed in such a way that all the game logic is stored on the server. The client only displays what the server offers it, no additional information is available for it's use.
:)
:)
Essentially, even though the Netrek clients have been blessed and trusted in some manner, in reality they aren't trusted at all. The server does not provide sufficient ability to the client to even allow it to cheat.
What we regard as cheating in the Netrek community is using computer based crutches to supplement your lack of skill. That could be auto-aim, or displaying cloaked ships, etc.
This game architecture obviously came about due to the open source nature of the game.
It's rare that I actually agree with Eric Raymond on anything, so I think this must be an amazing realignment of the planets and stars.
But as someone else pointed out in another article, the computerized players are not much better than the best human players, and in many aspects of the game are worse.
And this my friends is an example of why Netrek is a superior game to Quake.
Seriously, Netrek has depth to the game, it's not just about who has the fastest trigger finger. In some cases not firing at an opponent is a smart move, and a large part of learning the game is understanding such strategies.
We call it 'clue'.
Quake was designed and implemented by experts in the feild. Surely if they had even considered security to that extent, they would have seen the holes. Fact is, even if it was open sourced from the beginning...how likely is it that people would have thought of these holes when several *experts* did not?
Fact is, its just a fucking game. Who, in designing a game, is going to sit there and think of all the ways an assmonkey could possibly cheat? Its supposed to be fun for the person playing, so if they enjoy cheating....fuck it, let em. Isn't that why so many games are built with cheats included??
At any rate, I think it is likely that had those holes been seen by someone who was looking at the opensourced code, it is a high probability they would have been ignored. The cost to filling them would outway the playability...which is the highest priority in game design, not security.
If your building some sort of money exchanging program, of course you are going to plug all holes, no matter what the cost in bandwidth is. But for a game, common, this isn't fort nox here, and shouldn't be.
In my oppinion, it would not have mattered in the slightest.
jik-
Why don't they let you take bots into quake? The same reason they don't let you drive cars in a marathon. The thing is, Quake is not a real world application, but a game. Letting someone use a bot in quake is like letting them take a machete into a boxing ring... it's just not right. On the other hand, I would like to see a mod or recompilation that lets you do this. It sounds like a good idea, but I don't want unwary players to be subjected to it.
Have a look at the X Client Server relationship. The Client Software (Actually the X Server) runs in a high res graphics mode, and cannot do anything on the server that the server doesn't allow it to do.
Also look at PGP. Open Sourced code, running on untrusted PC's with Untrusted email clients, yet trusted to be secure.
I'm not saying these apply directly to quake, but it suggests to me that the problem is not unsolvable.
As a programmer, I understand the difficulty, if not impossibility, of finding a techical solution to this problem.
However, I don't feel a techical solution is needed. I think making some servers "Cheat Servers" will solve the majority of the problem. As a programmer, I like the idea of making a "cyborg" client which is a combination bot + user. I think I could add a new aspect to the game. If you were to use these clients on a normal server, you would be cheating. If, instead, you have "Cheat Servers" where this kind of play is accepted, then there is no longer a problem.
Admittedly, there will people who cheat on the normal servers, but that's why you have "kick." Most people will play by the rules.
Just my $0.02,
- Sam
As we all know, nearly all encryption works with hard algorithms -- something that takes a prohibitively long time to break. But people somehow think that "prohibitively" must mean a thousand years or something. I think this is because people become too narrowly focused on certain kinds of security. Quake doesn't matter that much. Cheating on Quake won't make anyone rich, and the feeling of power you might get is pretty pathetic really.
All the security in Quake has to stand up to is a few years of not very hard attempts to break it. That is, in a few years Quake won't be so exciting and people won't care too much, and until then cracking Quake can only be a hobby anyway. Foreign operatives and the NSA couldn't give a damn.
In this situation security through obscurity is enough. And it has worked fairly well up to now -- not perfectly, but well enough. It might not have been as hard to disassemble Quake or make a proxie as it would be to break a key, but it has been hard enough.
ESR is being dumb when he says that client caching is bad. He's being a total blockhead. Quake isn't an eCommerce application. It's a game. Speed and quality of play are the most important aspects, not security. And when the two conflicted, quality of play won -- as it should have.
Capability-based security is what you need.
See Eros. It's GPL'd.
Unfortunately open source games are not ideal from a gamer's point of view. The arguments of open source possibly improving quality and decreasing development time do not hold up against how easier it becomes to cheat -- and that's what gamers care more about, when it comes to multiplayer.
Seeing an opponent around the corner through cheating indeed could be eliminated, with a performance hit. This would have (probably) been done if the game had its sources available from the beginning, but...
Other cheats would not be detectable. The idea of detecting auto-aimers is truly ludicrous. With all the variable lag added in, the uncertainty grows to unacceptable levels. There is not a way to 100% be sure that a person is cheating via auto-aiming. I believe that it would be incorrect 75% of the time, with good players it would be incorrect all of the time. The idea shouldn't even be argued over -- simply not feasible.
If a method of attempting to detect autoaimers was developed then the auto-aiming cheaters would simply add in a few more milliseconds before they targeted the enemy. This wouldn't be detectable at all, certainly not with the variable lag added in, and cheaters could go even farther by adding variable times before targeting the enemy. Simply not possible to detect this.
Other undetectable cheats will be developed, dodging bullets by moving and/or jumping, automatically walking to pick up needed items, others that I can't think of. Possibly undetectable bots will be created if interest holds long enough.
The basic fact is that source available or not, cheating exists, distrust exists between players. With source available, that cheating and mistrust escalates, regardless if the protocol relentlessly follows a fake vision of security. Open source is not the solution to everything.
Also, shame on you ESR for describing the Quake 1 source release as a lump of coal. How much experience do you have playing Quake, or more importantly writing networked games? Or anything for that matter -- show me the code. Your recent writings are not helpful. Go hack on Quake 1 yourself and show us what you mean -- through action.
khaladan
Disclaimer : I am not good enough to play quake on the net, so I don't really have any idea what I am talking about
Something I have wanted to play with for a long time is systems that get the most of human-computer partnerships (see deep blue). One way to explore this area would be to encourage people to build things like armbots into their Quake clients. After all why do you want to get good at something that the computer will always be better at? Humans should do what they are good, and computers should do what they are good at - the trick is building the system so the computer and the human can work together. If the computer can aim better than I great, let see what the game is like if everyone is using armbots. What strategies are effective now? Are some armbots more effective than others? What are other good forms of computer enhancement?
Send in the cyborgs!
Sure it won't be Quake any more, but that does not mean it will necessarily be any less interesting (does't mean it won't be less ether....)
This post and $3.00 will get you a cup of coffee.
See the reply below for more details.
When you get that scanning, tunneling electron microscope, let me know.
There is a big difference between hardware and software, namely the incredible level of detail modern chips are printed on, and the fact that their complexity is constantly increasing. Yes, it is physically possible that a hacker might have access to such a device and weeks to spend pouring over the millions and millions of transistors on it. But the odds are better that a wheel of cheese will fall out of the sky and crush the entire DOJ team prosecuting Microsoft.
- Rei
When was the last time you ran anywhere? I mean with your own legs, not by pressing 'X'?
There are some ideas for how to pull this off.. Th e idea is to embed the 'real' calculation within a much larger 'outer' calculation such that operations in the 'outer' calculation gradually perform operations for the 'inner' calculation. The outer calculation is a cryptographic mask hiding the 'real' inner calculation.
Its all theoretical and stuff, but it is possible. Maybe in 20 years it will be doable with only a factor of 1000 slowdown..
John Carmack releases source code, and Eric Raymond rewards him by using what Carmack did out of necessity, to make the game playable, as an example of the problems of closed-source, while not being anything Carmack could have done anything about. That's no way to treat a person who's as pro-open-source as John Carmack, & has opened his own code as much as is reasonable. It amounts to misusing Carmack's generosity. I hope Eric Raymond isn't starting to get one-track minded like Richard Stallman (as useful as that has been).
As the essay points out, there are many ways to cheat at Quake - open source just makes them easier to do, in some ways. My favorite trick is copying some of the object's over each other, such as replacing the "invisible" eyeballs with a Shambler. Since the eyes have no animation to them like a Shambleer does, an invisible player appears as a very strange moving Shambler. :) There are lots of others. I don't use them when playing other people; I have more fun designing levels anyway.
I am actually a little bit insulted that the Quake release was used as an excuse for ESR to wave the "Open SOurce will eventually solve everything including world hunger" flag. (yes, I do participate in open source development regularly.)
The concept that the quake cheats would not have occured if the development had been open source is an interesting one:
If Quake had been designed to be open-source from the beginning, the performance hack
that makes see-around-corners possible could never have been considered -- and either
the design wouldn't have depended on millisecond packet timing at all, or aim-bot
recognition would have been built in to the server from the beginning. This teaches our
most important lesson -- that open source is the key to security because it changes the
behavior of developers.
BUT.
The problem here is not the developers Nor is it aimbots. It's because of bots that we have Quake III Arena today. The issue is that people abused the source code for completely selfish reasons. These people were not developers of the software. Making the project open source from the begining will not change the behavior of cheaters.
If quake had been designed to run securely on T1 lines and handle transaction rollbacks I could see spending the time to write a 4-5 page article explaining why it's security model has issues. But Quake is an old game A game designed to run on Pentium 90's and 14.4 modems. It's like having a doctoral disertaion panel to grade a sophmore's CS project. (just talkin' about the security model here, not the entire game). This is more of an "Oops. Sorry. We'll fix it next time" deal.
i'll stop now before I manage to get myself in a big time flame war, cause man am I upset right now.
Sig:
Barbeque is a noun. Not a verb.
I thought it was obvious that this article is simply a pre-emptive rebuttal against the inevitable FUD that will shortly appear. The FUD that will say "The Quake model would be secure for your enterprise transaction needs as long as your protocols and software is Microsoft(TM) Closed-Source(TM) certified".
The article states that the Quake model is not secure in any form so that the FUD doesn't get realised - It does not argue that games should be open-source and written securely, just that enterprise solutions should be written better anyway.
--
Tristan Wibberley
The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again. Carmack has already talked about this, this was his original ideal development model (dumb client). But real world problems caused it to be discarded. The latency and bandwith requirements for a dumb client are not able to be provided in this day and age. Hence, the QW compromise was born. Something like that needs to be done now, all this talk of making 100% secure systems etc is moot really, we just need to keep hacking up Quake as its always been done...
Learn to know, the dark side of the force, and you will achieve a power greater than any Jedi...the power to save your w
Look, guys, the solution is pretty obvious, and no, the sky isn't falling on open source.
In a rational economy, all participants work towards their own self interest. That's why a small level of cheating is tolerated but egregious acts of cheating eventually get wiped out (unless you're La Cosa Nostra, but that's another story.) Who in their right mind would want to play against a known cheater if they've been outed?
It's something that old command-line news readers have: A kill file. It doesn't take long to discover an aim-bot. If I have a kill file, I can choose to (a) ignore the cheater, (b) refuse to connect to the server that lets him play. The main requirement is that each Quaker player identify himself/herself. Names can be faked and new aliases crafted -- but once outed, again, it's into the kill file. Alternatively, Quake could generate a signature for itself that it exchanges with the server. Again, this could be damaged and faked, but make the effort sufficiently high to do this, and one takes the incentive out of it.
Even better is the QBL (Quake Black Hole) [My appologies to Paul Vixie.] This requires a mod to the server and the server d/l's a list of persona non grata periodically. Your name or signature in the QBL? Tough! It seems to work pretty well to combat e-mail spam...
I know, this requires infrastructure, but what solutions to problems doesn't?
-scooter
If ESR rants in Slashdot, and everyone ignores it, does it make a sound?
Face facts, ESR. Your glory days are gone. Stick to the Dictionary.
considering all these problems with security and bandwidth, giving and taking between honesty and playability.
:)
I have a suggestion to id for how to design Quake 4. Make it turn based.
Like a roleplaying game. With dice rolls and everything! I'm sure all the dice rolls could be server side without lag.
Something to chew on.
Sounds like another wanker taking a break from masturbating. Why cheat? It is fun without cheating. Only fucking asshole cunt lusers cheat.
You just can't. Even if your server has a detailed client checker that checks the Quake I executable from top to bottom with checksums or whatever. Why?
;o)
First of all this removes performance (Hello, ESR? We NEED this with 28.8 and 56k modems man!).
Second and foremost, nobody would be able to play with a client that has been modified for the purposes of making the game easyer or cooler for the player (and not to cheat.
Next is the fact that even if there is a server that checks the checksums of the Quake client, hello?! A good programmer would still just minimize their "fake" Quake client they used for recognition and load their real client which will let them cheat on top of the existin fake client.
GRR!
yeah
Stopping people from cheating is like stopping people from looking at pr0n, downloading warez, or win-nuking their neighbors while at work. You might be able to stop this week's attack or misuse of choice, but you won't be able to stop next week's until well after your first detection of it, which will be well after it first happens. As the person trying to prevent this from happening, you're in a Catch-22 which resembles Heisenberg's Uncertainty Principle: The harder you try to detect misuse, the more detection countermeasures will be used. In other words, if you treat your community (users, gamers, &c) like children, they'll act like children. Children with patience and a hefty knowledge of computing and the Internet, if you're unlucky.
I think opensourcing of old games is fantastic, and companies like id should (please!) keep doing it. Take no measures to prevent cheating, and the community will take its own measures. These measures may be technological, such as writing code to detect the use of cheats and disconnect the cheater. But the effective and final measures will be social, and as old as gaming -- I won't play with you if you're going to cheat.
SP
"Nothing was broken, and it's been fixed." -- Jon Carroll
IMO all this has done is made Quake more like real life. Now the end user has the ability to invent new smart weapons. Now it can get really interesting. Myself I'm thinking of a game where there are tons of bots mixed in with the players and they are hooked to neural nets and can communicate to each other in teams to plan attacks. It could be quite awesome. As an AI programmer I love bots.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
What naivete!
Computer security is just like a contract, a door lock, or a security system... all can be beaten if there's enough determination and/or money and/or time. Most of us lock our homes with a pidly little pot-metal thing that does what exactly? The alternative is to put in an expensive security systems that can, of course, be beaten as well. The hassle of paying for that fancy security system, swiping my card/whatever, etc. isn't worth it to me. If I want to play a net game with you I'm going to have to trust you a bit. If I'm going to enter into a contract with you then I'm also going to have to trust you a bit. If I invite you into my home to see my stuff then I'm also going to have to trust you a bit. (sounds like security through obscurity huh :)
The task of creating a reasonably secure environment to play Q1 using 33.6 modems isn't worth the effort if it's even possible IMHO. If Q1 had been constructed by OS from the ground up more time would have been spent patching it than playing it as a new hack would've come out weekly. The "final" OS product may have been more secure and robust than the current Q1 version but it would have been much more painful for the players along the way.
Obscurity doesn't work but it does slow things down a bit. the Quake 1 players had a couple of good hack-free years playing Q1 because ID didn't make it too easy. ID opened Q1 up and all the hacks that were held back by obscurity flooded in.
Just my 2 cents
Ok, a couple of things:
1) People have had the ability to cheat long before the code was opened. It seems that a bunch of people just renewed their interest in cheating because they had access to the code...some coders had a field day. That's not such a bad thing. The knowledge of how to make code that cheats in quake is actually a good thing: people will see it, and people will learn how to fight it. It's an evolution. And another thing: even though people COULD cheat, a surprisingly low number fo people do. It's actually not as fun. I know...I have rcon passwords on some servers, and I can do what I want. I can kick people so I can win the map, or whatever...sometimes I do. But it just isn't as good as when I actually DO kick everyone's ass. Cheating leaves me with a bad taste in my mouth. Quake isn't about winning: it's about being in real competition with people who love the game as much as you do. I just don't see the cheaters being a long-term problem. When I play quake1, I'm going to be playing with people who don't cheat.
2)I think this problem is endemic AND important. Even if performance isn't critical for many applications now, it will be. Things will be 3d, and at some point, milliseconds will matter for almost every application. It's going to be very important that applications can communicate securely and quickly...clients are going to have to do as much work as possible, without creating security problems. Perhaps the situation isn't as simple as a 'lump of coal,' or a gift...perhaps this has showed the community a complex situation which was inevitable. I think that this problem is part of Open Source's growing up...if gaming will ever go OS, this problem must be solved. The community has to prove that it can own+maintain valuable software, like Quake's source code. It's going to become a situation which occurs more and more frequently...and people are going to want to know that they can open their code and have a reasonable solution to keep everything secure. This is an important evolutionary step. I think that the ID model is a great example: they release the code of their games, because others can maintain code better than they might while working on new projects. This might be a very good default model for other types of software as well...but only if the community can come up with reasonable and effective solutions. And I suggest that a big part of this will not be in the code...it will be in the way people treat it. Cheating is a kind of electronic crime...and it may come to be that it's as easy as it it to commit a crime in the real world. People are going to have to learn to act responsibly online as well. It's an important part of the growing-up process. The integration of online realities into mainstream culture will not be completely painless...there will be lawlessness, and many problems. But it will be worthwhile. We should just appreciate that we live in the wild west era of the internet...Quake is the game that lets us be Billy the Kid. It's all about being faster and better than your opponent...people will do a lot for this. Including cheat...but cheaters don't get respect. There may be some ways to cheat, almost undetectably, and have just enough of an edge to win, without having people notice. But that's a skill just like any other. I would imagine there will be some people who do that, and do it well, the real Billy the Kid's out there...it's all part of a universe that's expanding and becoming more complex. And we're just going to have to deal with it, one day, frag, and line of code at at time.
You cannot give someone data and also not give them that data. It's the lesson of MP3 and DVD. It's why copy protection doesn't work. It's the root of the Quake problem, Diablo hacks, and the CAD issue.
Once someone has data, they can store it, copy it, modify it, retransmit it and sell it. There is no technological remedy to this. The only way to control what happens to data is to control (or at least approve) all the hardware and software that will ever come into contact with it. With physical media, nothing can stop me from picking it up and carrying it somewhat unintended. Over the network, noone can know who's sniffing. There is no possible way to be sure I haven't modified my hardware or software to mimic an approved configuration, but behave otherwise. It is inherently, provably, not technologically possible. End of story.
If there is an acceptable level of failure, such as with piracy, one can use legal means to discourage unauthorised behaviour. Where the gains are high, and the risks unimportant, as with Quake, you can trust the client, and hope it doesn't result in excessive problems. But when a single failure is unacceptable - as with important commercial data - the answer is simply don't do it. Know that any data you give someone may end up public knowlege, and do not give anyone more data than you trust them with. If you misplace your trust, that is a human error with no technical solution.
Firstly, the server would create 'signiture' types of situations that would be normally very hard to get a hit under normal situations. A person would be allowed (say) to be lucky once but get bounced if he got too lucky.
Secondly, the server could look for players that are just too good. Yes a hacked client could get smart and introduce errors to mask aimboting, etc. but that would be fine. Enough errors and a person is back to relatively normal skill levels.
Probably a combination of the two would be good enough. A person meeting certain statistical signatures would start to be passed bogus situations in combination with real ones to see how the client reacts.
From a hacker point of view it is nice that people would be doing all this code just to get better and better clients... the thing is that sometime the clients will get so perfect that they won't need human interaction and then they will start to program bots, in a bot war, each one with more AI than the other... It is funny 42nd post!
The POINT of "twitch" FPS gaming is just that.. it's twitch based, and requires millisecond accurate packet timing. This is a REQUIREMENT. Quake would be a BORING ASS game if movement was sampled in anything less than milliseconds. ESR is missing the point completely when he suggests that Aim Bots might have been eliminated had Quake been developed in an open-source fashion from the start. I disagree. The nature of the game places several hard constraints on the design of the game system, some of which cannot be solved simply by peer review.
Sure. In this case, the chip is the black box, with extra stuff tacked on, at low levels.
I still have doubts though... If the chip doesn't do onboard public key crypto, fast enough to swap banks of ram in and out, then this can't work. It'll only work if the only data outside of the trusted area is encrypted.
It could happen, but it's simply shrinking the trusted part from the whole computer to the CPU, making the CPU do the authentication at every step, instead of making it do the work once as it loads the info into the computer.
They'll think you're incapable of reading the posts you reply to.
The idea is that trusted computers, for limited applications *can* exist, provided all work done to them is done by a trusted company with trusted employees.
You can send data to Bob, to get it processed, without Alice intercepting it, you can also keep Bob from actually viewing the data, he just supplies the black-boxes need to process it. You still need two trusted parties, but they don't have to be the two main parties, as long as one client is using a trusted and secure client.
I doubt you'd sell many of these, but if data-havens ever become possible, it might happen. Ditto with a lot of off-site checking on stuff like circuits.
Well sure, why not have all the calculations on the server side with a plain 3D renderer client? I'm sure that Quake could have been designed to include every single security precaution known to man.
The problem is that it would be too slow to even bother and the graphics would be shoddy with people popping in and out of the game universe, so security through obfuscation is probably the best way to do it.
I believe that ESR hasn't even played Quake once. If he had he would realise that Quake isn't some slow text-based game but a fast paced 3D game. Some security precautions can be implemented but the network performance shouldn't have to be sacrificed, at least not until everybody has thrown away their 56k modems.
- Nick
>> To recap, the real lessons of the Quake cheats are (a) never trust a client program to be honest,
. . . which is good advice whether your source is open or closed . . .
>> (b) you can't have real security if you trade it away to get performance,
. . . which is logically equivalent to saying "you can't have real security if you give up your real security". . .
>> (c) real security comes not from obscurity but from minimum disclosure,
. . . and minimum disclosure is itself a type of obscurity. The information that the server knows but refrains from disclosing to the client is what's obscure, and it may be hard to get that information, but not impossible. For example, the client might lie about where the player is, send projections of where the player could be to scout ahead, pretend not to have received packets while still showing the player the information contained therein . . . etc.; you get the idea.
>> and most importantly (d) only open source can force designers to use provably secure methods.
Agreed.
[We Have No Product] [The Swindle
I remember as a kid playing the the family pet. My parents were right, if the pet didn't win at least once in a while it would stop playing. Does the same thing hold true for cheating in computer games? Are you willing to initiate a game with someone you don't trust who may be cheating? If you play against a cheater are you likely to play that person again?
The fundamental measure of security is "how hard is this to break?", expressed in terms of how long it takes to compromise given X resources.
The reason why we think security through obscurity is bad is because, by this metric, it takes very little time to break. With security through obscurity you're not up against the combinatorics of a secure key, but merely have the time taken to disassemble, reverse engineer, or otherwise unobscure the protocol. What's worse is that, unlike security residing in a key, once you've broken an obscured protocol once, you can usually use the same solution again and again for other instances of the same protocol.
Security through obscurity therefore gives you some small fixed 'amount' of security, which is insufficient to repel a concerted attack, and is dwarfed by the security provided by a disclosed system where the security resides in some set of keys.
However, the Quake problem presents us with a challenge. There doesn't appear to be a disclosed protocol which deals with the problem (at least, none has been suggested). In other words, the 'amount' of security provided by a disclosed solution in this case is zero. We then have to look at other options. Surveying the field, it looks like obscurity is the only proposed mechansim that provides a non-zero amount of security.
We should feel uneasy about this, but that shouldn't prevent us from making the pragmatic decision. If you're writing a multiplayer game, and need security against cheating, you may have to rely on obscurity. To suggest otherwise, without proposing a disclosed solution which works in practice, is IMHO irrational zealotry.
By the same token, it ought to be possible to have an open hardware implementation of the same sort of thing, pared down to essentials.
What you want is to send code/data to a processor "for its eyes only," and have it be able to process it "in private." Or in some cases all of it may not need to be encrypted, as with a signed piece of open code+data.
It may be sufficient to know for sure that your snippet of open code did execute to completion. If the processor can decrypt and/or verify a signature and execute privately, what gets executed can presumably create a signed return value containing the result. The OS handling the messages once in main memory can pass them or not, but it can't fake them, because it doesn't know the private key.
A post the other day floated similar ideas to discussion here. Maybe the "KxSec" is for real?
If you were willing to expand the black box to include some larger private memory in a sealed brick, perhaps you could run whole applications that way. Even with the new transistors, how much could you put on the same chip?
Consider: The Q1/QW clients bins are about 470K a peice. Even Q3 weighs in at 870k. What if the 'client' downloaded the binary from the server, then removed it when you disconnect? You're probably wondering whats to stop someone from keeping binarys or trying to spoof the program into using your cheat bin instead of the legitimate one. Well, I'm not sure, but it's just and idea.
------------------------ LordLobo - Because I can
You put whole game in server, and make clients "dumb" X-terminals! Well, it will need some improvements on bandwidth in most cases, but after that, it is ideal solution!
How about differentiating between the Engine and the Game? The engine should be open but the game's content (graphics, sounds, etc.) could be paid for!
To a certain extent, this is how id has been doing it anyway.. Not releasing the source, but the engine freely. Check ftp.idsoftware.com... You can download the linux version of the engine for the quake games quite easily. All you have to do is plug in the pak files (art, sound, levels) and the game works.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
There are simetric encription smart cards that have the capacity of creating/storing a pair of public/private key and is only possible to read the public one from the outside-world.
Unfortunaly some of those were already cracked by the use of high-precision measuraments (I don't know exactly what was being measured) of the device to read the private key. Those cards also have a protection against brute force, if you open them up they would blow them self up. :-)
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
Let's see....
nettrek has been open source from day 1
nettrek servers can run with the option of only accepting "blessed" clients.
these pre-compiled client programs (binary only) have cut down the cheaters quite a bit... but nothing can stop a true hacker.. look at quake 2 and 3! I know for a fact that there are some out there hacked to do auto aiming and even just acting like a deathbot.
Kudos for making quake 1 as open source.
For-shames for those pissing and moaning about kiddies playing with their new toy.
only a retarted kid will use a toy as intended, the rest of us mental cases try and plug the race car set directly into a car battery!
Do not look at laser with remaining good eye.
Anyone who has played the game Ultima Online can tell you that closed source is not the (total) solution to this problem. There exists a program called UO Extreme which adds features to the UO client. On several occasions Origin has attempted to defeat this cheat program by altering the client's encryption algorythm. On each occasion the encryption was cracked within days.
Surely your kind of group will benefit most from Open Source. You don't have to worry about cheats so you can get all the benefits Open Source debugging without having to worry about people exploiting it.
Rgds.
Tom
What if, after downloading the source, the user had to snail mail for the compiler? This compiler would only be a binary only distribution, and the information obtained from the address/name would be used as a way of creating a checksum that would be added to the compiler, so that every time the compiler was used to compile Quake (or any other source), the checksum would be added into the Quake executable.
Quake could still be compiled by non-signing compilers (like gcc), but only the signed versions of the Quake client would be allowed to participate on the servers. Those caught cheating would be banned (via the signature). The only way to get another signature would be to supply a different address to get another executable of the compiler (base the signature just off the address, name, city, state (don't use apartment number, or zip) so that the user would have to move or have cooperation of his neighbors to get a new compiler).
I don't think this would eliminate the problem, but it might help (there would maybe have to be a way for the users to authenticate the servers as well - maybe via a similar mechanism?)...
Reason is the Path to God - Anon
Author Neal Stevenson perfectly described this situation in his novel CRYPTONOMICON about WWII enigma Ultra Magic intelligentence cheats.
quoted but uncapped
"no action is to be taken on infomation herein reported , regardless of temporary advantage, if suh action might have the effect of reveling the existance of the source to the enemy"
"If the Nips keep getting ambushed -- if they keep finding their own ambushes spoiled -- if their merchant ships happen to cross paths with American subs more often than pure probablitity would suggest -- how long until they figure it out?"
(Without the allies cheating would they have lost WWII ? )
Give the script kiddies something new to put their talents too. Let them waste their time by fighting
each other and make money from them at the same time.
Get them to design/customise totally autonomous quakebots so they can upload the bot source to
servers/gyms which is then compilied and run to battle other robots.
Organise server providers into multilevel leagues pools with the top of the league possiblily becoming professional ( WWF of cyber space ? )
Make money by selling advertising space inserted into the enviroments of resulting battles that can be displayed on quake like clients
Open source is not a solution to everything.
ESR states that if Quake has been an open source project it would not have any security problems. That's a load of bunk, to put it mildly.
Sometimes the design criteria for a program make one trade off between multiple desireable traits. In the case of Quake (and other latency-sentitive online games) a critical design point is that the games have as little percieved latency as possible. So the clients are expected to do some processing beyond what the actual user is allowed to see.
Sometimes, in the real world, no perfect solution is available. So you have to weigh your options and make the best decision you can.
to say that quake had it's problems because it wasn't open source, and that if it had started out open source it wouldn't have them is obsurd. "If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers." now i understand trying to promote open source, but the above comments from your article are rediculous. Open source doesn't mean that a magic secure protocal and implimentation would have been invented that would allow smooth gameplay for modem users without caching any information they didn't need at any given time. And bot recognition? That's been a useless feature from the beginning anyways and would have been a complete waste of time to implement. Every detection simply gets bypassed within hours of being implemented.
"Also, shame on you ESR for describing the Quake 1 source release as a lump of coal."
:)
I don't think you've understood Eric's turn of phrase. In parts of Western culture (Scottish? Not sure.. I'm a Welshman, so we have different traditions) there is a tradition of bringing a lump of coal through the front door on New Year's Day -- it's supposed to bring good luck for the year ahead. Eric is describing the Quake source as a welcome gift.
I'm sure he'd be the first to welcome something which simulates an arsenal of high-powered weapons... He'll be eagerly awaiting "Defend your homestead against the commies" when it's released
--
Wrong: it has nothing to do with Windows.
Quake breaks as open source, because people can change the rules of the game, and cheat.
Windows, well, who cares if people make their own box crackable? changing windows wouldn't make other boxes less secure.
The fact that opening the source exposes current bugs is different, and is *good* -- once the bug is discovered, a fix is usually available instantly (nearly) on bugtraq.
--
David Taylor
davidt-sd@xfiles.nildram.spam.co.uk
[To e-mail me: s/\.spam//]