Valhalla Legends Archive

My advice: stop being lazy.

Quote from: iago on April 05, 2004, 04:27 AM
My advice: stop being lazy.

I Agree, just using a packet logger and http://bnetdocs.valhallalegends.com you can get all this to work, and the information is very xplained on there. (i think)

Ok cool, thanks for all the help  

Ok a question about Ehtereal, can I assume everything Im following in the TCP Stream is a single byte, because Im basically trying to figure why there are long strings of .....'s. I've basically been pasting the strings I've gotten from saving it as a text file into my sends, and it unlke before, its not automatically kicking me off, however I'm not getting any data like I should be.

Quote from: Rasico on April 05, 2004, 10:10 AM
Ok a question about Ehtereal, can I assume everything Im following in the TCP Stream is a single byte, because Im basically trying to figure why there are long strings of .....'s. I've basically been pasting the strings I've gotten from saving it as a text file into my sends, and it unlke before, its not automatically kicking me off, however I'm not getting any data like I should be.

I believe you should be looking at the hex dump and taking the bytes from there. All the ....'s are just various characters that the ethereal authors deemed unprintable.

Ok, but does this mean I need to calculate the ASCII code for all the hexadecimal pairs, because I'm lazy and that would take a long time  . I could write a function to do it, I know, but it would be much easier if there was some way for me to look at the bytes sent out and be able to compare them to the bnet docs, thats basically my goal at the moment, matching outgoing packes with the format specified (Starcraft in this case, but I intend to apply it to other clients as well.)

Quote from: Rasico on April 05, 2004, 02:21 PM
Ok, but does this mean I need to calculate the ASCII code for all the hexadecimal pairs, because I'm lazy and that would take a long time  . I could write a function to do it, I know, but it would be much easier if there was some way for me to look at the bytes sent out and be able to compare them to the bnet docs, thats basically my goal at the moment, matching outgoing packes with the format specified (Starcraft in this case, but I intend to apply it to other clients as well.)

Unless you're using the chat protocol, I think you'll find that most of the bytes that are tricky to get right are much easier to compare in hexadecimal form than as ascii characters. They are also rarely specified as ascii characters. Of course, in the actual chat/channel/text data there's lots of characters, but when you get to that point, you don't really need to count/compare characters.

What I meant was when I want to send these packets (I'm using VB with Winsock here), I need to take the value each hexadecimal pair provides and send it as a character(example FF = 255,  so I would send chr(255)), or is there perhaps a different way of going about this?

Quote from: Rasico on April 05, 2004, 02:49 PM
What I meant was when I want to send these packets (I'm using VB with Winsock here), I need to take the value each hexadecimal pair provides and send it as a character(example FF = 255,  so I would send chr(255)), or is there perhaps a different way of going about this?

In VB, the way of using a hex value is:

&Hvalue-in-hexadecimal

Which might be:

&H50, which is the value of 80 in decimal.
&H0F, which is the value of 15 in decimal.

etc.

You will see this written typically as 0x50 or 0x0f, which is the syntax for writing hex numbers in C-based languages (including Java).

You will also have to do manipulations on the values. You can't just send a fixed string of bytes - they have to be appropriate responses for the bytes that b.net is sending you.

Quote from: Adron on April 05, 2004, 04:06 PM
You will also have to do manipulations on the values. You can't just send a fixed string of bytes - they have to be appropriate responses for the bytes that b.net is sending you.

I'm fully aware  , but one thing at a time, thanks for all the help thus far everyone  .

QuoteYou will see this written typically as 0x50 or 0x0f, which is the syntax for writing hex numbers in C-based languages (including Java).

0x50 or 0x0f is the standard to printing/writing hex.  It is prefixed by either 0x or 0X.

This is similiar to the standard of printing a '0' (zero) as a prefix to any octal number.

When I look at the log on sequence for SC on b.net, I see a protocol byte is the first thing that needs to be sent, however bNet takse me to a protocol headers page, which then gives me the BNCS packet header format. This raises two questions: One, how do you format the protocol Byte, using what information to format it. Second, does the Packet header need be included with every other thing you send?

For instance with the SID_AUTH_INFO packet, should one send the header along with that packet?

Quote from: Rasico on April 05, 2004, 04:38 PM
For instance with the SID_AUTH_INFO packet, should one send the header along with that packet?

You just send Chr(1) to tell the server that you want to connect using a client. Similarly to how you would send Chr(3) to connect using the CHAT protocol, or Chr(2) (I think) for ftp.

Yes, you would need to include the packet header:
Chr(255) or Chr(&HFF) - FF
Chr("&H" & PacketID)  - 0x51 for example
Then the length of the packet which you use CopyMemory to get.

Those 4 bytes would be the packet header which you send along with every packet.

Yay I managed to IPBan myself, I take it that if you don't send the appropitate data after the protocol byte, bad thigns happen