My hashing library (BNCSutil) is now ready for public use.  I can't think of anything that could need to be changed at this point that would break compatibility.

A Windows DLL and OSX dynamic and static libraries are available for download.  The DLL comes with a VB module with imports and some convenience functions.  I'm not planning on building Linux binary packages.

The source is also available now.  A simple configure/make/make install should be enough, Windows included.  (MinGW/MSYS or Cygwin (untested on Cygwin) are required to use that, of course.  I've personally been using a custom makefile to build the DLL).  The GNU MP library is required to build.

Anyway, downloads are on the BNCSutil website along with some quick FAQ-style documentation.

If anyone has problems or questions, post a reply in this thread.

Nice work. :)

Nice, but reading through your site the variable names suck. Single letter variable names, unless being used as an accumulator, suck in general. :P

[quote author=hismajesty[yL] link=topic=10733.msg101752#msg101752 date=1109471153]
Nice, but reading through your site the variable names suck. Single letter variable names, unless being used as an accumulator, suck in general. :P
[/quote]

I haven't looked at it, but it's possible that it's ok.  The SRP formula uses a lot of single character names for the formulas:
http://srp.stanford.edu/ndss.html
Notice that all the forumlas use single character variable names.  IF that's what he's doing, then there's nothing wrong with it.


If you indeed have a working Windows library, THANKS! I've been wanting somebody to do it for awhile, but I didn't want to do it myself.  I'm glad somebody finally took the initiave.  Rock on!

And btw, .rpm and .deb suck.  No real Linux guy needs those, and the ones that do should go away.

Mac OS X binaries and the source code have been posted.  (In case you jumped right to the newest message, here is a link to the website.)

i love it <3

I'm strongly considering recoding a big chunk of StealthBot and using this library to do it. :D

Won't compile under Gentoo Linux.

[code]
make[3]: Entering directory `/home/kyle/bncsutil-0.2.1/src/bncsutil'
source='decodekey.cpp' object='libbncsutil_la-decodekey.lo' libtool=yes \
depfile='.deps/libbncsutil_la-decodekey.Plo' tmpdepfile='.deps/libbncsutil_la-decodekey.TPlo' \
depmode=gcc3 /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I..  -DMUTIL_LIB_BUILD  -g -O2 -c -o libbncsutil_la-decodekey.lo `test -f 'decodekey.cpp' || echo './'`decodekey.cpp
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -DMUTIL_LIB_BUILD -g -O2 -c decodekey.cpp -MT libbncsutil_la-decodekey.lo -MD -MP -MF .deps/libbncsutil_la-decodekey.TPlo  -fPIC -DPIC -o .libs/libbncsutil_la-decodekey.o
In file included from ../bncsutil/mutil.h:54,
                from decodekey.cpp:37:
../bncsutil/mutil_types.h:139:45: warning: no newline at end of file
In file included from decodekey.cpp:39:
../bncsutil/decodekey.h:50:24: warning: no newline at end of file
decodekey.cpp: In function `int kd_lock_decoders()':
decodekey.cpp:79: error: `CLK_TCK' undeclared (first use this function)
decodekey.cpp:79: error: (Each undeclared identifier is reported only once for each function it appears in.)
decodekey.cpp:90: error: `EBUSY' undeclared (first use this function)
decodekey.cpp:215:26: warning: no newline at end of file
make[3]: *** [libbncsutil_la-decodekey.lo] Error 1
make[3]: Leaving directory `/home/kyle/bncsutil-0.2.1/src/bncsutil'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/kyle/bncsutil-0.2.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kyle/bncsutil-0.2.1'
make: *** [all] Error 2
[/code]

I'm writing a similar library at the moment, however, it's going to be a more complete connection library with a higher level of abstraction.

For CLK_TCK, make sure your defines are right.  I've had problems in the past with some autoconf'd packages misguessing the necessary defines, leading to bogus unrecognized symbols.  (For example, gdb tries to reference a function that requires the __USE_GNU symbol to be defined, but gdb's source doesn't actually define it.)  For EBUSY, your system's got some problems. :)  afaik, EBUSY is a pretty standard error code, so it should've been present.  Perhaps it's just in an unusual place and the configure script didn't find it?

Even though I'm not the author, I'll go ahead and point out that reporting it non-working isn't all that useful if you can't provide a fix for it, since we can't see your header files to know what to include to make it work (if it's even possible to make it work).

Wow, it's nice to see a good response to this. :D
[quote author=Maddox link=topic=10733.msg102568#msg102568 date=1110006903][code]
decodekey.cpp:79: error: `CLK_TCK' undeclared (first use this function)
decodekey.cpp:79: error: (Each undeclared identifier is reported only once for each function it appears in.)
decodekey.cpp:90: error: `EBUSY' undeclared (first use this function)
decodekey.cpp:215:26: warning: no newline at end of file
[/code]
[/quote]Unfortunately, while writing and testing BNCSutil, I was trying to maintain two separate copies of the source (one on my Mac and one on PC).  When I built those packages, there were still some inconsistencies.

The CLK_TCK macro appears to be deprecated in favor of CLOCKS_PER_SEC.  The decodekey.cpp file has been modified to use CLOCKS_PER_SEC, with a test that defines it to CLK_TCK if CLOCKS_PER_SEC is not present.  Also decodekey.cpp now explicitly includes stderr.h, an oversight on my part (it built fine for me; I should probably use stricter build settings).

New source tarballs are online.  New OSX builds coming momentarily.

(I've also since realized that the site looks pretty bad in IE.  My apologies.)

[quote author=shadypalm88 link=topic=10733.msg102600#msg102600 date=1110057331]
Wow, it's nice to see a good response to this. :D
[quote author=Maddox link=topic=10733.msg102568#msg102568 date=1110006903][code]
decodekey.cpp:79: error: `CLK_TCK' undeclared (first use this function)
decodekey.cpp:79: error: (Each undeclared identifier is reported only once for each function it appears in.)
decodekey.cpp:90: error: `EBUSY' undeclared (first use this function)
decodekey.cpp:215:26: warning: no newline at end of file
[/code]
[/quote]Unfortunately, while writing and testing BNCSutil, I was trying to maintain two separate copies of the source (one on my Mac and one on PC).  When I built those packages, there were still some inconsistencies.

The CLK_TCK macro appears to be deprecated in favor of CLOCKS_PER_SEC.  The decodekey.cpp file has been modified to use CLOCKS_PER_SEC, with a test that defines it to CLK_TCK if CLOCKS_PER_SEC is not present.  Also decodekey.cpp now explicitly includes stderr.h, an oversight on my part (it built fine for me; I should probably use stricter build settings).

New source tarballs are online.  New OSX builds coming momentarily.

(I've also since realized that the site looks pretty bad in IE.  My apologies.)
[/quote]

It can't find time.h when specifing <ctime>

I don't think using CLOCKS_PER_SEC is such a great idea, actually.

[quote]
/* CAE XSH, Issue 4, Version 2: <time.h>
  The value of CLOCKS_PER_SEC is required to be 1 million on all
  XSI-conformant systems. */[/quote]

After reading through your code, it seems like an even worse idea.  You're busy-waiting for up to 6 seconds per attempted lock.  I'd suggest looking into pthread_cond_timedwait, which will let your thread sleep while waiting.  It'll also free you of dependence on CLOCKS_PER_SEC.  Also, several functions toward the end of that file look rather broken.  For instance:[code]MEXP(int) kd_getHash(int decoder, char* out) {
    if (!kd_lock_decoders()) return -1;
return decoders[decoder]->getHash(out);
kd_unlock_decoders();    /* NOTREACHED */
}

MEXP(int) kd_isValid(int decoder) {
    if (!kd_lock_decoders()) return -1;
return decoders[decoder]->isKeyValid();
kd_unlock_decoders();    /* NOTREACHED */
}[/code]

Comments mine.

[quote author=Kp link=topic=10733.msg102622#msg102622 date=1110072328]
I don't think using CLOCKS_PER_SEC is such a great idea, actually.

[quote]
/* CAE XSH, Issue 4, Version 2: <time.h>
   The value of CLOCKS_PER_SEC is required to be 1 million on all
   XSI-conformant systems. */[/quote]

After reading through your code, it seems like an even worse idea.  You're busy-waiting for up to 6 seconds per attempted lock.  I'd suggest looking into pthread_cond_timedwait, which will let your thread sleep while waiting.  It'll also free you of dependence on CLOCKS_PER_SEC.  Also, several functions toward the end of that file look rather broken.  For instance:[code]MEXP(int) kd_getHash(int decoder, char* out) {
    if (!kd_lock_decoders()) return -1;
return decoders[decoder]->getHash(out);
kd_unlock_decoders();    /* NOTREACHED */
}

MEXP(int) kd_isValid(int decoder) {
    if (!kd_lock_decoders()) return -1;
return decoders[decoder]->isKeyValid();
kd_unlock_decoders();    /* NOTREACHED */
}[/code]

Comments mine.
[/quote]Ah, thank you very much for those catches.  I could've sworn that I'd fixed the unreachable unlocks in at least one copy of the code, but I can't find it.  (I've now started using Subversion so I shouldn't run into that type of problem anymore.)

The source tarballs were updated (again).  I'll rebuild the Windows and Mac binary builds shortly.

As a possible longterm fix, you may want to look into some sort of autolock object.  For instance:

class Autolock {
public:
    Autolock() { kd_lock_decoders(); }
    ~Autolock() { kd_unlock_decoders(); }
};

Then you just create an Autolock object where you would've locked the decoders, and the compiler will ensure that all paths out of that basic block will unlock the decoder.  The primary drawback to this is that it enforces a bit more structure on where the unlock occurs than is really necessary, so some constructs that're quite legal cannot be expressed this way.  On the other hand, it ensures that the decoder is always unlocked before returning.

It's CSB all over again :P

No it isnt. It acually.... wait yes it is. Sorta. Its the CSB for NLS.
But hay! I've spent monthas of time working on porting java code to VB (open source, Javaops and JBLS) But then I had to reformat so I lost everything.

I'll continue working on when I get back home. But UL it's not CSB again, it's BnetAuth again.
~-~(HDX)~-~

Yeah, it's nothing like CSB.  Everything I hate about CSB is avoided.

[quote author=HdxBmx27 link=topic=10733.msg103067#msg103067 date=1110397698]
No it isnt. It acually.... wait yes it is. Sorta. Its the CSB for NLS.
But hay! I've spent monthas of time working on porting java code to VB (open source, Javaops and JBLS) But then I had to reformat so I lost everything.

I'll continue working on when I get back home. But UL it's not CSB again, it's BnetAuth again.
~-~(HDX)~-~
[/quote]

The War3 Decode isn't too hard to port from Java to VB but the SRP code might give you some trouble. I think it would be better to do what shady did and turn it into a DLL.

As long as it requires the knowledge of what it takes to emulate a battle.net connection, it's nothing like CSB. CSB was: CSB.connect, didn't take much at all...

But you had to configure all the options and parse the events! It was like Woah major heartbreaker!

::)

im making a program very similar to csb atm using bncsutil and it goes alot more indepth and will probally also contain those favorite bnls functions as well :-/

[quote author=Warrior link=topic=10733.msg103077#msg103077 date=1110401154]
The War3 Decode isn't too hard to port from Java to VB but the SRP code might give you some trouble. I think it would be better to do what shady did and turn it into a DLL.
[/quote]
Ya the SRP screw me over. I'm currently trying to teach myself enuf C# to understand it compleetly. Then i'ma make a DLL for my bot.

See, I'm one of those people who can read a programminglanguage, and know what it does. But I can't WRITE in that language. >.<

Does anyone recommend a good place to interact with others eaither trying to learn, or teaching C#?

Or is there a way to create a Java DLL? Cuz I know a lot more Java then I do C#.
~-~(HDX)~-~

Ive got my own little C# DLL for hashing, although its not complete.  It is BnetHashing.dll. I am working on alpha-numeric and NLS right now.

The SRP stuff really isn't that complicated. The big stumbling block is dealing with 256-bit numbers. Once you can do that, the rest is easy.

[quote author=Zakath link=topic=10733.msg103773#msg103773 date=1110815126]
The SRP stuff really isn't that complicated. The big stumbling block is dealing with 256-bit numbers. Once you can do that, the rest is easy.
[/quote]

Agreed.

Of course, when you're starting with Java or C code, it's much easier than when you're starting with assembly :P

What do you all suggest for dealing with those 265-bit numbers? Any suggestions or tips are welcome.
~-~(HDX)~-~

java.math.BigInteger

GNU Multi Precision Library

I can't remember how MyndFyre did it in C#, but it was built-in similar to Java's.

[quote author=iago link=topic=10733.msg103826#msg103826 date=1110833248]
java.math.BigInteger

GNU Multi Precision Library

I can't remember how MyndFyre did it in C#, but it was built-in similar to Java's.
[/quote]

BigInteger was a class used from The Code Project.

Also, iago confirmed the last part of my SRP class worked.  This is located here.

Oh yeah.  I notified JBLS and BNetDocs of M[2], but forgot to mention it to shadypalm88.  It's pretty simple to do, too :)

[quote author=iago link=topic=10733.msg103910#msg103910 date=1110873148]
Oh yeah.  I notified JBLS and BNetDocs of M[2], but forgot to mention it to shadypalm88.  It's pretty simple to do, too :)
[/quote]I saw that on the Stanford SRP site and have been meaning to add it in, so I did.

I've put out BNCSutil 1.0.0.  I decided it had been in use for long enough with few enough problems to get the bump from 0.x to 1.x.  1.0.0 is fully backwards-compatible with all older versions.

Most of the changes are in the NLS department.  Besides the M[2] check capability, two functions have been added that will allow you to re-use nls pointers (nls_t*).  The Windows build also includes an updated VB module, with the new functions' declarations and a fixed bncsutil_checkVersion function (thanks Archangel!).

Here's a list of changes from my Subversion log:
[quote author=svn.ionws.com]------------------------------------------------------------------------
r19 | ericn | 2005-03-15 21:34:22 -0600 (Tue, 15 Mar 2005) | 9 lines

Version 1.0.0
- Added capability to check server password proof.
- Added functions to re-initialize an nls_t struct.
- Added calculated variable caching to nls.c.
- Added more null-pointer checks in nls.c.
- Removed two unused variables from cdkeydecoder.cpp.
- Removed a few unused source and header files.
- Updated mutil.h to check for the BNCSUTIL_EXPORTS macro.
- Updated libinfo.h with the new version.[/quote]

Edit: Since I know the VB programmers won't read the sources to figure out how to check the server proof, here's the usage comment:
[quote author=nls.h]/**
* Checks the "M[2]" value, which proves that the server knows your
* password.  Pass the M2 value in the var_M2 argument.  Returns 0
* if the check failed, nonzero if the proof matches.  Now that
* calculated value caching has been added, B and salt can be
* safely set to NULL. (vbNullString in VB)
*/[/quote]

BNCSutil 1.0.1 is now available.  This release adds the capability to check NLS server signatures, a bugfix involving NLS client key generation, a VC 2003 project, and does a lot of tidying up.  Here's a full listing:

[quote author=svn.ionws.com]------------------------------------------------------------------------
r23 | ericn | 2005-03-20 20:37:23 -0600 (Sun, 20 Mar 2005) | 29 lines

Version 1.0.1
- Added capability to check an NLS server signature (nls.c).
- Fixed a problem in nls.c where nls_init always used "1234" as the private ephermeral value instead of a random one.
- Added a Visual C++ 2003 project for BNCSutil.
- Moved mpz_t declarations in nls_account create to top of function for the benefit of MSVC. (nls.c)
- Officially deprecated nls_account_logon. (nls.c)
- Officially deprecated kd_isValid. (decodekey.cpp)
- Moved raw large integer const char declarations from nls.h to nls.c.
- A couple of signed/unsigned fixes in nls.c.
- Added guard macros to the following files:
    bncsutil.h
    cdkeydecoder.h
    checkrevision.h
    keytables.h
    libinfo.h
    oldauth.h
- Added extern "C" declarations to:
    bsha1.h
    libinfo.h
    oldauth.h
- Added usage information to decodekey.h.
- calcHashBuf now uses uint32_t instead of unsigned long in final calculations. (bsha1.cpp)
- decodekey.cpp now includes BNCSutil headers before OS-specific headers.[/quote]

Quick updates.

Who cares if it's the new CSB? It was made to replace bnetauth.dll (which was essencially a CSB of hashing) which was horrible.

[quote author=Newby link=topic=10733.msg104782#msg104782 date=1111421992]
Who cares if it's the new CSB? It was made to replace bnetauth.dll (which was essencially a CSB of hashing) which was horrible.
[/quote]

And also NLS.dll which, of course, was only used by assholes who don't care about the amount of time that was wasted by me and others, who just want their life to be easier. 

Well, why doing something that was already done? i mean i dont use NLS.dll, but, if someone made it already, whats the pruporse of making it again?

NLS.dll has a long story behind it.  Basically, it's stolen and unsupported.  BNCSUtil, on the other hand, is maintained and totally supported :)

And also, it's tons cleaner (NLS.dll was just a test prototype) and faster (it doesn't use Storm.dll for the SBig functions, which are sloow)