SL Protocol Reverse Engineering Team

llSetPayPrice is a good example -- and while I cant think of any similar ones, it is the side effect of someone coding a payment function poorly - and then being insecure later on.

To counterpoint this, exploiting that was possible with the SL client anyway. Remove your network cable, right-click and hit 'pay..', plug it back in, bam.

Basically this comes down to two specific angles.

The first - it's in the open; not locked up in private - this means people are going to be more likely to find security issues with SL, and have them fixed, rather than leave them be to those who have reversed the protocol and havnt opened it, and havnt reported them. It is better to have these exploits discovered and submitted to LL in private, than it is to leave them there for someone who may have a malicious aim.

The second is awareness - "bugs" like llSetPayPrice shouldnt exist, because people should be checking to see how much has been paid. If people are aware of these problems, then they hopefully should be taking extra measures (because if it's exploitable with a RE'd client, then it's very likely to be exploitable with the SL client)

Actually... the llSetPayPrice bug I am referring to is much simpler than unplugging a network cable. No need to touch a wire. I'd rather not post it here for the general population to see, since it is still an active bug.

I am not saying I don't want bugfixing done... but I am wary of the process of unpaid, indepentant, unsupervised modification to the software that accesses the same server I do. Call me paranoid... but I feel my concerns are somewhat valid.

And yes... people should be careful to check the amount they are selling their items for with some sort of value comparison routine in their money event, but I can understand people not seeing the need since the bug isn't in the code, it is in how the client handles llSetPayPrice.

Well, the short of it is - this isnt modification to SL itself; this is a ground up, seperate client library being built from analysis of the underlying protocol.

There's nothing being done which the SL client itself cannot read or send. You could "hijack" a SL client and send keyboard inputs into it and achieve pretty much exactly the same things, without ever reverse engineering.

If there is a bug in the underlying protocol - then there is a bug in the underlying protocol that needs to be fixed, because even independently of any organised efforts - that bug is still going to exist, and still be exploitable.

Having many eyes pour over the protocol is going to make these bugs apparent, and get them fixed. LL is aware of this, and this is exactly why they are condoning this.

But, as has been said before, any reverse engineering on the client can have no effect on activities on the server, unless there are serious problems that really need fixing on the server.

I see client side hacks as a way of improving what happens locally on my client, with no implication at all for your experience. In fact hacking is a rather over-bold term, with all sorts of scary implications that are almost certainly not there in the project as it is being described.

An example: there is a semi-public "hack" that enables you to set up your client so that it starts without asking for a name and password, and bypasses the start-up screen altogether. You can use it to set up separate shortcuts for any alts you may have, so that one click on a shortcut automatically opens SL with the av you want to use.

This has no effect on your use of SL, or on the server, but it DOES greatly improve my use - and it depends on understanding the communication between theclient and server.

This is a very trivial example, I know. I bring it up simply to make the point that the understanding and manipulating the client need have no consequences for the server and other users at all.

Another example: I would like my client to collect and save the IMs that I get when I am offline - not show them in ascrolling list and then throw them away as happens now. To achieve this would mean understanding the interaction between the client and server, and understanding how the client currently deals with messages. Getting it to work would do nothing to anyone's experience of SL other than mine.

If Linden Labs really are going to have over 1 million members by 2009 then everything has to be completely secure a long time before that. Preferably now!

And a community effort to assist this is, in my opinion, a good and possibly necessary thing to happen.

Cheers
Mambo.

Has the RE team come up with ways to make the protocol more efficient or faster, yet? I bet you will!

Woot! Go, team!

This is just another of Jared Godels really bad ideas being acted on by various people for no other reason that that of self agrandisement and "cred". Just because something can be done, doesn't mean it should be done.

The only way to do this right is to work *with* LL. However LL has decided they don't want to open up their product right now, (they have said they will in the future), so people are going around them because they just can't wait. They want to be the very first hacker to discover the inner workings. That's what's really happening here.

Impatient little boys with too much time on their hands are sooo curious as to what's inside the product they just bought that they are willing to break it into pieces finding out what's inside. They'll all be sorry when it's just a bunch of springs and wires in a pile on the floor of course, but they won't be able to take back what they have done.

This is not an "open source" project, it's a theft project. Reverse engineering might be technically legal but it's morally indefensible in this situation. There is no moral high road in terms of motivation here, and this is nothing that any real supporter of the open source software movement would publicly do even if they were curious enough to poke through the inner workings on their own. It's not right to take people's private and proprietary work and just "open it up" cause you think that morally things *should* be that way. This is just hacker crap hiding behind the skirts of the open source metaphor.

Those doing it should think about whether their motivation is actually based on a need to do the kind of things it might be possible to do with this knowledge, or just hacker "cred." They should also reflect on the fact that LL has been asked about doing this before and that they might have solid, valid reasons for not wanting this to happen.

In short, the proponents of this thing should have a little respect for other people's work and think about someone besides themselves for a change.

Dianne, please read Phoenix Linden's comment at the start of this thread.



This isnt about "cred", this is about doing things in SL that cant be done right now in an automated fashion. Things we cant set by script, and have to do by hand, etc.

This isnt decompiling the SL binary; this is mapping the underlying protocol, then building our own clients from scratch using that map. There is an important difference there.

Ok, peeps. Time for some definition.

Network class 101

protocol: a standardized set of messages used to communicate between client and server.

client: the SL software you run on your computer.

server: the software that Linden Lab runs on its computers. the "grid."


What's being reverse engineered here, with the full cooperation of LL, is the protocol. The messaging system that your client uses to communicate with LL servers. NOT the client. The client software remains closed. NOT the server.

Class dismissed.

Why don't they just publish the specs

We have the complete protocol specs now, we are in the process of using them to write up a C++ library.

I can see one reason why this is a BAD idea . . . the details of every object is sent to the client upon viewing (as it needs to be to be displayed). One of the things that can't be done now is directly copying objects. Knowing the protocol makes it quite easy (relativly compared to making a full fledged client) to open your shiny new psudo-client . . . point at an object and "make" the object yourself automaticallly. Again . . . think about what you are doing here, and before publishing ANYTHING you might want to make sure expoits like that isn't possible by making sure LL is aware of potential expoits before publishment.

Just my 2 cents
Rodrick

Let me make a quick statement during a coding break. The network protocol for Second Life is not something written in a big stack of documents sitting in a corner, or a giant PDF file somewhere. It's shipped with every client and sitting on your hard drive in $SecondLifeFolder\app_settings\comm.dat. You can't read it directly because it's encrypted with a quick XOR routine using the magic key 43. Once you decrypt it you see every packet definition, the packet blocks, and the block variables all described in a (somewhat) human readable language. This file is what Second Life uses to negotiate a communication protocol with the servers, so all of this talk about "LL releasing the protocol specs" is a bit off, since they have been released since day one. They were just waiting for someone to bother with writing their own client.

And yes, we are working with LL on this. Some suggestions have been thrown back and forth and things look good for the project right now. Yesterday I logged in with the first publically known bot (there are several in Second Life already but the creators aren't talking about them because people freak out).

Being able to see objects in Second Life is actually a feature, not an exploit. Our library isn't quite powerful enough to bend the laws of reality and change copyright law to allow you to steal someone's work, but it will allow you to see objects.

If you check out the texture forum you will see that textures are already able to be copied from video card buffers. You don't need a special client to do that, the program is already available.

It might help to stop people freaking out unnecessarily to enumerate some of the advantages of alternate clients (independently written without reference to the existing client). That way worriers might see the limitations/advantages of alternate clients.

I would like to suggest a couple:

A simplified browser able to be run in cheaper computers without the full details in the current client. This would open up SL to a much larger audience. Perhaps show the world without textures, just boundaries. That way you still have a large part of the SL experience on many more PC's. I have always been able to run "There" on a cheap PC.

A blind client without any visuals to allow me to check classified, scripts, or whatever. Many times I am frustrated that I can't check things in world because I am not at my desk top. Because all movements etc are server controlled, others would still see me properly or I could make my "home position" a safe one where I could sit while scripting or even building on an elevated platform.

A game could be organized where all 3 D movement is controlled by SL, but damage, weapons, etc are managed by a "game" server that all participants need to connect to. Would be a good split between SL server, game server and game only client.

If SL is to become a true 3 D generalised platform, I really think gamers need their own facilities with live on the edge features, while leaving SL rock solid - never to crash.

Imagination needed here folks ! Not paranoia.

Ed

Rodrick Harrington wrote:


Seeing how an object is constructed can be quite informative. It is quite a different thing to generate the key strokes to actually manufacture a new version with your name on it in the SL server where all these objects are made. In any case, you can already "edit" other people's objects and see how they go together. Also, you will never see the scripts that sit in these objects because they only exist in the asset server and execute in the sim server. Other people's prim scripts will never go near your client, SL or otherwise! Your client will only ever see a script that you generate.

I want this! Please PM/e-mail me with details!

Toodle-oo!

I too would be interested in this. If your willing to share or need beta testers, please shoot me a private message on the boards or IM me in-world.

I'm afraid my low level programming skills are a bit old and rusty so I don't think I can assist in any development beyond high level suggestions and testing, but I would be willing to assist monatarily and provide a cash bounty to the first person that can develop a DLL that can be linked to / imported into a C# application that will would expose a few functions:

1) Login to SL
2) Get inventory (names & uuids) of the account it logged in as
3) Retrieve notecards from inventory based on UUID
4) Give inventory to other agents (given inventory UUID and agent UUID)
5) Create a new notecard in inventory
6) Receive IMs and/or chat (whichever is easer to impliment) -- does not need to be done as an event handler, can be as simple as storing all received IMs in a buffer and exposing a function to allow me get that buffer and clear it.
7) Be able to chat (equiv to llSay)

