SL Protocol Reverse Engineering Team

Yes there is.

I enjoy my land that I own, The Tree Project sounds good too. There are many many more things, Like Exploring by bicycle etc.

Glad to hear it!

Watch those evol reverse engineerers don't steal your bicycle!

By hacking away in my evil laboratory (please pronounce it with a slightly british accent), I've concluded that the very first thing I'm going to steal with my masterful reverse engineering of the SL CLIENT... is that person's bicycle.

-edit: Just for kicks, I'll change the prims to bright fuchia, and place it back. Maybe they won't notice.

Oh, it's been done:
/53/75/85468/1.html


By the person you just posted under, even.

Loved that render, too, Kris.

??? What do you mean?

If this is indeed Linden Labs' view.. then why not release the protocol specification?

(Note: I'm not really saying that LL should do this.. only that, if they'll sanction reverse engineering but wouldn't release the protocol, there's a mismatch there)

Yes, it will take time for it to be reverse engineered but once it is done (and it probably will be eventually) the result will be identical to the specification being released, including it being accessible to users who may be interested in the protocol for reasons other than scientific curiosity...

Little update on this.. we have the full protocol. Just trying to figure out how to parse it in to documentation right now, and designing the layout of libsecondlife.

AMen

One possible reason for LL to not release the protocol is that an official publication of that protocol might restrict LL's flexibility in changing the protocol. If a protocol change breaks an unofficial client, LL can say "Oh, well -- must have got it wrong" or "We never promised it wouldn't change". Publishing the protocol puts a little more pressure on them not to do this. (Although, it certainly doesn't make it impossible.)

So, when is the Treo client coming out?

ed44
The main goal of the program was for me to learn some VC++.Net (which I wasn't happy with at all; i really wanted to read the files into memory then just pull structures out by typecasting pointers, couldn't figure out how). I've never writen an app that peaked into the memory of another; I wasn't particulary keen on starting for this project (hence the client logout requirement). It would be possible to either change the lock status of the cache files via system driver; or patch the exe or do it at runtime.

Anyway, the type of hacking I really like to do doesn't involve getting your hands dirty in other apps. Keeps things simple and self contained, much more elegant.

If folks are interested in the specs for the cache formats; i've mapped all of them (though the object cache files are a bit more complicated). The most interesting is the LSL bytecode. The format supports 64 events (only 33 have been allocated), over 300 functions (I haven't bothered to keep the table up to date), and in the right conditions a cleverly crafted script could rewrite itself (I've thought about writing one of these for a long time).

There is some information on my wiki user page; and if your looking for my bytecode notes (that really should be rewriten), look no further. Then there is ACU, which makes configuring how animations are uploaded a bit easier (along with a window mod that allows for greater percision).

Hi Strife,

Looks great! However, I don't see much point in reverse engineering lsl where you already have the source code. It does point out the limits/features possible with lsl and helps our general undersatanding of what makes good script.

It's obvious from the speed with wich even the most complex script is compiled that this happens client side, but only for your scripts when you write them. Takes a load off the server. Then both source code and byte code get uploaded to the asset server and the byte code gets executed in the sim server. Someone please tell me I am wrong!

Just think, the best part of a possible new client would be client side scripting in whatever language suits best. LL keeps the core on their servers, we do the rest on our clients!

Ed

Client side scripting would be a godsend.

I've spent alot of time poking at the client, and I have come to the conclusion that the client was a rush job. The evidence is apparent in multiple places; there are half implemented interfaces, buggy interfaces and badly writen code that has become lava flowed. While the renderer has had much of it's old lava flowed code removed; the rest of the client is in dier need. Take for example the avatar skeleton, it isn't symetric. The back end of the avatar customization interface (handled by a handful of XML files) is partialy hardcoded for no real reason, other then it was faster to code it that way then to actualy dynamicly generate the data from the XML files (ex. global_color). The is no way to create new clothing types, or add new textures to go over mesh. The actual window interface is all hard coded (you can add elements but they won't do anything). Then there is the attribute overflow bug in the build tools (where changing one attribute will corrupt another) that has been in existance since before I joined SL (the *fix* for it was to double check attributes; with the new version some of the attributes have new ranges resulting in... the old cludge not working 100%).

If you want to take a look at LSO files and compare them against LSL files take a look at this program here: http://labs.highenergychemistry.com/slprotocol/index.php?title=Slice_Source

