Has anyone Moleboxed a T2D game?

#1 I remember that there were problems with running script files (especially compiling dso's) from within molebox applications a while back, but I don't know if it is still an issue.

#2 Hmm. I just added my sound, graphics and effects directories to it (leaving the .dso files out of the box and got the same error.

I'll have a bit more of a tinker with it...

#3 They've offered to look at my game and see what's going on. I've just mailed them the current version (sans source ofcourse) so hopefully they'll be able to figure out what's going on :)

#4 Just wanted you to know that I find this post most interesting and am looking forward to see how this will work out!

#5 Ditto! I've known about molebox for a while and I've been wondering off and on whether I could use it with T2D

#6 What does Molebox doo??
(i'll look it up).

#7 It's a code-protection mechanism. it 'wraps' your sourcecode with a obfuscation layer to help prevent people from snooping/stealing your stuff

#8 I think it just wraps the compiled EXE and other files, not the sourcecode itself. Too bad it doesn't work on Mac or Linux :( That's why I'd use the encrypted assets resource or try to compile scripts into the EXE. Even exposing main.cs can be a security hole. Because it's possible to schedule your own script from that main.cs to execute after the game starts, and then dump all the game console functions and start using them etc etc. I don't know if anyone thought of that but I may or may not have done it to some closed source Torque2D games. That's why I compile main.cs into my EXE now. Molebox would prevent that too, and more. It would be an easy alternative to using encrypted resources.

#9 Hi Joe!
This is very interesting, could you explain a little more how to compile
the main.cs into your exe, I 've noticed that this is the only script that remains as
cs in my demo so I'm concerned too.

thank you.

#10 The way I've hacked it in the past (thanks to either a resource or a forum post someplace) is in game/main.cc around line 264, comment out everything from 'FileStream str;' down to and including str.close(); on or around line 294. Then I put:

char *script = new char[55];
   dStrcpy(script, "	setModPaths(\"main\"); exec(\"main/main.cs\"); onLaunch();");
   script[55] = 0;

after the close-comment (just before 'Con::executef(2, "eval", script);'). This loads my main.cs.dso file in a "main" subdirectory and executes the 'onLaunch()' function which is the entry point into my script. All other code originally found in the main.cs in the root directory is either removed if unnecessary or moved into main/main.cs.

Obviously change the setModPaths, exec and function call to your own versions, and remember to properly size the "script" character array to fit.

Between this and encrypted DSO assets using the encryption resource (and the aesstream extension), it should be moderately secure against the average tinkerer. There's more worth doing too, such as checking CRC/MD5 of the script files from the engine, and/or enforcing that the script files *must* be encrypted to load, etc. to make sure someone doesn't swap out a .DSO on you.

#11 @Joe: You are correct, it is a wrapper around your .exe and supporting files.

i mispoke when i said it was around your source code.


and fyi, this is pretty easy to do using .net... tho i guess molebox isnt too expensive anyway.

#12 @Jason - I just started working with .NET, care to elaborate, or even a TDN article or resource?

#13 @Jason
If you can do it with .NET that's pretty interesting.. because Mono is cross platform and eventually it may allow that same technique to be used on Mac and Linux.

@Adam
I didn't try what Luke said, that's too confusing for me :) I just took main.cs and threw it into a const char * inside the exe. Then I replaced the calls to execute main.cs when the engine starts with a call to my string buffer. It was mentioned somewhere in another forum post, I don't have the link.. Sure there are more ways to add security but I'd say main.cs is the most obvious problem. I'm sure you can do this with other scripts too.

If you want you can just copy and paste this in your main.cc :

#ifdef SECURITY_LOCKDOWN // I use this preprocessor flag to turn it on or off

// note I stripped some stuff from my main.cs! So if something doesn't work.. you've been warned.

