NLS Purgatory

[shadypalm88]

Disclaimer:  I am not using any of the leaked NLS/SRP code.  The code being used is from a library I wrote myself using iago's open documentation.

This could turn out to be the second question I'm asking this week that comes from looking at the same code too much.  Nevertheless, I can't figure out what's wrong, and at this point am a little confused as to what the problem could even be.  Here's the situation:

The password proof (M[1]) being generated for test logons by my library on Windows matches that being generated by my library on a Mac (relevant because that's where it was originally developed), as well as that from class util.SRP from JavaOp2.  For a real login, the proof (as well as S and K values) that my bot gets from the library matches that from the test application when the server's public key is given to it and the client keys remain constant.  This also matches the test application on the Mac as well as JavaOp.  Sounds good, right?

I thought so, too, but the login attempt always comes back as "incorrect password".  Setting my bot to use BNLS, which uses much of the same network/packet handling/etc code, works (so I really am entering the correct password).  I believe the packets are being built and processed correctly, but I'll provide them below.

If they look good to you guys, what else could the problem be?

Variables:

a (Client Private Key): 1234 (Super Happy Fun Hello Kitty Secure!)

A: BB 73 C5 D9 F0 34 DB 49 3B 69 C7 B1 95 80 C7 85 E4 87 BB 3A 55 7C 98 DC D8 7E 9B A7 42 8F F5 A5

B: 4D F3 5E 3C 7D CA 4B 15 2A 89 05 C3 B7 76 FC D8 0B BD 28 E6 5B 3F DE D8 7E 85 E3 BE BF BB C6 3F

Salt: 4F FC A9 55 01 51 C0 FA A9 B7 0A AF 48 02 67 8F 9E A3 70 3F 5F B9 66 31 59 E6 73 50 0B 72 2B 65

S: EC 96 8E F3 78 20 8E B2 E7 44 C6 B7 0E 1B 04 5A C4 2F 4C 8B 56 60 27 01 A6 A4 CC 52 54 5B 6E 89

K: 6E 82 8D E6 2C CF 6D 65 55 63 1A 4A 12 A9 0B 37 2D 98 37 CB A1 60 E4 D0 18 8A 07 47 1F DE A4 32 F0 1C 58 39 AD 93 80 08

M1: 00 15 2F EE C5 CB 40 3E AB 82 CB 2C 30 76 80 A3 7F 8E DF BF

Note again:  Shouldn't the code blocks really be fixed-width text? (font-family: monospace)

C->S  SID_AUTH_ACCOUNTLOGON (0x53)

Code Select Expand

ff 53 33 00 bb 73 c5 d9  f0 34 db 49 3b 69 c7 b1 .S3..s.. .4.I;i..
95 80 c7 85 e4 87 bb 3a  55 7c 98 dc d8 7e 9b a7 .......: U|...~..
42 8f f5 a5 44 61 52 4b  2e 43 6c 6f 61 6b 2e 4b B...DaRK .Cloak.K
6f 47 00                                         oG.

S->C  SID_AUTH_ACCOUNTLOGON (0x53)

Code Select Expand

ff 53 48 00 00 00 00 00  4f fc a9 55 01 51 c0 fa .SH..... O..U.Q..
a9 b7 0a af 48 02 67 8f  9e a3 70 3f 5f b9 66 31 ....H.g. ..p?_.f1
59 e6 73 50 0b 72 2b 65  4d f3 5e 3c 7d ca 4b 15 Y.sP.r+e M.^<}.K.
2a 89 05 c3 b7 76 fc d8  0b bd 28 e6 5b 3f de d8 *....v.. ..(.[?..
7e 85 e3 be bf bb c6 3f                          ~......?         

C->S  SID_AUTH_ACCOUNTLOGONPROOF  (0x54)

Code Select Expand

ff 54 18 00 00 15 2f ee  c5 cb 40 3e ab 82 cb 2c .T..../. ..@>...,
30 76 80 a3 7f 8e df bf                          0v......         

S->C  SID_AUTH_ACCOUNTLOGONPROOF  (0x54)

Code Select Expand

ff 54 1c 00 02 00 00 00  00 00 00 00 00 00 00 00 .T...... ........
00 00 00 00 00 00 00 00  00 00 00 00             ........ ....   

[UserLoser.]

Are you putting the password and username to upper cased before performing any of the hashes?  I don't remember which ones anymore, but wherever you have username ":" password

[shadypalm88]

Are you putting the password and username to upper cased before performing any of the hashes?  I don't remember which ones anymore, but wherever you have username ":" password

Yes.  Besides,

The password proof (M[1]) being generated ... by my library on Windows ... matches the test application on the Mac as well as JavaOp.

[dxoigmn]

Is this a one time occurance?  I remember Skywing or Kp saying something about Bncs rejecting valid logins for some reason.  The interesting thing is that this could be detected by the client but no one knows how except maybe Skywing and Kp.

[Kp]

It's not that hard to figure out if you examine the parameters involved when it happens.  In essence, there's a bug in Blizzard's implementation that causes part of the validation buffer to be incorrect in rare cases, and there's no way for the client to know what to place in the afflicted cells, so you have a 1 in 2**8n chance, where n is the number of afflicted cells, of getting the answer right.

[tA-Kane]

I also recall that by the time that you can detect it, it's too late in the login sequence to be able to recover.

It also looks as if the code tags now use a monospace font. Nice request, shadypalm...

[iago]

You can't detect it and recover, but you can detect it and fail, then retry.

But anyway, if your code matches up with my java code for our test data, then there's onty one possibility that I can think of: you're processing the incoming data (B, I think) wrong.


And as a disclaimer: yes, he's using legit code, in case anybody's wondering.  I helped him work on it, based on http://www.javaop.com/~iago/SRP.html

[shadypalm88]

This could turn out to be the second question I'm asking this week that comes from looking at the same code too much.

*Cloaked sighs*

[T]hen there's onty one possibility that I can think of: you're processing the incoming data (B, I think) wrong.

When importing the B value into the arbitrary-length integer library I am using, I was telling it that the lengh of B was 20 bytes.  (It's actually 32.)

I'm surprised that I didn't figure this out when typing out my original question.  I now realize that the testing I had done where my lib and JavaOp2 came out the same was when the salt and B values were set to 0.  I hadn't previously actually tested it against JavaOp with real values.  It wouldn't have been the first time I'd solved a problem just by starting to type it out on this forum.

Well there it is then.  AFAIK, all parts of my library (BNCSutil) are now finished and working properly.  This covers CD-key decoding and hashing for SC/W2/D2/W3/TFT, all version checking / EXE info, and old and new logon system logons.  I'll definitely be releasing binary versions of this library, and very likely the source as well.  I'm hoping it'll be a nice alternative to the "leaked" DLL's and Bnetauth.

As always, thanks to everyone who helped.  And for fixing the code blocks!

[Warrior]

Thanks, Shadypalm. Good job.

[iago]

I'll definitely be releasing binary versions of this library, and very likely the source as well. 

I know I should have made my code GNU GPL, so that any derived work instantly had to be GPL

But seriously, I'm glad you got it.  The problem seemed pretty obvious to me, but I had a stroke of genious I think

[shadypalm88]

I know I should have made my code GNU GPL, so that any derived work instantly had to be GPL

Actually, maybe you'll be interested to know that something like this has been in all source and header files since I started:

/**
* BNCSutil
* Battle.Net Utility Library
*
* Copyright (C) 2004 Eric Naeseth
*
* Utility Headers
* October 23, 2004
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
* Lesser General Public License for more details.
*
* A copy of the GNU Lesser General Public License is included in the BNCSutil
* distribution in the file COPYING.  If you did not receive this copy,
* write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
* Boston, MA  02111-1307  USA
*/

So I guess you'll have to settle for lesser. 

Edit:  Even though that the people in the "community" who I would expect to be honorable enough to abide by the license are the ones I'd expect to basically do what the LGPL outlines anyway.

[warz]

Handy. When / where you plan on releasing this?

[iago]

LGPL is actually a lot less strict in terms of using its code in a non-LGPL project.  GPL is where it's at