(UINT8) Command
(UINT32) Cookie

Command 0x00 (Warden Seed):
(UINT32) Client
(UINT16) Length of Seed
(VOID) Seed
(STRING) Username (blank)
(UINT16) Length of password
(VOID) Password

Command 0x01 (warden packet):
(UINT16) Length Of Warden Packet
(VOID) Warden Packet Data

Command 0x02 (warden 0x05):
(UINT32) Client
(UINT16) Length Of Seed
(VOID) Seed
(UINT32) Unused
(UINT8) [16] Module MD5 Name
(UINT16) Length of Warden 0x05 packet
(VOID) Warden 0x05 packet

Command 0x03 (warden checks/ini file):
(UINT32) Client
(UINT32) Info Type (0x01)
(UINT16) Unused (must be 0x00)
(VOID) Unused

This packet can currently support 2 methods for SC/BW/W3ROC/W3TFT.

The first method (commands 0x00 and 0x01) allows you to support warden over battle.net with out any need for installing warden related code and algorithm. It does however, require you to stay connected to the server, or at least, connect each time a new request comes in from Battle.net.

The second method (commands 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, without having to worry about downloading, loading and executing warden modules, from Battle.net.

A basic description of the packet values above:
The command tells the BNLS server how to parse your request.

0x00 is for initializeing a new Battle.net connection, to allocate a packet handler for you, on the server.

0x01 is for having your warden requests handled, via the preallocated packet handler, done in command 0x00.

0x02 is for getting the correct data in response to warden 0x05 and a new set of RC4 keys, as well as any other future module requiring packets.

0x03 is for getting a list of offsets and their contents, to be used in your warden 0x02 handler.

The cookie is sent back to the client, to identify one request from another. With command 0x01, the cookie must remain the same as the one you initialized for a given Battle.net connection, with command 0x00.

It is important to use different cookies for differnt bots when dealing with commands 0x00 and 0x01, so you do not have a RC4 encryption key corrupted and therefor having to reconnect to Battle.net. For more info on commands 0x00 and 0x01 cookies, see the "First Method" description below.

The client value identifies what client you connected to Battle.net with. It can be the UINT32 you use over Battle.net (such as PXES) or one of the BNLS Product Codes.

The seed value is used to initialize wardens cryptography. This value should be the 1st UINT32 of the first CDKey hash in C>S 0x51 SID_AUTH_CHECK. For now, only a 4 byte seed is acceptable. If you are using the older logon protocol (packets 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 username blank and the length of password to zero.

For the result value in the response, see the "Result values and meanings" description below.

First Method (commands 0x00 and 0x01)
This connection style allows you to support warden over Battle.net without any need for installing warden related code and algorithms into your program. It does however, require you stay connected to the server, or at least, connect each time a new request comes in from Battle.net. This is basically a fully managed remote warden handler. The Cookie value is used to allocate (command 0x00) and access (command 0x01) a warden connection/handler. Once you initialize a cookie (command 0x00), it can then be sent back to BNLS with a Battle.net warden packet (command 0x01) to have the request handled, and a response sent back to you to be sent on to Battle.net. You can manage multiple Battle.net connections/wardens via one or more BNLS sockets.

Command 0x00:
When logging onto Battle.net and building your C>S 0x51 SID_AUTH_CHECK packet, you need to obtain the first UINT32 of the first cdkey hash which will be the seed value used in command 0x00. You then send this seed value to BNLS, via command 0x00, to activate, or reset the given cookie. This cookie value must be different from any other bots using the same BNLS server from your network, that way you do not have clashes. The BNLS server will respond telling you if the cookie was successfully initialized or not. The data in the response should only ever be present if the response contains an error code.

Command 0x01:
Once you have successfully initialized a cookie for a Battle.net connection, you are ready to forward all Battle.net 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 successful, then the "Warden Packet Data" will contain the BNCS 0x5E SID_WARDEN payload to be sent to Battle.net. You should only send the response data to Battle.net if the request was successful, the length of the data is one or more and it is a 0x01 command response. Please note that after initializing a cookie with command 0x00, that space will remain allocated on the server, for up to three minutes. This allows you to reconnect, and still be able to resume where you left off, without having to reconnect to Battle.net. You should only send the PAYLOAD of the S>C BNCS 0x5E SID_WARDEM packet, and NOT the full BNCS packet.

Second Method (commands 0x02 and 0x03)
This allows you to manage your own warden handler, and avoid the need to download and manage warden modules from Battle.net.

Command 0x02:
This is for managing packets that only the downloaded warden modules can do. Warden sends you an 0x05 packet that iss used to verify that you are truly running the correct warden module. You can send the whole decrypted 0x05 packet (including the packet ID) and get the 0x04 response and new set of RC4 keys. Since the algorithm warden uses to generate the 0x04 response data is differnt in each downloaded module, this usage requires you also send your orginal seed and the module name. It is possible, in the future, that more modules requiring packets, such as 0x05, may come into play. Because of that, the data in the response to command 0x02 maybe vary. This is the current supported format for the "data" in command 0x02 responses:

(UINT32) Response Type

Type 0x01:

(UINT8) [258] New RC4 In Key

(UINT8) [258] New RC4 Out Key

(UINT32) Length Of warden Response

(VOID) Warden responce packet Data

The warden response packet data will be the whole raw 0x04 packet. You then encrypt the response packet data with your existing RC4 Out key, then replace your existing RC4 keys with the new ones. It is possible that the BNLS server may respond with the result code 0x03 (warden module not loaded). There is a short delay between Battle.net switching to a new warden module and the BNLS server downloading it from Battle.net, so try again in 10 or more seconds.

Command 0x03:
This allows you to download a file and/or information about the checks warden is making. This infomation can be used by your warden 0x02 parser to identify the check type and its result. Currently the only info type 0x01 is supported (downloading of a .ini file). The "data" in the response to command 0x03 has the following format:

(UINT32) Into type

For type 0x01:

(UINT32) [2] File time

(VOID) ini File data

It may in the future support more info types, depending in what direction warden goes.