Disassembling Rediff Bol instant messenger protocol [Part 1]

Here I document my efforts to disassemble the protocol used by Rediff Bol IM client.
From the Wireshark dump, the initial connection is to the server: 203.199.83.62 at port: 1863. ie the client connects to the above mentioned address and sends a request. We see from the pcap dump that the following strings are sent in the initial request.

String  Length(decimal)  Length (Hex)
Gatekeeper2       11 (0B 00 00 00) 
GetLoginServers   15 (0f 00 00 00)
Rediff Bol8.0  build 315 24 (18 00 00 00) 
RBOL/1.2.5   10 (0A 00 00 00)
RBOL/1.2.5+HTTP_CONNECT  23 (17 00 00 00)
RBOL/1.2.5+HTTP   15 (0f 00 00 00)

The last three strings look like the client's advertisement of its capabilities for connection. Upon closer inspection, we see that for all strings, the string length is prepend'ed to the string (4 bytes). So the entire packet disassembled looks like this:

8a 00 00 00    4 total size(8a=138 total data size excluding this byte) 
00 00 00 00    4 null
00 00 00 00    4 null
0B 00 00 00    4 
Gatekeeper2    11
0f 00 00 00    4
GetLoginServers    15
5c 00 00 00    4 total (5c=92 total data size following excluding this byte)
18 00 00 00    4
Rediff Bol8.0  build 315  24
03 00 00 00    4 number of connection capability entries   
0A 00 00 00    4
RBOL/1.2.5    10
17 00 00 00    4
RBOL/1.2.5+HTTP_CONNECT   23
0f 00 00 00    4
RBOL/1.2.5+HTTP    15
      

Server Response

The server sends out the ip addresses to which the client should connect, after disconnecting from the first connection. (Full analysis of the response yet to be done)

String
RBOL/1.2.5
59.160.240.82:1863,59.160.240.82:1979,
RBOL/1.2.5+HTTP
RBOL/1.2.5+HTTP_CONNECT
59.160.240.82:80,59.160.240.82:8080,59.160.240.82:443,


RBOL/1.2.5
59.160.240.92:1863,59.160.240.92:1979,
RBOL/1.2.5+HTTP
RBOL/1.2.5+HTTP_CONNECT
59.160.240.92:80,59.160.240.92:8080,59.160.240.92:443,


RBOL/1.2.5
59.160.240.98:1863,59.160.240.98:1979,
RBOL/1.2.5+HTTP       15   0f  0f 00 00 00
RBOL/1.2.5+HTTP_CONNECT      23   17  17 00 00 00
59.160.240.98:80,59.160.240.98:8080,59.160.240.98:443,  

Login
Once the secondary address is obtained from the above response, the client disconnects the earlier connection, and reconnects to the secondary address.
A dump of the login request is :

00000000  67 00 00 00 00 00 00 00  00 00 00 00 09 00 00 00 g....... ........
00000010  53 65 72 76 65 72 31 2e  32 06 00 00 00 53 69 67 Server1. 2....Sig
00000020  6e 49 6e 44 00 00 00 1b  00 00 00 62 69 6e 75 70 nInD.... ...binup
00000030  61 75 6c 32 30 30 37 40  72 65 64 69 66 66 6d 61 aul2007@ rediffma
00000040  69 6c 2e 63 6f 6d 07 00  00 00 XX XX XX XX XX XX il.com.. ..XXXXXX
00000050  XX 00 00 00 00 00 00 03  00 00 00 33 31 35 09 00 X....... ...315..
00000060  00 00 57 69 6e 76 65 72  3a 34 38                ..Winver :48

Once again the data length is prepend'ed to the data, so we have the request as :
(I have the password blanked out as XXXX..).

Strings     Length(dec) Hex
67 00 00 00        67 = 103 dec (total size following)
00 00 00 00    4   null
00 00 00 00    4   null

09 00 00 00    4 
Server1.2      9   09 00 00 00

06 00 00 00    4
SignIn         6   06 00 00 00

44 00 00 00    4   44 = 68 in dec (total size following)

1b  00 00 00   4
binupaul2007@rediffmail.com  27  1b 00 00 00
07 00 00 00    4
XXXXXXX        7  07 00 00 00

00 00 00 00
00 00 03 00
00 00 33 31 35    13    ??????(*magic?*)
09 00 00 00    4
Winver:48    9  09 00 00 00

Finally we are able to login, and the server responds with alerts, contact list and stuff. (Yet to fully analyze the response). I am now able to login via my Java program.
Other observations.
The password is sent in clear text. If the indicated data size is greater than the one sent, the server waits till the client sends more data. If my client claims 3 connection capabilities, but only requests the IP addresses for two, I get a response which contains:

Nitro::UnknownRemoteException2
./../Interfaces/Gatekeeper/IGatekeeper2_nitro.cpp

It seems the server is all CPP code. Ugh !
Conclusion as of now: A thorough analysis of the protocol could ultimately lead the way for a gaim/pidgin plugin or a Java client. I'll dig deeper when I find more time !