Sending chr(3) and chr(4)

[haZe]

winsock1.senddata chr(3) & chr(4) & vbcrlf & username & vbcrlf & password
I THINK!!

[Mesiah / haiseM]

no vbcrlf after chr(4)

[haZe]

heh k but except for the & vbcrlf after chr(4), thats how u make a chat bot after u connect..i think!
hehe

[Etheran]

It's not needed, although I think b.net allows you to do it.  Try opening telnet and connecting to [your favorite b.net server].  Press ctrl-C ctrl-D [Username] + Enter(CRLF) + [Password] + Enter(CRLF).  You'll see exactly what needs to be sent in order to establish a connection using the chat protocol.

[Mesiah / haiseM]

no because in telnet, if you hit enter after you hit ctrl+d then it would assume that the crlf is the username, and skip onto the password, because youve just hit enter.

i dont even think it allows you to send ctrl+d...

[Camel]

no because in telnet, if you hit enter after you hit ctrl+d then it would assume that the crlf is the username, and skip onto the password, because youve just hit enter.

i dont even think it allows you to send ctrl+d...

telnet sends data on a timer. if you send ^C and then wait five minutes before you type ^D, bnet is going to think  ^D is part of the username. but if you type it fast enough (it's really not very fast at all), it'll send them in the same packet

[Skywing]

telnet sends data on a timer. if you send ^C and then wait five minutes before you type ^D, bnet is going to think  ^D is part of the username. but if you type it fast enough (it's really not very fast at all), it'll send them in the same packet

Uhm.. that's completely wrong.  For starters, telnet does not send data on a timer.  The Nagle algorithm, a feature of TCP/IP facilitates delaying a PSH until either a certain amount of data is backlogged locally or an ACK is received from the remote host.  This allows the TCP stack to concatenate small sends into a single, more efficient TCP packet.

TCP/IP applications must not make any assumptions about how data is delivered to them.  The application has no reliable way of knowing whether or not the data arrived in a single TCP packet; this is by design.  Thus, Battle.net won't "think it's part of the username" just because it received it "later".

[Camel]

i'm not wrong, i just dumbed it up

[Skywing]

i'm not wrong, i just dumbed it up

You are wrong.  The amount of time delay between you sending things on a TCP connection does not change how the remote application processes them.  Any program which tries to make such assumptions will only work intermittantly at best.

The only time where it could possibly make a difference is if the remote application decides to drop the connection as dead if it gets no data for so long.  This is not the case with Chat connections to Battle.net...

[Camel]

Any program which tries to make such assumptions will only work intermittantly at best.

i'm not arguing with you on that. any hacker who makes assumptions about the skill of the internal programmers will succeed intermittantly at best. i havn't opened a chat connection in a hell of a long time, but when i used it a long time ago it would allow about a second to send ^D before it replied with "Username: ". if you waited too long, the ^D would be part of your username (and obviously not work). if you didnt wait for the "Username: " before sending the username (not send ^D complicated this 1000-fold because bnet would never echo your password unless you send it before it sends you "Password: "), it would usually skrew up the connection.
but perhaps it has all changed and they are parsing the data correctly now. i dont really think it matters enough to open up telnet and try it. shall we call a truce?

[Skywing]

i'm not arguing with you on that. any hacker who makes assumptions about the skill of the internal programmers will succeed intermittantly at best. i havn't opened a chat connection in a hell of a long time, but when i used it a long time ago it would allow about a second to send ^D before it replied with "Username: ". if you waited too long, the ^D would be part of your username (and obviously not work). if you didnt wait for the "Username: " before sending the username (not send ^D complicated this 1000-fold because bnet would never echo your password unless you send it before it sends you "Password: "), it would usually skrew up the connection.
but perhaps it has all changed and they are parsing the data correctly now. i dont really think it matters enough to open up telnet and try it. shall we call a truce?

I've never observed that behavior.  By the way, Battle.net treats a ^D as a newline.

There is one quirk in their handling of ^D; they appear to only check for it once per TCP packet, which means if you keep disabling and reenabling it, you might get unexpected results.