I'm interested to know if the client uploads bytecode for the server to run directly. Can we write in LSL bytecode directly, or our own language that compiles to LSO and upload it with a third party client? What happens if bad bytecode is uploaded? Is the Mono support right around the corner and this is all futile?

Will that be a .h file or a .dll file?

(Perhaps the latter comment about VC++ answers my question.)

Actualy I've been peaking at the cache for over a year; it was the only way to reverse engineer the LSL bytecode (short of decompiling the client). I expressed my concern to LL for a few months between January -> March 2005 (at which point I cut off dialog as I felt that if the lawyers came; I'd be the first against the wall). The issue of my concern was that the UUID's that the cache uses are the same as those on the asset server; any user could recycle another users textures via the UUID's they gleaned from the cache; (the Linden I chatted with responce was "they can just use GLIntercepter instead, no point in more security". So I mothballed most of my research, only taking it out to poke at it.

BTW, why do you use memcpy instead of just typecasting the pointer?

.so of course! Unless you're on windows, then it will compile in to a .dll .

To Strife: Actually we didn't write that code, it was an anonymous donation. We just got another anonymous donation and would like some help, I'll post more details in the other protocol thread.

You're my new favorite!

I disagree.

I think that they're doing the right thing. And, if Secondlife is to really branch out and take root anywhere, it ultimately has to become as open and accessible as the web is. It might be scary, to Philip and the others, how fast this can happen - things aren't always under control as much as we'd like them to be.

The transition may be interesting, but I can only smile at the thought of Secondlife taking hold across the entire wired planet.

Life is risk, and I say...go for it.

What guarantees do we have that a client/viewer issue like the llSetPayPrice bug won't be exploited with such development? What assurences to we have that any of you aren't specifically planning something malicious? How will a "finished" work be distributed? Will LL offer support for user-created client/viewers?

There are a lot of questions that need to be addressed before I will be comfortable with this sort of thing. I pay for my SL account, and I think having a sense of relative safety and security in the client/server architecture isn't too much to ask.

There is no guarantee that any system created by mankind, anywhere, can't be gamed.

I'm stating this because most of the developers here know this already, but your question shows that you do not. So, to be clear, and not sarcastic -- its going to happen, and its better for it to happen with a million eyes watching, and a million brains working on how to solve it, than an overworked company of developers trying to keep themselves fed.

There is no guarantee that someone will not be mean, cruel, or malicious. Its part of human nature, and for that I apologize, its just the truth. We'll deal with it, just see the above paragraph.

I think the only question that needs to be addressed is why the client didn't become open *sooner*. Its ok, pretty much on the way to being in that state right now

I am aware of this. I do not, however, believe opensourcing the viewer is necessarily a good thing. Simply by stating... "someone's going to do it anyway, might as well just opensource it" ...is the same as saying... "someone is going to rob the bank, might as well leave the vault unlocked".

I do not agree with the hacker mentality that all software should be opensource, nor am I comfortable with the idea that a client/server environment which can effect people's financial endeavors is being tampered with by unidentified, unaffiliated individuals.

Bad policy. Bad business. Bad idea.

Well, this isnt about open sourcing the client - LL doesnt have any intention of doing that at this time -- this is about the underlying protocol, and there is a difference.

Right now, as a theoretical example; it isnt possible to delete objects off your land via script. With knowledge of the protocol, one could write a piece of software to login, and delete or return the objects automatically.

Everything in SL of importance (That is, money, inventory transfers, etc) is all run on LL's servers, and no-one can tamper with them legally. This is about being able to automate things that are done in the client.

In your bank analogy - it isnt about leaving the vault unlocked. This is about a bank serving robots as well as customers, and providing the same functionality to them both -- the vault isnt touched by anyone but the bank staff.

Woot! NPC's!

Ah, but in the case of the llSetPayPrice bug... that is a client interface issue. While money and assets are controlled by the servers... the client does have the power to effect the information sent to them.

llSetPayPrice <-- good example of client causing issues

Now imagine what could happen if someone *intended* to exploit with a malicious client. All I am saying... is that there are far to many unanswered questions for me to feel uncomfortable with people tinkering around with reverse engineering.

I don't buy the whole "life is risk" crap either. There is risk in life... and in business. The people who innovate WHILE minimizing risk are the ones that succeed.

Method for Opening Client Without Releasing Too Much Source

If Linden Lab. won`t do this, perhaps y`all good folk might?

Toodle-oo!