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
C-code example: (assuming that pl holds the packet length)
int r1, r2;
r1 = 0x18 + rand() % (PL - 0x18);
r2 = rand() % 0xFF;
- 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+=4)
{
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];
