ICQ and AIM

AOL’s AIM and acquired ICQ technologies currently purport to include nine of ten IM clients, the remainder a mix primarily of Yahoo and MSN users. This dominance is to a large extent due to the already “captive” user base of AOL ISP subscribers and to the acquirement in 1998 of the main IM player, Miribilis ICQ.

Bit 6.3 Registered identities invariably overstates the number of users. Many (most?) users in public IM directories have several registered identities.

Determining the real number of individual users for any IM system is difficult because people (intentionally or inadvertently) tend to have more than one identity with the system. Furthermore, because of the current lack of interoperability, the same user is typically registered with several different IM systems. Therefore, AIM’s 40 million and ICQ’s 150 million registered identities (at time of writing) must overlap and translate to less—perhaps significantly less—actual users.

Nevertheless, while AOL may have the dominant share of IM, it is under significant pressure to allow interoperability and thus a unified IM access independent of client system. So far, AOL has actively resisted such interoperability whenever any of the other IM systems have deployed the means to contact AIM users. It remains to be seen if this vision of “anyone contacting anyone” by instant messaging will ever be realized without AOL as a player.

Because ICQ technology was so trend setting, and still greatly dominates in relative share of users, this chapter mainly focuses on the ICQ implementation. Current ICQ software and support is provided at the main site, www.icq.com.

ICQ—IM for the Masses

Four Israelis, Yair Goldfinger, Arik Vardi, Sefi Vigiser, and Amnon Amir, founded the Miribilis company in July 1996 in order to introduce a new communication tool for the Internet. Their product ICQ (a mnemonic abbreviation for “I Seek You”) was released in November that same year. It introduced a for the time startling sidestep for the user in terms of achieving public networking access.

There was suddenly no need to ask the local IT department about IP addresses, domain name servers, or hosting facilities. ICQ simply ignored the idea that anyone else had any say over how you used your computer. Instead, users just installed the client software, which could communicate with a central server administering its own namespace over member clients. After that, a user’s computer could talk to any other machine with an address in the ICQ namespace. And it would do so from virtually anywhere with Internet access, even from behind firewalls.

ICQ bypassed Internet’s DNS system of addressing in favor of creating its own directory of protocol-specific addresses, translated into real network IP addresses by a central server member directory on the fly. This meant that it could update IP addresses in real time, thus coping with intermittently connected PCs and dynamic IPs, a feature later also implemented in a similar way by technologies like Groove, Napster, and NetMeeting.

The other ways of dealing with identity and intermittent connectivity, also bypassing DNS, either rely on current IP directly, without server-mediated directories, or on using scheduled connections. The latter solution is common with distributed processing systems, such as SETI@Home.

The main focus of ICQ (like that of Napster years later) was ease of use—install, click and go—and a small, resident application always at hand. The ease explains part of the enormous appeal of the system, adopted by hundreds of millions of users, because the vast majority of users detest anything they must configure and tweak. Any really useful mass-appeal tool must allow an essentially transparent functionality as default behavior; anything else will necessarily have limited adoption.

Table 6.1 shows the component summary for ICQ.

Installing ICQ

While Miribilis ICQ originally was just for Windows systems running Miribilis clients, ports to other platforms do exist—both official versions and third-party clones. The ICQ protocol has been hacked repeatedly and is therefore fairly well documented on several unofficial ICQP sites. After going AOL, however, both server behavior and protocol shifts are making ICQ interoperability difficult for the clones.

Searching the Web for the conjunction of “ICQ” and “Linux”, for example, turns up several sites that link to client software compatible with ICQ. Some Linux X-Window clients worth mentioning are LICQ (licq.wibble.net), GICQ for GTK (www.korsoft.com/gicq/), and KiCQ for KDE (www.cn.ua/~denis/kde/kicq.html). A number of text-based console clients are also available.

The original small Windows ICQ clients have evolved in the usual bloatware manner, so a full official ICQ installation package now runs about 5MB (ICQ2000); online help is another 600KB for a self-installing plug-in.

Table 6.1. ICQ component summary, common to many IM implementations

