Lots of people were just waving their hands saying "Netreck solved this years ago" without being specific.
There have also been other messages in the previous story offering other details. If you want more details mail off to vanilla-list@us.netrek.org. It is the list where the current Netrek server development team discuss the server. There are plenty of people there that can answer your questions offline. James Cameron is the current codebase head. Dave Ahn is the current res-rsa code maintainer. I can get you the res-rsa crypt key if you can prove to me you're a US citizen using the code for netrek, etc.
Couldn't someone get a blessed Netrek client, figure out what it sends to the server to authenticate itself, and then do a replay attack
It is security through obscurity, but the obscurity is the private half of a client's RSA key.
It is a challenge-response type of authentication. On top of that, the challenge is random and both the challenge and response are encrypted. Doing a replay attack would give the response to the wrong challenge.
I still think the only way you can guarantee that an OpenSource network game doesn't have cheating is to use a thin client approach.
Well that's essentially how Netrek works. In Netrek, the server handles ALL game mechanics and lays down the law as to what each player and weapon can and can't do as well as doing all the data hiding and deciding exactly what each player can and cannot see. The client is essentially a display engine and a user input packager.
However you can still cheat with that. You can make a client that will play the game for you (which is fun in its own right). You can do things like auto-aim, auto-shields, auto-dodge. You can also be an info-borg. An info-borg is a client that displays or makes obvious various game events and states that a good player knows how to look for and/or estimate. Examples include showing everybody's speed and true direction on your display, showing cloaked players on your tactical display, noticing a player with kills orbits a planet, and that planet's army count drops and flagging that player as a carrier, etc.
You can probably make it harder by doing some sort of authentication method, or make the players download the client from the server every time they want to play. Its a cat and mouse game.
At any rate, I like the existence of borgs on servers that allow them. In college, I used to be involved in running State and National Programming Contests at UTexas' IEEE-CS student branch. Our games were not the standard ACM type (here are 6 programming problems, have at it). What we did was write a game meant for computers to play. What the contestants did was take 8 to 20 hours to write a program that would play the game for them. During the actual elimination tournament, the contestants weren't allowed to touch the computers. It was quite fun for all involved. Dave Taylor (ddt of id, Crack, and Transmeta) founded and ran the first couple of National contests. If you ever get a chance to compete in a contest like that, I highly recommend it.
This is not a new problem! Netrek solved this problem years ago. It was explained in the previous discussion on this,
But as I explained in the previous discussion, Netrek's authentication protocol isn't very Open-Source. It is similar to Carmack's closed-source pair of programs. We just rolled it in to the binary. Sure, it was developed by several people in the development team, and protocols and methods were discussed in the open, but who actually gets that source is controlled. Without it, you have an un-blessed client or a server that doesn't require authentication.
And as this message's sibling states, if someone was patient, very patient, enough to break through our 20 levels or so of obfuscation for ONE particular binary, how do we, the Key Maintainers, know that key has been compromised? We don't. Somebody has to notice and cry foul. That particular cracker would be smart to be as quiet and non-obvious as he can since each binary's obfuscation is different.
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?
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.
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.
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.
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.
JPL IS privatized. JPL employees are NOT Government employees. They are employees of the California Institute of Technology, a private university. In JPL's Prime Contract with NASA, JPL business has to be at least 80 percent NASA business.
Though one of my pet peeves with the signs is that while they ARE metric, they are actually afterthought conversions from US units. An example street speedlimit sign says:24 kph (15 mph). (Converted metric units from "round" US units)
but the passwords will be a problem: they are encrypted, and as SunOS and Linux use different encryption schemes.
Umm. No. I copy the encrypted fields back and forth verbatim all the time between Solaris box at work and my Debian distribution at home. As long as the usernames are the same (for the salt) you should be fine.
Slashdot Mirror
As in Wednesday is the middle of the work week. You're at/past the hump and its all downhill until the weekend.
There have also been other messages in the previous story offering other details. If you want more details mail off to vanilla-list@us.netrek.org. It is the list where the current Netrek server development team discuss the server. There are plenty of people there that can answer your questions offline. James Cameron is the current codebase head. Dave Ahn is the current res-rsa code maintainer. I can get you the res-rsa crypt key if you can prove to me you're a US citizen using the code for netrek, etc.
It is security through obscurity, but the obscurity is the private half of a client's RSA key.
It is a challenge-response type of authentication. On top of that, the challenge is random and both the challenge and response are encrypted. Doing a replay attack would give the response to the wrong challenge.
Well that's essentially how Netrek works. In Netrek, the server handles ALL game mechanics and lays down the law as to what each player and weapon can and can't do as well as doing all the data hiding and deciding exactly what each player can and cannot see. The client is essentially a display engine and a user input packager.
However you can still cheat with that. You can make a client that will play the game for you (which is fun in its own right). You can do things like auto-aim, auto-shields, auto-dodge. You can also be an info-borg. An info-borg is a client that displays or makes obvious various game events and states that a good player knows how to look for and/or estimate. Examples include showing everybody's speed and true direction on your display, showing cloaked players on your tactical display, noticing a player with kills orbits a planet, and that planet's army count drops and flagging that player as a carrier, etc.
You can probably make it harder by doing some sort of authentication method, or make the players download the client from the server every time they want to play. Its a cat and mouse game.
At any rate, I like the existence of borgs on servers that allow them. In college, I used to be involved in running State and National Programming Contests at UTexas' IEEE-CS student branch. Our games were not the standard ACM type (here are 6 programming problems, have at it). What we did was write a game meant for computers to play. What the contestants did was take 8 to 20 hours to write a program that would play the game for them. During the actual elimination tournament, the contestants weren't allowed to touch the computers. It was quite fun for all involved. Dave Taylor (ddt of id, Crack, and Transmeta) founded and ran the first couple of National contests. If you ever get a chance to compete in a contest like that, I highly recommend it.
But as I explained in the previous discussion, Netrek's authentication protocol isn't very Open-Source. It is similar to Carmack's closed-source pair of programs. We just rolled it in to the binary. Sure, it was developed by several people in the development team, and protocols and methods were discussed in the open, but who actually gets that source is controlled. Without it, you have an un-blessed client or a server that doesn't require authentication.
And as this message's sibling states, if someone was patient, very patient, enough to break through our 20 levels or so of obfuscation for ONE particular binary, how do we, the Key Maintainers, know that key has been compromised? We don't. Somebody has to notice and cry foul. That particular cracker would be smart to be as quiet and non-obvious as he can since each binary's obfuscation is different.
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?
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
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.
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...
Zeroeth Law paraphrased as "Do no harm to humanity," with the first, second, and third accordingly modified with the "and not violate the n-1 law"
JPL IS privatized. JPL employees are NOT Government employees. They are employees of the California Institute of Technology, a private university. In JPL's Prime Contract with NASA, JPL business has to be at least 80 percent NASA business.
Though one of my pet peeves with the signs is that while they ARE metric, they are actually afterthought conversions from US units. An example street speedlimit sign says:24 kph (15 mph). (Converted metric units from "round" US units)
Here are a few links for converters/strippers/buffers, etc.
http://feste.mae.cornell.edu/st reeter/md/elektor.html
http://www.stack.nl/~leon/spdif/
http://www.fet.uni-hannover.de/ purnhage/dat/spdif.txt
and
http://members.tripod.com/~Psych/co ax-ttl-md.html
all grabbed from http://minidisc.org
You can set that in your user preferences.
This is JUNE 1st, not April 1st. *grin*
> Wouldn't assembly language be "source"?
Yes, but not machine code. Not assembled assembly. Not object files. Just the human readable stuff that can't be directly executed by a computer.