HI John,
Just confirming about the zero encoding.
Because the packet id cannot be 0, zero encoding will not affect fixed, medium, or high packet headers.
For low packets wehre the packet id can be 2 bytes, the 1st byte could be 0. And if zero encoding is used, i.e., opcode 0x80, and packet id of, say 5, could take up 3 bytes? 00 01 05? (bytes 7 8 and 9)? is that what you are saying?
if zero encoding is not used, it will just be the staight 00 05 right? (byte 7 and 8).
Thanks so much!
donna
John Hurliman <[EMAIL PROTECTED]> wrote:
donna
John Hurliman <[EMAIL PROTECTED]> wrote:
If you are just trying to determine whether network traffic is Second
Life traffic or not, here are some heuristics you can use:
* The server UDP port will be either 12035 or 1300 to 1350 as Phoenix
said. 12036 as well?
* The first byte of the UDP payload is the flags field. There are only
three known flags (MSG_APPENDED_ACKS, MSG_ZEROCODED, MSG_RELIABLE,
MSG_RESENT) so if the first byte is something other than zero or any
combination of those bitflags you can discard it.
* The second byte could be thought of as part of the flags field, but
since there are no flags greater than 256 the second byte will always be
zero for SL traffic.
* Bytes three and four are a network order sequence number that
increments mostly consistently, with a separate incrementer for each
simulator connection. Exceptions are resent packets which will have
their original sequence number, and if the sequence reaches 65535 it
loops back to 0. This is only really useful if you are doing stateful
packet inspection and aren't required to positively identify every SL
packet.
-- The rest of the packet is subject to zerocoding if the MSG_ZEROCODED
flag is set, so you'll have to take that in to account. In the testing
branch of libsecondlife (/branches/pregen/) we do a very fast zerocoding
expansion of just the header. 0 is not a valid ID so medium and high
packets will never have their header altered by zerocoding, so if bytes
five and six both equal 0xFF and byte seven equals 0, then byte eight of
the header (which will be 1) is actually equal to byte nine. I hope that
wasn't too confusing, I can point you to the code if you're interested.
The rest of the header before this (the flags and the sequence number)
are never zerocoded.
* For medium and low frequency packets (fixed packets are considered
low) the fifth byte will be 0xFF, so if you are using a scoring system
this could add points to the score. There are only so many high packets
(32 in the latest release), so if byte five is not 0xFF but it's greater
than some safe value, lets say 40 then it's definitely not SL traffic.
* The same principal can be applied to medium packets. In the latest
release there are only 20 of them, so if byte five is 0xFF and byte six
is greater than some safety value then it's not SL traffic. Low packets
are slightly more difficult since there are the so-called "fixed"
packets with a value of 0xFFFFFFxx (that corresponds to bytes five, six,
seven, and eight), but if bytes five and six are both 0xFF and byte
seven _isn't_ 0xFF, then the ID number (bytes seven and eight in network
order) must be less than a magic value. There are currently 506 low
packets but you can expect many of these will be removed and added over
time. 550 would still probably be a safe magic value for at least two
months, after that who knows. The protocol is getting some real
structural changes anyways to incorporate HTTP calls carrying XML data,
but that won't be in production for a little while.
* If you just want to identify if a connection to Second Life is being
made, the HTTPS session to login.*.lindenlab.com is a dead giveaway.
-- Anything beyond header analysis would require keeping multiple copies
of the message_template.msg and keywords.txt files (one set from the
stable grid, one set from each preview grid that is currently open) and
actually trying to deserialize every potential UDP packet and checking
for deserializing errors. The keywords.txt file has to be extracted from
the Second Life binary with a string of UNIX tools, and we
(libsecondlife) are currently the only group attempting to keep updated
releases of this available. We currently only publish keywords files for
the stable grid though, this may change in the future.
* There is another way to detect the traffic although it's slightly
hackish. Since the ID numbers for things like UseCircuitCode, PacketACK
and EconomyDataRequest are unlikely to change in the near future you can
build a fingerprint of the traffic generated at login and match against
it. This will only work for the connection to the first simulator.
However there is a single giveaway packet for every simulator
connection. The server will always respond to a connection with an ACK
for packet ID 1, so the entire packet will look identical coming from
every sim. 0x00 0x00 0x00 0x00 (or maybe 0x01, I forget where the
sequence number starts) 0xFF 0xFF 0xFF 0x0FB 0x01 (indicating there is
one block in the packet) 0x01 0x00 0x00 0x00 (a little endian unsigned
integer, value of 1). That's a 13 byte payload with an exact signature
and a predictable port range. Again if you are using stateful packet
inspection you will know any more traffic coming from that IP address or
going to it is SL traffic.
The last suggestion is by far the easiest to implement, hopefully that
will work for you.
John Hurliman
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail.
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