Component	Specific forms	Comments
Identity	Unique ICQ number tied to server directory with current online IP identity	Client IP identity tracked in real time by server and hence also presence status.
Presence	Usually online, offline, or one of a number of preset or custom states	Presence setting is customized by user.
Roster	Client-managed lists	Server can automatically notify of changed online status of specified users.
Agency	Automation settings in client plus server push	Functionality set in preferences and by subscription, and by inclusion of various plug-ins.
Browsing	Of server-presented content	Client minibrowser, or activation of system default Web browser.
Architecture	User-centric server mediated	Clients make p2p connections by default, with fallback channel through mediating server.
Protocol	Proprietary	Extensions and plug-ins.

Installation is still essentially click-and-go, but it takes a few extra clicks to deal with nag alerts, a welcome page, and some basic settings before reaching the running interface seen in Figure 6.3. The client is free, but as such it is also a conduit for paid banner advertising in the messaging windows, piped down from the ICQ server.

Figure 6.4 shows the advanced mode version of the interface, which makes more of the current ICQ functionality available up front. This hints at the extra features offered to entice users to join and remain with a particular vendor—and as hooks to potential revenue-generating services. The marketing push is comparatively low key, but it’s not insignificant. The animated banners become very distracting if you have a couple of message windows open. The licensing agreement has a lower age-limit in —perhaps a good thing, because after registration, even with unspecified personal characteristics and a low profile, I immediately received unsolicited “invitations” from a number of unknown users. Ignoring future contact attempts is at least possible using a clearly visible button on the message dialog.

User “convenience” and automation comes at a price, however, and is an issue we meet again with other implementations. The price for preprogrammed and automated convenience in ICQ is a distinct loss of control. For example, in a dial-up setting, the client by default is automatically live when a connection exists and asleep when it doesn’t. One immediate consequence is that you must be online to access and change settings, because the client—and its automatic welcome window—go up and down like a yo-yo if you connect intermittently, for example during e-mail check.

Furthermore, the client status overrides the normal connection control, so that if your e-mail client previously automatically closed the connection when its poll was complete, ICQ keeps it alive indefinitely once up. A number of such user issues need to be resolved after initial installation, unless you happen to like the default settings, and it’s not always clear how to find the relevant setting.

Luckily, it’s possible to disable ICQ in one click from the taskbar menu, for those situations when you don’t want the client to react to connection status on its own. Not everyone thinks to look there, and you might easily look in vain elsewhere.

You can make more selective and detailed customization from the Preferences dialog, accessed through the ICQ popup, when you have the time and inclination to peruse the very many settings indicated by full feature set in Figure 6.5.

The user should note in this context that there are two independent profiles here; a less detailed one accessed from Simple Mode, plus the detailed dialog for Advanced Mode as shown in the previous figure. If you only tweak the one, changing to the other mode will use the default settings this still has—something that confused me the first time it happened.

ICQ Protocol

The protocol used by ICQ is proprietary, and it has passed through several version iterations, each of them quite different from the preceding. Each version has been reverse-engineered from the current Windows clients in order to allow development of interoperable clients on other platforms.

The oldest version fully deployed and reportedly still in use by some (Java-based) clients is v2. What later came to be called v3/4 is a curious mix, where the server used an earlier v3 format packets (never fully deployed on the client side) to communicate with the clients, while clients instead used a later v4 format. Both v3 and v4 were in response to severe criticism of the security vulnerabilities in the v2 protocol, and they introduced anti-spoofing measures and client-side encryption, respectively.

The current ICQ protocol is v5, which should be seen as an attempt to clean up the patchwork result of the v3/4 security retrofits. It’s worth noting that v5 clients have a setting to refuse communication with clients using older protocol versions. There are signs that AOL is considering a significant protocol change (a v6?) to make AIM and ICQ interoperable, and possibly try to close out clone clients (for a while).

Bit 6.4 Proprietary protocols tend to be haphazard constructions. It appears significant that although closed protocols (such as ICQ or Napster) are often innovative, they tend to show inconsistent and incomplete design with numerous flaws. A general view is that open review in protocol design adds robustness.

