Introduction
AOL runs a service called AIM, AOL Instant Messenger. It provides almost real time text
communication between users of AIM clients. Full AIM service for clients supported by AOL
currently includes a number of features such as file transfer, warning and blocking of abusive
users, setting away messages and user info, maintaining a contact ("buddy") list, and so on. This
system coexists and is completely incompatible with other chat systems such as IRC and ICQ.
Full AIM clients use a a protocol called OSCAR (Open System for Communication in
Realtime). This is a binary protocol and contrary to what the name implies, it is closed.
There is an AIM client built into the AOL program itself, but users need not use AOL to use AIM.
AOL provides free of charge (but not free of advertisements) fully functioning clients for
Windows and Macintosh users. Unfortunately, for UN*X users, until a year and a half ago it had
only provided a buggy, slow Java client. This client was the source of many headaches because it
had to be downloaded for each use and it had a tendency to crash in strange ways. Then in
September 1998, AIM released an new protocol for instant messaging along with a beta Linux
client. This protocol was called TOC, was string based, and to many people's surprise, was
released under the GNU General Public License. TOC is much easier to use and has allowed
numerous Linux based clients to be written without the need of reverse engineering. TOC does
not replace OSCAR, rather, TOC servers act as a proxies for OSCAR, making life for the clients
much easier.
OSCAR
The main protocol that drives AIM is called OSCAR. While it is a closed, binary
protocol, people have managed to reverse engineer it and write Linux clients such as is FAIM and LAIM (LAIM's An Instant
Messenjer[sic]). Since the various AIM services (BOS [Basic OSCAR Service], chat and
advertisement, for example) exist on seperate servers, OSCAR uses a "single-login" concept for
connecting. First the client connects to the authorization server, login.oscar.aol.com, and
sends it information about the nature of the connection it wants. This includes buddy list and
permit/deny information. The authorization server sends the client back a cookie which then may
be used to connect to the various other servers. A more detailed description of the login
procedure can be found here.
OSCAR uses TCP and has a special header for all its commands called a FLAP (if this is an
acronym, no one has bothered to define it). Because FLAP is a higher level protocol than TCP,
there may be multiple commands per packet or a command spread out over more than one packet.
FLAP headers are always six bytes long and are summarized as follows:
Offset Function
0 Command start: always 0x2a '*'
1 Frame type 0x01 through 0x05
2 Sequence number, 2 byte word
4 Data length, 2 byte word
Frame Types are:
0x01 Signon
0x02 Data
0x03 Error
0x04 Signoff
Sequence numbers may start at any number and are incremented for each command and on reaching
0xFFFF they wrap around to 0x0000. The sequence numbers used for the client to server
communication have no relationship to those used for the server to client communication. If a
server receives a sequence number out of order, it will disconnect the client.
Frame type 0x02 contains a data type called SNAC (like FLAP, this is also undefined),
which has a number of headers and a variable length data field. There are a large number of SNAC
types, the ones which have been successfully decoded can be found at here at the FAIM web site. For example,
normal IM
communication is headed with 0x0004 (Messaging) 0x0006 (send message), two unused single byte
flags and a 4 byte unused request ID.
No strings in this protocol suite are null terminated, so all end location must be
determined by the length data fields.
TOC
In late September 1998, AOL released a new protocol for instant messaging called TOC.
This protocol is open, released under the GNU General Public License, and string based. Along
with this protocol they released a Tcl/Tk client called TiK. Currently, AOL no longer supports
TiK, and it is [was?] being maintained privately
here. Since its release, a number of other TOC clients have been written for Linux, the most
popular of which is Gaim (also available is [was?] kit).
Note: Attempts at expanding TOC have yielded is TOC to OSCAR and Talk
to OSCAR. The best we have for TiK is TOC is Kool.
TOC is a subset of OSCAR. All TOC commands also appear in OSCAR, but there are some
OSCAR commands not implemented in TOC. For example, commands such as file transfer have been
implemented in official clients but are not part of TOC. TOC uses strings for most of its
communication, but it still requires each command to have an SFLAP header. There seem to only be
a few differences between FLAP and SFLAP. SFLAP includes the frame type 0x05 "keep alive" which
OSCAR may or may not use, and SFLAP does not use frame types 0x03 and 0x04, "error" and
"signoff". Additionally, the client to server communication for frame type 0x02 (data) and some
other communication, is null terminated, though the host to client communication is not.
By reading the PROTOCOL file included with TiK, which is claimed to
contain all the information anyone needs to write a client, it is clear that AOL expended no
special effort to make writing clients an easy process (or to make their documentation
grammatical). Careful decoding of this file and experiment have uncovered the actual method of
doing things detailed in "how to sign on".
Once you are signed in the protocol provides a large number of commands which involve sending and
receiving messages, managing your buddy list, warning people who bother you, managing chat rooms,
reformatting your username (see normalization), changing your password,
searching for other users, etc. The PROTOCOL file is more clear about the use of these commands
than it is about signing on. Since in general, the client and server use completely different
formats for their communication, special care must be paid to the parsing of commands. The only
catches for client to server communication are to remember to put quotes around arguments that
include spaces and to use a backspace before dollar signs, square brackets, parentheses, quotes
and backslashes. Server to client communication does not encode in this manner, instead, it only
allows confusing characters to exist in the last field of each command, where their purpose as
plaintext is obvious. It is worth noting that although the protocol only mentions HTML for use
in info and away messages, it is commonly used and interpreted in normal messages.
For example, to send a message, your frame should be:
FLAP header (frame type 0x02), null terminated string "toc_send_im <destination user's
normalized name> "Message where you use \"a quotation\" you talk about M\$""
And you should expect your incoming IM's to be in the form:
FLAP header (0x01), "IM_IN:<source user's name, formatted >:<Is auto-response? T or
F>:<message, unencoded (no escape sequences)>" [not null terminated]
History and the Future
AOL released TOC under GPL in March 1999. In July of the same year, it withdrew TOC from
its status as an open protocol and changed it slightly to prevent Microsoft clients from
connecting. This move was protested by open source advocates who noted that GPL has no
termination clause. Microsoft quickly modified their client to allow it to connect using the
modified protocol. In September 1999 Microsoft wrote an OSCAR client that successfully connected
to AOL servers. AOL soon discovered that it could use a buffer overflow bug in its own client to
detect which client was connecting and used this to deny Microsoft clients access. By November,
Microsoft announced its surrender, saying it would not continue for security reasons. In
December, AT&T also released an AIM client, and it was almost immediately blocked by AOL. AOL has
never made any efforts to block clients, such as FAIM, which are not made by competitors.
In response to this game of AOL's and the general chaos surrounding messaging protocols,
there has been a call for a unified standard. While no RFC has yet been issued, the problem is
being worked on and the proposed standard will be called the Instant Messaging and Presence
Protocol. Memos issued by the IETF working group can be found here. However, whether a useful standard
emerges depends not only on the resourcefulness of the IETF, but also on the willingness of the
various corporations currently using proprietary protocols to support the new standard.
Page by Matthew Strait
Sources used
Last major edits: March 2000. Last edited (at all) Nov 2001.