AOL 6.0 protocol changes...

[Mark Doliner]

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!

> I'm also pretty sure that what I've captured is just the login 
> sequence.   I had two test accounts set up and I sent a couple 
> messages back and forth and none of the messages showed up in the 
> capture.  You'll note an IP address shows up during the attached 
> sequence (64.12.24.118:443). Anyone seen this IP address before 
> (i.e. on the old Oscar system)?

So all this traffic was encrypted using standard https encryption?  Mind if I
ask how you obtained the unencrypted version?  I don't recognize that IP
address, but I don't generally recognize any of AOL's IP addresses.

> My guess is that the AIM client connected to that server after 
> logging in and all messaging occurred there (i.e. acts in a somewhat 
> similar fashion to the Oscar setup - login separated from messaging).

That seems reasonable.  Two things that are interesting to me:

1. That's a lot of data being exchange for something as simple as
login/authentication.  With oscar the authentication process is very short. 
Of course, there's lots of other login type stuff that happens when you make
the first connection to the basic oscar server (bos).

2. What is "krbtgt"?  Is that another screen name?  It appears in there a few
times.  Maybe the actual conversation data itself is encrypted, but the
framing data surrounding the conversation isn't?

> The version of AIM used is:  6.1.41.2 (this probably shows up 
> somewhere during the communication)
> 
> Of interesting note...the password is plain-text.  This is just a 
> throwaway AIM login.
> 
> So, as already suggested, HTTPS is definitely in use.
> 
> kdc.uas.aol.com:443 seems to be a HTTPS server BUT the 
> request/response sequence is somewhat unusual looking:
> 
> ----------------------
> POST / HTTP/1.1
> Accept: application/x-snac
> Content-Type: application/x-snac
> User-Agent: CLC/1.0
> Host: kdc.uas.aol.com
> Content-Length: 250
> Connection: Keep-Alive
> Cache-Control: no-cache
> 
> [250 bytes of data]
> ----------------------
> 
> ----------------------
> HTTP/1.1 200 OK
> Server: KDC/uas_kdc_v11_r1.3
> Date: Thu, 06 Sep 2007 03:08:58 GMT
> Pragma: no-cache
> Cache-Control: no-cache, no-store, must-revalidate, private
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Connection: Keep-Alive
> Content-Type: application/x-snac
> Content-Length: 1939
> 
> [1939 bytes of data]
> ----------------------
> 
> The 'Server' line is interesting.  Perhaps a modified AOLserver.

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 :-)

> 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.

> I'm not sure how to proceed from here.  Someone far more 
> knowledgeable about the known protocols will probably be able to 
> break this faster than me.

Maybe try to write a client that mimics AIM 6?  Makes the same HTTPS
connection, tries to log in, etc.  I imagine you'd have to log in and out with
AIM 6 a lot of times and take packet captures and compare the differences.

-Mark