I've been running a BNLS server for some time now, mainly so I can update one program rather than updating countless bot's.
I was trying to talk Hdx into adding the packet into JBLS awhile back, and he thought I should post the packet spec here, to get ideas/feed back.
Altho im pretty sure each useage contains enough infomation to support predictible changes to warden in the future, they are open to suggestions. :p
All of the below is already in existance, but if you can think of more useages, more variables to include, or ideas in general, please post them!.

I've spent a few hours writeing up some protocol spec below, but im not to good at explaining things, so feel free to ask about anything that I haven't explained very well.

note: I used 0x7D, as it was well into no-mans-land, since I didn't want to step on skywings/yoni's toes, if or when they ever pick up on the orginal BNLS project and start adding new packets (for sc2/d3 maybe) :p



BNLS_WARDEN (packet 0x7D);
C>S Format:
[code]
    (BYTE)     Useage
    (DWORD)    Cookie
    Useage 0x00 (Warden Seed)
        (DWORD)    Client
        (WORD)     Lengh of Seed
        (VOID)     Seed
        (STRING)   Username (blank)
        (WORD)    Lengh of password
        (VOID)     Password
    Useage 0x01 (warden packet)
        (WORD)     Lengh Of Warden Packet
        (VOID)     Warden Packet Data
    Useage 0x02 (warden 0x05)
        (DWORD)    Client
        (WORD)     Lengh Of Seed
        (VOID)     Seed
        (DWORD)    Unused
        (BYTE[16]) Module MD5 Name
        (WORD)     Lengh of Warden 0x05 packet
        (VOID)     Warden 0x05 packet
    Useage 0x03 (warden checks/ini file)
        (DWORD)    Client
        (DWORD)    Info Type (0x01)
        (WORD)     Unused (must be 0x00)
        (VOID)     Unused
[/code]
S>C Format:
[code]
    (BYTE)     Useage
    (DWORD)    Cookie
    (BYTE)     Result
    (WORD)     Lengh of data
    (VOID)     Data
[/code]


BNLS_WARDEN can currently support 2 methods for SC/BW/W3ROC/W3TFT.
The first method (useage 0x00 and 0x01) allows you to support warden over battle.net with out any need for installing warden related code and algorithm.
- It does how ever, require you stay connected to the server, or at least, connect each time a new request comes in from bnet.
The second method (useage 0x02 and 0x03) allows you to support the more basic side of warden, why leaving all the more complex things to the BNLS server.
- One side to this method, allows you to support warden, with out having to worry about downloading, loading and executeing warden modules, from bnet.

A basic description of the packet values above;
The useage byte, tells the BNLS server how to parse you'er request.
- 0x00 Is for initializeing a new bnet connection, to allocate a packet handler for you, on the server.
- 0x01 Is for having you're warden requests handled, via the pre allocated packet handler, done in useage 0x00.
- 0x02 Is for getting the correct data in responce to warden 0x05 and a new set of RC4 keys -- as well as any other future module requireing packets.
- 0x03 Is for getting a list of offsets and their contents, to be used in you're warden 0x02 handler.
The cookie is sent back to the client, to identifying one request from another.
- With useage 0x01, this value must remain the same as the one you initialized for a given bnet connection, with useage 0x00.
- Its important to use differnt cookies for differnt bots when dealing with useage 0x00 and 0x01, so not to have a RC4 cryption keys currupted and have to reconnect to bnet.
- For more info on useage 0x00/0x01 cookies, see the "First Method" description below.
The client value identifys what client you connected to bnet with.
- It can be the DWORD you use over bnet (Ie; PXES) or one of the below;
- 0x01 = Starcraft
- 0x02 = Broodwar
- 0x03 = Warcraft 2
- 0x04 = Diablo 2
- 0x05 = Diablo 2 LOD
- 0x06 = Starcraft Japan
- 0x07 = Warcraft 3
- 0x08 = Warcraft 3 TFT
- 0x09 = Diablo
- 0x0A = Diablo SWare
- 0x0B = Starcraft SWare
The seed value, is used to initialize wardens cryptography.
- Currently, This value should be the 1st DWORD of the first CDKey hash, in C>S 0x51.
- For now, only a 4 byte seed is acceptable.
- Note* If you are useing the older logon protocol (BNCS 0x06, 0x07, etc), this seed value should be zero.
The Module MD5 Name is obtained from the warden 0x01 packet, starting at the 2nd byte.
The username and password, are for possible future updates.
- They can be ignored, for now.
- Just leave the user name blank, and the lengh of password to zero.
For the result value in the responce, see the "Result values and meanings" description below.


