[code]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.[/code]

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

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

[quote author=Andy link=topic=17529.msg178583#msg178583 date=1213908169]
How do you not know this yet?
[/quote]
What, were you born knowing it? Give him a break, he's obviously new at this.

:(

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

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

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

So FF, 3A, 00 30?

yes.

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?

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.

:(  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?

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

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?

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]
switch (*(int *)(data + 4)) {
   case 'IX86': //send the ix86 files...
     blahblahblah;
     break;
   case 'PMAC':
     blahblahblahblah;
     break;
   case 'XMAC':
    sdfgasfd;
    break;
   default:
    disconnectuser(socket);
  }
[/code]
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.

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

[quote author=option link=topic=17529.msg178604#msg178604 date=1213984401]
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
[/quote]

Not quite.

C and C++ allow 4-character character literals to be treated as a long int (32-bit).  So you can declare:
[code]
const long int IX86 = 'IX86';
[/code]

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

Yeah I got that, I was strictly referring to strings you insert as DWORDs. Thanks for the clarification though

No, not at all. Did you notice how I used single quotes? I put in a DWORD, not a string.
For example...
' ' is the same as putting in 0x20
'0' is the same as putting in 0x30
'!' is the same as putting in 0x21
'IX86' is the same as putting in 0x49583836.
Do you see?
So when you do something like... i = strchr(asdf, '0');, you're passing 0x30 as the second parameter. Notice how it asks for an int, not a string :P
Same thing with assigning a value to a byte...
Say you want to cut off the \n from a string after you called fgets().
I would do something like so:
[code]
asdf[strlen(asdf) - 1] = 0;
[/code]
However, that's just my coding style. Others might have made the 0 instead '\0'. That doesn't matter, since they're the same.


Also, your myPacket.insertDWORD("whateverNTstringyouneedtosend"); wouldn't work at all. I assume insertDWORD takes an unsigned long (hence insertdword), not a string pointer. Putting that code in would result in an error. For inserting NT strings, you should check out mypacket.insertNTString.

EDIT* Whoops, didnt see mynd's post.

Alright, so just for my reference, this is what I just did - just to see if I was on the same page as you guys.

putting 'IX86' into an unsigned long int, is the same as putting in 0x49583836, which I understand.

[code]#include <iostream>

const unsigned long int IX86 = 'IX86';

using namespace std;

int main () {
cout << IX86 << endl;

return 0;
}[/code]

My program returns 1230518326.

That isn't IX86 the string in ASCII, HEX, or octal. What is it?

Convert 1230518326 to hexadecimal and you get 0x49583836

If you used a little C, (I dont know much about iostream), you could output it like this:
[code]#include <stdio.h>

const unsigned long int IX86 = 'IX86';


int main (void)
{
printf("%X\n", IX86);

return 0;
}[/code]

[quote author=Andy link=topic=17529.msg178612#msg178612 date=1213990628]
Convert 1230518326 to hexadecimal and you get 0x49583836
[/quote]

Do I need to do that before I send the packet?

[quote author=option link=topic=17529.msg178614#msg178614 date=1213992403]
[quote author=Andy link=topic=17529.msg178612#msg178612 date=1213990628]
Convert 1230518326 to hexadecimal and you get 0x49583836
[/quote]

Do I need to do that before I send the packet?
[/quote]he was just stating a fact.
90% of the time when you're talking about data you put it in hex, unless its <100~
What language you working in?
if its any C style language you can simply do 'IX86' wherever you would out it's int value. But if its in other languges you have to convert it: 0x49583836

Damn andy, you weren't kidding:

[img]http://img99.imageshack.us/img99/2400/hexbz8.jpg[/img]

Took forever haha

Yeah Hdx I am working in VC++, so the point is, I could just put IX86 into a DWORD, as is, without reversing it, and then send the packet?

The values 'IX86', 1230518326, and 0x49583836 are all equal. They're identical. There is no distinction between them.

Oh man that's sweet to know.

Alright, now I need a C++ packet buffer so I can pick apart and learn how it works, can't create one myself at the moment because of lack of concept knowledge, all tutorials I've found through search are down (domains), and there seems to be like 4354354 C# ones, but no C++ ones.

:(

PS even though  these questions are rather newb, at least I'm giving you something to do :P

[quote author=option link=topic=17529.msg178616#msg178616 date=1213994250]
Damn andy, you weren't kidding:
[/quote]

Wow, what is this the 1800's?  most operating systems have a built-in calculator

hahah yeahhh well I just learned a lot about bytes, words, dwords, binary, hex, and just wanted to make sure I could actually do the conversion, so instead of just calculating it I tested my knowledge at the same time haha

[quote author=option link=topic=17529.msg178620#msg178620 date=1213997600]
hahah yeahhh well I just learned a lot about bytes, words, dwords, binary, hex, and just wanted to make sure I could actually do the conversion, so instead of just calculating it I tested my knowledge at the same time haha
[/quote]

At least it's written proof you're serious about learning.

I see summer break has started, and so you have free time now.  I wondered what happen.  You kind of disappeared, I thought maybe BotDev sacred you away, heh.  Btw, the link in your sig is broken.

It will most definitely be updated soon, it's at another host at the time being.

And yes I am back, school takes up a good amount of time, but i finished a few more programming courses and am armed with even more knowledge now so I am looking forward to getting back in the swing of things here!

[quote author=brew link=topic=17529.msg178607#msg178607 date=1213985104]
Also, your myPacket.insertDWORD("whateverNTstringyouneedtosend"); wouldn't work at all. I assume insertDWORD takes an unsigned long (hence insertdword), not a string pointer. Putting that code in would result in an error. For inserting NT strings, you should check out mypacket.insertNTString.
[/quote]

Actually, since strings manifest as pointers to chars, and pointers are 32-bit integers, it would write to the packet the address in memory of the string literal. You definitely don't want to do that.

[quote author=Camel link=topic=17529.msg178635#msg178635 date=1214210393]
[quote author=brew link=topic=17529.msg178607#msg178607 date=1213985104]
Also, your myPacket.insertDWORD("whateverNTstringyouneedtosend"); wouldn't work at all. I assume insertDWORD takes an unsigned long (hence insertdword), not a string pointer. Putting that code in would result in an error. For inserting NT strings, you should check out mypacket.insertNTString.
[/quote]

Actually, since strings manifest as pointers to chars, and pointers are 32-bit integers, it would write to the packet the address in memory of the string literal. You definitely don't want to do that.
[/quote]
If he writes an explicit cast to that parameter- and since he didn't in the code he spat out, it'd just error.

[quote author=Camel link=topic=17529.msg178635#msg178635 date=1214210393]
[quote author=brew link=topic=17529.msg178607#msg178607 date=1213985104]
Also, your myPacket.insertDWORD("whateverNTstringyouneedtosend"); wouldn't work at all. I assume insertDWORD takes an unsigned long (hence insertdword), not a string pointer. Putting that code in would result in an error. For inserting NT strings, you should check out mypacket.insertNTString.
[/quote]

Actually, since strings manifest as pointers to chars, and pointers are 32-bit integers, it would write to the packet the address in memory of the string literal. You definitely don't want to do that.
[/quote]
On my computer, pointers can be 64-bit integers.