Chat Mode Protocol
User to user chat mode or single-chat is much more complicated than anything
else in the ICQ protocol. Add in multi-chat and the whole process becomes down
right convoluted. It has taken this author several months to work out just how
the whole framework of single-chat and multi-chat all meshed together. After
much study it finally became clear that the listen() port used was key to
understanding the whole process. It turns out that single-chat is actually a
striped down multi-chat, not, as was originally thought, multi-chat being a
special case of, or built on top of, single-chat.
As stated, the listen() port is key as it controls who connects with whom and
whether or not the chat mode is single or multi. From here on out, a “Chat
Session” will refer two or more clients connected in such a way that the sent
and received text from all members will be seen within a single window. Each
chat listen() port controls its own chat session. In other words, each chat
session will have exactly one chat listen() port no matter how many users are
participating in the chat session.
To initiate single-chat mode, a user requests another user to enter chat. The
requester's client will create a chat listen() port at this time, however, it
will not be passed to the receiver in the message packet. (This is the listen()
port used if someone else wants to join this session.) Next, the receiver
accepts and the receiver's client opens a new chat session listen() socket and
passes its port in the message ACK back to the requester. The requester's client
then attempts a connect() on that port. The connection is made, the initial
setup packets are passed back and forth and single-chat mode is entered.
Here is the chat mode section of the message packet as sent by the requester:
UWORD SessionLen; /* Always 0x0001 for single-chat. */
char Chat_Session[]; /* Always 0x00 for single-chat. */
UWORD Chat_RevPort; /* Always 0x0000 in the message packet. */
UWORD Chat_X2; /* Always 0x0000, padding for port. */
ULONG Chat_Port; /* Always 0x0000 in the message packet. */
Here is the chat mode section of the message ACK packet:
UWORD SessionLen; /* Always 0x0001 in the ACK packet. */
char Chat_Session[]; /* Always 0x00 in the ACK packet. */
UWORD Chat_RevPort; /* The chat listen() port in network order. */
UWORD Chat_X2; /* Always 0x0000, padding for port. */
ULONG Chat_Port; /* The chat listen() port in intel order. */
The first method to initiate multi-chat mode starts when a user that is
already in single-chat session (as described above) requests another user to
join the chat session that is already in progress. The initial message packet
will contain a comma separated list of all users already in the chat session,
i.e. “User1, User2, User3”, and port of the listen() socket that was created
when the requester's client first sent/received a chat request message packet.
Next, the receiver accepts and the receiver's client opens a chat listen()
socket and its port is passed back in the ACK packet. After sending the message
ACK packet, the receiver then attempts a connect() on the port passed in the
message packet. The connection is made and the initial setup packets are passed
back and forth. In these setup packets, the requester's client will pass some
information on the other clients in the chat session. This information allows
the receiver's client to attempt connect()s with those other users in the chat
session. Once all the connections are made and the setup packets are passed
between the receiver's client and the other members of the chat session, a
multi-chat session is established between all users.
Here is the chat mode section of the message packet as sent by the requester:
UWORD SessionLen; /* Length of the Chat_Session text. */
char Chat_Session[]; /* Comma separated list of all those in the session. */
UWORD Chat_RevPort; /* Chat listen() port for this session in network order. */
UWORD Chat_X2; /* Always 0x0000, padding for port. */
ULONG Chat_Port; /* Chat listen() port for this session in intel order. */
Here is the chat mode section of the message ACK packet:
UWORD SessionLen; /* Always 0x0001 in the ACK packet. */
char Chat_Session[]; /* Always 0x00 in the ACK packet. */
UWORD Chat_RevPort; /* Chat listen() port for this session in network order. */
UWORD Chat_X2; /* Always 0x0000, padding for port. */
ULONG Chat_Port; /* Chat listen() port for this session in intel order. */
The next method used to enter into multi-chat is when a user requests to chat
with a receiver that is already in a chat session. In this instance, the chat
portion of the message packet will be used in the exact same manner as if
initiating a normal single-chat session. The requesting client does not know or
care that the receiver is already participating in a chat session. Once the
receiver receives the chat request, the user selects the join option and chooses
a chat session already in progress. At this point, instead of the receiving
client making a new chat listen() socket, it passes the port of the chat
listen() socket previously created when the first chat session was initiated.
(Now, if the receiving user had NOT chosen the join option, a new listen()
socket would be created and a single-chat session would result with the receiver
having two chat windows open at once.) When the requesting client receives the
ACK packet, it attempts a connect() on that port. After the connect succeeds,
the chat initialization packets are passed back and forth. At this point the
requesting client learns of the other clients also in the chat session and
attempts to connect() with each of the other clients. After all this a
multi-chat session is in progress.
Finally, the last case is where both the requester and receiver are both in a
chat session already. The PC ICQ clients do not allow for the merging of two
already in progress chat sessions. If the requesting user selects the Join
option, the receiver will not be given the Join option, and if the requester
does not select Join, then the receiver is allowed the Join option. Then one of
the above three cases will be the resulting method used to initiate a chat
session.
Here are the chat initialization packets in detail. There are three packets
passed during the initialization phase. The client that performed the connect()
will send the first packet (with the exception of when a Reverse TCP Connect is
used as stated above.) The receiver will respond with the second packet, and the
requester sends the third and final packet. At this point the socket becomes a
character stream. That portion of the chat mode will be described later.
First chat packet:
ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */
ULONG HiVersion; /* Negative of the TCP protocol version. V2 = 0xFFFFFFFE */
ULONG UIN; /* Local UIN. */
UWORD NickLen; /* Length of the nick. */
char Nick[21]; /* Local nick. */
UWORD RevPort; /* Chat session port in network order. */
ULONG TextColor; /* Text or font color in the form 0x00RRGGBB. */
ULONG BackColor; /* Chat window background color in 0x00RRGGBB form. */
UBYTE X1; /* Always 0x00. */
Second chat packet:
ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */
ULONG UIN; /* Local UIN. */
UWORD NickLen; /* Length of the nick. */
char Nick[21]; /* Local nick. */
ULONG TextColor; /* Text or font color in 0x00RRGGBB form. */
ULONG BackColor; /* Background color in 0x00RRGGBB form. */
UWORD Version; /* Version of TCP protocol used by the client. */
UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */
ULONG Port; /* Chat session port in intel order. */
ULONG IP; /* LAN External. */
ULONG RealIP; /* LAN Internal. */
UBYTE TCP_Flag; /* TCP capable flag again. */
UWORD X2; /* Random, unique chat session identifier, use unknown. */
ULONG FontSize; /* Size of the font. */
ULONG FontFamily; /* Font family? Used for font substitution? */
UWORD FontLen; /* Length of font name text. */
char FontName[]; /* Font name. */
UWORD X3; /* Usually 0x0002. Unknown. */
UBYTE Count; /* For single-chat, always 0x00. When entering a chat session
already in progress, this is a count of all other clients in
the chat session. */
For single chat mode, this packet ends here with a Count of 0x00. When
entering a chat session already in progress, Count will be greater than 0x00.
For each other client in the chat session the following data will be appended to
the second chat packet:
UWORD Version; /* Version of the TCP protocol used by the client. */
UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */
ULONG Port; /* Chat session port in intel order. */
ULONG UIN; /* UIN of the client being referenced. */
ULONG IP; /* LAN External. */
ULONG RealIP; /* LAN Internal. */
UWORD RevPort; /* Chat session port in network order. */
UBYTE TCP_Flag; /* TCP Capable flag. */
UWORD X2; /* Random, unique chat session identifier, use unknown. */
ULONG HandShake; /* Always 0x00000064. ICQ99b uses 0x00000065. */
It should be stated that the above additional data added to the second chat
packet will be data that was stored during a previous chat initialization phase
and has nothing to do with the client currently being connected to. Upon receipt
of this additional data, the client will attempt connect() with the supplied IP
and port. At this point a normal chat initialization phase will begin with each
of these additional clients. Also, each of these clients will send an extended
second packet containing the data of all the other clients in the current
session. Be prepared to ignore the UINs of those clients in which a connection
has already been established.
Third chat packet:
UWORD Version; /* Version of the TCP protocol used by the client. */
UWORD X1; /* Revision of the TCP protocol, used by Mac clients. */
ULONG Port; /* Chat listen() port in intel order. */
ULONG IP; /* LAN External IP. */
ULONG RealIP; /* LAN Internal IP. */
UBYTE TCP_Flag; /* TCP Capable flag again. */
UWORD X2; /* Random, unique chat session identifier, use unknown. */
ULONG FontSize; /* Size of the font. */
ULONG FontFamily; /* Font family? Used for font substitution? */
UWORD FontLen; /* Length of font name. */
char FontName[]; /* Font name. */
UWORD X3; /* Usually 0x0002. Unknown. */
It is unknown what the random number is in the chat packets. However, the PC
ICQ clients will only make one number for each chat session. If another,
separate, chat session is started, then a new random number will be generated.
To be continued...
The checkcode is calculated before encrypting the packet.
- Calculate NUMBER1.
- B8 = Byte at position 8 of the packet. (starting at position 0)
- B4 = Byte at position 4 of the packet.
- B2 = Byte at position 2 of the packet.
- B6 = Byte at position 6 of the packet.
Now put theese parts together and call them NUMBER1:
NUMBER1 = 0x B8 B4 B2 B6 (B8 = MSB, B6 = LSB)
Here's a fragment of C-code that will take care of this:
unsigned long number1;
number1 = packet[8];
number1 <<= 8;
number1 |= packet[4];
number1 <<= 8;
number1 |= packet[2];
number1 <<= 8;
number1 |= packet[6];
- Calculate the following.
- PL = Packet length
- R1 = A random number beetween 0x18 and PL
- R2 = Another random number beetween 0 and 0xFF (modulus 0x100)
C-code example: (assuming that pl holds the packet length)
int r1, r2;
r1 = 0x18 + rand() % (PL - 0x18);
r2 = rand() % 0x100;
- Calculate NUMBER2.
- X4 = R1
- X3 = NOT (BYTE at pos X4 in the packet)
- X2 = R2
- X1 = NOT (BYTE at pos X2 in the TABLE) (see TABLE section)
- NUMBER2 = 0x X4 X3 X2 X1 (X4 = MSB, X1 = LSB)
C-code example:
unsigned long number2;
number2 = r1;
number2 <<= 8;
number2 |= packet[r1];
number2 <<= 8;
number2 |= r2;
number2 <<= 8;
number2 |= table[r2];
number2 ^= 0xff00ff;
- You can now calculate the checkcode.
- CHECKCODE = NUMBER1 XOR NUMBER2
C example:
unsigned long cc = number1 ^ number2;
The Table
The algorithmes use a table of constants to found some numbers.
TABLE[X] mean data at position X in the table (starting at position 0).
POS DATA ASCII
--- ----------------------------------------------- ----------------
00 - 59 60 37 6B 65 62 46 48 53 61 4C 59 60 57 5B 3D Y`7kebFHSaLY`W[=
10 - 5E 34 6D 36 50 3F 6F 67 53 61 4C 59 40 47 63 39 ^4m6P?ogSaLY@Gc9
20 - 50 5F 5F 3F 6F 47 43 69 48 33 31 64 35 5A 4A 42 P__?oGCiH31d5ZJB
30 - 56 40 67 53 41 07 6C 49 58 3B 4D 46 68 43 69 48 V@gSA.lIX;MFhCiH
40 - 33 31 44 65 62 46 48 53 41 07 6C 69 48 33 51 54 31DebFHSA.liH3QT
50 - 5D 4E 6C 49 38 4B 55 4A 62 46 48 33 51 34 6D 36 ]NlI8KUJbFH3Q4m6
60 - 50 5F 5F 5F 3F 6F 47 63 59 40 67 33 31 64 35 5A P___?oGcY@g31d5Z
70 - 6A 52 6E 3C 51 34 6D 36 50 5F 5F 3F 4F 37 4B 35 jRn.Q4m6P__?O7K5
80 - 5A 4A 62 66 58 3B 4D 66 58 5B 5D 4E 6C 49 58 3B ZJbfX;MfX[]NlIX;
90 - 4D 66 58 3B 4D 46 48 53 61 4C 59 40 67 33 31 64 MfX;MFHSaLY@g31d
A0 - 55 6A 32 3E 44 45 52 6E 3C 31 64 55 6A 52 4E 6C Uj2.DERn.1dUjRNl
B0 - 69 48 53 61 4C 39 30 6F 47 63 59 60 57 5B 3D 3E iHSaL90oGcY`W[=.
C0 - 64 35 3A 3A 5A 6A 52 4E 6C 69 48 53 61 6C 49 58 d5::ZjRNliHSalIX
D0 - 3B 4D 46 68 63 39 50 5F 5F 3F 6F 67 53 41 25 41 ;MFhc9P__?ogSA%A
E0 - 3C 51 54 3D 5E 54 5D 4E 4C 39 50 5F 5F 5F 3F 6F .QT=^T]NL9P___?o
F0 - 47 43 69 48 33 51 54 5D 6E 3C 31 64 35 5A 00 00 GCiH3QT]n.1d5Z..
--- ----------------------------------------------- ----------------
Example : TABLE[0] = 0x59
TABLE[0xF2] = 0x69
Note: A lot of UDP packet was check to recreate this table, but some
data may be incorrect.
The Table in C static const BYTE table[] = {
0x59, 0x60, 0x37, 0x6B, 0x65, 0x62, 0x46, 0x48,
0x53, 0x61, 0x4C, 0x59, 0x60, 0x57, 0x5B, 0x3D,
0x5E, 0x34, 0x6D, 0x36, 0x50, 0x3F, 0x6F, 0x67,
0x53, 0x61, 0x4C, 0x59, 0x40, 0x47, 0x63, 0x39,
0x50, 0x5F, 0x5F, 0x3F, 0x6F, 0x47, 0x43, 0x69,
0x48, 0x33, 0x31, 0x64, 0x35, 0x5A, 0x4A, 0x42,
0x56, 0x40, 0x67, 0x53, 0x41, 0x07, 0x6C, 0x49,
0x58, 0x3B, 0x4D, 0x46, 0x68, 0x43, 0x69, 0x48,
0x33, 0x31, 0x44, 0x65, 0x62, 0x46, 0x48, 0x53,
0x41, 0x07, 0x6C, 0x69, 0x48, 0x33, 0x51, 0x54,
0x5D, 0x4E, 0x6C, 0x49, 0x38, 0x4B, 0x55, 0x4A,
0x62, 0x46, 0x48, 0x33, 0x51, 0x34, 0x6D, 0x36,
0x50, 0x5F, 0x5F, 0x5F, 0x3F, 0x6F, 0x47, 0x63,
0x59, 0x40, 0x67, 0x33, 0x31, 0x64, 0x35, 0x5A,
0x6A, 0x52, 0x6E, 0x3C, 0x51, 0x34, 0x6D, 0x36,
0x50, 0x5F, 0x5F, 0x3F, 0x4F, 0x37, 0x4B, 0x35,
0x5A, 0x4A, 0x62, 0x66, 0x58, 0x3B, 0x4D, 0x66,
0x58, 0x5B, 0x5D, 0x4E, 0x6C, 0x49, 0x58, 0x3B,
0x4D, 0x66, 0x58, 0x3B, 0x4D, 0x46, 0x48, 0x53,
0x61, 0x4C, 0x59, 0x40, 0x67, 0x33, 0x31, 0x64,
0x55, 0x6A, 0x32, 0x3E, 0x44, 0x45, 0x52, 0x6E,
0x3C, 0x31, 0x64, 0x55, 0x6A, 0x52, 0x4E, 0x6C,
0x69, 0x48, 0x53, 0x61, 0x4C, 0x39, 0x30, 0x6F,
0x47, 0x63, 0x59, 0x60, 0x57, 0x5B, 0x3D, 0x3E,
0x64, 0x35, 0x3A, 0x3A, 0x5A, 0x6A, 0x52, 0x4E,
0x6C, 0x69, 0x48, 0x53, 0x61, 0x6C, 0x49, 0x58,
0x3B, 0x4D, 0x46, 0x68, 0x63, 0x39, 0x50, 0x5F,
0x5F, 0x3F, 0x6F, 0x67, 0x53, 0x41, 0x25, 0x41,
0x3C, 0x51, 0x54, 0x3D, 0x5E, 0x54, 0x5D, 0x4E,
0x4C, 0x39, 0x50, 0x5F, 0x5F, 0x5F, 0x3F, 0x6F,
0x47, 0x43, 0x69, 0x48, 0x33, 0x51, 0x54, 0x5D,
0x6E, 0x3C, 0x31, 0x64, 0x35, 0x5A, 0x00, 0x00,
};
For a more detailed description, read Sebastien Dault's document.
Follow theese steps:
- Calculate the Checkcode (see "Calculating the Checkcode")
- Set PL = Packet length
- Calculate the encryption code:
CODE = (LONG) (PL * 0x68656C6C) + CHECKCODE (flush the overflow)
- For every longword (32 bits) in the packet, starting with 0x0A, XOR the
longword with the CODE previously calcualted added to the byte at the
corresponding position in the table. (eg. the longword at 0x0A in the packet
should be XORed with the byte at position 0x0A in the table added to CODE.)
Now the packet is encypted. All we have to now is to insert the
checkcode into the packet so the server will be able to decrypt it. The server
excpects this code to be scrambled as follows:
- Scramble the checkcode
Before inserting the checkcode you have to move the bits around a little.
It can be done like this:
A1 = CHECKCODE AND 0x0000001F
A2 = CHECKCODE AND 0x03E003E0
A3 =
CHECKCODE AND 0xF8000400
A4 = CHECKCODE AND 0x0000F800
A5 = CHECKCODE
AND 0x041F0000
A1 = A1 SHL 0x0C (SHL = Bitwise shift left)
A2 = A2
SHL 0x01
A3 = A3 SHR 0x0A (SHL = Bitwise shift right)
A4 = A4 SHL
0x10
A5 = A5 SHR 0x0F
CHECKCODETOINSERT = A1 + A2 + A3 + A4 +
A5
- Insert the checkcode into the packet at pos 0x14.
In C-code it
could look like this: /*
Encrypting the packet.
Assuming that checkcode has been calculated as previously
described, and that pl = packet length.
The packet to encrypt is pointed to by pkpptr.
*/
code = pl * 0x68656c6c + checkcode;
for(pos=0xa;pos < (pl + 3);pos++)
{
pktptr[pos]^ = code + table[pos & 0xFF];
}
/*
Scrambling the checkcode.
Assuming that cc holds the checkcode.
*/
ULONG a[6];
a[1] = cc & 0x0000001F;
a[2] = cc & 0x03E003E0;
a[3] = cc & 0xF8000400;
a[4] = cc & 0x0000F800;
a[5] = cc & 0x041F0000;
a[1] <<= 0x0C;
a[2] <<= 0x01;
a[3] >>= 0x0A;
a[4] <<= 0x10;
a[5] >>= 0x0F;
checkcodetoinsert = a[1] + a[2] + a[3] + a[4] + a[5];