Data Packets

The basis for all ICQ connectivity is a connection to the central ICQ server. Clients send packets to the server using the non-handshaking Internet protocol UDP. As of v4, these packets are encrypted before they are sent, unlike the packets sent from the server to a client, which are not—a legacy from v3/4 protocol.

(As an aside, tracing UDP packets to analyze the protocol did actually comply with the original Miribilis License agreement and was therefore not illegal.)

The header fields in an ICQ v5 packet are summarized in Table 6.2. ICQ packets must not exceed 450 bytes total length, so longer content requires multiple packets. For example, user lists are limited to about 120 names per packet.

Session ID might seem superfluous, given a unique client ID, but it’s used by the server to prevent spoofing. Every packet the client sends must have this same number; the server ignores any packets that don’t. This Session ID is also sent back with every packet from the server, so the client also ignores any packets that don’t match.

Table 6.2. Header fields present in ICQ v5 protocol

Header field	Description
Version	Fixed; protocol version (0x50 0x00 for v5)
Zero	4 null bytes, purpose unknown
UIN (32 bit)	Client identification number, assigned at registration
Session_ID (32 bit)	Random identification, assigned at each server login
Command	A 2-byte command
Seq_Num1	A 16-bit random number
Seq_Num2	A 16-bit number that starts off as 1
Checkcode	A 32-bit checksum value
Parameters	A variable length field for command parameters

Sequence numbers are used to ensure that all packets really arrive at the recipient and only do so once. Later packets with duplicate sequence numbers are ignored. Both numbers (random-set and 1-set) are incremented for each packet sent, except that the second is kept at value zero for certain commands.

UDP doesn’t use handshaking to implement a reliable connection like TCP, but the ICQ server does explicitly acknowledge (with SRV_ACK) each packet received. If the client doesn't receive this ACK for any packet sent, it should resend the packet.

The server expects the client to send an acknowledgment for every packet received except for SRV_ACK. The ICQ client will actually resend only six times with an interval of ten seconds—the interval chosen so as not to unduly consume bandwidth. After six resends it then sends CMD_SEND_TEXT_CODE with a B_MESSAGE_ACK (see the following section about command sets), seemingly as a fallback measure.

Command Sets

There are two separate sets of commands; one for client-server messages (Table 6.3), the other for server-client messages (Table 6.4). These lists are not complete, but they are provided here for reference and as examples of the kinds of commands an IM system must implement for minimum functionality. The reverse-engineering process means that the names are descriptive, not official.

Table 6.3. Client-to-server commands current in ICQ v5 protocol, packets sent encrypted.

Command	Description
CMD_REG_NEW_USER CMD_NEW_USER_INFO CMD_NEW_USER_1	Is sent in order to register a new user and request UIN. Only occurs prior to any session login. A subsequent login completes registration and sends entered information with new user info. Further users can be added to the same client with the last command.
CMD_LOGIN	Client request to start a session (contains UID, password, etc.).
CMD_ACK	Acknowledge a packet received from server.
CMD_ACK_MESSAGES	Remove old (offline) messages from server.
CMD_KEEP_ALIVE	Client sends this every two minutes to maintain online status with server (server provides a suggested value with login response).
CMD_STATUS_CHANGE	Updates user online presence status.
CMD_ADD_TO_LIST	Add a user to contact list (receive status changes).
CMD_CONTACT_LIST	Informs the server for which users you wish to receive online/offline events. May require multiple packets to send longer lists.
CMD_AUTH_UPDATE	Set whether users require permission to add you to their contact lists (not implemented in all clones).
CMD_SEARCH_UIN CMD_SEARCH_USER CMD_SEARCH_RAND	Request search for a user based on UIN, on (4) text fields, or at random from a specified group.
CMD_INFO_REQ CMD_EXT_INFO_REQ	Request basic or extended information about a particular user (UIN).
CMD_SEND_MESSAGE	Send a message through the server to an offline or invisible user. Parameters include target user UIN, message type, and length.
CMD_MSG_TO_NEW_USER	Sends a message to a user who is not in client contact list.
CMD_UPDATE_INFO CMD_UPDATE_EXT_INFO	Update normal and extended user info, respectively.
CMD_META_USER	Replaces a number of older commands to set or get user information (in particular, used to change password).
CMD_QUERY_SERVERS CMD_QUERY_ADDONS	Used to query server about addresses to other servers, and about availability of global add-ons.
CMD_INVIS_LIST CMD_VIS_LIST CMD_UPDATE_LIST	Overrides visibility status to specified users, specify users to see when in invisible mode, informs server of changes in visible/invisible lists.
CMD_SEND_TEXT_CODE	Extension mechanism to send other commands as text strings

