Second Life Wiki - User contributions [en]

Hegemons Login Analysis

2007-01-31T05:57:16Z

Hegemon Skall: /* Step 2 */

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

The function to parse the message_template.msg file is in /linden/indrea/llmessage/message.cpp in the Second Life viewer source and the number just appears to be in the order they are in the file (seperate counters for how medium and low frequency messages.

The code used to generate the checksum, around line 1000:
<pre>
snprintf(formatString, sizeof(formatString), "%%%ds", MAX_MESSAGE_INTERNAL_NAME_SIZE);
messagefilep = LLFile::fopen(filename, "r");
if (messagefilep) {

fseek(messagefilep, 0L, SEEK_SET );
while(fscanf(messagefilep, formatString, token) != EOF) {
// skip comments
if (token[0] == '/') {
// skip to end of line
while (token[0] != 10)
fscanf(messagefilep, "%c", token);
continue;
}

checkp = token;
while (*checkp) {
mMessageFileChecksum += ((U32)*checkp++) << checksum_offset;
checksum_offset = (checksum_offset + 8) % 32;
}
// Code here to actually process the entries, see source for more info
</pre>

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 
Here out client is requesting a checksum of the template file so it can check its version matches. 
 
<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 

This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID. 
 
The data bytes aren't in the same order as the template, and each one is reversed, the major version is 0x01 and the minor version id 0x0D (13). The checksum for this template version is 0x9D 0x95 0xE4 0xC4. I would gess that the flags are the 4 0x00 and the other patch information is the 02 and 00 but its speculative at this point. 
 
<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1 
One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols. 
 
The server replied to the packet befoure it ACK it, its also possible to embed the ACK into other packets by setting the ACK flag and adding the number of ACKs to the end of the packet and then the sequence numbers. 
 
<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit 
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed. 

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real encrypted password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

The next step is to take the request the client produced and attempt to send it to the login server and capture the reply from the server. The login servers use SSL encryption so we need to tunnel through the encryption, fortunately there is a tool similar to netcat called stunnel that supports SSL.

<pre>
stunnel -c -r login.agni.lindenlab.com:443 > loginreply.xml
</pre>
You can then paste the clients xml request into stunnel and recieve the reply from the server, by default the server sends gziped documents that aren't very human readable, by removing the ", gzip" from the Accept-Encoding in the heading we can get the server to send us plain text back.

Note: When manually changing the xml files, its important to keep the Content-Length field in the header valid, otherwise it will be rejected and rerequested.

The servers reply contains things like the inventory layout, gestures and some character details (check the libsecondlife wiki). This response also contains the sim_ip address, by changing this and sending it to the client, we can redirect the client again to connect to netcat.

There is also a new field containing the url of the [https://wiki.secondlife.com/wiki/Capabilities capabilities] (its not shown on the libsecondlife page), once again we can redirect it and receive the xml requests. <pre><member><name>seed_capability</name><value><string>https://sim2049.agni.lindenlab.com:12043/cap/fa3c0b48-2db5-c73a-c8c8-9cf68be4edb2</string></value></member></pre>

Client request to sim_ip/sim_port (it was port 13005 in this case) UDP:
<pre>
[FL] [Seq Num] [Message Num] [------------------------------Data, 2 LLUIDS and a 4 byte 'code' = 36 bytes------------------------------]
40 00 00 01 ff ff 00 03 ad 65 5e b6 5f f6 4b 67 af ee 6f da f1 f8 f1 65 38 ba 9a a4 7b 41 42 6e 90 c5 f4 76 3c 51 e8 37 e4 2a 1e 03
</pre>
Here we encounter the first non-fixed message number FFFF0003. FFFF indicates that it is a low frequency message as seen in the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] page. We can then find out this message by getting the 3rd Low frequency message in the message_templates.msg file, in this case it seems to be UseCircitCode.

The client also sends a request to the capabilities server of the simulator obtained for the XML-RPC response:
<pre>
POST /cap/cee88818-d777-ced4-af57-a3aa39757f4d HTTP/1.1
Host: localhost:12043
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/xml
Content-Length: 185

<llsd><array><string>MapLayer</string><string>MapLayerGod</string><string>NewAgentInventory</string><string>EventQueueGet</string><string>RequestTextureDownload</string></array></llsd>
</pre>

=To be continued=
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file
How to get the checksum/non fixed messageIDs

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-31T05:54:50Z

Hegemon Skall: /* Step 2 */ - Some more info on step 2

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

The function to parse the message_template.msg file is in /linden/indrea/llmessage/message.cpp in the Second Life viewer source and the number just appears to be in the order they are in the file (seperate counters for how medium and low frequency messages.

The code used to generate the checksum, around line 1000:
<pre>
snprintf(formatString, sizeof(formatString), "%%%ds", MAX_MESSAGE_INTERNAL_NAME_SIZE);
messagefilep = LLFile::fopen(filename, "r");
if (messagefilep) {

fseek(messagefilep, 0L, SEEK_SET );
while(fscanf(messagefilep, formatString, token) != EOF) {
// skip comments
if (token[0] == '/') {
// skip to end of line
while (token[0] != 10)
fscanf(messagefilep, "%c", token);
continue;
}

checkp = token;
while (*checkp) {
mMessageFileChecksum += ((U32)*checkp++) << checksum_offset;
checksum_offset = (checksum_offset + 8) % 32;
}
// Code here to actually process the entries, see source for more info
</pre>

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 
Here out client is requesting a checksum of the template file so it can check its version matches. 
 
<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 

This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID. 
 
The data bytes aren't in the same order as the template, and each one is reversed, the major version is 0x01 and the minor version id 0x0D (13). The checksum for this template version is 0x9D 0x95 0xE4 0xC4. I would gess that the flags are the 4 0x00 and the other patch information is the 02 and 00 but its speculative at this point. 
 
<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1 
One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols. 
 
The server replied to the packet befoure it ACK it, its also possible to embed the ACK into other packets by setting the ACK flag and adding the number of ACKs to the end of the packet and then the sequence numbers. 
 
<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit 
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed. 

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real encrypted password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

The next step is to take the request the client produced and attempt to send it to the login server and capture the reply from the server. The login servers use SSL encryption so we need to tunnel through the encryption, fortunately there is a tool similar to netcat called stunnel that supports SSL.

<pre>
stunnel -c -r login.agni.lindenlab.com:443 > loginreply.xml
</pre>
You can then paste the clients xml request into stunnel and recieve the reply from the server, by default the server sends gziped documents that aren't very human readable, by removing the ", gzip" from the Accept-Encoding in the heading we can get the server to send us plain text back.

The servers reply contains things like the inventory layout, gestures and some character details (check the libsecondlife wiki). This response also contains the sim_ip address, by changing this and sending it to the client, we can redirect the client again to connect to netcat.

There is also a new field containing the url of the [https://wiki.secondlife.com/wiki/Capabilities capabilities] (its not shown on the libsecondlife page), once again we can redirect it and receive the xml requests. <pre><member><name>seed_capability</name><value><string>https://sim2049.agni.lindenlab.com:12043/cap/fa3c0b48-2db5-c73a-c8c8-9cf68be4edb2</string></value></member></pre>

Client request to sim_ip/sim_port (it was port 13005 in this case) UDP:
<pre>
[FL] [Seq Num] [Message Num] [------------------------------Data, 2 LLUIDS and a 4 byte 'code' = 36 bytes------------------------------]
40 00 00 01 ff ff 00 03 ad 65 5e b6 5f f6 4b 67 af ee 6f da f1 f8 f1 65 38 ba 9a a4 7b 41 42 6e 90 c5 f4 76 3c 51 e8 37 e4 2a 1e 03
</pre>
Here we encounter the first non-fixed message number FFFF0003. FFFF indicates that it is a low frequency message as seen in the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] page. We can then find out this message by getting the 3rd Low frequency message in the message_templates.msg file, in this case it seems to be UseCircitCode.

The client also sends a request to the capabilities server of the simulator obtained for the XML-RPC response:
<pre>
POST /cap/cee88818-d777-ced4-af57-a3aa39757f4d HTTP/1.1
Host: localhost:12043
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/xml
Content-Length: 185

<llsd><array><string>MapLayer</string><string>MapLayerGod</string><string>NewAgentInventory</string><string>EventQueueGet</string><string>RequestTextureDownload</string></array></llsd>
</pre>

=To be continued=
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file
How to get the checksum/non fixed messageIDs

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-28T07:33:03Z

Hegemon Skall: /* Description */

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

The function to parse the message_template.msg file is in /linden/indrea/llmessage/message.cpp in the Second Life viewer source and the number just appears to be in the order they are in the file (seperate counters for how medium and low frequency messages.

The code used to generate the checksum, around line 1000:
<pre>
snprintf(formatString, sizeof(formatString), "%%%ds", MAX_MESSAGE_INTERNAL_NAME_SIZE);
messagefilep = LLFile::fopen(filename, "r");
if (messagefilep) {

fseek(messagefilep, 0L, SEEK_SET );
while(fscanf(messagefilep, formatString, token) != EOF) {
// skip comments
if (token[0] == '/') {
// skip to end of line
while (token[0] != 10)
fscanf(messagefilep, "%c", token);
continue;
}

checkp = token;
while (*checkp) {
mMessageFileChecksum += ((U32)*checkp++) << checksum_offset;
checksum_offset = (checksum_offset + 8) % 32;
}
// Code here to actually process the entries, see source for more info
</pre>

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 
Here out client is requesting a checksum of the template file so it can check its version matches. 
 
<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98] 

This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID. 
 
The data bytes aren't in the same order as the template, and each one is reversed, the major version is 0x01 and the minor version id 0x0D (13). The checksum for this template version is 0x9D 0x95 0xE4 0xC4. I would gess that the flags are the 4 0x00 and the other patch information is the 02 and 00 but its speculative at this point. 
 
<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1 
One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols. 
 
The server replied to the packet befoure it ACK it, its also possible to embed the ACK into other packets by setting the ACK flag and adding the number of ACKs to the end of the packet and then the sequence numbers. 
 
<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit 
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed. 

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

=To be continued=
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file
How to get the checksum/non fixed messageIDs

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Talk:Version control repository

2007-01-28T01:38:52Z

Hegemon Skall: /* Bazaar */

== SVN ==

I'm happy with a read only SVN.

We are all developers. We can set up our own local SVN if we want a sandbox. [[User:Gigs Taggart|Gigs Taggart]] 15:13, 9 January 2007 (PST)

Agreed.
I think our repo should have a struture like....
* /trunk/slviewer/ Root of what we are given. You basically just need to check this one directory out to build the client.
* /tags/slviewer/slviewer-*/ tag of each revision that's distroed by LL as a set, perhaps with it's binaries, and the build outputs. (map files and .asm files anyone?)
* /branches/slviewer/slviewer-*.1/ Branches to deal with bugs that happen once a tag has been made. Any changes fixed on a branch should also be applied to the trunk too.
[[User:Kunnis Basiat|Kunnis Basiat]] 18:38, 9 January 2007 (PST)

* [[User:Adam Zaius|Adam Zaius]] 06:38, 8 January 2007 (PST) votes for SVN
** Directory structure something like:
*** /trunk -- Only editable by Linden Lab
*** /branches/users/<username>/ -- unlimited permissions by owner/creator for third-party source

Do we want to integrate the VCS with the Second Life authentication? Pluggability of authentication scheme seems like an important axis to consider. --[[User:Which Linden|Which Linden]] 09:27, 8 January 2007 (PST)

Giving users branches in SVN without a degree of trust is dangerous - purging history in SVN is intentionally very difficult, so a single (malicious) user could conceivably use up all the space in the server or host not-so-legal content (even if you svn rm something, it's still in the history). However if the trunk is pure svn, normal users can use things like svk if they want their own branches. --[[User:Ginko Bayliss|Ginko Bayliss]] 13:33, 9 January 2007 (PST)

: Very good idea to consider (VCS w/ SLA). I would highly recommend sourceforge due to its known ability to handle major traffic; however, we would not have the SLA. Despite that, there are many professional and mature tools that work directly with SVN, for example Subclipse.
: I suggest a tier level repository with modes for production, test, and development, and each with their own trunk, branches, and tags. Production is not distributed and is mainly read-only except for the few who update it. Production is updated with, and only from, approved patches from test. Test tier is updated by an approved group of individuals with patches from development tier. Test is not distributed but is not read-only like the production tier. Test is where people go to get latest working patches. It is similar to Debian's mid-tier. Development can be distributed (people can host their own local sandbox), and it is write-enabled by a larger group responsible to merge code. Once code has been basically approved as working in development, it moves to test, so several patches to development may result in only one patch to test, and that would be the same from test to production. [[User:Dzonatas Sol|Dzonatas Sol]] 10:04, 10 January 2007 (PST)

[[User:Eddy Stryker|Eddy Stryker]] 13:22, 9 January 2007 (PST) votes against SVN
* Branching/merging capabilities are hacked in, so instead of doing push or pull commands you are looking up revision numbers to figure out when you last backported and where the new merge should start
* No distributed version control like bitkeeper, git, mercurial, etc without using SVK which is a less than ideal solution
* Not designed for very large codebases like Second Life, where branching becomes unbearable
** To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out
* SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems

[[User:Kunnis Basiat|Kunnis Basiat]] 22:35, 14 January 2007 (PST)
* While I agree with the fact that branching and merging is a bit wierd in SVN, it was designed that way from the start, it was designed to get around several of the design flaws that were present in CVS, though I agree it's not as intunitive as it should be, it allows for really good tracking, but it's also a bit confusing. LL has been using SVN for a while, so they should be familiar with how version control in SVN works.
* I Find SVN to be really stable.I've never had a problem with SVN, and I've used it for a couple years professionally, and I've been helping my latest company migrate to SVN. The only annoyance I have about SVN is it's lack of an "obliterate" command, which there is a workaround for, and the schedule of an addition of the command. Other then that issue, SVN has been in use for several years, it's a well tested tool, and if any issues arise while using it, it's likley that you can find support for it. I've only had to break out svnadmin once (to deal with the lack of obliterate, and I found a step-by-step on how to do it.)
* SVN is used by KDE. It has both binary and source files, which reflects what we would be checking into OpenSL, and I think that KDE would have more users editing it, and I'm pretty sure it has a larger codebase.
* I don't know what problem you had with your repo. I am using the windows version of SVN, and I took my existing repo that I've used for other projects and checked in all of the slviewer and libs in one big checkin, with no problems. It copied all ~9000 files and 160megs in about 5 mins.
* I agree that LL creating account for every developer is very unreasonable. I think LL should host a repo that only has "gold" code on it, ready for production, with tags for each build. There should not be a sandbox for every developer. I think that we should submit patches to LL that are diffs from the head version of the repo, then a LL employee can apply the patch, then check&verify it works and passes all tests, then finally commit the patch to the repo. What would the process for a LL employee to recieve a change, validate it, and apply it to production be with Mercurial? I don't know enough about it to say what it's like.
* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

== Distributed version control ==

One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- [[User:Rob Linden|Rob Linden]] 07:25, 8 January 2007 (PST)

=== Mercurial ===
Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.
----

[[User:Baba Yamamoto|Baba Yamamoto]] votes for this.
*No central repository.
*Easier branching and merging.

=== Darcs ===

Darcs is something you may want to investigate. I've used it for other projects, and it was simple and effective enough that the less technical folks have actually started using it for their own projects, it is so simple and effective. A possible con would be that it IS written in Haskell.. but that's not that problematic. --[[User:Ky Aska|Ky Aska]] 15:59, 8 January 2007 (PST)

We tried using darcs for a while in-house, and really wanted it to work, but it would frequently never finish operations on windows because it would consume too much memory. [[User:Phoenix Linden|Phoenix Linden]] 09:25, 9 January 2007 (PST)

Out of curiosity, how long ago was darcs tried? It might've gotten better since then - though I've heard that performance during conflict resolution is still rather bad. --[[User:Ginko Bayliss|Ginko Bayliss]] 16:32, 9 January 2007 (PST)

[[User:Don Linden|Don]] and [[User:Kelly Linden|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden|Andrew Linden]] 2006.01.10 09:21 (PST)

=== Bazaar ===
Bazaar seems to be the hot VCS of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not. It's got quite a lot of buzz recently in the Linux/Ubuntu/Launchpad world, also seems to have Windows support. http://bazaar-vcs.org/

Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --[[User:Hegemon Skall|Hegemon Skall]] 13:32, 26 January 2007 (PST)

=== Comparisons ===
Thought these might be useful, basically a list of features supported by each VCS:

http://bazaar-vcs.org/RcsComparisons
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
--[[User:Hegemon Skall|Hegemon Skall]] 17:38, 27 January 2007 (PST)

Hegemons Login Analysis

2007-01-27T07:36:34Z

Hegemon Skall: Checksum info

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

The function to parse the message_template.msg file is in /linden/indrea/llmessage/message.cpp in the Second Life viewer source and the number just appears to be in the order they are in the file (seperate counters for how medium and low frequency messages.

The code used to generate the checksum, around line 1000:
<pre>
snprintf(formatString, sizeof(formatString), "%%%ds", MAX_MESSAGE_INTERNAL_NAME_SIZE);
messagefilep = LLFile::fopen(filename, "r");
if (messagefilep) {

fseek(messagefilep, 0L, SEEK_SET );
while(fscanf(messagefilep, formatString, token) != EOF) {
// skip comments
if (token[0] == '/') {
// skip to end of line
while (token[0] != 10)
fscanf(messagefilep, "%c", token);
continue;
}

checkp = token;
while (*checkp) {
mMessageFileChecksum += ((U32)*checkp++) << checksum_offset;
checksum_offset = (checksum_offset + 8) % 32;
}
// Code here to actually process the entries, see source for more info
</pre>

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
Here out client is requesting a checksum of the template file so it can check its version matches.

<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID.

This is where my knowledge starts to get confuzzled as the bytes don't seem to be in order though as it seems to be the end bytes (not the very end, befoure the LLUID) that contain the actual version information 1 and 13, but no patch or server versions also the LLUUID is in its correct position at the end, its possible that the bytes are in reverse order. I also don't know what the flags are for.

<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1

One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols.

The server replied to the packet befoure it ACK it, its also possible to embed the ack into other packets by setting the ack flag so sending a separate ACK which is made redundant by the fact it already replied is probably a small bandwidth waste but anyhow.

<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed.

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

=To be continued=
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file
How to get the checksum/non fixed messageIDs

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Viewer Architecture

2007-01-27T06:19:09Z

Hegemon Skall: /* Learn by Example */

{{OSWikiLearnBox}}

The Second Life client (also known as the "viewer") is a complex piece of software. It can be visualized as a streaming media client like RealPlayer, a game engine like Quake 3, or a web browser.

First you'll need to learn some terminology like "agent", "sim", and "region" in the [[glossary]].

== Learn by Example ==
* [[Adding a menu item]]
* [[Adding a dialog]]
* [[How movement works]]
* [[How the camera works]]
* [[How login works]]
* [[Hegemons Login Analysis]]
* [[How keyboard processing works]]
* [[How scripts work]]
* [[The lifetime of a session]]
* [[Adding a preference]]

== Major Systems ==
* [[Message System]] - reliable and unreliable transport over UDP
* [[Image System]] - prioritizes and decodes JPEG2000 images into OpenGL textures
* [[Viewer Object System]] - objects in scene for rendering and editing
* [[Rendering System]] - from viewer object to drawable to face to vertices to graphics card
* [[Culling]] - octree and occlusion based culling to speed rendering
* [[UI Widgets]] - cross platform buttons, scroll bars, etc.
* [[UI Floaters]] - dialogs and windows built from XML files
* [[Asset System]] - transport for animations, sounds, notecards, scripts, etc.
* [[Inventory]] - server-side storage of assets for each user
* [[Sound System]] - cross platform audio based on FMOD
* [[Movie System]] - QuickTime-based video on object surfaces
* [[VFS]] - cached data is held in two "virtual file systems" in large files on the client
* [[Selection Manager]] - holds extended information for selected objects and allows editing
* [[Avatar Appearance]] - appearance is constructed from a mesh, parameters to deform the mesh, and textures to describe clothing
* [[Web Browser]] - the integration of the viewer with the web.
* [[Avatar Profiles]]
* [[Groups]]
* [[L$ System]]
* [[Tools]] - anything that takes effect when you click your mouse on the world view.

== Threads ==
The viewer is a single process with a few threads:
* Main thread -- The input/output main program function (including rendering).
* VFS thread -- Thread responsible for reading/writing to the local virtual file system.
* LFS thread -- Thread responsible for some reading/writing to the local native file system.
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Image thread -- Thread responsible for requesting and decoding image data
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Worker Threads -- Threads designed to do cpu intensive background tasks
** These threads may be paused during rendering so as not to reduce performance (design in-progress)

== Program Flow ==
# Initialize - newview/viewer.cpp :: main()
# Loop - newview/viewer.cpp :: main_loop()
#* Gathers keyboard and mouse input
#* Pumps the TCP i/o
#* idle()
#* Render the frame
#* let filesystem and worker threads process
# Shutdown

== Sources of Input ==
* The [[Message System]].
** Assets through the [[Asset System]], transmitted using the [[Transfer Manager]], and extracted from the [[VFS]].
** Files through [[Xfer Manager]].
* Files copied out of a [[VFS]] into local file store and read through c/c++/ll file API.
* XMLRPC calls such as [[Authentication Flow|login]] and [[Buying Land and Currency]].
* HTTP GET/POST to the [[Backbone]]. This is not yet in use.
* Streaming music and videos.
** Quicktime.
** FMOD.
* The web browser.

== User Guides ==

* [[Viewer coordinate frames]].
* Known [[Client_parameters]]
* Known Client Parameters on [http://lslwiki.com/lslwiki/wakka.php?wakka=newview&show_comments=1 LSLwiki.com]
* Known [[defines]]
* [[Godmode]] - what Lindens can do

Hegemons Login Analysis

2007-01-27T05:52:48Z

Hegemon Skall: Changed heading depth

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
Here out client is requesting a checksum of the template file so it can check its version matches.

<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID.

This is where my knowledge starts to get confuzzled as the bytes don't seem to be in order though as it seems to be the end bytes (not the very end, befoure the LLUID) that contain the actual version information 1 and 13, but no patch or server versions also the LLUUID is in its correct position at the end, its possible that the bytes are in reverse order. I also don't know what the flags are for.

<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1

One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols.

The server replied to the packet befoure it ACK it, its also possible to embed the ack into other packets by setting the ack flag so sending a separate ACK which is made redundant by the fact it already replied is probably a small bandwidth waste but anyhow.

<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed.

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

=To be continued=
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file
How to get the checksum/non fixed messageIDs

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-27T05:51:00Z

Hegemon Skall: Added info about libsecondlife XML-RPC login stuff

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
Here out client is requesting a checksum of the template file so it can check its version matches.

<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID.

This is where my knowledge starts to get confuzzled as the bytes don't seem to be in order though as it seems to be the end bytes (not the very end, befoure the LLUID) that contain the actual version information 1 and 13, but no patch or server versions also the LLUUID is in its correct position at the end, its possible that the bytes are in reverse order. I also don't know what the flags are for.

<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1

One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols.

The server replied to the packet befoure it ACK it, its also possible to embed the ack into other packets by setting the ack flag so sending a separate ACK which is made redundant by the fact it already replied is probably a small bandwidth waste but anyhow.

<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed.

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

The libsecondlife [http://www.libsecondlife.org/wiki/Login login] page has more information about the valid responses, pasting one of those into netcat should yield some results, looks like you could use it to make custom messages pop up :)

==To be continued==
How to get the checksum/non fixed messageIDs
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

SecuredTemplateChecksumRequest

2007-01-27T05:34:33Z

Hegemon Skall: /* Usage and Notes */

{{ProtocolNav}}
==Message Layout==
<pre width=80>
{
SecuredTemplateChecksumRequest Fixed 0xFFFFFFFA NotTrusted Unencoded
{
TokenBlock Single
{ Token LLUUID }
}
}

</pre>
==Usage and Notes==
[[Category:Messages]]
[[Category:Common Messages]]
This asks for a TemplateChecksumReply from the other node. It is used to ensure both nodes are using the same message template version.

Hegemons Login Analysis

2007-01-27T05:02:14Z

Hegemon Skall: Readded more nuked content

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>
===Description===
In english please?:
<li>[Client>Server] 0xFFFFFFFA - Please ACK this, Sequence #01, SecureTemplateChecksumRequest, LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
Here out client is requesting a checksum of the template file so it can check its version matches.

<li>[Server>Client] 0xFFFFFFFF No special flags, Sequence #01, TemplateChecksumReply, <This is the checksum and version info>,
LLUUID is [16-89-02-b0-75-38-50-f1-8f-41-fe-a7-6e-9a-f7-98]
This is the servers response, checking the correct [https://wiki.secondlife.com/wiki/TemplateChecksumReply template] shows that it has 32bits(4bytes) of checksum info, then 8bits (1byte) for each for major, minor, patch and server version information and then another 4 bytes for flags, it then has a LUUID.

This is where my knowledge starts to get confuzzled as the bytes don't seem to be in order though as it seems to be the end bytes (not the very end, befoure the LLUID) that contain the actual version information 1 and 13, but no patch or server versions also the LLUUID is in its correct position at the end, its possible that the bytes are in reverse order. I also don't know what the flags are for.

<li>[Server>Client] 0xFFFFFFFB - NoFlags, I am acknowledging that i received 1 packet from you, packet number #1

One of the 01 bytes is the number of packets that are being acknowledged, its possible to acknowledge more than more packet in one ACK reply. The other is the ID of the acknowledged packet. Looking at the [https://wiki.secondlife.com/wiki/PacketAck PacketAck template] you will notice there is just one unsigned 32 bit, no counting byte is listed, I believe that is because of the word 'variable', each ACK is assigned 4 bytes but the 01 appears in the first byte so it would seem to be in reverse order (might be relevant for decoding the previous entry). The 4 zeros bytes at the end Wireshark lists as trailing bytes so they are probably padding required by the network protocols.

The server replied to the packet befoure it ACK it, its also possible to embed the ack into other packets by setting the ack flag so sending a separate ACK which is made redundant by the fact it already replied is probably a small bandwidth waste but anyhow.

<li>[Client>Server] 0xFFFFFFFD - NoFlags, CloseCircuit
Having received the version info, the client closes this connection, it will now attempt to connect to the login server which is a TSL encrypted webserver, with XML-RPC calls. No extra data is needed.

===Very simple C# server===
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

==To be continued==
How to get the checksum/non fixed messageIDs
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-27T04:58:22Z

Hegemon Skall: Added some stuff the wiki killed :/

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

===Raw===
<pre>
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>

=Very simple C# server=
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

=Step 2=
Now that the client passes step 1, it will now attempt to access the login page using XML-RPC calls.

We can override the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

==To be continued==
How to get the checksum/non fixed messageIDs
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-27T04:55:09Z

Hegemon Skall: I Think the wiki is having problems with this much on one page, keeps duplicating and ereasing stuff

Hegemons Login Analysis

2007-01-27T04:53:54Z

Hegemon Skall: /* Valid Response */

Hegemons Login Analysis

2007-01-27T04:53:23Z

Hegemon Skall: /* Step 2 */

Hegemons Login Analysis

2007-01-27T04:52:59Z

Hegemon Skall: /* Step 2 */

Hegemons Login Analysis

2007-01-27T04:43:50Z

Hegemon Skall: Removed dupe server code, whoopse

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

<pre>
===Raw===
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>

=Very simple C# server=
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

==Step 2==
Now that the client authenticates step 1, it will now attempt to access the login page using XML-RPC calls.

We can overload the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

==To be continued==
How to get the checksum/non fixed messageIDs
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

Hegemons Login Analysis

2007-01-27T04:42:38Z

Hegemon Skall: /* Very simple C# server */

This page is intended to share/organize the information I learn while tinkering with the Second Life client now that its been GPLed.

I am not a guru, developer etc... I'm just playing around as a learning experience.

I am attempting to create an extremely basic server that just allows the Client to login, hopefully to a empty null world and maybe send some very basic information such as the suns position, area name, amount of money, 1 or 2 prims, flat terrain etc... I want to create it from scratch without relying on the SL viewer code or the libsecondlife stuff to ensure i understand everything. I would also like the server to handle all the elements of the login, ie not using a web server for the login stuff.

So far the server allows the completion of step 1 of the [https://wiki.secondlife.com/wiki/Authentication_Flow Authentication Flow]

Its not very advanced or prwdy and works by parroting the clients requests back to it, this is enough of a hack to trick the client into continuing however incorrect sequence numbers etc are sent.

Stuff used: netcat, wireshark(Ethereal), C#/Mono/Monodevelop

I'm doing this under Ubuntu but any form of Linux should be fine (theres also a port of SL on Solaris now apparently), netcat and wireshark have windows ports also. I have never actually learned C#, but i have done Java, C and C++ so with the help of Google its fairly easy to work it out as I go. I chose C# as I haven't used it much previously, its also being incorporate into SL for the scripting language and libsecondlife appears to be written in it.

=Step 1.=
The Authentication Flow just describes this as:

<pre>
Viewer(client)--------->User Server

* Secure Message checkum request - Protocol Level Supported? Yes/No.
* Port 12036
</pre>

which doesn't really give us an in depth description of everything thats happening or enough to make a server that does what is required, probably the quickest way is to analyses what the client does and try to emulate the servers responses.

== Redirecting the client ==
Firstly the client needs to be started with the correct command line parameter (found [https://wiki.secondlife.com/wiki/Test_Grid here]). This tells the client to send the initial UDP packets to the localhost.

./secondlife -user localhost

Then netcat need to be set to listen on UDP port 12036:

<pre>
hegemon@ender:~$ sudo nc -u -l -p 12036
@��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

@��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ

��`��+U_{q�Y)$�ͫ

��+U_{q�Y)$�ͫ[[]]
</pre>

This successfully makes the client send its response to localhost, its then not receiving anything back and disconnecting. The outputted information isn't very usefull so the next step is to fireup wireshark, set it to listen on the loopback interface and find out whats being sent (Alternatively netcat has the ability to output a hexdump also with the -o flag, its also possible to pipe the output to the 'hexdump' unix command however wireshark is probably nicer and can be used to analyze the client connecting to the actual server for comparison later).

==A timeout analysis==
===Raw Dump===
Wireshark gives us:
<pre>
Client>Server
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 01 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 60 00 00 01 ff ff ..../.. ..`.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 00 00 40 00 40 11 b7 62 c0 a8 01 03 c0 a8 .4..@.@. .b......
0020 01 03 94 ad 2f 04 00 20 83 88 40 00 00 02 ff ff ..../.. ..@.....
0030 ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 ../...y. .$*...6H
0040 be 04 ..
</pre>
===Description===
These are the 1st 3 packets, there where around 16 in total but its the same thing over and over.

So now we begin the packet analysis. We are only interested in the Data part of the packets, the first 42 bytes contains information such as source and destination ports/addresses, protocol information etc... which is what routers use to determin where to push these things around the internet to get it to your computer. This is shown in wireshark, so just select the data which highlights the following data packets.

===Packet info===
<pre>
40 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

60 00 00 01 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04

40 00 00 02 ff ff ff fa 2f c7 ac c1 79 ca f6 24 2a bc 12 e6 36 48 be 04
</pre>

You will notice there are only 2 bytes that are changing, the 1st and 4th, this is because there is no response so the client will keep resending the same data until there is one or it gives up.

By looking at the [https://wiki.secondlife.com/wiki/Packet_Layout packet layout] we can start to see what is being sent. There is also the [http://www.libsecondlife.org/wiki/Protocol_%28network%29 libsecondlife] analysis.

The first byte is the byte contains the bitmask flags, LL_ZERO_CODE_FLAG 0x80, LL_RELIABLE_FLAG 0x40, LL_RESENT_FLAG 0x20, LL_ACK_FLAG 0x10. To understand exactly whats happening in the first byte its best to look at it in binary. In the first packet we have 0x40, 4 in binary is 1000 and 0 is obviously 0000, which is 10000000, the first bit is 1 which means it wants an ack packet back so that it knows it was successfully received, if none is returned it will resend the packet, which is what packet 2 is.

The first byte in packet 2 is 0x60, in binary 10100000, in this packet the first and 3rd bits are set, so it wants an ack and it is a packet that has been resent. The 2rd packet is 0x40 again so its a new packet. not a resent one.

The next 3 bytes are marked as the sequence number, 000001, the first packet sent, then it is repeated in the resent packed and when the client decides to send a new packet rather then resend it increments it to 2. When an ack is sent back I believe it uses this sequence number for the ID, which tells the client it was received and doesn't need it to be resent.

The next bytes are listed as the 'frequency', its really means the messageID so the system knows the difference between a request for the version information and a request to close the connection, they are defined in the message template file /linden/scripts/messages/message_template.msg in the viewers source code, they are also available from libsecondlife [http://www.libsecondlife.org/template/ here] and you can also find the individual ones on this wiki [http://wiki.secondlife.com/wiki/Category:Messages here], there are 6 'fixed' ones shown near the top, we are encountering 0xFFFFFFFA which is the RequestSecureChecksum, we can check the [https://wiki.secondlife.com/wiki/SecuredTemplateChecksumRequest template] which shows that the packet only contains a LLUUID, that is the next 16 bytes and is a unique number for our client which is the remaining bytes.
This is the client check to make sure the server is talking the same protocol version.

A majority of the messages are not 'fixed' ones. The number of bytes that makes the frequency is variable, so if a byte isn't 0xFF then that byte is the last byte in the frequency. Currently I'm not sure how to convert the frequency number to the specific message, or workout the checksum as it appears the client loads the template file in (probably at compile time since it doesn't appear to be in the compiled client), and docs say it assigns the numbers at runtime, but the fixed ones are enough for the first login step and we can use what we know is a valid checksum number by asking the client for its checksum.

==Valid Response==
Lets looks at a valid response by sniffing an actual connection to the server

<pre>
===Raw===
Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 34 00 00 40 00 40 11 41 e0 c0 a8 01 03 42 96 .4..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 20 2f e6 40 00 00 01 ff ff ...n/.. /.@.....
0030 ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a ......u8P..A..n.
0040 f7 98 ..

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 40 72 bf 40 00 2d 11 e2 14 42 96 f4 97 c0 a8 .@r.@.-...B.....
0020 01 03 2f 04 94 6e 00 2c 14 38 00 00 00 01 ff ff ../..n.,.8......
0030 ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 ................
0040 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 ..u8P..A..n...

Server:
0000 00 18 f3 04 90 4c 00 e0 a0 a6 66 70 08 00 45 00 .....L....fp..E.
0010 00 29 72 c3 40 00 2d 11 e2 27 42 96 f4 97 c0 a8 .)r.@.-..'B.....
0020 01 03 2f 04 94 6e 00 15 42 79 00 00 00 02 ff ff ../..n..By......
0030 ff fb 01 01 00 00 00 00 00 00 00 00 ............

Client:
0000 00 e0 a0 a6 66 70 00 18 f3 04 90 4c 08 00 45 00 ....fp.....L..E.
0010 00 24 00 00 40 00 40 11 41 f0 c0 a8 01 03 42 96 .$..@.@.A.....B.
0020 f4 97 94 6e 2f 04 00 10 43 82 00 00 00 02 ff ff ...n/...C.......
0030 ff fd ..
</pre>

===Info===
In a slightly more readible form:
<pre>
/-Flags
|
| /-Sequence Number
| |
| | /-Frequency
| | |
+- +--+---+ +----+----+ <<<<<<<<<<<<<<<<<<<<<<<<< DATA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
40 00 00 01 ff ff ff fa 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98 <--- DATA is LLUID
00 00 00 01 ff ff ff ff 00 02 c4 e4 95 9d 00 00 00 00 01 0d 16 89 02 b0 75 38 50 f1 8f 41 fe a7 6e 9a f7 98
00 00 00 01 ff ff ff fb 01 01 00 00 00 00 00 00 00 00 \--\ \-------------------------------------------/
00 00 00 02 ff ff ff fd \ \--------\ \--\--\--\--\ \ LLUUID-/
\ \ \ \-Version info at this end?
\ \-ACK_ID \
\ (reversed) \-5 Trailing Zeros, not actually part of data
\
\-Number of ACKs in message
</pre>

=Very simple C# server=
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

==Step 2==
Now that the client authenticates step 1, it will now attempt to access the login page using XML-RPC calls.

We can overload the website with the -loginuri command. Normally the SL client will want to use encrypted TSL 1.0 but we can specify a nonencrypted url.

./secondlife -user ender -loginuri http://ender/

Then netcat can listen on port 80 and we see the following
<pre>
POST / HTTP/1.1
Host: localhost
Pragma: no-cache
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml
Content-Length: 1825

<?xml version="1.0"?><methodCall><methodName>login_to_simulator</methodName><params><param><value><struct><member><name>first</name><value><string>Hegemon</string></value></member><member><name>last</name><value><string>Skall</string></value></member><member><name>passwd</name><value><string>$1$4534d5a3257d801ba927ce39bca33aab</string></value></member><member><name>start</name><value><string>last</string></value></member><member><name>major</name><value><string>1</string></value></member><member><name>minor</name><value><string>13</string></value></member><member><name>patch</name><value><string>2</string></value></member><member><name>build</name><value><string>57209</string></value></member><member><name>platform</name><value><string>Win</string></value></member><member><name>mac</name><value><string>b5fcfb83e74517f2a8be6092995c51c7</string></value></member><member><name>id0</name><value><string/></value></member><member><name>viewer_digest</name><value><string>2bd23799-b279-8665-500a-ce27025b315e</string></value></member><member><name>options</name><value><array><data><value><string>inventory-root</string></value><value><string>inventory-skeleton</string></value><value><string>inventory-lib-root</string></value><value><string>inventory-lib-owner</string></value><value><string>inventory-skel-lib</string></value><value><string>initial-outfit</string></value><value><string>gestures</string></value><value><string>event_categories</string></value><value><string>event_notifications</string></value><value><string>classified_categories</string></value><value><string>buddy-list</string></value><value><string>ui-config</string></value><value><string>login-flags</string></value><value><string>global-textures</string></value></data></array></value></member></struct></value></param></params></methodCall>
</pre>

No thats not my real password :)

==To be continued==
How to get the checksum/non fixed messageIDs
<li> Find an appropriate response to the XML.
<li> Fix the server so it actually responds rather that parroting the packets it gets.
<li> Figure out how to incorporate the messages_template.msg file

===Step 3===
This is a server>server bit, it basically checks the password is correct, initially it won't have any security and will just auto accept the client or lookup a hardcoded value. If i get things more advanced maybe a SQL database lookup.

Another idea would be to use OpenID, the firstname would be the id and the last would be the OpenID server (the password could be anything). OpenID would be a good choice for 3rd party SL servers as it wouldn't be to hard to transfer the player from one server to another when the servers don't trust each other.

===Step 4,5===
Another Server>Server, This is intended to find which sim in the grid to use and autorize, since this is just a basic self contained server it will be itself and this can just be skipped. It will need to tell the client that though.

===Step 6===
Tell the client the sim info and other basic information.

===Step 7,8===
Client sends server information, if possible skip most of it.

=Very simple C# server=
<pre>
// This just listens on the port and sends back the packets to the client. It done some basic analysis of the packets
// Its very horrible code

using System;
using System.Net;
using System.Net.Sockets;

namespace SLLoginTest
{
public class Slog
{

public Slog()
{
int recv;
byte[] data = new byte[1024];

// Create the listening server socket...

Socket socServer = new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp);

IPEndPoint ipServer = new IPEndPoint(IPAddress.Any, 12036);

// Bind to local Address...

socServer.Bind(ipServer);

IPEndPoint ipClient = new IPEndPoint(IPAddress.Any, 0);
EndPoint Remote = (EndPoint)(ipClient);

// FIXME: These should be defines or static finals or whatever C# has
byte MASK_LL_ZERO_CODE_FLAG = 0x80;
byte MASK_LL_RELIABLE_FLAG = 0x40;
byte MASK_LL_RESENT_FLAG = 0x20;
byte MASK_LL_ACK_FLAG = 0x10;

while(true) {
data = new byte[1024];
Console.WriteLine("Awaiting packets...");
recv = socServer.ReceiveFrom(data, ref Remote);
Console.WriteLine("{0} bytes recived...", recv);

int seek = 0;
int i = 0;

// Dump the raw data
Console.Write("DATA:");
for(int j = 0; j<recv; j++) {
Console.Write(" 0x{0:X2} ", data[j]);
}
Console.WriteLine();

// This bit checks the packet flags
bool LL_ZERO_CODE_FLAG, LL_RELIABLE_FLAG, LL_RESENT_FLAG, LL_ACK_FLAG;

if((byte)(data[0] & MASK_LL_ZERO_CODE_FLAG) != 0) {
LL_ZERO_CODE_FLAG = true;
Console.WriteLine("Zero encoded");
}
if((byte)(data[0] & MASK_LL_RELIABLE_FLAG) != 0) {
LL_RELIABLE_FLAG = true;
Console.WriteLine("Reliable");
}
if((byte)(data[0] & MASK_LL_RESENT_FLAG) != 0) {
LL_RESENT_FLAG = true;
Console.WriteLine("Resent");
}
if((byte)(data[0] & MASK_LL_ACK_FLAG) != 0) {
LL_ACK_FLAG = true;
Console.WriteLine("ACK");
}
seek++; // Move to the next byte

// Read the sequence number into a 3 byte array
byte[] sequence = new byte[3];

sequence[0] = data[seek++];
sequence[1] = data[seek++];
sequence[2] = data[seek++];

Console.WriteLine("Sequence: 0x{0:X2}{1:X2}{2:X2}", sequence[0], sequence[1], sequence[2]);

byte[] frequency = new byte[4];
byte freqByte = data[1];

// Add each 0xFF byte until we reach something thats not 0xFF
// FIXME: Should stop at 4 bytes
do {
frequency[i] = data[seek];
i++;
seek++;
} while(data[seek] == 0xFF);

// We add the final frequency byte, unless it was already added in the case of 0xFFFFFFFF
if(i < 4) {
frequency[i++] = data[seek++];
}

// Print the frequency
Console.Write("Frequency: 0x");
for(int j = 0; j < i; j++) {
Console.Write("{0:X2}", frequency[j]);
}
Console.WriteLine();

// These are the basic templaces (Theres 2 more not listed here)
byte[] SecureTemplateChecksumRequest = {0xFF, 0xFF, 0xFF, 0xFA};
byte[] TemplateChecksumReply = {0xFF, 0xFF, 0xFF, 0xFF};
byte[] Ack = {0xFF, 0xFF, 0xFF, 0xFB};
byte[] CloseCircuit = {0xFF, 0xFF, 0xFF, 0xFD};

Console.Write("ST: 0x");
for(int j = 0; j < 4; j++) {
Console.Write("{0:X2}", SecureTemplateChecksumRequest[j]);
}
Console.WriteLine();

// Check to see which message was send
// This isn't a good way to handle it, it assumes a 4byte frequency and may crash
// I haven't bothered to check them all either
if(frequency[3] == SecureTemplateChecksumRequest[3]) {
Console.WriteLine("SecureTemplateChecksumRequest");
} else if(frequency[3] == CloseCircuit[3]) {
Console.WriteLine("CloseCircuit");
}

// By sending the packet back to the client we can fake the start of the login
//
// 1. V>S SecureTemplateChecksumRequest? - Viewer asks for the servers checksum
// 2. S>V SecureTemplateChecksumRequest? - Server asks for the viewers checksum
// 3. V>S TemplaceChecksumReply - Client replys to request 2
// 4. S>V TemplaceChecksumReply - Sending the clients on checksum back, answers request in 1
// 5. V>S CloseCircuit - The client has checked it matches the checksum and closes
// 6. S>V CloseCircuit - Parroted back (probably useless/ignored by client)
Console.WriteLine("Sending parrot response.");
socServer.SendTo(data, recv, SocketFlags.None, Remote);
}
}
}
}
</pre>

Hegemons Login Analysis

2007-01-27T04:21:11Z

Hegemon Skall: /* Valid Response */

Hegemons Login Analysis

2007-01-27T03:57:47Z

Hegemon Skall:

Hegemons Login Analysis

2007-01-27T03:14:30Z

Hegemon Skall:

Authentication Flow

2007-01-27T03:02:44Z

Hegemon Skall: /* Step 1 */ - Minor type

{{OSWikiLearnBox|parent=Protocol}}

== Protocol Step-by-step ==

=== Step 1 ===
Viewer(client)--------->User Server
* Secure Message checksum request - Protocol Level Supported? Yes/No.
* Port 12036

=== Step 2 ===
Viewer -----------> Login Server

* XML-RPC Func call - over HTTPS. to login. (Blocking) [[http://www.libsecondlife.org/wiki/Login#Client_XML-RPC_Request_.28Encapsulated_in_TLS_1.0.29][Login Info from libsecondlife]
* Mostly a web server (Apache) that talks to a SQL DB. Gets user info from DB (home. etc.) gets the info about which sim to connect to (IP address etc.) and drops the connection.
* First name, last name, MD5(password), viewer version, requested location

=== Step 3 ===
Login Server ------> Database

Checks actual database for authentication credentials

=== Step 4 ===
Login Server------> SIM in the Grid

* Login server decides which SIM to send the viewer to. talks to Grid
* Requests session start

Grid (of Simulators):
* inbound UDP port (for comm. with Viewer) 12035, 13000-13050

=== Step 5 ===
SIM ----> Login server (response)
* Verification that user is allowed on the SIM

=== Step 6 ===
Login server ------> Viewer (response)

* Information returned: agent id, session id, secure session id, sim ip, sim port, global location, some inventory info.
* Most IDs are UUIDs (agent id, session id, and secure session id, for example)
* Agent ID == User ID Unique and Persistent.

=== Step 7 ===
Viewer -------> Simulator (on Grid)
Handshake
* Viewer sends user id and session id

=== Step 8 ===
Viewer -------> User server
User server handshake
* Sent for presence information so Group IM works
* Confers group rights to user
* User server verifies the SIM session info via DB Presence-Agent table.(initially committed by the Login Server at the time of Sim-LoginSERVER negotiation) Step p3

Hegemons Login Analysis

2007-01-27T03:02:07Z

Hegemon Skall:

Talk:Version control repository

2007-01-26T21:32:05Z

Hegemon Skall: /* Darcs */

Talk:Version control repository

2007-01-26T21:16:18Z

Hegemon Skall:

== SVN ==

I'm happy with a read only SVN.

We are all developers. We can set up our own local SVN if we want a sandbox. [[User:Gigs Taggart|Gigs Taggart]] 15:13, 9 January 2007 (PST)

Agreed.
I think our repo should have a struture like....
* /trunk/slviewer/ Root of what we are given. You basically just need to check this one directory out to build the client.
* /tags/slviewer/slviewer-*/ tag of each revision that's distroed by LL as a set, perhaps with it's binaries, and the build outputs. (map files and .asm files anyone?)
* /branches/slviewer/slviewer-*.1/ Branches to deal with bugs that happen once a tag has been made. Any changes fixed on a branch should also be applied to the trunk too.
[[User:Kunnis Basiat|Kunnis Basiat]] 18:38, 9 January 2007 (PST)

* [[User:Adam Zaius|Adam Zaius]] 06:38, 8 January 2007 (PST) votes for SVN
** Directory structure something like:
*** /trunk -- Only editable by Linden Lab
*** /branches/users/<username>/ -- unlimited permissions by owner/creator for third-party source

Do we want to integrate the VCS with the Second Life authentication? Pluggability of authentication scheme seems like an important axis to consider. --[[User:Which Linden|Which Linden]] 09:27, 8 January 2007 (PST)

Giving users branches in SVN without a degree of trust is dangerous - purging history in SVN is intentionally very difficult, so a single (malicious) user could conceivably use up all the space in the server or host not-so-legal content (even if you svn rm something, it's still in the history). However if the trunk is pure svn, normal users can use things like svk if they want their own branches. --[[User:Ginko Bayliss|Ginko Bayliss]] 13:33, 9 January 2007 (PST)

: Very good idea to consider (VCS w/ SLA). I would highly recommend sourceforge due to its known ability to handle major traffic; however, we would not have the SLA. Despite that, there are many professional and mature tools that work directly with SVN, for example Subclipse.
: I suggest a tier level repository with modes for production, test, and development, and each with their own trunk, branches, and tags. Production is not distributed and is mainly read-only except for the few who update it. Production is updated with, and only from, approved patches from test. Test tier is updated by an approved group of individuals with patches from development tier. Test is not distributed but is not read-only like the production tier. Test is where people go to get latest working patches. It is similar to Debian's mid-tier. Development can be distributed (people can host their own local sandbox), and it is write-enabled by a larger group responsible to merge code. Once code has been basically approved as working in development, it moves to test, so several patches to development may result in only one patch to test, and that would be the same from test to production. [[User:Dzonatas Sol|Dzonatas Sol]] 10:04, 10 January 2007 (PST)

[[User:Eddy Stryker|Eddy Stryker]] 13:22, 9 January 2007 (PST) votes against SVN
* Branching/merging capabilities are hacked in, so instead of doing push or pull commands you are looking up revision numbers to figure out when you last backported and where the new merge should start
* No distributed version control like bitkeeper, git, mercurial, etc without using SVK which is a less than ideal solution
* Not designed for very large codebases like Second Life, where branching becomes unbearable
** To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out
* SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems

[[User:Kunnis Basiat|Kunnis Basiat]] 22:35, 14 January 2007 (PST)
* While I agree with the fact that branching and merging is a bit wierd in SVN, it was designed that way from the start, it was designed to get around several of the design flaws that were present in CVS, though I agree it's not as intunitive as it should be, it allows for really good tracking, but it's also a bit confusing. LL has been using SVN for a while, so they should be familiar with how version control in SVN works.
* I Find SVN to be really stable.I've never had a problem with SVN, and I've used it for a couple years professionally, and I've been helping my latest company migrate to SVN. The only annoyance I have about SVN is it's lack of an "obliterate" command, which there is a workaround for, and the schedule of an addition of the command. Other then that issue, SVN has been in use for several years, it's a well tested tool, and if any issues arise while using it, it's likley that you can find support for it. I've only had to break out svnadmin once (to deal with the lack of obliterate, and I found a step-by-step on how to do it.)
* SVN is used by KDE. It has both binary and source files, which reflects what we would be checking into OpenSL, and I think that KDE would have more users editing it, and I'm pretty sure it has a larger codebase.
* I don't know what problem you had with your repo. I am using the windows version of SVN, and I took my existing repo that I've used for other projects and checked in all of the slviewer and libs in one big checkin, with no problems. It copied all ~9000 files and 160megs in about 5 mins.
* I agree that LL creating account for every developer is very unreasonable. I think LL should host a repo that only has "gold" code on it, ready for production, with tags for each build. There should not be a sandbox for every developer. I think that we should submit patches to LL that are diffs from the head version of the repo, then a LL employee can apply the patch, then check&verify it works and passes all tests, then finally commit the patch to the repo. What would the process for a LL employee to recieve a change, validate it, and apply it to production be with Mercurial? I don't know enough about it to say what it's like.
* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

== Distributed version control ==

One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- [[User:Rob Linden|Rob Linden]] 07:25, 8 January 2007 (PST)

=== Mercurial ===
Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.
----

[[User:Baba Yamamoto|Baba Yamamoto]] votes for this.
*No central repository.
*Easier branching and merging.

=== Darcs ===

Darcs is something you may want to investigate. I've used it for other projects, and it was simple and effective enough that the less technical folks have actually started using it for their own projects, it is so simple and effective. A possible con would be that it IS written in Haskell.. but that's not that problematic. --[[User:Ky Aska|Ky Aska]] 15:59, 8 January 2007 (PST)

We tried using darcs for a while in-house, and really wanted it to work, but it would frequently never finish operations on windows because it would consume too much memory. [[User:Phoenix Linden|Phoenix Linden]] 09:25, 9 January 2007 (PST)

Out of curiosity, how long ago was darcs tried? It might've gotten better since then - though I've heard that performance during conflict resolution is still rather bad. --[[User:Ginko Bayliss|Ginko Bayliss]] 16:32, 9 January 2007 (PST)

[[User:Don Linden|Don]] and [[User:Kelly Linden|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden|Andrew Linden]] 2006.01.10 09:21 (PST)

Bazaar seems to be the hot repository of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not.