| This discussion has been archived. No new comments can be posted. |
... (Score:0)
by Anonymous Coward on Sunday December 26, @01:09PM EST (#1)
|
This is a very interesting problem I haven't seen addressed before (I'm sure it has and I've just missed it up to this point)... does "closed" source actually and truly make hacking harder?
Also, is anybody still playing Quake I?
|
| |
No it doesn't (Score:4, Insightful)
by color of static (smasters@ieee.org) on Sunday December 26, @01:56PM EST (#59)
(User Info) |
Closed source doesn't make any code less hackable. All it does is make a protocol not designed against a malicous client effective against those not willing to go through any effort in hacking.
The real solution for this is to make the protocol in a way so the client can only make requests to the server. Any time the client describes itself to the server, those things that can be described can not be trusted. In this case a safer protocol is to have the client request motion. The server will then provide updated info back to the client. If you want the client to track objects, then you can cryptologically sign them, so theywould be unique to the game session and non repeatable. The crypto could use very small keys to keep the performance managable, and the game exportable. 32 bits would probably be enough.
|
Re:No it doesn't (Score:1)
by sjh on Sunday December 26, @02:22PM EST (#92)
(User Info) |
You don't unserstand the problem. They don't want
clients "helping" players, like aiming for them.
No protocol change can prevent that. nettrek has
the same problem, and the same solution.
|
Re:No it doesn't (Score:2)
by color of static (smasters@ieee.org) on Sunday December 26, @02:38PM EST (#113)
(User Info) |
I can think of a number of ways around that one, but if the motion (rotation included) is controlled by the server then all the client could do is implement a control system to track the target.
The better solution for that may be logging and fingerprinting. While I haven't seen this data, almost all other I've seen you can easily tell the difference between human and machine control signals. Develop a fingerprint for control signals. If it looks to much like a control system output, send it spoiler data that would be out of control bounds. Or you can just log them off :-).
While I realize this is a record/record player problem (as in GEB), but the breaking record can be made unattractivly hard to make compared to the effort for the player.
|
Hello? (Score:1, Informative)
by Anonymous Coward on Sunday December 26, @06:19PM EST (#296)
|
>I can think of a number of ways around that one,
>but if the motion (rotation included) is
>controlled by the server then all the client
>could do is implement a control system to track
>the target.
We're not talking about Duke Nukem 3D here. In
Quake/QW the server is actually the only instance
that controls motion and everything else except
the client input. The most important cheat we are
talking about IS tracking of targets (aimbots).
>The better solution for that may be logging and
>fingerprinting.
You won't get far with logging. There are players
out there who have an aiming that might look
inhuman to some people (and some algorithms) and
on the other hand there may be aimbots that don't
aim DIRECTLY at their target or implement some
kind of synthetic jitter.
Fingerprinting is actually implemented in QW as
the client adds a checksum to it's UPDATE-message.
But now as the sources are laid open (and the
sources of new versions have to be laid open too)
it is very easy to write a workaround for ANY
fingerprintinging mechanism I can think of.
|
Yes it does but it's still not the right solution. (Score:1)
by Crazy Diamond on Sunday December 26, @03:17PM EST (#147)
(User Info) |
Ut oh.. another anti-security through obscurity ranter. It is absolutely correct in saying that having closed source does not make it secure. But the original question, does it make hacking harder? Yes. Without a doubt! Obscurity is a tool used to discourage less motivated opponents. Now what are the disadvantages of the lack of public viewing? Obvious or not so obvious holes is certainly the big one. This is what we should be looking at. Once a motivated opponent gets passed the obscurity, they have complete knowledge of the system and are able to exploit it in any way possible. Ways that John didn't even imagine.
How will the Quake client work and are we to assume that it won't have a bunch of holes that will certainly be exposed? Shouldn't we have a more elegant open source solution that is much more secure? This certainly is a very difficult problem and must be very seriously thought about.
|
Re:No it doesn't (Score:1)
by nano on Sunday December 26, @06:46PM EST (#307)
(User Info) |
There is already one way to prevent this problem, the qizmo proxy. This is the best proxy for QuakeWorld and it checks the executable file for crc and of my knoledge it's the only proxy that hasn't got hacked. It has also a whole bunch of other great features, many anticheat features but many other great features that makes quake more comfortable. It's free if you just want to use it as a regular proxy, but if you like to have the advanced features you'll have to pay 20$ i think, but i can ensyre you that it's worth it. Have a look at http://www.students.tut.fi/~zibbo/qizmo/ for more info
|
Re:No it doesn't (Score:0)
by Anonymous Coward on Sunday December 26, @08:45PM EST (#334)
|
While they are writeing a more secure protocol they should also try to write a protocol that makes listen servers fair. Maybe require a listen server to recieve acknoledgements before letting players on the same server's requests be processed. I don't mind playing against somebody with a better ping time, i enjoy the challenge, but playing with a 400 ping against someone on a listen server isn't fun
|
Re:... (Score:0, Offtopic)
by m3000 (m3000athotmail.com) on Sunday December 26, @02:03PM EST (#64)
(User Info) http://m3000.1wh.com/linux
|
I've seen this type of problem addressed before in Slashdot, or at least a thread or two about it. I forgot what the conclusion was, but this doesn't suprise me at all. As for playing Quake I, I play it at school since the computers really suck there, and we have lots of free time.
|
Re:...[solution] (Score:1)
by Zurk (zurk@SPAMSUCKSgeocities.com) on Sunday December 26, @02:04PM EST (#68)
(User Info) |
nope. closed source is just security by obscurity..it increases the time it takes to crack it.
Here's a simple solution (works with open or closed source):
[a] Take client A, a legitimate Quake client with no cheating. Compute a RIPEMD-160 signature for the client.
[b] Take client B, a hacked client.
[c] When A & B connect to legitimate server C, C passes a predetermined, randomly varying string to both clients which they load into memory. A snapshot is then taken which both clients have to pass back in the form of the computed RIPEMD-160 signature of their entire memory space (should take 1-2 seconds max) - and passing a 160 bit signature is negligible in terms of overhead.
[d] Server C knows what string it passed both clients and also know the signature of a legitimate client + random string. In this case, A will pass while B will fail.
[e] Server C denies B and allows A.
Since the string is set on the server and is varying randomly, it is very difficult for B to calculate the string dynamically at runtime in the length of time allotted. RIPEMD is open source , no patents and is stronger than MD5.
|
Re:...[solution] (Score:1)
by sunking (sam@tregar.com) on Sunday December 26, @02:14PM EST (#78)
(User Info) http://www.tregar.com
|
| [c2] Client B has a slave legitimate Client (B2) for which it is the "server". It passes the random string to Client B2 and obtains a good RIPEMD-160. Don't take my reply as meaning that I think your scheme was even reasonable in the first place - how could the server possible know what the ENTIRE memory space of the client should look like? That would include configuration options, models, player name, etc. -sam
|
Re:...[solution] (Score:0)
by Anonymous Coward on Sunday December 26, @03:50PM EST (#179)
|
What if the hacked clinet lies about its memory space? The hacked clinet will always send data that the server wants to hear.
|
Re:...[solution] (Score:0)
by Anonymous Coward on Sunday December 26, @04:23PM EST (#217)
|
2 quake clients will easily bog down any good system. And anyway, it doesnt have to compute the total memory space, just the binary code + the random server string. if the hacked client lies about its space it wont be able to compute the correct signature..hence it will be rejected.
|
Re:...[solution] (Score:2)
by TheCarp (sjc@delphi.com) on Monday December 27, @11:54AM EST (#431)
(User Info) http://people.delphi.com/sjc/
|
> And anyway, it doesnt have to compute the total
> memory space, just the binary code + the random
> server string. if the hacked client lies about
> its space it wont be able to compute the correct
> signature..hence it will be rejected.
So,....
This code has to be static or else the whole
system doesn't work...as long as they have a copy
of the original correct code (say a binary dump
in a file of some sort) then the hacked
client can computer the signature from the
static dump instead.
How about "man in the middle" style? Hacked client
contains a proxie built in. When you tell it to
connect, it spawns a real Quake that connects to
it...it proxies the connection over to the real
server and listens. The real client then
participates in the protocol, when it finishes,
it is killed and the hacked client takes over
the connection.
Yes...this can be worked around and possibly
stopped. However as long as someone has the
original code, they have the "secret" you want to
authnticate with. Thus they can authenticate.
|
Re:...[solution] (Score:1)
by Signail11 on Sunday December 26, @04:25PM EST (#218)
(User Info) |
"predetermined, randomly varying"--this doesn't make much sense.
"Since the string is set on the server and is varying randomly, it is very difficult for B to calculate the string dynamically at runtime in the length of time allotted"--nor does this. The main delay will be network latency, as most hash functions are *very* fast and some special optimizations are possible that can probably compute Hash([modified client binary]|[Random string]) where | denotes concatenation in around 850 cycles (this is a back of the envelope calculation).
|
Think again please! (Score:0)
by Anonymous Coward on Sunday December 26, @06:41PM EST (#303)
|
>[d] Server C knows what string it passed both
>clients and also know the signature of a
>legitimate client + random string.
If the server knows the valid signature then
this means that the memory dump of the client
(not included the random string) is static. This
is certainly possible if you make a dump of the
code (problem with different platforms!) or
any other data that is included in the valid
client execuable or computed by this executable.
The problem: this data could also be constructed
by a hacked client (especially if the qw-sources
are public).
|
Re:... (Score:1)
by ChazeFroy (gavina@river.it.gvsu.edu.ILikeCheeseWithSpam) on Sunday December 26, @02:25PM EST (#93)
(User Info) |
It makes cheating a lot more difficult, but cheating in Quake I didn't (and doesn't) require changing the actual executable or engine: Having it open-sourced or closed-source makes no difference to most cheaters.
Back a couple of years ago, when Quake I was in its hay-day, there were tons of model and map hacks. I even designed some of these myself. Of course, these only worked in NetQuake because of the pak-file checking in QuakeWorld.
For player models, all one had to do was load whatever MDL file they wanted to alter into a 3D rendering program. The cheat that got the most press on IRC was the infamous "pak2" cheat (named so because Quake I only came with a pak0.pak and a pak1.pak, so this cheat was commonly put in a pak2.pak). This cheat had a modified player.mdl model in which bars would stick out of players in the x-, y-, and z-axis and colored by the player's pants (the color of pants used to determine the team). These bars would stick out approximately 4 times the height of the model, and these bars went through walls, floors, and ceilings. Anybody with half a brain and the reflexes of my dog could now keep up with players from Unforgiven or Clan Kapitol. Other "pak2" cheats came along, also: Modified Quad and Pent models making it easier to determine if they had spawned, player models that did not have the "bars" when they were standing still (to get around the screen-shot approach of checking to see if you had the original pak2 cheat).
Another aspect of cheating without changing the code of the engine/executable would be to change the maps. Quake I has a nice feature of being able to "vis" water...to be able to see through it. Load up DM3: If you can't see the lightning gun at the bottom of the water, you don't have the water vis'd. The trick is to change the walls and floors to water, then vis them. "waterhack.exe" (I forget the actual name, it's been awhile :) under DOS would vis all entities of a map designated to be water. Now you can see through anything. With my modified DM3, I could see the red armor from quad and I could see the Pent from yellow armor (that's quite a distance and through many walls).
There are still a few clans that play Quake I. Check the enterthegame IRC network (ky.enterthegame.com, ny.enterthegame.com) in #ck . A lot of people hang out there, and I'm sure a few still play or they can direct you to a clan that plays.
- k3nny, Clan Kapitol
|
Anybody still playing Quake I? Hell yeah! (Score:2, Insightful)
by Turmio on Sunday December 26, @02:39PM EST (#115)
(User Info) |
IMHO Quake I is still the number one realtime multiplaying game.
Okay, the pure deathmatch is quite stupid, but still it beats Q2, Q3A, Unreal and all the others. Quake I may not be as pretty as the games listed above, but Q1 feel and atmosphere is something that any other game haven't been able to achieve.
And because it's pretty old game, you don't need the latest 3D accelerator that supports transparent-bumbing-flare-with-5th-reality-and-a-kitchen-sink effect to play it.
Overall game-play is just something that they don't do anymore, which is a shame. For example no delays when changing weapons - not very realistic but fun, easy and efficient.
And not to mention those great mods like CTF and TeamFortress.
Playing Q2 and Half-Life ports of these mods just don't rise the same feeling as the original ones do.
For example when I first tried TeamFortress Classics for Half-Life, I thought it just was a bad joke by people with sick sense of humour. Playing TFC just felt horrible when compared to the original TF. The great balance between classes was ruined and smaller versions of great TF maps with ugly textures almost made me puke. Never again, thanks.
Apparently quite a many other people thinks this way, too. At least here in Finland playing Q1/QW is still quite popular. To check out the state of Q1/QW scene, just join some major Finnish QW server like Sonera's small.qw.edome.net for deathmatch or tfa.qw.edome.net for TF or some other server.
From 10AM to 10PM GMT+00 you even may encounter some troubles when joining a game on the most popular servers since at that time they often are full. Around 03AM GMT+00 they all are empty, though.
Quake was the first well-working action game with multiplaying using IPv4.
Quake will be the last well-working action game with multiplaying using IPv4.
Since whe have the source, we can add IPv6 support.
You can be an Internet2 user and still you can play Quake I.
Quake One will never die.
|
Re:... (Score:1)
by Tarnar (jpullman@spamfree.ualberta.ca) on Sunday December 26, @02:41PM EST (#119)
(User Info) http://localhost
|
Closed source need not be the solution. Take almost any form of encryption. I have some trust in the server, but of course there's some form of authentication involved. That authentication is perfectly open source and it still can't be faked.
What I think needs to happen is JC to put out an open source authentication module so that the Quake players have some faith in the module and so that everyone is happy.
The point of good compilers is world domination. The point of not-so-good compilers is to serve quality coffee at an affordable price. Any questions? - phi1 |
Explain (Score:0)
by Anonymous Coward on Sunday December 26, @04:41PM EST (#231)
|
What gets authenticated? The client? What authenticates the client? You might say the server... but if you think thats the case you are not thinking it through. The server sees what the client tells it is there, the only way the server could authenticate the client is if it had guarantueed untainted code on the client host... wich was what we wanted to check for in the first place :)
Im sure you can make it difficult with open source (but not without communicating a lot of the internal state all throughout the connection IMO) but not as difficult as it would be if it were closed.
This isnt about security in the classic sense, this is about temporarily patching unrepairable security holes. In theory you could remedy vision tricks by making the client ultra-dumb but that does not work due to latency and bandwith limits, the client needs to have an accurate representation of the game situation on the host to combat latency and to be able to render the view itself.
But the only solution to borging/botting in fact is sitting next to the guy playing, its an unsolvable problem... (they could always construct a real robot for instance :)
|
Re: Does Anyone Play Quake I (Score:1)
by jawad (jawad@nycap.rr.com) on Sunday December 26, @02:57PM EST (#137)
(User Info) http://jawad.org/
|
Re: Does Anyone Play Quake I
Actually, since Quake was GPLed, I just downloaded & installed shareware Quake (to get a map of the level), and am about to browse the source code of it. I'm sure a lot of other people are doing the same.
sid=moderation |
Of course it does... (Score:1)
by um... Lucas (lucas@no.spam.or.flames.caralis.com) on Sunday December 26, @03:07PM EST (#142)
(User Info) http://www.nsa.gov/agents/~lucas (NO - not really...)
|
Not much harder... But hopefully all the good compilers strip out things like comments prior to actually compiling the code. Yes, you can decompile or disassemble binaries, but those are only 50% useful compared to fully commented code... So, it does make things a slight bit more difficult than otherwise...
My opinion, at least.
|
Re:... (Score:0)
by Anonymous Coward on Monday December 27, @12:49AM EST (#381)
|
Meeee...!! I still play QuakeWorld TeamFortress...!! 8-)
|
Re:... (Score:1)
by dhaber on Monday December 27, @01:00AM EST (#384)
(User Info) http://www.oswego.edu/~dhaber
|
This is all a bit silly. Everyone is proposing all these complicated ways of fixing the problem. Even Carmack suggested a closed source solution. The real solution that works perfectly and has no problem being open source is to rewrite the bad areas of the server so that it will check and make sure the client isn't trying to do anything it can't do. There is no reason this can't be done. If the protocol is badly written then the proper solution is for it to be rewritten so that it could work securely.
It seems like the best thing to do would be to keep this all open sourced, and the best way of doing that is to properly write a secure server/protocol. This method seems like it should keep everyone happy. It's not much more difficult than all the ideas being proposed, and it keeps it all open source. This is not the big problem everyone is making it seem to be. If the program is well written then it will be secure.
|
Re:... (Score:0)
by Anonymous Coward on Monday December 27, @04:04AM EST (#401)
|
An open source version makes it even more interesting in that the game is not just how well one can shoot but also how good a hack you are. Now its also about how good your tech is. Deathmatches will have a whole new side to them.
|
is anybody still playing Quake I? (Score:0)
by Anonymous Coward on Monday December 27, @08:14AM EST (#411)
|
| Not only are people still playing Quake 1, there are folks out there that still play Doom, which has been open source for quite some time. There are now several flavors of Doom; Windoom, GLDoom, etc. Plus, there are people out there who only upgrade their hardware when they have to, and as long as their word processor and internet connection work, they don't have to. After all, Quake is Doom with mouselook. -Springfield Fragfest
|
Doom :) (Score:0)
by Anonymous Coward on Monday December 27, @09:31AM EST (#418)
|
just to set the record straight, there are source ports of doom with jump and mouselook now :) and now that the quake sources have been released, server/client multiplayer is on the horizion for doom :) i dont care what anyone says, doom is the first and only game in the genre that doesnt require a supercomputer ro run and is still very cool :)
|
The Nature of the Source has no effect (Score:0)
by Anonymous Coward on Monday December 27, @11:55AM EST (#432)
|
No. It just makes 'hacking' different. Open Source games allow coders to write their own mods. Closed Source promotes script-kiddie growth, because making those mods is more difficult.
Blizzard's Diablo is the best example of what happens in a closed source game when people want to cheat. Several months after Diablo's release, all manner of cheats and hacks and other ways to take advantage of the game started appearing. When Blizzard tried to combat cheating, hackers found another way. One patch to prevent cheating lasted all of 18 hours before someone found a way around it.
Changing the nature of the source won't change people's desire to cheat. It only changes the means by which they do so.
If you want to play honest games, simply refuse to play games with cheaters.
|
Re:MEEPT!!!!! (Score:1)
by digigasm (mherrewig /at/ hotmail /dot/ com) on Sunday December 26, @03:50PM EST (#178)
(User Info) http://rhapsodie.tripod.com
|
Does anyone know of a gallery/collection of
MEEPT[\!]? poems? They are truly moving and amusing.
.:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:._.
ASCII art?? I thought it was a regular expression! |
Re:MEEPT!!!!! (Score:1)
by BOredAtWork (dsracic at vt.edu) on Sunday December 26, @04:20PM EST (#212)
(User Info) http://www.vt.edu:10021/D/dsracic
|
Heh... ya know, as loony as everyone's favorite green cheese loving man/woman/thing is, it does make a good point here. If all you've got to whine about is quake cheeters, do you really have anything to whine about at all?
--
Microsoft does have a Year 2000 problem. We're it. |
Re:slashdot (Score:1)
by pest (n@a.net) on Sunday December 26, @04:20PM EST (#215)
(User Info) |
someone moderate this down? please?
|
What about Quake 3? (Score:1, Offtopic)
by MrHat on Sunday December 26, @01:10PM EST (#2)
(User Info) |
The .plan file talks at length about cheating related to the GPL'ing of the original Quake - and then goes on to talk about a Quake 3 source release. Is this just the virtual machine code? Can cheating be accomplished with a Quake 3 release also (be it the VM code or actual source)?
|
| |
Re:What about Quake 3? (Score:1, Informative)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @01:15PM EST (#15)
(User Info) http://www.phish.net
|
just the game code. the c vm game code.
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
Problem has already been solved! Stop babbling. (Score:5, Informative)
by lorimer (squidly@bottom.of.the.sea.com) on Sunday December 26, @03:46PM EST (#175)
(User Info) |
http://www.netrek.org
As several others have pointed out, Netrek solved this problem a LONG time ago. I'm responding where I am so that this post gets, hopefully, seen by everyone who hasn't read yet, so we don't get any more vague, unclueful debate on this.
The solution is very simple. ID compiles a 'vanilla blessed' server. ID compiles a 'vanilla blessed' client. They create an encrypted binary key for the 'blessed' client, based on the client binary itself. They distribute this key with the vanilla server. They allow server gods to add any additional compiled keys they want - and to turn off or on whether key checking is used.
Now, every single server will be able to be accessed by the vanilla blessed client, no matter what. It all works out of the box. Turn on key checking, and no hacked binaries or recompiled clients will work on your server. Want to make a mod? Compile your modified client binary and distribute a matching encrypted server key for it. Server gods add your key if they like your client. It's that simple. If you want to run a "chaos" server, turn off key checking. Anyone can come in and do what they want - and THAT is often pretty fun.
It works great. People have been trying, and failing, to make 'borg' clients for Netrek for quite a long time now. There are some very good borgs that used to play on the Chaos servers. But they don't and CAN'T get into the vanilla servers.
-- foom! |
How do you prevent... (Score:2)
by roystgnr (roystgnr@iname.com) on Sunday December 26, @06:43PM EST (#304)
(User Info) |
...people from faking their client keys?
Maybe I don't understand the scheme you're proposing, so bear with me.
Proving that someone has a "blessed" client sounds theoretically impossible, for many of the same reasons why creating an uncrackable copy protection scheme in software is impossible. You can't have a perfectly hidden private or symmetric key in your "blessed" client, because to use that key the client has to decrypt it sometime, which implies:
A. The algorithm for decrypting it is there, in the client code. Making the client closed source may make it more difficult, but no less possible, to recover/reproduce this algorithm.
B. The decrypted key is in memory sometime. Whether you run the "blessed" client through a debugger, or halt its execution and examine /proc/kmem byte by byte, you can pull out that data somehow.
There are more ingenious techniques, I suppose - someone mentioned running a "blessed" client and using your cheating client as a proxy between it and the server, passing any "key requests" or "checksum requests" to the blessed client while handling most of the gameplay with the cheating program.
Two more points, as long as I'm posting:
There have been near invincible client-side bots on public servers since I started playing Quake over two years ago, with all the aim improving, sight improving, etc. cheats that Carmack outlined. Closed source didn't do anything to stop them. In other words, to the idiot QW player who whined that he was never buying another Id game: shut up; it's not Id's fault.
The best way to prevent cheating from a client-side bot is to have the client-server protocol such that the client is completely untrusted. Unfortunately, this isn't perfect:
Just because it prevents the client from cheating doesn't mean it prevents the client from being a borg or a bot. You can make a Quake game such that borg clients can't see around corners, but you can't make one such that borgs can't have perfect night vision, perfect (aside from dodging projectile weapons) aim, etc.
There are technical complications in realtime games to making the client completely untrusted. Quick example: Not sending the Quake client data on opponents who are around a corner means that the client can't do any local prediction on that player's movement, which means that you're subject to the full 200+ ms modem lag before the opponent becomes visible after he rounds the corner. I've already been too spoiled as a LPB to enjoy modem FPS games; this would just make them near-unplayable.
Having a number of "blessed" clients as you've suggested is the perfect way to prevent cheating, but short of a magic uncrackable piece of hardware to locally verify the "blessed" client status, I don't see any way of preventing people from creating cheating clients. Closed source makes it harder, but no less possible.
|
Ok, what the heck is a BORG? (Score:0)
by Anonymous Coward on Monday December 27, @05:53AM EST (#408)
|
Apart from a pasty looking dude in Star Trek?
|
Re:Ok, what the heck is a BORG? (Score:1)
by glorf on Monday December 27, @09:27AM EST (#417)
(User Info) |
In Netrek a borg is a computer generated enhancement to the client that would give you an advantage over other players. In the netrek community there are frequent debates as to how "borgish" a feature may or may not be. Examples are things like auto-aiming, auto-dodging, or so-called info-borgs that give more info on the HUD like range or speed indicators.
|
Re:Problem has already been solved! - GPL (Score:0)
by Anonymous Coward on Wednesday December 29, @11:52AM EST (#478)
|
This is incompatible with the GPL: you can't release binaries in this way without also releasing the network black box code.
Carmack's method won't work in Linux, either: there's no way for a loader to validate a client binary and then run it while guaranteeing the binary won't get changed (ie. via copying a new one in, or just shifting a symlink) between the two steps.
Even accomplishing this, you still have a weak point: IPC. A decent kernel hacker could redirect any form of IPC, so he could start his own client and make it hijaak the connection between the proxy and trusted client.
|
Re:What about Quake 3? (Score:0)
by Anonymous Coward on Sunday December 26, @07:45PM EST (#323)
|
It's _always_ possible to cheat. I'm sure by now there's people with Quake 3 auto-aim proxies. id tried to make it much harder for people to do this; if you've tried you'll notice that the packets are now compressed (I suspect huffman, but I haven't figured the code out yet) and crc signed. It's pretty easy to do if you're experienced with cracking already. Debug into where they handle the sequence numbers, go past where they check for unconnected (FFFFFFFF) packets and you'll start running into the code you'll need to snip. What id did with earlier games is to protect from proxies by changing their crc encoder from quake version to quake version. The proxy needs to insert packets and reorder sequence numbers to be effective, unless you can manage to tack commands onto an already existing packet. Either way, because of this if you didn't have the right crc routine, the server would reject your changes. Luckily they did this with ease of programming in mind and had pointers to each version's crc routine in a table. :) It was quite easy to pick out which crc routine they decided to use. A more advanced technique would be to design your proxy to take a quake binary and use its crc code automatically without having to recode the proxy. The proxy I'm writing for Quake 3 should be able to do this. One alternate technique to completely route around this would be to add code directly to the quake binary, but proxies are preferred as they usually require less recoding when versions change. In the future, proxies should require no recoding, as I doubt people will stand id's requiring you to upgrade to play every time a new version comes out much longer. Basically, keeping the protocol closed and trusting in obscurity means only the dirtyest of the cheaters or those with something major to win (think contests) will be doing it and everyone else will have the illusion they are safe from it. Similar to closed source software, only the really mean and vicious hackers that want to do much more than deface your web page will know that your system is insecure and they arn't going to tell you. :) It's probably better to know where your weaknesses are instead of ensuring only the truly pathological know.
|
One partial solution... (Score:1)
by Jeremi (jaf@chem.ucsd.NOLUNCHMEATDAMMIT.edu) on Sunday December 26, @09:43PM EST (#347)
(User Info) http://sdchemw1.ucsd.edu/~jaf
|
How about this: At connect time, the server transmits the authentication code to the client as a Java .class file (or reasonable equivalent)? The authentication code is run (in a sandbox) and checks out the game environment to make sure it's "approved", before generating the correct response code that can then be sent back to the server to allow the game to start.
Of course this is still vulnerable to all the previously mentioned spoofing attacks, but the advantage here is that the server could use a different authentication method every day (or even generate a custom authenticator for each connection), which would hopefully make it a giant pain-in-the-ass to keep your cheat code "compatible" with the server...
|
Re:One partial solution... (Score:0)
by Anonymous Coward on Monday December 27, @12:18AM EST (#372)
|
Let's put it this way. can your computer tell if it is you at the console or some program? :) Cheating at games is conceptually as simple as replacing you with some code. You can try as hard as you like but you can't stop people from doing this, as the client side of the equation is completely under their control. Most of the obfuscation being proposed is to make proxies harder to write, but proxies are only one way of replacing you. For example, a slightly more complicated but less intensive approach would be to monitor data structures via /proc/(fd)/mem and send xevents to the client. This is impossible to detect, so if writing a proxy becomes too time consuming, people will just switch to another method like this. It's like copy protection, obsessing with this wastes a developer's time and is ultimately ineffective.
|
Re:opensource (Score:1)
by mangu on Sunday December 26, @02:44PM EST (#124)
(User Info) |
1) to study coding, learn how it was done
2) to debug
3) to adapt it to other computers and operating systems
4) to create new user interfaces (e.g. to adapt it for impaired persons, or cripples, if you don't like PC talk))
5) to create new games based on it. For instance, GayQuake, where you throw flowers at your adversaries and suck the dogs' dicks. Or PCquake, where you throw sermons.
|
Re:opensource (Score:0)
by Anonymous Coward on Sunday December 26, @02:48PM EST (#127)
|
this all sounds fine and dandy....but the cheater problem still exists...the second ID released quake Open-sourced, was the end of quake online as we know it...the only way to stop it is to have a new client..with standards...which defeats the purpose of open-sourceing it in the first place.
|
Re:opensource (Score:1)
by benbean on Sunday December 26, @03:50PM EST (#180)
(User Info) |
Personally I don't see what people get out of cheating like this. Where's the fun? Where's the challenge? If you make it so easy you don't need to work or think at the gamem, what's the point?
--- It's a Unix system - I know this. |
Re:opensource (Score:1)
by Felinoid (jeffery@[website_url]) on Sunday December 26, @09:13PM EST (#341)
(User Info) http://www.meowpawjects.com/
|
It's the same with sports or any game. People who cheat do so in order to clame suppereority. "I'm better than you becouse I won and you lost... loser.."
Compeating is great and when you lose you learn and when you win you learn.. when someone cheats the cheater steals the experence from everyone including himself so he can feel better about himself becouse he won...
It's sad but some people can not see past the win itself... They want to win so badly they'll hurt anyone to do it.
But what is gainned? Hurt feelings... a cheater is not going to notice or care.. he feels the need to be better not to experence or to bond.. he wants to put himself on the pedistal.
The real irony is some people play FPS just to get away form that kind of person... blow off stome steam.. beat up on someone.. if only in a VR type sence.
I personnaly play against bots as a test of skill. So cheaters can not steal the experence from me.. it adds a new dimention to the game for me... but thats me...
It's certenly no fun for newbes... it roaly stinks.. Whats the fun of beating someone up on-line if you had to cheat to do it?
It's more fun when you frag a cheater...
But a cheater is infereor.. he dosn't open himself to the challange.. instead he cheats... So in the end he hasn't proven himself to be better... he proves himself to be worse...
Others are to blame for the obstacle I must overcome but I alone am to blame for my failures... |
Sadness (Score:2, Insightful)
by ZuG (zee ewe gee at madwolf dot net) on Sunday December 26, @01:11PM EST (#3)
(User Info) http://www.madwolf.net/zug/
|
This is really sad, guys. ID is one of the few companies who have really embraced open-source gaming, and what he says is going to have an effect on all gamers in the future. If he finds that there is no way around massive cheating other than to keep the source closed, then this will have a major effect on all other gaming companies, and he will follow suit. A few can ruin this for everyone. If you know someone who plays QIII under linux and uses a cheat, plead for them to stop, and have them plead for others to stop. This is one of the first attempts at OSS gaming, and it may well be the last if cheaters don't cut the crap.
-- Signatures are Evil. |
| |
Re:Sadness (Score:2, Funny)
by Qeyser (keyser at jay aitch yoo dot ee dee yoo) on Sunday December 26, @01:19PM EST (#17)
(User Info) |
I don't think the solution that he proposes is that unsavory. The important parts of Quake the game can still be open; the closed part would only concern client/server negotiation. Its a sacrifice, true, but I'm not such a purist that I refuse to use a version of Quake that's closed in such a way. I mean, as long as I can make my rocket launcher look like a big twinkie, I'll be happy ; )
-V
|
Re:Sadness (Score:1)
by cronio (josh@fausthaus.com) on Sunday December 26, @01:20PM EST (#18)
(User Info) |
you know someone who plays QIII under linux and uses a cheat, plead for them to stop, and have them plead for others to stop
This really doesn't affect Q3, at least yet (we don't know what code is going to be released, so it may not affect it at all).
All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant |
The solution is "blessed" clients (Score:3, Offtopic)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @01:35PM EST (#31)
(User Info) |
Does anyone remember Netrek? The same problem happened with that game. The solution is to cryptographically bless binaries that don't have cheats, and allow people to configure their servers to reject all "non-blessed" clients.
|
Re:The solution is "blessed" clients (Score:1)
by /dev/zero on Sunday December 26, @01:48PM EST (#47)
(User Info) |
Yes, I remember that game. It's still active, though I'm not. I think you've hit the nail on the head. Blessed binaries are the way to go. Could someone moderate winterstorm's post up a few notches? Gordon.
-- It doesn't get any easier, you just go faster -- Greg LeMond |
Re: "... Could someone moderate...?" (Score:0)
by Anonymous Coward on Sunday December 26, @05:10PM EST (#253)
|
| What would be wrong with a second moderation score that any poster could add to a post when replying to it? Anyone could add a signed value from -3 to plus 3. And the negative and positive evaluations would be accumulated separately like weighted (by intensity of opinion) votes. This would be more interesting to me than the effect of random attention from appointed moderators, but could be run in parallel with the old system. Just two more columns in the database, and a little perl to implement some new threshholding.
|
Re:The solution is "blessed" clients (Score:1)
by osu-neko (osuneko(whirlpool)iname(spot)com) on Sunday December 26, @02:26PM EST (#95)
(User Info) |
...allow people to configure their servers to reject all "non-blessed" clients.
I'm confused. What prevents me from writing a non-blessed client that returns whatever response the server expects from a blessed client?
--
Y2K bugs? Bleh. Wait until you see the W2K bugs! |
A little more detail on "blessed" clients. (Score:2)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @02:37PM EST (#111)
(User Info) |
| A "blessed" client is one that has been approved by some group of reviewers and then digitally signed. If anyone alters the binary in any way then the signature is invalid and the server can detect this. Here is the idea in more detail: You have the source code available so that people can play with it, improve it, check it for bugs etc. But the problem is that people program their own version of the client that cheats. To prevent cheating, people who run a server can choose to only allow clients whose binaries have been digitally signed to connect. This means you'd have a group of people setup to review the source code of the client and if it contains no cheat they would compile the code, digitally sign the binary and people using the "blessed" (digitally signed) binary wouldn't be rejected by servers. Of course you could still run a server that doens't care if clients are blessed or not. In fact in the netrek days that was kind of fun sometimes. This gives you the best of both worlds, open-source software that is free to evolve, and community based servers that have a system to prevent cheating.
|
Blessed binaries are such bullshit, part 2 (Score:0)
by Anonymous Coward on Sunday December 26, @05:15PM EST (#258)
|
| A "blessed" client is one that has been approved by some group of reviewers and then digitally signed. If anyone alters the binary in any way then the signature is invalid and the server can detect this. How? All it knows is what the client tells it. What would stop a hacked client from giving the signature of a version of the client that's on disk rather than the one that's running?
|
Blessed clients, digital signatures, and trust. (Score:1)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @05:26PM EST (#268)
(User Info) |
| This example of providing a CRC for a file in a client server environment is probably off-base. My example is a poor one now that I think about it. In a client-server environment you would "bless" a client by embedding a cryptographically signed secret into the program. All I know is that this technique is used succesfully for other games. I believe that cryptography is one of the keys to building an effective client/server trust system in software; we do it for Java Applets, SSL transactions, banking transactions, and we should do it for games too.
|
You're forgetting one thing.. (Score:1)
by prj on Sunday December 26, @07:41PM EST (#321)
(User Info) |
You can't embed "a cryptographically signed secret" into an open sourced program.
|
Sure you can. (Score:1)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @08:52PM EST (#335)
(User Info) |
There is a difference between the source code and the binary. The only thing that you want to "bless" is the binary. The source lives its open life as it normally would but people could submit copies of their customized versions to be compiled, "blessed", and distributed.
|
A comment from the current Netrek keys maintainer (Score:3, Informative)
by Unbeliever (unbelver@us.netrek.org) on Sunday December 26, @10:51PM EST (#357)
(User Info) |
How? All it knows is what the client tells it. What would stop a hacked client from giving the signature of a version of the client that's on disk rather than the one that's running? Absolutely nothing. We just make it as difficult as we can. Someone with enough determination can (and has) spoof us. Let me introduce myself. I am the current netrek client KEYGOD. I am the one who edits and serves the keyring that go to all the servers who wish to validate keys. How does it work? Not by open source. Well, not very open source. The people who own the RSA patent have given us permission to use a version of their algorithm for authentication purposes only. That source snippet is not included with any server OR client source tarball. Neither gets it, so the source isn't really "out there" or open-source. Who gets it and how are things blessed? Well, here's where trust comes in. The source for the RSA verification is relatively tightly controlled for US export, and patent and copyright reasons. There's a US version and a non-US version. You get the RSA source by becoming an established client developer or Server God. You ask us, who run the metaservers to give you the key to unlock the source tarball and include it in your source compilation. For a server, you're done, it will go fetch the keys from the keyring automatically. For the client, the verification source generates a public/private key pair stores it in about 20 different variables in random order and random .o files. Each .o file is randomly linked in to the final binary, and symbols are stripped. No binary CRC checking is done. Multiple binaries can be compiled with the same key, and yes, you read that right, the key IS stored in the client binary. The client maintainer will then offer the client public key to me, and I have a fixed set of criteria for accepting or denying a key. We, the server gods, client developers, and I, have to trust each other for this system to work. We have to trust that someone didn't compile a borg using the same key as a non-borg. Hell, we have to trust that someone didn't out and out try to bless a borg outright since it is practically impossible for us to check all the clients. Server Gods have to trust me to not slip in my own or my buddy's borg. The players have to trust the Server God to not put in server side cheats for himself. But there are recourses. Someone can cry foul on rec.games.netrek and we can investigate and yank a key. Server Gods can add their own keys of people they trust, and can reject keys from the keyserver. Maybe I'm overemphasizing this, but at some point, people ARE going to try to cheat. There is nothing anyone can do about that. You have to hope that that number is small and trust that people are generally going to Do The Right Thing. Barring that, we try to make it as difficult as possible for the casual cheater to succeed. Heck, the non-casual cheater doesn't even need to hack the binary. They can twiddle with the IP stack. They can even write something under X to send X events to the client, I'm sure you can do the same under Windows. Another level of trust is with the client developers. We have always been adding new features and new clients. Every once and a while a feature introduced by a client developer may be deemed borgish. A flame-fest/discussion occurs on rec.games.netrek, and if a feature IS declared borgish, we have to trust that the client developer retracts that feature. If you want to see how we discuss this, do a Deja search on rec.games.netrek. Keywords like "New Client" and "borg" will hit most of those discussions. Now to find a moderator to moderate this up...
--Carlos V.
|
Re:A comment from the current Netrek keys maintain (Score:2)
by Weezul (gt5079c@prism.gatech.edu) on Monday December 27, @12:38AM EST (#378)
(User Info) http://havoc.gtf.org/weasel
|
I have never looked at the netrek source code, but is there anything stoping you from just changing the protocoll to prevent cheating.. and perhaps changing the game mechanics and ideas about fair play too. After all any cheats that could be accomplished by an external program which monitored the X events is not really a cheat. The ``proper open source''' solution to borg clients is to include a scripting language to incurage them.. giving everyone equal opertunity via sharing these scripts.
Now, an interesting application of your existing blessed clients system would be to make a clients which gave a copy of your scripts to your oponent trivial.. and roge clients which did not give away the script a pain in the ass.
Finally, if people are sharing lots of borg scripts (even via some automatic script sharing system) then there would eventually be no benifit in making a client to keep your scripts secret since your scripts wouldn't really be that much better then anyone else, i.e. the user interface to the game has evolved.. which is what we all want anyway.. especially in those build and send troops games like StarCraft. A script system is exactly what they need.
Jeff
Campus crusade for Cthulhu -- it found me. |
Re:A comment from the current Netrek keys maintain (Score:1)
by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @01:22AM EST (#385)
(User Info) |
I have never looked at the netrek source code, but is there anything stoping you from just changing the protocoll to prevent cheating? Installed codebase. Right now there are at least 5 active client packages (COW, TedTurner, Paradise 2000, JAVATrek, Netrek:1999), and numerous inactive, but still heavily used clients. There does exist something we call "Feature Packets" that the server and client can signal to each other additional supported features not in the base protocols. Things can be added there. and perhaps changing the game mechanics and ideas about fair play too. What do you mean there? Game mechanics and rules have pretty much stabilized over the years into a very balanced game. Any change to game mechanics will be met with extreme resistance. People can still write borgs if they want. Telnet to metaserver.netrek.org port 3521. Any server without the 'R' flag doesn't do client verification. They are free to grab a client source tree and have at it. We actually do need 1 borg badly. Something we can run on an empty server that is smart enough to teach newbies how to play. The Netrek learning curve is steep. Any volunteers?
--Carlos V. |
Re:A comment from the current Netrek keys maintain (Score:1)
by Score Whore on Monday December 27, @02:31AM EST (#397)
(User Info) |
"Netrek, now there's a name I haven't heard in a long time..." LOL.
OK, as one of the original Paradise coders (yeah, I know, boo-hiss) I spent a lot of time thinking about borgs and prevention and such. Here's the conclusion: there is no way to prevent cheating in a situation where you can't fully control both the client and the server. As long as you have to trust a data stream coming over a network, you are at the mercy of an hacker intelligent enough to reverse engineer your protocol.
The same thing applies to Quake. Even with Carmack's proposed solution, it's impossible to stop a determined wanker. You best bet is to make it as difficult as possible and then change stuff as quickly as is reasonable possible.
Bubbles
ps - does anybody know why that first responder up top has been moderated up to +4? Is it because he used big words or what? I know it's not because he has a clue what the hell he is talking about. Sheesh.
|
A good point... (Score:1)
by sheldon (sheldon@yuck.net) on Monday December 27, @09:48AM EST (#420)
(User Info) http://www.sheldon.visi.com
|
The client/server protocol in Netrek already pretty much prevents cheating.
Everything is calculated at the server side, and only information which the enduser should know about is sent to the client.
This opens up ways to automate tasks for the user, but there's absolutely no way you can become God incarnate within the game with a client.
|
Here's almost how it works in netrek (Score:0)
by Anonymous Coward on Sunday December 26, @10:53PM EST (#358)
|
I looked into this a long while back, and this is what I remember of it. It's probably 85% correct.
The 'blessed' netrek clients are clients compiled by a few, trusted people. Netrek's verification scheme uses some sort of RSA or RSA-like encryption scheme which uses private and public keys. When someone is generating a blessed binary, they create a key pair, and compile the private key into the binary.
The normal source code that everyone downloads essentially has the routines which return the secret key stubbed out to do nothing. When you're compiling a blessed binary, you replace the normal routines with a routine which actually returns the secret key. The secret key isn't just compiled in directly (if it were, someone could just open it up with a hex editor and find it if they knew what they were looking for). Instead, a pretty hairy series of function calls and macros are generated which, when evaluated, returns the secret key. This makes it much harder for someone to pull out.
Nothing is going to be perfect, and someone is always going to be able to find a way to cheat. If you're distributing the binaries, then there will be a way to find out the secret key and make a borg (cheat client). It happens with everything... for example, DVD. Quite a few people have defeated the scheme netrek uses. Some may have poked around by running the client under a debugger, or disassembling the binary and finding the code that generates the key. I've heard that someone managed to make borg by writing a customized X server that understood the specific X calls a specific client makes, and sending appropriate input back to the client.
It does keep the majority of people from doing stupid cheats, though. FWIW, quite a number of the major netrek servers would allow any client to connect (borg or not) and didn't really have too much of a problem. I play on servers with people who I know are using borgs, and it doesn't really make it any less fun... even with the borgs, they are usually quite a bit less dangerous than the players who are truly good at the game.
|
Re:The solution is "blessed" clients (Score:2)
by Admiral Burrito on Sunday December 26, @02:36PM EST (#109)
(User Info) |
Does anyone remember Netrek? The same problem happened with that game. The solution is to cryptographically bless binaries that don't have cheats, and allow people to configure their servers to reject all "non-blessed" clients. But doesn't that defeat the whole point of releasing the Quake source? I mean, how many people are going to make really cool Quake modifications if they have to jump through hoops to get their code signed so that it can actually be used? I don't know if cheating is really such a big problem... Does anyone really know? It seems to me that there's no point to playing the game if you're going to cheat. It is, after all, just a game. "You're only cheating yourself". I doubt there's much prestige in the title "World's Best Quake Player When Cheating". And if you get used to cheats, you'll just suck all the more when you play at LAN parties where your cheats are unavailable.
|
Open-source methodology is strong enough. (Score:2)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @02:43PM EST (#122)
(User Info) |
| I think that one thing that the open-source development model has shown recently is that it can adapt and meet the needs of many complex situations. So in this case we'll need a way for developers to share their patches and submit them for inclusion in the "blessed" binaries. Isn't this the same way the Linux kernel is developed? Doesn't the Apache project already deal with this tough situation with many developers, many patch submissions, and only a few "official" releases. People can still created unblessed binaries, and people can still run servers that allow any client, blessed or not, to connect. This method just lets the people that are organizing games have a way to ensure cheating won't take place if they want to.
|
Blessed binaries are such bullshit (Score:0)
by Anonymous Coward on Sunday December 26, @03:39PM EST (#166)
|
| There is absolutely NO MEANINGFUL WAY for the server to verify the blessedness of the client. Go with that application launcher that Carmack wants, that verifies then loads? Well, I give you this: Launcher loads 'virgin' copy of cody Checks it Executes it First DLL call it makes is boobytrapped (check LD_PRELOAD under Linux, similar mechanisms exist under Windows) Modified version is now executing, with all the nifty hacks you have in there I suspect that the only reason there aren't many cheats for Nettrek is that there is no real incentive -- the mystique of the game is such that the people who play generally don't check. I'd make a bet that given some reasonable incentive (lets say a sum of cash dollars with some guarantee of a payout? ) that NetTrek would be hacked through like butter. Again with the proxy, ANYTHING YOU RUN ON MY MACHINE WILL BE SURVERTED. If a game programmer wants to keep me from mucking with his pretty little protocol, then he'd damn well better have EVERYTHING useful checked and double checked on the server. Allow me to send a skin? I'll make sure it's nearly invisible.. Allow me to pick a shape? See that one pixel on your screen -- it just capped you. And that designer had better be SURE that he isn't sending me any information that my client has that I don't? Sending me information that there is another player in the room? I'll flag him and auto-aim at him! Do I have the whole map? I'll make a map window which gives me locations of everything useful if I'm so inclined.. If you want fair network games, then the SERVER has to do the validation of commands and filtering of information. THERE IS NO OTHER WAY.
|
Proxies cheats can also be blocked. (Score:2)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @03:55PM EST (#185)
(User Info) |
| I don't understand your argument claiming that "There is absolutely NO MEANINGFUL WAY for the server to verify the blessedness of the client. " The obvious way to avoid booby-trapped DLLs is to statically compile the binaries. Yes they will be big on the hard disk but its not like Quake isn't big already? As an alternative the digital signature that "blesses" the client could actually apply to the client itself and all the libraries on the system too. You can digitally sign anything. There may have to be quite a few "blessings" issued but I think it is manageable; considering the popularity of Quake I'm sure that many voluteers will step forward to do the work. Defeating proxy cheats are simple. You encrypt your client/server protocol stream. Thus a proxy can't actually rewrite the stream. In fact I'm quite disgusted that more on-line games don't encrypt their streams already. Sure there is a hit to the CPU but it is well worth it. Ultima Online could have saved themselves a lot of hassle by simply encrypting their client/server protocols. Encryption is the key to preventing cheating: - Use encryption to create digital signatures to "bless" clients. Server can choose to reject all non-blessed clients.
- Encrypt all communication between the client and the server so that "proxies" can't site between the two and cheat.
|
Re:Proxies cheats can also be blocked. (Score:1)
by michajoe (joerg.michael@dont.need.spam.scs.ag) on Sunday December 26, @04:11PM EST (#203)
(User Info) |
AFAIK, Ultima Online DOES encrypt its data stream between client and server.
But then, I haven´t been with UO from the start, so maybe they didn´t encrypt back then ... :-)
|
If you use public key encryption for every bit... (Score:0)
by Anonymous Coward on Sunday December 26, @04:27PM EST (#220)
|
If you just use public/secret key encryption to negotiate a key for a normal symmetric key algorithm the cheater can just read the key from host memory. (this doesnt require changing the client)
|
This is a good point. (Score:1)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @04:44PM EST (#234)
(User Info) |
This is a good point. This might be why John Carmack says that their would have to be a closed-source part of the system. You could put a "global" secret key put into "blessed" clients known only to the authority that does the blessing and encrypted in the client itself.
|
You think your DLL's are safe? I got news for you (Score:0)
by Anonymous Coward on Monday December 27, @07:30PM EST (#467)
|
| Remember that the entire environment that you run under is under the control of a wanna-be marauder with too much time on his hands. Because of this, you can't even trust your system DLL's. Under Linux, you can statically link to libc, and people will just be unhappy, and your program will break under different library schemes. Under Windows, you *NEED* to do dynamic linking because of the differences between 98, 98SE, and NT if you support it. It didn't work for copy protection, it won't work for anti-cheating!
|
John doesn't want to be Linus (Score:3, Insightful)
by / on Sunday December 26, @05:40PM EST (#278)
(User Info) |
That is, Carmack doesn't want to have to maintain the Q1 code. He released the code, and he's nominally interested in whatever happens to it, but to ask him to stick around and bless any modifications that others make is asking too much of him. Maybe you can set up an international standards body to perform that function, but it's an uphill battle.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes |
Re:John doesn't want to be Linus (Score:1)
by powerlord (SPowerlordAM@worldnet.att.net) on Monday December 27, @11:57AM EST (#433)
(User Info) |
Hmmm...
The International Consortium for Quake...
that would be ICQ right?
:)
- Reunite Gondwana-land
(I'm a vegetarian. Free my name from spam, keeping the obvious bit, to e-mail me) |
Re:The solution is "blessed" clients (Score:3, Insightful)
by datazone (datazone@airmail.net) on Sunday December 26, @02:53PM EST (#132)
(User Info) http://web2.airmail.net/lelie
|
I see you have never played diablo on battlenet. At first the cheating wasn't so bad, then it became so disgusting! Trust me, people will cheat, just because they can. And the code to Diablo was not available. so closeing the source or opening it does not always mean you have a cheat free game. Someone, somewhere will find a way to cheat, if they really want to. but that does not mean that you have to stop trying to prevent the cheaters.
Its spelt "L-I-N-U-X", but pronunced as "Free Beer" |
Re:The solution is "blessed" clients (Score:0)
by Anonymous Coward on Sunday December 26, @03:34PM EST (#161)
|
Most cheaters cheat to screw you (a good player) up, not just to win. Besides, all they want is to see someone down, whatever it takes.
|
Read the nettrek FAQ (Score:0)
by Anonymous Coward on Sunday December 26, @04:19PM EST (#210)
|
Its not foolproof, its not even close to full proof... hacking a game is easy enough without an open source encryption scheme being the only part its made up of.
Borging/botting and vision-cheats will always be possible, the only thing you can do is make it as difficult as possible.
IMO the most protection would give a scheme wich can upload verification&connection-encryption code on the fly so you could change it very often. In theory you could build a sandbox around the code wich in all instances pretended to be the correct client but wouldnt be... but thats about as hard to hack as I can think of making it. In an OS with adequate security uploadable code wouldnt even have to be a security risk, but we all know those dont exists :) So that adds an extra worry, but if you're already accepting a precompiled binary you probably don't care.
This way you might even get away with keeping the security source open, if you could find somoene mad enough to keep updating it on a daily bases :)
|
Re:Sadness (Score:1)
by SendBot on Sunday December 26, @01:47PM EST (#46)
(User Info) http://dtheatre.com
|
This is one of the first attempts at OSS gaming, and it may well be the last if cheaters don't cut the crap.
It's not the first (Civ: CTP, Doom, everything at linuxgames.com), and there's no way it will be the last. For one thing, imagine all the people who get drawn into game development when they find out they can cheat. Cheating's fun at first, but then they strive to make something better.
And cheating isn't bound to OSS games (remember diablo?). A product can be designed to be relatively cheat-resistant, but no online game is completely cheat-proof.
At least read the article before posting. He's not talking about closing the whole source, just by adding a closed source cheatguard.
|
Re:Sadness (Score:0)
by Anonymous Coward on Sunday December 26, @02:31PM EST (#103)
|
cheater cheater! cheaters are a funny folk arent they? Messing up all John's big plans hehe....
|
Re:Sadness (Score:2, Informative)
by knghtbrd (knghtbrd@debian.org.NOSPAM) on Sunday December 26, @06:12PM EST (#290)
(User Info) |
| Most people aren't cheating. Most people being accused of cheating aren't cheating. Most people complaining about cheating are just sore losers. It's possible to cheat in quake. It always was. Now that there's source it's relatively easy to do if you grok some C. We'll fix it though, like we would any other bug. So far movement looks like the simplest cheat, but it's also got the simplest solution: let the server calculate movement rather than the client. We're all a lot better off in that case anyway because then nobody can cheat regarding movement. (server side cheats are of course always possible but that's because you have to trust the server...) It's been discussed that autoaiming aids could be doable, QuakeForge is talking about fixes for that too. And there's also the whole idea of someone faking packets to screw up a player (either to their client claiming to be from the server or the server claiming to be their client..) There are simple fixes for these things too and we'll fix them. There are doubtless other cheats to be found, but we'll fix those too. This isn't exactly a big deal.
|
The cheaters are screwing themselves (Score:0)
by Anonymous Coward on Monday December 27, @01:37PM EST (#446)
|
Thing is the simplest cheats require no source code mods...like allowing hacking of 2-fort-5 at the local quake server. All walls and floors are invisible, as the map was hacked on the client side. I was doing well, then I started getting my ass kicked. I finally got up to the point I was doing good against them (my walls were there). I then I saw that they were all using the invisible map...we set the server to not allow that...and they could not even play at remedial levels anymore. I now play elsewhere, where I have some opponents that can play.
|
open source evangelism (Score:1)
by vasiln on Monday December 27, @01:49AM EST (#392)
(User Info) |
i'm sick of this "open-source at any cost" shit. if open source has good effects with certain types of software-- hey, awesome. make your os super secure. but if open source is NOT the best for certain types of applications, so what? it doesn't have to be all or nothing. THERE WILL ALWAYS BE CHEATERS. it's true. open source or not. but that's not what's important. the game is fun when fewer people cheat-- and if closed source means fewer people write borgs, and fewer people cheat in fewer ways, then that's what should be done. i already know it can be cracked. but i know with closed source its more of a pain. and that means fewer people cracking.
|
Re:open source evangelism (Score:1)
by Duckie01 (ten.peen.eikcud@eickud--REVERSED) on Monday December 27, @04:38AM EST (#403)
(User Info) http://duckie.neep.net
|
and that means fewer people cracking. Yeah and more people downloading cracks other people wrote. I think this source code release is great, more people will be creating stuff from it and become interested as game developers.
|
Inevitible? (Score:1)
by uninerd on Sunday December 26, @01:11PM EST (#4)
(User Info) |
Surprise surprise... We suddenly have nothing holding us back but our conscience, and a few people abuse that.
|
| |
here's fragging ya! (Score:0)
by Anonymous Coward on Sunday December 26, @04:37PM EST (#226)
|
hooray! time to whip some linux butt!
|
bah (Score:0)
by Anonymous Coward on Sunday December 26, @01:11PM EST (#5)
|
It goes back to plausible deniability, and baseline ethics... i.e. I will do it if I can get away with it. People who have no love for the pure game have always tried to find ways to destroy it. Up until the GPL of Quake, at least, it was hard enough that the practice wasn't widespread. JWitt
|
woohooo (Score:1, Funny)
by Anonymous Coward on Sunday December 26, @01:12PM EST (#6)
|
Anyone got a client i could use? :) mite
|
This is a problem with OpenSource in general (Score:2, Insightful)
by cronio (josh@fausthaus.com) on Sunday December 26, @01:13PM EST (#8)
(User Info) |
I'm not against opensource, in fact, I love it. I was ecstatic when I heard Quake1 was opensourced. However, this does present the challenge for everyone who wants to play the game as it used to be. This is a problem with basically any opensourced game that really, to my knowledge, has yet to be addressed. The question is, how do you know whether that guy who noone can beat is really good at the game, or hacked a version that auto-aims, auto-fires, etc? I think it's good that someone is finally addressing the problem, at least for one game.
Just my 2 cents.
All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant |
| |
Implications for more important applictions too (Score:1)
by KahunaBurger on Sunday December 26, @03:34PM EST (#162)
(User Info) |
| I could see the same sort of problem coming up with on-line education oppertunities as well. If it gets to the point where you can take more certification type tests on your computer (leaving aside the issues that they could only be open book, I can still see the value if they were timed) or on-line voting for more important things than the time person of the year, open source avalibility would raise the same issues. So where is open source appropriate and inappropriate? And I understand the argument that "anyone who really wants to can hack closed source in a little more time" but I file it under the philosophy the nobody wants my bike. In brief this is the idea that, no, a kryptonite lock won't stop someone who really wants my bike, but it will cause someone who just wants "a" bike to look for an easier target, and add an extra component of time and therefore risk to disuade the casual thief. In the same way, it is unlikely that a casual cracker will suddenly turn into a devoted and more methodical cracker (or thief, mugger, corrupt politician, etc.) when faced with one more secure item. This theory also applies to evolution, but thats another story.
|
Re:Implications for more important applictions too (Score:0)
by Anonymous Coward on Sunday December 26, @05:21PM EST (#264)
|
There are also problems with people cheating on internet chess servers.
|
Re:This is a problem with OpenSource in general (Score:2)
by _Sprocket_ on Sunday December 26, @05:02PM EST (#247)
(User Info) |
This is a problem with basically any opensourced game that really, to my knowledge, has yet to be addressed. The question is, how do you know whether that guy who noone can beat is really good at the game, or hacked a version that auto-aims, auto-fires, etc? This problem has plagued the "closed" version of Q1 for years. There already exists proxies and patches that provide various methods of cheating. Opening the source, at worse, just allowed a few more cheats to an already exploitable environment. At best, its allowed those with the desire and ability to solve these problems the tools with which to do it. Time will tell.
|
Re:This is a problem with OpenSource in general (Score:1)
by knghtbrd (knghtbrd@debian.org.NOSPAM) on Sunday December 26, @06:24PM EST (#297)
(User Info) |
The problem is that quake was not designed to assume the client couldn't be trusted, only that the server had to be. The solution is to stop trusting the clients. Any open sourced game developed with open source in mind is going to be written with client untrustability in mind. Quake wasn't, which means everyone will have to update to the latest versions of the cleint and server as soon as we fix the cheating bugs. It's unfortunate, but it's not the end of the world.
|
Re:This is a problem with OpenSource in general (Score:0)
by Anonymous Coward on Monday December 27, @09:17PM EST (#468)
|
One thing that people neglect on slashdot is that security through obscurity is not in itself a bad thing, as long as that is not only what you are relying on. Open source can help faciliate the creation completely (?) unbreakable code, as many eyes can go through and find all the holes. In the case of a game, however, attempts to make it completely uncrackable would likely have adverse affects on the gameplay itself. As was said in a previous post, changes to the protocol such that the client would only recieve information on what it can see would make it more difficult to predict where players, if they are going around a corner. And that still doesn't prevent bots, which people consider a cheat. For something like a game, security is not going to be the main issue. As such, the code protecting the game can't be "perfect". Open sourcing the code, expecially the protocol/anti-cheat code, would make cheating easier. In this case, the best a game designer can do is make it as difficult as possible to cheat, as in obscuring the way the program works. Closing the source is the first step for this. Don't take this the wrong way, I believe open sourcing is a great way to perfect a product. In the case of a game, however, it's more of a balancing act.
|
Sad (Score:1)
by NightHwk on Sunday December 26, @01:14PM EST (#9)
(User Info) |
This shows a big problem with the concept of open source games. Back in the days of doom, there was dehacked, and I remember playing my friend in a modem game with my hacked exe loaded (i was using the ol superwep7 mod) so I had 10x firespeed and unlimited ammo, it was good for a laugh, and in an hour, we were both using the hack for a new twist on gameplay. But with quake1 opensource now, its barely a challenge to hack up your client to give you extra health points, more damage, etc. One could make it very subtle and go undetected, which is really a shame. Many people still play qw, its a great game (especialy a weekend game of creeper ctf =])
Looks like Carmacks gift to the Q1 community may be what finaly kills it in the end =[
|
| |
Re:Sad (Score:1)
by idealego on Sunday December 26, @03:33PM EST (#159)
(User Info) |
| It's not quite as bad as you might think with Quake. Doom was a client to client game so either client could manipulate the game state but since Quake is a client to server game as long as you are fairly sure the server isn't hacked for cheats then the other clients can only do so much when it comes to cheating. They can use a bot to aim/shoot and make people bright red but since the server controls the game state, things like your health, damage etc cannot be altered by the client. -idealego
|
Wrong... (Score:0)
by Anonymous Coward on Monday December 27, @01:43PM EST (#447)
|
You can take routines out of the client side, which in essence makes thinks like flares and mines not hurt you...the client side will just say things like "Missing Routine XYZ" on their client console. The client does indeed control things...at least in team fortress and the like. And yes your health is stored on server side, but it is deducted by the client.
|
Re:Wrong... again. (Score:0)
by Anonymous Coward on Wednesday December 29, @11:58AM EST (#479)
|
Er, you're wrong. All damage is controlled server-side ... the network protocol just has things like "your health is X".
Now, I don't see how people could have cheated as he said in Doom: it would have desynchronized the client states. Even if it didn't die with sync lost, the other client would have been playing a completely different game (most likely seeing the other guy bashing around wildly.) Doom's protocol was trivial: it sent button events. (You *could* cheat by changing models and so on, however.)
By the way, where did you pull "missing routine XYZ" from? That's not a Quake message (nor Doom.)
|
this is a big deal (Score:2, Insightful)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @01:14PM EST (#11)
(User Info) http://www.phish.net
|
i think this exposes a large hole if OSS development. not that open source develepment is bad, its just the now that quake is open source it has flaws. although the source release of quake may good for developers trying something new or leaaning opengl development. its opened a whole world of possibilities to them. it has completely destroyed quake1 culture. team fortress players, a segment of quake players that never really moved on to q2 or q3, after a bit of wanning of interest have finally got there death blow.
disadvantages:
-no clear leader [carmack is certainly not gonna continue develepment]
-no standardation of versions
-cheating
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
| |
Re:this is a big deal (Score:1)
by Microlith on Sunday December 26, @02:13PM EST (#76)
(User Info) http://east3d.dyndns.org
|
What a wonderful .sig
You do realize that's the only song they never officially published the lyrics to, and that's why?
No sir, I didn't like it. |
DMB Stuff (Score:1)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @03:59PM EST (#186)
(User Info) http://www.phish.net
|
i don't know if that specifically is the reason they didn't publish the lyrics, for those words specifically. the song is about dave's ex which he asked to marry him 3 times sehe said no everytime. i think its a interesting perspective, a man feeling, a feeling usually assiociated with women, 'the need for commitment'. lots of angst associated with the song too espescially on the BTCS version. please talk to me about it, love the discussion of jam band lyrics. ;)
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
This is not an OSS hole. (Score:1)
by ph43drus (EATph43drus@WITHAhomeSPORK.com) on Sunday December 26, @03:22PM EST (#150)
(User Info) http://24.5.73.229
|
| John Carmack is an incredibly gifted programmer, and I respect him for that, but this is totally a matter of a security flaw. It could have been exploited earlier, but I don't think anyone really went through with a good sniffer and decoded the protocol. What the problem is, is the amount of trust given to the clients. Now, with some revamping of the system, all the cheats dealing with the communication between the server and the client could be cleared up (however, the clientside mods would be a little harder). Using a combination of a "blessed" client model, guest access and random accuracy checking by the server, we might just have a workable system, where there is very little oppurtunity to cheat, while leaving everything open source. Go through the posts and see what these various solutions are. Jeff
Wasting Time is an important part of living.
|
Re:this is a big deal (Score:1)
by knghtbrd (knghtbrd@debian.org.NOSPAM) on Sunday December 26, @06:27PM EST (#299)
(User Info) |
| No clear leader eh? You're not aware I take it that just about every attempt to do something meaningful with the quake source but two or more persons is somehow involved with or connected the QSG if not QuakeForge or both? QSG is the standards body, they're "Linus". QuakeForge is shaping up to be the QSG reference implementation.
|
Re:this is a big deal (Score:1)
by RodStewart (robswin[at]hempseed.com) on Monday December 27, @10:47PM EST (#470)
(User Info) http://www.phish.net
|
is this worked out? whe i saw both of them last, they looked as if they were, well, basically running around like a chicken with its head cut off. they have no clear feature goals, plans, just a vaige[sp] idea, etc. email or post to this i sure would like to know and get in on the discussion.
thanks
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
Re:this is a big deal (Score:3, Insightful)
by mcc (mcclure111@earthlink.net) on Sunday December 26, @06:46PM EST (#306)
(User Info) http://drowned.cx/
|
> it has completely destroyed quake1 culture. team fortress players, a segment of quake players that never really moved on to q2 or q3, after a bit of wanning of interest have finally got there death blow.
heh.. bringing up the question.. what if Carmack did it this way on _purpose_..?
i mean think about it.. now that it's OSS all these Q1 holdouts have had their game ruined. So what? So, they have to upgrade to Q2 or Q3. Meaning Carmack gets more money.
I don't honestly think this is the reason Carmack went open-source, and i think that the way ID is willing to let go of intellectual property they no longer use is wonderful.. but still, interesting to think about. Excessive paranoia is fun!
-mcc-baka
listen to your heartbeat delete beep beep BEEP.
|
ROTFLMAO, While I play the GL version of team (Score:0)
by Anonymous Coward on Monday December 27, @01:47PM EST (#448)
|
fortress on top of quake version 1. I wonder if the guy who stated this knows he don't have a fucking clue.
|
This is just sad... (Score:1, Insightful)
by Anonymous Coward on Sunday December 26, @01:15PM EST (#12)
|
Honesty is one of the things needed to make the GPL work for the long term. If the only thing people can think to do once they have access to the source is to cheat, then they have no place whatsoever in the world of the GNU Public License.
|
| |
Re:This is just sad... (Score:1)
by Relforn on Sunday December 26, @03:30PM EST (#158)
(User Info) |
I think what you're pointing out, if we carry it just a bit further, is that the GPL will only work in a utopian world.
I don't think that's where you wanted to go with your comment, but it's where your reasoning leads.
Obviously the real problem in this case is that the whole scheme for multiplayer Quake is premised on the source for the clients remaining closed, and as obfuscated as possible.
Carmack should have thought about some of this before setting the source loose 'in the wild' and giving Open Source gaming the black eye it has as a result.
|
Re:This is just sad... (Score:0)
by Anonymous Coward on Sunday December 26, @04:51PM EST (#240)
|
GPL and all the good stuff that has emerged from this will be destroyed by the handful of losers that are determined to destroy (It is always easier to destroy something than to build/create). It gives these people a sense of control in their pathetic little world. Same with hijackers, terrorists, etc. These are lost/lonely people looking to control things around them that make them feel in control in some way/shape/form.
|
Always Happens (Score:3, Insightful)
by Accipiter (shadSowfireP@hotAmail.cMom) on Sunday December 26, @01:15PM EST (#14)
(User Info) http://www.hackphreak.org
|
There's always those select few assholes that have to ruin a Good Thing for everyone. That's not to say this problem with the Quake Open Sourcing wasn't expected....it was. The problem is that it's affecting more people then originally conceived.
ID Software does a Good Thing, and releases the source code to Quake. Then, we have this group of people that change the code to cheat in Quake, making the general public think the Open Source community generally does things like this. Now ID has to play "damage control" and fix the problem, and the community also has to repair the damage done by the cheaters.
Instead of looking for ways to cheat in the game, how about really giving the source a good look and maybe LEARN a couple of things. God knows ID programmers know what they're doing, and that code is bound to have a gem or two in there nobody thought of.
-- Give him Head? Be a Beacon?
(If you can't figure out how to E-Mail me, Don't. :P) |
| |
Re:Always Happens (Score:1)
by itsme on Sunday December 26, @02:16PM EST (#83)
(User Info) http://itsme.ddns.org
|
I think it is an example of the Good opensourcing can do for a product, the security flaws in the quake protocol were already there before the code was released.
This is very similar to someone releasing an exploit to sendmail, and the sendmail people then having to fix it.
The nice thing about being torn to shreds in the cyberjungle, is that you can fix things and try again.
willem
|
Re:Always Happens (Score:2, Insightful)
by matroid (matroid@hushmail.com.noSpammo) on Sunday December 26, @02:21PM EST (#89)
(User Info) |
To play devil's advocate for a bit: it's the assholes like this that drive software development to new levels. The same thing is paralleled in many different areas:
In cryptography: The people who propose new protocols depend on the people who break protocols to make their proposals robust. (Without those crackers we could still be using XOR to encrypt files).
In Science: Science, at the most fundamental level, is about destroying the work of others. One takes a theory and try to find places where it doesn't hold thereby disproving it. Without this process, we would probably still insist the world is on the back of a tortoise.
In nature: Nothing accelerates evolution like preditors.
Cheaters are nothing more than a virus in the open source community. We have no mechanisms of immunity against them. Now is a chance to prove our evolutionary fitness to the rest of the world. Either we adapt and survive these cheaters, or we die out until a better organism for developing software comes along.
The beauty of open source lies in its evolution. Let's evolve.
|
Re:Always Happens (Score:1)
by Relforn on Sunday December 26, @03:35PM EST (#163)
(User Info) |
I don't necessarily buy the idea that ID Software released the source for Quake I "to do a Good Thing."
Isn't it possible that what is happening was expected, and that they're trying to kill Quake I in order to sell the later versions? There are smart people at ID Software, and they're in it to make bux, after all.
|
Re:Always Happens (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @04:01PM EST (#190)
(User Info) http://www.tusa.org
|
I don't think that releasing the source is going to kill Q1 off. Most of the people that I have talked to in the Q1CTF arena have moved to Q3 and come back to Q1. Q3CTF was going to be released by Zoid w/o a grapple. This fact bothers most CTF'ers. In fact, I feel that the entire point of CTF is the grapple (Zoid doesn't share my opinion, but then again I play the game for me, not him). Q3's lag is hard to compensate for (as I mentioned in another post). As a HPB you seem to be moving rather freely and shooting people, but next thing you know, they are a) missing from the spot you just shot, or b) you are dead. You are standing still to those w/better connections but you think you are moving. Q1 even though you were moving SLOW, you at least were actually moving. Standing still during lag is a retarded way to have that go...
I also don't think that this was "expected" and "wanted" so that Q1 would die. There were always people cheating, and there will always be people cheating. It hasn't killed the game yet, and it won't. Q3 had bots available during the test phases, is it going to make us not want to play Q3 when Qx comes out?
-/- Bill -/- |
Re:Always Happens (Score:2)
by Accipiter (shadSowfireP@hotAmail.cMom) on Sunday December 26, @04:11PM EST (#201)
(User Info) http://www.hackphreak.org
|
I disagree. John Carmack openly admits to being a fan of Linux, and the GPL of Quake I shows, at least a bit, of devotion.
Quake 1 has been dead as a business model for years. Releasing the source was more of a contribution to the Open Source community rather than a business move.
Also, ID is smarter than to kill one of their products. Releasing the source does quite the opposite. By giving developers the source code, interest in Quake I has been rekindled, and developments are going to spring up left and right. (Also, if a better version of a product comes out, it's natural to buy the better one over the older one. They'll make their money on the newer versions regardless of the state of the predecessors.)
-- Give him Head? Be a Beacon?
(If you can't figure out how to E-Mail me, Don't. :P) |
Re:Always Happens (Score:0)
by Anonymous Coward on Monday December 27, @11:37AM EST (#427)
|
Huh? id stopped making any significant money off of Q1 quite a while back. And how would "killing" it increase sales of their newer products? Did releasing the source to Doom increase the sales of Quake 2?
|
I am a bot author - and I am outraged (Score:3, Interesting)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @01:17PM EST (#16)
(User Info) http://www.westga.edu/~stu7440
|
I am currently making a client cide interface that will work for all 4 versions of quake. I'm using my own network code on the client and server side of the games. How do you plan to use security by obsurity to block that?
You _can't_ - face it their a *legitamate uses for client side bots. I'm very interested in keeping them alive. Proxy cheat bots are only a small percentage of client side bots - also I've never seen a client side bot that really gave an advandage to the cheater.
John I was very disaapointed when my favorite programmer brought up legal action threats to stop client side bots. John we want to learn more about AI! Your games model real world phyics, so well and have so many variants... please don't do this!
- Mongoose ( from *old planetquake quakeC bot days )
|
| |
They tried to sue you ... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @01:35PM EST (#30)
(User Info) |
... is there more info on this ? I've never heard of this "episode".
Augusto
Flame on ! - Johnny Storm, Fantastic Four |
Re:They tried to sue you ... (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @01:41PM EST (#39)
(User Info) http://www.westga.edu/~stu7440
|
Not me personally, but they did threaten client side authors with legal action. Search blues news for 'proxy cheat'. It should bring the press release up. If it doesn't I can find it and post it here.
|
Re:They tried to sue you ... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @01:54PM EST (#57)
(User Info) |
"proxy cheat" resulted in zero records found at blue's I'll look around the other gaming sites, I've never heard of that.
Flame on ! - Johnny Storm, Fantastic Four |
I spoke to soon! go here to join this source fork! (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @01:59PM EST (#61)
(User Info) http://www.westga.edu/~stu7440
|
http://www.sourceforge.net/project/?form_grp=882
|
Re:I am a bot author - and I am outraged (Score:2, Interesting)
by garcia (garcia@tusa.org) on Sunday December 26, @02:36PM EST (#110)
(User Info) http://www.tusa.org
|
Proxy cheat bots are only a small percentage of client side bots - also I've never seen a client side bot that really gave an advandage to the cheater.
Wrong. VERY wrong. Proxy cheats, a low ping, and *some* skill (this *some* means being able to strafe and dodge incoming fire) will net you a game (that ends at 150 points) where you win by sometimes 60 to 100 points (with decent players). I have used the "stooge" bot before on public CTF servers (not trying to seem good, and only playing under an "assumed name" just testing it). You just see your weapon firing, and you don't know who at. You could be underwater and it will just launch at the nearest person w/the most number of points. If you are a decent player you can rack up several hundred points in only a few minutes (if you are running the flag as well).
Most of the proxy bots depend on ping. You can tell the bot to use some sort of restraint to compensate for high pings, but if you are on DSL or cable, the bot is unstoppable. They NEVER miss. The only way around it is to circle strafe the bot and hope it can't keep up. It normally can.
-/- Bill -/- |
Re:I am a bot author - and I am outraged (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @03:42PM EST (#170)
(User Info) http://www.westga.edu/~stu7440
|
I've seen and played more games with CS bots than you have - I assure you. I was a member of BAG. I know most of the people that wrote bots like stoge, mikebot, and pandora.
Proxy cheats are easy to defeat - and detect. And with voting mods you can ban that user from your game. If you see a guy fire a rail|nail gun from the back of his head, then he's using a client side cheat proxy aka cyborg OR "he" is a very poorly written CS bot driven by AI.
Proxy bots almost never hit a damn thing - they can't lead targets very well or compensate for lag/movement patterns very well either.
If you make asymeterical movement arcs in 3space (not just strafting over level ground) they won't hit you unless you really suck. I'm not saying if you're not torney level you shouldn't enjoy the game either. That's why you have mods that can vote to ban users *per level.
Your statements aren't founded - and you didn't mention "roller ball" CS cheats (the cs player is in a different bsp than the server and can cheat a lot more). Also I personally have been acused of being a bot on LMCTF ( q2 ) by modem players joining a LPB server (95% of clients always had = 100 ping). Make sure you go to a modem only server if LPBs bother you.
|
Re:I am a bot author - and I am outraged (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @03:54PM EST (#182)
(User Info) http://www.tusa.org
|
again, wrong. #1, I don't play Q2, never have, never will. I will probably never play Q3 for the same reason. Realistic looking games are not what I am in them for. Q2 was lacking (IMHO) good gameplay and even though some of this "gameplay" was given back in Q3 I still feel that the overkill in the graphics outweighs any reason to play it (don't say that my computer can't handle the 3D either -- Dual 400 Celeron's, 128mb, 16mb Voodoo3 3k and the r_smp is enabled). #2 -- on any Q1 server I have played on there are NO mods for "voting out" a player. This is a Q2 thing apparently. #3 -- I don't know what you mean by this asymeterical movement arcs in 3space b/c I really don't know how you can move in the air like that w/o grappling, and the second you grapple, you stop long enough for the bot to hit you...
I have been accused of being a bot constantly on public servers... They think cause you can grapple and shoot you are a bot, your statement doesn't impress me. LPB's don't look like bots, bots look like bots. LPB's just move faster. I don't know about Q2, but if it is anything like the lag you get in Q3 I can see where your statements come from. Q1 lag is just making you slow, Q3 you feel like you are moving w/a 30 ping, but you are really standing still to anyone else around you. Rather annoying on both fronts IMHO. Lag should be like Q1, it is much easier to compensate for.
None of my points mentioned in my previous post had anything to do w/fighting LPB's. I was saying that a proxy on an LPB connection will kill faster and miss less than someone w/a slower connection.
-/- Bill -/- |
Re:I am a bot author - and I am outraged (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @06:48PM EST (#309)
(User Info) http://www.westga.edu/~stu7440
|
"there are NO mods for "voting out" a player"
This proves you have little quake experence. All the major mods that released source code had the voting and/or "no bots please" code added.
I forget what was the first mod to do this, as it was years ago. Check the Inside3d website's archives.
" I really don't know how you can move in the air like that w/o grappling..."
Jump or run across slanted ground. Have you played quake much?
"Q3 you feel like you are moving w/a 30 ping..."
It's called client side prediction, and started with QW beta. It's nothing new at all, and we're discussing QW as much as Quake. This is an design issue in any event.
Your statement about LPB CS bots applies just as well to humans - some people are just that good. The only way to detect a cheat proxy for certian is to see a fire frame unsynced from the player movement - this is caused by forcing the server to "spin" the player and fire in 1 frame and then return the player back to normal postion the next.
If you still think CS bots are unbeatable I'll volunteer to play a server full of them and prove you very wrong. Email me - this thread is going off topic.
|
Re:I am a bot author - and I am outraged (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @07:00PM EST (#312)
(User Info) http://www.tusa.org
|
"there are NO mods for "voting out" a player"
Not on any CRCTF Q1CTF servers or any of the public servers I play on...
"no bots please" code added.
yep, some of them can detect proxies, or other bots, but they don't catch them all.
Jump or run across slanted ground. Have you played quake much?
doing either of these won't stop it. Jumping doesn't make you go high enough for the splash to miss. Running across slanted ground? Most levels I play in Q1 don't have much, and most of the proxies I have played against it doesn't matter. They will STILL hit you. Your position on the ground doesn't matter. It knows where you are.
Yes, and that was quite insulting. I am not the best, nor did I ever claim to be. You apparently haven't played much IMHO if you think that they can't hit you.
Your statement about LPB CS bots applies just as well to humans - some people are just that good.
most proxies don't turn and shoot, so the rockets come out of their ass. They aren't that good, I'm sorry. You're again wrong. xUx, CO, etc, none of them can shoot out their asses.
You couldn't beat me GUARANTEED w/me having a 30 ping, a fast grapple, and a proxy.
-/- Bill -/- |
Re:I am a bot author - and I am outraged (Score:2)
by WNight (wnight@rocketmail.com) on Monday December 27, @05:29AM EST (#406)
(User Info) |
Your comments about proxy bots are... unimaginative.
I can find a poorly written proxy bot that I can kill by exploiting obvious weaknesses, but that doesn't mean all proxy bots have to be that flawed.
The fire-frame-unsync you mention is a 'bug' in Quake and Quake2 (perhaps in Quake3) where certain animations override others. For instance, everyone in Q2 slid when they ran and fired, because there wasn't a proper running & shooting animation... There's no reason a bot's shots would look different from those of a players, the network code is the same after all, if there wasn't a complete spin in there, which only happens if the bots are given a 360 degree field of view.
A 'skilled' bot operator runs a bot with a much smaller field of view, and plays an intelligent game as well. They aren't so easy to spot, or kill.
I personally doubt you could kill a 360-degree viewing z-bot in q2dm1, with a semi intelligent player (ie, grabbing the odd bit of health). Your only strategy would be to stock up on armor to try to take enough rail hits to give you time to brute-force it to death.
And I know you couldn't take on a reasonably skilled player using the zbot 'intelligently', and subtly enough to not be noticed as a bot.
If bots are programmed to expect movement in straight lines, then parabolic curves will fool them, and jumping will make them miss. If you teach them about parabolic curves, then they'll hit jumpers. Air control will still avoid their shots, until they are programmed to cope with it. Anything you can do can be programmed into a client-side bot. Eventually the only thing you'll be able to do is dodge randomly and hope that the bot's lag keeps it from tracking you.
|
Re:Cheat bot authors suck (Score:0)
by Anonymous Coward on Sunday December 26, @05:37PM EST (#274)
|
Bots to play against in a single player game or to fill out a less than full server are okay. Bots that allow lame players to rack up big frag counts suck... period.
|
Re:I am a bot author - and I am outraged (Score:0)
by Anonymous Coward on Sunday December 26, @07:00PM EST (#313)
|
>You _can't_ - face it their a *legitamate uses
>for client side bots ... Proxy cheat bots are
>only a small percentage of client side bots
If you define bots as client side proxies then
this is certainly true (just think of proxies
like cheapo or qizmo). Normally if we talk about
"bots" we mean proxies that help you to aim.
>also I've never seen a client side bot that
>really gave an advandage to the cheater.
Hehe, this is hilarious. It seems that you don't
have much experience with REAL cheat-proxies. ;-)
>John we want to learn more about AI!
If you want to learn about AI then write a book
or write a serverside bot. I totally understand
and support ID if they want to sue people who
write cheatproxies and release them to the public.
|
Re:I am a bot author - and I am outraged (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Sunday December 26, @10:30PM EST (#353)
(User Info) |
Not to disrespect ID too much, cause they truly are a good company. Sueing to prevent people from cheating is shitty.
|
Yeah (Score:0)
by Anonymous Coward on Monday December 27, @02:22PM EST (#452)
|
It's shitty - for the cheaters.
|
Re:I am a bot author - and I am outraged (Score:0)
by Anonymous Coward on Sunday December 26, @07:52PM EST (#327)
|
"I've never seen a client side bot that really gave an advandage to the cheater." If this is true, then why do so many people use them? Because they don't work? Please. It seems obvious to me your only interest is not in learning anything about AI, but in trying to justify your own cheating. Very lame.
|
Here is a link to a listing of legitamate CS bots (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @09:11PM EST (#339)
(User Info) http://www.westga.edu/~stu7440
|
Goto http://www.planetquake.com/botshop then goto to ( Clients ) link.
I'm amazed at everyone acusing me of making a cheat proxy. I've written serverside and clientside bots, but I've never released CS code. I will be releasing CS code ASAP. Client side cheats aren't effective to any degree more than having a low ping or camping. I notice everyone posting otherwise is AC.
|
Re:Here is a link to a listing of legitamate CS bo (Score:0)
by Anonymous Coward on Monday December 27, @02:29PM EST (#453)
|
>Client side cheats aren't effective to any >degree more than having a low ping or camping. LOL! Maybe YOUR CS cheats aren't effective. There are proxies out there that you don't even know about, that have features you can't even think about. And you really can't compare cheats to low pings or camping. If you take football that's like comparing a defensive tactic (camping) or a better team budget (ping) to doping (CS cheats).
|
Why... (Score:1)
by punkass (punkass@yourdoorstep) on Sunday December 26, @01:21PM EST (#19)
(User Info) |
...would a closed source solution...any solution...be bad?
Just a thought...
"Nobody owns the fucking words man." - James Dean |
| |
Re:Why... (Score:0)
by Anonymous Coward on Sunday December 26, @03:40PM EST (#167)
|
Because in these parts, Closed Source is eeeevil! Eeeeeeevil!
All hail King Peer Review! And may we elite always be the Peers!
(don't mistake this usage with credentialed academic 'peer review.' Here we're talking about setting the ant farm loose crawling through the source code)
|
It's the only way (Score:3, Interesting)
by CentrX (centrx@usa.net) on Sunday December 26, @01:21PM EST (#20)
(User Info) |
I was actually thinking about this some time ago and I concluded that the only way to have no one be able to cheat is with a closed-source system of checking. A good system would make it possible for the server to add 'known good clients' i.e: clients that they know don't cheat.
Contrary to what some others are saying, this would not stifle open-source gaming as the only closed-source part would be the executable that checks to make sure there's no cheating. If only this were closed-source, the rest could be made open-source. I believe that this method would actually increase the proliferation of open-source games.
Chris Hagar
"It is only the great men who are truly obscene. If they had not dared to be obscene, they could never have dared to be great." - Havelock |
| |
No "only way" (Score:1, Insightful)
by Anonymous Coward on Sunday December 26, @01:52PM EST (#54)
|
You obviously haven't thought hard about this. How can the server identify "know good" clients, considering that all of the information it gets comes from the client. Whatever the "known good" clients do to prove that they are "known good", I have my cheat client do the same thing.
You haven't even described the exact mechanism of this executable, but what I think you mean is fundamentally impossible.
|
Re:No "only way" (Score:1)
by CentrX (centrx@usa.net) on Tuesday December 28, @11:38AM EST (#476)
(User Info) |
The executable was described my Carmack, didn't you read that?
Chris Hagar
"It is only the great men who are truly obscene. If they had not dared to be obscene, they could never have dared to be great." - Havelock |
Re:It's the only way (Score:1, Insightful)
by Anonymous Coward on Sunday December 26, @02:01PM EST (#63)
|
Actually, it's not the only way. Another solution is to give the client exactly the same information as the player's character should have. Similarly, the server must only allow the client to control actions that the character is able to perform. We're using this approach effectively in the MUGU Project (GPL code for both server and clients). I assume it wouldn't be practical to convert Quake to use this approach, but I offer it so anyone concidering a new Open Source game knows that other options exist. Note of course that the solution I offer requires extra computation on the server side, but I think the benefits are worth it. Kas (sorry, I don't have a /. login handy)
|
Re:It's the only way (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Sunday December 26, @02:08PM EST (#73)
(User Info) http://www.lucid.dyndns.org
|
I was actually thinking about this some time ago and I concluded that the only way to have no one be able to cheat is with a closed-source system of checking.
You know I'm sitting here thinking about this and I don't think this is so.
That's one way to do it, however, another way would be to have all damage allocation from weapons, and all damage recieved to armor, health, etc, be done at the SERVER side and not the client. Offload all the cheatable stuff to the server, that way hacking the client is useless because the client isn't the one doing all the damage assessment.
I know this would totally break the Quake protocol and would require enormous rewrites to both the quake client and server, but it's doable, and you can keep everything open source, the only problem now is people having cheat servers. :)
It would probably increase lag aswell, as the client would have to check with the server to see if it was allowed to do anything (ie: walking [server wouldn't let client walk through walls], firing weapon [server would have to make sure client had enough ammo], etc.) but with broadband hitting almost everywhere now, maybe it won't be such a problem in the future.
-- iCEBaLM
|
Re:It's the only way (Score:1)
by Fizgig on Sunday December 26, @02:18PM EST (#86)
(User Info) |
But there are more ways to cheat than that. What if I adjusted the Quake client to have all bad guys appear as bright red, no matter what the lighting. You certainly can't handle that server-side, and it's definitely cheating.
-- Fizgig, devourer of worlds . . . and beignets |
Re:It's the only way (Score:1)
by VinceJH (vharvey@[SPAM]enteract.com) on Sunday December 26, @04:32PM EST (#222)
(User Info) |
Funny thing is that the original closed source quake would let you easily do that. You just had to change the skins on your models to use fullbrights. I guess the client should have gotten md5sums from all the files before it started to make sure this didn't happen.
I know I will be moderated down for this, but . . . Vincent |
No solution (Score:2)
by Hard_Code on Sunday December 26, @02:20PM EST (#87)
(User Info) |
There really is no way at all to prevent hacked clients as long as the server trusts the clients. The only way for the server not to trust the clients would be to offload everything to the server except inputs, which makes the client effectively just a remote viewer. Of course this is obviously impossible because it would render the game absolutely unplayable. Everything is "cheatable" basically, except the inputs. Making a closed source proxy won't work either, since the proxy can just be hacked. It is a stop-gap measure, but I think it won't really work. If the closed source proxy relies simply on a digest, it is trivial for any cracker, not to mention most pedestrian programmers, to hack the proxy to return one of a list of known valid digests, or simply use mechanisms of the os to fool the proxy (point it to a valid copy, but make it run the hacked one). There really isn't any way to stop it at all, except to just rely on the honesty of the Quake gaming community, and give a big fat walloping kick and ban to assholes found cheating.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:No solution (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Sunday December 26, @02:42PM EST (#121)
(User Info) http://www.lucid.dyndns.org
|
There really is no way at all to prevent hacked clients as long as the server trusts the clients.
Well thats what I'm talking about. Since the clients are open source why should the server trust all the clients? The server should rightly assume all clients are hacked.
The only way for the server not to trust the clients would be to offload everything to the server except inputs, which makes the client effectively just a remote viewer. Of course this is obviously impossible because it would render the game absolutely unplayable. Everything is "cheatable" basically, except the inputs.
Well, all the maps, skins, etc would be local, the client would be doing all graphics rendering. I'm not suggesting something like X where the entire graphics output is displayed over the network. More along the lines of IRC, where the server checks everything the client does and "allows" it to do operations, or disallows it to do operations (can't join a channel you're banned from, etc).
Such as, say you wan't to fire your shotgun at AC_QuakeWeenee but you don't have any shells left, server doesn't know you have a hacked client which gives you unlimited ammo however, but it doesn't matter, the server would keep track of the clients ammo, and would disallow it from firing (maybe not on the clients machine, but to everyone else, the cheater never fired).
As for damage, let the server deal that out too, I mean come on, this is what servers are FOR.
There's absolutely no reason why this stuff shouldn't be offloaded to the servers. If you only have to worry about cheat servers, then that decreases the overall amount of people that can possibly cheat, and if you find one, just switch servers.
I know this isn't perfect. Someone brought up the idea of hacking the client to make all enemies glow red regardless of lighting or other visual hacks, well sure you can do this, but it's a lot less then being able to increase your damage or give yourself unlimited ammo or such.
-- iCEBaLM
|
Re:No solution (Score:2)
by Hard_Code on Sunday December 26, @02:55PM EST (#135)
(User Info) |
"Such as, say you wan't to fire your shotgun at AC_QuakeWeenee but you don't have any shells left, server doesn't know you have a hacked client which gives you unlimited ammo however, but it doesn't matter, the server would keep track of the clients ammo, and would disallow it from firing (maybe not on the clients machine, but to everyone else, the cheater never fired)."
I still think this would work in real life because of latency issues. Remember, clients like Quakeworld do all sorts of predicting. To make the game seem smoother, they automatically respond to your actions on your screen before syncing with the server. Imagine if you had to wait to see your shotgun fire until a round trip was made from your Ctrl keypress to the server and back so it could determine if that was a valid thing to do. Of course you could let clients go ahead and display actions regardless of the server's decision to honor them...that may work.
Also, as you mention, if the user is in control of the client, and the client "knows" everything about the game, there is absolutely nothing stopping somebody from hacking a client to help themselves without touching the protocol at all. Making enemies glow red, automatically dodging rockets...client bots are designed around this very thing...they are allowed to "know everything". There is going to be no stopping that even if things are offloaded to the server.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:No solution (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Sunday December 26, @03:11PM EST (#146)
(User Info) http://www.lucid.dyndns.org
|
I still think this would work in real life because of latency issues. Remember, clients like Quakeworld do all sorts of predicting. To make the game seem smoother, they automatically respond to your actions on your screen before syncing with the server. Imagine if you had to wait to see your shotgun fire until a round trip was made from your Ctrl keypress to the server and back so it could determine if that was a valid thing to do.
No, No, thats why I said "maybe not on the clients machine, but to everyone else, the cheater never fired".
The client would see himself firing, HOWEVER, once that command got to the server, the server would check it to make sure he had enough ammo, if not, drop the packet and no one else sees him fire, if he has enough ammo, broadcast it to everyone else, deal out damage if necessary, etc.
Also, as you mention, if the user is in control of the client, and the client "knows" everything about the game, there is absolutely nothing stopping somebody from hacking a client to help themselves without touching the protocol at all. Making enemies glow red, automatically dodging rockets...client bots are designed around this very thing...they are allowed to "know everything". There is going to be no stopping that even if things are offloaded to the server.
Yes, this is a problem, but all this can already be done in mods without having to hack the client, in Quake anyways. The trick is just letting the client know enough so it can play the game, and no more. I didn't exclaim to know all the answers, just a partial solution which, IMHO, should have been done ANYWAYS.
-- iCEBaLM
|
Re:It's the only way (Score:1)
by ArsonSmith (arsonsmith(at)hotmail(dot)com) on Sunday December 26, @02:25PM EST (#94)
(User Info) |
How about if instead of all damage/movement/ammo/armor etc handled by the server what if the server just had a way of checking as the game was being played. then labeling someone as a cheater. this could acually be kind of fun if the server then had a way of lowering someones stats without their client knowing it and marking them with bright pink paint and a sign that says cheater on top or something.
Just my input on this
spelling is optional
ArsonSmith
-- The ability to monopolize a planet is insignificant next to the power of the source. |
Re:It's the only way (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Sunday December 26, @02:50PM EST (#129)
(User Info) http://www.lucid.dyndns.org
|
How about if instead of all damage/movement/ammo/armor etc handled by the server what if the server just had a way of checking as the game was being played. then labeling someone as a cheater.
Well as far as I know all movement is already handled by the server (this is why on slow links you get an "ice skating" effect), the damage and everything has to go through the server anyways as the clients are not directly linked, so why can't the server correct the values?
I like your idea coupled with mine, you'd see everyone in a mad rush to frag the cheater :)
-- iCEBaLM
|
AAAAAAAAARRRRRGGG (Score:0)
by Anonymous Coward on Sunday December 26, @07:09PM EST (#318)
|
People should be forced to read the QW-Protocol specification before they contribute to this forum! The situation is: the server DOES actually all the damage/movement calculations! All the client does is input and rendering (in QW it with prediction).
|
Re:AAAAAAAAARRRRRGGG (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Thursday December 30, @01:32AM EST (#483)
(User Info) http://www.lucid.dyndns.org
|
People should be forced to read the QW-Protocol specification before they contribute to this forum! The situation is: the server DOES actually all the damage/movement calculations! All the client does is input and rendering (in QW it with prediction).
Uhm, We're talking about Quake 3 here...
And if this is so in Quake 3, how are hacked clients able to increase damage?
-- iCEBaLM
|
Re:AAAAAAAAARRRRRGGG (Score:2)
by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Thursday December 30, @01:35AM EST (#484)
(User Info) http://www.lucid.dyndns.org
|
Ugh, brain fart, this is a day or two after the discussion and I forgot what it was about, indeed, this is Quake.
Now, if that's already done, how is the client able to increase the damage?
-- iCEBaLM
|
Re:It's the only way (Score:0)
by Anonymous Coward on Sunday December 26, @07:41PM EST (#322)
|
> That's one way to do it, however, another way
> would be to have all damage allocation from
> weapons, and all damage recieved to armor,
> health, etc, be done at the SERVER side and not
> the client
All these things are ALREADY handled by the server in both quake and quakeworld. (as long as it's not a hacked server) Otherwise people would have hacked clients with 'god mode' enabled.
-Tony
|
just have client version report more data (Score:3, Interesting)
by poopie on Sunday December 26, @01:23PM EST (#21)
(User Info) |
I really don't think this is such a big deal... It's a game, for pete's sake! When people start earning salaries for their quake performance, then maybe we need to worry about this.
It's been my experience that cheating in these games really isn't much fun (unless your really stuck and about to give up on the whole game), and I don't think that others would want to play with cheaters unless they were cheating too, which would make the game fair again, I suppose.
With the source, it's pretty trivial to undo just about any protection and spoof any values the program expects to find, so why bother?
I fear that by putting in encryption and protection schemes, we'll be hindering potential development of new variations and play modes of quake and quake derivative games. If altered clients could be used to introduce a handicap factor into games, it might encourage gameplay between experienced and less experienced players.
Why not add a HANDIcAP FACTOR to the quake game, and have that be shown for each player when joining a new game? It's probably easier to deal with cheating by making it a defined feature than trying to protect against it ever happening.
|
| |
Re:just have client version report more data (Score:1)
by Ånubis (adhintz@I.H8.SPAM.mail.utexas.edu) on Sunday December 26, @01:28PM EST (#25)
(User Info) http://www.ece.utexas.edu/~hintz/
|
| "Why not add a HANDIcAP FACTOR to the quake game" Simply introducing a handicap feature wouldn't stop any of the cheating. People would simply modify the code so that their handicap gave them more of an advantage than normal.
|
Re:just have client version report more data (Score:2)
by Hard_Code on Sunday December 26, @03:00PM EST (#140)
(User Info) |
I agree that imposing some convoluted (and utltimately impotent) form of security might just stub development. Keep it open and keep it simple. People will always cheat and it won't be possible to stop them, even with proprietary code. It should be pretty easy to spot cheaters, and if it is not then is it really a problem? So let some guy see through walls as long as he's not disrupting gameplay. The moment he does something shady to disrupt gameplay, off he goes.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:just have client version report more data (Score:0)
by Anonymous Coward on Sunday December 26, @08:40PM EST (#333)
|
| "I really don't think this is such a big deal... It's a game, for pete's sake! When people start earning salaries for their quake performance, then maybe we need to worry about this." Translation: It's only OK to make this a big deal when money is at stake. Yeah... uh, right :S
|
Re:just have client version report more data (Score:0)
by Anonymous Coward on Monday December 27, @11:51AM EST (#430)
|
| I assume you disagree - why? It's just a game - there is nothing at stake... nothing. Which asks two questions: 1) Why would go to the trouble of scouring source code in order to cheat on a 3.5 year old game that very few people care about any more? 2) Why would there be 400+ posts about this topic on slashdot, as there is very little significance at all?
|
An opportunity, perhaps? (Score:2)
by Brian Knotts (bknotts@europa.com) on Sunday December 26, @01:23PM EST (#22)
(User Info) http://xfmail.slappy.org/
|
Perhaps this is an opportunity to come up with an open source solution to this problem. I'm not sure what that solution is, but if there is one, I feel certain that someone in the Free Software world will find it.
New XFMail home page
|
So this is the benefit of Open Source eh? (Score:1)
by Dj (dj@evnull.removethisbit.com) on Sunday December 26, @01:24PM EST (#23)
(User Info) http://www.waitstate.com/
|
The ability to make "Unlimited technical changes" is what Richard Stallman demanded for Java... Now here in another arena we see what that means. These are just technical changes so you can't deny people the option of doing them under the RMS ethos. Cheating? No no, just creating an advantage. Pity it destroys all the intangibles of the culture like "fair play". Oh, other people could "cheat" too but now we're in a fragmentory arms war. Carmack's solution of, well, nearly certifying games as fair/allowed to play is doubly ironic when mapped on the idea of a GPLing or Open Source (Debian OSD stlyee) Java.
Dj "Spare me the Gen-Y Irony... I'm in pain here!"-Doonesbury |
| |
Re:So this is the benefit of Open Source eh? (Score:1)
by limpdawg on Sunday December 26, @01:51PM EST (#52)
(User Info) http://slashdot.org/comments.pl?sid=limpdawg
|
How does this make freeing java bad? You really can't cheat in java, you could make your vm faster but that benefits everybody if it's gpl'd because you have to release your changes.
|
Re:So this is the benefit of Open Source eh? (Score:1)
by Dj (dj@evnull.removethisbit.com) on Sunday December 26, @01:56PM EST (#58)
(User Info) http://www.waitstate.com/
|
You can add non-standard extensions which applications demand and which have to be added to other peoples VMs... even releasing the code to them still leaves every VM maker in the world playing catch up.
Dj "Spare me the Gen-Y Irony... I'm in pain here!"-Doonesbury |
Re:So this is the benefit of Open Source eh? (Score:1)
by Relforn on Sunday December 26, @03:49PM EST (#177)
(User Info) |
Yes, this does present an interesting problem.
In modern computing, it seems like Game development plays a leading role. Driving the development of new high end (relatively speaking) hardware.
Maybe this whole issue ultimately shows that the whole GPL scheme is utopian and doesn't scale well to the real world in which everybody doesn't consider themselves the 'member of a community,' where there isn't a 'peer review' process that encompasses the whole. Only time will tell, but so far it doesn't look good.
|
Re:So this is the benefit of Open Source eh? (Score:0)
by Anonymous Coward on Sunday December 26, @04:44PM EST (#235)
|
youve got a free C, C++ and Java compiler, free operating systems, free GUI/devel environments, tons of free tools, free games and you say it doesnt look *good* ? what are you - braindead ?
|
Offtopic: Anyone heading a pure linux fork of QW? (Score:0)
by Anonymous Coward on Sunday December 26, @01:26PM EST (#24)
|
I'm wondering if anyone has started a project for QW development. I'd like to help in getting fixes and code attentions into a "major" fork. I already know of a dozen people with different trees.
We need a major linux fork, before QW becomes as forked as BSD!
----------
OpenProjects #debian - we love you
|
| |
Re:Offtopic: Anyone heading a pure linux fork of Q (Score:1)
by Relforn on Sunday December 26, @03:54PM EST (#181)
(User Info) |
We need a major linux fork, before QW becomes as forked as BSD!
Yes, we need to make sure that the Linux system and userland doesn't 'fork' into dozens of distributions, unlike the Net\Free\Open\BSD userland, which has 'forked' into three.
|
What about Cryptographic solutions (Score:2, Interesting)
by NateTG on Sunday December 26, @01:28PM EST (#26)
(User Info) |
There's got to be some way to verify the Quake exe using hashes etc. Maybee not the whole program, but just a small "subprogram" that can be verified directly via the connection, then it verifies that the whole .exe is untampered (for modded games, just compare MD-5's with each other) so that you know when the other guy has tampered with things.
Now, I suppose that this is not really a whole lot better since the verification system can be bypassed, but at least it should provide for some control mechanism which can then be altered, or improved untill it works.
|
| |
Re:What about Cryptographic solutions (Score:0)
by Anonymous Coward on Sunday December 26, @01:40PM EST (#37)
|
Yeah, and then we could have another program that verifys that programs integrity, and then another meta-program for security and so on and so on...
|
Re:What about Cryptographic solutions (Score:1)
by Keeper ofthe Keys (cmaxwell (@) themanor.net) on Sunday December 26, @01:44PM EST (#43)
(User Info) http://www.themanor.net
|
The problem really goes back to the integrity and honesty of the players. A dishonest player can easily bypass a hash by simply generating it before doing any mods to the client engine, and using the old hash to fool any verification system.
A trust ranking, kind of like e-bay user comments would work some of the time, but there is no absolutely secure way to verify an open-sourced game. The only way to know you're playing fair is to trust the other player.
|
Re:What about Cryptographic solutions (Score:0)
by Anonymous Coward on Sunday December 26, @04:01PM EST (#189)
|
The only way to know you're playing fair is to trust the other player.
Yes, as has been pointed out earlier, the GPL doesn't scale well beyond a tight "community" of people who know and trust one another.
Oh well...
|
Re:What about Cryptographic solutions (Score:0)
by Anonymous Coward on Sunday December 26, @04:46PM EST (#236)
|
huh ? what does the GPL have to do with it ? the same problem is also in the BSD license or any other.
|
Re:What about Cryptographic solutions (Score:0)
by Anonymous Coward on Sunday December 26, @06:19PM EST (#295)
|
No, with the BSD license you can produce closed-source components that do the verification. This puts the bar for cheating back at "people who can use a disassembler", whereas the GPL forces it to be at "people who can type 'make'".
|
Re:What about Cryptographic solutions -- Update (Score:1)
by NateTG on Sunday December 26, @05:40PM EST (#276)
(User Info) |
I was just reading through a comment above, and the following ocurred to me:
If both ends record events and send them as part of the protocol then it should be possible to have your client check that the behavior is consistent with the model. This could cost some significant bandwidth especially in large games.
Since AFAIK the bottleneck is actually network bendwidth, the compute time may not be an issue.
Now, if someone writes a client that produces keystrokes such that the enhanced activites are accounted for, then that client will effectively be a macro box.
This doesn't account for modified clients which allow you to see through walls or such, but it's a beginning. Although if you were concerned, you could watch the movie generated by the other guy's keystrokes and check if it mae sense/ was legal.
|
Re:What about Cryptographic solutions (Score:0)
by Anonymous Coward on Monday December 27, @04:30AM EST (#402)
|
Anything anywhere on a computer can be faked.. so what it comes down to is who can you trust: The Client or the Server. Any client side software responses can be faked (track the outgoing traffic locally or isolate it from a gateway, repeat it.). The server side solution is the only one that gives a the chance of a fair fight. Make all the decisions on damage and movement on the server (or fake them on the client then with server response 'correct' the client) so clients have as little control as they should. Verifying client files won't be a permanent solution, but unfortunately the avg bandwidth can't take what everyone's suggesting.
|
This is NOT an Open Source problem (Score:1)
by AmirS on Sunday December 26, @01:29PM EST (#27)
(User Info) http://www.shams.demon.co.uk/
|
This is instead a problem in game design. The only realistic way to stop this is to design the game
and network protocol so that the server only allows valid events to happen.
Obviously this some glaring drawbacks, like the server suddenly needs more horsepower, and hacked/insecure servers are no use, but that's a problem anyway. Also, it's too late to redesign all of quake so the server prevents any cheating, but this should be kept in mind when designing future open source games.
Another idea to toy with (which obviously haven't thought about) is to use encryption systems to validate every event, but not being a crypto-god, I don't know how exactly this would be done. It should allow for distributed servers however to work together, as there would be much harder for a server to cheat. Obviously this would also require lots of computing power for servers and clients though.
In short, games can be designed so cheating can't happen, but (as far as I can see) this needs more computing power. A quick fix is to make the game closed source so it can't be easily hacked.
- c.f. security through obscurity and security through openess.
|
| |
Doesnt work like that over the internet (Score:0)
by Anonymous Coward on Sunday December 26, @04:54PM EST (#242)
|
Of Quake1/world/2/3 the one coming closest to that is Quake1, that should tell you something.... its just not an option. If everyone has a 30 msec ping and high bandwith connection it might, so it doesnt.
And it does not combat the problem of borging/botting, I could always do pattern matching on framebuffer data and provide straight keyboard input... how you gonna fix that without sitting next to me?
|
Re:This is NOT an Open Source problem (Score:1)
by crt (wrightd@gamespy.com) on Sunday December 26, @09:10PM EST (#338)
(User Info) http://www.gamespy.com
|
The server can never tell what exactly to expect from the client. After all, all players aren't the same. A good player's data will look at lot different than a bad player's data, and a bad player with a good bot will look a lot more like a good player than something totally random. Yes, you should put as much control in the hands of the server as possible -- for example, allow the client to only define it's velocity and orientation, not position, and bounds check those numbers -- but Quake already does this. The problem is bots that make you aim more accurate or turn around faster... not faster than humanly possible, just better than the luser using them. There is a solution for this problem -- but it won't work with Quake. For games that use CD Key systems (like Half-Life) you can ban players on the server by their CD Key. So as soon as you identify a lamer using some kind of bot, you can ban them from your server, and trusted server admins can share their ban lists. This works even in an open source scenario. Why? The server never knows the actual CD Key, just a hash of it. So the server can ban CD Key hashes, and this works as long as clients are required to use a validation server to validate their CD Keys. A hacked client cannot get around the validation server, even if it's open source. (I'd be glad to follow up with any game developers that have questions about it).
|
This is an Open Source problem (Score:0)
by Anonymous Coward on Monday December 27, @02:35PM EST (#454)
|
| As far as the server knows, auto-aiming and auto-ducking ARE valid events. In order to render an image of an opponent, the client needs to know exactly where that opponent is. If I modify the the client to always aim my weapon exactly at the opponent (+/- a random error factor to throw it off) I get a big advantage. Likewise, if I modify the software to detect any projectiles that may damage me and move me out of the way, I get a big advantage. The other problem is with network latency/round trip time. Calculate everything on the server side, and the playability of the game suffers.
|
glibc2.1 build (Score:1)
by fsck (hey@fsck.you) on Sunday December 26, @01:30PM EST (#28)
(User Info) |
Can anyone get this to build on glibc2.1? How about setting up a contrib somewhere so those of use who cant, can play. (the retail release is libc5)
|
| |
Re:glibc2.1 build (Score:1)
by Mongoose (stu7440@no.spam.westga.edu) on Sunday December 26, @01:49PM EST (#50)
(User Info) http://www.westga.edu/~stu7440
|
Yeah - read this: http://www.planetquake.com/botshop
I got it working, and I guess *I'll start the first fork if no one else will. I can't verify that the GL clients build correctly, as my Mesa development kit is screwed at the moment. I have the source reordered like a proper OS project and a new Makefile for QW - I'll post it on my site when it's ready.
FYI, another guy on OP #debian has it running - if you're running debian you'll have a time getting your development kit correct - you need both ggi mesa and mesa development kits. I'm working on a solution.
|
Quake1 players (Score:0)
by Anonymous Coward on Sunday December 26, @01:37PM EST (#34)
|
Good maybe everyone still playing Quake1 will finally have a reason to stop.
|
| |
Re:Quake1 players (Score:0)
by Anonymous Coward on Sunday December 26, @04:04PM EST (#193)
|
Yep.
Carmack did ID Software a big favor by killing Quake 1 this way. Now they can stand at the cash register and bring in the cash from all the players forced to upgrade to Quake II or III.
|
Yep - all three of them. (Score:0)
by Anonymous Coward on Monday December 27, @11:59AM EST (#434)
|
C'mon - there are *very* few people who play Quake 1 with any frequency who don't already own Q2 or Q3 as well.
|
Open Source is not the problem (Score:5, Insightful)
by Python (python@freedom.gmsociety.org.NOSPAM-BADSPAM) on Sunday December 26, @01:39PM EST (#36)
(User Info) http://freedom.gmsociety.org
|
| Open Sourcing the Quake code is not what caused the cheating. If that were the case, no security flaw in any closed source product would ever come to light. And yet they do. I'm disappointed in slashdot for perpetuating such a myth. Opening the source does not create the security hole, it just makes it easier to find it and fix it. So, this is really yet another example, in a long an sordid history, of why building a security model that depends on the client to be honest in a client/server model is a Bad Idea[TM] (can anyone say rexd?). Closing the source would be nothing more than security through obscurity. I guess its time to open that can of worms again and kick that dead horse around. There were cheats before they opened the source, their were cheats for UnReal and I'm sure their are cheats for other games as well. Anytime you rely on the client exclusively to report valid values you shift trust into an untrusted space. The users machine is not trusted, so why does it suprise anyone that someone would cheat? Why is it suprising that its possible? Its possible whether you open or close the source. This bears repeating, trusting an untrusted system (the client) to report trusted values is not possible! Thats the problem. Not the fact that the source is open, its the fact that the client is so implicitly trusted to report valid values. Hopefully the ID folks will realize that if they want to stop cheating. Preventing cheating in the client alone is never going to work. It will of course take some more work on their part, but its been done correctly before and I'm sure they can do it too. If they're smart they'll embrace this and work with the open source community to get it fixed.
--
Python
"Linux, the last service pack you'll ever need." |
| |
Re:Open Source is not the problem (Score:2)
by ARRAY(0x0) on Sunday December 26, @02:21PM EST (#91)
(User Info) http://snaught.com/JimsWewb/
|
Exactly. By closing the source, you simply make it harder to expose weaknesses to either the potential cheater and potential developer/auditor. Who do you think will make the extra effort? Remember the supposed "Russian super computer" on distributed.net.
|
Re:Open Source is not the problem (Score:0)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @04:06PM EST (#196)
(User Info) http://www.phish.net
|
i disagree, this seems like one of those instances it wont work. jc is right, with the source open and me being able to enter as a server op "if name == mine, scale damage by 75%", i think this is one instance [there are several, alot more than OSS i believe] that closed source development is preferable because of the reasons i stated in another post:
-no clear leader for development [carmack is certainly not gonna continue develepment]
-no standardation of versions, new features added break network compatability
-cheating
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
Re:Open Source is not the problem (Score:2)
by _Sprocket_ on Sunday December 26, @04:48PM EST (#237)
(User Info) |
i disagree, this seems like one of those instances it wont work. jc is right, with the source open and me being able to enter as a server op "if name == mine, scale damage by 75%", If I understand this argument correctly, you're stating that open source servers allow for cheating servers. The trouble with this argument is that so do closed source servers. Cheats within this environment already exist for closed source clients. Thankfully, servers are often modified to detect these modifications to the client. Thus, as cheats become common, they also become a moot point. What's to say someone willing to put forth effort to modify a client can't also put effort towards modifying a server? I'm not aware of a client that looks for a cheating server. The point is that you will have to trust that server - open source or closed source. For now. i think this is one instance [there are several, alot more than OSS i believe] that closed source development is preferable because of the reasons i stated in another post: -no clear leader for development [carmack is certainly not gonna continue develepment] -no standardation of versions, new features added break network compatability -cheating And this is the challenge for open source developers to pick up if they so desire. Whoever begins putting out good fixes to the issues the Q1 environment has will naturally take the lead in development as more people decide to use/support that code base. Versions will be standardized since servers will likely only support clients comeing from trusted developers. And players are likely to only support servers that help guarentee a fair game. Cheating is one of the problems that need a solution - something I'm sure will be fixed. Open source progects have taken on other difficult tasks before and succeeded. Of course, the origional point was that closed source environents detur cheating. Not so. Remember, client cheat hacks have shown up in the Q1 environment while the source was closed.
|
Re:Open Source is not the problem (Score:1)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @05:16PM EST (#260)
(User Info) http://www.phish.net
|
your right the client right now must trust the client, even running the 'vanilla' server. mea culpa, the point i was trying to make is that you can cheat with the client too, and i did make that clear at all. but you continue to say that these problems will soon be fixed and its no big deal, i disagree. you offer no new suggestions. bring something new to the arguement ;). the best solution ive heard talked about is the system netrek uses.
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
Re:Open Source is not the problem (Score:2)
by _Sprocket_ on Sunday December 26, @09:12PM EST (#340)
(User Info) |
but you continue to say that these problems will soon be fixed and its no big deal, i disagree. you offer no new suggestions. bring something new to the arguement ;) Actually, the point I was making isn't that its no big deal. It is. Its a big issue with no quick fixes. Alas, I have no brilliant fix to offer right now. However, the point as I understood it correctly, is that open source won't work in this kind of environment and closed source will. That's the point that I disagree with. As I stated, even with closed source there has already been cheats. Closed source didn't buy us any security then. My suggestion is that open source will help lead to a fix if there is one to find. I don't have the fix. But I alone don't need to. Those who are interested in this problem will get togeather and they'll work to solve it. Open source progects have tackled some weighty problems in the past successfully. There's no proof that such an approuch has less of a chance coming up with a solution than a closed source model does. Alow me to quote - "bring something new to the arguement ;)". Now that Q1 is an open source progect, you can be involved in its development.
|
Re:Open Source is not the problem (Score:1)
by Python (python@freedom.gmsociety.org.NOSPAM-BADSPAM) on Monday December 27, @01:45AM EST (#391)
(User Info) http://freedom.gmsociety.org
|
| Heres a crazy idea (not well thought out I might add, plus I'm starting to fall asleep) - how about trusted players? Perhaps a player would have to get their key signed by a number of other players on different servers, have their binary signed and so forth, keeping the bad players off the servers, building a "web of trust" and so on. Server admins could place a threshold on the types of players that can get on their servers. You setup tiers of servers, allowing new players to get on Tier 1 servers, make friends, get "vouched for" by other players and so on. Of course, alot of these problems can be solved through private servers and well managed clans. I remember refering a match and catching someone cheating, he was banned from all clan servers. So cheating CAN be prevented with something as simple as a humble human system. Nonetheless, something like a unique UID for each player a key if you will (or something like it) so you can ban the cheaters, rate the "trustworthiness" of player - sort of like a moderation system like slashdot. Ack... I'm tired so its not totally thought out, but nonetheless the problem with all of these systems is that you have a problem of trust and thats what you need to build. Closing the source appears to solve the problem of trusting the binary, but its a false sense of security. Cheats existed before the source was opened. Hell, people have always tried to figure out some way to beat the game. That, to some people, is what playing a game is all about. Figuring out they can rocket jump to this ledge and no one will see them. Camping in a hard to shoot spot and picking everyone off. Ping flooding people so they can't talk to the server and so on. Some people just suck and can only win by cheating. That happens in every game unfortunately (yes, even the ones in the meat world... thats why they have referees!) In fairness to ID, it is very hard to build a totally trusted system. Its not impossible, just difficult and requires some thought. It can be done though and the cheating issue can be solved more efficiently through other means as well (human systems, like referees). The determined cheaters will figure out the game and its protocols whether you open or close the source, so closing it, I argue, buys you very little. I suggest everyone read Bruce Schneier's Applied Cryptography for more on problems with trusted systems. Even a blessed binary could be spoofed unfortunately. Anyway, its late and this thread is finally killing my insomnia. BTW, I'm flattered that someone(s) liked my comments enough to moderate them up and I appreciate everyones comments, even though I'm so tired I can't respond to all of them. Very interesting points on both sides of this issue. For me its a classic trust problem. :-)
--
Python
"Linux, the last service pack you'll ever need." |
Re:Open Source is not the problem (Score:2)
by Hard_Code on Monday December 27, @12:10PM EST (#435)
(User Info) |
"i disagree, this seems like one of those instances it wont work. jc is right, with the source open and me being able to enter as a server op "if name == mine, scale damage by 75%","
(don't know who actually posted this)
But who the hell is going to play on your server once they realize you/your server is cheating? Do all you want to your server. Nobody will want to play with you. This is besides the issue of open source or closed source (a non-issue), or client security (a not-completely-solvable issue).
Jazilla.org - the Java Mozilla
Attn spammers |
Re:Open Source is not the problem (Score:1)
by morph- on Monday December 27, @12:44PM EST (#441)
(User Info) |
In your own comment, you point out that someone can still modify the server. This is really impossible to prevent even using JC's method, because one would still have to trust the server operator. Besides, the very point of opening up the Quake source is so that people can create useful modifications to it and release them to the public. JC's solution requires using a digest algorithm on the client itself. Obviously this is an entirely invalid strategy, because it prevents people from using their own slightly modified clients. The solution is (and always has been) to assume the server is trusted and the client is not. The majority of server's out there that anyone is willing to play on will be trustworthy anyway.
|
Re:Open Source is not the problem (Score:2)
by Hard_Code on Monday December 27, @01:34PM EST (#445)
(User Info) |
"The solution is (and always has been) to assume the server is trusted and the client is not. The majority of server's out there that anyone is willing to play on will be trustworthy anyway."
Yes, I totally agree. Because of the specific constraints of a multiplayer gaming environment it is simply impractical to create a security model in which the client can be untrusted. People shouldn't be wasting time trying to make sketchy stop-gap solutions to the underlying (and necessarily) flawed security model.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:Open Source is not the problem (Score:2, Interesting)
by RodStewart (robswin[at]hempseed.com) on Sunday December 26, @02:40PM EST (#117)
(User Info) http://www.phish.net
|
I have to disagree. I dont the thousand eyes theory applies here. leave a comment i want to hear what /. thinks. remember fair competition is important to quakers.
"Are you satisfied with fucking?" - Dave Matthews from "Halloween" |
Re:Open Source is not the problem (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @02:47PM EST (#126)
(User Info) |
I think you missed the biggest point in his reply, which can be summarised by this quote;
Anytime you rely on the client exclusively to report valid values you shift trust into an untrusted space. The users machine is not trusted, so why does it suprise anyone that someone would cheat?
That's what need to be addressed here. Trusting client machines to tell you that RapTOR has killed lunaTic with a shotgun is not the right way to keep track of stuff in a distributed world.
Flame on ! - Johnny Storm, Fantastic Four |
Re:Open Source is not the problem (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:10AM EST (#371)
(User Info) |
Client machines are not trusted in this manner at all. I'm not at all an expert in this area, but I'm certain that ID does not trust clients to tell the server that a kill has been made. I am talking about quakeworld here not regular quake. I haven't played regular quake in multiplayer more than once. Quakeworld basically sends control response back to the server. The server sends the clent information about his position with respect to the world and the position of others.
The biggest issue I see is autoaim type cheating. I can't imagine a completely secure method to prevent this type of cheating. In the end the game will *always* be sending input supposedly from the user back to server. How could we possibly prevent that from being hacked?
|
Re:Open Source is not the problem (Score:0)
by Anonymous Coward on Sunday December 26, @09:30PM EST (#345)
|
Well, here's how I see it, before open source I have a feeling there were probably just a few people who had these similary hacks figured out and they wouldn't give their secrets away or release anything for people to use
Even with closed souce hacks exist [and are much more insidious] - but the people who have them are too smart to let others know, because the system is closed source few others if none will figure out the hacks. If you had a one in a kind valuable, everyone else having it diminishes its intrinsic value. This is why closed source is so bad - Imagine if a small network software company (say, Lantastic, for example) figured out a way to crash any Netware server (a closed source system), and make it look like a software fault. What if they took that knowledge and made new Lantastic servers crash local Netware servers randomly, once or twice a week. If Lantasic never told anyone, then no one would know, and it would be unlikely for anyone to find out, and Netware would look quite poor. On the other hand, if Netware was open source, after a couple of months someone else would be likely to discover the fault, since the source code for netware is availiable, and fix it -- and tell everyone how bad the Lantastic was for crashing Netware servers on purpose (Btw: This is all hypothetical...).
Now, this applies to quake like this: As a closed source product, someone could, through hacks, make themselves look like a "quake God" always, maybe even become quite famous for being so good at it. With open source, his hacks can be discovered, and he could be pointed out for the fraud he is... :-)
Now as far as fair competition goes, I look at it as nothing different from a board game. If someone cheats, they lose, even if they win. If someone is beating you, and you suspect they are cheating, but can't prove it, don't spam the server with "xyz is cheating", simply leave for another server. The cheater will feel like one hell of a loser if he has no competition to cheat against. :-)
And if everyone cheats, set up your own server, with a password, and only play with people you know don't cheat (they'll thank you for it.)
Sorry, that was a pretty long and convoluted way to describe my thoughts on the situation, but that is how I feel about it.
|
Re:Open Source is not the problem (Score:1)
by pabs (duncanpa@engr.orst.edu) on Sunday December 26, @02:51PM EST (#130)
(User Info) http://pablotron.dhs.org/
|
I agree.
I wonder if hte following implementation would help: Set up a rotary multiplex with all pertinent client game stats (eg hp, velocity, weapons, ammo, etc) and appending, XORing, or checksumming them and appending the result to server-bound packets (ex for XOR ones, obviously). Set up a server thread dedicated to verifying the validity of clients specs, flagging them when they don't match, and booting a client when it exceeds the server's flag limit. Granted this probably wouldn't stop minor client hacks, but major ones (eg million hp, no damage, flying, etc etc) would be caught and logged. Dunno if this would add too much completity to the server... I have hte src but I haven't had time to poke around in it. ANyone more qualified care to comment?
--
odds of being killed by lighning and
winning the lottery in the same day: 1 in 2^55 |
Re:Open Source is not the problem (Score:1)
by MbM (mbm@linux.com) on Sunday December 26, @03:33PM EST (#160)
(User Info) http://linux.com/tuneup/
|
You're on the right track the way to stop such cheating is done through the server, but there's no need to go to great lengths to encrypt the data, all you need to do is keep tabs on the clients and their vital stats and kick the client when it tries to do something impossible.
In such a scheme you really don't even need to be transmitting these statistics contantly, just have a thread on the server that keeps track of what it thinks they should be and if the server thinks health is at -25 but the client is still alive and shooting people you know they've been cheating and yuo can kick them.
This still leaves the problem that the server has to be trusted but I don't think there's any way to avoid that.
- MbM
|
Re:Open Source is not the problem (Score:3, Interesting)
by WNight (wnight@rocketmail.com) on Sunday December 26, @07:02PM EST (#316)
(User Info) |
Quake already does this. The server is completely in charge of if you live or die, if you run out of health, you fall over, even if you've found the bytes for health and locked them at 100...
What you're concerned about is actions... Bots can shoot better, and dodge better (theoretically) than humans. How does the server tell it that perfect spin while holding the lightning on a guy who ran by was Thresh, or a bot?
Similarly, the client can change the way information is displayed. Perhaps they change the Z sorting for items, so that all players that are drawn are drawn in front of walls, even if they'd normally be behind... Throw in a simple GL effect to indicate the difference between an X-Ray view and a non-X-Ray view and you've got a way to avoid ever being suprised at corners.
It's impossible to stop cheating in an environment with untrusted clients. Even with black boxes like console systems, it just raises the bar, making it harder to cheat.
|
Re:Open Source is not the problem (Score:3, Insightful)
by Hard_Code on Monday December 27, @12:16PM EST (#437)
(User Info) |
"It's impossible to stop cheating in an environment with untrusted clients."
I completely agree. This has nothing to do with open source or closed source. It is just simply impossible to stop cheating in an environment with untrusted clients. If you force clients to be trusted somehow (which won't work anyway) by only releasing "blessed" clients, then you have just lost the benefit of open source, and made a humongous pain in the ass for /decent/, non-cheating players.
All sorts of solutions and fervent discussion is flying around about how to make it secure. It always resolves down to security through obscurity. In the end any "security" system in place will just make it harder on decent players. Because of the simple fact that any system that trusts the client is unsafe, it will never be a absolutely safe game (unless /everything/ but inputs are pushed to the server, at which point the game becomes secure (except for the behavioral cheats), but entirely unplayable). For the game to be completely cheat-proof the whole architecture has to change, and I don't think there is one that could live up to and support the fast and furious online play.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:Open Source is not the problem (Score:2)
by Hard_Code on Monday December 27, @12:20PM EST (#438)
(User Info) |
"What you're concerned about is actions... Bots can shoot better, and dodge better (theoretically) than humans. How does the server tell it that perfect spin while holding the lightning on a guy who ran by was Thresh, or a bot?"
For the sake of clear terminology, I call these valid (within the rules) cheats "behavioral cheats". That is, it is a cheat of performing allowed, but unrealistic, behavoirs within the rules.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:Open Source is not the problem (Score:1)
by Digital_Fiend on Sunday December 26, @02:52PM EST (#131)
(User Info) http://b1nary.n3.net
|
Hopefully the ID folks will realize that if they want to stop cheating. Preventing cheating in the client alone is never going to work. It will of course take some more work on their part, but its been done correctly before and I'm sure they can do it too. If they're smart they'll embrace this and work with the open source community to get it fixed. I'm not sure I agree with that... Preventing cheating is pretty much a nonstop battle. That's why development on QuakeWorld pretty much halted, Zoid (Dave Kirsch, responsible for maintaining QuakeWorld client and ports of Quake to other platforms) just got tired of working on fixing loopholes and then seeing another 10 pop up.
-Warren
"The fool thinks he is wise, but the wise man doth know himself to be a fool." -William Shakespeare |
Thats only part of the problem (Score:0)
by Anonymous Coward on Sunday December 26, @05:04PM EST (#249)
|
Lets talk about some of the classic cheats:
eye-model cheat, does that have to do with passing trusted values to the server? No.
Old school concussion grenade disabler, same question same answer.
Concussion was a client side effect because effecting the view point server side has some really jarring effects due to lag, after a lot of cheating they did replace it with a server side effect... and it was horrible.
And of course good oll bot's, same question same answer.
Server doing checks on all client input only solves a minority of FPS cheats, since FPS's are already mostly server authorative.
|
cheating happens with uncheckable values (Score:1)
by Heisenbug (jcushmaSP@Msimons-rock.edu) on Sunday December 26, @05:19PM EST (#262)
(User Info) |
Not that I know any of this first hand, but from what I have read in other threads, the cheating does not have to be with trusted values. Mods to the program which dodge and aim for you affect only the client's position -- these are values which only the client can report, and there is no way to check them. It seems to me that it would have been very hard to modify the program to cheat this way before the code was releases, and it will be impossible to check for cheating now.
--Jack
--- "Is it just me, or am I imagining things?" |
nice in theory [Re:Open Source is not the problem] (Score:1)
by Logical on Sunday December 26, @07:30PM EST (#319)
(User Info) |
That's nice in theory, but when performance
extremes are needed (e.g. quake), you have
to make compromises. To get the kind of
performance you need from a game like this,
you have to put as much work into the client
as possible.
It's a tradeoff. In this case, open sourcing
the software didn't _create_ a security hole,
it just widened it to be big enough to drive
a semi truck through.
|
Re:Open Source is not the problem (Score:1)
by Lx (lx at hellstunas.org) on Sunday December 26, @09:52PM EST (#348)
(User Info) http://lx.dcwi.com
|
"Opening the source does not create the security hole, it just makes it easier to find it and fix it."
I doubt somehow that quake players really give a damn about 'fixing' quake, making it more secure, or suffering through temporary annoyances to make a better product. Point is, that they were playing quake just fine before the source was opened, and now suddenly many security holes come to light, and they have problems.
You need to be able to look at issues from the point of view of an end user - from their point of view, opening the source has made their life difficult, and there's no way of denying it or brushing it off by pretending that it's critical to fix 'security holes' in quake. This is one instance where open source has not applied very well, IMO.
-lx
-- BeDev ID #19497 |
its a direct result (Score:0)
by Anonymous Coward on Sunday December 26, @10:46PM EST (#355)
|
Were there cheat clients before this? No. Q1 was nice and secure until the source was released and cheat clients showed up. Security through obscurity was working.
|
Re:its a direct result (Score:1)
by gellor on Wednesday December 29, @08:53PM EST (#481)
(User Info) |
Either...
1) You are smoking crack...
and thus should share it...
OR
2) You are a troll...PLONK!
|
Re:Open Source is not the problem (Score:1)
by Qui-Gon (vladtheimpaler33@hotmail.com) on Sunday December 26, @10:57PM EST (#359)
(User Info) |
I do agree that Open Source is not totally to blame here. However, since the source is open it does make it easier for the user to modify the client to his/her likings. So, open source does play a role in the "cheating" in Q3. Although, I would not go as far as to say that Q3 should go closed source and that will solve the problem.
I think that the main cause of the "cheating" is the honesty and integrity of the players of Q3. Take Diablo/Battle.net for example: When it first started cheating was common place. (And so was Player Killing). Eventually, all the players who despised cheating and player killing started lists of known offenders. They also started games that were password protected so that only "trusted" honest players would be given the password to such games.
So, why doesn't the Q3 players try the same... See if it improves the quality of play. Then if it does not... Maybe seek another solution.
I would really save the closed source option for last. It would be a real shame for Q3 to go closed source.
We are blind to the Worlds within us
waiting to be born... |
Re:Open Source is not the problem (Score:1)
by Qui-Gon (vladtheimpaler33@hotmail.com) on Sunday December 26, @11:08PM EST (#361)
(User Info) |
I realized I put Q3 through out the above comment. I meant Q1... I guess that's what I get for not clicking preview.
I have been up for ~24hrs. so I am a bit tired.
We are blind to the Worlds within us
waiting to be born... |
Re:Open Source is not the problem (Score:1)
by vasiln on Monday December 27, @02:30AM EST (#396)
(User Info) |
>>Opening the source does not create the security hole, it just makes it easier to find it and fix it. If it's capable of being fixed... and in this case, as far i can tell, it's not (keep in mind we're talking about things such as aimbots). given that, opening source only makes it easier to find it and _exploit_ it.
|
Re:Open Source is not the problem (Score:1)
by FFR on Monday December 27, @12:21PM EST (#439)
(User Info) |
| Seems quite clear that security throught obscurity is a bad idea. But if you take into account some social parameters (for example proportion of guys able to hack a binary executable compared to the proportion of guys able to hack a .c file) things are not so clear anymore. Anyway, I've always been amazed by what smart protocoles and public key crypto can do. Can someone give a precise example of something in Quake 1 that can't be secured with an elegant protocole ? (maybe this is obvious, don't be too rude :))
|
"Causes Cheating?" (Score:1)
by gnubie (gnubie@NOcounterintuitive.orgSPAM) on Sunday December 26, @01:41PM EST (#38)
(User Info) http://counterintuitive.org/
|
| Open Source Quake makes it easier for a broader range of people to cheat. It's going to be mostly script-kiddie types using cheater clients, the rest of us who enjoy the game might try it once but will quickly grow tired of an unfair advantage.
What doesn't kill you stands a good chance of permanently maiming you. Contact me if you wish to quote me outside this forum.
|
Could encryption be the answer? (Score:2)
by dsplat on Sunday December 26, @01:41PM EST (#40)
(User Info) |
I haven't looked into the details of the cheating. Hey, I haven't even read the code in question. However, there are protocols that allow for fair games of chance over a network. Basically, a set of encrypted values are passed from server to client. The client picks and returns on to the server. The server uses it. Using public key encryption each party can verify that the other hasn't cheated. Presumably, the server is trusted in this particular case, but a protocol like this even leaves the option of verifying all of the options against their encrypted counterparts to ensure that the server didn't use a rigged deck.
This requires a significant amount of the control to be in the server. And to some extent for a workable game it requires that the server be trusted. All I can do in this case is point at a good reference, Applied Cryptography by Bruce Schneier, and ask whether such a solution is a viable alternative to locking up part of the source again.
Sign the Linux Drivers Petition at http://www.libranet.com/petition.html |
The answer is Community, not Closed-ness (Score:5, Insightful)
by pete-classic (SuperPete@earthling.net) on Sunday December 26, @01:41PM EST (#41)
(User Info) |
No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear."
A real solution would be to build an actual community. This word is bantered around quite a bit, so allow me to explain further.
If people were positively identified by the server, they would be accountable to others on their server for their actions. I think that the Slashdot model would work very well in this situation, in fact probably better than it does on Slashdot.
You could, of course, only allow "known" players to login. You could also allow an "unknown" player to login, but allow any "known" player to, say, kick him out and ban his IP for 20 min.
This could be implemented as simply as a username and password, and as complexly as, say, you must send your username (player name) and the date and time signed by PGP.
"Oh, yeah, I know pete-classic. Naw, he doesn't cheat. Watch out when he has the Railgun though!"
-Pete
|
| |
Re:The answer is Community, not Closed-ness (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @02:31PM EST (#102)
(User Info) http://www.tusa.org
|
No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear."
I have been playing Quake1CTF for a little over three years now (steadily). My clan has been around for that long as well, and even though we are no superstar clan, we enjoy playing for fun. There have been proxy cheats around (that include teamplay support and even turn to your enemy when firing) for a long time now. Some servers can detect this and kick the user, but still some have advanced proxies that still let them in (and the cheating is obvious). There has been word of this "pak2 cheat" where I assume that the user has a modified pak2 where it seems to allow them more damage and unlimited ammo. I haven't seen this "pak2 cheat" but on some public servers it really does seem that they have like 200A/250H/resistance rune/regeneration rune all the time. They are nearly impossible to kill in a fight even w/8x rockets and lightning. I'm sorry, but you can only take a direct 8x rocket once...
My long, drawn-out shit here is just to say that no matter if the source was released or not, there will always (and was always) cheaters in Quake. Using either proxies or this myserterious "pak2 cheat". They only seem to be on public servers (ctf.webmaster.com) but I have to be weary of some CTF clans and their remarkable aim... I never accuse, but when two rockets are already heading in your exact direction before you even think of grappling there, I have to think that something fishy is going on...
Just my worthless .02
-/- Bill -/- |
Re:The answer is Community, not Closed-ness (Score:1)
by glitch_ (rrinaldi@primenet.com) on Sunday December 26, @03:20PM EST (#149)
(User Info) |
I'm just writing to shed some light on your mention of the infamous pak2 cheat.
A pak2 cheat is where a player takes apart original pak, and adjust the player models. One of the more common 'adjustments' that are made are where all the players is made to glow, like they have quad. So you will see the player's glow, before they turn the corner. Another common pak2 cheat, elimate ring of shadows completely. So when the player has "eyes" they actually don't, they look just like any other player in the game, so the opponent never gains any type of advantage over you by picking up the ring of shadows.
Also, when using a pak2 cheat, you can't dicate how much or little damage is dealt to you
|
Re:The answer is Community, not Closed-ness (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @03:30PM EST (#157)
(User Info) http://www.tusa.org
|
most of those cheats aren't what I would have considered pak2 cheats. They are just addons that I have seen -- easily available -- glowing packs, glowing runes, better crosshair, etc.
-/- Bill -/- |
Re:The answer is Community, not Closed-ness (Score:0)
by Anonymous Coward on Sunday December 26, @02:53PM EST (#133)
|
I don't think that would work because, how can you know for sure if someone is cheating (assuming they are careful about it) An analogous problem occurs in internet chess and believe me it's a big problem, even though people must "log in" to play rated games.
|
Re:The answer is Community, not Closed-ness (Score:1)
by pete-classic (SuperPete@earthling.net) on Sunday December 26, @06:15PM EST (#292)
(User Info) |
Of course there will be growing pains, but if CoolGuy can't hit the broad side of a barn with a rocket launcher, and all of a sudden he is jumping, spining, strafing, and hitting every railgun shot (with perfect lead) it is a good guess that CoolGuy needs a little talking to.
Possibly more importantly, people who are part of a real community are FAR less likely to cheat at all, even if it is just a .97 client damage multiplier or something.
-P
|
Re:The answer is Community, not Closed-ness (Score:2)
by Jamie Zawinski (jwz@jwz.org) on Sunday December 26, @03:29PM EST (#155)
(User Info) http://www.jwz.org/
|
No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear." A real solution would be to build an actual community. Yes, this is absolutely right! The problem is that software can never be trusted: only people can be trusted. Take the problem back to the actual source. The only way to really fix this problem, rather than simply layering more obscurity onto it, is to design a system where you actually know the people you are playing with (or at least know them pseudonymously), and trust them not to cheat. You can cheat at cards, too. This is no different. To the folks who think that simply hashing the binaries can solve this: who's to say that my client reports back the hashes from the binary that is actually running? This is the ``copy protection'' problem all over again, it simply doesn't work.
|
Re:the gun (rocket launcher) control issue (Score:2)
by Money__ (hallada at Netscape dot net) on Sunday December 26, @06:13PM EST (#291)
(User Info) file:///C|/Windows/Exit%20To%20DOS.pif
|
| I have to agree with JWZ (yes *that* JWZ) and Pete on this one. The solution will require an alt.soc.hack. There are 2 parts to the problem here, the code that allows the cheating, and the cheater who uses that cheat in a game. The hacker who comes up with a cheat will always be around. What needs to be stoped is the deployment of that cheat on a large scale. Interestingly, I think that there is a parallel between this and the gun control debate. There will allways be guns (legal or not) and what needs to be stoped is the people's use of them to make bad things happen. To continue on this parallel, there are some who would seek to place restictions on the advanced 'guns that cause the damage'. Lets just assume for a moment that it was possible to screen on the server side for the video driver used, the software running on the client, and share that information across servers. How would one implement such a 'big brother' layer of abstraction without touching off a 'your rights-on-line' debate? (see:Another Software Spy - November 28 (/.) This comes down to a trust model, and the ability of a server op(or designated trusted players) to kick a bot when they see one. It's worked in IRC for decades.
_________________________
These comments powered by Printf |
Re:the gun (rocket launcher) control issue (Score:1)
by gellor on Wednesday December 29, @08:58PM EST (#482)
(User Info) |
Before I nitpick let me say that I agree with your post in all but the final detail.
IRC hasn't quite been around a decade yet...but still...point granted. ;)
--
Gellor
who is feeling analretentive today...
|
Sanctioned Cheating (Score:1)
by Fenmere, the Worm (fenmere [at] lab.net) on Sunday December 26, @04:04PM EST (#194)
(User Info) http://haunt.lab.net/index.html
|
The community model is compelling, so I'm posting my thought under this thread. Most people have been writing about the poblem as being cheating, and when the "cheating" is uncalled for it is a problem. But with a community in place, certain kinds of "cheating" could be allowed by certain groups of people. Kind of like the old saw about hackers getting together on a closed system and having a virus war. The game no longer becomes who can wiggle the joystick the fastest but who can write the snazzier code. In fact, with this code being openned, there is ample opportunity to write some really fantastic AIs and pit them against other player's AIs. All it needs is the checksums in place that would be put there by a community style system, or what have you.
-- "So far, I have not found the science" -Soul Coughing |
Re:The answer is Community, not Closed-ness (Score:0)
by Anonymous Coward on Sunday December 26, @04:08PM EST (#197)
|
Yes, the answer is "community" (that translates to "utopia" for anybody who didn't do the reading for today's lecture). So much for the real world. Oh well.
|
Re:The answer is Community, not Closed-ness (Score:1)
by IntlHarvester (vcs2600@yahoo.com) on Sunday December 26, @04:14PM EST (#205)
(User Info) |
A real solution would be to build an actual community
You are correct that the only real solution here is to verify people rather than trying to verify binaries. There's plenty of tools to do this (X509 certificates, etc.)
Real personal verification might be necessary, because a 'reputation' system can fall apart with a few bad apples. There's plenty of horror stories from ebay users with enormous feedback ratings, for example. However, personal verification will require a few things that might not go over well.
(A) You would need some all-powerful certificate authority that would verify people by credit card #, birth certificate, and so on. People would hate going through this verification process, paying VeriSign (etc.), and minors or people not trusted by the US banking system might be left out. Even with all of that, fraud is possble -- at least in the US, it's quite easy to get a fake SSN and birth certificate.
A simple login/password system would only work about as well as slashdot's negative karma system does.
(B) You would need an authority to mediate disputes and invalidate cheaters' certificates. This could quickly devolve into "Did not!" "Did too!". For e-commerce we have a mechinism to resolve disputes -- the court system. Obviously hiring lawyers or inspecting people's computers for evidence is far too much for Quake game.
The bottom line is real verification of people is difficult, and the era of public Quake games and cash prize tournaments might be over. People can still have a lot of funny playing with their buddies, though.
--
Plagiarism is necessary. Progress demands it. |
Certificates == CD Keys (Score:1)
by crt (wrightd@gamespy.com) on Sunday December 26, @09:16PM EST (#342)
(User Info) http://www.gamespy.com
|
The answer to (A) is client CD Keys, as discussed in my earlier post. Obviously this won't work for pure open-source-only games (since it requires you to "buy" something), but since Q1 is an open-source hybrid (as will be Q3 and others if they get released) this scheme can certainly works. It requires that the game be distributed with CD Keys to begin with, but I think you'll see that more often than not, starting with Q3 (especially future id games).
That also is the solution to (B) -- disputes are settled the same way the company settles the normal "he stole my CD key dispute"
|
Re:Certificates == CD Keys (Score:1)
by IntlHarvester (vcs2600@yahoo.com) on Sunday December 26, @11:32PM EST (#367)
(User Info) |
Yes, I can see that if some company wants to sell value-adds to their modifed version of Quake. (One of the value-added bits would be player verification and fair games.)
But, I strongly suspect that a good number of Quake modifications will entirely be freely distributable. After all, one of the reasons that Id is open sourcing it is because it doesn't have much commercial value any more, which means their marketers must know that the number of potential paying customers for a modified Quake 1 is very limited. The Q1 fan base will probably happily keep it alive in the traditional open source free download model.
Furthermore, there will probably be so many modified versions that it would be difficult to gain a "community" for a particular company's commercial security scheme. (Admittedly, my ideas about player certificates have the same problems.)
Maybe your idea would work commercially if the price was $5 or something, but then it would very easy for cheaters just to buy a new key when they are discovered.
--
Plagiarism is necessary. Progress demands it. |
Re:Certificates == CD Keys (Score:1)
by pete-classic (SuperPete@earthling.net) on Monday December 27, @03:08AM EST (#399)
(User Info) |
New York Second: The amount of time that elapses between a light turning green and a taxi driver honking his horn. ~= 1/1000 seconds
A Quake Key Second: The amount of time that elapses between a "cd key" system being implemented for Quake, and a keygen being released. ~= 1/1000 New York Seconds
"I just got kicked again, let me generate 400 new cd keys."
Back to the drawing board Mr. Coyote ;-)
|
Lessons from Subspace; Centralized Naming (Moof!) (Score:0)
by Anonymous Coward on Sunday December 26, @05:49PM EST (#280)
|
I am an active player on Subspace (http://subspace.inet.fi/), more or less of an online spacewar clone with around 80-300 people to a server (Okay, at least that's how it used to be). I'm not going to quote all game's history, so I'll get to the point.
One of things I've never liked about Quake is how the servers are so independent of each other. You can basically choose any name you like and go anywhere. This isn't all bad, although it isn't exactly good for forming a community.
Subspace uses centralized 'Billing' servers (No one actually charges though) to hold information on users and squadrons. While it does have it's faults, it provides fairly nice stat tracking and cross-arena chat. This is also a good platform for dealing with cheaters and troublemakers on both arena and network wide levels.
Subspace has had serious problems with cheating throughtout it's lifetime, mostly stemming from the fact that most of the game's calculations are performed client-side, allowing a cheater to alter their location, inventory, or life levels at will.
Building a community structure helped stave off quite a bit of the most blatent cheating, at the cost of having to submit to the whims of frequently incompetent SysOps.
Lessons to learn from subspace's mistakes:
Whatever you do, allow users to reset their own playing stats and hold various pseudonyms under a single account. I'm betting that over 70% of subspace's billing database entries are created lamers either trying to go for the coveted 50:0 kill ratio, or using a name like 'SUICIDE BOY' just to screw around with.
Don't over-centralize. If the billing server went down in subspace, things seriously screwed up. A distributed solution similar to IRC may be in order, or something where servers could possibly on several different billing networks at a time.
Look into providing IRC-like communications with name servers that you don't control. Being unable to talk to your squadron while playing was a major issue in Subspace, and one of the reasons why independent zones have such a rough time.
Run a hierarchy where servers may ban independently of each other, but enter everything into the main database so that other servers may implement the ban as well, if they want to. This helps against overzealous Ops and whatnot. 'Oh, so GodOfTheServers has banned SkillzedPlayer again. Whoopee.'
Moof!
The Subspace Moof, not any of the others you've seen before.
|
Re:The answer is Community, not Closed-ness (Score:2)
by Trepidity (delirium4u@theoffspring.net) on Monday December 27, @12:02AM EST (#368)
(User Info) telnet://127.0.0.1/
|
Exactly. Opening the Quake source code didn't create this problem - it was always possible to disassemble the Quake executable and modify it to cheat. It's just a lot easier now.
It's still possible to have good, cheat-free games though. Tetrinet (online 6-player Tetris) had a really bad design, with everything kept track of client-side, and didn't even prevent you from typing ASCII 255 (the "packet" separator char) into the chat window, so you could cheat just by typing some simple text into the chat window. Yet many people still play the game, and don't cheat. They find other people who they know and who also enjoy playing the game so that nobody wants to cheat, since that would be somewhat pointless.
Anyway, this is really the only solution. Any other attempted solution just makes it more difficult, but not impossible, to cheat.
|
The Pricetag... (Score:1)
by Danbo (pabulum7@hotmail.com) on Sunday December 26, @01:43PM EST (#42)
(User Info) |
Unfortunately, this is the price we have pay for open source- you are all right, ID does a great thing for the computer community, but much like the inherent freedom of the Internet, the prize of free speech comes with the price tag of flamers and anonymity. There must be a way for the login to detect altered source; like the new Mod-Chip proof Playstation games which, I am assuming work on the basis of an architecture encoded in the CD that MUST match the system or the process terminates; any ideas, guys?...I imagine this would only affect the game servers, b/c who gives a %$#& if someone cheats on their own?
"There are only two things men want more than money, power, and sex; praise and recognition." |
Maybe a new client/server model is needed here. (Score:2, Insightful)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @01:46PM EST (#44)
(User Info) |
This is probably not a good answer now (slow networks) but maybe a solution, when everybody has faster connection, is to basically have servers that don't trust clients ?
For example, if somebody make a modification that allows unlimitted ammo, a better place would be to move the keep_ammo_count :) code in the server , not the client.
Another example would be a modification that allowed invalid movement (ex: going through walls, running too fast, flying). This could be countered by the server monitoring movement and enforcing the proper laws of physics in the virtual world.
Anyways, I think there might be other alternatives that keep the whole thing Open Sourced. After all, this (hacked clients) is not a new problem nor one exclusive to online gaming.
Imagine if in your websites you relied on your JavaScript code to do all the data validation and integrity checks and you had none on the server side ! It's like letting a user validate his/her credict card and your server just going "no problem"...
Like I always tell my coworkers here when we do distributed apps, never trust the client (code that is), it can always get hacked or spoofed.
Flame on ! - Johnny Storm, Fantastic Four |
| |
This is not much of a problem in Quake (Score:0)
by Anonymous Coward on Sunday December 26, @05:08PM EST (#251)
|
Bot's are the main problem, Quake is already mostly server authorative.
|
Hate to say it, but... (Score:3, Insightful)
by Tsuran on Sunday December 26, @01:46PM EST (#45)
(User Info) |
| Sorry to say it, but this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model. Simply put. If I dedicate my time, my effort, my life to making anything, a game, a SETI@home client, a utility, I'm not going to want people to pervert my hard work. That's what it comes down to, really. Why should I, as a potential product designer, want to release my code if the potential exists for misuse? Suppose that they opened up the source to SETI@home. Then you'd most probably be able to figure out the protocol, and how it sends 'alert' messages. And I guarantee you, someone will start sending fake data to SETI, and it'll totally defeat the purpose of the collaboration. Now. If your argument is that in all of the community, there will be no bad apples who will misuse the source, that's naive, I'm sorry. No group can be completely without its bad element, and I would wager that most developers don't want to open themselves up to that element, however small. There's security in a closed-source model, and companies want security. I know I wouldn't want to risk my userbase, my name, and my job security for something like this, and I would imagine that most people who do this for a living would tend to agree. Do I think that an open-source model is necessarily always bad? No. It has its place. Is that place in the world of commercial business? I don't believe so, no. Companies make products for money. Cheaters, exploiters, and all of that will always be there, and will always be a danger to any company. By keeping their source private, the chance of this element exploiting their work falls dramatically. It's just a fact of economics. Well-written, thoughtful replies are, as always, welcomed. Flames are not. --Tsu
|
| |
Re:Hate to say it, but... (Score:2)
by Guy Harris (guy@alum.mit.edu) on Sunday December 26, @02:14PM EST (#80)
(User Info) |
Yes, there is a risk that, by making certain programs open-source, somebody could make use of the information made so available to, for example, commit fraud. However, it's not clear that this possibility exists with all software that is sold commercially - yes, you could perhaps modify a digitized photograph to show Bill Clinton or Newt Gingrich having sex with Scary Spice by using the GIMP, but you could, as far as I know, do the same with the closed-source Photoshop. If there were some mechanism to prevent tampering with digitized photographs, or to make such tampering detectable (e.g., some sort of digital signature), then there might be more of a risk with an open-source image editor that implements such a mechanism - but I don't know one way or the other whether no such mechanism can be implemented without keeping it secret. (And, no, that doesn't ipso facto mean that any company doing an image editor would be too afraid to do so - "I don't know one way or the other..." doesn't mean "nobody knows, it'll forever be a fear", it means "I don't know".) Furthermore, it won't necessarily be the case that the cost of the sort of fraud, etc. that could be committed with an open-source program (or any other source of openness, e.g. published protocols, published file formats, published algorithms; this isn't just a question of open source vs. closed source) will be deemed greater than the benefits of openness. Yes, there have been cases where that sort of fear has dominated - see, for example, the policy of some governments, including but not limited to the US government, towards freely-available encryption technology - but that doesn't prove conclusively that this sort of fear will, of necessity, be dominant. I.e., I've seen no evidence to suggest that the fear of misuse of a program must be so strong as to prevent any software developer from ever making their source available, so, whilst a more limited version of your conclusion might be valid, I see nothing to suggest that your quite sweeping conclusion ("this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model") is, of necessity, valid.
|
Re:Hate to say it, but... (Score:1)
by Fnkmaster (gabriel@NO_SPAM.fas.harvard.edu) on Sunday December 26, @02:21PM EST (#90)
(User Info) http://gabriel.student.harvard.edu
|
| Your argument is somewhat flawed. With respect to SETI@Home, I can conceive of a number of ways in which to prevent spoofed alert messages and punish those who would abuse the system (alert messages are verified, and if the verification rejects the alert, the IP address is banned from the SETI@home server). If somebody really wants to attack and abuse a system such as SETI@home, they probably could anyway, as I'm sure the client-server interactions can be reverse engineered enough to hack it in some way. The system should really involve client accounts, and authentication and an abuse punishment protocol. The point is that a robust protocol is always preferable to a security or integrity through obscurity system. As far as games go, there is a case to be made for some type of closed source verification module. That is most definitely *NOT* a case against Open Source in general, nor against Open Source in the corporate world. There is a lot of room for Open Source software in the corporate world. Game software companies are a small segment of the software world and have particular concerns and a particularly dynamic market sector. Most of us hope for more Open Source gaming software, but don't legitimately think all game software should be free (besides which, a large part of any game is story line, graphics, sound, etc. stuff that isn't even part of the core software).
|
Re:Hate to say it, but... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @02:26PM EST (#98)
(User Info) |
You are making an assumption that the SETI@home protocol is very difficult to hack under a closed source model. However, if a decent programmer was intent on screwing up the SETI data, I'm sure she or him could do it very easily right now.
Again, data should be validated on the server. Why would you trust arbitrary packets coming anywhere from the internet and not check for their validity on the server ? We don't do this with the HTTP protocol, and we shouldn't do this with any protocol out there.
In the case of SETI a good dose of server side validation and encrypted password protection and authentication would be a much better solution than , "you can't break me because you don't know how I work".
Flame on ! - Johnny Storm, Fantastic Four |
Re:Hate to say it, but... (Score:2)
by sjames (sjames@nospam.gdex.net) on Sunday December 26, @02:40PM EST (#116)
(User Info) http://www.members.gdex.net/sjames
|
Given enough determination, closed source can be patched for cheating as well. I'm guessing that it's probably been done before, and likely went undetected. Opening the source may make cheating a bit easier, but that also makes it all the more lame. I suppose a closed stub can help to limit the problem by reducing the number of people qualified to cheat, but that still leaves a lot of people.
|
Released code is always open to exploitation (Score:2)
by DragonHawk (dragonhawk@iname.microsoft.com) on Sunday December 26, @02:54PM EST (#134)
(User Info) |
Why should I, as a potential product designer, want to release my code if the potential exists for misuse?
You are going to release your code one way or the other, regardless. If you release the source code under a generous, open source license, then everybody will benefit. If you release just the binary, with a restrictive license, then only those willing to ignore your license, break the law, and reverse engineer your program will benefit. (And if you don't release anything, nobody benefits.)
Security through obscurity never works. If your argument is that not releasing the source code is a serious roadblock to the crackers in the world, that is naive, I'm sorry. :-)
I do not like Microsoft. Remove them from my email address. |
Re:Hate to say it, but... (Score:1)
by Jeff Licquia (jeff@luci.org) on Sunday December 26, @04:05PM EST (#195)
(User Info) http://www.luci.org/
|
Suppose that they opened up the source to SETI@home. Then you'd most probably be able to figure out the protocol, and how it sends 'alert' messages. And I guarantee you, someone will start sending fake data to SETI, and it'll totally defeat the purpose of the collaboration. And, of course, that's totally impossible now. No one today has the ability to disassemble SETI@home, or whatever, and figure out how to send alarms, or send carefully constructed inputs into the client and watch the net output. I'm so thankful that SETI@home is just as secure as Windows, thanks to that closed source code. Oh, wait, they do. And they could. And (in the case of Windows) they have. The problem with Quake and with SETI@home is the exact same problem: spoof detection and prevention. Period. Closed source or open. The chance of a crack can decrease with closed source; it can also increase as well. (If the vendor thinks he can hide behind closed source and gets sloppy, or if some hacker thinks it'll make him/her e1337 to hack a closed product...) But crappy software is still crappy, source code or not. The only difference is whether people can fix your foulups themselves or not, which appears to be what is happening with Quake.
|
Quake Development (Score:3, Interesting)
by Blue Lang (blue@gator.net) on Sunday December 26, @01:48PM EST (#48)
(User Info) http://www.gator.net/~blue
|
is continuing - see quake.sourceforge.net - Also, quakeforge is working closely with the quakeworld people, as well as some people from Loki games, to bring Q1 up to speed.
They have a development roadmap, and the cheating issue is addressed. They have already managed to merge QW/Q1 into a single client, port it to SDL, etc, etc, etc.. It's rocking along, and quickly.
To those of you saying "THIS is the problem with OSS.." - shut up and code. It isn't a problem, just a little bump in the road till things settle out. There are several solutions to it, including ones not mentioned by Carmack.
I am fairly certain that this does not spell Doom (hehe) for OSS id software. Get lives, and get over it, in the face of what's already been accomplished, it's really not that big of a deal.
--
Blue
|
Netrek (Score:2)
by Signal 11 (signal11@mediaone.net?Subject=Slashdot comment) on Sunday December 26, @01:49PM EST (#49)
(User Info) http://www.malign.net/~bojay/
|
| Netrek already addressed (and solved) this problem. Release the source to the clients under GPL or anything else - this is not a problem. HOWEVER, you use an encrypted key for each client (and each version) and the binary is compiled and encrypted. You can have servers in "open" mode where you can use untrusted clients, or closed, where only trusted (ie: binary only) clients are trusted. What's nice here is that the server operator can add keys for his newly-compiled client, ad nausuem. So if a binary ever gets hacked, simply yank the key and no more access. This requires that the server op be clued, but other than that it's a 1st class solution to this kind of hacking. Why try to deny bots? Just give 'em there own servers...
-o What does "superblock error" mean? o- |
| |
Its just that not enough people play it :) (Score:0)
by Anonymous Coward on Sunday December 26, @05:15PM EST (#257)
|
As you say, they still get hacked...
|
problem? maybe not... (Score:4, Interesting)
by jlehrbaum on Sunday December 26, @01:51PM EST (#51)
(User Info) http://linuxdevices.com
|
Like john said in his .plan, there have always been ways to cheat. Transparent maps that are not detected despite server-side mapchecking, proxies that allow (albeit very poorly implemented) auto-aiming, glowskins that let people seen through shadows easily, "spikes" that are built into the player model to let people know you are coming because they go through walls, and even proxies that allow a completely hacked up map.. there are numerous other cheats and hacks that are all possible with the original quake. Many of which are undetectable. The source code release lets people to much more obvious forms of cheating such as floating in the air, or zooming through the level like a cheetah on crack. But cheating has always been around.
what is really different now? The real problem is
that a) more people have been exposed to the possibility of cheating, and b) it is far more fun to cheat.
In my 3 years of playing quake up till now, I haven't used a cheat for more than 2 minutes, and then only to test it out. I believe in keeping the game pure and skilled. But with the release of the sourcecode, coders can play with a game they love. They can add special features, optimize code, and really just mess around. Its fun. It makes cheating a game all to itself, what cool feature can YOU code in? Its not the same type of cheating that plagued competitive and non-competitive gaming in the past. This cheating isn't being used to win at all costs, but to mess around. each successive build of quake becomes 'your' build, full of your customizations and features, not just something you download to get an edge.
The important question, is where will things go from here? In all reality, the ability to cheat has not suddenly appeared, it has always been here. The knowledge required to cheat has become mainstream, and has "come out of the closet" as it were. Will this rash of cheating continue, or is it merely a phase? Will it kill competitive match-play, or will the same people that cheated in competitions still do so, and everyone else will play by the rules.. Only time will tell
Jacob Lehrbaum jacob@linuxdevices.com |
| |
Re:problem? maybe not... (Score:0)
by Anonymous Coward on Sunday December 26, @04:58PM EST (#244)
|
Here's a question: Do Olympic athletes use drugs in competition? The Olympics will always be around, athletes will always be around, and drugs will always be around. Olympic athletes know that it is an immense embarassment to their countries and themselves once they are exposed. But for the some reason those dumb suckers still do it.
|
Quake==Pokemon (Score:1)
by havardi on Monday December 27, @12:03AM EST (#369)
(User Info) |
You could trade Quake Clients like Pokemon cards!! they could gold plate the cd's and have them in happy meals!
|
possible work around... (Score:1)
by smash (smash@gold.PLEASE.SPAM.ME.net.au) on Sunday December 26, @01:52PM EST (#53)
(User Info) http://www.gold.net.au/~smash
|
I dunno if you could do this with the current "client" versions of quake out there, but what the server could do (for future), is this:
When a client connects, do a checksum of the connecting binary of quake (1/2/3/whatever) and compare that with a database of "known good" binaries. I don't see that there can be *that many* different checksums to support...
If it doesn't match, don't allow the client to connect, until the version of the client they are using to connect with can be verified. It's up to the serveradmin as to what binaries he will allow.
This would still keep the source available, but any modified binaries could be excluded from online competition unless they have been verified as "legal" (ie they dont cheat).
smash
|
| |
Re:possible work around... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @02:03PM EST (#66)
(User Info) |
So what's to prevent the modified client from reporting the wrong binary checksum ? The solution is to remove validation from the client completely.
Flame on ! - Johnny Storm, Fantastic Four |
Re:possible work around... (Score:2)
by Yebyen (yebyen@adelphia.net) on Sunday December 26, @03:10PM EST (#144)
(User Info) http://home.adelphia.net/~yebyen/
|
Even worse, if modified clients can't connect, then what's the point of open sourcing something???
Damn the man [page] |
Re:possible work around... (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:24AM EST (#373)
(User Info) |
When playing a standard game modified clients shouldn't be able to connect. If you make a modified client, you should run a server that allows that client to connect. If you made a substantial improvement you could try to convince other people to run that on their server.
I waste too much time playing quake and quakestyle games and one of the most frustrating feelings is wondering if your opponent has some advantage that you don't know about.
|
Fundamentally wrong approach (Score:1, Interesting)
by Anonymous Coward on Sunday December 26, @01:53PM EST (#55)
|
| JohnC's suggested solution to this problem is fundamentally the wrong thing to do. What he suggests is nothing more than a software arms race against cheaters. It has nothing to do with "open" and "closed" source -- there have certainly been cheaters before, and there will be more now that the source is out there. It doesn't matter how sophisticated the anti-cheat technology is; as long as the client software runs on an untrustworthy client's system, there is a possibility of somehow subverting it in ways that make it possible to cheat. The problem of running trusted software on untrusted systems is an active area of theoretical research, and it shouldn't surprise anyone that it's not a problem that looks like it's generally solvable. This is just like why software copy protection was a poor idea. It didn't matter how sophisticated the copy protection software got; the crackers simply got more sophisticated, too. And meanwhile, the innocent people get caught in the crossfire and really pay for it. So what to do? How about exactly what's been done with cheaters before? If a player appears to be cheating, make a movie and make a judgement call. If there's good reason to suspect cheating, don't let that player play on your server. Social policing and a community understanding that cheating will not be tolerated seems to me to be a far more practical solution than an arms race.
|
no, no, it's a GOOD thing (Score:0)
by Anonymous Coward on Sunday December 26, @01:53PM EST (#56)
|
Strictly speaking, under the GPL, wouldn't the cheaters have to make their code changes publicly available? When we all can "cheat" equally, we are again on a level playing field.
--removes rose-colored glasses--
Of course, any attempt to make the case that this is a drawback inherent in open source software would be just plain wrong. A cheat, in terms of Quake, translates to a technical advantage with other software. While a Quaker might be looking to squeeze off more rockets per second, a software vendor might be looking for faster database access, or better device drivers. The game environment insists that players observe essentially artificial limits, for the sake of sportsmanship. The real world environment has no such limits.
|
| |
Re:no, no, it's a GOOD thing (Score:0)
by Anonymous Coward on Sunday December 26, @02:05PM EST (#69)
|
The modified clients only need to be distributed in source if they are distributed in binary form. The user/author doesn't need to give out the source if they only use them for themselves. The affect of the GPL on distributed systems was discussed recently on gnu.misc.discuss.
|
Unfortunately, no (Score:2)
by / on Sunday December 26, @02:20PM EST (#88)
(User Info) |
Unless the cheater is distributing his modified client to others, the GPL does not require him to release the source code to anyone. The distribute-the-source requirement isn't tied to the act of source modification -- it's tied to the act of distribution.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes |
no no no (Score:1)
by Siva (someone@antiquark.subatomic.org) on Sunday December 26, @02:26PM EST (#97)
(User Info) |
Strictly speaking, under the GPL, wouldn't the cheaters have to make their code changes publicly available?
what makes you think that someone who hacks up their client to give them an advantage is going to want other people to have that same advantage? exactly how do you think this is going to be enforced?
When we all can "cheat" equally, we are again on a level playing field.
what about those of us who WANT to play the game in its original form? i dont want to have to modify gameplay just to compete fairly with some fscker who doesnt want to play fair.
--Siva
Keyboard not found.
Press F1 to continue. |
Re:no no no (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:29AM EST (#375)
(User Info) |
I don't think there is any way to play a "virgin" game against others online, at least not in the games I've played. Primarily I play quakeworld teamfortress and starsiege tribes. Not too much tf anymore. In neither game did I have the illusion of everyone else playing it in it's "virgin" form as I do. Both had the capability to do scripting. Where sequences of commands are bound to keys. Neat and powerful, but now the game is a competition between who can make or find better scripts and play better than just a pure competition based on gameplay.
|
So what? (Score:0)
by Anonymous Coward on Tuesday December 28, @02:31AM EST (#471)
|
Yeah, let's suppose I wrote QW autoaim patch. Also let's suppose that I want to distribute it. I can do it with sources included. What's wrong with it? Does it help other people playing fair?
|
Client/Server gaming (Score:2)
by Gleef (gleef@capital.net) on Sunday December 26, @01:57PM EST (#60)
(User Info) about:mozilla
|
If opening the source of the client made multiplayer cheating possible, then it was possible before the source was open, just harder to implement. The obvious solution isn't really a fix for Quake, but care in the design of multiplayer games.
In any multiplayer game, you have a server and at least two clients. Anything critical and cheatable should be on the server, anything computation intensive should be on the client. For example, the client determines the keyboard/mouse/joystick/whatever state, and sends it to the server. The server resolves the action, and sends a schematic of the situation to the client (health, ammo, layout of area, etc.). The client then handles the 3d rendering, sound mixing, and so forth. No amount of cheating on the client end (short of out of game attacks on the other's computers or networks) would affect any other players. Cheating could be done on the server end, but there will always be cheat-free servers available.
----
Open mind, insert foot. |
| |
Re:Client/Server gaming (Score:1)
by Morlenden on Sunday December 26, @02:35PM EST (#107)
(User Info) |
| This makes the server more expensive. Another way to avoid cheating is to have both clients compute the "important" state and compare results between the two machines. The comparisons can be done on the clients.
|
A bot wont hurt you? (Score:0)
by Anonymous Coward on Sunday December 26, @05:23PM EST (#265)
|
First of all the client doing the rendering allows an array of vision cheats, because the turnrate is way too high to not have whats behind you stored client-side at all time you can use that information to have eyes in your back. Same goes for stuff behind walls.
And theres no solution for bots, if worsed came to worse you could just read the framebuffer do some pattern matching and use that to generate keyboard input... although it would take some good AI and a lot of processing to make a good bot like that :)
What you describe is already what quake and its descendants are mostly like.
|
binary integrity (Score:1)
by Emphyrio (emphyrio@rvdm.op.het.net) on Sunday December 26, @01:59PM EST (#62)
(User Info) http://rvdm.op.het.net
|
As far as i know, the only way to check for non-cheating binaries is allowing a fixed set of binaries that are known to be non-cheating.
This is a Bad Thing (tm) - because who's going to check and verify them ?
The binaries would have to fulfill a couple of conditions: - They are known not to cheat
- They have a valid checksum
- They have been entered into the closed source checking system.
As far as i know, only point 2 is manageable, and not bad for things.
How do you know a binary is not cheating ? - somebody would have to do a _really_ thorough source analysis (i.e. diffs), and analyzing diffs is not a fun thing to do.
Then there needs to be a trusting party, that allows trustworthy people to enter the trusted checksum into the closed source checking system, wich will be a slow, annoying process that will return on each new binary release. (public key encryption/gpg and stuff might make a difference, but it's _still_ annoying to have to have your source checked (and compiled!) by a trusted party before you can use it on the game servers...)
If anyone has a better idea - i can always miss something...
I think that playing games using cheats is just not fun anymore. I also think that cheating players can be easily identified and booted out by the server administrator; unnoted cheats don't make that much difference, and are not always a Bad Thing.
Using opensource game systems will (as far as i know) always allow cheating, unless there is a _server_ solution that identifies that somebody's cheating - and we will probably not have that until everybody runs around with huge origin2000-ish computers, and the server is 1000fold that.
Just my $.02..
Emphyrio
|
This isn't a new problem (Score:1)
by JamesKPolk (multivac @ fcmail.com) on Sunday December 26, @02:03PM EST (#65)
(User Info) |
Ever heard of netrek? http://www.netrek.org might help you if you haven't, or if you've heard the name, but know nothing about it (as I did yesterday).
Here's an open source game, with binary client distribution. Cheating problems get minimized, because they use the awesome power of mathematics to authenticate the clients (the FAQ calls it RSA, so I bet it's based on some public key cryptography).
GPL Quake could do the same thing.
Don't blame open source for the problem; look to open source for the solution!
|
| |
Re:This isn't a new problem (Score:0)
by Anonymous Coward on Sunday December 26, @04:02PM EST (#191)
|
I think ID software should leave it closed sourced, but impliment the system used at netrek. It would make cheating very difficult
just my $.51.5
|
Re:This isn't a new problem (Score:0)
by Anonymous Coward on Sunday December 26, @04:42PM EST (#232)
|
You say:
Cheating problems get minimized Yes, but they are not eliminated. People will still cheat. The only true way is to close the source. It should never have been opened in the first place.
|
Re:This isn't a new problem (Score:1)
by JamesKPolk (multivac @ fcmail.com) on Sunday December 26, @07:47PM EST (#324)
(User Info) |
Closing the source will work, like with real Quake/Q2/etc, eh?
Cheating occurs as long as one factor remains constant: humanity. The rest is damage control.
|
Re:This isn't a new problem (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:31AM EST (#376)
(User Info) |
Well put, the problem is unstoppable at it's core. And it's always been around.
|
Ultima? (Score:1)
by Kaht (orbitz~at~mail~dot~igormud~dot~org) on Sunday December 26, @02:04PM EST (#67)
(User Info) http://www.satpal.tsx.org
|
Correct me if I'm wrong, but didn't this happen with Ultima Online 8? I believe I heard that they had open-sourced it to try and get improvements made to it, and people used the source to find all the secrets and such.... like letting players on a MUD see the code to all the monsters.
Anyway, does anyone have any suggestions other than the depressing don't-open-source-stuff-no-more one?
h3o - better than caffeine. |
| |
Re:Ultima? (Score:0)
by Anonymous Coward on Monday December 27, @12:14PM EST (#436)
|
I could be wrong, but Ultima ONline has never been open source
|
This is impossible to stop, so please grow up (Score:4, Interesting)
by Terje Mathisen on Sunday December 26, @02:06PM EST (#71)
(User Info) |
I discussed this with John Carmack back in May, the real problem is that it is absolutely impossible to make a completely cheatproof system. This is because it will always be possible for a cheater program to load the original program along side itself, and then use this to reply to things like requests for a MD5 checksum of a random area of the executable. Closed source helps only in making it harder to reverse engineer the protocols used, it is no real solution. Terje
"almost all programming can be viewed as an exercise in caching" |
| |
Re:This is impossible to stop, so please grow up (Score:1)
by IMarshal on Sunday December 26, @02:13PM EST (#77)
(User Info) |
No, it's not impossible if you define your client-server protocol in such a way that the server ends up making all the decisions. In this way all input from the various "hacked" clients can be validated and the trust problem is greatly reduced.
Of course, for a game like Quake this isn't necessarily feasible because of performance and latency concerns. But for other types of games, like (for example) an Open Source Age of Empires, it could be easily done.
|
Re:This is impossible to stop, so please grow up (Score:1)
by AtrN on Sunday December 26, @02:29PM EST (#100)
(User Info) |
And how is the validation supposed to tell the difference between hacked clients and very good players? It's Turing's "Imitation Game" problem. There will be some things that are obviously wrong and can easily be detected but a skillful cheater will be able to game some advantage and remain undetected.
|
Re:This is impossible to stop, so please grow up (Score:2, Interesting)
by Skinka (mikko.kinnunen@cs.helsinki.fi?Subject=Slashdot) on Sunday December 26, @04:34PM EST (#224)
(User Info) |
| No, it's not impossible if you define your client-server protocol in such a way that the server ends up making all the decisions. So how exactly does the server tell if a client is using an aimbot?
Thats right, it doesn't.
|
Re:This is impossible to stop, so please grow up (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:33AM EST (#377)
(User Info) |
You are assuming that the client is sending result information to the server. This is untrue. The client is sending control information back to the server. Hacking that info is practically impossible to stop
|
Re:This is impossible to stop, so please grow up (Score:1)
by Terje Mathisen on Monday December 27, @07:29AM EST (#410)
(User Info) |
This does not work:
Only sending the info which is currently visible to a human player only means that an aimbot cannot send off a rocket before a player comes around the corner, but railgun hits from across the map is still easy.
Since a FPS is a real-time game of dexterity and reflexes, you cannot have the server making all decisions. I.e. the user has to do the aiming and press the fire key/button.
These are the two most important decisions, along with running/navigating the level.
Terje
"almost all programming can be viewed as an exercise in caching" |
It's a protocol problem. (Score:1)
by Russ Nelson on Sunday December 26, @03:59PM EST (#187)
(User Info) http://russnelson.com/
|
The problem, Terje, is that Carmack decided to cheat on bandwidth, and tell the client more than they deserved to know. Yes, it makes the game more responsive and faster. However, it also allows cheating by a hacked or proxied client. There may not be any good solution for Q1, but in the long term the server will have to only tell clients things they should know.
-russ
|
How much does that add really? (Score:0)
by Anonymous Coward on Sunday December 26, @05:28PM EST (#269)
|
So an aim bot can shoot behind and front instead of just in the front... big deal. Even if the client only knows as much as it needs to know to render the present frame that doesnt preclude cheating. And on the internet its just not an option.
|
correct (Score:1)
by ranton (ranton@uti.com) on Monday December 27, @10:25AM EST (#424)
(User Info) |
And that is why you need to go Closed source. That will keep a game fun and cheater free for the longest possible time. And maybe then you can put out a patch with a different protocol so that all the honest players can stretch play cheater free for a little longer until the next version of the game comes out. Then it doesnt matter any more, cause there will be a better game to play.
|
Authentication (Score:2)
by robertchin (robert@nospam_pophost.com) on Sunday December 26, @02:08PM EST (#74)
(User Info) http://qin.gameshadow.com
|
They should build a small scripting language into the code, and upon connecting to a server, a specialized authentication program could be downloaded off of the server. Ideally this would be a different authentication program, or a set of programs that are rotated. This program then would generate some sort of PGP-type signature of vital files, and return it to the server. The server would then look at the signature and see if it matches the signatures in its database, thus determining whether the client was a valid one or not. The scripting language would be limited on commands, to prevent any sort of abuse. Since the script sent by the server could be pseudo-randomly rotated, the client would never know exactly which response to send, if it were a hacked client with cheats.
-- "Curiosity killed the cat. And, in fact, curiosity could kill Schrödinger's Cat -- and quite often does -- 50% of the time." |
| |
Re:Authentication (Score:2)
by sjames (sjames@nospam.gdex.net) on Sunday December 26, @03:27PM EST (#154)
(User Info) http://www.members.gdex.net/sjames
|
Since the script sent by the server could be pseudo-randomly rotated, the client would never know exactly which response to send, if it were a hacked client with cheats. The problem is, the script would be running in a client created environment. It wouldn't be hard to make the script see what it expects to see by modeling the process/files image of an unhacked game. If the model is complete, it won't matter what the script does.
|
Re:Authentication (Score:2)
by robertchin (robert@nospam_pophost.com) on Sunday December 26, @08:21PM EST (#331)
(User Info) http://qin.gameshadow.com
|
However each script would try to authenticate the environment using a different method. The people that ran the servers could write custom scripts, using new methods of authentication, methods which a hacked version may not know about (since each script is could be custom written, there could be an infinite number of ways to authenticate the program files).
-- "Curiosity killed the cat. And, in fact, curiosity could kill Schrödinger's Cat -- and quite often does -- 50% of the time." |
Re:Authentication (Score:2)
by sjames (sjames@nospam.gdex.net) on Monday December 27, @05:31PM EST (#463)
(User Info) http://www.members.gdex.net/sjames
|
However each script would try to authenticate the environment using a different method. It still doesn't matter, I just load an unhacked version up as a captive task, and feed it whatever I get from the server. It replys, and I feed that back to the server. It is NOT simple, but it CAN perfectly model what an unhacked game looks like, and it CAN make the script see only the model. At that point, even if the script checksums the entire process image, and all of the files, it will be fooled. Remember, the script runs in a hacked VM.
|
This is not an Open source problem (Score:5, Insightful)
by color of static (smasters@ieee.org) on Sunday December 26, @02:12PM EST (#75)
(User Info) |
I have spent much of the last year developing systems/protocols for hostile client to trusted server connections. There are ways to do this, but it requires that the base protocol be designed with it in mind. I don't know the quake protocol, but I will try to describe a possible method.
The client connects to the server with a request for a unique ID. What comes back is a two part ID, one public, one private. The client then makes universe change requests (movement of client in the universe, firing, etc...) with the pub ID, request, and a hash of the above with the priv ID. The server then can verify it's the same person that requested the ID (PKI can be used to send the intial ID back if snooping is a problem). The server sends back universe updates along with the verification. If you want these can be signed with the priv ID.
If you want to do object tracking then the objects could have seperate signatures so they are unique and verifiable. Ammo could also be tracked with a sub object or something like that.
Basically any rule that you don't want broken need to handled on the server in this model.
Encryption could be cut down to a low level to prevent computaional slowness and export problems. Even a mild algorithm would be acceptable so long as the key secure until the end of the game against a single PC.
If you want to do peer to peer, or move more handling back to the client, then one would have to look into one of the many blind poker algorithms, but it to should be doable.
|
| |
Re:This is not an Open source problem (Score:0)
by Anonymous Coward on Sunday December 26, @04:40PM EST (#230)
|
This won't solve the problem. The cheaters will find other ways to cheat.
|
How does that solve bots/vision hacks? (Score:0)
by Anonymous Coward on Sunday December 26, @06:00PM EST (#284)
|
Because of the way the internet works the client has to store a lot more state information than just whats needed for the present frame... wich allows you to do look behind your back/wall kind of tricks. And of course theres the good old model hacks, wich checksums never really solved. (initially the checksum was just send unencrypted over the Quakeworld connection for instance, so changing it to the valid number with a proxy was trivial... but however you implement an integrity check you can get around it)
The encryption you describe sounds like a symmetric one, or diffie/hellman at best. (since you suggest the key could be broken) The first can be easily broken by finding the way the key is stored in memory, and for the second you just use the man in the middle approach. You really need a large public/secret key pair.
And even if you get the integrity checks so good hacked executables/models are not possible, and you use RSA with large keys to make proxies impossible... there will always be ways to use an aim bot.
|
Re:How does that solve bots/vision hacks? (Score:0)
by Anonymous Coward on Sunday December 26, @06:04PM EST (#285)
|
Oh wait, you could of course still use smaller public/secret key pairs just for the running connection... you would just need to pass the small public key via encryption with the large secret key during the log on.
|
Re:How does that solve bots/vision hacks? (Score:2)
by color of static (smasters@ieee.org) on Sunday December 26, @08:15PM EST (#330)
(User Info) |
I only meant using encryption for the object tracking and inventory problem. The signature would be used to verify from the server, back to the server that the client really does have what he says he has.
When it comes to computerized aiming, and target tracking, I'm not sure there is a way around this other then sending a spoiler input to the aiming control system, or recognizing it based on the response.
Maybe this is something more like what postal chess does. Have everyone register to get on a server by giving personal info, and then boot them of if there is a problem. To make it work might be slow and intrusive. Then again I always liked just playing against the computer much better.
|
Unrelated: How I plan on doing it. (Score:1)
by tietokone-olmi (at-my-home-page-dummy) on Sunday December 26, @06:47PM EST (#308)
(User Info) http://www.pp.htv.fi/~ksandstr/
|
I'd hate to start a new thread, so I'll just follow up to this one :-) Hope you don't mind. I've been working on a multiplayer networked rocket game (see Turboraketti 1/2, turbis and others for a definition of "rocket game") for a while, and I think I've solved the clientserver trust problem pretty well, although the result may not be satisfactory if you're on a slow / laggy link. I designed the client -> server part of the protocol so that the client only tells the server what changes to the state of the user have just occurred. It is then up to the server to cause that player's ship to turn, fire its engine or something like that. But the point is, the input data packets don't contain anything that could be falsified (like a command "move my ship to some random position and set its velocity to 0,0", to quickly get out of trouble when no such thing can be done without cheating). This also causes the client not to be able to compensate for its lag to the server, but hey - life is tough. The server also keeps count of shots fired, checks for collisions and other stuff like that. Most of the calculations are also shadowed by the client program, so object movement is pretty smooth with relatively low consumption of bandwidth. This scheme also doesn't require encryption; the server simply performs strict sanity checking of all incoming packets and kicks clients who violate certain constraints right out. This should make the server side completely cheat-proof, unless I've been smoking crack at some point and just haven't noticed :-) Unfortunately, as I see it, this method of client-to-server communication can't be easily migrated to Quake, and absolutely not without breaking backward compatibility.
No .sig to see here. Move along, citizen. |
Damn cheaters (Score:1)
by jcs (jcs at jcs dot org) on Sunday December 26, @02:14PM EST (#79)
(User Info) http://www.superblock.net
|
All this time I thought I just really sucked at Quake and I find out they were cheating.
$selfesteem++;
--
Joshua C. Stein
Superblock Information Systems
http://www.superblock.net |
Interesting possibilities. Mostly questions. (Score:1)
by Greg Merchan on Sunday December 26, @02:15PM EST (#81)
(User Info) |
I haven't play networked games in a while and never more than a few people in the same real world room, so please flame me (on email, find it) if anything I suggest is too ignorant or stupid.
Could a peer-to-peer, instead of server-client, system be useful to stop cheating? I have no idea, but since the .plan mentioned trusted servers et al. I immediately thought of trusted peers.
Maybe a new gaming paradigm should be introduced. 'To the best coder go the spoils,' anyone? 5 words: Dual Alpha Beowulf Bot Army.
Is anyone working on a VR client that could turn the gaming environment into a sort of 'holodeck'? With the appropriate hardware and code, we could make our Quake-selves look like us (or otherwise) and mimic our realworld movements. Add to this the peer-to-peer setup and then I'll show you a real home page! (No tactile-feedback fighting, please.)
Didn't everyone else think they would have caught on the manipulating 'The Matrix' while in it?
|
| |
Re:Interesting possibilities. Mostly questions. (Score:1)
by UnknownSoldier (mpohores@NOBLOODYSPAMsfu.ca) on Monday December 27, @12:08AM EST (#370)
(User Info) |
> Could a peer-to-peer, instead of server-client, system be useful to stop cheating
Nope. Descent 1 and Diablo are peer-to-peer networking games, and both have cheats.
In fact, peer-to-peer games make it EASIER to cheat, due to the game state being stored localy. Thats WHY server-client games are preferred: The client can't as easily change the game state.
Unfortunately, it is IMPOSSIBLE to verify binary client integrity.
Furthermore, how does the server tell the difference between a real human, and a aimbot?
I'm a game developer and game player. Cheating is a fact of life, that will never go away.
Cheers
|
Possible solution perhaps (Score:2)
by gothic (axe@crown.net) on Sunday December 26, @02:17PM EST (#84)
(User Info) |
As a non-quake player, I can't say for sure what exactly a client reports to a server.
Exactly how hard would would it be for the server to be a little more intelligent? If a cheating person is shooting someone with a machine gun doing 50 points of damage per shot, I *think* it wouldn't be hard for the server to notice that the gun is doing too much damage. Maybe have the server know what damage each gun does, how much health a person should have, and how quickly a certain gun fires/recharges. In my thinking, I wouldn't assume that would be hard to do, but I'm always ready for corrections.
If this was actually possible, perhaps a flag could be added to the server. Something like AllowPlayerCheat=On/Off ...If the server doesn't want cheaters, and it detects one, it can boot them off with a message of "Player 1 was cheating, and has been removed from the game"
To me, that's a pretty simple solution, but I also assume it would seriously bump up the required bandwidth, and also bump lag up. Again, I'm not sure what info is already passed to the server, but I'm assuming it will pass something about hit/miss fires from a gun, or how much health a user has left to drain.
In a scenerio like this, I assume you would just now have to rely on servers set to not allow cheat, or if they do, let people know. Anyone think of a way around that? I'm up for opinions, as this is pretty interesting.
On a side note, I don't think this actually damagages OSS, but proves at how quickly people can find paths that could damage your hard-worked program, amongst other pos. bugs...
--There's a cow parked in my driveway-- |
| |
Re:Possible solution perhaps (Score:3, Insightful)
by Hard_Code on Sunday December 26, @03:11PM EST (#145)
(User Info) |
The problem, though, is not invalid behavior. Invalid behavior can be shoved to the server and verified. What is a bigger problem is valid, but highly improbable behavior. For instance, since my client knows everthing about the state of the world, I can program valid, but highly improbably inputs, that allow me to dodge most anything, simply because I /know/ the trajectories of everything. Now is this legal? Of course...it is /possible/ that I could really have the skill to do this...but very improbably.
As long as the client knows everything about the world, these sort of exploits will be possible. I think the current protocals maintain a state in the client and then sync that state frequently. The client "knows" the state though. The only option is for the client /not/ to know the state of the world, but only the portion it can percieve. But since the permutations of changes of one state to another is smaller than the permutations of all possible states, I think it has been easier to do the "push-state-and-sync" method rather than "redefine-state-every-time".
Jazilla.org - the Java Mozilla
Attn spammers |
Re:Possible solution perhaps (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:39AM EST (#379)
(User Info) |
I believe that qw does limit some knowledge of the world to a player's immediate vicinity. But the whole point of a FPS is that you can see what's coming. If your computer draws it on the screen, a cheat can be made to avoid it.
|
synchronization solution? (Score:2, Interesting)
by onethirtyseven on Sunday December 26, @02:26PM EST (#96)
(User Info) |
One potential solution is to have all keyboard/joystick/etc. input be sent to all the other clients before any of it is handled. (This is like the client/server solution mentioned earlier, but treats everyone as servers.) As long as all the user input is applied synchronously at each client, and each client has the same set of deterministic rules, the game will proceed consistently. If anyone cheats (in any way that causes a change in the actions/properties of the objects in the game) then the game will lose consistency. To check this, simply have each client checksum their data every once in a while. If someone has a bad checksum, throw them out of the game (by a vote of the clients). If someone fakes a checksum, then they can continue playing, but they won't be seeing the same game everyone else is. One advantage of this method is that it does allow modification of the game source, as long as everyone uses the same set of modifications.
There is one game that attempts to use this mechanism (here), but it is incomplete (mostly graphics issues currently). I'm not sure that this approach is viable in practice, but I think it works in well in theory.
|
| |
Re:synchronization solution? (Score:1)
by Risen Devil on Sunday December 26, @04:11PM EST (#202)
(User Info) |
Doom's network play was designed that way.
It falls apart with unreasonable/unpredictable data lag times.
Read: Playing on anonymous servers on the Internet.
|
Re:synchronization solution? (Score:1)
by Nathan Mates on Sunday December 26, @04:49PM EST (#239)
(User Info) |
| I'm the network programmer on Battlezone II [see the Official site here ], and we're using such a setup. It looks as if at least one other game is using a similar method; see here also. Only user inputs are sent around in BZ2, and used by every machine in the game to compute a new gamestate; if a client disagrees with the server, we can either shove a correct gamestate do that client, or kick them out. While traditional lockstep methods do have smoothness problems due to unpredictable transmission delays over the internet, on BZ2, we developed an interesting solution which we call 'Multiworld' -- sorry I can't say much more than that. Even with synchronization, there still are client-side hacks that can be used-- people changing texture maps to show enemies more clearly, perfect radar hacks, and more. Even if everything's checksummed up the wazoo and that "works" (hah), a hacked driver can do fun stuff with texturemaps, or more. This all points to one fundamental problem in computer security: on a system, there is at least one user (and/or process) that can read another processes's memory. Just that abiity is enough to develop cheats. [See: perfect radar above.] Unix's root account can do that, so it's really no better in terms of trust than Win95/98. Fully stopping cheating is a problem not in computer science. It's a problem in humanity-- we're buggy to the core. Nathan Mates
BZ2 Network Programmer
http://www.visi.com/~nathan/
|
another pointless post (Score:0)
by Anonymous Coward on Sunday December 26, @02:28PM EST (#99)
|
hehe...if it can be exploited, u can be sure it will be.
|
What's the problem (Score:1)
by seaportcasino on Sunday December 26, @02:30PM EST (#101)
(User Info) http://www.GreatWorldCasino.com
|
It's not cheating if everybody can do it? It's just another way of showing that brains, not brawn wins the battle. Somehow us old (20+) software engineers have to even the score against those 13 year olds with unbelievable reflexes and non-carpul wrists. Some of us didn't go to college for nothing you know.
Play a few hands of blackjack at www.GreatWorldCasino.com and let me know what you think of my Java Servlets! |
| |
Re:What's the problem (Score:0)
by Anonymous Coward on Sunday December 26, @04:49PM EST (#238)
|
When i was 13 i had carpul tunnle syndrome
i had been using a computer since i was like 5 or 6 for long periods of the day 6-8 hours on end. In ms-dos i went went through my 80mb harddrive and moved to a 1.2gb then i filled that.
now that i am 16 my reflexes are slow but my mind is quick. BTW since all gaming has gone to the net what is happening to single player? the Quake3demo had a nice single player setup. play against the computer bots prepare you for multiplayer.
|
Re:What's the problem (Score:0)
by Anonymous Coward on Sunday December 26, @05:02PM EST (#246)
|
You are so right when you say:
It's not cheating if everybody can do it? Let's all remember that it's not drug abuse when everybody ab/uses drugs! Free drugs for everyone!
|
Just move more code to the server (Score:0)
by Anonymous Coward on Sunday December 26, @02:31PM EST (#104)
|
The solution to this is ludicrously simple: move inventory and damage control to the server. When a client goes over an item, make it so that it can't automatically add that to inventory, but instead the server becomes aware, and informs the client it has more inventory at its disposal. It keeps track of rounds fired, etc. Instead of having the client monitor damage, similarly, the server would inform the client when it was hit. To cut down on bandwith traffic, the server and client could both keep track, and when the client requested items it didn't have, fired a weapon where it had no more rounds, or tried to keep going after it died, the server would not allow it. The client could show others being shot at all it wanted with whatever weapon the person wanted; it just wouldn't have any effect in the arena, because the server would know that it didn't make sense, and not show the cheat. This wouldn't be too difficult to implement, I would think, though it would increase the server's hardware requirements. However, it does have the advantage of being an effective open-source solution.
|
| |
Its already there (Score:0)
by Anonymous Coward on Sunday December 26, @06:05PM EST (#287)
|
nuff said
|
Re:Just move more code to the server (Score:0)
by Anonymous Coward on Sunday December 26, @06:11PM EST (#288)
|
I have done a lot of Quake 2 programming and I am pretty sure that extra health and ammo is _not_ a concern since the server does manage all of that. The big problem here is auto-aiming! Since the client decides when/how it will aim and when it fires, the server really can't do anything to restrict this except to detect bots by noticing machine-like behavior (the zbot for Quake 2 could be detected in this way). It would be incredibly easy for someone to go into the source code and make it so when the user presses the fire button, that the client will automatically aim in a straight line at the nearest target and fire. And how would the server know the difference? If you were clever, the server wouldn't know the difference, that's the scary thing.
|
Re:Just move more code to the server (Score:1)
by higuita (higuita@clix.pt) on Sunday December 26, @06:59PM EST (#310)
(User Info) http://raff.fe.up.pt/~eq92025/
|
much of this already happends, the server do all the game, the client only show it, and send the movements...
but...there is still the problem of the client seeing all (invisible walls, people and itens map), know where are the other guys, how they are (life, ammo, shield, gun) and finally bots help (when a bot helps the cheater in the aim, autofire, or escape of the incoming fire )
but many of this already happends now...
i saw one demo of quakeworld deadmatch where the cheater fly, auto-aim and auto-fire all the people in range...there was 5 guys playing and none could reach near him
i saw little time ago a quakeworld TF where the map 2fort5r had invisible walls and the chater could see the other guys coming in
cheats existe and will continue to exist... Open source or close source...
we must only check the cheaters and try to block then out of the servers...
humm... just remember this...... a vote kick...
when some one think that other is cheating, voted to kick him out... if more than 50% of the server vote on his kick, he is gone (kicked that is)
this way normal players can kick out the cheater without haven to wait for the adm
cya
Higuita
Higuita |
Excessive Trust In Game Design (Score:5, Interesting)
by Effugas (effugas@best.com) on Sunday December 26, @02:32PM EST (#105)
(User Info) http://www.doxpara.com
|
No, no, no.
Most, *not all*, but most client side hacks work because the server is trusting the client to provide data that provides state data regarding a separate client not under the same security/permissions context.
For example--I shoot a rocket launcher at you, and the server lets me decide whether or not the rocket hits. It doesn't matter whether the system is open or closed source--this is a flaw. Give a dedicated opponent a day with TCPDump and rockets will be teleporting all over the place.
Any server, whether it is a game server, an IP Telephony Gateway, or a simple web proxy, must be designed to exclude all contexts but those that originate from the client from what content will be accepted from that client.
This is not an impossible endeavor. Starcraft, for instance, has binary modification software that changes unit commands. Even in a peer to peer two player game, the modifications work perfectly until they ask a unit to execute a command that unit cannot do. Then, the other client detects the cheat and the game is immediately cancelled.
The immediate response, of course, is that this peer to peer arrangement prevents information hiding. If your client is always verifying that other clients aren't cheating, then you can always watch the incoming datastream to know what's going on. Therein lies the reason why peer to peer isn't a particularly good topology for competitive gaming--there's no server to restrict the visible dataflow to that which the given client should see.
Interestingly enough, the most inevitable (and least fixable) hack involves changing not the game but the video card drivers. Metabyte, the dementedly gifted hackers that gave gamers the first multi-API stereovision solution(and the single-pixel-resolution-adjustment power for Voodoo 2's), had a single revision of their drivers out for one day that artificially forced transparency on all surfaces. They called it X-Ray--needless to say, it made shooting around corners quite a bit easier. It also got shouted of existence rather quickly ;-)
Reminiscent of Crypto, ain't it? Where's your trustable end point?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
==== Some people live life in the fast lane. I live life in oncoming traffic. ==== |
| |
A big "But..." (Score:2)
by kaphka (matthew.s.keitz@bigfoot.com) on Sunday December 26, @03:23PM EST (#151)
(User Info) |
You're abosultely correct that "game security" should be enforced by the server, and the server API should disallow any request from the client that would violate the rules.
But there's a huge practical problem in implementing that. When rule processing is done on the server, the client must wait for the server to process each rule. Even if you have a lightning fast network connection, eventually relativity limits the speed at which that sort of communication can travel. (Congrats, Al!)
For example: Let's say player A has some sort of invisibility power turned on. (I know very little about Quake, so I'm speaking generically.) Ideally, the server will not report player A's position to any other client, since the other players aren't supposed to know. But what happens when player A steps right in front of player B, turns off his invisibility, and starts shooting? Player B's client now needs to download all of player A's properties from the server. (Maybe even custom textures, sounds, or other bandwidth-intensive data.) And the client needs to do this fast enough to seem instantaneous to player B.
That's generally not possible, and that's why network games often need to place some trust in their clients.
MSK |
You could still make it work ... (Score:3, Insightful)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @04:09PM EST (#199)
(User Info) |
But first , let me point out that your example is a bit off. Player B doesn't need to download all of the players properties from the server , because the scheme is that the server knows and manages everybody's health. Also, the problem with skins, custom sounds, etc. is not related at all to the GPL Quake since you can do that with closed source version already. I think the current scheme is to simply ignore custom sounds/skins/etc and just use the standard ones, so that if you look like Barney you still look like a grunt to me :) [this is how it works in half-life]
Anyways, I think the general point you were trying to make (and very valid) is that waiting for the server to "approve" an action might take too long, and you're right. Unless we get really fast network connections, the only other way around this would be to use a hybrid approach hwere the server sortof trusts the clients, but then "audits" some players (randomly, or top players) and even if it let's actions go through (for speed) it might still reserve the right to analyse them and kick you out later. Once a cheater has been detected , his/her actions could be undone or simply ignored and the player is kicked out/banned from the server.
Flame on ! - Johnny Storm, Fantastic Four |
Re:You could still make it work ... (Score:2)
by kaphka (matthew.s.keitz@bigfoot.com) on Sunday December 26, @05:31PM EST (#271)
(User Info) |
Like I said, it was a generic example. I think we're more concerned about open source games in general than about a particular 5 (?) year old program, anyway. Regardless of what data you're actually transferring (how about the position of your opponent?), in practice you're going to end up spending a lot of time waiting for the server.
Your suggestion is an excellent one, and I hadn't thought of it in this context before. (Although it comes up a lot whenever we discuss open source distributed computing. It would solve 90% of the problem, but ironically, it doesn't help in the particular case that I described: What happens when the server needs to hide information from a player, but the client needs that information to provide reasonable performance? I.e. the location of an invisible player. Once the server gives up that information, it has absolutely no way of ensuring that the client software will hide it from the player.
MSK |
Re:You could still make it work ... (Score:1)
by journey- (journey@jps.net) on Sunday December 26, @05:50PM EST (#281)
(User Info) http://journey.ddns.org/
|
I'm thinking that for most information, besides position, what the person looks like, and what gun they are holding is the only information that the client absolutly needs to know about. This information(in most first person games) is going to be 3 int's for the position(xyz), and another 2 for looks and gun ... that leaves 20 bytes of info ... you could even assume it "needs" to know 3x more that ... thats still 60bytes which will travel over a modem in 1/4 seccond ... only the position would need to be hid for your example.
I'm not sure what other information the clients would really need to have hidden from them(i'm still speaking from a first person game type thing though) .. I just dont see there being that much information to hide, and therefor don't see the lag of keeping the information on other players hidden that big of a deal when it comes to resending it
Erik journey@jps.net |
Re:You could still make it work ... (Score:0)
by Anonymous Coward on Monday December 27, @04:45AM EST (#404)
|
On all uplstream player movement packets you have a timestamp, a CRC, an input hunk, (movement is actually calculated server side, But predicted client side), and client heartbeat/status messages. Plain text messages are also sent up for more exotic commands and chat messages. The primary problem with cheating is mainly using a proxy to determine from sniffing the downstream packets (all essential data in the PVS is sent down for the client to render) and the modifying the upstream packets to send "correctly formatted" data back up, such as a fire command along a wrong vector[straight at the player position that was sniffed out of the downstream packets], thus giving the user of the proxy a perfect aim. Because the code is open sourced, the CRC algorithm on the packets can be discovered, and perfectly replicated by the proxy, making cheaters undetectable.
|
Re:Excessive Trust In Game Design (Score:0)
by Anonymous Coward on Sunday December 26, @03:41PM EST (#169)
|
There is a strict limit to how well this can work in a shoot-em-up game like Quake. The reason is that the (non-cheating) client must be given enough information about enemy location to display them on the map. Thus, a cheating client can auto-target them without doing anything that would look like cheating to the server. This is basically the same problem nettrek has since way back when (and why "competition" clients are binary-only) Strategic games (like your example Starcraft) are a lot easier to make safe from bad clients since then the server only needs to provide what information the client will see. With any game that is a pure test of reflexes it's impossible for the server to tell if the reflexes are client-assisted.
|
Re:Excessive Trust In Game Design (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:48AM EST (#380)
(User Info) |
The client does not dictate whether or not the rocket hits. I've played qw games where because of client prediction, it seems to me that I blasted the person I was shooting at. On my screen I hit the player. But the player who would have surely died, didn't die, because my client did not know the true position of the player only the predicted position. In other words it was an illusion. The server decides what rockets hit who.
|
These guys need to do their homework! (Score:1)
by mangu on Sunday December 26, @02:35PM EST (#106)
(User Info) |
What is needed here seems to be the right authentication protocols. Security is not just encoded communications, without the right protocol, the best cryptographic algorithm is useless.
Recommended bibliography:
1) Bruce Schneier "Applied Cryptography"
2) Menezes, van Oorschot, Vanstone "Handbook of Applied Cryptography"
3) Michael Rosing "Implementing Elliptic Curve Cryptography"
just for fun:
a) Neal Stephenson's "Cryptonomicon"
b) Electronic Frontier Foundation "Cracking DES"
Of course, this is a made-in-USA game, and due to the NSA mandated secrecy around anything related to cryptography in the USA, that country seems to be lagging behind in this respect. Perhaps they should try to hire some consultants in Israel or Russia to teach them the tricks that were originally developed in the USA...
|
| |
No you do (Score:0)
by Anonymous Coward on Sunday December 26, @06:11PM EST (#289)
|
Encryption is only part of the solution of authentication... it can be used to authenticate a connection, but not the client. If you can fake the input to the encrypting authentication routine the encryption doesnt do much good.
|
Re:No you do (Score:1)
by mangu on Sunday December 26, @06:15PM EST (#293)
(User Info) |
That's why I said "Security is not just encoded communications, without the right protocol, the best cryptographic algorithm is useless."
|
Abstraction Layers (Score:2, Interesting)
by Nite_Hawk on Sunday December 26, @02:36PM EST (#108)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
| I never thought I'd say this, but maybe that scheme class I just got done taking actually did me some good. ;) You see, the instructor pounded the idea of abstraction layers into our heads over and over and over again. Never ever let the subprocess (ie client) of a program have access to global variables if they don't have to. Part of this is already there, the client just passes values on to the server. The server code is what needs to be changed. If it could verify every move as being legal or illegal, this problem could be fixed. This would mean that the central server would have a lot more work to do, especially for large multiplayer games, but these days I think most mid end machines should be able to handle it. You basically just have the client do everything it does already, but change the server so that any move that the client tries to make is checked. Does the player still have this much ammo? Is it a valid move for this player to try to go through this wall? Can the gun this player fired do this much damage? etc. If the client tries to make an invalid move, it means instant death. If both the client and server are working the way they are supposed to, you shouldn't need to sync because they will be counting things like bullets the same way, so it shouldn't really be anymore network overhead. If you wanted to get fancy, you could create a mechanism so that when a client logs in, it recieves a set of variables as the "ruleset" for what everything does. (IE how much damage a specific type of ammo does, how fast bullets move etc.) In that ruleset, if something isn't defined, it just uses the default, taking up less bandwidth. In my scheme class, we actually just wrote a basic AI game player to play a game that's kind of a cross between 21, and cross-four. It was implemented very similar to above, but on a much simpler scale. I think it would work for something like quake, but I'm still not sure what the overhead on the server would be to check everything that the player is trying to do. It also wouldn't eliminate the problems of nightvision type stuff. Maybe we could implement a system were in the shadows, the server reports a 50% chance of "seeing" a client being there, and it's the job of the client to render that in whatever way it can do best. So if someone always draws a player being there with a 50% chance of him not being there, and that player fires, he tells other people were he is, and they know where to shoot.
Nite_Hawk #e and #povray - efnet
|
One workable solution (Score:5, Insightful)
by / on Sunday December 26, @02:37PM EST (#112)
(User Info) |
As others have illustrated, it's not the open-source model but rather this particular client-server model that's at fault. Let's see what we can salvage out of the existing model:
Ideally, the server would check all of the client's requests to see whether they comply with the laws of physics, but that is unfortunately unworkable with today's hardware and bandwidth. It is possible to go half-way on this one, though.
If the server simply audits the client's behavior, that is, verifies the client's requests at random intervals, fair play can be insured. Remember: all it takes is one bad request for the client to be banned as a cheater. If the auditing is done at random intervals, then the client can't adapt by spacing its valid requests with the correct interval.
All that's left is for someone to code a server to do this, and then for people to play on only trusted servers. The need for trust can't be eliminated, but it can be lodged solely in the server, where it belongs.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes |
| |
One little optimization ... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @03:55PM EST (#184)
(User Info) |
... to your scheme would be to only audit the "n" top players, because who cares if someone is cheating if they have a crappy score right ?
This would also allow the situation to have multiple servers with different levels of cheater prevention mechanisms. For example, the more bandwith you have the bigger the guarantee is that nobody is cheating (set n to "all"). For low bandwith situations n can be set low (1 , the best player) but you have less "assurance" that others are not cheating on that server.
I'm sure others can come up with many more simple heuristics to overcome the bandwith problem.
Flame on ! - Johnny Storm, Fantastic Four |
Re:One little optimization ... (Score:2)
by Hard_Code on Sunday December 26, @05:04PM EST (#250)
(User Info) |
"... to your scheme would be to only audit the "n" top players, because who cares if someone is cheating if they have a crappy score right ?"
How about a cheat that allowed people to kill teammates? I mean, it really is of no use to someone unless they're an asshole spammer, but there are plenty of those. Score shouldn't be the [only] criteria. Disruption of gameplay is the big one. I mean, if someone had a cheat that exited a level, that wouldn't raise their score but it would really disrupt the game and suck, and have to be fixed.
Jazilla.org - the Java Mozilla
Attn spammers |
Re:One little optimization ... (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @05:40PM EST (#277)
(User Info) |
Like I said, this would be one of many heuristics that can be used.
How about a cheat that allowed people to kill teammates?
I'm sure Quake already checks for that (see John Carmacks comments), and anyways this type of option is a server side switch. The server (right now) knows who killed who and if somebody does this it would be easy to kick him/her out.
I mean, if someone had a cheat that exited a level, that wouldn't raise their score but it would really disrupt the game and suck, and have to be fixed.
This can only be done by the person that has access to the server. A client hack for this would change the cheaters level (map) but not everybody elses, just because a client is modified doesn't mean that the server has been hacked.
Disruption of gameplay is the big one
The problem you're trying to solve is more of spam/annoyance, that is a differnt problem from somebody cheating to try to get high scores. You don't need a hack to annoy other players, this happens all the time now. It happens over and over when I play Counter Strike (Half-Life mode) , when friendly fire is on, there are idiots that get a kick out of killing their teammates. In this case ...
You can't produce code to prevent stupidity(first law of User Interfaces)
But you can ban by IP or serial number, like they do in Half-life.
Flame on ! - Johnny Storm, Fantastic Four |
Wouldn't encryption be better than auditing? (Score:1)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @04:02PM EST (#192)
(User Info) |
| Woudln't encrypting the client/server connection be much easier than auditing each client's requests? I'm not sure I would trust random sampling, though it is a good idea to keep CPU load down (Quake isn't a CPU hog anyways). Random sampling might actually encourage people to try for short lived cheats unless the sampling interval is small enough. As a few of my other posts on this topic have indicated, I really favour two things: - Digitally sign the quake binaries, and give the server the choice of rejected unsigned clients.
- Encrypt the data stream between the client and server so that proxy cheats aren't possible.
|
Re:Wouldn't encryption be better than auditing? (Score:0)
by Anonymous Coward on Sunday December 26, @04:22PM EST (#216)
|
| Encrypting the data stream won't do any good....the client's source is open, so I could simply make the modifications to the client instead of having to use a proxy. and digitally signing the client won't work either...I can make my modifications to the client, then resign it.
|
You wouldn't be able to sign the client. (Score:1)
by winterstorm (qe2sd@winterstorm.org) on Sunday December 26, @04:36PM EST (#225)
(User Info) |
| The idea of digitally signing the client is that there would be a central authority who signs clients, or even better a "web of trust" (many trusted authorities for signing clients). This is how Netrek solved the problem of people writing clients that cheat. So bascially encrypting the data stream and signing the client should work. Because you can only get a client signed by some "authority" who verifies there are no cheats, if you modify the client then the signature is invalid and the server won't let you play. If you try to use a proxy to cheat, your proxy would have to be able to decrypt the client/server conversation in real-time which would should be sufficiently difficult as to stop people from doing that.
|
Re:Wouldn't encryption be better than auditing? (Score:1)
by Unbeliever (unbelver@us.netrek.org) on Sunday December 26, @11:05PM EST (#360)
(User Info) |
And I don't even have to hack the binary to cheat. I just have to run a Windows/X/SVGALib app to play the game for me, or assist me. As in starting up the real client, and sending X events, keystrokes, mouse strokes, etc, directly to the client.
--Carlos V. |
Re:One workable solution (Score:1)
by jesser on Sunday December 26, @04:18PM EST (#209)
(User Info) http://www.palosverdes.com/jesse/
|
but.. auditing can't prevent "translucent wall" cheats. ianaqp (i am not a quake player), so i don't know how common this cheat is.
--
Warning: this sig attracts all other sigs with a force proportional to funniness and inversely proportional to distance squared. |
Re:One workable solution (Score:1, Interesting)
by Anonymous Coward on Sunday December 26, @04:26PM EST (#219)
|
| This makes a false assumtion--that all cheats rely on defying the laws of physics. While such cheats probably do exist (making players able to fly, etc.), I think the main problem is clients that are able to shoot for the player (make it 100% accurate), count quad timers, see through walls, perhaps even move out of the way when a rocket comes near. All of these can be done on the client, and it would appear as a normal player to the server. there's no real way to "detect" cheating...any scheme which you can think of can be worked around. Any information that the client sends to the server for authentication can be faked very easily now.
|
Re:One workable solution (Score:1)
by interiot on Sunday December 26, @04:43PM EST (#233)
(User Info) |
| What about counting the number of shots that missed vs. the number of shots that hit? 100% hit rate is probably not reasonable, especially for machine gun type weapons. But this would mean that the bots would make sure they miss 10% of the time (eg. with useless ammo when there's no one to shoot at).
|
Re:One workable solution (Score:0)
by Anonymous Coward on Sunday December 26, @06:16PM EST (#294)
|
Exactly, and even looking for patterns in bot provided doesnt help much if the pattern searcher is open sourced :) (not that you couldnt fool them in other ways... just record aiming movements for some really good players and use those for your aim bot :)
|
Cheating != Extra Health, Ammo, Weapons (Score:1)
by eh (maxburke at home dot com) on Sunday December 26, @04:28PM EST (#221)
(User Info) |
Just for your information, the cheating that is being talked about is not about giving oneself extra health, ammo, or weapons, but rather the use of such aim proxy bots. These such cheats do all the aiming for the player. These are hard to detect because it looks like the player is exceptionally good, and implementing some sort of proxy bot detector will unfortunately weed out the best of players, calling them cheaters.
Anyways, my two cents Canadian, which is worthless to most of you Americans....
|
Re:Cheating != Extra Health, Ammo, Weapons (Score:1)
by ranton (ranton@uti.com) on Monday December 27, @03:21PM EST (#459)
(User Info) |
Which is why you cannot have open sourced games. It is too easy to fake any authentication protocols within the program. Sorry guys, but we need to keep open source out of games.
|
The closed source client is a waste of time (Score:1)
by ChrisZ on Sunday December 26, @02:42PM EST (#120)
(User Info) |
This is proven not to work, look a software license managers -- When someone reverse engineers it, and they will, then what?
I don't think the 'mental poker' model adapts well to this situation, because the server and client do not have a 50-50 role here. It's a lot easier to have a server cheat than a client. Someone who has a cheating client will get kicked from the server and they lose the multiplayer experience, but the only choice a client that has detected a rogue server has, is to exit the game.
|
nothing left to do but smile smile smile... (Score:1)
by garcia (garcia@tusa.org) on Sunday December 26, @02:44PM EST (#125)
(User Info) http://www.tusa.org
|
No matter what you propose as a possible way to stop the cheating, it won't stop. The availability of the source code (as I have stated above along w/others) hasn't caused the cheating. It was available long before the source was introduced. No matter what the game, no matter how well it was designed to not allow cheating, some asshole will always find a way to cheat. Look at swimming (the sport I am involved in, and the one that has seen the most recent drug problems -- the 84, 88, 92, and 96 Olympics). They have taken drugs that are undetectable, taken other drugs to mask the ones that they took, injected other people's urine, etc... There will forever be ways around pre-existing measures.
I have played against "bots" for years now. I change my alias to BotOwner and even if I don't win, killing the little fuck is more annoying to him (especially when you laugh about it) than he is to me. Just shows that I have more skill than he does if his computer aided shit still can't frag me.
Just get over it. You can spot a cheater the second he joins and everyone just laughs at him. Play until he leaves, he is just trying to annoy you. Just let him cheat, he will get bored of letting the computer play for himself...
Just my worthless .02
-/- Bill -/- |
blah blah blah (Score:1)
by OnlyNou (blank@localhost) on Sunday December 26, @02:49PM EST (#128)
(User Info) |
| so people can go see the source code and change it to work the way they want it to. GREAT!! so everyone will be cheating! this will destroy the quake 1 culture but if those little brats want to do that, then let them. they now have that right. we then just laugh at them and point at all the losers that cheat. there is no honor in cheating. the lessons of cuase and effect must be learned by people. if you screw up the game, then the game becomes meaningless. then POOF, you devalued the game and yourself. once this happens, they'll only be a small group of trusted players, they will do what's needed to check and validate real players. i don't see this being a big problem. life isn't fair and people will abuse you. you won't stop them, you'll just have to work around them.
"you get hit and your head goes ping" --rocky horror |
Problem or Opportunity? (Score:1)
by aerobee on Sunday December 26, @02:56PM EST (#136)
(User Info) |
Frankly, I don't see this as a problem of Open/Closed source. Cheats for various games have been around since games have been. I see an interesting fork here: (1) Client registration that is cryptologically secure for "fair" clients. and (2) a "no holds barred" clients section that would allow hackers to build superbots and have them duke it out in the arena against their own type. Cyberwar of man and machine at its finest perhaps?
my .02; was really a $1 but after taxes...
|
Download on demand (Score:1)
by Compuser on Sunday December 26, @02:58PM EST (#138)
(User Info) |
Since Quake is open-source, how about
having each client download a signed
precompiled client each time they want to
play. The overall source would be open,
but players would deal with encrypted
black box only.
|
| |
Re:Download on demand (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @03:20PM EST (#148)
(User Info) |
Have you seen the size of the Quake binary ? This would really suck up bandwith !!!
Flame on ! - Johnny Storm, Fantastic Four |
Closed? (Score:1)
by EEEthan (emh26@columbia.edu) on Sunday December 26, @02:59PM EST (#139)
(User Info) |
Ok, this might be a stupid question...why does the authentication program have to be closed-source? Wouldn't it be possible to keep all the code for authentication on the server side, and merely create a protocol which any client must implement? It seems to me that since we've gone open-source, any solution that's closed-source ultimately won't be feasible...we have to create code that's open source AND unhackable...perhaps it's impossible, but it's the ultimate goal. Of course, nothing can be totally unhackable... But what if an 'authentication client' was created...a client that connects and watches the logs and other players to make sure that everything tallies up as it should. It'd be separate code from the server, and could be applied when security is needed... Ultimately, however, it's up to the people who play and run servers. Server ops should watch their servers and kick+ban cheaters. And, ultimately...cheating has no point. It's not that fun to win if you do it every time. Cheating isn't a big issue if you play games with people you know and trust no to cheat. And for any kind of serious competition, people's clients can be examined...anyway, I've rambled on enough. I just hope someone will maintain the quake code and create some enhanced clients+servers that deal with this.
|
Do like nettrek (Score:0)
by Anonymous Coward on Sunday December 26, @03:04PM EST (#141)
|
The nettrek clients were available as source or 'blessed' binaries that contained a RSA checksum which the server verified. Then the server can confirm the client is one downloaded from ID as binary than a hacked cheat client compiled from source.
|
Conspiracy theory: (Score:1)
by webslacker (webmaster@webslacker.com) on Sunday December 26, @03:08PM EST (#143)
(User Info) http://www.webslacker.com
|
I knew it! This is all part of Carmack's evil master plan. He wants people to buy Quake3, so how do you wean players away from Quake1? Release the source code and let the Q1 community be destroyed by cheaters and unscrupulous hackers. Then when they get sick of being toyed around with by hacked servers, they'll come crawling to Quake3. I figured out John Carmack! He's up to something sneaky, that John! Boycott Quake3!
|
Ask Bruce Schneier for comments, please! (Score:0)
by Anonymous Coward on Sunday December 26, @03:24PM EST (#152)
|
| As John Carmack said, " It would also be a good idea to find some crypto hackers to review proposed proxy communication strategies." And the proposed security-by-obscurity strategies. This would also be an excellent opportunity to head off another rash of dumb patents. If Bruce -- being practiced in the relevant arts -- would comment on what is obvious to him, both re the immediate problem, and re CPU/architectural HW support to bullet proof this general kind of thing.
|
Some more depth (Score:5, Informative)
by John Carmack on Sunday December 26, @03:24PM EST (#153)
(User Info) |
First, the Quake architecture of (reletively) dumb clients conencted to an authoritative server prevents the egregious cheating possible in some games ("I say you are dead now!", "I say I have infinite ammo!").
For the most part, a cheating client can't make their character do anything that couldn't happen as a result of normal game interaction.
The cheating clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully.
The "more information" part can take a number of forms. A reletively harmless one is adding timers for items and powerups. Good players will track a lot of that in their heads, but a simple program can "remind" players of it.
Media cheating provides more information. Changing all the other player skins to bright white and removing all the shadows from a level give players an advantage not within the spirit of the game. Some would say cranking your screen brightness and gamma way up is one step on that path.
More advanced clients can make available information that is not normally visible at all. The server sends over all of the entities in the potentially visible set, because the client can move around a fair amount between updates. This means that the client is often aware of the locations of players that are around corners. A proxy can display this information in a "scanner window". The server could be changed to only send over clients actually visible, but that would result in lots of players blinking in and out as you move around or turn rapidly.
The worst cheats are the aim bots. In addition to providing more information, they override the player's commands to aim and fire with very high accuracy. The player usually "drives" around the level, and the program aims and shoots for them. This is usually extremely devestating and does ruin the game for most people.
There are many possible countermeasures.
There are server-side countermeasures that look for sequences of moves that are likely to be bot-generated and not human-generated, but that is an arms race that will end with skilled human players eventually getting identified as subtle bots.
Media cheats can be protected by various checksums, as we do in Q3 with the sv_pure option. This is only effective if the network protocol is not compromised, because otherwise a proxy can tell the client that it's hacked media are actually ok.
If the network protocol is not known, then the extra-information cheats generally can't happen unless you can hack the client source.
Q3 performs various bits of encryption on the network protocol, but that is only relying on security through obscurity, and a sufficiently patient person with a disassembler can eventually backtrack what is happening. If only they would find something more usefull to spend their time on...
With an open source client, the network communication protocol is right there in the open, so any encryption would be futile.
Any attempt at having the client verify itself isn't going to work out, because a cheating client can just always tell you what you want to hear. People have mentioned nettreck several times, but I don't see how a completelty open source program can keep someone from just reporting what it is supposed to for a while (perhapse using a "real" copy to generate whatever digests are asked for), then switching to new methods. Anyone care to elaborate?
I think a reasonable plan is to modify QW so that to play in "competition mode", it would have to be launched by a separate closed-source program that does all sorts of encryption and verification of the environment. If it just verifies the client, it would prevent the trivial modified client scanners and aim bots. It could verify the media data to prevent media information cheating. To prevent proxy information cheating and aim bots, it would have to encrypt the entire data stream, not just the connection process. That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends.
In the end, it is just a matter of making it more difficult for the cheaters. If all it takes is editing and recompiling a file, lots of people will cheat. This is indeed a disadvantage of open source games. If they have to grovel over huge network dumps and disassemblies to hack a protocol, a smaller number of cheats will be available.
Even if the programs were completely guaranteed secure (I havem't been convinced that is possible even in theory), an aim bot could be implemented at the device driver level.
It would be a lot more work, but a program could be implemented that intercepts the video driver, the mouse driver, and the keyboard driver, and does bot calculations completely from that.
Kind of sucks, doesn't it?
John Carmack
|
| |
Re:Some more depth (Score:1)
by miracle69 (devnull@procyon.com) on Sunday December 26, @04:20PM EST (#214)
(User Info) |
As this thread has definitely stirred some controversy, perhaps we need to back up and look at it from another angle.
When you release the source to the software, there are things that you expect people to do with it - improve its function, improve its speed, add/remove features that they want. However, there is also the other side - the side which we love and hate - and that is that people will do things to it that were never intended or never imagined. This can be a good thing, or a bad thing, but it is perhaps the most amazing thing about Open Source, because we can be so creative at times.
Now, when Quake was opensourced, all sorts of people stated how this was a good way for novice programmers to investigate an learn about complex programs using neato utilities like OpenGL. And this was all considered good.
Of course, others have taken the code and done things that weren't particularly liked - but not because of what was done code wise - but rather on the effect it had on games. But, who is to say that programming better AI isn't as noble or inventive as figuring out how to improve 3D effects?
And lets face it, people want to encode bots - for whatever reasons - and they want to run them. This is both good and bad. If bots are allowed into games to play humans, who EXPECT to play other humans, well, the result is predictable. The game is ruined.
But, what if there was a way to set up valid bot servers, and valid human servers - such that a human would never play a bot unless he wanted to? This can only be a good thing - for the game would still be just that - a game - and the AI programmers would have a chance to test their AI out against other AI programs, or even other humans.
That all being said, I have no idea how to improve security, but I think it can be done because Open Source allows for such an improvement to happen.
Microsoft and McDonalds are alike. They don't make the best, but they make the most. |
Re:Some more depth (Score:2, Informative)
by Nite_Hawk on Sunday December 26, @04:32PM EST (#223)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
The auto-aiming thing does indeed seem to be a problem. I wonder if it would be possible in some way to "confuse" such programs by limiting the information they have available to make decisions. You mentioned changing it so that you couldn't see players around corners. Perhaps in addition to this, something could be implemented so that you have a system of probabilities. It would be hard, and probably rather cumbersome to implement. Though if you could, in some reasonable way, limit the client to "there is a 50% chance that another player exists in the shadows straight ahead of you." the auto-aiming program would be forced to choose targets of highest probability. If you could also implement shadow "cues" that appear to be models of people ahead of you, (like when you scare yourself into thinking that a chair in a dark room is really a monster or a burglar) it may be enough to make auto-aiming additions unintiutive, as they shoot targets that don't exist. Of course in a bright hallway, it doesn't really help all that much.
The other question would be how to render a polygon based model that has a 50% chance of existing. I suppose you could use transparency, though it would be questionable how accurate it would look. It would be nice to be able to remove or add other cues to tell someone if an object is there; the shadow and depth information, contrast to the background, etc.
Perhaps another way might be to have invisible "targets" scattered throughout the level. Essentially a target that no human player can see/hear, or with information that the human player knows to ignore, but that would draw fire from auto-clients that just use client position information to aim/shoot. Again, I'm not sure how feasable this is. If you have an opengl model with completely transparent textures, how much overhead would it add? could a model with only say 6 polygons be used with mayb dull green texture so as not to be obtrusive? Would it be easy for people to code in checks for the fake players into the auto-aiming clients?
Well, I don't know how feasible this all really is, as I'm mostly thinking in physical terms rather than polygons and models. I think limiting the useful information the client has available might be the way to go, if it can be done. Just something to think about perhaps.. Anyway, Thanks again for all the hard work John, it really is apreciated!
Nite_Hawk #e and #povray - efnet |
Re:Some more depth (Score:2, Interesting)
by ahchem on Sunday December 26, @04:55PM EST (#243)
(User Info) http://www.akabean.com/
|
It sounds like the probablity thing is just too complicated.
However, your idea of creating "fake targets" sounds very interesting. The server could just create some random invisible targets in different spots each time the map is run. To make it more useful the targets could be automatically placed in weird spots (like in the sky or on the ground) that a human player would be unlikely to aim for. Then when the bot hits the fake target a set number of times it would be automatically bounced from the server.
This sounds like a possible solution to at least the aiming bot problem.
|
If a human knows not to hit it.. (Score:1)
by Mr. Klaw (emergencybroadcast@yahoo.com) on Sunday December 26, @05:09PM EST (#252)
(User Info) http://www.bile.com
|
Then someone would find a way for the AI to not hit the target. The targets would then have to be ligit players. The only way to try and catch this would be to randomly send the client that a player has appeared infront of it, but this could be curcumvented by putting a delay on how soon the bot would shoot and if the fake player exists for too long it might get annoying to the human players.
-- "Well, Hello, Mr. Fancy-pants. I've got news for you pal, you ain't in control but two things right now, Jack and shit... Jack left town." |
Re:If a human knows not to hit it.. (Score:1)
by Nite_Hawk on Sunday December 26, @05:30PM EST (#270)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
You can make an AI do anything you want if you give it enough processing power, time, memeory, etc etc. The point would be to make it so hard to do so, and so computationally intensive that it would be irrelevant. If you could force the computer player to have to analyize visual information similar to how the human brain does so to determain wether or not it's "fake", the computation power to do so in realtime would be pretty intense. Now, if the client can simple say "this model is only 6 polygons, ignore it" then it's fairly easy. But if the client has to say, determain if a movement pattern that the faked player is moving in is random or human generated, then the problem becomes a bit more difficult. And if the player in question doesn't move, does that mean it's faked or could it still be real? does the AI want to take the chance that it could be a human siting still until it comes into range, and then blasts it's head off? Should it just shoot all players that are sitting still incase they are human?
Alternatively, it might try to do a texture analysis of some sort, though that could involve even more intensive computational power. Each texture on each polygon would have to be anylized to see if it qualifies as a "faked" client or not. What if 1 pixel was set for green while the rest are transparent? What if on the other side it's 20 pixels of green with 1 transparent? what if it's a random mix of transparent and different shades of green?
Once you start adding variables to the equation, pattern recognition, especially in realtime, becomes pretty intense, and if the client is trying to play the game on top of it, things could get pretty nasty, which is the point. They may be able to make the AI crack your scheme and be able to determain if a player is faked or not, but if the faked player is done well, it will add so much overhead that it won't be worth doing.
Nite_Hawk #e and #povray - efnet |
Re:If a human knows not to hit it.. (Score:1)
by umoto (shathaway at earthling.net) on Monday December 27, @01:09PM EST (#444)
(User Info) http://slashdot.org/comments.pl?sid=umoto
|
We're solving several problems at once! This may come close to solving the entire problem. Assuming the Quake protocol has already taken care of "impossible" movements and actions, we could just add the following to make bots more difficult to write.
1. All players, bullets/rockets, and some objects should be indistinguishable in the network protocol. Only a human should be able to recognize the difference between a player and a scurrying rat or a flame because the server sends the 3D mesh to the client using a randomized ID.
2. The objects should be so numerous that a bot would be useless.
3. The server should not reveal the location of objects that are not within the user's field of view. This takes a little more processing by the server but also reduces network traffic, making the first point more possible and eliminating "X-Ray" views.
4. Here's the fun part. We could have an "apparition" mode which causes objects to appear in random but impossible places, or make impossible movements. The human would be able to see the images of their opponent rushing around at 1000 MPH and would be able to dismiss it as an apparition, but a bot would get confused.
5. A variation of apparition mode: a decoy mode! Sometimes a player is all alone and the server knows it but the client does not. At those times, and at random intervals, bring in the image of an opponent that's moving in such a way that makes it extremely difficult for a human to shoot at, but possible for a bot to hit. If the player is impossibly good at shooting these apparitions (which don't actually do any damage to the player), boot the player out.
What do you think?
|
Re:Some more depth (Score:1)
by Augusto (augusto.sellhorn@_no._spa_._m_.ps.ge.com) on Sunday December 26, @05:12PM EST (#254)
(User Info) |
Would it be easy for people to code in checks for the fake players into the auto-aiming clients?
Yes. If you set up transparent targets, the proxy could check for transparency and not bother itself with it. Also, how about "human" players just shooting the fake targets by accident ? Will they get kicked out ? I don't think this scheme solves the problem.
Flame on ! - Johnny Storm, Fantastic Four |
Re:Some more depth (Score:1)
by Nite_Hawk on Sunday December 26, @05:40PM EST (#279)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
You wouldn't need for them to be kicked out at all. If a target gets hit, have it respawn in another place. You just keep enough of them floating around that the AI is shooting fairly often at the "wrong" targets wasting it's ammo and openning itself up to be shot by other players while it's shooting at fakes.
As for the texturing, you wouldn't need it to always be transparent. You could have differing textures, even ones that are generated server side at the start of each game. The human brain currently still is going to be better at pattern recognition than a desktop computer trying to do it in realtime while at the same time trying to play a game of quake. That's what we'd want to capitalize on. Granted, this means that the server would need to send that texture to the client, and that's a dead giveaway if no other textures are being sent. Though because certain teams seem to be able to have their own textures in some of the screenshots I've seen, perhaps it would be possible it hide them. Anyway, most solutions are going to have some problems atleast..
Nite_Hawk #e and #povray - efnet |
Random targets (Score:0)
by Anonymous Coward on Sunday December 26, @06:24PM EST (#298)
|
I like the idea of random targets. To make it work, you would need to make the clients unaware of which clients are visable. If any client identifying info is added, then an aiming bot could quite easily distinguish between the real ones and the fakes (insert breast joke here). A counter could be maintained on how many times the fake targets were hit. A large hit ratio would indicate that somebody was either very lucky (and should be spending more time at the roulete wheel in Vegas), or else using some sort of aiming bot. This information could be used in addition to a player voting system whereby the players can vote if they think a given player is a bot or not. Different degrees of punishment could then be implemented. The easy solution would be to simply kick players off the server. However, I think that a more lenient policy would be better. Guilty players could be reduced to using only certain weapons, take a health penalty of some kind, lose there frags, be forced to listen to Britany Spears, etc... Bot users would likely move to another server were they can rack up there 50 frags in 2 minutes. So too would those that may have been wrongfuly accused, however, if they really were innocent (and as stubborn as I tend to be while playing), then I think that they would stick around to clear there name.
|
Re:Random targets (Score:1)
by Nite_Hawk on Sunday December 26, @06:43PM EST (#305)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
I'm wondering if we would need any form of punishment at all. If the aiming bot is hitting a fake target 75% of the time, they'll run out of ammo pretty quickly, and also be pretty susceptable to other people hitting them. not only would other people be able to easily spot them, but they'd also be able to hear their gun go off all the time and essentially "track" them without cheating. you'd know to run away if you were low on health. ;) People would also easily know who was cheating and team up on em too. :)
it'd be kinda funny if you had them respawn in close quarter areas, so that if they use a rocket launcher they blow themselves up. ;)
Nite_Hawk #e and #povray - efnet |
Re:Random targets (Score:0)
by Anonymous Coward on Monday December 27, @01:35AM EST (#389)
|
There is one major problem with this method I can see. If you have "random" targets spawning inside of the map space, it will be quite easy to hit them accidentally in a suprising number of situations. Most areas in Quake are very small, and cramped, with low ceilings. Also, some of the weapons in Quake have a radius of splash damage. So two people madly duking it out in a little room with two rocket launchers are bound to continuosly hit random, invisible targets.
And like Carmack said, any modification made along these lines will end up in modifications on the part of cheaters, and so on and so on in the Aim Bot Cold War. Also, how can you randomly spawn items inside of a Quake map? I don't think there is any way to tell if an item is inside of the binary partitioned space, or outside, unless there is the help of some seperate file (such as the bot aas files in Q3), or on the part of the map maker (by placing spawn points in a map). What I mean is, if an entity is there, Quake can tell you if it is inside or outside of the map DURING COMPILE TIME (of the map). But it can't just spawn items with random coordinates and guarantee they are inside of the map, especially after the map has been compiled. If you look at the maximum space extents, versus the actual space of the world that is inside of the map, the vast majority is outside of the map. This will lead in a lot of trial and error (mostly error) guessing on the part of the random target spawning algorithm. You can't calculate vis every time you want to generate another random target, unless you want to get .001 fps. I don't feel like registering, so my ID is: Ben Barker
ben@benbarker.com Flame away, heh. I'm a windows user after all. But I go to Slashdot. That counts for something.
|
Re:Random targets (Score:1)
by Nite_Hawk on Monday December 27, @02:59AM EST (#398)
(User Info) http://www-users.itlabs.umn.edu/~nels1678
|
It really shouldn't matter all that much if people hit the targets, even accidently. The idea would be to draw the fire of the auto-aiming software so that they run out of ammo and make themselves well known to other people. That's why I don't think you'd need to have the server actually "do" anything to anyone that hits a target, just having the auto-aimer always shoot at those targets would be punishment enough to deter people from wanting to use them.
I'm not totally sure about the second case, as I'm not terribly familiar with quake's object placement methods. Arn't there certain locations that players always respawn? Would it be possible to use those locations, and then have these target bots just kind of float around aimlessly? as long as they are treated as "players" I think it should work..
Nite_Hawk #e and #povray - efnet |
Re:Random targets (Score:0)
by Anonymous Coward on Monday December 27, @04:54PM EST (#462)
|
along these lines... you could place a floating target behind a player --- a normal player would never see it, a bot would be spinning constantly to shoot it.... or possibly create an anti-bot... a godmode bot controlled by a server... have it follow the player with the most kills (what good's a bot if it's not winning)... um... just un-thought-out ideas to toss around... maybe a server sweep... it could place those random targets for a second, see who hits them, and go from there... or you could just play team fortress ;)
|
Re:Some more depth (Score:0)
by Anonymous Coward on Sunday December 26, @04:39PM EST (#228)
|
You don't need really gross hacks to prevent encrytion from affecting latency, because the server doesn't really need to know know NOW that the data was hacked. So its sufficient to sent the data off, encrypted using pregenerated pad material from a stream cypher, and in the background checksum it and sent the checksum off within a few seconds. The pad means the data cannot be read, and the checksum detects 'attack in depth'.
|
Re:OSS benefits far outweigh the disadvantages (Score:0)
by Anonymous Coward on Sunday December 26, @04:40PM EST (#229)
|
| Yes, people will create bastardized Q1 clients and terrorize unsuspecting Q1 DM's but all that is irrelevant compared to the larger benefit to OSS community that we have more quality game code to build from. Creating a closed-source proxy is a quick-and-dirty solution to a not-so-relevant problem. However solving the client-side cheating paradox purely in open source is a challenge and it's solution would surely be a milestone in the advancement secure networking. Personally I think the development of the Doom/Quake series will prove to have contributed more to modern computing than we yet realize, and releasing the code will be remembered as a Good Thing overall.
|
Or maybe some things just shouldn't be Open Source (Score:1)
by tc on Monday December 27, @05:18AM EST (#405)
(User Info) |
So, what you're saying it that it's fine to fuck up a perfectly good game, because in doing so you further the glorious Open Source movement? I guess that's a marginally defensible position (and is bound to attract lots of karma), but isn't it at least as reasonable to say "gee, y'know what, maybe there are some things that just shouldn't be Open Source".
Look at it this way: I've not seen any practical solutions proposed that don't ultimately rely on security through obscurity. Perhaps this is because of something fundamental about the problem that only permits such solutions. If this is the case, then you might as well have the most obscure obscurity you can lay your hands on. Which means closed source.
Incidentally, I really hope I'm wrong (I'm working on a network game myself and I'm bashing up against this very problem), and if anyone comes up with a solution that doesn't rely on security through obscurity then I'm sure there would be lots of us that would love to hear about it. Until then, it looks like closed source is the way to go.
|
Re:Some more depth (Score:0)
by Anonymous Coward on Sunday December 26, @05:14PM EST (#256)
|
this marks the end of qw for me, and i don't plan on pickining up any more ID products in the future if they just give the quakeworld bible out to the idiots. Fuck all of u gamers that thought it was fair .... a big hahahaha to u
|
Re:Some more depth (Score:1)
by D_B_COOPER (db_cooper@hotmail.com) on Monday December 27, @04:36PM EST (#461)
(User Info) |
yah well i am sorry to hear that the fun is just beginning Less cheating, better mods better preformance, in outherwords
TASTS GREAT !!!
LESS FILLING !!!!
sir it is your loss the best game made for the net is about to get MUCH BETTER.
D_B_COOPER
|
Re:Some more depth (Score:1)
by jallen02 on Sunday December 26, @06:37PM EST (#301)
(User Info) |
ScareME. heh. if anyone on gods green earth has nothing better to do than write a device driver level AIM bot I am scared.. :-) heh. Okay im scared.. Seriously however, Given a large enough group of people.. Someone somewhere is going to find a way to beat the system. It happens all of the time.. There are people who thrill from reviewing large network dumps of encrypted protocols.. There is nothing to stop it. I have a very simplistic view on a lot of things since I do not do a whole lot with Client/Server yet. But is it not possible to somehow monitor what all the client is doing? IE, The more health stuff etc? Ahh phooey I dont want to get flamed maybe I should go study the Quake server source >:P bleh ill post more later.
|
Re:Some more depth (Score:2)
by Hobbex (hobbex@fragzone.se) on Sunday December 26, @07:01PM EST (#314)
(User Info) |
Barring the device driver based hack, the situation you have with the networked game is much like a distributed computing situation. In fact, the network game could be considered to be just a large distributed computer for putting pixels on the right place on each player in the system's (game's) screen. Most of the distributed computing projects (distributed.net, seti@home etc) do suffer from the same problem of people cracking the protocol and lying to the coordinating servers about what is actually going on, and it does seem that most of them end up relying on closed protocols and source code to keep it from being a problem. Distributed.net seems to use the same tactic for spotting cheaters as I use on my local Quake server, ie "they are too good".
However, a lot of work does seem to have ben done, at least in theory, on making distributed computing truly secure, so it might provide a place to start. A quick search through Counterpane's list of crypto papers gave quite a number of hits on the subject. I doubt you could create a truely secure protocoll today (for speed reasons) but this is a problem that is only getting worse as time and technology advances...
-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.
- Huxley |
Athlon KxSec will make this solvable (Score:0)
by Anonymous Coward on Sunday December 26, @09:32PM EST (#346)
|
| The problem is how a server can know it is securely linked to a trusted client with particular properties. This boils down to the server being able to get trusted code executed at the client which is able to exchange secure messages back to the server, and bootstrapping trust from there. The key element of course is the KxSec chip itself. The new vertical gate technology you've heard about (~10 x current density) permits huge on-chip cache, and this chip will have two, one of which will be dedicated to holding trusted code. The trust comes from the fact that the only way the code can be loaded is through an added on-chip special execution unit which has built-in capability to take an encrypted memory image and decrypt it and store it only in the secure cache. The encrypted image in our case is encrypted by the server using the KxSec's public key. Each chip is manufactured with a unique key pair, with the private half permanently hidden, even to debuggers etc. The chip executes the decryption/load operation in parallel with normal chip functions, something like floating point going on in parallel, only a lot lengthier. It takes a kernel mode special instruction to kick off the load sequence, and similarly to kick off execution starting at a location in secure cache, but the execution is done by the special unit, providing in effect an added CPU mode which is the only execution mode allowing data storage into the secure cache area. So, if we have loaded the right secure code, it can, e.g., compute checksums etc., and prepare an encrypted message securely in the cache for transmission back to the server. But what if the poor chip is being used by a hacked OSS OS? Well, the secure code will transfer its encrypted message to insecure memory and call on OS network functions to send it to the server. It will either arrive or not, but if it arrives, it can be trusted if it can be decrypted, (and if it is known that the public key really belonged to a KxSec chip, which can be determined via public data base). Privacy issues similar to the P3 PSN may be relevant. Comments? The anticipation is that new BIOSs will use this feature starting with the boot block, and that OS loading, and driver loading will all eventually be securely controlled to allow guarantee of what is executing in the system (e.g., so a Quake server can verify that a "blessed" video driver is installed). Secure random audits could be well supported this way too. Certainly Open Source, compiled and signed, with signatures for all desired modules, will help, not hinder, the goal of security. Eventually perhaps most significant devices in a system will have on their controller chips a secure execution core of this type, to allow secure aggregation into larger trusted systems, where in truly paranoid cases all links will be treated as untrusted and requiring secure comm protocols. When is this due to be fabbed and sampled? Suspicion is it is tied up trying to shake patent parasites at the moment. So, it is hoped this little hoax will help fight them off with disclosure of the obvious into the public domain ;-) Athlon is a trademark of AMD, and AMD has not authorized this post.
|
Re:Athlon KxSec will make this solvable (Score:0)
by Anonymous Coward on Sunday December 26, @09:56PM EST (#349)
|
Shit. How we gonna hack MP3 type stuff if they make digital speakers with a stripped down KxSec with D/A on the same chip? Let's patent this and not let anybody use it.
|
Re:Athlon KxSec will make this solvable (Score:1)
by Python (python@freedom.gmsociety.org.NOSPAM-BADSPAM) on Monday December 27, @02:02AM EST (#394)
(User Info) http://freedom.gmsociety.org
|
Are there any white papers out on this? I'd love to read some more on the implementation before I comment. Feel free to e-mail me anonymously (thru a remailer, there is one on at the URL above) if you can't post anything publicly. :-)
--
Python
"Linux, the last service pack you'll ever need." |
Re:Athlon KxSec will make this solvable (Score:0)
by Anonymous Coward on Monday December 27, @04:01PM EST (#460)
|
| Sorry, I can't point you to anything, and I'll have to let you decide how real the "KxSec" project is. There are of course all kinds of papers on the web on secure distributed computing etc. Let's assume something pretty bullet proof can eventually be built with something like "KxSec" hardware and appropriate mods to GNU/Linux etc. - What can we do to make sure we (free software community) aren't legally fenced out of the action? (How much fencing is already up?)
- What can be done to preserve freedom to implement open versions of practically unhackable commercial formats for electronic distribution (of music, video, etc.)?
- Will this bring back software protection with a vengeance? Seems like it would fit in well with the commercial electronic distribution that will probably be mainstream soon.
- How can this kind of infrastructure be used to enhance privacy?
The broad concepts of the "KxSec" are pretty obvious, so I think we can assume there's going to be a real one at some point, whether there's some disinformation in my description or not. I believe we will have to deal with these issues soon, and my hope was to get some useful (or at least interesting or entertaining) discussion started. Of course, this post is pretty far down-river by now ;-/
|
Re:Some more depth (Score:1)
by Unbeliever (unbelver@us.netrek.org) on Sunday December 26, @11:19PM EST (#362)
(User Info) |
Any attempt at having the client verify itself isn't going to work out, because a cheating client can just always tell you what you want to hear. People have mentioned nettreck several times, but I don't see how a completelty open source program can keep someone from just reporting what it is supposed to for a while (perhapse using a "real" copy to generate whatever digests are asked for), then switching to new methods. Anyone care to elaborate? The client verification code isn't part of the standard source tree. That is relatively tightly controlled for ITAR and copyright reasons. That part is only given to established client developers and Server Gods. We have to trust that they don't pass it around. The authentification is an RSA public/private key pair. Client reports: "I'm such and such client" Server looks up the client's public key, encrypts something random, sends it back to the client to decrypt it and send it back. I believe. I need to re-read the source again. Of course it is spoofable to a determined cheater. See my other comment for more info. ("Comment from the current netreky keys maintaner") Or I can mail you directly if that's ok. Mail me at: unbelver@us.netrek.org
--Carlos V.
|
Re:Some more depth (Score:1)
by Kymermosst on Sunday December 26, @11:23PM EST (#363)
(User Info) |
I think a reasonable plan is to modify QW so that to play in "competition mode", it would have to be launched by a separate closed-source program that does all sorts of encryption and verification of the environment. If it just verifies the client, it would prevent the trivial modified client scanners and aim bots. It could verify the media data to prevent media information cheating. To prevent proxy information cheating and aim bots, it would have to encrypt the entire data stream, not just the connection process. That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends. Okay, so there is race condition between the time that the verification program finishes verifying, and the launching of the new executable. Under unix-like OSes, two copies of an entire directory tree could be kept, and a symlink switched to the cheating copy during the instant between the verifying program and the launch of the actual game, thus causing the verification program to launch the wrong one. A new filesystem could also be mounted over the original directory, or any number of other clever race-condition exploits. Of course, this can be worked around, but such a closed-source verification program would have to be *very* carefully designed to avoid pitfalls such as this. A method such as... say, forking and execing the potential game executable _before_ verification, and immediately sending the process a SIGSTOP, then if it checks out, go ahead and send a SIGCONT to continue execution, if not, send SIGKILL and quit. Also, not following symbolic links during verification, and not following symbolic links to get to the executable. Further, checking to make sure that the path of the executable and media hasn't changed, or that it is not on a different filesystem from the one it was just on. The problem is, the closed-source executable would not be subject to the peer review that open-source software is, and must either be *very* well thought-out, or must implement M$-style security through obscurity. It's easy to say to do something, it's a lot harder to do it.
People are stupid, and will believe anything they fear is true or think might be true. |
Distributed chess solvers (Score:1)
by jab (jeff@jab.org) on Monday December 27, @01:24AM EST (#387)
(User Info) http://www.jab.org
|
| Back in the Kasperov vs Deep Blue days, I was thinking about how the next round would go (assuming Kasparov won and there would be rematch) The idea was to have thousands of computers around the internet work together to compute chess moves, which really boils down to searching a huge tree (of possible board positions) for the best possible position (according to a static board evalutator) assuming optimal play y your opponent (again, using the static board evaluator). This is the famous minimax algorithm which I am sure you are familiar with. (Most of modern chess engines are about pruning the tree down a bit (alpha/beta pruning) and increasing brute force, thorugh specialized chess hardware. The trick in making sure clients are trustworthy is to have them calculate results that are easily verified. For example, if a client reports that a move gives a particularly favorable position (so favorable that it beats all other client's suggestions), then it can be rechecked by the trusted server for correctness. It's fun, easy, and doesn't even require messing around with trusted hardware (i.e. the AMD post above) or trusted executables embedded with an obfuscated private key (a.k.a the netrek solution outlined by the nettrek keymeister above.) But how does this work for quake? My chess example is all about hunting for an optimal solution that can be easily checked once found. Quite frankly, I can't think of any way of phrasing Quake 1 client functionality as a similar task. So, lets talk about another, hypothetical game, which we'll call, um, how about "Quake 4." In Q4, computer assistance (targeting, dodging, whatever) is built in to the client. Even better, multiple computers may team up to collaborate on a superbot. (The "AI" would have to be moved from a bunch of heuristics (I assume) to something more resembling minimax. These superbots could either fight other superbots, or perhaps the Kasparov's of the Quake 4 world running manually. Now, before you object that this doesn't sound very fun (having the computer do all the work) imagine if serious swordplay was introduced. The AI assisted parrying and blocking could end up similar to the sword fighting scenes in Princess Bride, with far more entertaining results than might be accomplished by humans banging away on their keyboards or mousbuttons trying to control every thrust. The more sophisticated and subtle player actions can get, the more difficult they will be able to control without AI assistance, and there are some great games to be made in the future. And yes, I'm still pissed that Kasparov lost to Deep Blue, foiling a great opportunity for a collaborative computing rematch.
|
Re:Some more depth (Score:0)
by Anonymous Coward on Monday December 27, @02:28AM EST (#395)
|
I've often thought about the "fake targets" idea. However, if there is anything that could indicate to the human player that a target is not real, then there must be some bit of data that the bot can also use to discern the reality of the target and be made to avoid those so that it doesn't "give itself away". If a "fake" target was placed behind a suspected cheater, and that player always seems to "know" that there is someone behind him, then that could be a giveaway for a scanner bot (like the radar function of Zbot). Perhaps mouse movement could be tracked, and players making large yet precise aim changes that are always accurate could be revealed to be bots. But good players (and sometimes bad ones when they are lucky) can do that sometimes. There would have to be some sort of statistical threshold where it is decided that no "real" person would be that accurate that often. But then bots could be "toned" down to be more subtle, and it becomes an "arms race" like Carmack mentioned above.
|
Brute Force Solution? (Score:1)
by Mortigalli on Monday December 27, @05:42AM EST (#407)
(User Info) |
How about the server, doing a check to see if the client responds with a appropriate action. Say a user gets hit with a server created rocket at a known percentage loss, then the client has to admit to the right percentage. Plus if the user normally would be killed, but isn't acting as it ought, then a immediate kick/ban?
|
The facts about what can and can't be done. (Score:2)
by WNight (wnight@rocketmail.com) on Monday December 27, @06:10AM EST (#409)
(User Info) |
Heh, I was suprised to read a post by someone who actually understood that you need two trusted parties for encryption to work, and who understood the Quake client/server model and it's strengths/limitations... Then I read the name...
The 'unfortunate' truth is that there is nothing which runs on your computer which you can't subvert with some work. As long as the computer is an open platform, which you can debug programs on, and monitor device traffic on, this will be the case. There is NO way around this. Anything the program can run for authentication, the hacker can rip apart to spoof said authentication.
Both game models, peer-to-peer and client-server are vulnerable to this, in their own ways.
The problem is that you can't control what the client does. If it returns the same information, you don't know what program is running.
There is no cryptographic was around this. For crypto to be used to communicate between two parties, you have to trust both. If I send you a private encrypted message, I can make sure it can't be decrypted without the key (or cracking, which we'll assume is impossible in the scope of the problem.) but once you have that message, you can share it with the world and I can't stop you.
Likewise, with digital signatures, I can be sure you sent me the information that appears to be from you, but that doesn't tell me if you're telling the truth or lying.
Anything added onto this is security by obscurity (which, is possible in open source code, simply see the OCCC for proof...) If the source code is available, it's a bit easier, but that doesn't mean binaries are secure. Anything that happens on my computer is ultimately subject to my control.
So, what can be done?
Nothing really. Servers can check for unlikely shots and moves, but as JC notes, this ends up eventually kicking off Threshes as bots, and allowing any bots set to perform well but still below the cutoff.
There are some tricks, such as invisible targets that are labelled players, but that the humans don't see, this will stop bots, until someone analyzes stored network code from before they got detected as a bot, sees this invisible target, and codes the bot to ignore invisible targets. One generation of bots stopped, no net gain.
The only way to stop cheaters is to ship computers as black-boxes, that run a restricted OS, don't allow OS-level code, for debuggers and such, and that have private keys and serial numbers embedded, and are encassed in tamper-resistant materials. But, if we liked that sort of computer, we'd be using an N64...
Half measures, such as dongles, have been suggested, but are simply more obscurity. Any half-measure *will* fail.
So, are we doomed? Are good network games something we'll never have?
Nope.
I downloaded a ZBot, as did most people I know. Certainly any quake-playing programming person I know downloaded one. But I don't play with it. I don't even keep it installed. Why? Because it's not fun. A few wankers find distupting games to be fun, but if we simply vote to kick them and continue, they will eventually go away, simply because bugging people for fun relies on people being bugged.
We have to put up with these people if we want the freedom of open computers, in the same way we have to put up with street mimes in a free society. But, if you just ignore them, they will go away.
I should mention that bots exist in games like Quake because there are some actions that require little mental skill.
Shooting a railgun is trivial. A monkey could be trained to do it, if they had a fast computer and a nice video card. This is why bots are usually used with the railgun. It's a no-brainer. You don't often see bots use weapons like rockets, or grenaes, especially across an open area, because those are least effective when fired at the current player location. To work, they need to be fired either where the player is going to be, or where you don't want the player, to herd them. Bots can't do this.
If we want to get rid of bots, we'd be 90% of the way there if we'd remove the no-brainer weapons.
|
Re:The facts about what can and can't be done. (Score:1)
by Seth Golub (seth@aigeek.com) on Monday December 27, @02:07PM EST (#450)
(User Info) http://www.aigeek.com/
|
To work, they need to be fired either where the player is going to be, or where you don't want the player, to herd them. Bots can't do this. Sure they can. It's just more complicated. The Visual Dynamics Research Group at Oxford has some really cool demos that show the results of using probabilistic prediction techniques to improve image-based tracking. Using the same techniques to track something whose past and present location is known precisely (rather than being inferred from noisy observations) is much easier. As you yourself already said, you just teach the bot about whatever kinds of movements you want it to be able to handle. Once you have lots of common models in there, you can tune its expectations by having it learn during real games.
|
Re:The facts about what can and can't be done. (Score:2)
by WNight (wnight@rocketmail.com) on Monday December 27, @03:11PM EST (#458)
(User Info) |
Sure they can. It's just more complicated.
Got me there. I meant "Can't [easily] ..." but was lazy.
As you yourself already said, [include link...]
Hey, no fair actually reading what I write to make me stay consistent... :)
I mean, bots can't plug in a simple mathematical formula and cope with it. Herding a player involves knowing where you don't want that player to be, and knowing the area well enough to know where you do want them to be, and the choke points involved in cutting them off.
Theoretically a bot could figure this out on the fly, but more likely, for a few years at any rate, it'll simply launch rockets at the 'protected' item and dare you to get too close, instead of defending it in a clever and dynamic way.
So, I stand by the "bots can't" part of my post in all but the most theoretical ways...
|
Re:Some more depth (Score:1)
by matso on Monday December 27, @05:44PM EST (#464)
(User Info) |
| That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends. Split the program into two parts; a loader and a .dll for the client. The standard (open source) loader just loads the dll, hooks up the i/o streams and lets the client run. Enforcing loaders would be closed source and CRC the client .dll and handle encryption/decryption of the i/o stream. As the encryption/decryption is in the same process as the client, there wouldn't be any context switching problems. Extending it a bit further, the client part would not be allowed to load any data directly from a file on the host, instead doing it through the loader which can CRC the loaded data to verify that it hasn't been tampered with. Now, what happens is of course that you move the interest of crackers from the client to the loader - if it's cracked then you can do anything you want. A further improvement would be to download the loader from the server every time you connected to it. The server would periodically (every few minutes or maybe even for every connection) generate new loaders through some server-specific algorithm, meaning that it wouldn't be enough to crack one loader, but instead you would have to crack the algorithm used by the server to generate the loader, as well as cracking the individual loader. Also, as soon as a server suspects that its algorithm is weak, it can be changed. The size of the resulting security hole - basically you are letting the servergod control your computer - means that it isn't a practical solution - unless, of course, you write the loader in Java. With Java1.2 security, it should be possible to setup the security parameters allowing you to safely let the loader load the .dll files and necessary data files. Also, using this technique, the loader interface would be open-source, and it might be possible to open-source the loader implementation template/loader generator as well, if the generated instances is sufficiently hard to crack.
|
Quake 3 Inspiration (Score:1)
by Sludge (sludge@SPAMREMOVE.atdot.org) on Tuesday December 28, @02:38AM EST (#472)
(User Info) |
After talking with Zoid about hypothetical ways to crack Quake 3's CD Key, and me coming up blank other than cracking the Quake server which turned out to be unacceptable ( I had already purchased the game before any of this talk went on in private ), I was quite impressed with the "server's server" verification:
The Quake 3 server sends the CD key verification to the Master server along with it's heartbeat.
Would it not be possible for Quake 3 to also do a CRC check on it's own binary, send that with the CD key info, for requirement of validation?
While this would require a small deviation from cross platformism, a list of valid CRCs would be on ID's server of servers.
In order to stop proxies, the closed source binary would encrypt the data of a port on the localhost being sent to the server. The server would decrypt this, and establish a new connection (or connections for both UDP and TCP) on the localhost.
Essentially, the server would connect to the client.
I'm still only 25 pages into Richard Steven's TCP/IP Illustrated, so if this sounds a bit naive, know that it is the product of my fascination with abstraction and my good will. :)
Um, after reading over the above, would it be possible with winsock or BSD sockets API implementation to have a program open every socket from 1024 to 32768, and then wait on them all? (All of Quake 3's potential resocket ports.) Also, you'd have to beat the proxy to bind(), which would be just another chapter in the bot cold war.
Note that Quake one users could be prevented from cheating by implementing what I mentioned for Quake 3. At least in my head.
Michael Labbe (not the pedophile) |
Re:Some more depth (Score:0)
by Anonymous Coward on Tuesday December 28, @02:42AM EST (#473)
|
>Kind of sucks, doesn't it?
Frankly -- no, I don't think it does. Probably this is just because I'm a freak, and don't really find playing games to be that fun (sure, I play a round of quake now and again, but really, I'd usually rather be reading a good book). What really fascinated me about quake, though, was the possibility of writing a bot to do it -- motion prediction, route finding, strategizing, optimizing all of these -- all of these are very hard and very interesting problems. I'm talking about an autonomous bot here, of course, not one of those proxy bots that help you cheat -- those are pretty lame (though could still be interesting to code).
This kind of project is cool in ways that you don't see very often. It mixes some very interesting AI related problems with the fact that when you're done, your creation is a person running around trying to kill you. All together, a much cooler hack than yet another IRC client.
This is why I always feel a pang in my stomach when I see posts like yours -- because people are trying to take away this most awesome of toys. Of course, I know that the hordes of gamers out there probably are (and should be) the focus of your company, but I just feel like someone should point out this other side...
-- Nathaniel
njs at uclink4.berkeley.edu
|
Re:Some more depth (Score:0)
by Anonymous Coward on Wednesday December 29, @01:21PM EST (#480)
|
BTW i just aint had time to create an account :) I agree totally with what has been said and have been on the end of certain players gaining help. Im a Kingpin player myself, but the same cheats are still being used, one person, who i wont name but probably should be reported somewhere, sent his config files to a fried of mine due to a problem with his kingpin setup, we found what looked like aiming bot references and auto circle strafing.These are againt the ideas and fair rules of the game, BUT it is not the biggest problem with online gaming at present that must go to "We cant win unless we have more players" type people who seem to have grown in number, these people ruin the fair play element and make it boring and unfair to normal gamers. They moan when the teams are unbalanced against themselves constantly but as soon as they have the advatage its a case of "shut up moaning, loser" etc This is something that cannot be overruled by server side codes etc, just common sense So all of you now who is reading this that is part of the unfair side of things, grow up and play fair! To all of you who switch when needed etc, keep it up and realise that your the better man/woman/gamer in the ed, cuz u dont need to cheat to play and on occasion win :) SBM Aka [69]Red Devil
|
trusting the user (Score:1)
by moore (moore@eds.org) on Sunday December 26, @03:29PM EST (#156)
(User Info) http://warez.slashdot.org
|
Carmac is right about the fact that a cheet
free systome is imposable. That is with respect to
avalable computing resources. even if you off load
all of the accounting to the server there is still the posibality to hack you GL driver so that it dosent render walles so that you can see who is on the othere side. this hack is even out side the game so you can't fix it with a closed game. the only way to fix this would to have the server to the rendering which is not feasable with todays resourses.
What I think you could do in stead is require users to get a CERT in a way that would make it hardish to get one with a false identity. you could then not wory about trusting the clyent you just have to trust the user if there is suspected cheeting then it can be investagetated and with the positive result being revocation of the CERT. This is of corse just moving the problime else where but I think that there are easer solutions in this relm. No I don't think the useing CERTs will solve the problime compleatly but I do think it will offer more effective sloution then through the use of just software.
|
GPL/Open Source in general, is flawed (Score:0)
by Anonymous Coward on Sunday December 26, @03:38PM EST (#165)
|
This is simply more proof that some things are mean't to be kept secret. Lets say the source was never released...first off, boom, no more major cheating problem but then of course boohoohoo, you aspiring script kiddies can't learn how ID made quake. SO WHAT? It is my belief that not having access to the source will simply get kiddies off their lazy asses and figure code out for themselves instead of wasting countless hours attempting to make sense of other peoples work. In short, in 99 % of cases, OSS is totally inappropriate and in fact ruins other innocent consumers software (cheaters/crackers make sure of this).
|
Missing the point - the truth of cheating in Quake (Score:1)
by Chris Pimlott on Sunday December 26, @03:43PM EST (#171)
(User Info) |
(This is not a troll)
Unfortunately, reading the comments, it is painfully clear that most of the posters are not truly familar with the history of cheating in Quake. The problem lies not with the client sending bad information to the server but the client doing things that don't involve the server at all.
I.E., here is what most people seem to think is happening:
client: I have 200 health
server: Okay! Whatever you say!
client: I just got quad
server: Super!
client: I just killed everyone
server: Alright! +7 frags
This isn't close to the truth. Here are how people have really cheated in Quakeworld -
1) Hacked models (aka Pak2)
Models can be editted on client side to be more visible and easier to see. The famous "pak2" example you hear about had player models with BIG bars along each axis. The result being you could see a guy behind a wall, or under your feet, or above you, etc before they could see you.
2) Hacked skins
Make the player skins fullbright textures so you can see everyone without a problem, negating dark areas on maps.
3) Hacked maps
Take the normal quake maps, then cut a bunch of a holes in it. Result - you can see people behind walls, through floors, in the water, etc.
These are not theoretical cheats, there are things that have been used successfully by cheats.
The solution that has been tried is to have the client report checksums of important data files and have the server verify that they're correct.
Now, with open source clients, it is a trivial matter to make your client report the correct values of the CRCs regardless of what the true values on the client are.
The point of the matter is all these cheats take place on the client level and don't effect in play data sent to the server. Therefore, they are undetectable. Now that the client is fully open source, the sky is literally the limit. Your client could tell you where everyone else is, what weapons they have, ammo, how much health, when the powerups respawn, etc. The possibilities are endless.
The point is, cheats of this kind don't taint the datastream. Therefore the only way of protecting against them are validating the client, which, with an open source system, is very difficult, if not impossible.
|
| |
Re:Missing the point - the truth of cheating in Qu (Score:1)
by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:55AM EST (#383)
(User Info) |
This post should be marked up as informative. I mostly played team fortress not dm so maybe I just don't get it, but I don't agree that the sky is the limit. Or I should say I don't believe it because I don't know. Does the server send the full state of the current level to a client? I thought that in some version of qw, in the interest of saving bandwidth, the server only sent information that was pertinent to the client. basically just what the client could display at that point in the game.
|
Haven't all the ways of cheating in Q been around? (Score:1)
by idealego on Sunday December 26, @03:44PM EST (#172)
(User Info) |
There are only a few ways to cheat in Quake since it's a client server game. Assuming the server isn't running hacked code.
I *thought* all the ways of cheating in Quake have already been used and abused for years so I'm a little confused here. Exactly what new ways are people able to cheat with now just because the code has been released? I can see cheating being easier but proxy bots and and all that stuff have been around for a long time so I don't see any of this as being new. Someone please enlighten me.
-idealego
|
Problem with OSS security (Score:0)
by Anonymous Coward on Sunday December 26, @03:45PM EST (#173)
|
Well this raises an interesting point. With OSS how can we trust the security of _any_ program? I mean, we cannot use ssh on anyone's box, because it might be modified. We can only trust our own version on our own box. The closed software (binary only) may have an advantage here... we could compare checksums of the binaries to an accepted distribution.
|
Remember BSD rsh? xhost? (Score:2)
by Alex Belits (abelits@phobos.illtel.denver.co.us) on Sunday December 26, @03:45PM EST (#174)
(User Info) http://phobos.illtel.denver.co.us
|
They were adequate in trusted environment, and were replaced with ssh after the Internet became a bit less "trusted". The same thing will happen to game protocols -- they will be replaced with versions that will keep "world" integrity even if clients are hostile. And since this still allows cheating by giving player more information than he normally would have (for example, by making things transparent), more advanced future servers would have to limit the amount of information, every client receives from the server to only things that player will be able to see -- but this will benefit the game as a whole because it reduces the lag and amount of calculations in the clients' 3d engines. The kinds of "cheating" that will always remain possible will thus become limited to client-side "automation" (scripts that determine parts of character's behavior, information keepers,...), however those things can be legitimized -- they require skills and creativity to be used, so the advantage won't be "unfair".
|
We solved this with Netrek years ago... (Score:1)
by sheldon (sheldon@yuck.net) on Sunday December 26, @03:49PM EST (#176)
(User Info) http://www.sheldon.visi.com
|
Well go figure, Quake comes out and tries to do the same thing as Netrek started doing over 10 years ago, and they run into the same problems.
I don't recall if it was Andy McFadden, or Sam Shen who first implemented it, I think they were both involved to some degree. But Netrek uses RSA public key encryption to do a client verification.
Public keys of authorized clients are stored on the server. A client connects, uses it's private key to prove it's identity and away you go.
The only thing closed is the private key. This is held by the client maintainer, and is also embedded into the compiled binary in a obfuscated manner.
If a private key comes into question, it can be yanked off the server immediately, requiring people to obtain new clients for that platform, whatever.
I think the other problem is that Quake allows too much processing to be done at the client side. In Netrek everything is server based, so about the only thing a borg client can do is auto aim for you, etc. No different than a robot playing your position. You can't defy the netrek rules at any rate, by increasing power or controlling whether you got hit or not.
|
| |
You aint half cocky are ya :) (Score:0)
by Anonymous Coward on Sunday December 26, @06:34PM EST (#300)
|
"The only thing closed is the private key. This is held by the client maintainer, and is also embedded into the compiled binary in a obfuscated manner."
Break the obfuscation and the security is broken. And for a good determined cracker (in the original sense of the world, ie somoene who cracks software protection scheme's) thats not going to be very difficult IMO. I think netrek escapes massive cheating because it isnt popular enough to have an effective spreading of cheats and enough lamers to want them.
|
Re:You aint half cocky are ya :) (Score:1)
by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @12:26AM EST (#374)
(User Info) |
| But the obfuscation is different for each COMPILE. And if you find the key, you've broken only 1 key. IF we find out about it, that key is yanked, and within 12 hours, its useless.
--Carlos V.
|
I am cocky! (Score:1)
by sheldon (sheldon@yuck.net) on Monday December 27, @01:23AM EST (#386)
(User Info) http://www.sheldon.visi.com
|
It actually works quite well. It's difficult to pull the key out of the binary, because it's been obfuscated into the binary.
As Carlos pointed out in another message if the key is compromised, it's easy to yank the key, create a new one, and recompile the binaries.
And since the code is obfuscated per compilation, to find the key out would require the same amount of work each and every time... i.e. disassembly of the client. Sooner or later someone will give up.
Netrek isn't very popular these days, because of eye-candy games like quake. But at it's height back in the early 90's there were quite a few people who looked at the authentication mechanism and tried to break it... thus strengthening it.
|
He already wrote it... (Score:1)
by HobophobE on Sunday December 26, @03:54PM EST (#183)
(User Info) |
Carmack probably already wrote the proxy and is just waiting to release it. Seems logical enough, he could keep it closed source, its already probably done.
Nothing laughs forever. |
It's not cheating (Score:1)
by oki900 on Sunday December 26, @04:00PM EST (#188)
(User Info) |
Do you call it cheating if you re-write some of your kernel code to be optimised and allow you features other linux users dont hav? Didn't think so. It's winning by intelectual abbility and now who can get to the rocket launcher first. If you aren't smart enough to go in and fix your code then be dumb zombie walking around blasting without a brain, else get busy and fix up that code to make the game more fun for you.
|
| |
Re:It's not cheating (Score:1)
by Master of Kode Fu on Sunday December 26, @04:16PM EST (#207)
(User Info) |
| If we assume that it was intended for people to hack their clients in ways to give them an edge, then it's not cheating. I remember a story about a starship captain who hacked a "no-win scenario" simulation and got Starfleet Academy's top awards as a result. :-) The problem is that a good number of players out there either:
a) have no idea how to modify their Quake client b) have ability but lack the time c) have both the time and the ability, but think that it's either unfair or takes away the fun Perhaps there's a way to support both hacked and non-hacked clients. Maybe some servers could be for "pure" clients only (assuming we either trust the honor system or have some reasonable client-verification process) while others could be designated for hacked clients (or Jedi masters/masochists with "pure" clients). That way, the people with "pure" clients play on a reasonably level playing field, while Quake hackers can test both their fragging and hacking ability.
|
Deja Vu (Score:1)
by bafful (bafful@gmx.net) on Sunday December 26, @04:09PM EST (#200)
(User Info) http://www.geocities.com/SiliconValley/5270/
|
Hasn't this been discussed a million times in connection with the SETI@home client (see their FAQ)? I don't think a real solution has been found yet, but it's kind of the same problem as with Quake.
|
Comparisons to paper/board gaming (Score:1)
by Athos (.athos.at.cryogen.com.) on Sunday December 26, @04:12PM EST (#204)
(User Info) |
Paper/board/mail-based games also have an enormous potential for similar behaviour. The complete rules (source) are available openly (to the players at least), and it's possible to cheat in these situations (mis-read the dice anyone, "misunderstand" a rules situation, bring your own (altered) rulebook). While this happens, it doesn't seem as much of a problem in the gaming I'm involved in. (I help run a (non-comp) gaming convention here in Toronto and I've seen a lot of gaming. Of course, your mileage may vary and all the usual disclaimers.)
Why is this? I can think of several reasons. First and perhaps most importantly, cheaters generally end up without anyone to play with.
Second, 'cheats' can turn into 'house rules' and 'variants' and become a part of the game, and people playing agree to the variants in play. If someone abuses this, we get back to the first point.
Thinking about it a bit further, it's possible that mail/e-mail games may be a more appropriate parallel. The additonal abilities imparted in gaming clients (e.g. targetting etc) may be more akin to players in a game talking out of band, or additional tools being used to assist play. In this situation, such communication and tools are a hazard that must be borne. It's somewhat mitigated by playing through a single arbiter (server). You're playing by the server's rules -- at least as far as actual gameplay. With the arbiter actually running the game as ordered by the players, cheating is less of a problem.
The applicability of this to computer gaming (specifically Quake) is limited, unfortunately. As a thought, granularity with some margin of error may improve the targetting situation (I'm not much of a computer gamer, so I'm not as versed in it as I might be).
Looking at role playing, I can see some parallels here as well. While there is an arbiter (GM, whatever), it's still possible for players to fudge, lie, use aids they shouldn't be (woe betide any player caught with a DMG in my campaigns). In this situation, the arbiter offers some form of consistency of play (at least within the GM's sessions). If the players or the GM goes outside of agreed bounds too often, the isolationism effect I mentioned near the start comes into play.
I'm not sure there's a need for a closed-source solution to this, just some responsibility and communication among players. However, since I don't see much of a real 'community' of gamers being constructed (other than to sell the next game), the relationships need to build up the needed web of trust aren't there yet. Might be a good time to start.
--
The Internet is the Suppository of All Knowledge. You get it in the end. |
| |
Re:Comparisons to paper/board gaming (Score:0)
by Anonymous Coward on Sunday December 26, @05:12PM EST (#255)
|
Drug addicts (aka cheats) take no responsibility. All they have to say for themselves is, it's open source, it's there, what do you expect. It's open source, so it's not cheating. Yeah, sure!
|
Here's what to do: (Score:1)
by pwagle on Sunday December 26, @04:14PM EST (#206)
(User Info) |
| Keep open source. Sign binaries for publically available (in a secure location) source files. You think someone is cheating? Look at their source from the repository and see if you like it (and cross-breed it with your own source, and submit the offspring for signing). If you don't like it, vote with your companions to have it rejected from your server. [Some server-communities will like the cheat, and some won't.] This requires a sane voting system, and multiple servers with moderately attentive and responsive server gods (or good automation). Different servers should have the different policies and accept and reject lists. "Genetic diversity" will be important. Voting acceptance and rejection will promote evolutionary progress. Some forks will die off, and some won't. This way, cool cheats will make it into publically available source, while various mechanisms for rejecting stupid cheats can be explored by various server gods. This requires servers that can compile sources for all the supported platforms, in sandboxes that prevent people from exploiting the compile-and-cryptographically-sign-the-binaries server.
|
Why not just... (Score:0)
by Anonymous Coward on Sunday December 26, @04:20PM EST (#211)
|
Now, I'm no crypto genius, but why can't the server submit a challenge phrase to the client and have the client do some mojo and crate a hash using some info from the client? I don't have a clue as to how this would be implemented, but I'm thinking of something like SSL. Am I crazy or what?
|
Server side physics etc? (Score:0)
by Anonymous Coward on Sunday December 26, @04:53PM EST (#241)
|
I thought all of these calculations were done server side? Since they aren't... why can't they be? If all the client does is display the info it would be a lot harder to cheat. Maybe see through ways... but even that could be server side... Course this ups the demands on the server.
|
| |
it would be too much load on the server (Score:0)
by Anonymous Coward on Sunday December 26, @09:26PM EST (#344)
|
lets say each client uses 10% of its processing time for physics (maybe the rest is for polygons drawing/lighting, etc). lets say you have 35 clients. if u move all that calculation to a server, it will have to do 350% of the processing each frame that a normal client would do just for the physics. Your server would have 2 be pretty fast i think.
|
Encryption (Score:0)
by Anonymous Coward on Sunday December 26, @05:01PM EST (#245)
|
I'm not a big quake player, so I don't know if this will work, but...
What about the server having to sign each client with a private key, together with a random string. The cheater will therefore be unable to reproduce this signature, and the server will therefore be able to determine wether to trust a client or not.
|
What is handled on the client side vs server side (Score:0)
by Anonymous Coward on Sunday December 26, @05:16PM EST (#259)
|
In quake, game logic is handled on the server side. It would not be possible to hack up your own executable that makes it so you do 50 points of damage per shotgun pellet and run twice as fast, all of this is determined on the server side. The problem here is not preventing hacked clients, but making sure server operators keep themselves honest enough not to compile something in that says if your name = "Anonymous Coward" then you get 5000 health. Whatever anti hack scheme is created it should be geared towards a client verifying the server is "pure" rather than vice versa.
|
It's Open Source, It Can't Be Cheating! (Score:0)
by Anonymous Coward on Sunday December 26, @05:17PM EST (#261)
|
Just like you're banking account can't be overdrawn, you still have checks in your checkbook. Come on cheaters/open source advocates, get responsible!
|
been going on long time (Score:1)
by Diamond Slicer on Sunday December 26, @05:20PM EST (#263)
(User Info) |
This is nothing new. For almost every game there is some cheaters that exist. The problem with people cheating is not new. Blizzard has this problem with their battlenet servers (for diablo). A closed source or blessed client fix is not always the right option. Either fix can be gotten around if someone has enough time on thier hands. The article does not say cheating at Q.1 is anything new. It just simply states that it is easier for the average gamer to do.
On another note: Will this effect Q.3 - Yes. Diablo II was effected quite a bit by all the lamers that used trainers on battlenet and blizzard has said they added code to stop trainers from being used. When the Q.3 source is released there probably be a patch to prevent hacked clients or clients that are modified.
An ez solution would simply to have a little bit of code in the server that makes sure that the clients have not been edited yet and require people to use non-edited clients - they can always have another on their comp to use if they do not want to always comply with the rule.
- xcuse mi grammer, i lernt it from CmdrTaco - |
Suggestions (Score:1)
by Uri on Sunday December 26, @05:24PM EST (#266)
(User Info) |
In an ideal world the server would send only essential input to the client (e.g. a sequence of 2D images) and request only actual output from it (e.g. key/mouse-strokes). All calculations would take place at the server-end. Hence all interactions would be legal, which would prevent all forms of cheating - except skill, or a client-side bot with human limitations.
Unfortunately, this is clearly impractical wrt bandwidth. So instead one ends up sending more information to clients (e.g. the present universe state) and receiving more back (e.g. a chunk of the future universe state), letting them do all the calculations in between. Malicious clients can use this for 'extra knowledge' such as seeing through walls, and 'extra power' such as rockets that don't miss.
One way of dealing with these is:
1. All information arriving from the client is audited once in a while. That is, the client is required to 'show the working' as it were and send the actual output. Of course, if no actual output would produce the client's chosen future state (or if calculating such an output is impractical) then the client is well and truly buggered.
2. Occasionally, data sent to the client is sent with misleading information. That is, chunks of the present universe state which should have no effect on the desired output (e.g. hidden characters) are replaced with whatever the server feels like. This will not prevent the client from trying to use 'extra-knowledge', but will counteract most of the benefits by providing an inconsistent environment, and will probably piss the cheat off enough for him to give up.
As a sidenote, does anyone know if someone's tried writing a client-side bot that uses just visual input? Would make a darn interesting alternative to handwriting and face recognition...
|
| |
Re:Suggestions (Score:1)
by Jeremi (jaf@chem.ucsd.NOLUNCHMEATDAMMIT.edu) on Sunday December 26, @09:59PM EST (#350)
(User Info) http://sdchemw1.ucsd.edu/~jaf
|
As a sidenote, does anyone know if someone's tried writing a client-side bot that uses just visual input? Would make a darn interesting alternative to handwriting and face recognition...
This is a very interesting idea... after all the complaining from "visual computing" people about how hard it is for a computer to interpret real-world visual input, perhaps it's time to start with systems whose "eyes" aren't video cameras but Quake3 rendering engines. Once we have systems that do a good job visually navigating Quake World, then we can try them out in the Real World...
|
Redownload binary for every game. (Score:1)
by ZephyrAlfredo (mbuttreyatbigfootdotcom) on Sunday December 26, @05:24PM EST (#267)
(User Info) http://www.telusplanet.net/public/mbuttrey/
|
You could be required to download a trusted binary for every game (even every level). The binary and source would be randomly modified for a unique cheating challenge, and as the source is different each time, cheaters would have to spend all their time d/ling and compiling source and no time playing.
This solution is a little off the wall, but I think the quakeworld client could be as little as a 300k file.
My overall suggestion is this: if the conditions needed for sucessful cheating are randomly changing all the time, to cheat will be very time-consuming.
Still, I believe external personal authentication or secondary checksum programs are the future.
|
A non-problem? (Score:1)
by jwriney on Sunday December 26, @05:33PM EST (#272)
(User Info) |
Cheating has been a problem in multiplayer games since Doom. A closed-source, security-through-obscurity solution isn't going to work in the long run, as observed above. Chances are the problem will simply degenerate into a circular "arms race" between those that are trying to cheat, and those who are trying to stop them.
The most practical solution is already in place. As cheats are released, obviously a number of people, mostly 'script kiddies' and the like, will start to use them. If cheaters start frequenting a game server, leave. Just leave. Eventually, the only people left will be the cheaters, and the servers will shrivel and die.
In this way, the problem effectively solves itself. The novelty of patching the game in order to cheat will, eventually, wear off. Servers that are known to harbor cheaters will dissolve. And, most importantly, the source remains open and free for all to study and learn from.
--jwriney
|
| |
Re:A non-problem? (Score:0)
by Anonymous Coward on Monday December 27, @10:49AM EST (#426)
|
You make the assumption that cheating will be obvious. In carmack's plan his simple example of a server side cheat knocks all the dammage done to a specific client down to 25% or something like that... In a fast paced game you can never be totaly sure if someone got hit directly by a rocket or just got singed. Subtle cheats like this make it a very definate problem.
|
Open source (Score:0)
by Anonymous Coward on Sunday December 26, @05:35PM EST (#273)
|
This is *exactly* why games shouldn't be open sourced!!!!!
|
Trends (Score:1)
by redhog (redhogNOSPAM@lysator.liu.se) on Sunday December 26, @05:39PM EST (#275)
(User Info) http://mini.dhs.org
|
This is the second time I read trends here at /.. This time, it is the set of projects that atempts security by obscurity: First Napster, then DVD, and now John Carmack's ideas. This is never a good solution - someone will dissassemble the closed source program some time and implement a cheat. It's only a matter of time.
The problem with Quake is that the client is smart. It is not just steered by the server, but acting by itself. If it was dumb, it would have been easy - there would be no way to cheat since you don't have access to the server.
I don't have any solution right now, but there surely is one. An open-source one.
--The knowledge that you are an idiot, is what distinguishes you from one. |
| |
Re:Trends (Score:0)
by Anonymous Coward on Sunday December 26, @06:38PM EST (#302)
|
Quake1 client was pretty dumb, thats why playing over a modem with it is such a joy. There is no solution only stop gap measures, and the open source variety of the stop gap is inferior in most ways to the closed source variety.
|
[QuakeForge] Cheating in Quake - will fix (Score:1)
by knghtbrd (knghtbrd@debian.org.NOSPAM) on Sunday December 26, @05:52PM EST (#282)
(User Info) |
| Yesterday someone came onto the QuakeForge irc development channel and pointed out the first quake cheat we've seen yet. The movement multiplier. Change it and you can move as fast as you want independant of the server's limits. It's surely not going to be the last such cheat. QuakeForge is already discussing this problem and is planning to fix it WITHOUT requiring a closed source solution because we believe any closed source solution could at best be considered a stopgap measure. We will be coordinating our efforts to fix the problem with the Quake Standards Group. Any ways we discover in which cheating is possible will be fixed as soon as we discover the nature of the problem and the best course of action to correct it. In the meantime we'd like to ask everyone to consider that at least half of the reports of people cheating are probably false alarms anyway. There are real problems in how the client and server trust eachother at the moment which are bound to lead to some problems now that it's possible to modify the clients, but they're certainly not fatal to quake as a game or the quake development projects such as QuakeForge.
|
What about a random check at the server? (Score:0)
by Anonymous Coward on Sunday December 26, @05:57PM EST (#283)
|
I think we could save the old good quake I by making servers check the data send back by clients at random. For example, every ten seconds the server check one client at random, it make all the calculation for some action and compares it with the client answer, if it isn't the same, the client gets banned for half an hour (and a rocket emailed him :-). This way it will be harder to cheat, or at least to cheat in a way that you get advantage over the rest. Because as everybody has already pointed out, OSS is not the problem, people with inferior capabilities when playing networked games, with low cost egos and with half the brain necessary for playing *ARE* the problem.
|
an IMO wild idea (Score:1)
by Mao (pingshun_c@yahoo.com) on Sunday December 26, @06:05PM EST (#286)
(User Info) |
Maybe someone thought about this already. But this morning soon after I read about the cheating problem in linuxgames.com, I wonder:
One solution would be to opensource everything completely. that is opensource the game (which they did) and have a thorough tutorial of the workings of the client so that any joe schmoe can rewrite the code and cheat/counter-cheat. So in the end the invisible hand of self-interest may produce a balanced gameplay. It is like one of those homemade robots competetion where people bring in their bots who try to knock each other out. So now you have different quake clients competing in accordance to a server side protocol. So for example if someone uses an aimbot, you can rewrite the code so that you can dodge incoming projectiles automatically. The cheating would go as far as the game remains fun to the player... Of course this does not apply to people who really don't care about the fun of the game...
But then again as i always will believe, this is a whacked out idea.
|
Well-Known Solution (Score:1)
by MrMister on Sunday December 26, @06:59PM EST (#311)
(User Info) |
It has been possible to verify documents for years now using public/private key encryption techniques, for example PGP. For example, using PGP you can sign an email message and others can then verify that the message really came from you. Obviously the same thing could be done for an executable file. This doesnt depend on the source that does the checking be hidden. So why not have "signed" versions of all the acceptable quake 1 clients and then use public/private key techniques to check them ? Even if you limit yourself to a key-length which would avoid export problems, it would take considerable effort to break a scheme like this.
|
| |
Re:Well-Known Solution (Score:4, Interesting)
by Jamie Zawinski (jwz@jwz.org) on Sunday December 26, @07:58PM EST (#328)
(User Info) http://www.jwz.org/
|
For example, using PGP you can sign an email message and others can then verify that the message really came from you. Obviously the same thing could be done for an executable file Unfortunately, this isn't true. When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender. To oversimplify: you can know who I am, but you can't know that I'm telling you the truth. Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using. This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption.
|
Quake (Score:0)
by Anonymous Coward on Sunday December 26, @07:02PM EST (#315)
|
Quake 1 was good, nr 2 and 3 sucks
Here is a list of GOOD multiplayer games
Teamfortress I&II, Delta Force I&II
Nothing beats a game with a big and good sniper rifle :) And some silenced close-combat weapons too.
|
What is cheating? (Score:3, Insightful)
by Jamie Zawinski (jwz@jwz.org) on Sunday December 26, @07:08PM EST (#317)
(User Info) http://www.jwz.org/
|
Would targetting computers and nightscopes be cheating if everyone used them? Of course not. It's only cheating when people don't agree on the rules. You might think that robot/cyborg players were cheating unless your goal was to see how good you were playing against the AI. Or unless you were competing with other humans to see who could build the best robot. So making it impossible for the game to have bots and timers and other add-ons isn't necessarily the best approach, since that eliminates the potential for whole new forms of gameplay among consenting participants. That's why this is and will always be a social problem, not a technical problem. And it's one with a simple solution: don't play with jerks. It's just like Usenet: it used to be a nice place, but then it got overrun by idiots, and so newer, smaller communities like Slashdot appeared. If you are playing Quake and there are a lot of cheaters and idiots around, chances are your community got too big (and thus lost the elements of it that made it actually be a community) and you need to find or create a more intimate one.
|
| |
Re:What is cheating? (Score:0)
by Anonymous Coward on Monday December 27, @10:39AM EST (#425)
|
Nice thought, but people don't win or lose on usenet. People will seak out places they can cheet cuz' they crave the ego boost. As long as cheating is prevelent, or at least as long as their is no way to tell if someone is cheating or not nobody will ever be able to play with the same confedence.
Peter M.
|
Show them that open source works... (Score:0)
by Anonymous Coward on Sunday December 26, @07:37PM EST (#320)
|
Well, it seems to me that this presents the open source community with an excellent chance to prove itself... People have said that open sourceing quake is not the cause of the cheating. That cheating still would have been/was possible, just harder.
The real issue here is this: A software developers time is money. This is amplified by the slimmer profit margin on games and the pressure to innovate. When something like the protocol for a network game is developed closed source it take much more initial effort to hack it. So much so that in many cases people simply don't take the time to do such a thing (after all, it's a game and we are talking about high scores, not a high security server). Additionally it is fairly easy for a manufacturer to make some sort of simple "Band-Aid" type fix that renders all the effort that went into hacking the protocol worthless. Compound this by the fact that with game hacking the only _real_ payoff is the esteem that a person might get for the oh-so-sexy first hack, a repeat attempt is a lot less likely.
Games being games there is also a lot less pressure on manufacturers to make them secure. A game that someone can cheat at will hardly serve to tarnish the reputation of a game company, the only real loss is that of some gamers pride for a little while. All the company must do is simply produce the previously mentioned fix and everyone is happy again.
On the other hand if a game is released as open source and a plethora of hacks start appearing faster then anyone can fix them nobody will want to play the game and the manufacture (and the community) will lose big-time.
Now as a community if we want thing like games to be open sourced then the burden would seem to fall on us to provide a way for game makers to do what we want, yet still live securely in their little profit driven world. Therefor what needs to happen here is the creation of an open and secure framework for game client server communication. Something such at this would have to have the following requirements:
Speed - Speed is paramount, our solution must be extremely fast. The fastest solution available really. I'm sure everyone here has felt the pain of laggin network games.
Ease of implementation - It has to be flexible enough that it can be incorporated into all types of games but really painless to implement. The best way to get a game programmer to make use of something like this is to make it better then what he could accomplish by himself.
Security - Though obviously security is what is most important to "us", it's the last concern for "them"... Game companies have a model right now that works just fine for them. In order for something like this to work (and to have any sort of point) the security would have to be good enough to make cheating as rare on occurrence as it is with existing closed source models but not impact ether of the previous two goals.
As I finish writing this I've almost convinced myself of it's impossibility. Iron clad security with no penalty? Speed comparable to or better then anything that has come before? The goals are numerous the obstacles large and the reward comparatively small, remind anyone of anything? :)
I'm not a programmer or an organizer (nor do I ordinarily spend an hour writing things to post to /.), what I've proposed might be impossible. It might not interest anyone. But I hope it does. I use to run Linux but stopped when I got into CG and found that the best software was not available for the platform and that I didn’t have the disk space to devote to something that was not my primary interest. Since then I’ve watched Linux and open source software bloom into something that I never though possible. Because the software I use is still not available I remain a windows user, but I have watched and waited for the day that this will change. I put my faith in all of you to help expand the boundaries of what has been the conventional limit of open source software.
The "opensourceing" of Quake I may very well be the first and last chance the open source community has to prove that their model for software development is good for situations outside it's current scope. I hope that some of you pick up this ball and run with it.
Happy New Year and good luck,
Peter M.
|
Software problem or community problem? (Score:1)
by xeer0 on Sunday December 26, @07:49PM EST (#325)
(User Info) |
In every sort of game there exists the potential for cheating. From thursday night poker games to the World Series.
In Quake gaming and client/server computer games in general I doubt the remedy to this will be in software.
It seems more likely to me that an adjustment in the attitudes/customs of the community will bring swifter, better results. The higher the stakes the participants are playing for, the more severe security measures the community will have to take. Leagues and other "official" organizations will start to assume more importance.
In other words games for money will probably have to be played on league property, on the league's hardware, using the league's clients and servers, with league referrees monitoring the participants at all times. Just like all other games played for money.
There will still be cheating. The World Series has been fixed and people are occassionally caught in the Majors with corked bats, but the frequency will have been reduced to a level that the community can stand.
As for smaller pick-up games for fun, every time you go into a new community (or in this case, server) there is always the chance that you will be cheated. The same holds true for poker, basketball, pool or Quake.
Basically you need to look around for a community that holds values similiar to your own.
With the game being open sourced hopefully there will be a large number of servers out there and you can find one that values your mad fragging skills or insane hax0r ability appropriately.
"Hey... don't be mean." --Buckaroo Banzai |
Cheating in QuakeWorld, thoughts about the source (Score:1)
by Vario on Sunday December 26, @07:51PM EST (#326)
(User Info) |
hi,
at first I was very excited that the source code of my favorite online game was finally gpl'ed. Now the several problems and incompatibilities can be adressed.
The remaining problem is cheating. I read several thoughts in this discussion about checksumms, cryptography, etc. but in my opinion nothing like this will work.
To prove this I'll give you an example of a typical clan match in team fortress (a quake mod). 20 people join the server. Their maps are checked with a crc32 checksum (maybe md5, dont remember exactly), their models too. The movement protocol is a bit encrypted too. Then we perform a f_modified check. f_modified is the keyword for qizmo, a qw proxy, to calculate the checksum of the executable, the models, maps, sounds, etc and replies it to the server so that everyone knows that there is nobody cheating.
This system with qizmo is quite safe and trusted by the online community.
Now with the source release several problems come to the surface.
The f_modified check still works, it reports incorrect binaries sucessfully. The problem now is the server. My clan is called "CORE", so it's a five minute hack to implement a function in the server executable like: if (teamname = "CORE") then give health 150%
This cheat is not detectable for the other players and clan matches are useless now.
Everyone here discusses about trust and encryption. With the gpl'ed quake we can not trust the clients and the servers! In my opinion this problem is almost unsolvable. Maybe we need a closed source program like qizmo for the serverside too, any suggestions?
Vario
--
for more infos about qizmo check http://qizmo.sci.fi
|
| |
Re:Cheating in QuakeWorld, thoughts about the sour (Score:1)
by rpenguin (rpslashdot@k0w.com) on Monday December 27, @01:49AM EST (#393)
(User Info) |
I believe that server cheats present only a very small problem. In the Quake community, people know the server operators, and server operators spend a large amount of resources to keep their servers running and are generally of good will. A clan who hosted a server for clan matches would have a hard time running a 'cheat' server without getting caught. Most clans, in fact, are not interested in cheating, but playing the game and competing.
The majority of cheaters are those who join public servers for pickup or deathmatch games and just wanna see their name at the top of the scorelist. There's no way to stop cheating, the same problem exists with chess by mail or email. I can't make any illegal moves, but I most certainly can have a computer make my move for me and that might give me an unfair advantage. Qizmo is great, but it's certainly not foolproof.
|
Nothing new about Quake cheating (Score:1)
by Juln (juln @ netscape . net) on Sunday December 26, @08:04PM EST (#329)
(User Info) |
People have been cheating in the original Quake for quite a while.. that has made even more annoying and irritation that the game was to begin with. Open Source quake might make it a bit easier, but there has been so much cheating in quake already - big deal.
Juln |
Not a new problem (Score:2)
by Felinoid (jeffery@[website_url]) on Sunday December 26, @08:56PM EST (#336)
(User Info) http://www.meowpawjects.com/
|
I'm affrde a lot of people are responding with the same old answers.
The fact is on-line games like Quake are VERY sensitive to cheating. The client is trusted with "to much information" it's nessisary becouse the server can not deliver all nessisary information on time. Instead the server delivers information the client MIGHT need.
Time City preposes to solve this problem by building the client/server pacage ground up with an auditing system. All Quake servers and clients were built ground up on a trust system. To change this would require a compleate rewrite.
The problem is Quake expects the client to be 100% reliable and trustworthy. Now that the client is open sourced this is no longer the case. Just as you can close security holes in open source you can open them.
Thies defects have been known for quite some time and could NOT be addressed. Eventually some punk would make a cheat clinet based on the server code (allready open) not the client code and we'd be in the same position. But it would have been sevral years from now and by then Quake would not be that iteresting.
Many open sourced multiplayer games suffer exactly the same problem. They solve it with a closed sorce solution. Trusted clients are compiled by the games develupers and given encryption keys. If your client has a valid key you can play if not you may have compiled it yourself and could be running a cheat client.
So the source is only there to fix the bugs and improve the game but to accually use it you have to return the code to the develupers and let them compile it.
Or you can fork the code and make your own keys.. But then only the servers recognising your keys/code could be used by your fork.
Time citys solution is unqiue and time will tell if the game server will effectively detect cheating or if people will be able to make cheat clients using the open source code.
The way it was explained to me BTW is that if the server detects someone cheating he will be dropped form the server.. It dose this by mesuring to make shure the user really really really could do what he says he's doing and if not.. disconnect...
Some of the cheats in a Quake client rely heavy on the fact that Quake clients MUST have data on ALL players at ALL times. Raidar and transparent walls are the result. The client is trusted to do "the right thing" with the data. A cheat need only take advantage of this...
If Quake did not yeald as much information as it dose it wouldn't be so easy to cheat... but that would take a compleate rewrite of the client server interface....
Others are to blame for the obstacle I must overcome but I alone am to blame for my failures... |
Carmack - idiot!!! (Score:0)
by Anonymous Coward on Sunday December 26, @09:04PM EST (#337)
|
Carmack is an idiot and should burn in hell for proposing a closed source solution. It shows that he knows little about real coding. Real coders support 100% Pure Open Source. Also, the fact that he released first for Windoze shows that he has no respect for the huge Linux community.
|
If you are really interested in the subject then.. (Score:2, Informative)
by The Optimizer on Sunday December 26, @09:18PM EST (#343)
(User Info) http://www.ageofempires.net/studios/people/mpritchard.shtml
|
...please check out my upcoming article in Game Developer Magazine on Cheating in Online Games. It will appear in the May (+/- 1 Month) 2000 issue (The exact date of publication will be determined when both Alex Dunne (GD Magazine Senior Editor) and I get back from our respective vacations).
(Darn! Of all the days to be gone visiting relatives, there are ~320 posts already - I'm hoping someone still has moderator points left)
The article for Game Developer discusses not only cheating in fast client/server games like Quake and other shooters, but in strategy games such as Age of Empires and Starcraft, Action-RPG's such as Diablo, Massively multiplayer games such as Ultima Online, and others. It also makes an effort to identify and classify cheating efforts from the blatant hacks to the gray-area issues of a game's design. It discusses the various architectures games use, and the inherent strengths and weaknesses in them. It talks about the specifics of how games get hacked, specific counters for them, and the limits therein. It also examines programming weaknesses that can lend themselves to cheating in non-obvious ways. My goal with this article is to provide to others in the game industry a reference to assist them in their efforts to secure their games. (For those interested in my credentials, I've written significant portions of all three "Age of Empires" games, and worrying about cheating and designing counters for them is something I'm paid to do in my day job. :)
With that said, there are four rules that apply to Cheating in ALL Multiplayer games:
1) Despite what you think, someone really wants to cheat bad enough to do it.
2) Despite what you think, cheating in game (insert title here) is possible.
3) Despite what you think, someone really wants to cheat bad enough to do it
4) Despite what you think, cheating in game (insert title here) is possible.
I repeat myself because denying the problem (which many game publishers do) does not make it go away.
-----------------------------
In response to various issues raised in the ~320 posts so far, I would like to assert the following regarding online gaming:
Closed Source will not prevent cheating, only slow it down (a little)
Terje Mathisen is correct - it is absolutely impossible to make a completely cheatproof system
This is not a case of "Security Holes" in the game programs, but rather basic aspects of the design of our computers and network communications being used to achieve particular results. To perceive it as such is to promote a fallacy.
You can verify that a game is running a specific and trusted executable. This does not achieve security. You can not verify anything else that is running on that computer or any other computer between you and the other players that passes your communication packets along.
Security through obscurity is not security
John Carmack's post includes pretty much all I was planning on saying about cheating in Quake-engine games and clarifies the misconceptions in many of the other posts. The issues with the Quake Architecture are summed up in his comment: "The cheating clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully. " - What I classify as "Information Exposure" and "Reflex Augmentation".
Information exposure will remain one of the biggest problems for most games. In nearly every game, there is a degree of interpretation in the display of a fixed piece of information. A cheater can alter that interpretation (display something that should not be shown, make bright something dark, make a sound louder, whatever) on his and only his machine without altering that information with respect to the game world it is a part of.
Information exposure does not have to involve modification of game's code, data, or network communications. Passive reading of network packets and key values from another processes' memory space are sufficient to provide a cheater with a significant advantage with some games.
Reflex Augmentation will remain a big problem for games where player's reflexes are an important part. How fast you can move the pips in Backgammon does not matter - it has no bearing on the outcome of the game, or the other player's turn. In Quake or Half-Life, it's all about being fast and accurate; that's why you can never have a fast enough system, video card, or ping. Aim-bots and other proxies will always be capable of passing themselves off as the real thing. The fundamental problem here is the inability to distinguish human inputs into the game from computer generated inputs. Quake server modifications to attempt to distinguish the two have led to the Aim-Bots adding human-style "errors" into their inputs until their accuracy is reduced to just below the statistical threshold that the server will allow. That really good human players may be incorrectly fingered as cheaters only underscores the limits of this option.
Game Design decisions may inadvertently add to the problem and lead to quicker dissatisfaction with a given game. I'll use Half-Life for an example. Let's assume an auto-aim proxy exists for it (I believe it does). Half-Life has a weapon in Deathmatch that has two interesting capabilities (which have a place in normal gameplay): 1) it kills with a single shot no matter how much health or armor the target has. 2) it shoots through walls. I will leave it as an exercise to the reader as to how much less fun the game becomes (became) the day that proxy makes (made) the rounds.
Encryption in communications has some important limitations:
1) Any sort of protocol that involves adding any back-and-forth to complete a single action will raise "ping" times significantly. Games are already struggling to do everything possible to reduce lag. The gaming community would reject adding 250 ms to everyone's ping.
2) Packet loss is accepted for some portion of communications in some action games. Any sort of encryption on those packets has to be able to survive lost packets.
3) CPU bandwidth is limited. Too many cycles devoted to encryption and decryption (especially on the server) will negatively impact game performance.
4) If the end user has access to both the client and server, they can and will be debugged. By very smart people.
Slashdot user 'Pete-classic' touched on one of the anti-cheating efforts that I feel has been under-explored to date: identifying people that cheat at a game and exposing them to the online user community for that game. Being able to record games and play them back from the perspective of other players (as you can in Age of Empires II) brings the ability to audit a game after it is played. While this can't address all possible forms of cheating, it's a good tools for raising suspicion in those cases that it can't outright detect. It's also equally useful for proving that you were beaten by a better opponent.
An opportunity exists for developers to add hooks into future games to assist the user community in policing itself. Imagine if you will, that when your server browser bring up a list of games, next to the net-speed indicator is an indication of the controversy and reputation of the server. Social solutions are going to be complex and take time evolve, but they offer possibilities that programming alone can't.
So much more to say, but I have to sign off now. Thanks for reading and caring.
-Matt Pritchard
Ensemble Studios
Age of Empires, Rise of Rome, Age of Empires 2: Age of Kings
|
| |
Re:If you are really interested in the subject the (Score:2)
by Jamie Zawinski (jwz@jwz.org) on Monday December 27, @03:24AM EST (#400)
(User Info) http://www.jwz.org/
|
Matt Pritchard said a lot of good things and then said: You can verify that a game is running a specific and trusted executable. This does not achieve security. You can not verify anything else that is running on that computer or any other computer between you and the other players that passes your communication packets along. I have to disagree with the first part: I don't believe that you can verify that a game is running a specific and trusted executable. Maybe I'm wrong -- I am not a cryptographer, and don't even play one on TV -- but I just don't understand how this is technically possible. If someone thinks they know how to do this, I'd like to hear how. Security through obscurity is not security Amen.
|
Re:If you are really interested in the subject the (Score:1)
by cherub (hazel@hawking.cs.stedwards.edu) on Monday December 27, @08:17AM EST (#412)
(User Info) http://www.cs.stedwards.edu/~hazel/
|
| I have to disagree with the first part: I don't believe that you can verify that a game is running a specific and trusted executable. I know it's sort of out of the range of solutions you were considering, but it would be possible with various forms of redundant distributed processing (amoung player machines) to verify that each client is running the correct executable. Still doesn't help, of course, since a client could always cheat with programs that act purely on the inputs and outputs of the game. >Security through obscurity is not security
Amen. That aphorism has always bugged me, useful as it is. All security is obscurity, in a sense. The data that will clear up the obscurity can be seen as the "key". The important thing is to isolate the obscurity (to the recognized key), and to be reasonably confident that one can't determine the key without solving a Hard Problem (finding large prime factors, obtaining data from the brain of an unwilling human, getting ahold of the disk I keep in my left breast pocket, etc).
|
Re:If you are really interested in the subject the (Score:1)
by The Optimizer on Monday December 27, @07:04PM EST (#465)
(User Info) http://www.ageofempires.net/studios/people/mpritchard.shtml
|
Jamie Zawinski said:
I have to disagree with the first part: I don't believe that you can verify that a game is running a specific and trusted executable.
Maybe I'm wrong -- I am not a cryptographer, and don't even play one on TV -- but I just don't understand how this is technically possible. If someone thinks they know how to do this, I'd like to hear how.
Jamie,
You are technically correct. A more accurate thing to have said whould have been:
Even if the game executable running is unaltered it doesn't mean damn thing. Someone can still be cheating bigtime.
As a game developer, the underlying issue is that there are more ways to cheat than just hacking up the code. A good game will assume that it is running in a hostile environment and attempt to raise the difficulty and cost of cheating (with an understanding of its vulnerabilities).
|
Here's an idea: it's not cheating! (Score:2)
by Kaz Kylheku on Sunday December 26, @10:10PM EST (#351)
(User Info) http://users.footprints.net/~kaz/
|
The open source model lets creative people come up with superior strategies for winning. It's retarded to run around with the mouse and fire if you can use your brains and hack up some code to kick everyone's asses.
Plus isn't it, at least to some extent, the fault of the design of the game protocol in that it facilitates cheating? A well designed protocol would not allow client modifications to give rise to cheats---other than the creation of robot players with superhuman reflexes. Even that could be eliminated; the game server could be equipped with detection heuristics in order to kick suspected robot players off, or handicap them in some way.
I think that people who cry ``cheat'' are just damn whiners lashing out against nerds who are applying ``alternative skills'' to the game.
|
What about ADVANCEMENT?! (Score:0)
by Anonymous Coward on Sunday December 26, @10:27PM EST (#352)
|
Why is everybody bitching about people cheating at this old game? There's some killer network code in there! There's an awesome game engine! There's interface, resource management, and multiplayer code! Why, oh why is everyone so hung up on people cheating all of a sudden? The game is how old? How many people have moved on? How easy is it to cheat at any aspect with mods and patches already in existance?! How many actually read his .plan? Shit, use it, modify it, and send it back out.. Am I missing something, or isn't that the point of releasing the thing in the first place?
|
Question on the Binary HASH key (re: netrek). (Score:1)
by Grock on Sunday December 26, @10:40PM EST (#354)
(User Info) |
How can the server verify the HASH key? If the
server is asking the client, then it would be
easy enough to fake the response??? I have never
seen a good idea for client-server gaming where
the server puts *any* trust into the client.
Thanks,
Ben (greearb@candelatech.com)
|
| |
Re:Question on the Binary HASH key (re: netrek). (Score:1)
by sheldon (sheldon@yuck.net) on Monday December 27, @01:26AM EST (#388)
(User Info) http://www.sheldon.visi.com
|
The secret is RSA public key encryption.
The server encrypts something using the client's public key, sends it to the client who then decrypts it and responds accordingly.
Only something holding the private key can decrypt the message.
The old mechanism used to use a rather simply encryption/decryption program based off of some simple math. It worked, as long as the source was trusted. Then someone posted the source to the newsgroup and it was all over. :)
|
Perspective... (Score:1)
by raytracer on Sunday December 26, @10:47PM EST (#356)
(User Info) |
C'mon people, let's show some perspective here.
Quake is a game. Yes, it's annoying to enter a game where someone employs one of the various descendents of Stooge-Bot to blast you from here to oblivion. But to claim that this is somehow a big problem with the Open Source methology is just silly.
As far as I know, the first client of this type was the StoogeBot stuff done by some students at Stanford with lots of time on their hand. Note: this was well before the source code for Quake was available. It's a relatively straightforward thing to make a proxy to intercept and log the conversations between the server and client, and since the original protocol was done pretty much without any kind of authentication or security, it apparently wasn't very difficult to reverse engineer the protocol.
I view the whole thing as a rather clever bit of hacking, perhaps not worthy of slashdots top 10 list, but rather good overall. Yes, it does ruin the fun for some people. But you'll find that some people will cheat at pretty much anything. I'd merely advise not to play with such people...
To me, it's pretty damned silly to play a game that you always win.
|
A crypto graphical solution. (Score:2)
by Inoshiro on Sunday December 26, @11:25PM EST (#364)
(User Info) http://www.thock.com/Dylan/
|
the only way to have no one be able to cheat is with a closed-source system of checking.
We have GnuPG under the GPL, as well as Quake 1 and OpenSSH. So why not setup a system where first the client and server exchange keys and begin encrypting the session, then they verify the identities (this could allow a global "stats" centre) of the client and server. If the server is a good one, and the client has not been blacklisted, play commences. By encrypting the stream (or just compressing it), you make it harder for others to break in and/or forge identities. This could dovetail quite well with Netrek's blessed binaries, and would allow better "global" rankings :-)
---
Internet Explorer (n): Another bug, that is, a feature that can't be turned off, in Windows. See also: monopoly. |
| |
Re:A crypto graphical solution. (Score:2)
by MikeBabcock (mikebabcock@pobox.com) on Monday December 27, @09:34AM EST (#419)
(User Info) http://www.linuxsupportline.com/~pgp/
|
Sure, if you want to make a database of "trusted" people ...
- Michael T. Babcock <homepage> - PGP Key 0xC2F837FD |
action and reaction (Score:1)
by serialk (thematrix@themail.com) on Sunday December 26, @11:27PM EST (#366)
(User Info) http://aboutguide.tripod.com
|
people can and will always attempt to do stuff
like this but thta does not mean it should not be
open for all.
|
reasons not to open source (Score:1)
by CmdData (data@startrek.com) on Monday December 27, @12:50AM EST (#382)
(User Info) http://www.erac.com
|
Yet another reason why giving people the code to your programs. This happends to 99% of all open source games. And almost 4% closed source games
|
Use Cryptography (Score:1)
by DoronRajwan on Monday December 27, @01:41AM EST (#390)
(User Info) |
| Like in a lot of cases, you can use strong cryptography to solve this. Id should create two version of Quake: An open-source version, and a binary version. The versions will be almost identical, except one thing: the binary version will use strong cryptography to pass it's messages. When connecting to open-source version of Quake server, or a Quake client, a player with the binary version will get a warning. Then, he/she can decide to play or not. It is possible to use private-key cryptography (no need for public-key cryptography). However, the binary version will need some kind of anti-debugging code. Doron.
|
Client Downloading? (Score:1)
by Wiwi Jumbo on Monday December 27, @08:41AM EST (#413)
(User Info) |
I'll be the first to admit that I don't really have a grasp on this subject, but would it be possible to make it so that the client had to download the server's version of the game code?
I'll try to make this as straight forward as possible...
1) Clients need to dl game code each time they connect.
2) Servers need to compile their own binary, which results in adding a random password to some varible.
3)Server checks for the correct password in the binary.
I have no idea how large the game code would be, so if it's of fair size this would be impractical.
I'm sure there are other problems associated with this, but I figure that I might as well put this "out there"... maybe someone could fill in the holes and make this work. (If it's not horribly flawed to begin with...)
Wiwi
--
"I trust in my abilities,
but I want more then they offer"
-The Odds, "At Your Word" off the album "nest" |
| |
Re:Client Downloading? (Score:0)
by Anonymous Coward on Monday December 27, @02:53PM EST (#455)
|
| No this doesn't work for a few reasons: 1) Game code must be decrypted to run; it can then be modified/analyzed/encryption broken etc. 2) Other programs can be run on the client machine to modify incoming and outgoing messages (Ok, so maybe message checksums would make this more difficult) 3) You're still assuming the server is trusted.
|
the assholes always rule (Score:0)
by Anonymous Coward on Monday December 27, @08:44AM EST (#414)
|
The problem ISN'T open source, it's the players themselves. There have been cheaters since there has been Quake. The most popular page on my site (to my dismay) is the single player cheats page, followed by the console command page, followed by the server commands page. The Quake "community" has the same proportion of assholes as the world at large. If you think the preponderance of "first post" posts here is pathetic, you should see the trolls on sCary's messageboard (shugashack.com) It's not a new problem; people have been hacking the source, creating cheatbots, etc. since online gaming started. Besides, if I am on a T1 and you are on a 33.6, am I cheating? And why isn't it counted as a kill if I push you into the lava? The simple answer is- if you don't like the server or the players, get out and use one of the thousands of other ones. This is easy with Q1, open sourced or not. Unfortunately, you can't do that with Q3A, as they make you wait 5 mins to join another server (according to the .plans).
|
| |
Re:the assholes always rule (Score:0)
by Anonymous Coward on Tuesday December 28, @05:53PM EST (#477)
|
Not nessecaraily, society has evoled a system of incentives and punishmenets to keep cheaters in line. We have jail for people who steal, cheat and lie to gain an unfair advantage over the law abiding citizens. What's lacking in the quake community is a complementary structure of expected and inforced rules of behavoir. That may sound like a bad thing, but without rules anarchy is rampant, and those who take advantage of the systems gain the most, the cheaters usually. Looking at online banking, and other secure transation mechanisms on the internet would hold the key to prevent cheating. Creating an appropriate method of punishing cheating would greatly reduce it. If a secure name server verifies a person as a non-cheater, the player can play, if however this person is a known cheater the server has the option of denying connection. Thus if one is prone to cheating, it is mostly likely that they would be eventually be caught once or twice and end up in the cheaters database, which would ban them for all legitimate players servers. Perhaps this will timeout so they can eventually redeem themselvels. They ofcourse can play on the opens servers which don't care who plays. Since the non-cheater population has always been greater than the cheater population most of the people playing will mostly likly be on the secure servers. Since the secure name servers have heavy secutirty they are unlikely to be hacked, the weakest part of this system is catching the cheater and also identifying them. These are known issues of internet security and i'm sure approirtate techniques can be used to ensure reasonable success rates. Nothing is absolute but this solution could be implemented with little additional code to the source and no need for expensive client-server encryption rounties or server engine mods, and it makes no restrtitions on the servers themselves so they can be free to invoate. Good luck! -ddn
|
Who cares? (Score:0)
by Anonymous Coward on Monday December 27, @09:09AM EST (#415)
|
Get off your butts and buy Quake 3. The lightning gun is back, and the rocket launcher doesn't suck anymore. No lamer-friendly bfg anymore either. Gameplay is soso, but it was the same with q1 and q2...wait for the REAL game*PLAY* programmers to make the mods. id makes wonderful clients, but has little clue on truly FUN gameplay.
|
Ignorance and Open Source Zealotry (Score:0)
by Anonymous Coward on Monday December 27, @09:24AM EST (#416)
|
A disturbing amount of this discussion is simply garbage. What is staggering is not the lack of technical knowledge displayed by some of the people posting, but their arrogance in assuming that they can, with a few seconds' consideration, solve problems that the authors of Quake/QW/Quake2/Quake3 have been fighting for years. Why do you think John Carmack wrote about this problem? Because he's so stupid that he never thought of a) checksums of some form or b) moving game decisions to the server? Or because these suggestions are useless?
Checksums cannot work because they can be faked. Reading Carmack's plan/post would have helped inform some of the people who, despite professing to knowing nothing about Quake, still feel the need to give of their knowledge. Whatever checksum you demand of the client, it can be supplied by a cheating client. This was made significantly easier by the release of the source. Yes, keeping the software closed source only slows down the cheaters, but that is better than nothing. That this conflicts with people's religious feelings about open source's superiority is irrelevant: it is simply a technical fact.
The helpful suggestions to enforce damage levels, physics and ammo counts on the server are as useless as the checksum ideas: all of this has always been done in Quake. Had the posters in question bothered to gather any facts at all before submitting their ramblings they might have realised this. Because the list of entities sent by the server is necessarily imprecise, clients often have more information than they strictly need to construct a given frame. Thus cheats which allow seeing players round corners are possible. Worse, even given a client that uses no more information than a legitimate one, automatic aiming can be used.
The solution used by Netrek is essentially the same as the one proposed in Carmack's plan: a closed source one. There is no completely secure technical solution - maybe the real solution does lie in how the community itself works - but the best attempt at a technical solution relies on closed source, and no amount of platitudinous sermonising about open source will change that.
|
Who cares about cheating? (Score:0)
by Anonymous Coward on Monday December 27, @09:49AM EST (#421)
|
Wasn't there a rogue source code version available on the net? I know because I actually had it stored on my box for a while. Someone (not mentioning who to protect the guilty) offered it to me almost a year back. Since source code was allready available, why weren't there rogue clients appearing everywhere?
I don't think GPL'ing will murder the game. It will make it a better game. I downloaded it, am sifting through it now and seeing what makes it tick.
Sure I'll hack around in it, to see what the possibilities are, and I might even fix bugs, introduce new ones, or add new features.
Who cares? I think it's a wonderful thing that's happened. I can finally port quake to my Palm IV! ;-)
Gtx,
Me
|
..., unfortunately, a closed source solution. (Score:1)
by Object01 on Monday December 27, @09:57AM EST (#422)
(User Info) http://objection.resnet.gatech.edu
|
You people make it sound like you have bouts of depression every time you discover that a project is closed source. There is nothing WRONG with closed source. In addition, you people need to learn that it would be IMPOSSIBLE to secure the Quake client if all code involved were open source. So don't go blabbing about how "unfortunate" a closed source solution is. It's the ONLY solution, and you know it. There isn't an alternative, so DON'T COMPLAIN!
-- Jeff S. |
I dont see OSS as the cause (Score:0)
by Anonymous Coward on Monday December 27, @10:16AM EST (#423)
|
Online cheating in games has become common. Diablo comes to mind. The solution is that there will have to be anti-cheating systems which are strong enough to make OSS. Its not as if closed source makes something safe. To an asm cracker, everything is open source.
|
Open Source: Choice of the Cheater's Generation (Score:0)
by Anonymous Coward on Monday December 27, @11:42AM EST (#428)
|
Forget generation X, now we how the open source cheater's generation. Finally, the lie of open source has been exposed. And, will be exposed even more once the bubble bursts! I can't wait till it does.
|
It *IS* only a game. (Score:1)
by mr on Monday December 27, @11:50AM EST (#429)
(User Info) |
I hate to break this to you all.
But we *ARE* talking about a game here. Soemthing people do for entertainment.
And, for some, having the computer do some of the helping (like aming/shooting/scripting) is how they get entertainment.
This "robot problem" is one that has existed for YEARS in the mudding community. And, rather than get an ulcer over a game, its better to just play the game the way YOU enjoy to play it, rather whan worry about how everyone ELSE is playing.
If it was said on slashdot, it MUST be true! |
A new client/server model? (Score:1)
by Fesh (eric/fesh@wcom/com) on Monday December 27, @12:31PM EST (#440)
(User Info) |
| I wonder if it might not be possible to distribute server functions across a group of related clients (say a "team", or grouped by location on the game grid). The clients would agree by "majority" vote on an action. Since cheaters are usually a minority, this would filter out a cheating client. Of course, commo overhead becomes a major issue. Related question to commo overhead... It usually takes much more effort to make/break a connection than to maintain one, correct? The only real solution I see is centralized control over servers. Not necessarily closed source, but using an untrusted client model with a server in control of someone who has an interest in seeing that the game is played by the rules. This is pretty much the way I'm leaning with an idea that I'm kicking around at the moment... I as a game designer have a vision of how things should run in "my" universe, so I feel that I would need to keep server-side control. Is this unreasonable?
--Fesh
My email has been /. encoded.
|
| |
Com overhead (Score:0)
by Anonymous Coward on Monday December 27, @03:01PM EST (#457)
|
| Of course, commo overhead becomes a major issue. Actually, with IP multicast, there would be no more network traffic than with a central server based system. No, a guaranteed trusted server still doesn't solve problems like auto-aim, auto-dodge, radar, etc.
|
Simple answer to a simple problem (Score:1)
by FPhlyer on Monday December 27, @12:59PM EST (#442)
(User Info) http://slashdot.org
|
The whole idea of releasing software under the GPL is to allow people to modify the source code. This is not cheating, it's programming. The obvious solution is to setup servers to allow people to run their hacked clients to their hearts content. This would allow the "cheaters" to play against others of their kind. The key competition on this kind of server would not be who has the most frags, but rather who has coded the most stunning "feature" into his/her client. Imagine a game of quake in which players have the abilities to alter reality much like in "The Matrix." Would't it be fun to play against other players who can walk on the ceilings/walls or jump 100 feet if your player were camelion like and could take on the texture map of your surroundings? Sure, these aren't cool cheats in a regular game of quake, but if you dedicate certain servers for nothing but hacked code, you will have one excellent competition running.
--Brought to you you by Frobozz Magic Penguin Fodder. |
I haven't seen one issue being addressed (Score:1)
by sean.k on Monday December 27, @01:07PM EST (#443)
(User Info) |
and that is that this is the code for Quake *1*. The game itself has been around for years, and Id has long since stopped actively supporting it.
Id released the source to the community so that people could learn from it. They never claimed that the client or protocol was unhackable and should not be expected to take any responsibility for the hacking that's occurring now. If people have a problem with the way the code is implemented, they should take it upon themselves to change it. After all, that is why it's in the public domain now.
|
Why ID really let out the source code (Score:1)
by 9001 on Monday December 27, @01:50PM EST (#449)
(User Info) |
I really dont understand why ID released the source. Sure it is great that people can help fix it up and maybe make the game better, but over all it will just cause more problems. Already I have seen hacks that crack the admin codes and rcons for all servers, I have seen bots galore, radars, and much more. This is all within the first week or so, I dont even want to think what will happen in a month or two. Id is saying that people will just have to make a client with better cheat protection for everyone to use for tourneys, this will be extreemly dificult, because you will always have people who are unhappy with the way it turned out, or that dont like certain features. I was always taught that if it aint broke why fix it. I dont see why they did not just release it to a few trusted people that could work on it themsleves and keep the security of the game. My thoughts on why id released the q1 source code is because they realised that there is still a huge qw comunity that are not going to q3 and that will not be purchasing their game, and by releasing the source they made it more vulnerable to cheats and hacks, which in turn makes the game no where near as fun. Which they hope will make all us die hard quake players get completely pissed and change to Q3 so that there will be fewer bots. I do know that there will never be a game with no cheats, there is always someone who can hack it. I just dont see why id had to make it so easy for them to do it. I just think they should have waited awhile before releasing it to the general public. that is my two cents... or maybe 20$
|
What game are these people playing? (Score:1)
by rocketjesus on Monday December 27, @02:13PM EST (#451)
(User Info) |
I've heard from the people complaining that releasing the source had just killed QW, because it was going to increase cheating.
I'm not sure what these guys are playing. I stopped playing QW because of all the cheaters. People who could run faster, whos weapons did more damage, who would get gibs on every shot they fired. They were rife about two years ago, when I was still playing. I haven't played since one game where a guy started blasting away with the lightning gun on a level that had no lightning gun.
It'll probably make it harder, as you can now modify the server to better recognize when people are violating the base rules.
What I'm thinking is this: A server mod that gives far more detailed information about each player. Things like: Average Speed, % of shots that hit, amount of damage per shot per weapon, rate of fire per weapon, things like that.
I don't really care about some of the more cosmetic cheats. Yes, modifying pak2 so the character models had axis bars sticking out of them so you could see them through walls is a cheat, but it's not one that gives that much of an advantage. I'm more concerned about people with abilities that give them 50% or more kills over the honest players. All of that stuff can be pretty easily checked on the server side.
|
Try this on for size... (Score:1)
by Red_Chaos1 (red_chaos1@hushmail.com) on Monday December 27, @07:26PM EST (#466)
(User Info) |
Since opening the source of a given program generally makes it free, why not just make it closed source freeware? Might be a little too late now, but leaving it closed and making it free would be have stopped this whole thing from happening. The only thing I personally would like to see, is a REAL OpenGL implementation, rather than this crap 3Dfx OpenGL implementation. It would be nice to see regular Quake the way I see Quake2. Thats my two cents.
|
Quake1 source was out years ago (Score:0)
by Anonymous Coward on Monday December 27, @09:49PM EST (#469)
|
I remember getting quake 1 source that was stolen from..stomped.com ? back a couple years ago, i wasn't too into linux then but from what i heard it compiled fine..this was when id gave stomped the source to port it to linux. so at least in this case, having the source GPL'd wouldn't help the people trying to cheat because the good ones would of had theee source years ago and would have 'been there done that'.
|
Why this is a good thing (Score:1)
by LordLobo (lordlobo@voyager.net) on Tuesday December 28, @07:40AM EST (#474)
(User Info) |
After limiting to threshold 3 (Thank GOD) I came across many great comments. I like open source quake. I learned a mound from the source to QE4 and continue to learn more from Q1. I'm not a 'pro' c or opengl programmer, but now I can see more of how to do it. John C: Keep it up, we love you. I also like this discussion on cheating. Consider carefully the lasting effects of so many intelligent people working twords the objective of secured cheat-free gaming. Don't you think other game companies will pick up on what we learn from Quake today? I like pure gaming, and I think this will only help promote it and make it better.
------------------------ LordLobo - Because I can |
All this talk of huge scale cheating... (Score:1)
by Marlin (marlin@moonskin.spam.com) on Tuesday December 28, @08:05AM EST (#475)
(User Info) |
A few years back one of the universities in the states (Can't remember which one, can't find a url) had a code war, where people would write short programs that would try to kill the other program to be king of the hill. It'd be amusing if some group of people decided to do the same with deathmatches, two people with extremely hacked clients connect to a standard server and battle, whoever has the better code wins. :P
|
Re:Cheating is a Good Thing (c) (Score:1, Insightful)
by Anonymous Coward on Sunday December 26, @01:35PM EST (#29)
|
Cheating is bad because it destroys the community. Community is based on ideas like fairness and when you cheat you violate that idea. Cheating is good for people who do not want to live in a community, who are not able to use their own abilities and ingenuity. In short a cheater is lazy and care not for the good of others.
|
Re:FINALLY A DECENT ARTICLE POSTED! (Score:0)
by Anonymous Coward on Sunday December 26, @02:05PM EST (#70)
|
Amen.
|
| |
AAAAAAAAAAAAAAAAAAAMEN (Score:0)
by Anonymous Coward on Sunday December 26, @04:20PM EST (#213)
|
AMEN! AAAAAAAAAAAAAAAAAAAAAAAAAAMEN! AMEN!
|
Re:FINALLY A DECENT ARTICLE POSTED! (Score:0)
by Anonymous Coward on Sunday December 26, @02:06PM EST (#72)
|
Naturally because we all know that closed central command based systems are more efficient and less corrupt than open democratic ones. Without the high preists of the software industry to protect the average consumer what will stop the complete destruction of personal sovereignty and individualism. MS uber alles!
|
| |
Re:FINALLY A DECENT ARTICLE POSTED! (Score:0)
by Anonymous Coward on Sunday December 26, @03:41PM EST (#168)
|
MS more uber everything? I guess babelfish doesn't speak nazi german.
|
Why Closed Source Is Uncrackable! (Score:3, Funny)
by chromatic on Sunday December 26, @02:15PM EST (#82)
(User Info) http://snafu.wgz.org/chromatic/
|
That's right. We all know that closed source projects like Diablo, Ultima Online, and IIS 4.0 are secure and uncrackable. Thank goodness for software like Windows 98 and Windows 95 which are immune to BackOrifice due to the superior protection of Security through Obscurity. Can you *imagine* if someone like Alan Cox or Theo De Raadt had access to the source code? I mean, he might spend upwards of two hours fixing the security holes. That is plainly unacceptable. It is a very good thing that reverse engineering and hex editing and asm disassembly are impossible and illegal, not to mention packet sniffing! Otherwise, our panacea of Ivory Tower software development might show some cracks. Now if we can just rid the world of Computer Science classes and books, we can all hold hands and dance around. Huzzah!
--
Thoughts on the Revolution |
I AGREE (Score:1)
by knightx on Sunday December 26, @02:44PM EST (#123)
(User Info) |
IM JUST CONFUSED AS TO WHY THE PEEPS AT SLASHDOT HAVEN'T MODDED IT YET :-)
|
Thank you!!!!!!!!! (Score:0)
by Anonymous Coward on Sunday December 26, @04:08PM EST (#198)
|
Excellent post, and of course it was moderated down. I am so sick and fucking tired of hearing about open source this, open source that, blah blah blah. This situation shows why Linux is such a complete piece of utter dogshit. This will be the final nail in the coffin. I pray each night that God will smite all fucking open source users. Open source is not just anti-business, it's anti-Christian. You fuckers will pay for it in the afterlife, better believe it. He who laughs last ..
|
| |
Revelations (Score:0)
by Anonymous Coward on Sunday December 26, @08:26PM EST (#332)
|
Damn straight! You better believe it! When the shit hits the fan this New Year's Eve, all those heathens who do not follow Christ and don't promote closed, proprietary, slash-and-burn capitalism will be taking the Expedia Express straight to *Hell* (rumored to be near Seattle). Thank God for Christians like Trent Lott, Bill Gates, and George W. Bush who will be there to lead us in the *Afterlife*.
|
Re:FINALLY A DECENT ARTICLE POSTED! (Score:0)
by Anonymous Coward on Sunday December 26, @04:16PM EST (#208)
|
What the hell are you reading Slashdot? It seems you might be more interested in non-free software (i.e microsoft.com). Free software is about giving freedom to users, in the case of games, that freedom means the ability to cheat, which is a problem, and as specified, has solutions, and involves bad design of protocol.. If you want to be limited, feel free to be non-free...
|
Re:this is why (Score:0)
by Anonymous Coward on Sunday December 26, @04:39PM EST (#227)
|
We'll shortly all be seeing the death of open source once the bubble bursts. Everyone will be so glad that there is closed-source stable software out there! John's doing the right thing by closing the source. I had my doubts about even allowing gaming software to be open source. It doesn't make sense. The developers/creative artists put too much time and effort into it to make it available to the non-innovative open source copyists. 'Nuff said.
|
Re:Cheating is a Good Thing (c) (Score:0)
by Anonymous Coward on Sunday December 26, @05:02PM EST (#248)
|
Because it lets dorks like you have an even chance at the hand/eye coordination thing that would have killed losers like you off 300 or so years ago. it is technology/modern medicine that lets people like you continue to breath/live/breed... Evolution has stopped for the human race. Any half-brained loser can now reproduce inferior offspring in this day and age.
|
| |
Re:Cheating is a Good Thing (c) (Score:0)
by Anonymous Coward on Monday December 27, @02:55PM EST (#456)
|
| Any half-brained loser can now reproduce inferior offspring in this day and age. You're certainly living proof of this! (Give my regards to you're parents!)
|
Re:THE BEAUTIES OF OPEN SOURCE (Score:0)
by Anonymous Coward on Sunday December 26, @11:26PM EST (#365)
|
Haha. You are from AOL. AOL shift key(s) keep(s) getting stuck, and because of that, AOLers are so easily viewed to be the senseless morons they really are.
If you had left shift off, you might have been able to masquerade as a non AOLer, and perhaps someone else might have read your post.
|
Posted by CmdrTaco on Sunday December 26, @01:04PM
Open Source Quake Causes Cheating?