Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > Advanced MUD Concepts
Click here to Register

Reply
 
Thread Tools
Old 08-24-2006, 03:31 PM   #1
Rathik
Member
 
Join Date: Aug 2004
Location: Arizona
Posts: 35
Rathik is on a distinguished road
Send a message via Yahoo to 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?
Rathik is offline   Reply With Quote
Old 08-24-2006, 03:49 PM   #2
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Our upcoming game www.aeonfalls.com will use a java based client. All other clients will be disabled and illegal to use.
Hephos is offline   Reply With Quote
Old 08-24-2006, 07:59 PM   #3
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
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.
shadowfyr is offline   Reply With Quote
Old 08-24-2006, 11:25 PM   #4
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,301
the_logos will become famous soon enough
Quote:
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 is offline   Reply With Quote
Old 08-25-2006, 01:44 AM   #5
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,301
the_logos will become famous soon enough
Quote:
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
the_logos is offline   Reply With Quote
Old 08-25-2006, 04:08 AM   #6
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
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.
Hephos is offline   Reply With Quote
Old 08-25-2006, 04:32 AM   #7
Smith
Member
 
Join Date: Dec 2005
Posts: 33
Smith is on a distinguished road
Quote:
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.
Smith is offline   Reply With Quote
Old 08-25-2006, 04:43 AM   #8
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
Originally Posted by (Smith @ Aug. 25 2006,04:32)
8-->
Quote:
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.
Hephos is offline   Reply With Quote
Old 08-25-2006, 04:47 AM   #9
fire_phoenix
New Member
 
Join Date: Jul 2006
Posts: 3
fire_phoenix is on a distinguished road
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.
fire_phoenix is offline   Reply With Quote
Old 08-25-2006, 07:48 PM   #10
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Quote:
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 is offline   Reply With Quote
Old 08-25-2006, 07:58 PM   #11
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
[quote= (Hephos @ Aug. 25 2006,04:43)]
Quote:
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
shadowfyr is offline   Reply With Quote
Old 08-25-2006, 11:52 PM   #12
Brawndel
Member
 
Join Date: Oct 2005
Posts: 35
Brawndel is on a distinguished road
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.
Brawndel is offline   Reply With Quote
Old 08-26-2006, 03:53 AM   #13
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
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 is offline   Reply With Quote
Old 08-26-2006, 04:23 AM   #14
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
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 is offline   Reply With Quote
Old 08-26-2006, 04:36 AM   #15
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
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.
Hephos is offline   Reply With Quote
Old 08-26-2006, 04:38 AM   #16
Kylotan
Member
 
Join Date: Jun 2003
Location: Nottingham, UK
Home MUD: Abattoir (Smaug)
Home MUD: ex-Jellybean (Smaug)
Home MUD: ex-Dark Chambers (Merc)
Posts: 174
Kylotan is on a distinguished road
Send a message via ICQ to Kylotan Send a message via AIM to Kylotan Send a message via MSN to Kylotan Send a message via Yahoo to Kylotan
Wrong. In many countries, not only is it legal, it's actually explicitly protected.
Kylotan is offline   Reply With Quote
Old 08-26-2006, 04:50 AM   #17
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
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.
Hephos is offline   Reply With Quote
Old 08-26-2006, 12:50 PM   #18
cratylus
Banned
 
Join Date: Feb 2006
Posts: 153
cratylus is an unknown quantity at this point
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
cratylus is offline   Reply With Quote
Old 08-26-2006, 01:53 PM   #19
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Quote:
Originally Posted by (cratylus @ Aug. 26 2006,12:50)
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
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.
Hephos is offline   Reply With Quote
Old 08-26-2006, 04:24 PM   #20
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Quote:
Originally Posted by (Hephos @ Aug. 26 2006,09:53)
Quote:
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?)...
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.
KaVir is offline   Reply With Quote
Reply


Thread Tools


Beyond Telnet - Similar Threads
Thread Thread Starter Forum Replies Last Post
Why not exploit the telnet protocol? erdos Advanced MUD Concepts 53 05-16-2012 01:00 AM
Java Telnet Applet Crystal MUD and RPG Webmasters 3 03-19-2008 09:42 AM
Telnet Options? Raewyn MUD Coding 1 02-05-2006 10:58 AM
Telnet Negotiations Khadgar MUD Coding 6 01-09-2006 10:02 AM
Cant type in telnet window! Chobbie Newbie Help 2 07-17-2002 03:38 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 07:48 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014