I'd prefer to see the library provided as an Open Source library, but won't be picky if the authors would prefer it be kept closed but distributed freely.

Oh yes, we are always taking donations to speed up the coding effort ! And just for you... the first Subversion import of the library, that will be importable by C/C++/C#/VB/etc and do 1-7 plus more, using a hybrid of callbacks and serialized functions: http://svn.jhurliman.org/wsvn/libsecondlife/trunk/

(No it doesn't do anything yet, but remember we only started thinking about this a few days ago, it's come a long ways).

EDIT: The bot that I was talking about was very rough proof of concept code, not related to this new library. We actually have a very superior tool that piggybacks on the official client and can be customized to do any of the things you requested, and that could be finished with a few hours turnaround time instead of waiting for the main library to be finished. Of course that's a few hours less time one of the devs has to spend on the main project, but money makes the world go 'round I hear. Shoot an IM in-game. Oh, and our library will be released under the modified BSD license, we wouldn't have it any other way.

Edit: I think I have my answer; will delete as soon as I have confirmaion.

To Eddy Stryker: I got your Instant Message, but I don`t know if I answered it before the e-mail address expired. I tried to Private Mail you, but it didn`t work. If you got my second reply, you have my e-mail address; you may use it directly. If you did not get my replies, please send me a PRIVATE MESSAGE here with information I may use to contact you. This message will self-destruct when I hear from you.