Table 6.4. Server-to-client commands current in ICQ v5 protocol, sent not encrypted

Command	Description
SRV_ACK	Acknowledgment for a command sent to the server. Received packet is identified by its sequence number.
SRV_GO_AWAY	Error message from the server. Client must disconnect and reconnect in order to continue.
SRV_NEW_UIN	A new UIN, requested by CMD_REG_NEW_USER, has been reserved (passed in the UIN header field). CMD_LOGIN completes registration.
SRV_LOGIN_REPLY SRV_BAD_PASS SRV_RECV_MESSAGE	Response to correctly received CMD_LOGIN. Response to invalid password in the login packet. Response after login if (offline) messages are waiting.
SRV_USER_ONLINE SRV_USER_OFFLINE	Changes to status for users on a contact list are notified to the client using these commands.
SRV_QUERY	Response to CMD_QUERY_SERVES and CMD_QUERY_ADDONS.
SRV_USER_FOUND SRV_END_OF_SEARCH	Responses to CMD_SEARCH_USER or CMD_SEARCH_UIN when user is found, one per packet. End for no more or too many.
SRV_RAND_USER	Response to CMD_SEARCH_RAND.
SRV_INFO_REPLY SRV_EXT_INFO_REPLY	Responses to respective request for information about a user.
SRV_NEW_USER SRV_UPDATE_EXT SRV_AUTH_UPDATE SRV_STATUS_UPDATE	Responses to corresponding client commands.
SRV_UPDATE_SUCCESS SRV_UPDATE_FAIL	Response to CMD_UPDATE_INFO, successfully changed user information, or not, respectively.
SRV_META_USER	Response to CMD_META_USER, update performed or data sent.
SRV_MULTI_PACKET	Several packets sent at once. Requires only a single CMD_ACK.
SRV_NOT_CONNECTED SRV_TRY_AGAIN SRV_SYS_DELIVERED_MESS SRV_SYSTEM_MESSAGE SRV_X1, SRV_X2	Identified commands not specified further in documentation.

The identified message types can be sorted into five main groups:

• Text

• URL (2 parts, description plus address)

• Authorization request to add user to contact list (five parts)

• Grant authorization request, user added (four parts)

• Send contacts (arbitrary number of parts)

Within each message, its component parts are in all cases delimited by a trailing byte value of 0xFE.

User presence status is defined by a single OR-able bit value, although some combinations are not allowed. The recognized component states are online, away, do not disturb (DND), invisible, occupied, not available (extended away), and free for chat. Optional components are Web-aware and show current IP. The state offline is defined by disconnecting from the server.

Client to Client

When ICQ clients are communicating p2p to each other (which they do for actual messaging, for instance), they use normal TCP protocol. Server relay is an automatic option for store-and-forward messaging when the recipient is offline.

Each type of client functionality (message, chat, file exchange, etc.) must set up its own listening TCP socket in order for client-initiated p2p communication to occur. Normally, however, only the Message listener is active by default; the others are created as the result of some event message received over the server UDP connection. Chat, file, and other transfers are in reverse TCP situations handled much the same as in the message case; the difference is that these are all initiated by a request message, so the receiving client always knows what to expect.

The normal TCP exchange needs to be “reversed” (that is to say, initiated by the target client) if, for some reason, it can’t receive a TCP connection. In that case, it must be informed of the sender’s IP address in a UDP packet sent by way of the server connection. The sequence of events for reverse TCP goes as follows, and it is similar in principle to any p2p exchange that needs to traverse a firewall (that is, use “push”).