const char *maincs = "function BIT(%bitIndex){return 1<<%bitIndex;}"
 "function pushFront(%list, %token, %delim){if (%list !$= \"\")return %token @ %delim @ %list;"
 "return %token;}function pushBack(%list, %token, %delim){"
 "if (%list !$= \"\")	return %list @ %delim @ %token;return %token;}"
 "function popFront(%list, %delim){return nextToken(%list, unused, %delim);}"
 "function onStart(){}function onExit(){}function parseArgs(){}"   
 "function loadDir( %dir ){setModPaths( pushback($userMods, %dir, \";\") );exec( %dir @ \"/main.cs\" );}"
 "function loadMods( %modPath ){%modPath = nextToken(%modPath, token, \";\");"	
 "if (%modPath !$= \"\")loadMods(%modPath);if( !exec(%token @ \"/main.cs\")){error(\"Error: No mod\");$modcount--;	}}"
 "$runWithEditors=0;$modcount = 1;$defaultGame = \"T2D\";$userMods = $defaultGame;$displayHelp = 0;"
 "for ($i=1; $i<$Game::argc ; $i++){$arg=$Game::argv[$i];$nextArg=$Game::argv[$i+1];$hasNextArg = $Game::argc - $i > 1;	$logModeSpecified=0;switch$ ($arg){"
  "case \"-log\":$argUsed[$i]++;if ($hasNextArg){if ($nextArg != 0){$nextArg += 4;}setLogMode($nextArg);$logModeSpecified=1;"
  "$argUsed[$i+1]++;$i++;}else error(\"Error 1\");case \"-mod\": $argUsed[$i]++; if ($hasNextArg){$userMods=strreplace($userMods,$nextArg, \"\");"
  "$userMods=pushFront($userMods,$nextArg,\";\");$argUsed[$i+1]++;$i++;$modcount++;}"
  "else error(\"Error 2\");default:$argUsed[$i]++;if($userMods $= \"\")$userMods = $arg;"
  "}}if( $modcount==0){$userMods=$defaultGame;$modcount=1;}"
  "if ( !$logModeSpecified ){   setLogMode(6); }setModPaths($userMods);"  "nextToken($userMods,currentMod,\";\");loadMods($userMods);if($modcount==0){enableWinConsole(true);error(\"Error 3\");quit();}"
  "parseArgs();onStart();echo(\"Engine initialized.\");"
  "}for ($i = 1; $i < $Game::argc; $i++){if (!$argUsed[$i]) error(\"\" @ $Game::argv[$i]);}";

#endif //SECURITY_LOCKDOWN


then at the beginning of the runEntryScript function (line 300 ish) :
 #ifdef SECURITY_LOCKDOWN
   bool useDefaultScript = 0;                
  #else
   bool useDefaultScript = true;                
  #endif //SECURITY_LOCKDOWN

and at the end of that function :

#ifdef SECURITY_LOCKDOWN
   Con::executef(2, "eval", maincs);
#else
   Con::executef(2, "eval", script);
#endif //SECURITY_LOCKDOWN

 delete[] script;
 return 1;
}

EDIT : I think doing that verbatim allocates some memory for no reason. Feel free to remove that stuff too.

#14 Sorry i dont have a .net ide around right now, but basically here's how it's done in the .net world.

note: this is how you would protect a .net app, not any app... though the "any app" protection isnt too tough either if you can figure out the c++ calls to intercept.

for .net, you can embed pictures, assemblies, etc into your assembly as a "resource". Then, when your application tries to load the file, a Assembly.OnLoad (something like that, i dont remember the name) is triggered, which you can intercept (it's an event) and then manually load the file from the resource (extract it as a byte array, and then pass it back to the Assembly)

i have done this myself, so i know it works, but again, this is for .NET applications.. and if you are using a .net app, there are other nice ways of protecting content (like encrypting) so using molebox or the sort is not really nessicary.

and PS: if you use .net, then C++ CLI is a GREAT tool for obfuscation. use CLI or C# for your application, and for anything sensitive, switch back to native C++. decompilers like reflector dont work on native code.

If anyone has questions on obfuscation techniques for .net, just ping me. i have done a lot of research on this (prototyped a solution)

PS: to stop hackers using low-level debuggers, just throw and catch an exception.

#15 Yeah I hear exceptions are "a nightmare" to debug... Good! Also fullscreen apps seem to cause problems for people with debuggers, even those using dual monitors or that remote debugging nonsense. I've read many forum complaints. Some more food for thought.. I personally am going with a slightly modified LuaJIT for most of my game code, which I hope will cause enough debugging nightmares in and of itself :D But this has nothing to do with Molebox! Sorry... hey if it works then use it. There, now I'm close to being on topic.

#16 Just had the floowing back from Molebox:

Quote:We've found that Torque's executable is somehow protected from
modifications, and this error is the result of packaging (though, the
error message is not typical). To be sure, we've tried using UPX with
Torque2D, the result was the same error.

We cannot break through this protection.

Possible solution can be receiving a non-protected copy of T2D from
GarageGames developers.

I've used UPX on some older versions of TGB, but haven't tried the on the newest version. Does this sound right, or is there something else going on?

#17 Are they joking? We have the source code...and there are no protections. What EXE did they test on?

I just downloaded the Molebox demo and packed my TGB project with no problem. It's annoying how you can't add folders! It was tedious adding all those files to Molebox. But it worked...

#18 Yeah it sounds a bit suspicious, but i havent tried molebox before, so i dunno (tho i did tweak with the tgb exe enough to convert it to be a dll, and i didnt notice anything funky in the process)

#19 Oh I forgot to mention this but TGB complained about not finding main.cs... despite it being in the Moleboxed executable.

#20 This resource might be handy if that's the key issue. It shows how to eliminate the main.cs file.