Ok I have a question about sending the packet 0x50.
The Format is:

(DWORD)             Protocol ID (0)
(DWORD)             Platform ID
(STRING)       Program ID
(DWORD)             Version
(DWORD)             Product language
(DWORD)             Local IP for NAT compatibility*
(DWORD)             Time zone bias*
(DWORD)             Locale ID*
(DWORD)             Language ID*
(STRING)       Country abreviation
(STRING)       Country

Ok, my question is how should I send all the data?? Jus send the PlatformID as IX86, the ProgramID as STAR, the version as 1.09, etc etc. Or should I convert all the values to hex before I send them, because they are all supposed to be Dwords. Oh ya, all the ones w/ stars by them I am sending as (0).

Also, what is Country Abbreviation and Country?

Thanks and reply quick please.

How do you convert a DWORD to hex? Hex is just a representation of the data.

All the things you send are in hex.  

DWORDS and other formats are just a way to break the hex up into parts so that it can be easily assembled to create the packet.  

Does that make sense?

If you get a packet logger and log some TCP packets, it will be much clearer.  

Check your packet logs to see what country abreviation and country are.  ;)



(btw, I don't believe that by asking to reply quickly, there will be an incentive for someone to post a reply quicker.)  ;)

Ok, I see what you mean but I was jus wondering b/c when I was lookin at the PacketBuffer code after you call InsertDWORD, it calls MakeDWORD which calls ToHex.

So does the code take a string turn it into hex then send it?? I am asking b/c I need to know how to send the data to the InsertDWORD function.

[quote](btw, I don't believe that by asking to reply quickly, there will be an incentive for someone to post a reply quicker.)  ;)[/quote]

I know, it was jus a shot in the dark ;-)

ok, i got the Country Abbreviation (USA) and Country (United States)

But my packet editor did not show me the Version or Product Language.

Also I noticed when it sent my platform and product ids it sent them as 68XIRATS, whent it should be IX86STAR why is it sending them backwards??

it sends them backwards because they're not strings, they're DWORDs. They look like strings, but in actual fact, they aren't. You can find the current version byte for whichever game you're using from this page on BnetDocs:

http://www.valhallalegends.com/arta/bnetdocs/page.php?id=5

ok, thanks. I finally get it now(after going over the code a hundred times)

But I am still confused a little. My platformID is IX86, but thats not a DWORD is it??

Also what should I send for ProductLanguage and why did you call it a version byte, should it be a dword??

No IX86 is not a DWORD, that is a string, You could make that a DWORD by putting it into hex

I know that "IX86" is a string, but the packet info on BnetDocs, says that it is supposed to be sent as a DWORD.

[quote]I know that "IX86" is a string, but the packet info on BnetDocs, says that it is supposed to be sent as a DWORD.[/quote]
Actually, the clients treat it as a DWORD internally.  Blizzard games are compiled with Visual C++, which has an extension that allows you to expand the 'c' character notation to 32 bits.  The Blizzard programmers did things like this:

[code]req.platformId = 'IX86';
req.productId = 'SEXP';[/code]

so I should send it as a string??

You can just use it as like this instead of using a DWORD(Example for Starcraft):

*insert a NonNTString like "68XIRATS"

oh ok thanks, last thing what do I send for the ProductLanguage??

shouldnt it be "68XIRATS"

       .InsertDWORD &H0
       .InsertNonNTString "68XIRATS"
       .InsertDWORD &HC5
       .InsertDWORD &H0    ' This can be left as 0
       .InsertDWORD &H0    ' This can be left as 0
       .InsertDWORD &H480  ' This can be left as 0
       .InsertDWORD &H1033 ' This can be left as 0
       .InsertDWORD &H1033 ' This can be left as 0
       .InsertNTString "USA"
       .InsertNTString "United States"
       .SendPacket &H50

Try that, if you need a packet buffer, go on AIM and ill send it to you

thanks SOO much

Lol whats with all this hex buisiness? You dont have to make a dword by converting it to hex... use copymemory, and packets arent sent in hex, theyre sent as pure strings, packet loggers read them in hex...

ok yall keep confusing me, this is the code I have to send the 0x50 packet:
[code]
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertNonNTString "68XIRATS"
   PacketBuf.InsertDWORD &HC5
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertNTString "USA"
   PacketBuf.InsertNTString "United States"
   PacketBuf.SendPacket &H50
[/code]
Is this right??

[quote]ok yall keep confusing me, this is the code I have to send the 0x50 packet:
[code]
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertNonNTString "68XIRATS"
   PacketBuf.InsertDWORD &HC5
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertDWORD 0
   PacketBuf.InsertNTString "USA"
   PacketBuf.InsertNTString "United States"
   PacketBuf.SendPacket &H50
[/code]
Is this right??[/quote]

Well you got lucky in this case since 0 and 0x0 are have the same value, however. In the future, put a &H before a number that you intend on being hex.

so all my 0's should be &H0's ??

;D ;D ;D ;D
I just had a epiphany, like the ending scene of the Matix, I finally see how it all goes.

The client looks at the packets as hex but sends them as strings.

Ya ya ya I know people keep tellin me this, but I never understood it until I was goin over the code for the PacketBuffer and when it added a word or dword to the buffer, it converted it to a string first. It was only like the 100th time I looked over the code I realized this.

Ya I know its stupid but I finally get it and can stop asking so many questions, so dont flame me.

I can finally sleep good at night.

Been away for a week, just got back, and have noticed you learning.

Such confusion...

But at least you're trying, gotcha_ass, unlike some other people who've visited here before... I thank and congratulate you on that.


Just wanted to inform you that when you say "the client looks at the packets as hex", hex would be an incorrect term, and "sends them as strings", you are incorrect.


The client both reads and writes PlatformID and ProductID as DWORDs. A DWORD is a 4-byte (32-bit) integer.

*refrains from a 3-page long essay on how computers work, regarding why the DWORDs IX86 (and STAR) are displayed as 68XI (and RATS) (and the hex values thereof)*


By the way, at the very least, you should make a CHAT-protocol bot before indulging yourself, and getting in over your head, with the new-user's complexities of battle.net's binary protocol.

but that wouldnt really help him understand how binary packets are used, seeing as its all sent in plain strings.

I think hes just confused on using hex characters in packets, and so on, cause vb makes it so easy to do.

Heres the deal behind that, you prolly see source code with &h25 or whatever. In vb, that just converts a normal string character into hex (basically.) So when people packet logged and parsed things, they didnt bother converting things into integers, they just used hex characters, cause it makes no difference in parsing.

so when i receive data, that I have to send again (like ping) I can jus seperate the parts of the packets and send them?

kane, I realize that the dwords are really integers but the data that the integer represents is sent as a string(am I correct) then why the crap do I even bother worrying about the hex?? To me, it sounds like the hex is a middle man that should be cut out of the code process. If the actuall data is an integer why bother having to convert it to hex and back?

(hmm for a second there I almost convinced myself I know what Im talking about)

here is an example used from spht's 0x0f education:

[code]Figure 2.3 - 0x00000003
RECV-> 0000   FF 0F 2B 00 03 00 00 00 00 00 00 00 AC 00 00 00    ..+.............
RECV-> 0010   00 00 00 00 0D F0 AD BA 0D F0 AD BA 5B 24 69 43    ............[$iC
RECV-> 0020   6B 5D 55 6E 69 54 2D 30 31 00 00                                                                                         k]UniT-01..

Flags: 0x00000000, ping: 172, account: [$iCk]UniT-01.[/code]

as you can see, the dword (which consists of 4 bytes) which contains AC 00 00 00, is in hex. But if you convert hex into decimal, it is 172. This is not the case in an actual battle.net packet, you do not need to convert it, as the data does not come in as hex.

You do not ever need to worry about hex. Some people in vb just like to use dwords in hex, because its simple. all data is sent as a string, so just take your data, create your dwords, or strings, or integers, and send them as is, no hex is needed.

[quote]*refrains from a 3-page long essay on how computers work, regarding why the DWORDs IX86 (and STAR) are displayed as 68XI (and RATS) (and the hex values thereof)*[/quote]
Many years ago, a dispute broke out in a tribe of indians. The dispute was about a trivial matter - when cooking eggs, whether they should be broken in the little end or in the big end.

The dispute was not resolved, and the tribe split to two groups - the group that believed that the eggs should be broken in the little end (the Little Indians, aka Intel) and the group that broke the eggs in the big end (the Big Indians, aka Motorola).

The Little Indians designed the CPU that your computer uses, but the Big Indians designed the network that your data travels through. Therefore a conversion must be made (from IX86 to 68XI, etc.) so that the right end of the egg is sent first.

Yeah, that kiddy-explaination will work good  =]


