bnetdocs / bncsutil

The Classic Battle.net™ client library

BNCSUtil

BNCSUtil is the Battle.Net Chat Service Utility which aids applications trying to logon to Classic Battle.net™ using the binary protocol. Specifically, BNCSUtil has functions that help with the cryptography of game versions, keys, and passwords.

BNCSUtil was originally written by Eric Naeseth (shadypalm88) and has since been maintained over the course of several years by the open source Battle.net community.

Usage

#include <bncsutil/bncsutil.h> and link against bncsutil.lib or libbncsutil.so.

Building

To force a specific build (32bit or 64bit) add -DCMAKE_GENERATOR_PLATFORM=x86 or -DCMAKE_GENERATOR_PLATFORM=x64 to CMake flags.

Change BUILD_SHARED_LIBS to build the library as static or shared.

Windows Visual Studio 2022

Conan is used to install dependencies. GMP can't be installed as a shared library due to a bug. Mpir dependency option will be re-introduced once it is uploaded to conan index v2 (MR pending).

In cmd or Visual Studio dev console run:

amd64

"C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Auxiliary/Build/vcvarsall.bat" x64
conan install . -of build -s build_type=Release -o *:shared=False --build=missing
cd build
.\conanbuild.bat
cmake .. -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DBUILD_SHARED_LIBS=1
cmake --build . --config Release

x86

"C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Auxiliary/Build/vcvarsall.bat" x86
conan install . -of build -s build_type=Release -s:h arch=x86 -o *:shared=False --build=missing
cd build
.\conanbuild.bat
cmake .. -G "Visual Studio 17 2022" -DCMAKE_GENERATOR_PLATFORM=x86 -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DBUILD_SHARED_LIBS=1
cmake --build . --config Release

Alternatively open build/bncsutil.sln and build from Visual Studio.

Linux

Using system dependencies

Install libgmp-dev on deb distros or gmp-devel on rpm distros. For 32bit builds, CMake will not warn you if you are missing 32bit glibc and GMP, you must install them manually first (CentOS/Fedora: glibc-devel.i686 and gmp-devel.i686).

cmake -G "Unix Makefiles" -B./build
cd build
cmake --build . --target install --config Release

Using conan

If you are using pyenv or building python3 from source, make sure you have libbz2-dev and liblzma-dev installed first or conan will fail to unpack dependencies.

conan install . -of build -s build_type=Release --build=missing
cd build
bash conanbuild.sh
cmake .. -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release -DUSE_SYSTEM_LIBS=0
cmake --build . --config Release

.deb and .rpm packages

After invoking CMake, cd to build folder and generate them with cpack -G "DEB" and cpack -G "RPM". You can then use gdebi to do a local install of .deb with automatic dependency resolution or yum localinstall on rpm distros. For dnf it's dnf install <name>.rpm.

Note that this is a "development" package which also includes header files.

Library installs to /usr/local/lib, include files in /usr/local/include/bncsutil.

Packages are also available for download from github releases built on Debian Bookworm and Fedora latest.

Development with CLion

1. Run conan from cli as per build instructions above
2. Open the project
3. Tools -> CMake -> Change Project Root -> build
4. Settings -> Build, Execution, Deployment -> CMake -> Add at least this cmake option: -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake

bncsutil's Issues

Using BNCSUtil on OS X 10.5.6

I've tried compilin this under OS X 10.5.6 which would be fairly close to 
linux.  I can try it on my 
Ubuntu 
machine as well. The main problem here on my OS X machine is that its 64-bit 
and the default 
compiler 
options are for 32 bit.

A problem here is that libgmp (GNU MP) must be compiled as 64 bit on OS X and 
as such I must 
compile 
BNCSUtil as 64 bit, which i also did successfully after using the CFLAGS and 
CXXFLAGS "-m64"

I cannot get a test program to compile though, as i get the following message 
from the linker:
Undefined symbols:
  "_bncsutil_debug_message", referenced from:
      _main in ccljODIr.o
ld: symbol(s) not found

This is only after changing mutil.h to reflect the following change:
#if (!defined(BIGENDIAN)) && (!defined(LITTLEENDIAN))
#if MUTIL_CPU_PPC
    #define BIGENDIAN 1
    #define LITTLEENDIAN 0
#elif MUTIL_CPU_X86
    #define LITTLEENDIAN 1
    #define BIGENDIAN 0
#else
    #define MUTIL_CPU_X86 1
    #define LITTLEENDIAN 1
    //#error Unable to determine byte order, define BIGENDIAN or LITTLEENDIAN.
#endif

because the preprocessor cannot determine endianness or cpu type on my OS X 
system.

My compiled OS X binaries are attached for bncsutil.xt to provide additional 
information.

Original issue reported on code.google.com by [email protected] on 3 Mar 2009 at 3:55

Attachments:

• bncsutil-binaries-osx1056.tar.bz2

bncsutil does not compile in Linux

The 'configure' script for building on Linux is broken (did it ever work?).
 As such, there is no way to build a version of bncsutil for Linux.

Original issue reported on code.google.com by [email protected] on 22 Jul 2008 at 8:05

Wrong exeinfo parsed for war3.exe on 1.28.2

war3.exe 05/20/117 13:25:30 558568 is obviouly not correct, must be another bug in pe parser

Digital key value

http://code.google.com/p/bncsutil/source/browse/trunk/src/bncsutil/cdkeydecoder.
cpp#480

Should be:
value1 = LSB4(*(uint32_t*) (((char*) values) + 2)) & 0xFFFFFF03;

According to:
http://forum.valhallalegends.com/index.php/topic,18165.0.html

Original issue reported on code.google.com by AHeinerm on 6 Sep 2010 at 3:42

Re-apply the fix made in war3 cdkey decoding

Patch originally applied in issue #4 with commit 3c784bf was reverted when merging with ghost++ bncsutil code in commit dad53ff#diff-d5a93d7531ccd0fcd11b21ba22798262.

Debugging framework sucks

The current method of printing debug messages from bncsutil just plain
sucks.  It could be way less complicated with the same amount of features.

Original issue reported on code.google.com by [email protected] on 22 Jul 2008 at 8:07

Fix PE parsing of VersionString

With Warcraft 3 1.27a the VersionString parsing from PE is completely broken. Research notes:

1. What is actually sent to bnet for exampe from ghost++: verstr=1.246.162.18. Even more bizarre is that different people got different VersionString results on 1.27a..
2. What we actually need: 1.27.0.16 (this is sent to bnet if you login via w3 client, I believe in reversed order)

Problem is in function getExeInfo() in checkrevision.cpp where the UNIX code is #ifdefed with custom PE parser while Windows one uses WINAPI and therefore works correctly. I believe the actual function doing the read is cm_pe_fixed_version() in pe.c.

Additionally, I found a lib https://github.com/merces/libpe which implements a PE parser. Unfortunately, pev lib shows 1.27.0.52240, the same as Windows Explorer (if you right click on war3.exe and go to properties you will see that number)! It looks like the patch version is calculated in some different way by w3 client.

Finally, official bnet does not enforce correct VersionSring anyway but PvPGN has an option to do so (and we do actually use this in production).

I'm opening this issue just to make it public knowledge that the bug exists, I'm not sure I'll have time or willpower to tackle it but it can be a nice summer project for someone.