AOL 6.0 protocol changes...

Thomas Hruska thruska at
Sun Sep 9 15:01:58 EDT 2007

Mark Doliner wrote:
> On Thu, 06 Sep 2007 00:14:21 -0400, Thomas Hruska wrote
>> Sorry for the lengthy delay in my reply on this thread.  AIM 6.1 was 
>> quite the stubborn beast but I finally got access to the underlying 
>> data.  I've tried to make heads/tails of the protocol but I'm not 
>> seeing how it maps to any documentation that already exists.  I've 
>> attached some data to this message that represents a (mostly*) 
>> complete communication sequence with
>> * I say "mostly" because the file could be cut off.  However, it 
>> probably isn't.
> I'm sorry I haven't replied to this thread at all.  I agree with Sean that it
> is unlikely that AOL will shut off access from oscar clients any time soon. 
> If iChat starts using the new https stuff then we might want to start
> worrying.  But I also agree with you, Thomas, that we should do what we can to
> try to figure out how the new protocol works.
> And thank you for taking a lot of initiative in doing that!  Please continue,
> this looks promising!

Thanks Mark.  And I agree that AOL isn't likely to do it soon, but it is 
a pretty big shift from the FLAP/SNAC/TLV way of doing things.  I love 
the challenge!

> Heh heh, Googling for the server, user-agent and content-type strings returns
> only your mail to this mailing list.  Doesn't look like many other people have
> looked into this :-)

That's part of the challenge - I enjoy doing stuff that no one else has 
done before that ultimately betters mankind.

>> The attached Log.txt file has both the original data* and a 
>> hexadecimal representation.
>> * Slightly modified - unprintable characters are replaced with an 
>> underscore '_' character.
>> In the file 'Src' = the AIM client, 'Dest' =
>> There appear to be Length-Value pairs in the file but also appears 
>> to possibly have the usual TLVs mixed in.  The first few bytes are 
>> baffling...they don't seem to correspond to any SNAC codes (perhaps 
>> just "magic" bytes?  But it isn't a FLAP signature, as far as I can 
>> tell.)
> Yeah, I don't seen anything familiar in there at all.  No SNACs for FLAPs that
> I can recognize.  Some length-values for sure... I'm not sure there are types
> preceding the lengths... find a string, you can see the 2-byte length
> preceding that, but usually the 2-bytes that precede the length are either 0
> or the value from the previous string.

Based on other discussion, the data seems to be ASN.1 encoded.  As part 
of the Kerberos protocol.  I'm looking into this.

Thomas Hruska
CubicleSoft President
Ph: 517-803-4197

*NEW* MyTaskFocus 1.1
Get on task.  Stay on task.

More information about the Devel mailing list