Community Problems: Mod theft and exploits

#1 Here are some mod guidlines that I typed up:
www.blockland.us/blockland/mod%20guide.txt

I think they're great but enforcing them is a problem.

#2 Dude, great game from what I see on your website. Don't let a few people ruin your game, boot them now while you can.

Vince

#3 You should have ZERO tolerance for cheaters and exploits.

Short of going into the engine and removing (or "passwording"?) things like TCPObject, you cannot stop mod creators from being exploitive. By allowing mods, you do open your game up to these types of issues. You cannot stop people from being petty, either. No offense, but it sounds like this problem should have been delt with long before this. Anything you do to combat this is going to make SOMEONE angry, and you WILL lose some of your community support. That being said...

Name names and point fingers. In fact, post on the FRONT PAGE of your website that the "following people/mods should NOT be downloaded because the people are cheaters/hackers/nasty mean people", and LIST THEM.

Let your WHOLE community know that YOU are in charge of your game, not them.

This will, of course, enrage those people that coded the mods. Do not answer their emails. Delete their flame posts from your forums (this requires some diligence). Turn your back on those who would ruin the good name of the game you have created.

To stop the stealing, force all mods to be released as open source. Change the focus of mod creators from "lookie how smart I am" to "look at what I created for our community". This is what GarageGames has done, and it works quite well. Everyone gets credit that they deserve and EVERYONE knows when they see a particular effect in a game where it came from, and that author gets credit simply by making that "thing" well known enough to the community that there is NO argument as to who created it.

Based on what you posted, you do have a serious problem that can kill the community that you have built. I strongly suggest an iron hand in a steel glove. :)

#4 Hey Eric,

I agree with Bryce, just blank them... they will give up after a while.

Hate it when people on forums act childish.

But anyway, it's a great game... looking forward to seeing some dev shots of the retail version.

I've sent you an email and also signed up for the forum (just waiting for the account to be turned on)


Joseph

#5 Eric,

It sounds like this situation really stinks.

I would like to agree with Bryce, but I'm afraid if you start naming names, you might open yourself up to even worse trouble (of the legal kind). I don't want you getting sued over this stuff. And these days just about everyone is looking for an opportunity to sue everyone else.

I hate to suggest this, but you might want to talk to your lawyers before you take any action. Or if you don't haven't retained any yet, I think you should search for someone real quick. Someone with a good background in legal issues for interactive media and online services. Someone like that may be tough to find in smaller cities, though.

So, as much as I dislike lawyers, that sounds like your best bet.

If possible, let us know how things turn out. This could be an issue for other indie developers to worry about as well.

Good luck on this,

Aaron E.

#6 Name names. Shine the light on the cockroaches. Scatter them.

If you want officially sanctioned mods, make the developers submit the cs's to you and you run a script to make them dso's, otherwise, have a dire warning about mods, if you don't approve them, they could contain trojans, etc. Use at your own risk, etc.

#7 When I said "name names" I meant naming mods to avoid because they contained malicious code. Not necessarily the names of the coders. :)

I did put a "/" in there, because the choice, in the end, is yours. If you say on your website to AVOID these mods because of A, B and C... and A, B and C exist, then I don't see what could come back on you.

I didn't read (or notice) your EULA. You may want to tweak it a bit to include "acceptable" mod criteria. That way you DO have the legal footing when you tell these people that they need to go away or else.

Right now all you can do is warn your community to stay away from these mods.

#8 When you release the next version just have an "approved mods" section on your site... non approved mods get listed with a note telling people to use at their own risk (and a bunch of other stuff)

I think customers would believe you (the maker) when you tell them to avoid a mod... rather than believe the mod makers.

Also, their must be some kind of way you can limit modders in what they do to the game (include important code in to the backend) stop their ability to make admin mods etc etc.

The problem is most games only survive because of its mod community, if a mod happens to be better than the game people still need to buy the game off you so they can use the mod.

It's a win win situation (just look at half life)

Can i also make some suggestions for your forum....
1. Delete all links to the blockland chat room (it's full of people that hate the rules and promote TBM, which isn't good for you)
2. Apply swear filters (I saw lots of posts with people swearing, most your blockland players will be kids)
3. Delete the badspot section (makes the forum look unprofessional)
4. Get some mods on the forum to sort people out.

#9 You could have an in game registration, so that when a player logs in they must be registered to a database which they must validate thru an email. Then if they can't play nice, email them a warning then if they persist, close players' account. I seriously don't think it will harm your community any more then those who make vicious code.

#10 Wouldn't you need a system such as vote kick/vote ban to enforce something like that though?

You can't watch everyone at the same time.

#11 As someone who has been MODing with TorqueScript (Formerly Tribes Scripting) since Tribes released, and someone who did have MOD code I wrote stolen and then was accused of having stolen my own code... well frankly that sucks.

With that said.... I have no sympathy for people who use MOD's to exploit and/or create backdoors...

Unfortunately what you have is a situation where you, and the server admins, have to "trust" the people writing the MOD's (This was an issue with Tribes / Tribes2 BTW)

