Protecting scripts without the Lindens

Hi guys

I saw this in another forum, but I think it's of extreme importance to scripters so I'm reposting here:

http://secondlifetoys.googlepages.com/

Basically, it's a tool for stripping the source code from LSL files. This makes it impossible for any hacker to steal your source code, because it's no longer uploaded to SL. There is just nothing to steal.

--

My own personal backstory: Last year, there was (another) flaw in SL that let hackers read and copy scripts that were tagged nomodify.

They went around the world and took about 15000 lines of LSL code, 3000 lines of which belonged to me, and posted it to a website. I am so incredibly glad that a tool like this exists now, so hopefully I won't have to go through that kind of grief again.

I'm not sure this would be legal.

TOS:
4.2 You agree to use Second Life as provided, without unauthorized software or other means of access or use. You will not make unauthorized works from or conduct unauthorized distribution of the Linden Software.

Linden Lab has designed the Service to be experienced only as offered by Linden Lab at the Websites or partner websites. Linden Lab is not responsible for any aspect of the Service that is accessed or experienced using software or other means that are not provided by Linden Lab. You agree not to create or provide any server emulators or other software or other means that provide access to or use of the Service without the express written authorization of Linden Lab. You acknowledge that you do not have the right to create, publish, distribute, create derivative works from or use any software programs, utilities, applications, emulators or tools derived from or created for the Service, except that you may use the Linden Software to the extent expressly permitted by this Agreement.You are prohibited from taking any action that imposes an unreasonable or disproportionately large load on Linden Lab's infrastructure.

You may not charge any third party for using the Linden Software to access and/or use the Service, and you may not modify, adapt, reverse engineer (except as otherwise permitted by applicable law), decompile or attempt to discover the source code of the Linden Software, or create any derivative works of the Linden Software or the Service, or otherwise use the Linden Software except as expressly provided in this Agreement. You may not copy or distribute any of the written materials associated with the Service. Notwithstanding the foregoing, you may copy the Linden Software that Linden Lab provides to you, for backup purposes and may give copies of the Linden Software to others free of charge.

Why in the heck would they name it Hypercard?

I don't see how this violates the TOS. More to the point though, I don't want to have my source code stolen again, just because Second Life is not written securely.

Oh, and Norman - I believe it's a reference to Snow Crash, by Neal Stephenson.

... cause hypercards store (read: "hides" informations in the book Snowcrash. You can't tell what kind of information is inside a hypercard till you open it. Read the sub-title of the website - nobody knows if it will be information or virus inside.

To the secure-my-script-by-executing-an-closed-source-executable-thingie: NEVER-NEVER-NEVER use a third-party-program - even it tells you about the good thing it can do. It may contain a keylogger or a trojan. I hope we can agree on that. If you use it: your fault, dont say you have not been warned.


Now the the actual function of the program:
Whats it for? I mean .. why do i have to register ingame to get my cache stripped? Its just useless junk. And i guess it renders useless, if you want to sell items with scripts inside. So my guess: its a toy to get passwords.


HANDS OFF, Guys!

Um... so how does this actually work? At the best I would guess it does some kind of packet altering to obfusticate the script that is saved in the notecard so it's illegible? Variable overloading and the like?

I bet you L$10,000 you are wrong.
You obviously don't know Rathe's history in SL.

LSL scripts are in two parts, the text and the bytecode. I believe this program scrambles or deletes the text part of the script.

No viruses. No trojans. No keyloggers. My personal promise to all of you. Of course, the only way to really prove that is through trust, but I've been in Second Life for over 3 years now and hope that counts for something.

It does nothing to your cache, what it does is remove the actual human readable source code of your LSL scripts from the scripts after compiling them to byte code. This makes the script function as it always has, but makes it impossible for anyone else to read, view, or extract the original source code because the original source was never sent to or stored on the Second Life grid.

It protects your source code from ANYONE else ever seeing it since your original source code does not leave your computer or network while running Hypercard.

It is still possible that someone could still steal your "script" through permission bugs or exploits and attach it to another object, but they would never be able to recompile it, modify it, or cut & paste any of your intellectual property. If you write owner key checking functions in your script, you could even prevent them from doing that, because they will not be able to change the owner keys in the source to recompile it to work in their object.

You're right that it can be dangerous to run binary executable programs. Every time you install a new program (such as secondlife) you are implicitly saying "I trust Linden Lab is not installing malicious or invasive code on my computer".

I don't have any kind of counter-argument to this claim, other than to say that I personally trust Rathe more than I trust Linden Lab.



I think you're misunderstanding the purpose of the program, and/or how Second Life works.

Whenever you save a script in Second Life, this is what happens:

1) Your local client compiles your LSL down to LSL byte code.
2) Your client uploads both the LSL source code, and the LSL byte code back to the server.
3) The remote server (sim) runs the LSL byte code.