To Torley Linden: You have my e-mail aaddress. You now have my EXPRESS PERMISSION to release it to the entity known in Second Life as "Eddy Stryker" by any reasonably private means available.

To everyone else: Apologies, but I couldn`t contact Eddy the way I wanted to, and had to fall back to this. As I said, I will remove this message myself when it is no longer needed. Thanbk you for your patience.

Toodle-oo!

Let me just make a quick statement also.... This seems like total bullshit to me.

Care to back up that statement of "Working with LL?"

If you are working with LL how come they haven't said anything about it? how come they are not initiating the project or just telling you what the protocol is for that matter?

The presence of the protocol information in an encrypted, coded, file on your hard drive does not equate to them "releasing" said information. If you are not being straight about that then why should anyone believe you are "working with LL?"

Might this project enable the chat text to be extracted and sent to a text to speech program?

I'm sorry Adam but your just wrong from my point of view.

All Phoenix has said is that they won't "go after you" for reverse engineering. But this is a given because reverse engineering is allowed under most laws and specifically allowed under the DMCA.

That's not the same thing as saying this is an "alright" or cool thing to do. There are also a lot of hackers just like the people behind this project employed at LL so the fact that a few folks at LL might secretly think the people involved here are "cool" is also irrelevant.

The fact is, this project is the same thing as Jarod's premature expose on how to rip off textures in SL using the GL grab thingie. It's just plain wrong to promote this stuff and then make it available to everyone, hiding behind the fact that you just "made the gun" and didn't actually shoot it. The other oft-used justification in cases like this that, "someone would do it anyway" is similarly intellectually bankrupt (not to mention morally off base. )

These arguments are word for word the same kind of moral claptrap that the arms industry uses to justify the creation of the latest bomb or anyone who wishes to shirk responsibility for things they do that cause real harm to other people. I know this is just a game, but right is right and wrong is wrong. If you would do this, you would do the other.

I stand behind the obvious , which is that the only reason for doing something like this is the interest of doing it and the "cred" of being the first person to figure it out. If you know anything about psychology, you can see that motivation behind every word posted here.

LL is "resigned" to the fact that people would do this thing but that doesn't eliminate the responsibility of those actually doing it.

This project will cause real harm to real people, it *will* engender a lot of griefing, theft etc. You know it will. And the people behind this project will be responsible for that, (not that they care.)

You people haven't a moral leg to stand on.

Yes, the packets you are looking for are ChatMessage and ChatFromSimulator (sim-wide messages). When the library gets to a more usable state though you shouldn't have to fiddle with packet names, instead just using callbacks like onChatMessage() and high-level functions like agent.sendChatMessage();

To Dianne: They have been talking about it, haven't you been listening? And I don't know how to explain it in simple terms, but the network protocol is dynamically generated based on a file, there's no hard-coded spec. Parsing the file is extremely trivial, so there's nothing left for LL to "release". Remember that all of this information is being publically released, so you're not going to get left out in the cold with other people having superior access to information in game. That's how it works today, not when we finish. If our intentions were to destroy the grid or steal your prims, there wouldn't be a seven page thread on the forums with everyone talking about it, it would have happened by now.

He doesn`t need to. Phoenix Linden already did. Check out post number 27 in this thread.

They did. Post #27.They`re too busy with other things.There`s no need to TELL them the protocol: they aready HAVE the protocol, WITH Phoenix`s blessing, no less.Because Phoenix Linden SAID SO RIGHT HERE IN THIS FORUM.

Just go back and read post #27 for yourself, please?

I`m sorry if I`m comming across like a grump, but the information you ask for is plain to see, and you have already ignored the reference at least twice that I see. Please, just look for yourself? Honest curiosity here: If that isn`t enough to convince you, what would be?

Toodle-oo!

Dianne, I want to correct a small typo in your speech.

"someone would do it anyway"

That should be

"someone has done it anyway"

And in fact, we have the tool and the source code of how it was done. You can go find it yourself but I'm not going to jump through any extra hoops to explain it. I don't want people coming to me saying "Dianne stole my animations!" We don't deserve any credit beyond the code we write ourselves, the fact is all of our work had been previously done and we're working with those anonymous persons to bring their work to a wider audience.