MBNCSUtil v2.0.4.17 (Beta 2) has been uploaded.  This version addresses a number of bugs and adds a couple of new features.

The following is the list of updates in this release:
[list]
[*]Did you know that MBNCSUtil includes a number of additional tools used in the development and testing of MBNCSUtil? These tools and utilities are sample code that indicate how to use some of MBNCSUtil's features, including a command-line tool for downloading files from BnFTP, extracting a file from an MPQ, and even a rudimentary client used to ensure the Lockdown implementation works with class based on JinxBot's ConnectionBase class. These files are all available through the Subversion repository at https://www2.hosted-projects.com/robpaveza/mbncsutil/. You should log in with the username mbncsutil_anonymous with no password. Need a Subversion client? I use TortoiseSVN.

[*]Added event/status support to the Battle.net FTP downloading scheme. To obtain status updates, listen to the BnFtpRequestBase.FilePartDownloaded event.  (Trac ticket #8)

[*]Corrected an issue in which approximately 7.5% of lockdown calls would result in failure. The bulk test tool reports 100% success. If you encounter a revision check failure, please e-mail MyndFyre@valhallalegends.com with the value-string and lockdown MPQ file parameters (as well as the product).  (Trac ticket #9)

[*]Corrected documentation that provided a sample for extracting files from MPQ archives.  (Trac ticket #10)

[*]Corrected an issue reported by Homerlan and iNsaNe (at the vL forums) in which the NLS class was generating a NullReferenceException because the k field had not been initialized to a value. (Trac ticket #12)

[*]Corrected an issue reported by Chriso.de (at the vL forums) in which the NLS class was generating an IOException because certain username values returned shorter names when using Encoding.ASCII.GetByteLength than the actual length of the username.  (Not in Trac)

[*]Explicitly added a NotSupportedException when CheckRevision.ExtractMPQNumber is called with a Lockdown MPQ filename.  (Trac ticket #13)

[*]Corrected an issue reported by Joe[x86] in which the MPQ loader would mistakenly load the 64-bit MPQ support DLL when operating within a 32-bit process on Win32 platforms not running 64-bit OSes.  (Trac ticket #14)
[/list]

First of all, thank you for releasing this new version so fast.

I've spent couple of hours testing it. I've faced new problems. Thus, I'm trying to compare all the different computation steps with JavaOp SRP class.

First problem (in CalculateM1):
[code]BigInteger local_S = ((s_modulus + local_B - verifier) % s_modulus);
local_S = local_S.ModPow((a + (u * x)), s_modulus);
byte[] bytes_s = local_S.GetBytes();[/code]
Here, bytes_s is 32-bytes long, so is local_k array (code below).

[code]byte[] even_hash = s_sha.ComputeHash(even_s);
byte[] odds_hash = s_sha.ComputeHash(odds_s);
byte[] local_k = new byte[bytes_s.Length];[/code]
Hashing with SHA-1 returns a 20-bytes long array. So, even_hash and odds_hash are both 20-bytes long arrays.
But the loop following this code fills local_k (32-bytes long) alternatively with odds_hash & even_hash bytes : the loop stop condition is based on local_k length (32). So, the resulting array is a 32-bytes long array with 16 bytes from odds_hash and 16 bytes from even_hash.
Shouldn't it be a 40-bytes long array as a result?

PS: an exception is raised from CalculateM1 ("Index was outside the bounds of the array").

Second problem (in CalculateVerifier):
[code]byte[] data2 = new byte[salt.Length + hash1.Length];
Array.Copy(salt, data2, salt.Length);
Array.Copy(data1, 0, data2, salt.Length, data1.Length);[/code]
In the third line, we can see a copy of data1 content that is actually "USERNAME:PASSWORD" string and not its hashed value. I think data1 has to be replaced by hash1 (hashed value of data1 string).

Currently, I didn't go further but I'll try to ;)

I think I'm just going to rewrite this from the SRP spec.  I'm sick of trying to patch it up. 

Ironically enough it uses the same naming conventions as my WoW auth (which does work).  So I wonder if I didn't copy stuff over.

Anyway, again I apologize.  I have not had the time to write a client to test this class, and I appreciate the updates.

My problem still exists:
if ((stream.Position + 65 + userNameAscii.Length) > stream.Length)
                throw new IOException(Resources.nlsAcctCreateSpace);

There is insufficient space in the data buffer for the account creation packet.

stream.Position==0, stream.Length==73, userNameAscii.Length==9

0 + 65 + 9 > 73

Hm, I have a theory that it's line 375.  I'll look at it tonight or tomorrow.

I've fixed the problem with logging in thanks to some help from Homerlan (it turned out I wasn't truncating the buffer, something that I struggled to find in my WoW SRP implementation too, as well as some other stuff). 

@Chriso: I've had mixed results with NLS.CreateAccount, so I'm not releasing a new DLL yet.  Good news is that there's no longer an exception being generated.  Bad news is that it appears that if you create an account it could send the wrong verifier in which case you're screwed.  However, the latest bits for NLS.cs as well as DataFormatter.cs and BigInteger.cs (which are needed) are in SVN.  You can get them out using the instructions on the MBNCSUtil website.

I see, thanks for the update.  I'll have a look at the repository later.

@Chriso: I fixed CreateAccount.  It's in the repository, revision 18.  I'm not making a final release until I've fixed the last two functions (ValidateServerProof and ValidateServerSignature).

Corrected VerifyServerProof.  Checked in at revision 19.

Corrected VerifyServerSignature.  Checked in at revision 20.  I'll make a build later this weekend.

Sweet, can't wait.

Apparently my SVN URL has changed:

https://svn2.hosted-projects.com/robpaveza/mbncsutil/

I suggest going for the /trunk folder:

https://svn2.hosted-projects.com/robpaveza/mbncsutil/trunk/

The /branches/ folder has some utilities and testing tools, and the /releases/ folder has the .zip files I make.

Passworded?

As has always been the case, the username is mbncsutil_anonymous with no password.