1.	User A types in a message to send to user B.
2.	Client A attempts to connect with client B but fails.
3.	Client A builds a TCP_REQUEST packet and sends it to A’s ICQ server.
4.	Client B receives a TCP_REQUEST packet from its ICQ server containing IP:Port information for client A.
5.	Client B attempts to connect to client A and succeeds.
6.	Client B sends a TCP_Init packet to client A. (This is what client A would normally have sent if the connection attempt in step 2 had succeeded.)
7.	Client A receives the TCP_Init packet and can then send the message typed by user A in step 1, with packet flow as if a normal TCP connection.
8.	User B receives and reads the message.

In rare cases, neither client can receive a TCP connection, perhaps because both are behind firewalls. Then the fallback is to send messages as UDP packets, using the ICQ server as mediator. This process is automatic and transparent to the user.

Further details of the ICQ protocol can be found at the ICQ Protocol Site (at www.d.kth.se/~d95-mih/icq/), maintained by Magnus Ihse.

Using ICQ

Despite the increasing number of features that go beyond simple IM and the consequently larger client installation, the core of ICQ remains messaging.

On the basis of overall functionality and biggest user base, if the choice is between any of the popular proprietary IM systems, then ICQ seems the best bet and is supported by several third-party developers, notably with ICQ clients for Linux.

There are two main caveats to using ICQ, however. Since AOL owns ICQ, the protocol could easily change with little warning in a new version upgrade to promote a better internal interoperability, AIM-ICQ, leaving other clients in the cold. The other problem is the total dependence on the ICQ central server for connectivity, even though subsequent conversations between peers may be direct p2p. AOL servers are very unforgiving of even marginally noncompliant clients and summarily drop them.

AIM

For the sake of completeness, an overview of AIM is also in order. AOL’s original IM system is a closed, proprietary technology based on a user-centric architecture. Clients are provided as free downloads but are exclusively tied to AOL servers that rarely acknowledge third-party clones for long. This made the AIM protocol harder to hack than ICQ when it was run by Miribilis. Table 6.5 lists the component summary.

Table 6.5. AIM component summary, very similar to ICQ

Component	Specific forms	Comments
Identity	Unique screen name tied to server directory with current online IP identity	Client IP identity determined at login, presence status tracked by periodic advertising redirects.
Presence	Usually online, offline, or one of a number of preset or custom states	Presence setting is modified by user settings of permit/deny and visible/ invisible.
Roster	Client-managed buddy lists	Server can automatically notify of changed online status of specified users.
Agency	Automation settings in client plus server push	Functionality set in preferences and by subscription, and by inclusion of various plug-ins.
Browsing	N/A	N/A
Architecture	User-centric server mediated, login server	Clients do IM entirely through message server relay.
Protocol	Proprietary	Locked to AOL’s servers.

Connecting to AIM services is a two-step process. First, the client connects to a central authorization server (such as login.oscar.aol.com) for a login session. AIM clients use port 5190, but any will do. If this attempt succeeds, the server returns a success response message, plus a cookie that will automatically authorize the client to connect to any of the other messaging servers in the AIM service domain, or to the special-purpose servers used for advertisements, chat, etc. The authorizing server also recommends the client a “ BOS” (Basic OSCAR Service) server to use for the primary services session. On receiving the authorization cookie, the client disconnects from the authorization server.

With cookie in hand, so to speak, the client then initiates a connection with a BOS server, as indicated by the address in the Authorization Response, and “signs on” for the service. Regular connections are automatically made during the session to designated Ad-servers that supply advertisement content to the client.

The periodic advertising redirects are how the AIM service tracks a user’s online status, which is clearly why simply disconnecting from the service is sufficient to log off. Any clone client must, from the point of view of the BOS server, at least appear to support the advertisement component, or it will be disconnected.

User Roster

When signing on, the client sends a list of screen names (called the Buddy List) to the message server. Although the user sees the Buddy List organized into groups, this is a client-side feature; the server deals only with the individual names.

