Bugs item #1654806, was opened at 2007-02-08 04:56
Message generated for change (Comment added) made by dalvarado
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: dalvarado (dalvarado)
Date: 2007-03-12 05:06

Message:
Logged In: YES 
user_id=1741268
Originator: NO

Two of my accounts aren't working, and two others that I know of are. 
Strange that this only affects some accounts and not others, but being able
to contest the captcha seems to be the key issue, at least from my point of
view.  Even using the latest version of QQ, 2007 beta, two of my accounts
always ask for captcha authorization, as shown in the screenshot on this
page, which I know you are already aware of:

http://forums.cocoaforge.com/viewtopic.php?t=12369


----------------------------------------------------------------------

Comment By: Tai (taiyang)
Date: 2007-03-09 17:20

Message:
Logged In: YES 
user_id=1674198
Originator: NO

Wow I didn't know some accounts were restricted a month before mine just
did.
It sucks because Tencent had recently filed a lawsuit against a very
popular Chinese 3rd party QQ addon (basically a full protocol) and won.
They probably sensed this and added some script to disable older versions
from logining in.
But I think its still possible to change the version string gaim sends to
their server. 

----------------------------------------------------------------------

Comment By: Mark Huetsch (markhuetsch)
Date: 2007-02-11 22:52

Message:
Logged In: YES 
user_id=1529760
Originator: NO

That doesn't surprise me.  I don't have a totally clear picture of what's
going on pre-login.  A bunch of requests for which server to log into, and
I think I remember some unknown packets (maybe it was 3).  But I think I
also decided that they probably weren't necessary to log in, and started
work on those hashes.  Anyway, the dissector is a work in progress.

----------------------------------------------------------------------

Comment By: Matt Clay (mattclay)
Date: 2007-02-11 22: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 08: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 08: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-11 02: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 22: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 16: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 08: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-09 02: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 23: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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gaim-bugs mailing list
Gaim-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gaim-bugs

Reply via email to