AOL 6.0 protocol changes...
thruska at cubiclesoft.com
Thu Sep 6 00:14:21 EDT 2007
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
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 (126.96.36.199:443).
Anyone seen this IP address before (i.e. on the old Oscar system)?
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).
The version of AIM used is: 188.8.131.52 (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
[250 bytes of data]
HTTP/1.1 200 OK
Date: Thu, 06 Sep 2007 03:08:58 GMT
Cache-Control: no-cache, no-store, must-revalidate, private
Expires: Thu, 01 Jan 1970 00:00:00 GMT
[1939 bytes of data]
The 'Server' line is interesting. Perhaps a modified AOLserver.
The attached Log.txt file has both the original data* and a hexadecimal
* 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.)
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
*NEW* MyTaskFocus 1.1
Get on task. Stay on task.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Devel