AOL 6.0 protocol changes...

[Thomas Hruska]

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 kdc.uas.aol.com.
>>
>> * 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' = kdc.uas.aol.com:443.
>>
>> 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.

http://www.CubicleSoft.com/MyTaskFocus/