[Rathik]

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?

[Hephos]

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

[shadowfyr]

Don't bet on it. Hmm..

[code] function OnPluginPacketRecieved
if <some Aeonfalls code> then
send "proper response"
return false 'Don't let client handle the line.
else
return true 'Clean non-server specific, let the client handle it.
end if
end function[/quote]

That lasted about 5 seconds. lol

Seriously. Something like Mushlcient, even if you stripped things down to UDP and built a special TCP/IP like system on top of that (some companies did that in the past for their systems) there is still the Simulate command: Sends data from the script to the client as though it was being recieved from the mud, for testing triggers and scripts. So, all you need at that point is a socket library and the script system that would support it. Lets see... Python? Yep. Lua? Yep. Others? Sort of, but you can't create threads in them to handle the inbound data properly, without locking up the client while waiting for the script.

But heh, good luck trying. You might actually scare off enough flexible client lovers, like myself, to avoid someone hacking the system the day after its implimented. lol If not, then its a "lot" easier to update a Mushclient plugin to handle new codes, then upload it to the net, than it is to completely rebuild both the clients and the server to disable the previous system, which did get hacked. I am not sure its really realistic now to try to prevent people using other clients, not without changing the system to such an extreme that its not even possible to identify the differences effectively, never mind code around them.

[the_logos]

Originally Posted by (Rathik @ Aug. 24 2006,15:31) 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?

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.

[the_logos]

Originally Posted by (shadowfyr @ Aug. 24 2006,19:59) I am not sure its really realistic now to try to prevent people using other clients, not without changing the system to such an extreme that its not even possible to identify the differences effectively, never mind code around them.

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

[Hephos]

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.

[Smith]

Originally Posted by (Hephos @ Aug. 25 2006,19:08) 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.

[Hephos]

Originally Posted by (Smith @ Aug. 25 2006,04:32) 8--> Originally Posted by (Hephos @ Aug. 25 2006,19[img http://www.topmudsites.com/iB_html/non-cgi/emoticons/wow.gif[/img]8)]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.

Yes thats what I am saying... On one hand it opens up for more possible users allowing any type of client. On the other hand that also opens up for trigger and bot abuse (among other things). So we're still considering both options, but are leaning towards only allowing our own client in a similar way that other muds make bots illegal (enforced by active immortals).

Then we have other problems. Our client includes game specific things that other clients will have a very hard time to implement (although a very fanatic person could probably do it ). That includes things like help files, map images and coordinates, character creation, mail system etc etc.

[fire_phoenix]

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.

[shadowfyr]

Originally Posted by (Hephos @ Aug. 25 2006,04:08) 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.

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.

[shadowfyr]

[quote= (Hephos @ Aug. 25 2006,04:43)]

Originally Posted by Smith,Aug. 25 2006,04:32 Our client includes game specific things that other clients will have a very hard time to implement (although a very fanatic person could probably do it <!--emo&). That includes things like help files, map images and coordinates, character creation, mail system etc etc.

Hmm.

1. That could be a problem, but not impossible, just not something you can just glue something on and have work. Then again, if someone wanted to do so, its not hard to have the script make an OS call and run the help file. You just need to get your hands on the file.

2. Trivial, as long as someone uploads the maps someplace, or they are (most likely) FTPed from the server. Though, right now there is insufficient GUI support in Mushclient to manage it. I am actually working on an add-in that would include a form designer and common GUI elements. With LuaCOM I don't even need to reinvent the wheel when using a COM bridge to get events from the controls and once you can make a window, add controls to it, then capture events, you are only limited by what controls you can create. Fact is, if I was willing to ignore half of the client's users and did it in .NET, I could have all those for free, including the designer (well, as free as needing to install the .NET framework).

3. Trivial.
4. Trivial.
5. Very trivial.

Next problem? lol

[Brawndel]

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.

[Hephos]

Originally Posted by (Brawndel @ Aug. 25 2006,23:52) 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).

[Hephos]

Originally Posted by 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:

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.

[Hephos]

Originally Posted by 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.

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.

[Kylotan]

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

[Hephos]

Originally Posted by (Kylotan @ Aug. 26 2006,04:38) 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.

[cratylus]

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
http://dead-souls.net