AOL 6.0 protocol changes...
thruska at cubiclesoft.com
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 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
> 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
> 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.
*NEW* MyTaskFocus 1.1
Get on task. Stay on task.
More information about the Devel