
From mdouglass@techie.com Mon May  4 14:01:42 1998
Date: Thu, 30 Apr 1998 18:24:53 -0400
From: Matthew Douglass <mdouglass@techie.com>
Reply-To: icq-devel@tjsgroup.com
To: icq-devel@tjsgroup.com
Subject: [ICQdev] Version 4 Peer to Peer Update

Here is my updated descriptions of the V.4 peer to peer protocol:

Any questions, feel free to ask, also make sure to read the notes at the
end, they're interesting.

Updates:
* Some new message types are included (URL, File Xfer, Chat, Contact)
* More info on random magic at start
* Extended Packet Description for Chat and File Xfer

To Do:
* Phone Request Message Type
* Figure out the rest of the extended packet description

PACKET DESCRIPTION
------------------
xx xx                     2 bytes                 Length (separate TCP
packet)
xx xx xx xx               4 bytes                 Source UIN
04 00                     2 bytes                 Protocol Version Number
xx xx xx xx xx xx xx xx   8 bytes                 Random Magic
xx xx xx xx               4 bytes                 Source UIN #2
xx xx                     2 bytes                 Message Type
                                                    (below)
xx xx                     2 bytes                 Message Length
variable                  MsgLen bytes            Message
                                                    (NULL Terminated)
xx xx xx xx               4 bytes                 Source IP Address
xx xx xx xx               4 bytes                 Source "Real" IP Address
xx xx 00 00               4 bytes                 Source Port
04                        1 bytes                 Magic
                                                    (Possible Version #??)
xx xx                     2 bytes                 Status
                                                    (below)
xx xx                     2 bytes                 Initiator
                                                    (below)
BEGIN EXTENDED PACKET AREA (File Transfer + Chat Only)
xx xx xx xx               4 bytes                 Extended Packet Type
        (below)
xx xx                     2 bytes                 Sub-Message Length
variable                  SubMsgLen bytes         Sub-Message
                                                    (NULL Terminated)
xx xx xx xx               See Ext. Packet Type    Sub-Message Data #1
                                                    (below)
00 00 00 00               4 bytes                 Sub-Message Data #2
                                                    (Below)
END EXTENDED PACKET AREA
xx xx xx xx               4 bytes                 Sequence Number
                                                    Starts at 0xFFFFFFFF and
counts down
Message Type Values:
  Message (0x0001)
  Chat Offered (0x0002)
  File Xfer Canceled (0x0003)
  URL (0x0004)
  Contact (0x0013)
  File Xfer Offered (0x3EEE)

Status Values:
  Online (0x0000)
  Away (0x0004)
  Occupied (0x0009)
  DND (0x000A)
  Not-Available (0x000E)

Initiator Values:
  User-Initiated (0x0010)
  Auto-Reply (0x0000)

Extended Packet Type Values:
  Chat (0x00000001)
  File Xfer (0x00000000)
  I have a theory (completely unproved) that this is a mapping of which
sub-message data blocks are valid.  Consider it to be declared thus:
DWORD dwSubBlocksExists[2];
#define EXISTS 0x0000
#define DOESNOTEXIST 0x0001
  Like I said it is a theory.. could just as easily be that file
xfer's just have extra data.

Sub-Message Data #1 Values:
  File Xfer Offered (File Size)
  File Xfer Canceled (0x0000)
  Chat (0x0000)

Sub-Message Data #2 Values:
  File Xfer (0x0000) (this may belong to file size too)
  Chat (non-existent)

NOTES
------
* Integer Values
  These are ordered intel style, meaning:
  0x12345678 would show up as 78 56 34 12
* When sending URLs, Message is of the following format
  DESCRIPTION(0xFE)URL  where (0xFE) represents the single byte (in hex) FE

* When sending contacts, Message is of the following format
  Number(0xFE)UIN(0xFE)Name
  Where UIN and Name are repeated Number times
  Everything is in ASCII (ie if there are 10 contacts sent, then the first
two bytes would be 0x31, 0x30

* When sending file requests, Message is the file description, Sub-Message
is the file name

* When sending chat requests, Message is the chat description, Sub-Message
appears always NULL

* Message Type in acknowledgement packets is the same as the message type in
the original packet.  I think this is true, but am not positive yet.  I will
give more info as it becomes available

* Source Port
  This *usually* appears to be source port.  I'm not positive that it always
is.  When it isn't it appears to be (Source Port - 1)  I can find no pattern
describing when it is either of those though.

* And most importantly Random Magic and Source UIN2:
  These 12 consecutive bytes are the most confusing to me.  Here is what
happens:
  A) 6 bytes of random, 2 bytes of 0x00, 4 bytes of Source UIN
  B) 10 bytes of random, 2 highest bytes of Source UIN
  C) 12 bytse of random
  A appears most often, B every now and then, and I've only seen C once, and
it may have been my mistake, I can't check to be sure. I can find no pattern
to either the random data or when which of A, B or C occurs.  Any help would
be appreciated.  Here are some samples with message type (with source UIN if
it was affected)

RANDOM MAGICS:
FA C6 EE CA 1A 2A 00 00   (MSG "PQRS" to JASMIL)
E7 2E 72 F5 99 5F 00 00   (MSG "PQRS" to JASMIL)
DC EC FF E2 EB 41 00 00   (MSG "PQRS" to JASMIL)
B5 D2 00 DC 72 DB 3D 10   (URL "URL,DESC"to JASMIL)
F6 53 42 00                 + overwrite of SourceUIN2
DD B3 42 C1 3A CC 75 69   (CONTACT to JASMIL)
BE 44 42 00                 + overwrite of SourceUIN2
F6 E4 FF C2 03 39 06 85   (FILE XFER OFFER to JASMIL)
87 B1 53 85                 + overwrite of SourceUIN2
F4 7E FB F3 8C CF 54 DD   (FILE XFER CANCELED to JASMIL)
36 47 42 00                 + overwrite of SourceUIN2
FE 1C 00 D7 8F AC 5E 7B   (CHAT OFFER to JASMIL)
0B 24 42 00                 + overwrite of SourceUIN2
F4 5E BD C0 58 F0 B4 F3   (CHAT CANCELED to JASMIL)
E2 78 42 00                 + overwrite of SourceUIN2

96 EA FE CE B4 93 00 00   (AUTOREPLY from JASMIL)
8B 02 FF FF B4 C2 00 00   (AUTOREPLY from JASMIL)
B0 C0 00 EA 0B 1C 68 19   (AUTOREPLY from JASMIL when AWAY)
D7 76 6E 00                 + overwrite of SourceUIN2
D9 FE 25 D0 4F 92 00 00   (AUTOREPLY from JASMIL)
B1 9F FF FF B5 C2 00 00   (AUTOREPLY from JASMIL)


That's all for today.  I think that's enough to bomb you with at one time.

Matthew Douglass <mdouglass@techie.com>
IT Contract Services
IT Disk Recovery Team


          =====================================================
          The "unoffical, not-sponsored-by-Mirabilis-one-bit"
          ICQ Clone Development List
