AOL Instant Message Protocol

The majority of this write-up will be dedicated to the actual "IM" part of AOL's Instant Message Protocol, as that is what's really interesting:

I first stumbled across this information while playing around with the idea of creating my own IM client, so I had spent a considerable amount of time using a packet sniffer on my NIC recording my network traffic. The first thing that's apparent is the insecurity of the AIM traffic.

The basic structure of a packet for a simple IM as as thus:

The ethernet and IP headers are as expected, with the TCP flags PSH and ACK set. The checksum must be accurate in order for the message to validate with the AOL server, otherwise it is, I believe, discarded.

The payload of the packet contains the following:

Command Start: 0x2a - This means that the packet is an IM
Channel ID: 0x02 - Unknown purpose at the moment
Sequence Number: 737 - Variable based on packets sent back and forth between your computer and the AOL servers
Data Field Length: 146 - Variable based upon how much you actually say in the IM
FNAC Family ID: 0x0004 - Unknown purpose
FNAC Subtype ID: 0x0006 - Unknown purpose
Screen Name: HibikiTokai0 - Recipient of the message if you are sending the packet, sender of message if you are recieving packet
Body: Sample message - The complete unencrypted contents of your message to/from $SCREEN_NAME

It is because of this that I do not use the default AOL IM client, the combination of the facts that (a) I spend a large portion of my time on a university network, in other words, an unswitched LAN with many unknown people and (b) I do not like other people to be able to read my IMs.

In order for someone to actually read the IMs, it requires a packet sniffer (no great difficulty to obtain one of those), a little basic knowledge of how computers and networks function (again, no difficulty obtaining this), and a terminal amount of boredom, in order to read about other people's private lives.

However, despite all of this, AOL will probably not encrypt their client's network traffic any time soon, so I recommend using a third-party such as Trillian (http://www.trillian.cc) for its SecureIM feature.