Public Exploit: steal anything in your cache

/13/98/113908/1.html#post1094453

EDITED 8th August: The link above points to a post pointing to the old website for the Reverse Engineering group. The new site is at http://www.libsecondlife.org/ and the Slice program is missing from the site.

Here is the results of me using this program:

Images (.j2c files) 1833 files
Gestures (.gesture ) 75 files
Sounds (.ogg files) 152 files
Body parts (.bodypart) 4 files
Animations (.bvh files) 398 files
My Scripts (.lsl files) 132 files.
My Compiled Scripts (.lso files) 82 files
Notecards (.text) 61 files

We need the cache to be encrypted. And the encryption changed each release.

Psyke, i know this is already on the forums, but people have been banned for linking to items like this.

I don't think the sellers guild is going to have any credibility AT ALL if we publicise ways to help other people steal things.

Please edit your post!
Cali

I am not interested in causing problems or conflicts here.
The truth is that the word is out and Lindens have no interest in covering this up at all. The original post remains there for all to see and has been there since the 16th of June, it is now August. The bad people know about this and the other hack that I have not mentioned already.

Me showing this here just informs the good people, us.

The Slice program is part of the "Second Life Protocol" revese engineering project. Here is what the Lindens have to say about this project:


Here are the stated aims of the project which Lindens so far done nothing about:

The project is so far still authorised by the Lindens and public knowledge in the forums. Therefore it breaks no rules to admit this truth.
The bad guys know and now the good people should know.

Are you angry about this? Don't shoot the messenger.

I would love to see some cache encryption, I think awhile back a linden said something on the forums about encryption taking up to much cpu, which I doubt it would but I'm not 100% sure. Even a simple encrypytion would help to get rid of the theives that have no idea what their doing. As it is now its download a program, use it, get the textures, not really a hard thing to accomplish once you get the right software.

We should rally for cache encryption, this is an important issue. I don't buy the excuse that it would create some kind of connectivity problems.

I think splitting files into parts would make difficult for people to steal content.

Texture theft wise, I wrote an email to LL yesterday about implimenting watermarking onto texture files, I found a few nice sites about it including one that had open source C programs so they can try them out and see what they think. If I hear anything back from LL I'll post it here.

Curious why you think that ?

The largest bugbear to the state of digital copyrights are the peer-to-peer networks, which invariably use file splitting as a means to get large files from various places, then put them back together again seamlessly.

Modding one of those sort of programs to put the SL content back together - or even digging into the client and ripping out it's "joiner" code is going to take someone all of ten minutes.

Encryption is the way to go (IMO) - but how much encryption can LL pack into either end of the connection without destroying response time is one problem with that, and the other being how long is it going to take someone to break the encryption and publish it ( or sell it )

Since we update weekly we could change the key weekly? Just trash the old cache and start again. Design the encryption so that the average time to crack is over one week.

Love you guys, but this has been reviewed many, many times before. :3

It is pretty much impossible to encrypt the cache at a level mentioned for the simple fact that, at some point, it arrives whole, decrypted and rendered on your screen. It doesn't matter how many barriers you place in front of this fact - it will eventually arrive at this point in which it can simply be fished out.

There are methods to do what many of you are suggesting, but they involve much more complicated CPUs and methods not available to the mainstream public. Many of our SL residents do not wish to be forced to upgrade to enjoy something that is only infected with moral issues. All the data encryption in the world won't stop someone from trying to steal something they want.

That being said, I'm also fairly sure that the Lindens themselves wouldn't want to lose a very large percentage of their residents due to making a change in coding to function with a system component not available to many of them.

In reply to both the above

Psyke Phaeton