There is no need to upload the source code back to SL, except for convenience. From a functional perspective, the server never looks at the LSL source code again.

However, there is a significant drawback to this convenience: Your source code exists on the server for no particularly good reason. This leaves you vulnerable to permission exploits that let people steal all your source code. (This is what happened to me)

What hypercard does is that it strips the source code you upload back to the server. So anyone exploiting flaws in SL code will not be able to recover your LSL. The bytecode remains intact, so your LSL code runs as it always had.

Hypercard does *not* strip your cache. In fact, because it does not strip your cache, you (on your local client) will be able to see the original source code until you clean your cache

It is definately not "useless junk". If I had this tool a year ago, it would have paid for itself a few hundred times over, and saved me from a lot of personal anguish.

ok, don't wanted to offend the creator nor you. And if it works like it should, i will retract the "useless junk". But I will stick with my warning about closed-source-applications thou ...

@Rathe Underthorn: very nice, that roamsearch ...

The alternative way to really prove it would be to include the source code of program in question, but since then you'd basically have to trust everyone and kitchen sink to not just compile it and use it without payment, i can see good reason for reluctance towards such approach ^^

edit: also, if i understand the way this works, if someone uses this application to protect their scripts they better make damn sure to copy-and-paste-and-save the script source in external text files on their hard drive... because once the source goes out of their SL cache to make room for more 3d world data, it's *gone* and impossible to retrieve, as only compiled bytecode is actuall present in SL?

Babbage Linden has already advised against it, and any future item that does the same thing. It will cause scripts to be crippled when the Mono Virtual Machine recompiles.

/invalid_link.html

And Mono will be available when? My guess, same time as Havok II, joints and HTML on a prim, some time around 2020.

My thought, though, was that you'd have to be careful to always save your original source. I don't know exactly when the client clears its cache, but it could be at any time really, since as far as it's concerned it can always re-download the content. Or, I suppose, you could keep a personal copy that is only ever in your inventory. Is this program toggleable, can you specify that it should only remove certain scripts and not others?

(Granted that for anything large and complex and thus probably valuable I tend to save and edit it outside of SL anyway, just because my external editor is better).

Reputations aside -

The first principle of computer security is that /even if you can read the source code/, there is still a limit to how much you can trust any tool you - yourself - did not build. The canonical example is a backdoor built into the UNIX C compiler by the original authors.

This tool ostensibly prevents the uncompiled scripts from being uploaded and allows only compiled scripts up. What the page on secondlifetoys.googlepages.com states is:

"... no one will ever be able to view the source code, not even the Lindens!"

Which is /technically correct/ but entirely misleading. Linden Labs abides by their ToS that creators own content, but they do have access to, and likely routinely audit, scripting code - especially code used by griefers, malfunctioning/misperforming code, etcetera - and the notion that they don't have a tool suite specifically for reverse-engineering LSL bytecode scripts into object / pattern / pseudocode - seems ludicrous to me. LL by /defintion/ pwns everything in SL, even if they choose to be cool about it.

If used properly, it would prevent users from exploiting bugs to steal source code. It's not preventing the exposure of your intellectual property to Linden Labs.

And, as always, keep a half your water in a redundant glass so that when Mono comes along, you don't get Nucleosis. (heheheh)

It'll be that much longer if people use tools like Hypercard and make Babbage's migration job more difficult!