[quote]The Little Indians designed the CPU that your computer uses[/quote]

*cough*

hahahahaha

Let me try to explain it to you.

Every character in a string is a byte. Think of a byte as a number between 0 and 255 (unless it's signed...which it's not). Thus, every character has a corresponding number. For example, the character 'A' has a value of 65.

When Battle.net sends numbers, it simply writes raw bytes. For example, if it wanted to send the number 65, it would send the single byte 65, which would turn out to be the letter A. It knows whether to interpret it as an A or as 65 based on the position of the byte in the packet.

When you look at your packet logger, you see hex. Hex is simply a way of representing the packets in an easy-to-read form. Hex is base-16. The number 0 is 0h, and the number 255 is FFh. When you're expressing numbers as hex to other people (such as this forum), either add an h at the end of the number or prepend 0x. Why do we use hex? Because if we only looked at the string form, we couldn't easily see the value of numbers Battle.net sends in the form of characters (see the last paragraph). Why don't we use base 10? Well, you could, and some packet loggers do, but everyone really just uses hex. See, in base-10, the numbers displayed could be 1, 2, or 3 characters long. However, in hex, they are always two, so it's easier for packet loggers to format. Hex is also the native base of computers, so that's why you should get to know it!

Hope that helped. Ask someone else about big endian/little endian and how dwords are created.

thank u storm, i tried saying that like 3 times, im just no good with words  :-/

[quote]im just no good with words  :-/[/quote]
What about dwords? ;)

those too, im good with qwords tho :)