[Size=6]First Method[/size] (useage 0x00 and 0x01)
This connection style, allows you to support warden over battle.net with out any need for installing warden related code and algorithms into you're program.
It does how ever, require you stay connected to the server, or at least, connect each time a new request comes in from bnet.
This is basicly, A fully managed remote warden handler.
The Cookie value is used to allocate (useage 0x00) and access (useage 0x01) a warden connection/handler.
Once you init a cookie (useage 0x00), it can then be sent back to BNLS with a bnet warden packet (useage 0x01) to have the request handled, and a responce sent back to you to be sent on to bnet.
You can manage multiple bnet connections/wardens via 1 or more BNLS sockets.
Useage 0x00:
When Logging onto battle.net, and building you're C>S 0x51 packet, you need to obtain the first dword of the first cdkey hash. This is the seed value used in useage 0x00.
You then send this seed value to BNLS, via useage 0x00, to activate, or reset then given cookie.
This cookie value must be differnt from any other bots useing the same BNLS server from you're network, so not to cause clashs's.
The BNLS server will respond telling you if the cookie was successfully initialized or not.
The data in the responce should only ever be present if the responce contains an error code.
Useage 0x01:
Once you have successfully initialized a cookie for a bnet connection, you are ready to faward all bnet warden traffic to BNLS.
If the result comes back with an error code, the "Warden Packet Data" may contain infomation about the given error code.
If the result comes back successfull, the the "Warden Packet Data" will contain the BNCS 0x5E payload to be sent to bnet.
you should only send the responce data to bnet if the request was successfull, the lengh of the data is 1 or more and its a 0x01 useage responce.
Note, after initing a cookie with useage 0x00, that space will remain allocated on the server, for up to 3mins.
This allows you to reconnect, and still beable to resume where you left off, with out having to reconnect to bnet.
You should only send the PAYLOAD of the S>C BNCS 0x5E warden packet, and NOT the full BNCS packet.

[Size=6]Second Method[/size] (useage 0x02 and 0x03)
This allows you to manage you're own warden handler, and avoid the need to download and manage warden modules from battle.net.
Useage 0x02:
This is for manageing packets that only the downloaded warden module's can do.
Currently, warden sends you an 0x05 packet that's used to verify you're truely running the correct warden module.
You can send the whole decrypted 0x05 packet (including the packet ID) and get the 0x04 Responce and new set of RC4 keys.
Since the algorithm warden uses to generate the 0x04 responce data is differnt in each downloaded module, this useage requires you also send you're orginal seed and the module name.
It's possible, in the future, more module requireing packets, such as 0x05, may come into play.
Because of that, the data in the responce to useage 0x02 maybe variable.
This is the current supported format for the "data" in useage 0x02 responces;
[code]
(DWORD)    Responce Type
Type 0x01:
    (BYTE[258]) New RC4In Key
    (BYTE[258]) New RC4Out Key
    (DWORD)     Lengh Of warden Responce
    (VOID)      Warden responce packet Data
[/code]
The warden responce packet data, currently, will be the whole raw 0x04 packet.
You then encrypt the responce packet data with you're existing rc4out key, then replace you're existing RC4 key's with the new ones.
It's possible, at times, the BNLS server may respond with the result code 0x03 (warden module not loaded).
There is a short delay between bnet switching to a new warden module and the BNLS server downloading it from bnet, so try again in 10 or more seconds.
Useage 0x03:
This is allows you to download a file and/or infomation about the checks warden is making. This infomation can be used by you're warden 0x02 parser to identify the check type and it's result.
Currently, only info type 0x01 is supported. (downloading of a .ini file)
The "data" in the responce to useage 0x03, has the following format:
[code]
(DWORD)    Into type
For type 0x01:
    (DWORD[2]) File time
    (VOID) ini file data
