READ .dso files, can it be disabled?

#1 When I rename .dso to .gui and open it, I only get a bunch of chars, since the .dso files are the compiled scripts. I'd say it's pretty hard to modify anything that actually works afterwards. You can just delete the .cs files, though, at least in your distribution copy, but why would you want to prevent the engine from reading .dsos? I don't think the engine will work without the scripts, unless your game only uses c/c++ and no script. As far as I know, the .gui also get compiled and end up as .dsos, so if you really disabled .dso reading, the guis wouldn't work either.

#2 Hello Stefan

I'm afraid you misunderstood. I know that I can delete whatever clean script that is left behind the compiler, what I was saying is that you can open COMPILED scripts with the GUI EDITOR from within the game even if the .gui/.cs file is missing and only the .dso is there.

Anyone trying to accomplish that will find the function, and disabling it from the gui editor will stop the one's trying and the ones that don't either HAVE the source, or don't know how to re-enable it.

#3 But like this, you can only load existing files, rename them and save them somewhere. You can't actually modify anything, can you? To use this for cheating, you would need to be able to modify the scripts. Just renaming them and resaving doesn't really help anything, since the file must be loaded from the scripts somewhere. You might be able to load it from the console, but in a server/client setup, when cheating matters most, the effect wouldn't be too big, since the rules are controlled by the server. Do you have an example of what could be done with the gui-renaming and resaving technique?

#4 I don't know how to further explain in english, more than I already did; but I'll try it this way around instead.

Imagine you have a script file: game.gui
You delete it from your distr. and only leave the .dso.

Now, the user is trying to view it, can't.. since it's compiled and not in readable form. Cool.

But then, you can just modify or create a new init.cs file, where game.gui is executed, and then head into the GUI editor, select the GuiControl in the dropdown menu and press save.

Now you got the .gui file again.

#5 Don't ship with the GUI editor, and make sure the C++ code exposed to the GUI editor is not callable anymore by scripts, for example with particular defines for your public release builds.
I don't know what you should do to disable it , but keep in mind that disabling that functionality probably has cascading effects on the GUI editor, and possibly the World Editor (since it also writes out scripts files) and other parts of the code. I simply don't know first hand :)

#6 Nicolas

Heya, you have to remember that everyone has access to the Torque demo, that has the GUI editor. Ripping it out from the game won't help since everyone can just get the demo.

And hehe, well. The GUI editor and World Editor creates .mis and .gui/.cs files. Not .dso's :P What the problem is that the GUI editor reads .dso files rather than the .gui/.cs file.

Obviously I'm not making any sense so, try yourself if you get a free moment, you'll notice what I mean. :)

Right now Gui Editor reads .dso files and not the .gui/.cs files. What *should* be is that it reads those and halts if they are not found.

Guess this is tied very closely to loading these and their templates, so it might be worthless to even try.

#7 People will be able to do that no matter what. Your DSO's and a copy of the TGE demo with the GUI editor enabled, and I bet a nickel they will unravel it.

Don't keep secrets you can't afford to have public on the client ;)

Think about it this way: what are you actually trying to protect? Is it a function you GUI calls, or is it your GUI itself? Do you have critical game logic happening on the client? If so, consider moving it to the server, and only having the client call the server command.

Etc, etc.

#8 You could change the format of the .dso files, that would break any other Torque client from being able to read them.

#9 Edward Gardner

Come on, I know that. It has been brought up numerous of times that it needs effort to do this, and I thought I'd pass on that it ain't that hard at all.

Someone will eventually break into ANYTHING I'll do to keep them out, but it stops the normal user. You know. :P

Of course keeping the critical scripts over at the server is a good way, but to hack anything that's happening on the server or manipulate it in the wrong way, you'll need to see how the client side scripts work first, thus I want it to be hard to open.

Harold

Yeah, only that it ain't easy.. right?

#10 Ooor couldnt you just remove editor support from the engine folder (its in there somewhere isnt it?) that would eliminate all hopes of ever editing if you didnt ship with an editor in general... if you wanted an ingasme editor you should be able to just remove the gui editor scripts from the engine too. just my 5 seconds of thinking

--ishbuu

#11 Ishbuu, haha yeah. Read the other posts for an additional 5 seconds and you'll realize how you missed the entire point. :P

Quote:
Heya, you have to remember that everyone has access to the Torque demo, that has the GUI editor. Ripping it out from the game won't help since everyone can just get the demo.

#12 I haven't looked into this, but I was under the impression from just working with the gui editor, that It will only write out actual gui objects from what it has loaded. So renaming a script file to a .gui extension wont actually decompile the script, and about writing out gui files it will only write out the gui objects it has available(between the object write begin and end sections) If you have any functions in your .dso and write a new .gui from it, the functions are not written. These are just my observations I may be wrong.

#13 Bruce,

You hit the nail on the head :) TGE will only write outt the sections between

Quote:
//--- OBJECT WRITE BEGIN ---

and

Quote:
//--- OBJECT WRITE END ---

Everything else is read in from the .gui file itself and saved back out. Have a look at

ConsoleMethod(SimObject, save, bool, 3, 4, "obj.save(fileName, <selectedOnly>)")

in

simBase.cc

relevant sections around lines 529 - 534

-ROn

#14 So those comments need to be there for it to work?

#15 I believe those comments are placed to mark what the gui editor has written, but even if you did put those in at the top and bottom of a .cs file, it would not work.

When you load a gui file, all the properties are available for each object(lower right corner of the editor). All it does is dump these to a file when you save it.

As far as I know there is no way to write out anything other then the gui objects loaded in your game this way. And when it dumps these objects, it just starts out with the begin comment and then writes the objects and all thier properites then closes it with the comment.

This is my understanding how it works.

It is possible to write other things as well, the particle editor loads particle datablocks and writes them out in a format that torque can use.

Without actually "decompiling" the particle dso files.

#16 Alright. That sounds better :)

#17 Everything between those comments are dynamicly generated by the engine code, items outside of the last comment is read directly from the .gui file itself and rewritten back out.

lines 529 - 534 show it reading in everything outside of the comment until EOF and spitting it back into the file...

-Ron

#18 Yes, so you'd have to have the uncompiled gui file already available for it to write out anything after the generated code. If you try to do it from a dso you will only get what is generated from the objects it is writing out.

#19 BINGO ;)