How to restrict access to scripts?
by Alexei Chupyatov · in Torque Game Engine Advanced · 09/17/2006 (5:22 pm) · 18 replies
Sorry for the noob question but the FAQ doesn't address this subject nor did I find an answer in the docs.
From what I uderstand, scripts can be later accessed and modified, even when the final product is built and released. This would be fine if it was an open-source project, but for any kind of commercial product that is unacceptable. Is there way to prohibit any and all modifications by the end user to the code? Would I have to test everything inscripts and re-write it later on C++, or is there an easier way?
Thanks
From what I uderstand, scripts can be later accessed and modified, even when the final product is built and released. This would be fine if it was an open-source project, but for any kind of commercial product that is unacceptable. Is there way to prohibit any and all modifications by the end user to the code? Would I have to test everything inscripts and re-write it later on C++, or is there an easier way?
Thanks
#2
09/17/2006 (10:00 pm)
@JC: Not sure why you think loading .dso files increases--if anything, it will decrease them assuming you don't ship .cs files, because .cs files would have to be byte code compiled.
#3
Nothing you can do will keep your game logic secure if you give it to a client, but distributing just DSOs will make it easier to hide it.
09/18/2006 (1:14 am)
Loading compiled script is MUCH faster than compiling it on the fly - the feature was added so that Tribes 2 (which was heavily scripted) would load faster!Nothing you can do will keep your game logic secure if you give it to a client, but distributing just DSOs will make it easier to hide it.
#4
09/18/2006 (8:15 am)
J.C. was saying "increase your load times", but probably meant "decrease" or "improve".... as in "increase the quickness of loading".
#5
If you mean this literally, then no there isn't. Just to emphasise Ben's point "Nothing you can do will keep your game logic secure if you give it to a client...": this does include rewriting it in C++, or taking any other measure you care to name. You can certainly make it harder to break, but you cannot make client code completely secure.
However, if you just mean "Is there a way to discourage people?", then distributing just the DSOs would work well.
09/18/2006 (4:31 pm)
Quote:Is there way to prohibit any and all modifications by the end user to the code?
If you mean this literally, then no there isn't. Just to emphasise Ben's point "Nothing you can do will keep your game logic secure if you give it to a client...": this does include rewriting it in C++, or taking any other measure you care to name. You can certainly make it harder to break, but you cannot make client code completely secure.
However, if you just mean "Is there a way to discourage people?", then distributing just the DSOs would work well.
#6
Thanks for the answers all. This maybe not the chattiest forum I've ever seen, but it's the fastest I've ever got an actual response :)
BTW, I keep seeing the references to the book and such, aside from the "general" TSE doc, is there something else? Like tutorials (I got the water and the standard one) docs etc. Like guide to generating landscape, how the landscape is stored, how to reference the player's pos to the landscape type (in case you want his options to be dependent on the type of landscape i.e. slower in the sand, or mud, faster in the plains) I do realize that these are noob questions and they have probably been asked time and again. So maybe there is sense to pin the answers to the forum's top? Or create a FAQ or WIKI? Dunno, just a suggestion.
09/19/2006 (4:14 am)
Well in DSOs from what I can tell you can even see the variable names in plain text. So running a simple decompiler and... But perhaps there are some programming practices that can help to "discourage" people from doing that? I do realize that if someone is determined enough he will get in. The goal is IMO to weed out the dumb ones (which are about 80% of that public) and make it not worth the time for the others. Thanks for the answers all. This maybe not the chattiest forum I've ever seen, but it's the fastest I've ever got an actual response :)
BTW, I keep seeing the references to the book and such, aside from the "general" TSE doc, is there something else? Like tutorials (I got the water and the standard one) docs etc. Like guide to generating landscape, how the landscape is stored, how to reference the player's pos to the landscape type (in case you want his options to be dependent on the type of landscape i.e. slower in the sand, or mud, faster in the plains) I do realize that these are noob questions and they have probably been asked time and again. So maybe there is sense to pin the answers to the forum's top? Or create a FAQ or WIKI? Dunno, just a suggestion.
#7
There's a wiki as well, tdn.garagegames.com, although it doesn't have everything in it... yet.
09/19/2006 (10:12 am)
Well, the books are pretty darn useful if you're new to all this. The next biggest resource is the engine itself - the Player class actually implements just that, so you could probably crib off of it. :)There's a wiki as well, tdn.garagegames.com, although it doesn't have everything in it... yet.
#8
09/19/2006 (10:32 am)
@Stephan: Obviously it was a typo. I threw it in at the end meaning to say that it will also decrease your load time. Meaning another plus.
#9
One obfuscation possibility that I've looked at in the past is the idea of combining DSO's with Torque's built-in support for zip files. You would need to modify the script loader so that it could take a zip feed instead of just a normal filesystem feed. The idea would then be that you zip up your tree of script folders into one big archive, and give it a misleading name like "heightmap.raw" or something. Wouldn't fool a determined, savvy person for very long, but it would probably put off the 80% you mention...
This *feels* like it should be relatively straightforward to do, but I haven't actually tried to do it. If you could make it work, then you could go further by rolling your own file format so that the obfuscated file doesn't just load straight up into WinZip - one simple option would be to wrap the zipfile inside a valid graphics file, so it looks like some obscure part of your artwork - if your code is hiding inside a valid bmp file called "perlin.bmp" or something similar, I think you've hidden it about as well as you can!
09/19/2006 (4:24 pm)
@AlexeiOne obfuscation possibility that I've looked at in the past is the idea of combining DSO's with Torque's built-in support for zip files. You would need to modify the script loader so that it could take a zip feed instead of just a normal filesystem feed. The idea would then be that you zip up your tree of script folders into one big archive, and give it a misleading name like "heightmap.raw" or something. Wouldn't fool a determined, savvy person for very long, but it would probably put off the 80% you mention...
This *feels* like it should be relatively straightforward to do, but I haven't actually tried to do it. If you could make it work, then you could go further by rolling your own file format so that the obfuscated file doesn't just load straight up into WinZip - one simple option would be to wrap the zipfile inside a valid graphics file, so it looks like some obscure part of your artwork - if your code is hiding inside a valid bmp file called "perlin.bmp" or something similar, I think you've hidden it about as well as you can!
#10
I know you're working on it, but right now it's simply not worth looking on TDN - searching the forums is a *far* more reliable way of finding something useful.
09/19/2006 (4:46 pm)
@BenI know you're working on it, but right now it's simply not worth looking on TDN - searching the forums is a *far* more reliable way of finding something useful.
#11
09/19/2006 (10:35 pm)
I have to agree with Wayne. While I like the documentation on TDN, the lack of comments and interaction there make the main site much more useful. Luckily TDN is indexed here which helps draw people to the articles there, but IMO right now I'd rather read a resource here at the main site. Because when I'm reading a resource here, if people have problems with it, or have fixes, improvements you can read them. There you can't.
#12
It's not everything but there IS useful stuff there!
(Edit: have you guys tried using the talk pages? There _are_ mechanisms here to help you along - obviously it's a very different world than the main site. :)
09/19/2006 (10:38 pm)
Unless you want to know about the profiler, or the memory manager, or Atlas, or TGB docs, or lighting system docs for TSE, or Constructor docs, or Adventure Kit docs, or information about unicode support...It's not everything but there IS useful stuff there!
(Edit: have you guys tried using the talk pages? There _are_ mechanisms here to help you along - obviously it's a very different world than the main site. :)
#13
TDN is nice, just wanted to give my input on why I think a lot of people still use the older system instead.
09/20/2006 (11:56 am)
Oh don't get me wrong Ben. I didn't mean there isn't good and useful information there. It's nice that the search function on the main site points you to TDN for those articles. I haven't noticed the talk pages in all my visits there. I'd guess a lot of people probably don't even realize they exist. TDN is nice, just wanted to give my input on why I think a lot of people still use the older system instead.
#14
09/20/2006 (11:59 am)
I hear ya - and on our end we should be investing more effort in making it friendlier to use, too, so I'm definitely not trying to assign blame for anything. Just want to make it clear that it IS being used and it DOES have some useful info in it. :)
#15
09/20/2006 (3:01 pm)
I guess my post does kind of imply that TDN has nothing of worth on it - mea culpa, that isn't what I meant. I just meant that the breadth and depth of information available on TDN is of a different order than what is available from searching the forums. I think this will probably always be the case, because Torque experts - GG employees and knowledgable users alike - contribute to the documentation base represented by the forums on a daily basis.
#16
09/20/2006 (3:26 pm)
And the good thing is that the search bar here integrates TDN results as well! 
#17
The other way (like it was mentioned before) using zip's with passwords.
09/21/2006 (7:34 am)
Alexei, have a look at Cryptainer resource.The other way (like it was mentioned before) using zip's with passwords.
#18
09/21/2006 (7:30 pm)
Thank you guys. 
Torque 3D Owner J.C. Smith
Whenever you are ready to release you can remove that flag and it will generate .dso files out of the .cs files. You can then remove the .cs files from the distribution and it will load the precompiled versions when the game is run (which will also increase your load times).