Sad news...... Scripts are vulnerable now

define obfuscate? not that it matter if they are converting the bytestream, as opposed to the plain text.

Chalk that off to a senior moment Since there is no two sided communication where you can actually encrypt, in this case you are pretty much well stuck with something as simple as keyword replacement and as you mentioned, stripping comments. Underlines & Japanese characters are easy and makes plain text code much more difficult to read. Anyone determined enough can still do a search/replace and eventually grok the code anyway though. But then again, anyone competent in LSL doesn't need to see a script to know how to do something.

I count 7 characters on the basic keyboard that are ignored as breaking spaces, but yeah, a whitespace builder is easy to make. as is search replace variable names... plus all lsl commands would be visible... and it still doesn't address the fact that they don't need to understand it to use it... they woman that launches the nuclear missile on command doesn't need to know how to build the sucker. just insert key, press big red button. (although I'm told my code as written is getting unreadable again =X)

If you're really concerned about your scripts being stolen, it's still possible to upload bytecode only for LSL2 compiled scripts. Obviously, you lose the advantages of Mono. And your bytecode can still be reverse engineered. Chances are your scripts aren't worth being stolen in the first place. Not to insult anyone, but there's only so much that can be done in LSL, and they already know how to do it. The only case I can imagine being worth the effort of protecting would be something like a SLX terminal, or whatever other large commercial service that probably has sensitve keys or whatnot in it.

Tl;dr: it's not worth worrying about.

I agree that it's highly unlikely that you have any code that's sufficiently unique to get all crazy over, but you don't have to be a large commercial service to be a little worried about whether someone gets your code.

To use an example near and dear to my own heart, there are a number of combat systems in Second Life that use one method or another to try to prevent 'cheating'. This often means that, while the actual mechanics of the combat system are perhaps nothing particularly special, there are still 'trade secrets' like communication protocols that need to be protected.

To say that it's "not worth worrying about" is overly dismissive. Many of us put countless hours into our work, and even if it's not earth-shattering truly groundbreaking stuff, we have invested ourselves in it.

.

Speak for yourself


...really? I'm wondering how an LSO script source is then represented to the creator/owner.

It isn't. You can put whatever you like as the corresponding text. A big "Screw you, kthx" is what some people put.

I do understand how you feel, actually, I like said combat systems. I found an easy way to break CI's a good while ago without even needing to see the scripts, though. :<

Unlike Linden Lab, I appreciate information on these things, and will act as quickly as possible to resolve any issues (if they are resolvable).


.

we do what we can, because we must...

...or we go do something else because we have a choice

Of course, the missing part of your answer there is that to do this you need to use software that's not part of the LL distribution (i.e. omv/libsecondlife et al).

Clearly!

Alternatively known as a "hack workaround".

Perhaps the platform should be fixed too.

I haven't seen much evidence that there's much interest by Teh Lab in doing so

.

...yep, my experience also. ...so a nice strong *serious* competitor in this whole VR/Metaverse space would definitely change attitudes in a positive way I think.

The current "alternative" platform (based on .NET) appears to make all the same mistakes that are persistently confounding LL themselves. I suspect, BTW this is why LL tolerates OMV - while they simply continue to copy SL, they aren't ever going to be serious competition to LL.

not a Portal fan I take it? it's a few hours fun =)

The 'alternative' I think you are referring to is absolutely awesome as an enhancement to the Second Life content creation process, and is a fascinating proof of concept, but it is not even close to being a viable alternative yet.

And I wouldn't be at all surprised if security were more of a problem there, rather than less. I don't know that to be true, I frankly haven't done much testing in that regard, but security is *hard* and doesn't seem to be one of the highest priorities from what I've seen thus far.


.

After a long review, I now strongly suspect that this current breach is limited scripts that have been compiled to MONO.

Comments?

Oh, if only this guy were in charge of SL security: http://www.schneier.com/blog/archives/2009/06/im_being_interv.html

Bruce Schneier will be interviewed in Second Life tonight at 9:00PM ET. /me desperately wishes he could make it


.

Failure of DRM is not a security problem.

..yea yea "information wants to be free", the point is that not all information should be.


*edited to add*: I wish the source code for the SL simulator wanted to be free. Then maybe it could be fixed.

I didn't say failure of DRM is not a problem. I said it's not a security problem.

Review harder.

It's never wise to bet that you have 100% security.

Well, for the most part, you are correct. Scripts are very resistant to being copied, compared to all the other assets. Like you say, there have been instances when they have been vulnerable, and this may be one of those times. However, I wouldn't go beating yourself up over a minor semantical error (that nothing is "invulnerable" to copying).

I have my own doubts about the specifics of this "hole" as well, but at least it isn't something that you can simply do with a few lines of LSL (ie, like treating it as a notecard and reading it that way).

In fact, it is one reason I don't design systems with obfuscation being the sole method to security. I don't allow people to put passwords in config notecards, for example, because I know that ANYONE can read ANY notecard, once they have its UUID. A custom viewer can easily pick a notecard UUID out of a networked vendor server, then that person can go and make a networked vendor terminal give you all their stuff.

Same goes with authentication mechanisms. Never depend on any authentication mechanism which hides critical parts of it in the script code. If someone can get your source code and trivially break your security mechanisms after that, then you're screwed. "Security through obscurity isn't security at all" (even though that's not the whole truth of the matter -- passwords are a form of security through obscurity).

Scripts have been vulnerable, and will be vulnerable again; it will happen. The important point is, though, that they are still more well-protected versus people copying them than other assets which get shipped to the viewer to be displayed. As such, your argument in that direction is still realistically valid, if not absolutely so.