Are there any MUDs that have broke away from being telnet supportive? I'm not talking about MXP or mud clients-- I know most people use clients. I want to know if there are any muds that are impossible to use telnet on, and instead have either developed their own elaborate online Java client or require players to download a client to run their mud, etc. If yes, which MUD(s)? Or if not, have any of you MUD owners considered doing it?

Our upcoming game will use a java based client. All other clients will be disabled and illegal to use.

That's what graphical MUDs do, basically. Use protocols other than telnet to run communication between the client and the server. Telnet just happens to be a pretty limited, text-focused protocol.

It's worth considering that even Blizzard knew they couldn't manage to create a non-duplicatable client protocol and opted for the potentially very expensive route of using the DMCA. Unless I'm mis-remembering, WoW trivially encrypts 1 or 2 bits of every byte, letting them claim that anyone who made a client to supplant their own would be violating the reverse-engineering provision of the DMCA, and thus gaining the ability to sue the pants off offenders.

I suppose that's a viable strategy if you have the kind of money Blizzard (and their master, Vivendi Universal) has, but it's not feasible for small games companies.

I wish you luck Hephos, but it's a paradoxical situation: The only way you're going to be able to prevent other clients in the long run is if you have few enough players that nobody cares enough to hack protocol.

--matt

Well, it won't be that hard to detect users that use invalid clients (if we want to actively do it).

Simply add a new quick check that the server sends sometime during game play, and if the wrong answer is received a warning is sent to immortals. (This could be changed fairly frequently and without warning).

This ID check could be changed VERY SIMPLY from our side, but on the illegal client side the user would need to sniff up the code (to know what is sent) before they log in every time and change the code in their client, or face a chance to get detected and banned/deleted. On their side it will be a pain in the butt. But very easy for us.

However... i'm not so sure it is very wise to prevent other clients. We're still thinking about it. The main reason is to prevent triggers, bots and other boring things.

I do hope you are aware that you've contradicted yourself here.
Preventing triggers/bots and preventing other clients are virtually equivelent statements.

Those MUDs are all over the place. All 4 of the ironrealms come immediately to mind because they are the only ones I (currently) know. There are quite seriously dozens, even hundreds, of others though, I just haven't found/tried them.

One presumes that the clients needs to recieve the code, that it doesn't change over time (one that does could go out of sync real easy, but its not impossible) and that your making the laughable assumption that the client couldn't do what I already said, check every incoming packet for the data, then send back the predetermined code? Seriously, the only way I could see that working is if you used:

1. Server side seed code.
2. Server side scrambler.
3. Client side scramber.

Basically, the same you see in the bond movie involving GPS. A constantly changing, synced code, where both the code returned, and the code expected, change in a known way, each time you make a request for it. And that just makes it inconvenient, not impossible. As the_logos points out, this is basically like using an a DRM or encrption code, which would make it illegal under the DMCA for one person to solve it "then" provide others with that solution. But, is a mud "capable" of defending its DRM rights? Is it even worth it. If not, then your right back to, "All that needs to happen, is for one person the break the code." And all that takes is a proxy, which logs a sufficient number of responses for someone to derive the scrambler you use. I.e., anything from extremely trivial, to so complicated that the code to track both ends might result in the game lagging, on both ends, every time a request for the code is made.

Worse, I doubt you will have encyrption experts on this, so the solution might even "look" complex, but be breakable with far less code and way less effort. So no, any client able to catch the packets, parse them for requests, and send back the proper response *won't* be detected, no matter how random the requests. That was my point. And even if you changed it frequently, without warning, "the client" still needs to get the new code, so it knows what to respond with. If they captured the code when it started the first time anyway, that won't matter. In fact, even if you changed it so randomly that two days had the same code for the last 10 minutes of the prior play and the first five the next day, variables in Mushclient plugins are "persistent" across executions. Worse, all they would need to do is wait a significant span of time, like only playing every friday, to make sure that they got a new code every time they connected.

"Sniffing up" the code is so rediculously silly, in any context that you can guarrentee the players can get it at all, so as to render it either a) too rediculous and inconvenient for them to bother (like an email of the code for the day) or using some sort of automated sequence at start up, which is just as trivial to manage as send the code after you have it.

I really don't think you understand what some modern clients are capable of, using just their standard functions, never mind added libraries.

I might add to this discussion that there is a rather large player base of visually impaired or blind users of muds and the like, and switching to a non-telnet client solution would affectively ban all blind players. I must say that it is rather agrivating to find a mud, get really excited about playing it, and then find out that you must use a provided (completely unaccessible) client... Grendel's revenge comes to mind.:(

