BA (Hons) Degree in Computing
Final Year Project Report
(2000/2001)
Analysis of ICQ
Protocol
|
Supervisor |
: Dr. Rocky Chang |
|
Co-examiner |
: Dr. Alvin Chan |
|
Student |
: Yu Tsun Bon |
|
Student ID |
: 97120526d |
|
Class |
: 6110 - 4 |
|
Submission date |
: 28th April 2001 |
Abstract
There are many applications that provide presence and instant messaging services. However, these two services usually exist independently. Moreover, different applications developed by different vendors will deploy different protocols. Thus the leak of intercommunication between two different applications is the main problem.
In this project, ICQ protocol was analyzed in two aspects, presence and messenger services. After having the idea of how ICQ protocol works, ICQ protocol is compared with the IMPP requirements (Instant Messaging and Presence Protocol) proposed by IETF Network Working Group.
To analyze the ICQ protocol version 5, the ICQ packets were captured in hexadecimals and convert the data into some meaningful data that people can read and understand. A SOCKS5 proxy server is setup to test the ICQ protocol traverses through SOCKS5 Proxy. Using the obtained data to investigate the operations of ICQ again the investigations are mainly focus on the presence and instant messaging services.
The result of the analysis of ICQ protocol shows that ICQ protocol version 5 met most of the requirements proposed in the memo rfc2779.
Acknowledgements
I would like to take this opportunity to thank my supervisor Dr. Rocky Chang, for his great enthusiasm on assistance of problem solving, he always gives invaluable advices to me and guides me to meet the requirements. He helps me to find those RFC proposed documents, e.g. RFC 2779 (IMPP requirements) and RFC 2778 (A Model for Presence and Instant Messaging). He also gives me the very useful web sites about ICQ protocol. If not, this project will not be possible without the help of Dr. Rocky Chang.
Also, I would like to thank my co-examiner, Dr. Alvin Chan, to my project report and presentation.
Furthermore, I would like to say thanks to the technical support team for preparation of PCs for my final year project. Also, I want to thank all the people in the mailing list “The ICQ-devel” for their kindly help and advices.
CHAPTER TWO – LITERATURE REVIEW
CHAPTER THREE - PROJECT METHODOLGY
3.1 Tools used to analyze
basic operation of ICQ and ICQ protocol
CHAPTER FOUR – ICQ PROTCOL EXPERIMENTAL RESULTS
4.3 Peer to peer
communication
CHAPTER FIVE – DISCUSSION OF THE
ICQ PROTOCOL AND IMPP REQUIREMENTS
5.1 Comparison of ICQ
protocol against IMPP requirements
LIST OF FIGURES
Figure 2. Socks5 proxy
running on Linux 6.0
Figure 4. Operation of
ICQSniff
Figure 5. Experimental
setup to investigate ICQ protocol
Figure 6. Setup to test ICQ
protocol passes through SOCKS5 firewall
Figure 7. Setup to test ICQ
protocol passes through SOCKS5 server
Table 1. Experimental setup
conditions
Table 2. The configuration
modified in order to use ICQProxy
Figure 14. Message sent
through server
Figure 15. Logical diagram
of operation of ICQProxy
Figure 16. Security setting
of ICQ
Figure 17. Authorization
request
Figure 19. Choose the type
of firewall.
Figure 18. Locate the
firewall and the port.
Figure 19. Test the
firewall setting.
Figure 20. Test the
firewall setting (server side)
Figure 21. SOCKS5 user
authentication using password
Figure 22. SOCKS5 user
authentication using password (server side)
CHAPTER
ONE – OVERVIEW
1. Introduction
As the development of network technology, the electronic mail is a very convenient way to exchange information. However, some users still think that the electronic mails are not transferred in “real-time”. Some people say that electronic mail is suitable for sending “letter” form of messages, which are relatively long in length. How about a user want to send a relatively short, urgent and real-time message? E.g. “Peter, come to see me immediately.” Instant Messaging service is developed to allow users to send messages in REAL-TIME.
1.1 Instant Messenger (IM)
Instant Messenger lets users to send electronic messages back and forth to other online users in real-time. Instant Messenger is faster than email and more private than traditional public chat rooms.
1.2 What is ICQ
ICQ stands for “I Seek You”. It is a program invented by Mirabilis. Mirabilis was founded in July 1996 by four young Israeli computer users. Yair Goldfinger, Sefi Vigiser, Arik Vardi, and Amnon Amir created the company in order to introduce a new communication tool for the Internet. At that time, Internet provided a connection for each people but the interconnections among users were still missing. As a result, they developed the technology to allow people connecting to the Internet to find and locate each other more easily and provide them a tool to communicate with each other. In November 1996, the first version of ICQ was introduced to the Internet.
ICQ is a program, which combined the Instant Messaging and Presence services. ICQ allows you to see whenever your friends are online i.e. allows you to see the presence information of your friends. You can also send text messages, URLs, chat requests, greeting cards, voice messages and transfer files. Now the latest version of ICQ provides SMS service (Short Messages System, is a technology used in cellular phones to send text messages to and from cellular phones.). ICQ also has the highest amount of users among other instant messengers, such as AIM (AOL Instant Messenger), Yahoo Instant Messenger and MSN Instant Messenger.
Restrictively speaking, ICQ is a program called Internet buddy list. The goal of the buddy list is to let you see which of your friends are online, so you can send instant messages to them.
1.3 Problem definition
ICQ, one of the most popular online conferencing systems introduces a deep impact in the way that human communicated. The user-friendly interface makes it easy to use. Single clicked of the “send” button allows you to communicate with friends on the other side of the Internet. However, the poor design of ICQ protocol makes it easy to be attacked. ICQ is not designed for mission critical applications and does not in any way guarantee users’ security. If the risk of exposure your information is unacceptable to you or if you do not want to expose IP address to other people, you should not use ICQ for information exchange.
Firewall is a component or set of components that restricted access between a protected network and the Internet, or between other sets of networks. Since Mirabilis has announced that the latest version of ICQ (ICQ2000a and above) could overcome the problem of using ICQ behind firewall. There might be something new introduced in ICQ protocol.
The lack of standards causes some serious disadvantages to the users of Instant Messengers. Unlike email, which all tend to support standards such as SMTP and POP3. Instant Messengers from different vendors cannot talk to each other and users using the same program may not always be able to traverse Firewall.
Fortunately, the IETF Network Working Group defined a standard protocol so that independent applications of instant messaging and presence could communicate with each other.
Since ICQ is an application that combines Instant Messaging and Presence services, it should follow the standard proposed by IEFT Network Working Group in the document rfc2997.
1.4 Objective
In this project, the ICQ protocol was investigated in order to understand the operation of ICQ. From the operation of ICQ, got some ideas of why ICQ was so insecure. A single homed Linux based Socks5 proxy was setup to test the ICQ behind firewall. ICQ2000 and ICQ98 were compared to see how ICQ2000 overcame the problem of using ICQ behind firewall. Also, the ICQ protocol was compared against the IMPP (Instant Messaging and Presence Protocol) Requirements defined by Network Working Group.
CHAPTER TWO – LITERATURE REVIEW
Most versions of ICQ protocol have been un-covered by a group of random users with common interest. However, each new version of ICQ client is introduced new features. Although the development of ICQ protocol version 5 is stopped, there are still many mysteries about ICQ protocol version 5.
On the Internet, there is a document about the ICQ protocol version 5,Version 5 of the ICQ protocol, by Henrik Isaksson. This document is still being updated time from time. Also since the ICQ protocol version 5 using ckeckcode to encrypt the packet for security, to investigate the ICQ protocol version 5 I needed to know the algorithm for ICQ to encrypt data.
In this project, I analyzed ICQ protocol version 5. There is a mailing list, the ICQ-devel list, all of the people joint this mailing list are interested in ICQ protocol and willing to hear and answer the questions. I have got many advices from this mailing list.
Although there is a document about ICQ protocol, the document does not mention about the details of how the ICQ protocol works related to its functions. Also the document does not robust since two versions of clients using the same protocol may have different packets for the same function. I have to read the document first and then use some tools to capture the packets and decrypted the packets when necessary. Sometimes when some unknown packets appear, I have to investigate these new packets and reverse engineer to find the packet format.
2.1 Related reading
- Version 5 of the ICQ protocol
This is a document with excellent description of the version 5 protocol. This document is written based on the version 5 protocol used by ICQ client 98. This document is not robust and being updated time from time.
- ENCRYPTION and CHECKCODE of the
ICQ Protocol V4
This document explains the algorithm of ENCRYPTION and how the CHECKCODE is calculated in the version 4 of the ICQ Protocol.
- ENCRYPTION and CHECKCODE of the
ICQ Protocol V5
This document explains the algorithm of ENCRYPTION and how the CHECKCODE is calculated in the version 4 of the ICQ Protocol.
- SOCKS5 Proxy Mini-HOWTO
This Mini-HOWTO provides a good explanation of how to setup a SOCKS5 proxy on Linux.
- Instant Messaging / Presence
Protocol Requirements, rfc2997
This document provides the requirements for Instant Messaging and Presence Protocol Requirement defined by Network Working Group. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet.
2.2 Work has been done
In this project, I used the analyzer and ICQSniff to capture the ICQ packets. From the sequence of packets I got, worked backward to know the operation of ICQ. During the experimental phrase, I got some packets those did not be described in the document “Version 5 of the ICQ protocol”. I analyzed these packets based on the certain situation of ICQ client to guess when would these packets be used. Repeatedly test the client under the same situation to capture the packets for analysis. After reading the document “ENCRYPTION and CHECKCODE of the ICQ Protocol V5”, I can decrypt the packets when necessary. With the decryption knowledge in mind, it is easy to do the reverse engineering of ICQ protocol. I have found the layout of the new packets I found during the experiment and send the packet specification to the author of the ICQ Protocol web site. I think the document will be updated next time.
In this project, I used the ICQ99 client for protocol analysis. Although ICQ99 is also using version 5 of the ICQ protocol, there are many new packets that are not described in the document. These new packets are newly introduced in ICQ99. Some protocol specifications I have worked out and will be described in CHAPTER FOUR. These packets may not be found in the document “Version 5 of the ICQ Protocol”.
In order to examine the ICQ protocol
traversal through SOCKS5 Proxy. I have to get some ideas of how the SOCKS5
Proxy actually works in protocol level. The document, rfc1928 (http://www.socks.nec.com/rfc/rfc1928.txt),
“SOCKS Version 5
Protocol” provides the full picture of how SOCKS5 Proxy works. At the same time
I have to setup a SOCKS5 Proxy server running on Linux 6.2. A SOCKS5 Proxy
server is setup to test the ICQ protocol passes through Firewall.
(SOCKS5
Proxy can be download from http://www.socks.nec.com/cgi-bin/download.pl)
Since analyzer will capture all the packets on the LAN, I setup the whole experimental setup in an internal LAN. The whole experimental setups are shown in CHAPTER THREE.
ICQ is one of the Instant Messengers and there is a memo “Instant Messaging and Presence Protocol Requirements”, rfc2779, defined by Network Working Group. So it is very interesting to analyze the ICQ Protocol and compare the ICQ protocol against the IMPP requirements defined by Network Working Group. The comparison between the ICQ Protocol and the IMMP requirements is presented in CHAPTER FIVE. Besides just compare the protocol, I will explain how the requirements are meet by ICQ protocol and give some real examples.
CHAPTER THREE - PROJECT METHODOLGY
To investigate the ICQ protocol, the following tools were used to facilitate the work.
3.1 Tools used to analyze basic operation of ICQ and ICQ protocol
1) WinPcap + Analyzer
Figure 1. WinPcap
WinPcap is a program for capturing packets and network analysis for the Win32 platforms. Analyzer is a full configurable network analyzer program for Win32 platforms. Analyzer is able to capture packets on all platforms supported by WinPcap. Generally speaking, analyzer provided a nice interface for user to use the WinPcap.
I used WinPcap to capture all the data in the experiments and used analyzer to analyze the data. Analyzer analyzes the data based on the header of the packets. It shows the data in tree structure and shows the content of the header e.g. IP addresses, Ports and the real data.
2) TracePlus32
TracePlus32 is a powerful application-level diagnostic tool for Winsock available for Win32 platforms. TracePlus32 is both a full-featured Winsock spy and data analysis tool.
TracePlus32 provides a very good feature to allow the user to examine only the sockets opened on local host. I used TracePlus32 to examine the sockets opened during the experiment.
3) ICQProxy
ICQProxy is an application that runs in your computer acting as a Socks proxy server. ICQ sends data to the ICQProxy client running on the local machine, which then tunneled the data over HTTP to one of the ICQProxy server. This server then sent that data to the real ICQ server. By doing so, the people were allowed to using ICQ behind a firewall.
ICQProxy is one of the solutions to use ICQ behind firewalls. I used ICQProxy to test the ICQ protocol pass through our campus’ HTTP proxy (proxy.polyu.edu.hk:8181).
4) Socks 5 proxy firewall
Figure 2. Socks5 proxy running on Linux 6.0
The SOCKS protocol is an open Internet standard (IETF RFC1928) for performing network proxying at the transport layer. SOCKS created a proxy which serves as a data channel for TCP communication or UDP communication based on client and server. SOCKS 5 proxy now was freely available for academic use.
I used SOCKS5 Proxy to test the ICQ protocol. In the experiment, packets were captured by WinPcap and examined to see what modifications had been done on the ICQ protocol when configured the ICQ client to support SOCKS Proxy.
5) ICQSniff
Figure 3. ICQSniff
ICQSniff is an ICQ protocol version5 sniffer. It only supports the protocol between client to server and server to client. ICQSniff is running as server and client on local machine at the same time. The server part received data from your ICQ client while client part received data from server.
I used ICQSniff to decrypt all the packets sent from client to server. From the decrypted packets, work backward to understand how ICQ protocol works.
Figure 4. Operation of ICQSniff
3.2 Experimental setup
Figure 5. Experimental setup to investigate ICQ protocol
Figure 6. Setup to test ICQ protocol passes through SOCKS5 firewall
Experimental setup to test ICQ protocol passes through SOCKS5 Proxy
In this experiment, since the ICQ peer to peer communication will use random port for communicating, I had to configure the router to make sure only allow the traffic between SOCKS5 server and external network. All the traffic from client machine to external network would be blocked.
First, I had to setup a SOCKS5 Proxy server. I chose to setup a single homed SOCKS5 Proxy server running on Linux 6.2. The SOCKS5 server was configured to accept all the packets from private LAN (192.168.0.0). There is new feature of SOCKS5 to perform authentication. Thus there are two configurations.
1. Allows any authentication, no proxy to other hosts on the internal subnet, and allows all hosts on the internal subnet to use the socks server.
2. Enable Username/Password authentication in your SOCKS v5 environment, user has to input the user name and password in order to use the socks server.
The socks5 daemon reads the configuration file when it starts and each time it receives an HUP signal. The configuration file contains the information the server needs to determine:
· The interface to use to reach an address
· When the server should connect directly to an address
· When the server should use another proxy server
· The necessary requirements to make a proxy connection
The configuration file is usually located
at etc/socks5.conf.
The entries of the configure without authentication is
#etc/socks5.conf
without user authentication
auth
- - -
permit
- - 192.168.0. - - -
set
SOCKS5_V4SUPPORT
For the configuration with user authentication, another file that contains username/password pair was created. The file is located etc/socks5.passwd. The socks5.conf file for user authentication is
# etc/socks5.conf with user authentication
auth - - u
permit - - 192.168.0. - - -
# Userlist is a comma-separated
list of individual users, with no white space and no wild card patterns.
permit u - - - - - david
set SOCKS5_V4SUPPORT
The entries for socks5.passwd is
# etc/socks5.passwd
david 12345
The setup of this experiment is shown below
Figure 7. Setup to test ICQ protocol passes through SOCKS5 server
1) The traffic between client machine and SOCKS5 Proxy server.
2) The traffic between SOCKS5 Proxy server and the router.
|
Machine |
IP address |
|
Client machine |
192.168.0.98 |
|
SOCKS5 Proxy server |
192.168.0.3 |
|
Router |
192.168.0.1 |
Table 1. Experimental setup conditions
In this setup, the client machine would send all the packets to SOCKS5 Proxy server first. Of course the packets sent from client machine must contain the SOCKS5 protocol header. If the packet does not contain SOCKS5 protocol header, SOCKS5 Proxy server will reject the packet.
Setup to test ICQProxy
ICQProxy is a program that will redirect the packets from ICQ client to the outside world through the famous http port 80 using the technique of HTTP tunneling. The ICQproxy acts as a local SOCKS Proxy server. The ICQProxy is designed for all versions of ICQ protocols. Since it only encapsulates the packet by HTTP header, it would not modify the data of the packet.
To use the ICQProxy, the default configuration of ICQ client has to be modified.
|
Item to change |
Original setting |
New setting |
|
ICQ server |
icq.mirabilis.com |
127.0.0.1 (Localhost) |
|
Port number |
4000 |
1080 (Default port for SOCKS server) |
|
Proxy server |
Do not behind SOCKS server |
Using SOCKS Proxy server |
Table 2. The configuration modified in order to use ICQProxy
In this setup, the ICQ client first sent the packets to ICQProxy, which served as SOCKS Proxy server running on the local host. The ICQProxy then uses the HTTP tunneling to encapsulate the packets and sent the packet as the http protocol through Firewall.
CHAPTER
FOUR – ICQ
PROTCOL EXPERIMENTAL RESULTS
3.1 Main Features of ICQ
There are several features those make ICQ so popular. There are some brief descriptions about main features of ICQ. After having the ideas of the main features of ICQ, it is easier to understand the purposes of some specific packets.
|
Figure 8. ICQ contact list |
The picture on the left hand side shows the contact list (buddy list) of ICQ99. On the top, the number “21596897” is my ICQ UIN (User Identify Number). Each ICQ account is assigned a unique UIN. This UIN is also associated to the message inbox. ICQ server will use this number to distinguish user from user. From the contact list, you can see the status of each user. “Online” means the user is connecting to the Internet. “Offline” means the user is disconnecting from the Internet, turning off the ICQ or enabling the invisible status. “Not In List” means the user is not added to your contact list. However, the user can still send message to you but the message must “sent through server”. “Random” means the user got your online information from the “Random chat” At the bottom of the contact list, there is your own status “Online”. |
|
Figure 9. ICQ features |
The picture on the left hand side shows all the functions what a user can perform. This menu appears when you click on a particular user on your contact list. “Message” allows you to send instant messages to this particular user. “File” allows you to send file directly to this particular user. “Web Page Address (URL)” allows you to send URL to this particular user. “ICQ Chat” allows you to send chat request to this particular user. |
|
Figure 10. Message dialogue |
The picture on the left hand side shows the message dialogue that is used to send instant message to a particular user. After typing the message you want to send, click the “Send” button. The message is sent immediately. |
|
Figure 11. Send file |
Figure 4 shows the dialogue when you want to send file to a particular user. From the dialogue you can know the destination user, file name and file size. |
|
Figure 12. Send URL |
Figure 5 shows the dialogue when you want to send URL to a particular user. From the dialogue you can get the information of the destination user, the URL and the description about the URL. When the user receives this URL on the other side, the user can invoke the browser to browse the URL. |
|
Figure 13 ICQ chat |
Figure 6 shows the window when you want to send ICQ chat request to a user. The window shows the information about the user whom you want to chat to and the topic of your chat. |
3.2 Basic operation of ICQ
In theory, for most buddy list applications you need to register yourself by some information, it is usually your IP address, which will enable others to see and message you. The buddy list application then pings somewhere (maybe server or individual) to see who’s online.
There are two ways to communicate with the buddy in your buddy list, depending on what kind of buddy list you are using. They are peer-to-peer or peer-to-server. Peer-to-peer allows you to make directly connection to your buddy’s system via Internet. Peer-to-server allows the buddy list’s server keep track of IP address and serves as a middleman when you communicate with your buddy.
It is not yet proven that which architecture is better. For example, a peer-to-server system depends on the company’s server working normally and running for the buddy list application to work while a peer-to-peer system is more difficult to deal with dynamic IP addresses, which maybe change each time a user logs on. As a result, most buddy lists use a combination of both architectures.
ICQ is an example, which combines both architectures to accomplish its goal. There are three kinds of communications in ICQ. They are client to server, server to client and client to client. The basic operation of ICQ99 is as following
1. In ICQ99, once ICQ detected the PC is connected to the Internet the client sent the first packet, which contained protocol version, UIN (User Identify Number), command (will be explained later), time of login, your TCP listening port, which will listening for direct TCP connection, your IP address and your password etc.
2. After the server received the first packet and validated it was correct. The server would send some data back to inform the client to continue sending data.
3. Client then sent second packet, which contained the information to tell server which users you wished to receive their online/offline status.
4. Server then sent the status of your buddy to you.
5. ICQ99 login process finished.
However, latest version of ICQ (ICQ2000) deploys a new protocol and the operation has been slightly changed. The basic operation of ICQ2000 is as following
1. In ICQ2000, once the TCP connection between client and server was established, the client would not send the packet first and wait until receiving the packet from server. The first packet told to the client that the server was ready for function.
2. Upon receiving the packet from server, client would send the first packet, which contained the UIN, command, your TCP listening port for listening incoming connection, your IP address and password.
3. After server received the first packet and sent back the acknowledgement, client would send the SignOn command. (I have no idea why the client needed to send the SignOn command. Because what ICQ could do now is SignOn only).
4. When server received the SignOn command and verified correctly, it would send the packets to inform client that it was ready to begin services.
5. After client got the “Host Ready” from server, client would send client version information to server. And server would send the raw data back.
6. It was time for client to know how fast client could send data to server. So client sent the packet called “Rate Request”. Server also sent back the “Rate Response”. Finally, client sent back “Rate Acknowledgement”.
7. Once the negotiation completed, client started to send buddy list to server in order to get the status of your buddies.
8. ICQ2000 login process completed.
As you could see from the login processes of two different clients, the login processes are very different. However, the peer-to-peer communications of two different clients are similar. It is because there are still many users using old version of ICQ client (ICQ99) and Mirabilis needs to make sure the compatibility of two clients. The peer-to-peer communications are shown below. There are two ways that the two clients can communicate. They are “Directly communicate” and “Send through server”.
3.3 Peer to peer communication
Directly communicate
1. During the login process, the client would send the information about its IP address, TCP listening port (This port must larger then 1024) and whether the client was TCP compatible. Once server received this information, it would save this information until the client logoff.
2. When the user whose buddy list contained your name went online, ICQ server would send the above information (IP address + Port) to that user. This user would use this information to establish direct TCP connection to you and was ready to send messages.
3. This connection would be maintained until one of two parties disconnected from ICQ server. Also this connection would only serve for one communication channel for one people. You needed to create another socket pair if you want to communicate with other people.
4. This direct communication was the default way for ICQ to send messages. ICQ client would try this method first if failure it would try another method.
Send through server
1. During the login process, the client would send the information about its IP address, TCP listening port (This port must larger then 1024) and whether the client was TCP compatible. Once server received this information, it would save this information until the client logoff.
2. You could complete the login process, which means that you had no problem to communicate with ICQ server.
3. When the user whose buddy list contained your name went online, ICQ server would send the above information (IP address + Port) to this user. Again this means the client had no problem when communicating with ICQ server. This client would use this information got from server to establish direct TCP connection with you by sending TCP initiating packet.
4. If failure after some times of retry the client will try another method to send message i.e. send through server.
5. First the client would send the message to ICQ server first using some other special packet format than the format that would be used for direct messaging.
6. After ICQ server received the message from sender, it would redirect the message to the destination.
There are some situations that the client would send the message through server.
1. When the receiver is in the status of “offline”.
2. In the case that the receiver is not in your contact list.
3. The TCP listening port is blocked by firewall.
4. In the case that the receiver did not allow you to establish direct connection with him/her (ICQ2000 new function).
In the above situations, since the client had no mean to know the IP address and the TCP listening port the ICQ client could not establish direct TCP connection with other users. The only one way to communicate is send the message through server.
Here are some details of how ICQ works.
3.4 Details of ICQ operations
Server to client communication
ICQ99
ICQ99 communicates with ICQ server through UDP port 4000 and could not support the communication on ports other than 4000.
Although peer-to-peer communication was based on TCP connection when the message sent through server the message was sent through UDP port 4000.
ICQ2000
ICQ2000 communicates with ICQ server by default through TCP port 5190. However, ICQ2000 could communicate with ICQ server through any port including port 20 (FTP), 23 (Telnet) and 80 (HTTP).
Peer-to-peer communication
ICQ99 and ICQ2000
Both ICQ99 and ICQ2000 use the same mechanism to initiate the peer-to-peer communication although the protocols are totally different. Also the protocol on the peer-to-peer communication is almost the same. Because ICQ99 and ICQ2000 are used at the same time on the Internet the peer-to-peer communication is not changed to ensure the compatibility.
1. When client A went online, client A sent its IP address and TCP listening port number to ICQ server. Let’s assume A’s IP is IP<A> and port is P<A>.
2. Now when client B went online, client B would send its IP address and TCP listening port number to ICQ server. Let’s assume B’s IP is IP<B> and port is P<B>.
3. If client B was added in A’s buddy list already and vice versa, ICQ server would send IP<B> + P<B> to client A. And sent IP<A> + P<A> to client B.
4. Whose listening port would be used depends on who would initiate the communication.
5. Assume client A wanted to send message to client B first. Client A would randomly select an available local port and send the messaging initiating packet to B via IP<B> + P<B> to establish TCP connection.
6. If the TCP connection established successfully, the message would be sent immediately after the messaging initiating packet. All the messages from client A to client B and vice versa would be sent through this TCP connection until one of them disconnected from ICQ server.
7. Assume now client C went online. If B was added to C’s buddy list already, client C would get the IP<B> + P<B> for direct messaging.
8. When client C wanted to send message to client B. Client C would randomly select an available local port and send the messaging initiating packet to B via IP<B> + P<B> to establish TCP connection. This connection would be maintained until whether client B or client C went offline.
9. Now client B’s listening port has established two TCP connections. One for client A and one for client C.
10. At this moment, both listening port of client A and client C were still unused.
During the login process, ICQ would randomly open available port as TCP listening port. However, ICQ will not test whether this port is connectable before sending this information to ICQ server (in the case when this port was blocked by firewall). ICQ client just open the port and send it out.
3.5 ICQ protocol
ICQ protocol was designed by Mirabilis. ICQ client is a commercial product although it is free of charge now. As a result, ICQ protocol is not opened for public. All the information and detail descriptions about ICQ protocol were published by a random group of people on the Internet with lose collaboration and common interest. The ICQ protocol has passed through several versions and each of them are quite different from the preceding. Since ICQ protocol was designed privately and not opened for public, there was not official name for each version of ICQ protocol. The name was given according to their development sequence. This document would focus on the ICQ protocol used by ICQ client ICQ98 and ICQ99. However, all other versions of ICQ protocols would be briefly described.
1. Protocol V1 (Version 1)
ICQ protocol V1 was the first version of ICQ protocol and is no longer in use. This version of ICQ protocol was never used by and publicly released ICQ client. So there is not any specification for ICQ protocol V1.
2. Protocol V2 (Version 2)
ICQ protocol V2 was the first ICQ protocol used by publicly released ICQ client in 1996. This version of protocol was the oldest version of ICQ protocol still in use today.
Basic layout of ICQ protocol V2
|
Client to server (Which is fixed in structure) · Protocol version (2 bytes) · Command (2 bytes) · Sequence number (2 bytes) · Client’s UIN (4 bytes) |
||
|
|
· Parameters for command |
|
|
|
||
|
Server to Client (Which is fixed in structure) · Protocol version (2 bytes) · Command (2 bytes) · Sequence number (2 bytes) |
||
|
|
· Parameters for command |
|
|
|
||
3. Protocol V3 (Version 3)
ICQ protocol V3 was the second ICQ protocol used by publicly released ICQ client. This version of protocol used a simple checksum for security.
4. Protocol V4 (Version 4)
ICQ protocol V4 was the third ICQ protocol used by publicly released ICQ client. In this version, encryption is first attempted for security.
|
Client to server (Fixed in structure) · Protocol version (2 bytes) · Random number (2 bytes) · Zeros (2 bytes) · Command (2 bytes) · First sequence code (2 bytes) · Second sequence code (2 bytes) · Client’s UIN (4 bytes) · Check code (4 bytes) |
||
|
|
· Parameters for command |
|
|
|
||
5. Protocol V5 (Version 5)
ICQ protocol V5 was the most widely used ICQ protocol. This version was used by ICQ client ICQ98 and ICQ99.
6. Protocol V7 (Version 7)
ICQ protocol
version 7 was designed by AOL (American OnLine). Some people called this
protocol modified AIM/OSCAR protocol. It is totally different from previous
version of protocols.
ICQ protocol V5 – ICQ98 and ICQ99
In this document, ICQ protocol V5 would be analyzed against the IMPP requirements proposed in rfc2779. So I needed to comprehend the details about how ICQ protocol version 5 fulfilled the basic operations of ICQ98 and 99.
In each ICQ client, no matter what version it is, there are only three kinds of communications. They are client to server, server to client and client-to-client communications. The client to server packet always sent using UDP and was encrypted before sending.
Client to server packet layout
|
Client to server (Header: which is fixed in structure) · Protocol version (2 bytes) · Zero (4 bytes) · Client’s UIN (4 bytes) · Session ID (4 bytes) · Command (2 bytes) · Sequence number1 (2 bytes) · Sequence number2 (2 bytes) · Check code (4 bytes) |
||
|
· Parameters for command |
|
|
|
|
||
The server to client packet always follows the following structure and always sent through UDP connection
Server to client packet layout
|
Server to client (Header: Which is fixed in structure) · Version (2 bytes) · Zero (1 byte) · Session ID (4 bytes) · Command (2 bytes) · Sequence number1 (2 bytes) · Sequence number2 (2 bytes) · Client’s UIN (4 bytes) · Check code (4 bytes) |
||
|
|
· Parameters for command |
|
|
|
||
The packet header contains basic information about the client. The sensitive information is placed in the body of the packet. ICQ server and client analyze the parameters for command according to the Command in the header. Each command has its own structure. Below are some commands, their structures and some examples. The raw data is encrypted by client before sending to server. The encryption and decryption mechanisms could be found on the web site:
http://www.algonet.se/~henisak/icq/encrypt-V5.txt
The raw data of the first packet from client to server
sniffed is shown below
0x0000: 05 00 00 00 00 00 87 8A 49 01 A3 C2 DA CD 28 E1
0x0010: E7 92 D3 E2 3F 54 C1 59 40 7E 7C D8 43 CD C8 E2
0x0020: 17 92 F2 DA 27 A7 9A D6 2E 92 A9 E3 14 92 31 66
0x0030: 17 69 C8 E2 1F 93 D1 E4 1F 92 B2 E2 1F 92 CE E0
0x0040: 1F AD A8 B2 1F 92 AD E1 1F 92 D1 E6 66 5F 8C E7
0x0050: 11 53 E6 E2 1F 92 BA E2 1F 92 AD FD 1F DB 91 B3
0x0060: 3F DB AA 81 31 B2 81 C2 4F E0 A3 86 6A F1 EE C2
0x0070: 70 F4 F3 AB 5C C3 F2 CA 4B DF ED E2
After the above data was decrypted by ICQSniff.
0x0000: 05 00 00 00 00 00 87 8a 49 01 12 20 c5 5f e8 03
0x0010: f8 00 01 00 20 c6 15 bb 5f ec cd 3a 5c 5f 00 00
0x0020: 08 00 36 38 38 35 32 34 31 00 3f 01 0b 00 9e 84
0x0030: 08 fb 04 00 00 01 00 06 00 00 00 00 00 00 00 02
0x0040: 00 3f 01 50 00 00 00 03 00 00 00 04 79 cd 3a 05
0x0050: 0e c1 37 00 00 00 00 00 00 00 00 1f 00 49 43 51
0x0060: 20 49 6e 63 2e 20 2d 20 50 72 6f 64 75 63 74 20
0x0070: 6f 66 20 49 43 51 20 28 54 4d 29 00
A brief example of ICQ decryption
Encrypted packet
05 00 00 00 00 00 E1 8A 49 01 5B 1B 8D 8A D5 A8
4A EB EA A9 EE 82 1B 93 22 62 85 A8 A4 E8 E5 A9
CD 8D B3 C5 CA E8
Packet checkcode is located at 0x14 to 0x17
EE 82 1B 93
Reverse bit
93 1B 82 EE
A1 = 93 1B 82 EE and 0001F000 = 18000
A2 = 93 1B 82 EE and 07C007C0 = 30002C0
A3 = 93 1B 82 EE and 003E0001 = 1A0000
A4 = 93 1B 82 EE and F8000000 = 90000000
A5 = 93 1B 82 EE and 0000083E = 2E
A1 = 18
A2 = 1800160
A3 = 68000000
A4 = 9000
A5 = 170000
Real Checkcode = A1+A2+A3+A4+A5 = 69979178
PL (Packet length)= 38 = 0x26
CODE1 = 26 * 68656C6C = 7F0E1808
CODE2 = CODE1 + 69979178 = 7F0E1808 + 69979178 = E8A5A980
N = PL + 03 = 0x29
POS = 0x0A
Do while POS < N
Loop1
T = 0x0A MOD 0x100 = 0x0A
CODE3 = CODE2 + TABLE[A] = E8A5A980 + 4C = E8A5A9CC
Data = 5B 1B 8D 8A = 8A 8D 1B 5B XOR E8A5A9CC = 6228B297
POS = 0x0A + 0x04 = 0x0E
POS < N continue
Loop2
T = 0x0E MOD 0x100 = 0x0E
CODE3 = CODE2 + TABLE[E] = E8A5A980 + 5B = E8A5A9DB
Data = D5 A8 4A EB = EB 4A A8 D5 XOR E8A5A9DB = 3EF010E
POS = 0x0E + 0x04 = 0x12
POS < N continue
Loop3
T = 0x12 MOD 0x100 = 0x12
CODE3 = CODE2 + TABLE[12] = E8A5A980 + 6D = E8A5A9ED
Data = EA A9 EE 82 = 82 EE A9 EA XOR E8A5A9ED = 6A4B0007
POS = 0x12 + 0x04 = 0x16
POS < N continue
Loop4
T = 0x16 MOD 0x100 = 0x16
CODE3 = CODE2 + TABLE[16] = E8A5A980 + 6F = E8A5A9EF
Data = 1B 93 22 62 = 62 22 93 1B XOR E8A5A9EF = 8A873AF4
POS = 0x16 + 0x04 = 0x1A
POS < N continue
Loop5
T = 0x1A MOD 0x100 = 0x1A
CODE3 = CODE2 + TABLE[1A] = E8A5A980 + 4C = E8A5A9CC
Data = 85 A8 A4 E8 = E8 A4 A8 85 XOR E8A5A9CC = 00010149
POS = 0x1A + 0x04 = 0x1E
POS < N continue
Loop6
T = 0x1E MOD 0x100 = 0x1E
CODE3 = CODE2 + TABLE[1E] = E8A5A980 + 63 = E8A5A9E3
Data = E5 A9 CD 8D = 8D CD A9 E5 XOR E8A5A9E3 = 65680006
POS = 0x1E + 0x04 = 0x22
POS < N continue
Loop7
T = 0x22 MOD 0x100 = 0x22
CODE3 = CODE2 + TABLE[22] = E8A5A980 + 5F = E8A5A9DF
Data = B3 C5 CA E8 = E8 CA C5 B3 XOR E8A5A9DF = 006F6C6C
POS = 0x22 + 0x04 = 0x26
POS < N continue
No more data to be decrypted. Stop
Packet [10..13] 62 28 B2 97 = 97 B2 28 62
Packet [14..17] 03 EF 01 0E = 0E 01 EF 03
Packet [18..21] 6A 4B 00 07 = 07 00 4B 6A
Packet [22..25] 8A 87 3A F4 = F4 3A 87 8A
Packet [26..29] 00 01 01 49 = 49 01 01 00
Packet [30..33] 65 68 00 06= 06 00 68 65
Packet [34..37]00 6F 6C 6C = 6C 6C 6F 00
Decrypted packet:
05 00 00 00 00 00 E1 8A 49 01 97 B2 28 62 0E 01
EF 03 07 00 4B 6A F4 3A 87 8A 49 01 01 00 20 1E
68 65 6C 6C 6F 00
Parameter: 87 8A 49 01 01 00 06 00 68 65 6C 6C 6F 00
UIN = 87 8A 49 01 = 01 49 8A 87 = 21596807
Message type = 01 00 = 00 01
Message length = 06 00 = 00 06
Message text = 68 65 6C 6C 6F 00 in ASCII ® hello
Analysis according the layout
Version number: 05 00
Zero: 00 00 00 00
Client’s UIN: e1 8a 49 01
Session ID: 12 20 c5 5f
Command: e8 03
Sequence number1: f8 00
Sequence number2: 01 00
Check code: 20 c6 15 bb
Parameters for Command (e8 03): 5f ec cd 3a 5c 5f 00 00 08 00 36 38 38 35 32 34 31 00 3f 01 0b 00 9e 84 08 fb 04 00 00 01 00 06 00 00 00 00 00 00 00 02 00 3f 01 50 00 00 00 03 00 00 00 04 79 cd 3a 05 0e c1 37 00 00 00 00 00 00 00 00 1f 00 49 43 51 20 49 6e 63 2e 20 2d 20 50 72 6f 64 75 63 74 20 6f 66 20 49 43 51 20 28 54 4d 29 00
Before the header becomes meaningful for people, they needed to be rearrange
Version number: 00 05 (Decimal value: 5)
Zero: 00 00 00 00
Client’s UIN: 01 49 8a e1 (Decimal value: 21596897)
Session ID: 5f c5 20 12
Command: 03 e8 (Decimal value: 1000 ® CMD_LOGIN)
Sequence number1: 00 f8
Sequence number2: 00 01 (Decimal value: 1)
Check code: bb 15 c6 20
This header tells the ICQ server the version of ICQ protocol used by the client (Version 5), the client’s UIN (21586897), the command (1000: CMD_LOGIN).
How do the command and its parameter work?
When server is informed which command is being received, it will partition the parameter according to the command’s structure.
The structure of the command CMD_LOGIN (03 e8: 1000)
|
Length |
Designation |
Description |
|
4 bytes |
Time |
Number of seconds since 1 January 1970 |
|
4 bytes |
Port |
The port you will be listening for TCP connection |
|
2 bytes |
Password length |
The length of password, including null |
|
Variable |
Password |
Null terminated string containing the password |
|
4 bytes |
X1 |
Unknown |
|
4 bytes |
IP |
Client’s IP address |
|
1 bytes |
TCP flag |
Tell server how to connect to the client |
|
4 bytes |
Status |
The status of the client |
|
2 bytes |
TCP_version |
TCP version, ICQ 99 use TCP version 6 (V6) |
|
2 bytes |
X2 |
Unknown |
|
4 bytes |
X3 |
Unknown |
|
4 bytes |
X4 |
Unknown |
|
4 bytes |
X5 |
Unknown |
|
4 bytes |
X6 |
Unknown |
|
4 bytes |
GMT |
GMT since 1970 |
|
4 bytes |
X7 |
Unknown |
|
4 bytes |
X8 |
Unknown |
|
4 bytes |
X9 |
Unknown |
|
2 bytes |
Data length |
Length of information of ICQ client |
|
Variable |
Data |
Null terminated |
Parameter for Command (e8 03): 5f ec cd 3a 5c 5f 00 00 08 00 36 38 38 35 32 34 31 00 3f 01 0b 00 9e 84 08 fb 04 00 00 01 00 06 00 00 00 00 00 00 00 02 00 3f 01 50 00 00 00 03 00 00 00 04 79 cd 3a 05 0e c1 37 00 00 00 00 00 00 00 00 1f 00 49 43 51 20 49 6e 63 2e 20 2d 20 50 72 6f 64 75 63 74 20 6f 66 20 49 43 51 20 28 54 4d 29 00
Time: 5f ec cd 3a
Port: 5c 5f 00 00
Password length: 08 00
Password: 33 36 31 30 37 37 37 00
X1: 3f 01 0b 00
IP: 9e 84 08 fb
TCP flag: 04
Status: 00 00 01 00
TCP version: 06 00
X2: 00 00
X3: 00 00 00 00
X4: 02 00 3f 01
X5: 50 00 00 00
X6: 03 00 00 00
Build date: 04 79 cd 3a
X7: 05 0e c1 37
X8: 00 00 00 00
X9: 00 00 00 00
Data length: 1f 00
Data: 49 43 51 20 49 6e 63 2e 20 2d 20 50 72 6f 64 75 63 74 20 6f 66 20 49 43 51 20 28 54 4d 29 00
Rearrange and convert the hexadecimal value to decimal value
Some fields are big endian while some fields are little endian. So some fields needed to be rearrangement while others are not.
Time: 3a cd ec 5f (Decimal value: 986573919 seconds ® about 31 years)
Port: 00 00 5f 5c (Decimal value: 24412)
Password length: 00 08 (Decimal value: 8 bytes)
Password: 33 36 31 30 37 37 37 00 (ASCII value: 3610777)
X1: 00 0b 01 3f
IP: 9e(158) 84(132) 08(137) fb(251) ® (158.132.137.251)
TCP flag: 04 (Enable communication over TCP)
Status: 00 01 00 00 (online)
TCP version: 06 00 (ICQ98/99 use TCP version 6)
X2: 00 00
X3: 00 00 00 00
X4: 01 3f 00 02
X5: 00 00 00 50
X6: 00 00 00 03
GMT: 3a cd 79 04(Decimal value: 986544388 seconds ® about 31 years)
X7: 05 0e c1 37
X8: 00 00 00 00
X9: 00 00 00 00
Data length: 00 1f (Decimal value: 31 bytes including null terminal)
Data: 49 43 51 20 49 6e 63 2e 20 2d 20 50 72 6f 64 75 63 74 20 6f 66 20 49 43 51 20 28 54 4d 29 00 ® ASCII value: ICQ Inc. - Product of ICQ (TM)
Above is the login packet that was sent during the login process and provide the information to ICQ server, who you are and where you are. Since this packet was sent from client to server, this packet would be encrypted before sending. All the packets of ICQ98/99 could be analyzed in this way once you know the header, the command format of the packet and the decryption algorithm.
ICQ protocol pass through SOCKS5 Proxy
SOCKS is a generic proxying protocol for traversing firewalls and other trust boundaries; version 5 of the protocol adds new features such as authentication and UDP support. The new feature of SOCKS5 to support UDP will be a good news for the user that want to use ICQ behind SOCKS Proxy.
ICQ client intrinsically supports SOCKS5
Proxy and user authentication. There is an application called SocksCap. SocksCap automatically
enables Windows-based TCP and UDP networking client applications to traverse a
SOCKS firewall. SocksCap intercepts the networking calls from WinSock
applications and redirects them through the SOCKS server without modification
to the original applications or to the operating system software or drivers.
ICQ SOCKS5 supports only server to client communication and vice
versa. It does not support peer to peer (direct TCP) communication. Although
ICQ does not support peer to peer communication through SOCKS5 it can still
provide the presence and messaging services. It is because the sending message
can be done by “send through server”.
Results of testing ICQ protocol passes through SOCKS5
In this experiment, a SOCKS5 Proxy server was setup. ICQ client is configured to communicate with server through SOCKS5 Proxy server. There are two types of connections I want to test. The first is the client to server and server to client communications.
There is no problem
when ICQ performing login process because ICQ would add the SOCKS header to all
the packets. First of all, when ICQ client starting up, it used TCP connection
to send the version identifier/method selection message to SOCKS5 Proxy server.
The layout of version
identifier/method selection message is:
|
Length |
Designation |
Description |
|
1 byte |
VER |
Protocol version |
|
1 byte |
NUM_METHOD |
Number of methods in
method field |
|
1 byte |
METHOD |
Method identifier |
The values currently
defined for METHOD are:
o
x00 No authentication required
o
x01 GSSAPI
o x02
Username/password
o
x03 to x7F IANA assigned
o
x80 to xFE Reverse for private methods
o
xFF no acceptable method
The data of version
identifier/method selection message is shown below
0x0000: 05 01 00
Protocol version: 05
Number of methods in
method field: 01
Method identifier: 00 (No Authentication required)
When the SOCKS Proxy
was configured to use username/password authentication the version
identifier/method selection message would be changed to:
0x0000: 05 01 02
In this message, the
method field was changed to 0x02, which indicated that the username/password
authentication method is used.
When SOCKS server
received the version identifier/method selection message, SOCKS server would
send back the METHOD selection message, which contained the METHOD selected.
The layout of the
message is
|
Length |
Designation |
Description |
|
1 byte |
VER |
Protocol version |
|
1 byte |
METHOD |
Method selected |
Method selection
messages sent from server
0x0000: 05 00 (No
authentication is selected)
When the server was
configured to use username/password authentication, the METHOD selection
message was changed to:
0x0000: 05 02
(Username/password authentication is selected)
Once the
method-dependent sub-negotiation has completed, the client sends the request
details.
The SOCKS request is formed as follows:
|
Length |
Designation |
Description |
|
1 byte |
VER |
Protocol version |
|
1 byte |
CMD |
Command |
|
1 byte |
RSV |
Reserved |
|
1 byte |
ATYP |
Address type |
|
Variable |
DST_ADDR |
Destination address |
|
2 byte |
DST_PORT |
Destination port |
Where:
|
VER |
x05 |
|
CMD |
x01 (CONNECT) |
|
x02 (BIND) |
|
|
x03 (UDP ASSOCIATE) |
|
|
RSV |
x00 |
|
ATYP |
x01 (IP V4 address) |
|
x03 (DOMAINNAME) |
|
|
x04 (IP V6 address) |
The raw data below is captured during performing login process.
0x0000: 05 03 00 01 00 00 00 00 04 42
Protocol version: 05
Command: 03 ( UDP associate)
Reserved: 00
Address type: 01 (IP V4 address)
Destination address: 00 00 00 00 (If the client is not in possession of the information at the time of the UDP ASSOCIATE, the client MUST use a port number and address of all zeros.)
Destination port: 04 42 (1090, this port is the local port number will be used for UDP connection)
The SOCKS request information is sent by the client as soon as it has established a connection to the SOCKS server, and completed the authentication negotiations. The server evaluates the request, and returns a reply as follow:
|
Length |
Designation |
Description |
|
1 byte |
VER |
Protocol version |
|
1 byte |
REP_FIELD |
Reply field |
|
1 byte |
RSV |
Reserved |
|
1 byte |
ATYP |
Address type |
|
Variable |
BND_ADD |
Server bound address |
|
2 byte |
BND_PORT |
Server bound port |
The reply field has one of following values:
· x00 succeeded
· x01 general SOCKS server failure
· x02 connection not allowed by ruleset
· x03 Network unreachable
· x04 Host unreachable
· x05 Connection refused
· x06 TTL expired
· x07 Command not supported
· x08 Address type not supported
· x09 to xFF unassigned
The raw data captured in the experiment:
0x0000: 05 00 00 01 C0 A8 00 03 04
09
Protocol version: 05
Reply field: 00 (succeeded)
Reserved: 00
Address type: 01 (IP V4 address)
Server bound address: C0 A8 00 03 (192.168.0.3 the IP address of SOCKS Proxy server)
Server bound port: 04 09 (1033, this port is the remote port number that SOCKS Proxy server will be used for UDP connection)
After server sent back the reply and the reply field is 0x00(succeeded), ICQ client started to send the real data using UDP. However, carries a UDP request header with it:
|
Length |
Designation |
Description |
|
1 byte |
RSV |
Reserved |
|
1 byte |
FRAG |
Current fragment number |
|
1 byte |
ATYP |
Address type |
|
Variable |
DST_ADD |
Destination address |
|
2 byte |
DST_PORT |
Destination port |
|
Variable |
DATA |
Data |
The raw data of first packet sent from client is shown below:
0x0000: 00 00 00 01 CD BC 99 67 0F A0 05 00 00 00 00 00
0x0010: 87 8A 49 01 CF 77 4C 6D 08 56 C4 A9 F3 55 40 5A
0x0020: 01 D1 2A F2 04 6F CA B9 E8 55 A9 95 D2 6D 99 A0
0x0030: FA 61 90 95 89 54 AA 95 0F FD A1 0B EE 55 A1 94
0x0040: F1 53 A1 95 D2 95 09 95 ED 55 A1 AA C8 05 A1 95
0x0050: CD 56 A1 95 F1 6C 30 EA EC 50 AF 54 C6 55 A1 95
0x0060: DA 55 A1 95 CD 4A A1 DC B1 04 81 DC 8A 36 8FB5
0x0070: E1 75 F1 E7 83 31 D4 F6 CE 75 CE F3 D3 1C E2 C4
0x0080: D2 7D F5 D8 CD 55
The underlined data is UDP request header:
00 00 00 01 CD BC 99 67 0F A0
Reserved: 00 00
Current fragment number: 00
Address type: 01 (IP V4 address)
Destination address: CD BC 99 67 (205.188.153.103 this is the IP address of ICQ server)
Destination port: 0F A0 (4000 this is the port number that ICQ client communicates with ICQ server)
From the above experiment, before ICQ client sent the packets to
server it was first negotiated with SOCKS proxy server. It sent the version identifier/method selection message and then the
request to SOCKS proxy server. Finally ICQ client would add UDP request header
to all the datagrams. All data and procedures in the experiment match the
information provided by RFC 1928 “SOCKS Protocol Version 5”. Thus I can
conclude that there is no problem for ICQ client to communicate the ICQ server.
On the other hand, the
peer to peer communication use TCP connection. During the experiment, before
sending message ICQ client did not negotiate with SOCKS Proxy server. It just
tried to send the message directly to other client without knowing the
existence of SOCKS Proxy server. Of course, the message could not be sent
successfully. After a certain time of retries the ICQ client prompt the user
with the dialogue box:
Figure 14. Message sent through server
After clicking the
button “Send Thru Server” ICQ client sent the message through server. Again the
UDP request header was added to the messages.
After the experiment, I found that ICQ could support both Presence and Instant Messaging services behind SOCKS Proxy server although the messages were sent through server rather than sent to other user directly.
Result of testing ICQProxy
The ICQProxy will redirect the packets through http port using the HTTP tunneling.
Figure 15. Logical diagram of operation of ICQProxy
The first packet sent from ICQProxy client machine:
* 50
4F | 53 54 20 68 | 74 74 70 3A [ .t...POST http:]
* 2F
2F 36 34 | 2E 32 32 34 | 2E 32 30 32 | 2E 31 31 32 [//64.224.202.112]
* 2F
55 70 64 | 61 74 65 2E | 68 74 6D 20 | 48 54 54 50 [/Update.htm HTTP]
* 2F
31 2E 30 | 0D 0A 55 73 | 65 72 2D 41 | 67 65 6E 74 [/1.0..User-Agent]
* 3A
20 57 69 | 6E 64 6F 77 | 73 20 4D 65 | 73 73 65 6E [: Windows Messen]
* 67
65 72 0D | 0A 48 6F 73 | 74 3A 20 36 | 34 2E 32 32 [ger..Host: 64.22]
* 34
2E 32 30 | 32 2E 31 31 | 32 0D 0A 43 | 6F 6E 74 65 [4.202.112..Conte]
* 6E
74 2D 4C | 65 6E 67 74 | 68 3A 20 31 | 33 32 0D 0A [nt-Length: 132..]
* 50
72 61 67 | 6D 61 3A 20 | 6E 6F 2D 63 | 61 63 68 65 [Pragma: no-cache]
* 0D
0A 0D 0A | 7C 00 00 00 | 90 BD 01 00 | 05 00 00 00
[....|...........]
* 00 00 87 8A |
49 01 80 56 | C4 99 57 30 | 12 FD D0 33 [....I..V..W0...3]
* 25 46 4D A9 |
16 C9 30 09 | 6B F0 C7 33 | DB C1 F5 0B [%FM...0.k..3....]
* EB F4 95 07 |
E2 C1 AA 32 | D8 C1 6E 9B | D3 5F C9 33 [.......2..n.._.3]
* D3 C0 D0 35 |
D3 C1 B1 4C | D3 C1 CC 33 | D3 FE A9 63 [...5...L...3...c]
* D3 C1 AC 30 |
D3 C1 D0 0A | 42 BE 8F 36 | DD 00 E7 33 [...0....B..6...3]
* D3 C1 B9 33 |
D3 C1 AC 2C | D3 88 92 62 | F3 88 AD 50 [...3...,...b...P]
* FD E1 86 13 |
83 B3 A4 57 | A6 A2 ED 13 | BC A7 F2 7A [.......W.......z]
* 90 90 F1 1B |
87 8C EA 33 | 0D 0A | [.......3..]
From the above packet, the data in blue color is the header added by the ICQProxy while the data in black color is the raw data generated by ICQ client. In this experiment, the packets are sent through campus’ HTTP Proxy server (proxy.polyu.edu.hk:8181).
Again the ICQProxy only support the communications between client and server. The peer to peer communication is not supported by ICQProxy. Thus in this experiment, sending Instant Messaging is again sent through server.
ICQ protocol version 7
The latest version of ICQ client (ICQ2000) deployed a totally new protocol. This protocol is developed by AOL (American On Line) and is very similar to the protocol used for AIM (American online Instant Messenger). Both of ICQ2000 and AIM will use TCP port 5190 to communicate with server.
Besides the default port 5190, ICQ2000 can allow users to use any available ports for the login process. It can also allow the user to scan the available ports on the Firewalls. The client also allows the user to determine which port is opened as TCP listening port.
During the experiment, I didn’t know which ports are available on campus firewall. I tried the new feature of ICQ2000 to scan the available port on campus firewall. Always it reported back the port 20 (FTP). So I use the port 20 for client-server communication.
ICQ2000 uses a new server (login.icq.com) for login process, and this server opens all the ports for listening incoming connections. As a result, there is no effective way to filter the ICQ protocol by Firew