A full update of list member status occurs after signing on. The names on the list thereafter get watched server-side for login/logoff events, and notifications are sent back to the client when these events occur. Online status is also read and sent from the server as periodic updates to the client during the session, irrespective of any state changes—apparently, such updates ensure that no name is missed.

AIM users are classed in three groups: “AOL” for registered AOL members (using the AOL browser client), “free” for AIM-only users, and “trial” for anyone with an account less than a month old. What significance this classification might have for service level or access has never been disclosed.

You can access user information only for a user who is online. AIM servers don’t store any information about users who aren’t logged on. The basic information includes Member Class, Warning Level, Idle Time, Time of Sign-on, and the date when the member started the AOL/AIM account. This information is transported by the notification system for the oncoming buddy event.

Further information must be specifically requested as a personal profile. An “invalid user” response to this request usually means that the user isn’t online. A user can also add names to permit/deny or visible/invisible lists. Users who have denied access to see them are effectively “offline” to the denied party.

Primary user search is by screen name (as in Buddy List), but the service also provides simple search by e-mail address. A search by real name was implemented originally, but it had an on/off kind of existence—sometimes it worked, sometimes it didn’t. It seems to have been replaced by a “white pages” directory on the AOL Anywhere search site, the same as that accessed from the Web (at search.aol.com).

Messaging Functionality

Although the messaging functionality is formally p2p, AIM transport is in fact completely server mediated. All messages are sent to the message server, which relays them to the destination clients, much like IRC. This process is shown in Figure 6.6.

Bit 6.5 AIM peer messaging is entirely dependent on central server relay. At no time does one client directly locate another client or even know its (IP) location.

AOL MIME-types all message content as “text/x-aol-rtf”, and the client wraps it in a rudimentary HTML wrapper. The HTML markup is evidently not necessary, and the AIM client supports only a subset of markup. Everything is sent in clear text, and the server relay is transparent to the content.

An e-mail gateway of sorts is provided for AIM’s trivial “invite a friend” feature, which adds a short message to a server-generated e-mail inviting the recipient to join. AOL subscribers can check their e-mail account through AIM, and a form of POP account is possible for others. Notification of new mail is supported.

Protocol

The proprietary AIM protocol has been analyzed with the intent to provide interoperable clients for the AIM service. Unlike for ICQ, this work is made more difficult by countermeasures by AOL to keep AIM closed, as discussed later.

Adam Fritzler and Scott Werndorfer maintain an evolving overview of the AIM/ Oscar Protocol Specification (www.auk.cx/faim/protocol/ or www.zigamorph.net/faim/protocol/) as a service to those who are trying to develop compatible clients, especially in the *nix world. There they motivate the work in this way:

AOL has provided very nice clients for the Windows and Macintosh platforms, but has left its UNIX(tm) users with a horrible (Java-based) “solution”. Exposing this protocol will allow third-parties to develop nice, stable clients for other platforms, generally supporting the idea that “rewritten work is always better than the original”.

Everything has come from interpretation of AIM/Oscar packets coming straight off the wire. The pair state categorically that there’s been no disassembly of any code.

Moving on to the protocol, we can note that it uses standard TCP packets. More than one command may be sent in a packet, as an abstraction layer above packets. Therefore, commands are in the data stream signaled by a six-byte header that begins with a byte value of 0x2a. The header also contains a byte-value for the channel ID, a two-byte sequence number, and a two-byte value for the variable length of the following data field. The data length offset would thus point to the next command header, if one is in the packet stream. Data is not terminated in any special way.

Sequence numbers are superfluous in TCP, but it seems they’re used as a form of client validation. The seed origins are picked quite randomly, with no connection between server and client sequences. Sequence numbers are initialized for each opened TCP connection (or socket), are always incremented upward, and wrap.

AIM uses the concept of channels to multiplex information over the same connection, with somewhat the same functionality as TCP port numbers. Of the four observed channels, data is transmitted only over channel 2. New connections are set up using channel 1, error management uses channel 3, and “formal” termination uses channel 4. In practice, termination is commonly achieved by simply disconnecting— no server negotiation has been observed when using channel 4 notification.

