BNCSutil

[shadypalm88]

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.

[Blaze]

Nice work.

[hismajesty]

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

[iago]

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

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.

[shadypalm88]

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.)

[NetNX]

i love it <3

[Stealth]

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

[Maddox]

Won't compile under Gentoo Linux.

Code Select Expand


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


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.

[Kp]

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).

[shadypalm88]

Wow, it's nice to see a good response to this.

Code Select Expand


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


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.)

[Maddox]

Wow, it's nice to see a good response to this.

Code Select Expand


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


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.)

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

[Kp]

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

/* 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. */

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 Select Expand

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 */
}

Comments mine.

[shadypalm88]

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

/* 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. */

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 Select Expand

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 */
}

Comments mine.

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.

[Kp]

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.

[UserLoser.]

It's CSB all over again