Gaim 0.11.0pre14 source tarball Gaim 0.11.0pre14 source bz2ball Other Releases (Patches, RPM, DEB) CVS Information Nightly CVS Tarball The Amazing Marko Cam Official FTP Site SourceForge Project Page

So What's Disconnecting Oscar

What follows is a somewhat technical discussion of what's happening that's causing Oscar to get disconnected. The net of it all is that you can't stay connected using Oscar unless if you have AOL's AIM installed on your computer. This is probably all that most people need to know. The rest of this, then, is just for historical purposes. Most numbers in this are hex; it's not important though.

Brief discussion of how the Oscar Protocol works

Oscar messages from the server are sent with a 6 byte header which contains the length of the data (as well as other mostly useless information, for our purposes anyway). The data then follows the header. Data is stored in SNACs, which are composed of a type/subtype pair of words. There are 15 or so types, and each type has its own set of subtypes. For example, an incoming message is type 0004 and subtype 0007. Each type/subtype pair then has a certain set of data associated with it. That's pretty much all you need to know about how the protocol works for this discussion.

What the AOL server is sending us

There are certain type/subtype pairs that aren't normally used. Since they aren't normally used, only AOL knows what they are. With the recent blocks, the server has been sending us a certain type/subtype pair, 0001 001f. No one (other than AOL) knew what this was; but we did know that in response to it, the client is supposed to send back 16 bytes of data. If you don't send back the correct 16 bytes, then after a short period of time (generally a minute or two), the server would disconnect you. The data sent by the server in the SNAC changed daily, and the 16 bytes that got sent back changed daily. No one knew what the data from the server meant, or how it affected the 16 bytes that got sent back.

What those 16 bytes are

When the server sends the 0001 001f SNAC, it also sends an offset and a length as the data content. You then read the specified number of bytes from a file (I'll tell you which file later, though you've probably already guessed), starting at the specified offset. It's then run through md5 (which outputs 16 bytes), and is sent back to the server. Since it's put through md5, you cannot know from looking at the transfer what the file contents originally were. This means it is not insecure at all. The file that it's getting the data from is... aim.exe!^*

What this means

So when you receive the 0001 001f SNAC, you are expected to send back an encrypted chunk of the AIM binary. The only way to feasibly do this is to have a copy of the binary on your computer. This is an incredibly clever hack by the AOL developers. If it didn't really piss me off I would have to commend them on their ingenuity. Basically, if you want to use Oscar, then as long as AOL is having the server send the 0001 001f SNAC, you need to have aim.exe on your computer. Either that, or change libfaim to send the right 16 bytes every time the data in the SNAC changes (though, it could change for each connection, so this may not be possible). There is no fun solution. It would be possible, theoretically, to embed aim.exe inside of libfaim (encoded as a byte array or something similar), and that may in fact be the only solution, but it's one that the libfaim developers would prefer not to do. It may also be possible to set up a server that libfaim could connect to that would provide correct values, but this would be as illegal as embedding aim.exe in libfaim, would be "less clean" in the way that it's implemented, and would lead to other reliability issues, such as making sure the server responds before the AIM connection times out.

^*Actually, they're taking it from the address space where aim.exe gets loaded in memory, just dereferencing a pointer. But the net effect is the same.

``Dedicated to the near-memory of Rob Flynn. Let's start remembering people while they're still alive.''
- Mark Spencer -

Website design and development provided by Portal Web Design. Hosted by