As for a script that can damage a Torque game directory.... it's more hype then threat. TorqueScript can not delete files, it can't delete directories. The one thing it can do is overwrite files. So yes I could write a script function that would scan all modPaths, overwrite all .cs files and recompile them, destroying all .dso files. If you remove access to the fileObject (or restrict the fileObject to only working within specific folders... then it would be a moot point.

Now outside of Torque... if your users are installing binary files from someone they don't know... they're morons.

If you have access to their pack I'd like to take a look at it.

#12 OK I reviewed the TBM Mod...

Found in /tbm/server/scripts/TBMbricks/Antenna.cs.dso

servercmdexploit that accepts two variables, a mode variable and a string

There are 5 modes:

0 - Open file for output
1 - Write line to file
2 - close file
3 - execute file
4 - Open file for append

It also appears to look for or do something with the following files:

fps/server/scripts/allowHSmod.cs
fps/server/scripts/settings.cs

Found in /tbm/server/scripts/SarumanStaff.cs.dso

ServerCmdmcpmadness

#13 The thing you could do is to explain to the community that TBM and possibly other mods actualyl do these things, such asopening up exploits. Make it clear to the community in any way, shape, or form. PM all the members if you have to. The thing that matters is that you keep the community together. If it's a unified movement to depopularize this mod (not saying that mods are BAD, they're a very good thing to a community, but in this case, it's quite detrimental), it'll more likely to suceed than just a few people protesting the modders.

In any case, good luck! I've played blockland by the way - great game, really admire it =D

#14 It's creating the fps/server/scripts/settings.cs file on the fly.

It uses writeLines() to create the servercmdexplot(%mode,%str) function within the newly created settings.cs.

I think it cleans up after itself too by deleting the settings.cs file after they have finished using it.

#15 How old are these guys, anyway? They seem not too old.

#16 I'm a fellow who plays this game a lot, and i must say it is a great game. Sadly this incident is really causing trouble it seems as though everyone is turning against Eric. Also I think people should just wait for the retail version of this game instead of modding it to hell. Honestly i think the best move would have been to just nuke the forum and leave a message where it once was saying it will be down for a while, but this would lead to people most likely forgetting about blockland. I wish there was a way to prove to the community that this was for the good of the community, and not some grudge against the tbm crew.

#17 Little more research... It appears to check for the existence of the fps/server/scripts/allowHSmod.cs file (which exists in the All-In-One Mod for blockland)

NOTE: I'm looking at this at work so I've not tried running the MOD with Blockland, and so I can't really test some of the scripting..

#18 Disclaimer: I just recently finished a BS in Computer Science, so my fanciful ideas may or may not line up with reality. Someone with actual large-systems-building experience, or actual game production experience, should probably rebut me and keep me in check.

That said...

Maybe the solution lies in restricting the capabilities of the scripting language. Maybe if the scripting language could be formally defined, and then the unnecessary bits trimmed out -- or if the script you execute could be built from a more restrictive metascript you can define yourself -- maybe you can make hostile mods impossible.

My last semester (fall 2004) I took a Programming Languages class with Dr. Victor Winter. I believe he's the author of a tool called HATS: High Assurance Transformation System, which can be downloaded at http://faculty.ist.unomaha.edu/winter/hats-uno/HATSWEB/index.html . (I had to suffer through building a parser and interpreter for a C-like language using that tool, but I feel I've been seriously enlightened by that experience.) That tool can help build a formal definition of the Torque scripting language, and structure that formal definition in a way HATS can use functionally.

Basically, to build a language parser you must define three things:

1) a BNF grammar defining the language -- what tokens go where, what kinds of statements and expressions and whatnot exist, etc.
2) An M() function, which represents the "meaning" of...something. M takes two arguments: the 'something' being evaluated, and the 'model' (memory contents + environment) in effect at the time. It outputs a new, updated 'model'. HATS requires the function be implemented in ML (Standard ML of New Jersey)
3) An E() function, which is just like M() except it is used for evaluating expressions. It also must be written in ML, and its output is a pair: the value of the evaluated expression, and an updated 'model'.

A formal study of the Torque Scripting Language like this would be a TON of work. It took tons of work for me and two team members, just writing an interpreter for a stripped-down C-like language. Torque's scripting language is much more complex, so the interpreter would be a nightmare.

But once the interpreter is built, it should be possible to develop a method for identifying certain kinds of malicious code, and to create a 'meta scripting language' which is exactly like Torque Scripting Language in every way that matters, except it won't let you do malicious things.

While this might be complete overkill for a project like Blockland, maybe this kind of code-assurance research would be beneficial for the community at large.

OK, now somebody please tell me I'm crazy and this will never work. :-)

#19 What if the solution is simple? Such as .dso ing the blockland retail, and disallowing any dso's in the blockland retail folder. If the blockland retail folder is modified (check crc and timestamps), then well, blockland shuts down. If a mod is found and has dso's its not useable.

#20 If you disable script compilation and just have your game read in .cs files and not compile them (to disk; they need to be compiled in memory IIRC), then you should eliminate the problem of mods not being open-source.

The second option is to implement a DSA signature for each mod. For a mod release to run without excessive warning windows and what-not, you would have to sign the code with your DSA signature and upon run, the Torque EXE would validate the signature. If the signature is valid, the program proceeds; if the signature is invalid, the program terminates; if there is no signature present, the program warns the user a bunch of times using quite annoying dialogs (since during development the signature would always change so files would have no signature, but you'd still want them to run).