Top Mud Sites Forum

Top Mud Sites Forum (http://www.topmudsites.com/forums/index.php)
-   MUD Coding (http://www.topmudsites.com/forums/forumdisplay.php?f=9)
-   -   MUD Anti-cheat (http://www.topmudsites.com/forums/showthread.php?t=4325)

lovechiefs 05-13-2007 10:25 PM

Hey guys
Before I write the main post,let me first put two disclaimers:

1. I am posting this here, because I think it belongs to coding. Feel free to move the thread if it doesn't

2. I am a member of two anti-cheat communities and head admin of one for Americas Army and True Combat Elite, so I am interested to see what type of security other games have

I was wondering what type of anti-cheat software are MUDs using.Also,do you guys use ban lists

Zeno 05-13-2007 11:21 PM

What exactly do you mean by "cheat"?

the_logos 05-14-2007 01:45 AM

If you're interested in game security in general, let me recommend Steven Davis's blog at Playnoevil.com. It is easily the best blog on game security in the world.

--matt

lovechiefs 05-14-2007 09:22 AM

What I am talking about is what type of software if any,MUDs are using to prevent hacking/cheating in the realms

KaVir 05-14-2007 11:18 AM

Protection against things like hacking and denial-of-service attacks is likely to be handled by the hosting provider (protecting the entire machine) rather than the individual mud.

Cheating prevention is going to be handled on a case-by-case basis, as part of the mud itself - if you don't want players to do something, you either modify the code so that such an activity isn't possible, or you set up a rule threatening to punish those who perform said activity.

lovechiefs 05-14-2007 11:55 AM

So no one is using a software such a PunkBuster, Valve and such?
Anyone thought about maybe using something similar?
I haven't seen any hacking that i know of,but I am sure it exists.Just basically wondering what a MUD game is doing differently or similarly to graphic MMOs and FPS

Aeran 05-14-2007 11:57 AM


Valg 05-14-2007 01:01 PM

Generally speaking, the more you broadcast about what measures you use to detect and prevent cheating, the easier you make it for people to circumvent those measures.

Zeno 05-14-2007 01:17 PM

There is no point. I'm pretty sure it's impossible to hack a MUD. Hacking the server on the other hand is entirely possible.

lovechiefs 05-14-2007 01:20 PM

I am aware of that and I wasn't asking for specific info.My apologies if it sounded that way.

shadowfyr 05-14-2007 02:45 PM

To add my two cents in here. The rule where I play is, "No script or client can 'directly' send commands not initiated by someone who is not at the keyboard, *except* for those that only provide information between players. This means someone could "cheat" by doing it anyway, but they will eventually get nailed for it, since someone on the staff, or another player, will notice them doing something, try to talk to them, and find that they are being ignored (and not officially with the ignore command). This is a nuking violation. So is hacking someone's passwords or multi playing, both detectable by which IP is in use at the time and what sort of things they are doing while logged in.

As for trying to munge the data, so people can't trigger off it, I think that seriously stinks, doesn't work in the long run, and just ****es off the people that intend to do things like funnel some things to secondary windows, or do data tracking on their end, which has no direct interaction with the mud itself. Its the equivalent of telling people, "I don't care how clever you are or what you client can do, I don't want you displaying a MMO style inventory sheet on your own computer for the stuff you are wearing!" The obvious question, as with any such intentional derailment, is, "How the hell can you tell, and why the heck should it matter to you how I display that information?" The only answer is invariably, "Well, we want to make it 1% harder for someone that does botting to write their scripts. Umm, OK, and how is that stopping them at all? lol

After all, making the data harder to deal with doesn't solve anything, it just kills legitimate uses in some case, while making the bots AI slightly more complex. In the end, you are still going to have to watch for non-responsive people, who seem to be doing a lot of exping, etc., while never responding to your staffs questions to them. That is the *only* way, short of using a proprietary client, that you can catch them. And the later... isn't much use either. With something like Mushclient, the only difference between an Iron Realms client and Mushclient is figuring out the protocols they came up with to prevent someone using a non IRE client. Some people are fiddling with it and are about... 80% there already. Making the client-server interface more complicated only stops the most limited clients from circumventing things, it still doesn't "prevent" anything, it just makes it take longer to duplicate the protocols. In the end, its still someone at the machine trying to talk to a supposedly active player, who finds they won't respond to anything, that will "catch" people that cheat. If anything, the morons trying to hack the server/characters are *far* easier to detect than someone using the wrong client or running 5000 lines of script that doesn't send one single thing to the mud in a recognizable way that a player couldn't. Its still going to take trying to talk to them to figure out what is really happening.

the_logos 05-14-2007 03:39 PM

Yep.

?

We don't have any problem with people using 3rd party clients. At any one time, only about 40% of our players are using Nexus .

--matt

Kylotan 05-14-2007 03:44 PM

It uses a completely dumb client. Thus there is no need for any anti-hacking tools. There is no extra information to uncover, no walls to see through, no world data stored client-side, etc.

shadowfyr 05-15-2007 12:56 AM

Was using it as an example of how you could use a modern client to make a working protocol, without the server necessarily knowing the difference, not necessarily as one where this isn't intended. Point was, giving information on the protocol, or hiding it, doesn't matter.

Want a better example? A few years back MS added a mess of stupid nonsense to some web protocol and flat out stated, "Open source projects might be able to duplication one or two of these, but making it work with all of the changes would be nearly impossible." This genius statement was made as a selling point to companies that bought into MS hype, three days *after* a project for the Apache server released a *completely* compatible protocol implimentation, which supported *all* of the features MS had added. lol

shadowfyr 05-15-2007 12:59 AM

Only partly true. Some use proprietary extensions. Others use things like MXP, or compression, etc, which are hard to deal with if you don't have support for them in the client. But yeah, most of them you could play using a VTxx client for 1980s DOS, assuming you could tack a TCP/IP layer onto it to make it think it was talking to a COM port instead. lol

Kylotan 05-15-2007 04:15 AM

Even MXP and compression still pretty much fall into the category of 'dumb client', as they're just extra layers in the networking model as opposed to part of the game as such. I don't think people are sending information with MXP that isn't instantly displayed to the player, so there's nothing hidden to uncover with hacking tools.

shadowfyr 05-15-2007 10:46 PM

Well, in most cases yes. There are some extensions like that which do things like opening windows, displaying images, etc. that are *not* dumb, in the sense that they do nothing at all if the client doesn't know what to do with them. And that's all "security features" really do anyway, provide data that the client can't deal with without something else added to it. So, sure, 90% of the client is *dumb*, but claiming that parts are not would also make web browsers "dumb", since they display strait text quite well, using a fairly "dumb" HTTP protocol, and everything else is just "layered" over top. So, I am not sure where you draw the line exactly? Does it have to encrypt all of its data and display it throw some system that *can't* process pure text? What defines, "no longer dumb"?

scandum 05-16-2007 06:28 AM

A client can however gather and re-use information that is not otherwise available to a dumb client.

Automappers and graphical/VT interfaces are a good example of this. Most muds don't consider that to be a problem though.

Kylotan 05-17-2007 02:12 PM

You draw the line where the decisions are made and where the data is stored. FPS and MMO clients make certain decisions such as what is visible to the player, and often store terrain locally. They also often receive data that isn't instantly displayed to the player - eg. an enemy within 10m of the player but hidden behind a wall will still have its data sent to the client.

Opening a window or displaying an image is still the act of a 'dumb' client in that the client is still just a passive recipient of information which it feeds to the player. It's not deliberately hiding anything from the player, and it only receives the minimum required for presentation purposes. That's where they differ from clients for other games.

shadowfyr 05-17-2007 07:06 PM

Hmm, so what about some people's ideas for experimental muds, where ones "position" is determined just like in a MMO? But, ok, point taken. As a rule, most clients currently don't handle "invisible" data. Some could, if there was a valid reason to do so. For example, opening a window to display the *complete* inventory for a shop, with scroll bars, would make sense. Some of that data wouldn't be immediately visible, some might even be invisible until needed, if you used a tab system to separate "types", as some games allow.

But again, from the perspective of what most muds *currently* do, they often don't even support the most reasonable things in "existing" protocols, or even entire protocols correctly.


All times are GMT -4. The time now is 02:14 PM.

Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright Top Mud Sites.com 2022