Linden employ a policy of work on what you enjoy - They dont have enough people working on bug fixes, let alone dedicating a whole team of people to coming up with new encryptions every week ( especially for a subject they don't care about )

Carbon Breed

I would have to agree - dongle type encryption would be the safest way - but if people don't want to be premium, what is going to convince them to pay 25 dollars ( or more ) for a hardware add-on.

Answer - I havent got one - not one that would pass the usability and acceptability test at the same time.

If you are only refering to textures then you are totally correct. In my estimation texture protection is a lost cause. They can be grabbed from memory. Infact I would argue that LL make textures in SL unprotected technically but state they are protected by copyright law and DMCA. This would stop many from being totally deluded. A few thousand DMCA requests floating around may change the culture in SL rather than leave this hidden epidemic.

Sound may benefit from encryption because then it becomes more difficult to get a clean copy from sound drivers or the analogue hole. Not impossible. But my guess is that its not a big issue that the effort is worth it for a 10 second sound bite. (Imagine the situation if LL allowed 5 minutes of sound)

Notecards could be made difficult when protected by simply disabling copy in that window. Some one can screen capture or copy by hand. But if its a book the reward for effort becomes a deterent.

And then going further I presume gestures & animations become even more obscure to obtain.

Lets put textures aside for the moment and ask for the sake of other types of content is encrypted caching worth while? And then if so how about an open texture cache (where speed is important) and a encrypted cache for everything else?

How about locking the cache when SL is running and deleting or encrypting the cache on shutdown?

I didnt actually want to get too involved in this thread - just to ask why the file splitting seemed a good option.

But..

Locking the cache won't work as it resides on your PC somewhere - and is therefore accessable.

Unless SL is forced to be the only thing running on your machine something else can sit and monitor what it does and what it accesses ( yes there are protections on memory etc - but there are also ways around them )

If you limit SL to being the only thing that can run you upset people who use other apps whilst logged on, and hit all sort of problems with virus checkers and spyware systems claiming they have to run as well.

At least that is my understanding of what can be done.

Actually, I was suggesting, though I don't have specific names, that certain CPUs have an inate ability to encrypt any render on-screen combined with video overlay much in the same fashion as some DVD images cannot be grabbed with a simple press of the Print Scrn button - producing a black, blank image.

However, your dongle idea intrigues and impresses me. If it were designed to only allow SL to function when used, and run a software application in tandem with SL itself to encrypt anything before it can be grabbed by the CPU by finding the outsourcing of popular methods such as the many already associated with texture theft - you'd have a solution. The dongle software would have to be updateable to solve new cracks on a scheduled basis. Neither would run without the other.

Unfortunately, this is the design expectation of a commercial product. SL, already several years into developement, seems as if it is to far to go in this direction. Not only that, but with all the talk about open-source and so on, it just seems far to impractical as well. When the platform is finally completed and there exists a virtual-world net, whether it be SL or any other platform being built in this way, you'll still arrive at the same moral issues we are facing now.

Think of it this way. HTML is easy to learn if you put a little time in it. So are the methods of sending and recieving information over the net. Slap a little common sense in there, and some questionable morals - and anything is easy enough to steal. Second Life, should it ever pinnacle entirely, will be no different. This is a people issue, not a software issue.



EDIT: Also ---



Well, something sort of along the lines of what you've mentioned can be done, but it pushes a lot of people's buttons. An application can be run at the same time as SL, implimented into it, to detect known exploits by seeking out components of those programs. This, of course, means that this program will have to actively scan your machine for instances of these exploits. Many consider this spyware. Also, in some instances, due to how the exploits are constructed, it is almost impossible to detect them without having the program think SL itself is an exploit. :\

It is an unfortunate truth that it is simply not possible for LL (or any other software company) to protect everything perfectly. Just like every other company, they know that if it is digital, it can be stolen.

And they need to work toward the best balance of "keeping honest people honest" vs. spending an inordinate amount of resources combating a problem that cannot be solved perfectly.

So we dont bother making things secure? If not why have permissions in SL at all? They are a smoke screen.

Someone has notified the SecondLife Forum Moderators that this thread discusses an exploit in violation of the TOS. They then sent an automated message to this forum's moderators. If I dissapear for 3 days and/or this thread does, you will know why.

If this does happen, thank you for the double standard*, Lindens

*See post #3 in this thread.

The links above point to the old website for the Reverse Engineering group. The new site is at http://www.libsecondlife.org/ and the Slice program and goals are missing from the site.

libsecondlife forums:
http://compiledreality.com/forum/
Please be courteous.

Textures can be stolen by a variety of means as we all know, and sounds as well, if anyone wanted them....,

But textures (images) and sounds are what your computer are supposed to render... Which is why they are easy to snag.

But note cards, gestures, animations, scripts, etc, these can't be stolen with the slice program.

If you have authorization to an item in SL, then the slice will dump it. If you don't have access to the appropriate permissions, then slice won't give you the item.

If you disagree, snag an Xcite script and send it to Javier Puff, then send a collar script to Amethyst, and a pose ball animation to Jessie. I don't think you can, but if you could, those citizens would be the ones to get involved in this discussion to make LL take action, and sending them their own work would get them involved.

A quick note, the slice program seems to be still available from libsecondlife page. It's source code rather than compiled executable, but compiling it is pretty much less than a minute of work.

Gave it a try, and aside from textures, sounds and such it appears able to dump full data on AV shapes, clothing etc... which are actually stored in text (human-readable) format. Aside from other things, this means instant access to original UUIDs of textures used for making these items, without any need to re-upload them etc ... plus i figure it's only missing a matching program that can take such data and upload it into SL as "your" asset, to generate complete, 100% exact copies with full permissions as they'll be seen as 'rightfully yours' by the system.

And creation of such program is just matter of time, if only because it can be actually useful tool allowing genuine creators to save plenty of time. E.g, instead of having to manually generate dozen versions of the same outfit with just different texture to give appearance of different colours, or skins differing only by makeup.... it could just take'prototype' item, automatically upload dozen of provided textures, then combine the prototype item data with UUIDs of new textures, to create and upload all variations automatically o.O;

LL already provides UUID data via Debug, Which is on everyones User Interface menu. (Provided they enable it)

UUIDs of other people's textures, used in their items? Where, exactly in the debug menu options is it listed? Texture debug window provides only a small part of UUID as id for processed textures, and the debug console doesn't seem to list them, either... asking because it'd be quite insane if debug menu was actually doing it o.o;

Ummm, without looking, I think it is labled "Selected Texure Info" or something similar. If you can't find it let me know and I will log on and locate it.

By stealing I meant unauthorised duplication (and resale), not unauthorised access.
My guess is a viewed notecard, gesture and animation can be duplicated via cache once it has been viewed in game, then resold.