The data field has its own structure, with a kind of subheader. This identifies Family ID for a group of services (of which there are very many) and subtype ID for the specific service or information provided in the data section. There are a couple of rarely used flags and a four-byte Request ID to identify nonatomic information. The last is vital to identify responses and associate them with the initiating queries.

Some identified command families are named in the analysis:

• Generic Service Controls

• Location Services (user information)

• Buddy List Management (and presence monitoring)

• Messaging

• Advertisement Management

• Administrative (information and account management)

• Popup Notices

• BOS-specific (services, group permissions)

• User Lookup

• Statistics (event reporting)

• Translate

• Chat Navigation

• Chat

• Notification List

Either as part of one command or directly in the first-level data field, a TLV triplet can occur (a 16-bit Type code, a 16-bit Length of the following Value field). They are commonly used for sending short strings and other values, for example {0x0011, 0x000d, "[email protected]"}, where this type identifies e-mail address.

Interoperability Problems

AOL has never been interested in opening its IM service to third-party software. The AIM client may be free, but it’s theirs, and the intent seems to sign up and keep members for AOL more than just providing a generic IM service.

Observed AIM server behavior, especially in the context of analyzing the protocol, provides this list of entry barriers to clone clients.

• The OSCAR server will disconnect an offending client immediately if it receives a malformed command or command header.

• An out-of-order command, according to the header sequence numbering (not the actual order) causes the server to disconnect the client.

• Lost data is unacceptable in the AIM standard—for example, any client parsing errors in the command stream invariably results in disconnection by the server.

• Tracking of online status is indirect, intentionally tied to the redirects issued when the client periodically requests new advertising content.

The analysis of the server requirements on acceptable data from a client suggests a significant dependency on low-level timing constraints, such as when constructing headers. This might be why the *nix Java implementations for AIM connectivity work so poorly; they are simply too slow in this context.

Increasingly, similar hostile, xenophobic behavior is being noted by users and developers of the ICQ clone clients. Some AIM and ICQ clones perform better than others, but the situation tends to change without warning.

Covert Client Detection

It can be interesting to examine one method that AOL allegedly used to ensure that only its own clients can communicate with the AIM servers. The caveat here is that the analysis relies on anecdotal evidence, but the method is plausible and supported by trials that shows it to work across many client versions. It’s also known that attempts to be interoperative have generally failed because AIM servers always manage to disconnect third-party clients that are otherwise protocol compliant.

At one time, Microsoft designed its MSN client with enough knowledge of the AIM protocol to be able to contact and exchange messages with AIM users. The assumption was that an AIM server at AOL should not care whether it’s talking with the intended AIM client software (as written by AOL) or with the MSN client software (as written by Microsoft). This failed, just like the other attempts.

It was alleged that AOL exploited a software bug in its proprietary client code to covertly detect and disconnect non-AOL clients that attempted to be AIM/Oscar compliant. The described exploit is similar to that used by Internet virus and worm infiltration attempts that inject code using a buffer overrun. The AOL server can use the bug to make the user’s machine execute a code fragment downloaded from the AIM server that will run with an expected response only in the AIM client.

It’s been determined across several versions of the AIM client that all had the same long-standing vulnerability to overlong string data in a particular command context—a bug that was never publicized or fixed. Server packets have also been detected with data that will overrun the 256-byte buffer. A specially crafted 278-byte value can corrupt the running AIM client image, but in a carefully controlled way, so that execution resumes in the packet data.

A portion of the packet data is therefore prepared as executable code to do two things. One is to have the AIM client recover and seem to resume normal execution. The other is before this to form a return packet from some of the downloaded packet data and induce the AIM client to send this packet back to the AIM server.

What for all intents and purposes comes across as a retrospective protocol extension is used as a test of genuineness. No existing version of the AIM client was coded explicitly to respond to this contrived subcase, but the response is implicitly known by any old AIM client that has the “secret” buffer overflow bug.

This illustrates one of the disadvantages of closed source and proprietary solutions. No secret truly remains secret for long, but closed source and secret bugs pose serious risks by inviting exploits by others for purposes not as innocent as confirming genuineness.