Fast question about a packet

[option]

Code Select Expand

00000000  ff 3a 30 00 f6 4d 3a 00  82 57 b1 56 32 7f 4b ad .:0..M:. .W.V2.K.
00000010  ec 84 a6 ba 33 7a 7c 9d  53 c9 1a 28 c0 96 b9 de ....3z|. S..(....
00000020  76 65 78 2e 72 65 73 75  72 72 65 63 74 65 64 00 vex.resu rrected.

The packet header, is the DWORD ff 3a 30 00.

Alright, FF signals the start of a packet. 3a is the identification byte, (0x3a is the packet), and 30 00 is a WORD representing the packet's size.

So, according to a hex to decimal calculation, the word 0x3000 is 12288 (in dec).

However, is that little endian, and really read, 00 30? Because if that's the case, then we've got 48 instead of 12288, and there are 12 DWORD's in 0x3a, and each DWORD is 4 bytes each, so that would give the packet length a 48byte size?

Either that really makes sense or I am looking at this totally wrong. I'd like to know which it is

[Barabajagal]

How do you not know this yet? Everything except ports are in little endian, whether they be Words, DWords, or Filetimes.

[iago]

How do you not know this yet?

What, were you born knowing it? Give him a break, he's obviously new at this.

[option]

so that header, comes through as, 00 30 3a ff?

well, is it 48 bytes then as opposed to 12288?

[Barabajagal]

No, the header is not a DWord. It's two bytes and a word.

[option]

So FF, 3A, 00 30?

[brew]

yes.

[option]

Alright that is sweet, thanks for the info.

Alright also: one last.

Say you have myPacket.insertNTstring("IX86");

Do you actually have to insert the string into the packet as ("68XI") or you put it in normally, and it is sent as reverse endian?

EDIT: I actually heard that the game code or whatever that is, is a non NT string, is that true?

[brew]

It's not an NT string- it's not a string at all. It's the dword 0x49583836. I don't know nor want to know where you got the notion that it's a string...

Try this instead:
myPacket.insertDWORD('IX86');
And yes, just ignore the warning it throws when you use a multi-character constant in gcc.

Just a sidenote: Using a non nt string in a packet is never correct.

[option]

   http://botdev.valhallalegends.com/documents/bnetpacketedu.html

how the hell do you turn IX86 into a DWORD? I mean i guess it's as simple as adding it as a DWORD to your packet, but how does IX86 turn into 0x49583836? what happens there to make that conversion?

[brew]

There's this awesome thing called ascii. I think you should look into it.

[option]

Oh shit, I am retarded. Each character is a byte, DWORD is 4 bytes, soo ...

0x 49 58 38 36

Nice call man that eliminated much confusion. So we don't actually need to convert it to hex before we put it into the DWORD, that automatically happens? (assuming the insertDWORD function is complete).

So we put it in normal, and when it is sent, it arrives at bnet like 0x36 38 58 49?

[brew]

Data is data. There's not much to it. It doesn't matter if it's parsed as a string, a filetime structure, a float, or anything. When data is sent over a winsock, it's nothing but a block of memory- how the server deals with it is its own problem. The server does something like...

Code Select Expand


switch (*(int *)(data + 4)) {
   case 'IX86': //send the ix86 files...
     blahblahblah;
     break;
   case 'PMAC':
     blahblahblahblah;
     break;
   case 'XMAC':
    sdfgasfd;
    break;
   default:
    disconnectuser(socket);
  }

as you can see, the char * is being casted to an int *, so there's your answer. it arrives as nothing but an amorphous blob of data, but is parsed as an integer.

[option]

Alright so, when a packet requires a DWORD, that you are inputting as a string, don't worry about converting it or anything before we send the packet. It's merely as simple as

myPacket.insertDWORD("whateverNTstringyouneedtosend");

And the compiler does the rest?

That's what im hung up on, thanks for your patience btw just stick with me here haha

Fast little edit: You don't need to insert it backwards either, do you? From what andy said, DWORDS are among those sent in little-endian, so do you actually have to put the string in as ("68XI"), or ("PX2D"), or do you put it in the proper way and then winsock just sends it backwards

[MyndFyre]

Alright so, when a packet requires a DWORD, that you are inputting as a string, don't worry about converting it or anything before we send the packet. It's merely as simple as

myPacket.insertDWORD("whateverNTstringyouneedtosend");

And the compiler does the rest?

That's what im hung up on, thanks for your patience btw just stick with me here haha

Fast little edit: You don't need to insert it backwards either, do you? From what andy said, DWORDS are among those sent in little-endian, so do you actually have to put the string in as ("68XI"), or ("PX2D"), or do you put it in the proper way and then winsock just sends it backwards

Not quite.

C and C++ allow 4-character character literals to be treated as a long int (32-bit).  So you can declare:

Code Select Expand


const long int IX86 = 'IX86';


That will perform the endianness conversion for you automatically.  You just treat IX86 as any other integer value.

However, you need to distinguish between these kinds of "strings" and real character strings.  If you want to insert a null-terminated string (which is what C strings are), then you'll need to have a separate function for it, and it should probably be named "InsertString" or "InsertNTString", not "InsertDWORD".