OK. I know about chr(3) and chr(4) for chat bots but answer me two questions:
What IS chr(3) and chr(4) ? What do they represent?
Also, I'm pretty sure theres a special way of sending it or is it just like this:
sckBnet.SendData chr(3) chr(4)
[/color]
once again, help would be appreciated, and plz dont post unless your going to help
Make a simple output program, and view the output of chr(3) and chr(4).
Use the string concatenation operator (&):
sckBnet.SendData Chr(3) & Chr(4)
The first byte is the Protocol byte. It lets bnet know you're going to be using the chat protocol. If you were using a game, you'd send 0x01 instead.
I forget what the second byte does.
^D turns off foreign echo.
so chr(4) turns off echo? ya lost me =/
Anytime you send something, it will echo it back to you. SO if you send "blah" it will send you "blah"
So you send ^D to turn that off ;)
sckBnet.senddata ^D
ok got it 8)
no.
sckBnet.SendData Chr(3) & Chr(4)
^D is shorthand notation for Ctrl-D, which is expressed by the byte Chr(4).
thx yoni now i understand perfectly
I thought I'd just add that chr(3) is ^C.
but..etheran...
QuoteThe first byte is the Protocol byte. It lets bnet know you're going to be using the chat protocol. If you were using a game, you'd send 0x01 instead.
I forget what the second byte does.
i thought chr(3) was 0x03..thats what arta made it sound like
chr(3) is 0x03. the post you quoted doesn't say otherwise
Quotebut..etheran...
i thought chr(3) was 0x03..thats what arta made it sound like
chr(3) translates as ascii 3(00000011), which (the last time I checked) is ctrl-C.
winsock1.senddata chr(3) & chr(4) & vbcrlf & username & vbcrlf & password
I THINK!! ::)
no vbcrlf after chr(4)
heh k but except for the & vbcrlf after chr(4), thats how u make a chat bot after u connect..i think! ::)
hehe
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.
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...
Quoteno 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
Quotetelnet 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".
i'm not wrong, i just dumbed it up
Quotei'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...
QuoteAny 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? :)
Quotei'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.