Francis, I'm really not going to wade into the technical discussion of if this tool is a good idea/bad idea, etc, but I really need to call you out for Shenanigans right here. Rathe Underthorn is your friend and sometime business partner. I'm sure you've been well aware of this program's development for quite some time, and probably even tested and provided feedback on it's development. You didn't just stumble across this and realize you needed to share it with everyone.

Well, it just wouldn't happen for those scripts. I heard from someone (might have been Cory Linden) that at some point in the distant past they lost some uncompiled script text in some kind of crash. Items using those scripts will break when Mono happens, but hopefully that loss happened so long ago that it won't matter much.

That is correct, Rathe is my friend. I am well aware of his integrity and his technical ability, which is why I feel confident in recommending this. But your allegations are not correct - I did not find out about hypercard before anyone else. Of course, before I posted this thread, I did test it myself, and verified that it works.



What I've done (and am planning to do in the future) is to develop my scripts normally. Before I do a release, I make a copy of my object with scripts, and do a recompile-all-scripts. I release the stripped-copy.

Regarding Babbage's comments, I'm not giving it a whole lot of weight for several reasons:
- LL has not shown a particularly strong commitment into ensuring that scripts for previous versions of SL will work with the current version. Why should mono be any different?
- It would be possible for LL to write an LSL byte-code to mono translator
- I still retain the original source code. I can recompile for mono and update users of my scripts myself
- SL is not secure. I don't particularly enjoy having my day ruined by SL exploits
- We do not have the tools to see if anyone's stealing our scripts
- LL has not demonstrated any willingness to help us deal with IP theft in SL, nor punishing the offending parties

Given the choice between protecting my scripts and the alternative, I know what I'd choose.

I'm a big fan of your work, and I'll take you at your word then, it just smacked of shilling at the first glance. Apparently my BS detector is misbehaving again.

I personally don't give a damn if it does violate the TOS.

I trust Francis, Francis' judgement, and by extension Rathe. There is another tool there that will dump a log of traffic between the client and server on the same site as hypercard and there are lots of packet loggers capable of dumping SL traffic. If you don't trust closed source and have some RL coding skill, by all means, write your own utility using the libsecondlife source and the packet log. Should be entirely possible.

I really don't have anything to add to what francis has said. I plan to develop the same way. I'll build and script as normal until I'm ready for release, then I'll load hypercard and recompile all the scripts in the object thereby removing all plaintext source. As far as Mono is concerned, Babbage and LL should ignore this tool and work on mono dev as "planned". Someone, Rathe or otherwise, will probably have to write/revise a tool to protect source again when/if it ever goes into production, for which I'm not holding my breath .

I have to say that I do agree with Francis' last two paragraphs; I am not, at the moment, a particular target for script theft (I think!) but if I were, there would be practically nothing that I could do about it. It's much harder to even tell if someone has stolen a script than if someone has stolen a texture; it's not something one can easily detect at all unless one actually owns the object with the stolen script in it and can test its behaviour, and even then one faces all of the problems that any other content creator does in dealing with the issue.

If there are exploits appearing which make it easy to strip out nomod scripts, well. And that's the first I've heard of this one too.

This can be against the TOS because if someone makes a script to do such and such and crash a sim, and the lindens can't look at the script once they've secured it to try and counter the script function, they won't be able to read it.
However, it's not my decision to make anyway. Best to ask the big men (and women) themselves.

My opinion? I try to keep my scripts secure to some extent, depending on their content, but it really doesn't bother me if they get copied or modded or not. I'm not making money off them as of yet, and the only way I've gotten where I am today is taking snippets out of other scripts and looking at them to see exactly what makes them work.

The only thing left I need to learn I think would be quarternions or whatever e_e

I sincerely hope the lindens weren't relying on the plaintext source to analyse possible script abuse manually. If that's the case then they need to change their abuse tracking method anyway because since this is possible, text source is obviously not a reliable method for determining a scripts purpose. Not to mention it would be incredibly time consuming and unreliable having a person sift through the hundreds of scripts reading horribly formatted source by multiple people in different coding "styles".