BnFTP v1 for WAR3 results in BNCS "silent violation"?

[tA-Kane]

I've been thinking a bit more about the problem that I've had for the past two years or so; and that's that at seemingly random times when my bot is connecting with WarCraft 3, it gets itself into a login-then-disconnected state, where it's able to login to the server just to be immediately disconnected by the server... I call that a "silent violation" since you don't really know what you violated.

I recently disabled my icons support for a different reason, but it seems that I'm not getting this problem anymore.

So I've looked into this a little more, and it seems that I was neglecting to use the BnFTP version 2 when downloading the icons file that Battle.net told my bot to download; so I would end up sending the BnFTP header using WAR3 as the game, get disconnected by the server, and then revert back the the file in my cache which was downloaded by my bot when connecting on a different product (usually STAR or W2BN).

So, it seems that that is the problem. But I wonder; is it really? I've yet to look into the BnFTP v2 stuff (I hear it has some stuff from 0x51, though)... but if what I'm saying is indeed true, where's some information on BnFTP v2? I did a brief search and found this mostly unhelpful topic: http://forum.valhallalegends.com/phpbbs/index.php?topic=6354.0

Unfrotunately, I do not have a packetlog of a valid BnFTP v2 connection (and am not currently in a position to obtain one), otherwise I would try to guesstimate what everything is myself.

[MyndFyre]

BnFTP v2 is a negotiated connection, where you have to semi-log-on before you can download.  It requires that you provide a CD key decode IIRC.

I wish I could find the URL to help you out -- UserLoser. was the only one whose site I've seen with information on it, and it looks like he's removed his Battle.net documents page (or at least moved it elsewhere on his server).

I honestly can't imagine that your use of BnFtp v1 would disconnect a Warcraft 3 connection on a different outgoing port.  Does it disconnect every connection when you do so?  I can't see how the BNCS server could know with certainty that your sessions were connected, and it can't just go by IP address because you'd have proxies and LANs to deal with.

[tA-Kane]

I honestly can't imagine that your use of BnFtp v1 would disconnect a Warcraft 3 connection on a different outgoing port. Does it disconnect every connection when you do so?

It seemed that only WAR3 would trigger the silent violation, but once it had been triggered, all *new* (that is, new meaning not-yet-logged-in) connections would be disconnected immediately after sending 0x0A.

I can't see how the BNCS server could know with certainty that your sessions were connected, and it can't just go by IP address because you'd have proxies and LANs to deal with.

Indeed. That's one of the reasons I'm asking about this; it seems kinda far-fetched IMO, yet it's certainly possible. Could one misbehaving bot screw over an entire LAN from connecting? Absolutely; look at IP bans. Once the silent violation had been triggered, changing CD keys would not affect it, and nor would changing products. I'd have to just sit it out.

But the thing is, once it had been triggered, normal (Blizzard) clients could still log in. So maybe it can be "untriggered" somehow? I'm just so confused.

[UserLoser.]

BnFTP v2 is a negotiated connection, where you have to semi-log-on before you can download.  It requires that you provide a CD key decode IIRC.

I wish I could find the URL to help you out -- UserLoser. was the only one whose site I've seen with information on it, and it looks like he's removed his Battle.net documents page (or at least moved it elsewhere on his server).

I honestly can't imagine that your use of BnFtp v1 would disconnect a Warcraft 3 connection on a different outgoing port.  Does it disconnect every connection when you do so?  I can't see how the BNCS server could know with certainty that your sessions were connected, and it can't just go by IP address because you'd have proxies and LANs to deal with.

Lost everything on my system/server, so pages were lost too.  But, IIRC, the system wasn't really difficult to figure out and you could probably figure it out your self by trial/error & guess/check.  It could be figured out just from packet logs (never did any disassembly). Only 'tough' part about it is, it required a war3 cdkey

[EpicOfTimeWasted]

Version 2 isn't overly hard.  Just have to have to be able to create a standards compliant SHA1 hash (not Blizzard's modified SHA1), as well as decode a warcraft 3 cdkey.  My code is super ugly at the moment, so I'll just provide my notes instead.

Code Select Expand

struct fileRequestOne {
unsigned short packetLength;
unsigned short protocolVersion; // Appears to always be 0x0200
unsigned int systemArch; // 68XI
unsigned int gameType; // 3WAR
unsigned int adID; // Valid for previous games, zero for Warcraft 3
unsigned int fileExt; // Valid for previous games, zero for Warcraft 3
}

struct fileRequestTwo {
unsigned int zero; // Appears to always be zero
FILETIME fileTime; // Last write time for file
unsigned int randomHashValue; // Random value for hashing
unsigned int cdkeyLength; // Length of cdkey
unsigned int keyProduct; // Product portion of decoded cdkey
unsigned int keySerial; // Serial portion of decoded cdkey
unsigned int zeroTwo; // Appears to always be zero
unsigned int hashBuffer[5]; // SHA1 hash of randomHashValue, serverRandomValue, decoded key parts (int product, int serrial, char random[10])
char *fileName; // File name
}

struct fileRequestResponse {
unsigned short packetLength;
unsigned short requestType; // Maybe a request type?  Appears to always be 0x0000
unsigned int fileSize; // Size of the file
unsigned int adID; // Valid for previous games, zero for Warcraft 3
unsigned int fileExt; // Valid for previous games, zero for Warcraft 3
FILETIME fileTime; // Last write time for file
char *fileName; // File name
}

C -> S: \x02
C -> S: struct fileRequestOne
S -> C: int serverRandomValue
C -> S: struct fileRequestTwo
S -> C: struct fileRequestResponse
S -> C: file contents until complete