Packet 0x50 Question

[Mesiah / haiseM]

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...

[gotcha_ass]

ok yall keep confusing me, this is the code I have to send the 0x50 packet:

Code Select Expand

   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
Is this right??

[Noodlez]

ok yall keep confusing me, this is the code I have to send the 0x50 packet:

Code Select Expand

   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
Is this right??

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.

[gotcha_ass]

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

[gotcha_ass]

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.

[tA-Kane]

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.

[Mesiah / haiseM]

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.

[gotcha_ass]

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?

[gotcha_ass]

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)

[Mesiah`Gramma's]

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

Code Select Expand

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.
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.

[Yoni]

*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)*

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.

[tA-Kane]

Yeah, that kiddy-explaination will work good  =]

The Little Indians designed the CPU that your computer uses

*cough*

[Banana fanna fo fanna]

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.

[Mesiah / haiseM]

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

[tA-Kane]

im just no good with words  :-/

What about dwords?