Protecting scripts without the Lindens

If someone was able to make a seriously malicious script, I think it's format would be more than readable.

ALso, they may be able to view or decompile the bytecode and look at the script, but in game, I'm not sure. They may have to rely on the plain text.

My first instinct is to flame the hell out of you, but I'm so astounded that you think these things I just have to ask why you think them?

LL is prettly lax about the TOS as long as intentions are good and it does no harm.

Nice Rathe, only wish we had this before all the unpleasantness of the past week. As far as TOS violations and things breaking when switching over to MONO, compared to your source code being easily compromised I think I know which I'll pick.

LL is going to convert existing scripts that are running from there LSL bytecode -> Mono; perserving their state (or so i've heard).

Yeah, I would love to only supply binaries in the items I sell, but I tend to think that Babbage is probably right; the potential to sell a bunch of items using this tool with object-only code, then have ALL of them break down the road when LL changes something requiring a back-end recompile, and me having to answer to a lot of upset people as a result I don't wanna deal with.

I'll stick with trusting LL's permission system for now until they can implement something similar within SL itself. Plus, that L$2500 price tag is quite discouraging; would rather write it myself for that price.

That's a really good point Strife - if converting to Mono means that all my scripts get reset, I'm dead.

Also, your thinking in terms that how LSL executes it's commands is flaw proof. Lets just say that for a moment, an exploit exists in how something is coded at run-time, but the compiled bit-code appears unflawed... the Lindens would have no reference to go by to see which portion of the code was being compiled incorrectly. So if someone exploits a flaw in how ll functions get implemented, and griefs the grid, then the lindens check and find out that they can't see the actual text code to fix the problem, I can imagine some lawyers knocking on your door about then. As far as what I've been able to tell, the lindens take a lax approach on modifying the client side of SL, as long as it doesn't effect the server side functions. This 3rd party program definately effects the server side functions, and I'd be very weary to even use this, let alone release it to the public. All it takes is one bad situation and your skunked.

You should backup your scripts before using this (as suggested in the documentation). The cache just makes it easier for re-editing (only need to cut out and not paste into over and over).

I have been backing up my scripts locally for years now because you never know when the asset server will lose your script. All you need to do is select all, copy (CTRL-C), alt-tab to your favorite editor, paste (CTRL-P), and save.

If there is enough interest I will add some auto-backup features that will save a copy of every script to a target folder when using Hypercard.

Also, thanks to the earlier suggestion, I will try to add a on/off toggle so that you can disable it for scripts you do not want protected.

Feel free to contact me with other feature suggestions and I will see what I can do.

Well my opinion is that any script you rip is likely not going to do exactly what you want. The ripper is highly unlikely to be able to make mods to it effectively (that is why they rip not write).

From my experience, the only real protection in software is to move faster than the rest. So when they are trying to make bucks off your last stuff, you already moved on to something better.

/esc

I respect Babbage Linden for his work and progress on the Mono compiler, looking very forward to that, but the question remains when, and how does it offer me anymore security or protection of my intellectual property?

Open source is great, and need not apply, but for closed source projects, where you spend hours, days, or even weeks writing LSL there needs to be more protection, and having been a vicitim of LSL source script theft REPEATEDLY I decided to take some action.

Your souce code becomes protected from would-be thieves who could exploit permission bugs at anytime in the future. Permission bugs have happened before, many times, and will probably again. Your source code is even protected from possible disgruntle Linden Labs employees. Not to say that there are any, but you certainly wouldn't want them pasting your source code around to their in-world buddies. You can even add extra security to prevent scripts from working for, in, or with other assets than your own by adding key checking code that cannot be modified via the script source.

You sacrifice some convenience, such as automatic rewrite to Mono (when it becomes available) in exchange for the best security possible (byte code only). A price I'm willing to pay considering the intellectual and economic damages I have already suffered in the past depending solely on Linden Labs ability to secure my source code.

I haven't read everything, but seeing how the libSL crew uses Rathe's Snowcrash program on a regular basis for patching libsecondlife I think Rathe's words hold some ground.

Thanks Rathe, for doing what LL dont seem to be able. Protecting the many hours of work creation takes.

Have you considered trying your hand at havok+ ? (only half joking)

Every time someone calls this bugged out thing a metaverse god kills a kitten.

Nice work Rathe!

Rathe, I'd really appreciate a backup of stripped code to a local directory. I can work with it as is, but I'm pretty absent minded and I'm going to trip over it and lose my source eventually.

... and then I will cry... you wouldn't want to see me cry

To put things into perspective, imagine that Microsoft Visual Studio .NET uploaded your entire C/C++/C# project's source code to Microsoft's website EVERYTIME to you hit Save or Build. How secure would you feel then? How would the world of software developers react to this?

This is exactly what happens in Second Life with LSL, except the source code goes to Linden Labs instead of Microsoft. Granted they have a few more karma points, but who do you trust more for protecting your intellectual property?

My answer, neither.

Rathe, my best guess is that this works by intercepting and discarding the upload of the script source... Would it be possible to encrypt or obfuscate the source being sent to the server rather than dropping it? This way the script could ostensibly be on the LL servers for remote backup purposes, but not in a human readable format, which wouldn't matter since only the bytecode is required anyways.

Just wondering. I for one think it's a great idea, and encourage you to keep it up!

Takuan, I had similar thought not too long ago, great idea! I'll look into it more and see if I can't come up with a good solution and add this as yet another alternative optional way of backing up your source in addition to automated local file backups.

This could make sense if you gave the user a key, and encrypted everything with that key. When they want their source back, they paste the encrypted text and insert the key, showing the original source.

Completely destroying the source text is, in the long run, going to cause more problems than it solves.

Wow. This is giving me ideas. I CAN'T copy/paste in Linux (and sending XEvents, while it can be an okay workaround at times, is VERY tedious due to the way SL handles input events). If the source code is stored locally, is there any way I can paste to/from the local verion and then re-upload to SL? Where did you get your information about local script storage? Did you just monkey around and find it, or is there some documentation somewhere?

Linden Labs has a list of legitamate and approved software that it recommends to enhance your Second Life Experience. My question is, why isn't this being first taken to Linden Labs for Approval?

I will warn everyone that it is risky to go to any website listed on a forum. It is also risky to download and use unapproved software that stores data which may or may not allow another person to see it (which would in affect eliminate the purpose of the program).

That being said, yes, this program (if it does what it says it does) would certainly have merits.

Automated local backups is a very good thing, especially if I can have a setting that always puts them in my svn working folder, hint hint.

[Edit] Ooh! Ooh! And an upload feature to get around the damned Linux-can't-cut-and-paste bug! Yes, indeed! Do you have those sorts of hooks? I understand that someone on the libsl team is looking into the XUL interface defs and hooks, maybe that kind of information could help enable such a thing? Okay, maybe that's a big dream, but that's because it is so sorely needed. Sounds like a great product even without such a feature!!!

Rathe, thanks so much for this. I can't believe that this isn't the default behavior of the client anyway.

Francis, thanks for posting. I rarely read the forums anymore (maybe a few times a year, glad I read it today!).

--Bos

They might, but I'd bet not. If they did, the comments and self-documenting variable names would be stripped out, and they'd be reduced to trying to read machine-generated source code with arbitrarily named variable and no comments. But as a developer, I'd guess that they have the client upload the code to the server as basic behavior so that they don't have to rely on reversing the compiling process, and probably don't have a tool that can do it. If it became a big enough issue, they might create such a tool, but comparitively, only a tiny minority of scripters would be using something like this anyway, so it probably wouldn't be worth the development costs to create such a tool.

It sounds like a very good idea but I'm very cautious of supporting anything that involves client-side hacks.

The registration system for instance sounds iffy - what server is it checking in with and what information is it sending? Activation systems are suspicuous enough normally and one that's running with hooks into the Second Life process is especially so.

And (devil's advocate a bit here!), if it's ok for you to make a proxy that makes SecondLife.exe act in ways the programmers didn't want it to, then would it be ok for someone else to make a proxy that makes Hypercard.exe act in ways you didn't want it to, such as becoming registered when it isn't?