Well there aren't really THAT many blind players playing text based games (or is it?)... Not enough to make it worthwile coding a custom client for a particular game for it.

Anyways I had the idea earlier to include some sort of feature to make a mud client that was aimed towards blind people. A generic client for any (telnet) mud. Was looking around if it was possible to get any kind of financial aid to produce one of those but couldn't find any. It just has to be somekind of place you can get aid from if you make free products aimed towards handicaped people... At least in our country (Sweden).

Ehmm... Of course the id checks will change over time. Every time we update/patch our client or reboot our game for example. Our users cannot log into the game with an out of date client.

We simply send a single string encrypted on the server side that will be sent to the client any time during game play (random).

The client will hold the decryption key hardcoded and will send a respons immediately as it receives the key.

If no respons is given or the wrong one, a warning will be issued to the immortals of illegal client activity.

Now, of course a user that wish to emulate the client can check every incoming data and try to find out which is the client id key. Then send back the correct decrypted string.

But in order to do that they would need to do this (EVERY DAY before they log in with their illegal client *every time*) Or at least every time they can figure out our client has been patched/updated (which happens every day):
1. Decompile the client to find the decryption algorithms or keys. Or start the client and read every incoming data and figure out when the encrypted code is received and then work out the decryption for their own client (the code is sent random and could take hours to find it).
2. Recode/update their own client with the new id checks.

If more than one person would use the illegal client, it will be a mess for them to make sure people do not log into the game with an out of date client, and get banned/deleted/whatever.

For us, this would be very easy, we can update both the server and client with new encryption keys very easily. We can also change the whole client id system, or add smaller checks that are fired at certain times without any problem whatsoever. On our side its a <5 minutes work.

The id checks don't need to be triggered when the client is started. It could be sent randomly. It doesn't need to be sent very often.

We can also make so that it is only sent when an immortal issues a command to scan for illegal clients.

They would need to decompile our software to figure out what to respond with. Which isn't really legal.

Wrong. In many countries, not only is it legal, it's actually explicitly protected.

Well i'm no lawyer. It will be against our end user license to reverse engineer the software.

Nonetheless, it will be a hassle to decompile our obfuscated binaries to figure out the encrypted id checks everytime you wanna start your illegal client.

My first question is, what are you solving with this approach?
What problem is fixed by forcing people to use your client?

I can tell you that I'm personally going nowhere near a
precompiled binary some mud admins cooked up and try
to make me run. The security implications of running such
a program, designed with the kind of planning I've seen so far,
are just an insurmountable object for my adoption.

Is there a purpose to forcing the exclusive use of your client,
other than a sense of control?

I would also comment that not only do you discourage
new players with such a hostile approach, you also are basically
challenging every clever coder out there to figure out some
way to defeat you. I think that no matter how
smart and clever and dynamic your defenses are, your efforts
to prevent the use of anything but your own client will
be foiled by someone more determined to make you look
silly. And the hackers have all the time they need to
figure it out, and they only need to defeat you once per
each client update you make.

Personally I think it's a horrible waste of time and energy to
do this, except maybe as an academic research project. If
what you're actually trying to do is run a game, this
just seems counterproductive to me. What's wrong with
letting people use their favorite mud client? What do you gain
by trying to ram your client down their throats?

-Crat

Why we would enforce our own client as only option:
1. To prevent things we don't like in other clients such as scripting, triggers, bots (to make the list short).
2. To make players use the same software and have the same "basic" tools available. Rather than having heavy scripting doing the playing, you should do it yourself.
3. Get a "sense of control" as you put it.

The reason we would NOT enforce our client as only option:
1. Might loose a bunch of players that wouldn't use anything but their particular mud client.

Horrible waste of time? As i said, this "client check" is a 5 minute hack on our side (or probably less). Its a terrible much more work on the "hacker" side trying to continually update their clients as we daily patch our software.

It all boils down to if we want to enforce our own client or not. At the moment, we're probably going to do so. It is a TERRIBLE amount of work to get our game working for any standard mud client. The game is build upon a custom client GUI and it isn't going to easily be working with any general telnet implementation.

It depends what you mean by 'many'. I've encountered quite a few, and several of my regular players are blind. It makes sense if you think about it - blind people can enjoy roleplaying games just as much as anyone else, but when it comes to computer games they can't see the graphics.