SL Protocol Reverse Engineering Team

I'm still wrapping my brain around how exactly the protocal works. Why is it built this way at all? It seems like bloat to me; pointless abstraction.

I've writen a little AutoIt script to parse the decrypted comms file to an xml file, and then have it insert whitespace so it's human readable (comlements MS). Could have writen it to be smarter but this does a nice job.

$text = FileRead ("output.txt")
$text = "<root>" & @CR & $text & "</root>"
$text = StringRegExpReplace ( $text, "[ ]*([{}])\1[ ]*", "\1");remove the spaces, they are a hastle to remove later.
$text = StringRegExpReplace ( $text, "\{([^{}]+)\1\}", "<tag text='\1'/>"&@CR);not needed, but makes things look nice
$text = StringRegExpReplace ( $text, "\{([^\r<{}]+)\1", "<tag text='\1'>"&@CR)
$text = StringRegExpReplace ( $text, "\}", "</tag>"&@CR)
$text = StringRegExpReplace ( $text, "\r([^\r<]+)\1", @CR&"<comment text='\1' />"&@CR)

FileDelete ("output2.txt" )
FileWrite ("output2.txt", $text)

$xml = ObjCreate("Microsoft.XMLDOM");makes nice whitespace.
$xml.async = "false"
if $xml.loadXML($text) Then
	ConsoleWrite ( "Valid XML" &@CR )
Else;these only do anything for editors that support it (like scite)
	ConsoleWrite ( "Invalid XML" &@CR )
EndIf
$xml.save("output.xml")

My main gripe with the protocol file is that part of it is ordered and part of it is unordered. Everything in the protocol relies heavily on ordering, for example the command names (tier one) correlate to a packet number that is their position in the text array. Kind of. There are four basic groups of packets; low, medium, high, and fixed (which is a subset of low). So the first low packet in the text file is identified with a 1, the second with a 2, etc. The first medium packet is identified with 1, so on and so forth. The fixed packets look like low packets, but they have a fixed position in the array, at the very end of it so no matter what protocol version the client or server are speaking they can still send those packets, which mostly deal with verifying the protocol version. But the block values (tier two) and field values (tier three) are randomly thrown in each packet with no regard as to ordering. All of the "keywords" are in a fixed array just like the command names, but the ordering of that array can't be gleaned from the comm.dat file as far as I can see. libsecondlife handles this by keeping a keywords.txt file that is just a list of all the keywords in order, which is thrown in to a map at run-time.

Has anyone had luck in decoding the teleport protocol? I would like to see the communication process starting from when the client tells the server where to teleport to, to when the teleport finishes. Tried running snowcrash w/ latest version of SL but SL crashes when loading quicktime.

I haven't had a chance to take a look, but we're going to have to use snowcrash to do it so hopefully this crash isn't the case for everyone. I know I had a crash on login with WinXP64 installed, but it worked fine on a 32-bit computer. Haven't tried with the latest version, if it's crashing maybe removing some of the system hooks would fix it.

If you're having trouble with SL crashing when loading Quicktime. Look at the Quicktime options and turn off the DirectX calls.

This fixed it for me.

Also, we're moving to using SLProxy instead of Snowcrash for anylizing client messages. SLProxy is written in C#, so its platform-agnostic, and it has some cool packet manipulation/injection features.

SLProxy doesn't use the odd windows hooks that Snowcrash does, so it should be much more stable.
==Chris

I've been playing a bit with SLProxy, and I'm thrilled with it and the rest of libsecondlife for the most part (kudos!)

Great work, very exciting, and I can hardly wait to see the things that this will enable. I'd especially love to be able to add inventory backup and restore to combat the too-frequent sim roll-backs! Or svn support for lsl scripters =D

edited to remove comments on a percieved issue with libsl that turned out to be my own misunderstanding. rtfm, huh?

Just downloaded SLProxy zip file. No ChatConsole included, despite docs and when running Analyst I do get the proxy server bit, but typing in chat window does not seem to log packets to the console; by which I mean the command window opened when you run analyst. Could we have a tutorial for this?

Apparently you're supposed to route SL through the proxy.

Did you read the README?

That's the first place to start.


...



However, i've also had trouble. I can get the Analyst to show all the packets with the --log-all enabled, however I can't get it to recognize /log * or any other chat command in SL.

What's wrong?

Maybe an update is needed?

Yup, did read the readme, but it was useless, sadly. Was answered off-line that the binary zip was incomplete, out of date and worthless. So, have been attempting to download C# etc in order to compile the sources; problems with access to MS web site, and other work has prevented progress thus far. Will report back if I have problems.

http://www.libsecondlife.org/downloads/libsecondlife-latest.zip

If it's gonna work, you will find it there. That is compiled every night by automatic build script.

Please remember that this has not been updated for today's release just yet. SLProxy should work for chat console or other limited uses.