Bugs item #1654806, was opened at 2007-02-07 20:56 Message generated for change (Comment added) made by mattclay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100235&aid=1654806&group_id=235
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.0.0 beta 6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Clay (mattclay) Assigned to: Mark Huetsch (markhuetsch) Summary: qq protocol login fails Initial Comment: The QQ protocol fails to log in. It worked a few times in 2.0.0 beta 5 then started failing. Now all attempts fail with the following message in the debug log: 您的号码暂时不能使用低版本的QQ，请到：http://im.qq.com/下载安装最新版的QQ，感谢您对QQ的支持和使用 Using the 2005 English version of the official QQ client also results in this message. Only using the 2006 Chinese version of the official QQ client solves the problem. The message roughly translates (by computer) to: Your number temporarily cannot use the low edition QQ, welcome to: http://im.qq.com/ downloading installment most new edition QQ, thank you to QQ the support and the use. Here is a snippet from the debug log: 20:34:06) QQ: ==> [51993] QQ_CMD_LOGIN, from (QQ2006 Spring Festival build) (20:34:06) QQ: ack [51993] QQ_CMD_LOGIN, remove from sendqueue (20:34:06) QQ: Decrypt login reply packet with inikey, 99 bytes (20:34:06) QQ: Unknown reply code: 6 (20:34:06) QQ: >>> 112 bytes -> [default] decrypt and dump 0000: 06 C4 FA B5 C4 BA C5 C2 EB D4 DD CA B1 B2 BB C4 .Dz5D:EBkT]J12;D 0016: DC CA B9 D3 C3 B5 CD B0 E6 B1 BE B5 C4 51 51 A3 \J9SC5M0f1>5DQQ# 0032: AC C7 EB B5 BD A3 BA 68 74 74 70 3A 2F 2F 69 6D ,Gk5=#:http://im 0048: 2E 71 71 2E 63 6F 6D 2F CF C2 D4 D8 B0 B2 D7 B0 .qq.com/OBTX02W0 0064: D7 EE D0 C2 B0 E6 B5 C4 51 51 A3 AC B8 D0 D0 BB WnPB0f5DQQ#,8PP; 0080: C4 FA B6 D4 51 51 B5 C4 D6 A7 B3 D6 BA CD CA B9 Dz6TQQ5DV'3V:MJ9 0096: D3 C3 00 SC. (20:34:06) QQ: Try extract GB msg: 您的号码暂时不能使用低版本的QQ，请到：http://im.qq.com/下载安装最新版的QQ，感谢您对QQ的支持和使用 (20:34:06) account: Disconnecting account 0x813f378 (20:34:06) connection: Disconnecting connection 0x88388c8 ---------------------------------------------------------------------- >Comment By: Matt Clay (mattclay) Date: 2007-02-11 14:27 Message: Logged In: YES user_id=1507917 Originator: YES I've noticed a problem with the dissector you provided. There are 3 incoming packets handled by dissect_request_login_token that fail decryption just before the log-in packet is sent. An error is printed to stderr: Unable to decrypt the buffer passed to new_decr_tvb Which comes from an error returned by qq_decrypt (the only one without a printf label). The following assertions also fail: Warn Dissector bug, protocol QQ, in packet 189: tvbuff.c:387: failed assertion "tvb && tvb->initialized" Warn Dissector bug, protocol QQ, in packet 189: proto.c:2736: failed assertion "tvb != ((void *)0) || *length == 0" Which come from dissect_request_login_token when decr_tvb is used, despite being NULL. ---------------------------------------------------------------------- Comment By: Matt Clay (mattclay) Date: 2007-02-11 00:48 Message: Logged In: YES user_id=1507917 Originator: YES I've been trying out a few programs to trace Windows system calls. So far I've had the most success with a commercial product called TracePlus/Win32. I've been able to see the exact same data in sendto() calls as I'm getting in my Wireshark captures. Unfortunately, when I start recording more than just network API calls, the capture files can get quite large, and this program seems to have a few bugs when dealing with large captures. I'll keep trying it out more, and also see if I can find any good alternatives. As for the NULL string, I know it works, my QQ2006 client is able to login just fine sending it. Of course, QQ2006 seems to have some other issues after login when running as a Limited user. ---------------------------------------------------------------------- Comment By: Mark Huetsch (markhuetsch) Date: 2007-02-11 00:32 Message: Logged In: YES user_id=1529760 Originator: NO That's fantastic! QQ's been using unsalted MD5 for all of its hashes thus far. I suspect with enough toggling with the 3rd pair you could get the pattern to drop out. The hash would be rather hard to figure out by itself, but I'm guessing it's based on the 4 byte thing preceding it, which is probably some simple algebra done on the MAC. Maybe it's an easy linear transformation. A good thing to do would be to iterate through a series of MACs that are off by 1 and try to find something emerging in that long. You can also see if something falls out of the 1st long. I never encountered a NULL for the first string. Thats good to know. Maybe we don't need it. I wish I knew Windows better. Do you know if there's an equivalent of something like strace() where one can watch the system calls QQ's making? That might shed some light on the hypothesized hardware analysis that it's doing. ---------------------------------------------------------------------- Comment By: Matt Clay (mattclay) Date: 2007-02-10 18:30 Message: Logged In: YES user_id=1507917 Originator: YES Using the Wireshark dissector you provided, I have made some progress. I am testing from two different Windows XP systems behind NAT using a single public IP. Both are running QQ2006, one installed as an administrator (Machine #2), the other as a limited user (Machine #1). My testing is with a single QQ login and password. The first "Unknown String" is set on Machine #2. On Machine #1 the values are null. I suspect this value is derived from some hardware analysis not available to limited users. Changing the machine's IP or MAC has no impact on this value. The first pair of "Unknown Long" and "Unknown String" values seem to be keyed off of the MAC address and some other value. They are constant from session to session. If I change the MAC address on a system, these values change. If I restore the original MAC, these values are also restored. If I use the same MAC on another machine (when the other machine is not using it), the values are different. The second pair of "Unknown Long" and "Unknown String" values seem to be keyed only off the MAC. They are constant from session to session. If I change the MAC, these values change. If I restore the MAC, these values are restored. If I use the MAC on another machine (when the other machine is not using it), the values are the same on that machine. Changing the IP address of the machine seems to have no impact on any of these values. ---------------------------------------------------------------------- Comment By: Mark Huetsch (markhuetsch) Date: 2007-02-09 14:48 Message: Logged In: YES user_id=1529760 Originator: NO If you want to help, you can compile Wireshark with this dissector (you might just rename it packet-oicq.c and copy it over that file, so you don't need to deal with Makefiles and the like). Enter the double MD5 hex of your password in the QQ preference, and you'll be able to decrypt some of the packets. Look at the outgoing login packet. There are 3 unknown areas (I think 3 16-byte hashes, 2 of which are preceded by some 4-byte somethings). If you can experiment with different IP addresses and computers to deduce fixing which of those causes the unknown areas to be fixed, you would greatly help me. I believe the unknowns are somehow generated from one or the other. File Added: packet-qq.c.gz ---------------------------------------------------------------------- Comment By: Matt Clay (mattclay) Date: 2007-02-09 08:59 Message: Logged In: YES user_id=1507917 Originator: YES Out of curiosity, I decided to take a look at the new login scheme myself. I've done some packet captures using Ethereal during login with QQ2006, and found two commands used before QQ_CMD_LOGIN, 0x0091 and 0x00ba. Not being familiar with the QQ protocol, I don't know if these are new commands or not. I haven't checked against an older QQ version yet. If you think I can be of any assistance figuring out the new login scheme, let me know the best way to communicate any of my findings (in the bug tracker, or some other way). ---------------------------------------------------------------------- Comment By: Mark Huetsch (markhuetsch) Date: 2007-02-09 00:36 Message: Logged In: YES user_id=1529760 Originator: NO I suspect the disabled accounts are stored on a certain set of servers which have already been transitioned to accepting only the new login scheme, whereas the rest are on servers that have yet to be upgraded. Unfortunately, I need a couple of Windows machines and a free day or two to figure the scheme out and I won't have access to those things for a few weeks at the very least. ---------------------------------------------------------------------- Comment By: Matt Clay (mattclay) Date: 2007-02-08 18:50 Message: Logged In: YES user_id=1507917 Originator: YES Do you have any idea what causes specific accounts to be affected by this problem? ---------------------------------------------------------------------- Comment By: Mark Huetsch (markhuetsch) Date: 2007-02-08 15:49 Message: Logged In: YES user_id=1529760 Originator: NO Damn. I was hoping to have more time before this started happening. I need to find some free time and reverse engineer the new login scheme. The bad news is, I can't do much to help you until then. The good news is, some (probably most?) accounts still work. Thanks for letting me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100235&aid=1654806&group_id=235 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Gaim-bugs mailing list Gaim-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gaim-bugs