[/code]
It may, in the future, support more info types, depending in what direction warden goes.


[Size=6]Result values and meanings[/size]
The result code, in the responce, maybe one of the following;
0x00 = Success
0x01 = Unable to find you're allocated packet handler.
- This is used in useage 0x00 and 0x01 responces.
- Useage 0x00: it normaly means the BNLS server has reached it's designated limit. In a nut shell, the server is full.
- Useage 0x01: The cookie  was not initialized with useage 0x00, Or you're cookie has timed out/removed,
0x02 = Incoming Data currupt
- This is used in useage 0x01, telling you that the incomming warden data was unreadable, after decryption.
0x03 = warden module is not loaded yet
- Bnet has switched to another module and this BNLS server does not have it yet.
- It should automaticly update (get the new module) anywhere from 10 seconds, to 10mins -- try again later.
0x04 = error executing warden module
- BNLS was unable to load and/or execute the given warden module.
- Basicly, shit hit the fan.
0x05 = Unsupported bnet client/game
- You're bnet client/game is unsupported.
- Currently supports starcraft and warcraft III BNCS warden, but may enable D2/D2LOD D2GS warden in the future.
0x06 = Warden hack check error
- The BNLS server was unable to read the warden 0x02 packet.
0x07 = Warden check invalid
- The offsets have probly changed and the BNLS server is not yet aware.
0x08 = incomming warden packet unsupported
- This is used with useage 0x02.
- Currently, only warden packet 0x05 is supported.
0x09 = unsupported warden info type
- This is used with useage 0x03.
- BNLS is not yet able to process this info type.
- Currentl supported info types are: 0x01
0xFD = Invalid password
0xFE = Invalid user name
- This is used with useage 0x00.
- Currently, that method is open for all to use. (leave user name and password as blank strings)
- In the future, if the sevrer is being abused, it maybe required of you, to use a BNLS username and password.
0xFF = You're request was currupt.
- You're BNLS 0x7D packet had bad format, or sizes.
- The "data" in the responce, may contain an offset into you're packet, where the problem is.

You guys are willing to keep an established connection? You're looking at hundreds, if not, thousands of connections and that doesn't include those that will use it to mass load. That could get very tedious.

