Question about releasing a game

#1 Script files (*.cs) are compiled into *.dso files at run time. Just distribute the *.dso files only and it should work. But hang on to your original *.cs files because once compiled, there's no way to go back without the .cs

#2 I was thinking about that, it seemed like it would be pretty good.

How secure are the .dso files? Can they be edited easily enough? decompiled back into .cs?

I'm trying to keep this as secure as possible, the fact you can't compile the scripts into like, a .dll or something is the only downside i can see to this whole engine.

#3

Quote:But hang on to your original *.cs files because once compiled, there's no way to go back without the .cs

(emphasis added) :)

As far as I know they are very secure, but I've not tried to crack one to see.

#4 This thread might be of interest: [link]http://www.garagegames.com/mg/forums/result.thread.php?qt=18834[/link]

#5 The DSOs contain bytecode, not source. So they are very hard to understand.

In fact, there are a lot more tools and expertise out there to reverse engineer DLLs than DSOs... :)

#6 That said, it's also important to bring up that shipping with .dsos only will just slow down the hacking of your scripts : look at ThinkTanks, members of the community started producing custom content and mods without any form of backing from Bravetree just a couple months after release.
As is being regulary said around here, and elsewhere on the Net, security through obscurity is no security :)
Also, there is some string data stored as is in .dso files (variable names, functions and method names, etc.)

So yes, it obviously makes it harder to deciper the contents of the scripts, but there are quite a bit of people who are actually proded to hack stuff like that just because it's there to be done ;)

#7

Quote:As is being regulary said around here, and elsewhere on the Net, security through obscurity is no security :)

LOL, how do you explain Macs then? Full of holes that no one wants to hack because nobody would care.

Quote:is it possible to either encode or hide all of the script files in any way so they don't just sit there for users to edit and cheat in the game?

Releasing the .DSO's will slow things down a bit, but it's not gonna stop it completely. The number one way to eliminate cheating in online play is to make your code VERY solid and very secure. If you leave stuff hanging out al over, people will gobble it up and spit it in your face for fun. I wish there was an easy way for me to tell you how I find cheats before they even get compiled into a running game, but it's got a lot to do with experience and good coding habits. I can give you an example here....

function CapTheFlag::flagRecover(%client, %player, %flag)
{

	%team = %flag.team;
//
	%flag.canImpulse = false;
	%flag.sethidden(true);
	%flag.startFade(0, 0, true);
	%flag.carrier = %player;
//
	$Game.statFlag[%team] = "SAFE";
//
	%player.mountImage(FlagImage, $Armor::Slot::Flag, true);
	%player.hasEnemyFlag = "";
	%player.hasOwnFlag = "true";
	%player.hasFlag = %flag;
//
	%message = "\c4" @ $GTC_Pref_[%client @ "_BaseName"] @ "\cr has recovered the \n\c3" @ $Pref::Server::TeamName[%team] @ "\cr flag.";
//
	Print(ALL, Bottom, %message, 3, 2, ALL);
//
//
	%client.ScoreAward(3, "recovering your teams flag...");

}

That right there is a full blown cheat just waiting for someone to discover it. Can you tell why?

#8 I presume this function is being called on the server, by the server, with none of it's arguments being taken from a commandToServer?

#9 Is this a platform war thread?

Quote: LOL, how do you explain Macs then? Full of holes that no one wants to hack because nobody would care.

GG members are developing on the Mac platform too. Is there a thread here where we can discuss the differences between Macs and Windows platforms for development?

#10 Perhaps not but you could probably start one.

#11 Or one could encrypt key game data and save the encrypted data into a .cs that would be compiled into a .dso.

I have been working on a resource that would allow a developer to encipher/decipher any value via script, this could be used to encrypt things like a players password to be stored in a .pref or any other game data.

Hopefuly I should have a resource out shortly, just need to tie up some loose ends and hand it over to MRT for some functional testing.

-Ron

#12

Quote:Is this a platform war thread?

It was just a joke, no offense intended.


@ Ian...

Quote:I presume this function is being called on the server, by the server, with none of it's arguments being taken from a commandToServer?

As wacky as this will sound, that function works perfectly to the untrained eye. It works exactly as it was intended to and as it was scripted to do. That being said, you are correct. There is no way at all for ANY player logged into the game to alter that function or do anything that would cause it to fail or act differently than it currently does. BUT!!! It still has ONE major flaw that ANY player could exploit to cheat. All you need to know beyond that to find the flaw is contained in that function.


@ Ben

LOL, your answer could be taken the worng way at first glance....


Ned - "Is this a platform war thread?"

Ben - "Perhaps not but you could probably start one."

Start the thread? Or start the war? DOH!!!!

#13 Heh.

I saw this:

Quote:
Ned - "GG members are developing on the Mac platform too. Is there a thread here where we can discuss the differences between Macs and Windows platforms for development?"

Ben - "Perhaps not but you could probably start one."

So it made perfect sense to me.

#14 Ken, I saw it both ways actually. I knew what Ben meant, I was just making a joke.

#15 The answer to the above function flaw is that it scores the player without checking to see if he was the one who dropped the flag. In order to solve it you would just attach a variable to the flag called %flag.dropper and when the flag is dropped, set it to whoever dropped it, then when the above function is run it should be checked like so...

if(%flag.dropper != %player){ %client.ScoreAward(3, "recovering your teams flag..."); }

#16 If you are interested in securing your resources, scripts, et al I would recommend evaluating a resource packer such as UDE or rolling your own using ziplib. There are quite a few commercial variations on the market, one that I particularly like is MoleBox (http://www.molebox.com/) which costs $100 and the developer is very responsive to suggestions from users, e.g. recently added the ability to run from command-line which is required in a single step automated build environment to produce a final distributable without human intervention. Unfortunately MoleBox does not seem to enjoy co-existing with TGE and I haven't yet had time to figure out why -- it is probably because TGE is attempting some funky cross-platform file access.

#17 Of course, TGE can load zip files...

#18 Just out of interest, can it load password protected .zip files?

#19 Might be able to... If not, all the hard work is already done so I imagine you could hack it in without too much trouble. What do you hope to gain with the protected .zip?

#20 Placing the server (and/or common) code inside a password protected .zip would make it more difficult for others to read and/or edit the contents.