/pidgin/main: 5e65b489a31d: oscar: Add a comment explaining the ...
kakaroto at kakaroto.homelinux.net
Fri Jun 17 19:11:41 EDT 2016
Author: Youness Alaoui <kakaroto at kakaroto.homelinux.net>
Date: 2016-06-13 13:22 -0400
oscar: Add a comment explaining the data and meaning of the KDC binary blob
libpurple/protocols/oscar/kerberos.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diffs (24 lines):
diff --git a/libpurple/protocols/oscar/kerberos.c b/libpurple/protocols/oscar/kerberos.c
@@ -328,6 +328,20 @@ kerberos_login_cb(PurpleHttpConnection *
* https://kdc.uas.aol.com with the user's username and password and
* receives the IM cookie, which is used to request a connection to the
* BOSS server.
+ * The binary data below is what AIM 126.96.36.199 sends in order to authenticate
+ * to the KDC server. It is an 'X-SNAC' packet, which is relatively similar
+ * to SNAC packets but somehow different.
+ * The header starts with the 0x50C family follow by 0x0002 subtype, then
+ * some fixed length data and TLVs. The string "COOL" appears in there for
+ * some reason followed by the 'US' and 'en' strings.
+ * Then the 'imApp key=<client key>' comes after that, and then the username
+ * and the string "im/boss" which seems to represent the service we are
+ * requesting the authentication for. Changing that will lead to a
+ * 'unknown service' error. The client key is then added again (without the
+ * 'imApp key' string prepended to it) then a XOR-ed version of the password.
+ * The meaning of the header/footer/in-between bytes is not known but never
+ * seems to change so there is no need to reverse engineer their meaning at
+ * this point.
void send_kerberos_login(OscarData *od, const char *username)
More information about the Commits