[quote author=PunK link=topic=17910.msg182403#msg182403 date=1239980463]
You guys are willing to keep an established connection? You're looking at hundreds, if not, thousands of connections and that doesn't include those that will use it to mass load. That could get very tedious.
[/quote]

True, that's the main reason i've been nagging Hdx to add it to JBLS :p
I've currently capped my server to allow up to 10,000 clients/ip's, each with no more than 50 cookies (pretty much 3MB of allocated memory for all)
The mass loading issue, is the main reason why I included a username and password in the useage 0x00 request -- if it becomes to much work making the server detect and ban loadbots, it's pretty fool proof to request an account, and have a set (small) number of cookie spaces for them to use.
As for the other requests, theres really no problem there -- My 50kb/s upload speed alone, could deal with 80+ requests per second, before feeling any stress.
Since those requests would need to be done once per logon (like a checkrevision for example) the number of requests per second, would be pretty low.

It's only the 0x00/0x01 requests that could be a problem, if a ton of people started useing it.
Useage 0x00/0x01 method is "my 1st bnet bot" kind of stuff. :p
Since it requires you connect to BNLS every time a warden packet comes in (about once every 15 seconds), or stay connected through out you're time on bnet, I wouldnt expect alot of people to want to use it, even tho it could possibly allow a bot to always work with warden, as long as the BNLS server is up to date with any changes/new batchs of modules etc. :)

I was thinking just creating a warden library in C++ and creating restrictions to only a select few. It just seems like trying to do what your trying to do would take up a lot of bandwidth.

Well, it depends what you mean by alot -- I estimate (I suck at math btw) you could manage 8,000 to 12,000 clients all useing the 1st method, under 50kb/s upload.
Its sort of like the old subject "local hashing vs BNLS" :p
Alot of bots useing BNLS, worked for many years with out any need for an update (untill lockdown :p) and some probly still work now.
Thats sort of the idea here.
Useing the first method (useage 0x00/0x01) one can assume their bot will continue working with warden, as long as BNLS does.
Useing 0x02 you can remove the need for updating code to deal with the module, when dealing with ghay packets, like 0x05 and any other things like it that may pop up in the future.
Useing 0x03 you can manage warden localy, and get the latest checks and results, so not to be effected when offsets change, like after a patch.

Since I run a server like this for persional useage I was wundering if anyone else would be interested in useing this packet.
I don't want to end up with a crap load of people all useing it tho, thats partly why I was trying to talk Hdx into adding 0x7D to JBLS.

Would anyone be interested in useing this packet, if it was widely avalible?

If anyone wants to try this packet, you can use the BNLS IP "212.139.114.127" on port 9367
It wont be up for long tho.

Well, eliminating the updates due to the offset change is a great idea. Connecting to the BNLS to recieve the latest up-to-date offsets seems pretty nifty.

But, I've already started taking a gander at extracting the offsets directly from the hash files rather then an INI file. Which, like you where saying, is like the old school BNLS vs local hashing :)

I'd be interested in helping out if there is any help needed. I'm starting to become more familiar with C so perhaps that could be of use to you :-P

I've written a client to use your BNLS server protocol for handling the warden packets. At the moment I've only written the "stupid" version (e.g. sending you the seed + the raw warden packets) because my client is not able to handle the 0x02 packets at the moment. I will likely use the "smart" version in the future but for me it's secondary to getting a working bot at the moment.

I was able to connect to your BNLS server and relay the packets to battle.net. I wasn't kicked after the usual 2 minutes so it appears to be working. Are you planning to release your server code and/or binaries?

Thanks for all the work you guys have done on breaking Warden, I really appreciate it.

Well, if I get this warden library done within the next couple days and if you don't intend to abuse it, then I won't mind giving you access to the library.

Right now I am having a hard time since i'm fairly new to C, but I am using a helpful site (http://www.skullsecurity.org/wiki/index.php) as a reference. I am planning to have this done by the end of this weekend.

[quote author=Varlock link=topic=17910.msg182411#msg182411 date=1240008551]
I've written a client to use your BNLS server protocol for handling the warden packets. At the moment I've only written the "stupid" version (e.g. sending you the seed + the raw warden packets) because my client is not able to handle the 0x02 packets at the moment. I will likely use the "smart" version in the future but for me it's secondary to getting a working bot at the moment.

I was able to connect to your BNLS server and relay the packets to battle.net. I wasn't kicked after the usual 2 minutes so it appears to be working. Are you planning to release your server code and/or binaries?

Thanks for all the work you guys have done on breaking Warden, I really appreciate it.
[/quote]

Neat, good to know it works correctly (I haven't had much time to test the TCP handlers for this packet) :)
I think theres alot of people working on dll's at the moment, so they will be out there soon.
I figured a BNLS warden type system, maybe fairly usefull in the future.
If there is a demand for this, then I'm happy to knock up a cleaner program to release (it would be in vb6 tho) -- the one im useing atm, is pretty messy and old.
We would need to talk about source codes, since alot of code could be easy add' into a spam/load bot :( -- thats the main reason ive not released any public source, that allows you to run multiple connections though, off the bat.

There is some fairly significant demand for this because I've already added the necessary client code to GHost++. I have very little motivation to continue porting the VB modWarden.bas code to C/C++ and unfortunately I don't know VB well enough and I also don't know Windows programming well enough to interface with your modWarden code from C/C++.

I'm sure someone will create an easy to use Warden library at some point, but it would be very nice to have a workaround for GHost++ in the meantime. It's not really necessary to have the source code, just a binary since it's likely there would be several thousand users wanting to use the BNLS server and many of them would want to run their own server.

Thanks again.

[quote author=Varlock link=topic=17910.msg182431#msg182431 date=1240076240]
There is some fairly significant demand for this because I've already added the necessary client code to GHost++. I have very little motivation to continue porting the VB modWarden.bas code to C/C++ and unfortunately I don't know VB well enough and I also don't know Windows programming well enough to interface with your modWarden code from C/C++.

I'm sure someone will create an easy to use Warden library at some point, but it would be very nice to have a workaround for GHost++ in the meantime. It's not really necessary to have the source code, just a binary since it's likely there would be several thousand users wanting to use the BNLS server and many of them would want to run their own server.

Thanks again.
[/quote]

BNLSWarden.zip
It maybe a little buggy, i've not had chance to fully test this build.
It also lacks alot of options.
The BNLS.ini and Updater.ini should be self explaining.
The WardenUpdater.exe is the program the server executes, to get new modules.
This can be any program, as long as it connects to battle.net, downloads the module, decrypts and decompress' it and saves it to the \warden folder.
The updater program logs on with broodwar -- but the modules the same on all BNCS clients atm, so that wont be a problem for now.
The server will run the WardenUpdater as soon as a new module name is seen -- it has a 5min cap between running the updater.
You need to put the game binary files, in the \Binarys folder. There is a file.txt in each game folder, listing the needed files.

When blizzard patchs a warden supporting game, I advise deleteding the releated warden.ini -- blizzard has been known to check the same address's after patching, altho im sure by mistake.
Those values are used to identify a given check and its legit responce value. It ensures the chances of missidentifying a check and sending back invalid data are very slim.
It also will brake the parser at the sign of any changes to the warden protocol so they can be looked into, to make sure blizzard are not being sneeky, or if the whole protocol has changed etc.

I've also capped a few things, to make it a less effecticve abuse tool for load bots.

If you have any problems, just PM me, and i will try find time to fix them.

Why have a separate BNLS username/password for this? Use the BNLS_AUTHORIZE and BNLS_AUTHORIZEPROOF support for that stuff... besides then you're not sending a decrypted password...

[quote author=Ribose link=topic=17910.msg182464#msg182464 date=1240253122]
Why have a separate BNLS username/password for this? Use the BNLS_AUTHORIZE and BNLS_AUTHORIZEPROOF support for that stuff... besides then you're not sending a decrypted password...
[/quote]
True, but persionaly, I would rather at least have that 2nd option open.
The password can be sent as anything, plan text, a binary hash, etc, since it's lengh is undefined. I mainly added, for the reasons I couldn't think of :P
The other half of it being there, allows extentions to be added on in the future.
For example, if in the future, the first dword of the cdkey hash is no longer used, and another value(s) are used, they can be pass'ed to the server in the password buffer.
imo, having it there, opens up alot of possible options for future extentions. :p

[s]1) is packet format the same in BNLS as BNCS? (0xFF, 0x7D, size[0], size[1], data[])
   [sub]i don't remember for sure, but is the header 0xFF or 0x00 or something different?[/sub][/s]

[s]2) could you outline how the packet will be on the reply?[/s]

[s]3) Usage is obviously a subpacket header, what is cookie? is that your way of saying "the rest of the packet data" which is labeled below it, or is it a a session ID sort of thing?[/s]

[s]4) What is Client?[/s]

[s]5) what is the seed? is it random? is that where i use the first dword of cdkey hash?[/s]

[s]6) username is blank? what is the point of the password? should it be the account i'm using on bnet's password or something else?[/s]

sorry i was having trouble scrying this information from your first post. i added you on MSN. also, i included your outbound packet outline so you don't have to flip back up at your first post.

edit:: oh the wonders of reading...  ::)

[code]    (BYTE)     Useage
   (DWORD)    Cookie
   Useage 0x00 (Warden Seed)
       (DWORD)    Client
       (WORD)     Lengh of Seed
       (VOID)     Seed
       (STRING)   Username (blank)
       (WORD)     Lengh of password
       (VOID)     Password
   Useage 0x01 (warden packet)
       (WORD)     Lengh Of Warden Packet
       (VOID)     Warden Packet Data
   Useage 0x02 (warden 0x05)
       (DWORD)    Client
       (WORD)     Lengh Of Seed
       (VOID)     Seed
       (DWORD)    Unused
       (BYTE[16]) Module MD5 Name
       (WORD)     Lengh of Warden 0x05 packet
       (VOID)     Warden 0x05 packet
   Useage 0x03 (warden checks/ini file)
       (DWORD)    Client
       (DWORD)    Info Type (0x01)
       (WORD)     Unused (must be 0x00)
       (VOID)     Unused[/code]