SID_LOGONRESPONSE2 ignored?

[shadypalm88]

Has anyone ever had Battle.Net ignore a LOGONRESPONSE(2) packet?  I sent it, Battle.net gave an ACK and did not close the connection, but didn't send anything back.  This is an account I created to test account creation on my bot connected as Brood War.  And no, Battle.Net does not ask for e-mail registration.  Any ideas?

[tA-Kane]

Battle.net gave an ACK ... but didn't send anything back.

You lost me there. Battle.net did or did not send anything back? If it didn't send anything back, then perhaps you should define ACK for me?

[shadypalm88]

That's what shows up in Ethereal (packet logger).  ACK is a TCP flag that Battle.net sent back saying that it recieved the LOGONRESPONSE2 packet.  So it goes through, I don't get IP-banned, but I don't log on either.

[tA-Kane]

Do you have a packetlog? What client were you trying to emulate?

[Eric]

If you enter an invalid password too many times, Battle.net will temporarily lock you out of the account without warning.

[Falcon[anti-yL]]

Its 5 times.

[hismajesty]

Yea, which client? Not all clients require e-mail accounts which could be why it didn't request one?

[shadypalm88]

Nah, I'm thinking it's a lockout.  My bot probably is creating accounts with incorrect passwords.  Thanks.

[Falcon[anti-yL]]

You get locked out when you use the wrong password for an account 5 times.

[MyndFyre]

Nope, I send SID_LOGONRESPONSE2 for SC/BW/W2/D2/LoD and I connect fine.

[Skywing]

If you enter an invalid password too many times, Battle.net will temporarily lock you out of the account without warning.

IIRC, the lockout scheme is something like: start at a 20 second delay, and after each further failure double the delay time.  At some point, Blizzard may have implemented sharing of lockout delays between all servers in a server cluster.

[shadypalm88]

I'm just going to ressurect this briefly to add a note.  I recently added "hashed" connections to my bot, with a slightly modified version of BnetAuth.dll.  When it got to sending SID_LOGONRESPONSE2, this same thing was happenning, Battle.Net received the packet but apparently ignored it.  When I logged on this account with the Brood War game, not more than 30 seconds later, the account was not locked, and Battle.Net did not report any failed login attempts.  There was apparently a problem with the hashing routine because when I rewrote PasswordHash (A on some .dll's) in VB, it connected fine.  So I guess Battle.Net will ignore your login packet if your hashing routine is horribly broken, even if your account is not locked.

[UserLoser.]

I'm just going to ressurect this briefly to add a note.  I recently added "hashed" connections to my bot, with a slightly modified version of BnetAuth.dll.  When it got to sending SID_LOGONRESPONSE2, this same thing was happenning, Battle.Net received the packet but apparently ignored it.  When I logged on this account with the Brood War game, not more than 30 seconds later, the account was not locked, and Battle.Net did not report any failed login attempts.  There was apparently a problem with the hashing routine because when I rewrote PasswordHash (A on some .dll's) in VB, it connected fine.  So I guess Battle.Net will ignore your login packet if your hashing routine is horribly broken, even if your account is not locked.

So before you were logging in without hashing any data?  That's kind of hard.  If your hash function is broken, it shouldn't matter because you'd get an invalid password response from Battle.net as long as it's still producing a 5 DWORD result.  Otherwise, most likely you would get banned for a bad 0x3A packet size.

[Adron]

Otherwise, most likely you would get banned for a bad 0x3A packet size.

Unless you're sending the correct packet length, but your actual data is too short. Then it would seem to you that b.net is ignoring your packet.

[shadypalm88]

Otherwise, most likely you would get banned for a bad 0x3A packet size.

Unless you're sending the correct packet length, but your actual data is too short. Then it would seem to you that b.net is ignoring your packet.

Only I don't believe that it was just that Battle.Net was waiting for more data.  It was a valid packet where the actual length matched the length in the header.

You see, I tested this on an account that didn't exist yet.  The first time the bot tried to log on, Battle.Net came back and said the account didn't exist.  My bot created it.  Then, when it went to actually log it on, using the same password hashing routine as it did when it tried to log on the first time, Battle.net "ignored" the packet.