[C -> S] 0x51

[Hdx]

I have been being nice and trying to find a simple tutorial but I cant so i'm going to write one.
Anyways, just be honest from the start. It makes things a lot easier.

[Trunning]

Well I wasn't really lying, I know some stuff, just not everything. I'd say I was being in-accurate, and I'd appreciated you writing one yourself.

[Hdx]

You lied, anyways:

Alright, I am not good at explaing things but I will do my best. If the other regulars here want to comment feel free. As I am writing this off the top of my head. It may not be perfect.

Part One: Data Types
On Battle.net every peice of information is encoded as a specific data type. They are most commonly integers. A number without a decimal point. Integer can be signed or unsigned. If a integer is signed it simply means it can be negative.

The easiest way to seperate integer types is to label them by there bits. And if they are signed/unsigned. Here are a few examples:
uint8 - Unsigned 8-bit Int, also known as a BYTE, Range: 0-255
int8 - Signed 8-bit int, Rang: -128 - 128
uint16 - Unsigned 16-bit int, also known as WORD, Range: 0-65,535
int16 - Signed 16-bit int, Range: -32,768 - 32,768
uint32 - Unsigned 32-bit int, also know as DWORD, Range: 0-4,294,967,295
int32 - Signed 32-but int, Range: -2,147,483,648 - 2,147,483,648
uint64 - Unsigned 64-bit int, also know as QWORD, or possibly FILETIME (though this is a special case), Range: 0-18,446,744,073,709,551,615
And so forth.

The other types of data you will see on Battle.net are Strings. In general when you see "String" as the data type they are referring to a 'CStirng' which is an array of bytes, followed by a single null byte. It's also called a Null-terminated String. In vary rare cases you will run into strings that are terminated by another value, this is usually indicated in the packet notes. (Example, D2GS has 0x0A terminated strings)

Memory Layout:
Almost everything on Battle.net is in Littel-endian layout. Which means the least significant byte comes first. This only matters with integers greater then 8 bits.

Lets get to some examples:
8-bit Ints: They are one byte, and are represented as 1 Hex value.

Code Select Expand

0x01 = 01
0x02 = 02
0x03 = 03
Etc...

16-bit Ints: They are 2 bytes, and logically are represented by 2 hex chunks. Remember, Battle.net is Little endian. So the bytes are reversed.

Code Select Expand

0x0102 = 02 01
0x0103 = 03 01
And so on.

32-bit Ints: They are 4 bytes, and get 4 hex chunks. Once again, in reverse order.

Code Select Expand

0x01020304 = 04 03 02 01
0xAABBCCDD = DD CC BB AA
And so forth.

64-bit Ints: They are 8 bytes, and are just the same as everything else.

Code Select Expand

0x0102030405060708 = 08 07 06 05 04 03 02 01
0xAABBCCDDEEFF0011 = 11 00 FF EE DD CC BB AA


So, how can we use this to read packet logs?
Lets say we have a packet which is described as follows:

Code Select Expand

(BYTE) A
(BYTE) B

When we look at it in the log. We see something like:

Code Select Expand

00 01

As I said above, a BYTE is a 8-bit int. Represented by 1 hex value. So A would be the first Hex value:
00 01

Since we have already read a byte, anything else we read, starts AFTER that byte.
So if we were to Read B we would read the 2nd hex value:
00 01

Therefore, our packet is:

Code Select Expand

A = 0x00
B = 0x01
And there is no more data remaing.

Now you can expand upon this to read all the different sizes of integer.
Here is another example:

Code Select Expand

(DWORD) A
(WORD) B
(BYTE) D
With the data of:

Code Select Expand

01 02 03 04 05 06 07

The first thing we read, is a DWORD, which is 4 bytes.
01 02 03 04 05 06 07
And, since it's little-endian, it's reversed. So we end up with a value of: 0x04030201

Next we read a WORD, 2 bytes, and again in reverse order!
01 02 03 04 05 06 07
Which turns into: 0x0605

And yet again, we read a single byte, we can't really reverse the order of 1 thing, so this one's easy:
01 02 03 04 05 06 07
Which turns into: 0x07


Now, the only other thing you need to learn to read, are strings. They are really simple. You read everything untill you hit the terminator.
So if you have a packet as such:

Code Select Expand

61 62 63 64 65 00
a  b  c  d  e  .
It's null terminated, so read untill you get to '00'
You end up with 'abcde'

Part 3: Arrays
Arrays are stright forward, they are simply multiple values of the specified type.
So if you see:

Code Select Expand

(DWORD[2]) Data
Its exactly the same as:

Code Select Expand

(DWORD) Data[0]
(DWORD) Data[1]


So, this isn't a perfect tutorial. But it's fairly basic. So i'm gunna leave with a test!
The packet format is:

Code Select Expand

(DWORD) Registration Version
(DWORD) Registration Authority
(DWORD) Account Number
(DWORD) Registration Token
And your packet log is:

Code Select Expand

AB CF 64 72 85 AB DD CC CC 74 00 94 11 BB 34 76
What would each of the values in the packet be?

[brew]

Just an interjection while you're on this topic, you should make sure you do things right with endianness the first time around to avoid lots of problems. I never properly did a packet buffer/debuffer, and I used all kinds of hacks in my bots, such as appending a character to a string by doing something like *(unsigned short *)(str + strlen(str)) = '\', which turned it into a disaster when I went to compile for SPARC.

[Hdx]

Thats a horrible horrible way to append a character... (code wise)
Anyways, endianess doesn't matter beyond what I explained above right now.

[rabbit]

Didn't read the whole thing yet, but I thought I'd point out that FILETIME is a structure of 2 UInt32's, a Hiword and Loword.  You can treat it as a signle UInt64, though if you try to derive a time from it in that form you will get bad results.

Also, DWORD/WORD on BnetDocs are (by convention, apparently) the 16-bit system equivalent, as a WORD on a 32-bit system is 4 bytes, and on a 64-bit system 8 bytes, but in BnetDocs a WORD is only 2 bytes.

[Trunning]

Pretty sure I got these right, and that really cleared some things up.

Registration Version     = 0x7264CFAB
Registration Authority   = 0xCCDDAB85
Account Number      = 0x940074CC
Registration Token           = 0x7634BB11

[Hdx]

Didn't read the whole thing yet, but I thought I'd point out that FILETIME is a structure of 2 UInt32's, a Hiword and Loword.  You can treat it as a signle UInt64, though if you try to derive a time from it in that form you will get bad results.

Odd, I've never had issues with passing it as a 64-bit int to the various APIs.  If you mean manually trying to convert it.. ya thats a pain.

Also, DWORD/WORD on BnetDocs are (by convention, apparently) the 16-bit system equivalent, as a WORD on a 32-bit system is 4 bytes, and on a 64-bit system 8 bytes, but in BnetDocs a WORD is only 2 bytes.

Thats why I put them in the AKA form, anyways Bnet packet docs have been behind the time for a long time. Personally I think everything should be denoted in (u)int(#) format. It's less ambiguous.

Pretty sure I got these right, and that really cleared some things up.

Registration Version     = 0x7264CFAB
Registration Authority   = 0xCCDDAB85
Account Number      = 0x940074CC
Registration Token           = 0x7634BB11

Correct!!!!!
Now heres the kicker.
Look at your packet log again.
And figure out whats wrong with it.
This ones a bit trickier then simply reading the log because the packet is malformed. So you have to put some logical thinking into it.

[Trunning]

Code Select Expand

struct BNLS_HEADER {
WORD Length;
BYTE         ID;
};

struct CMSG_BNLS_HASHDATA {
DWORD Size;
DWORD Flags;
void *Data;
DWORD ClientKey;
DWORD ServerKey;
};

Code Select Expand

0000   17 00 0b 03 00 6c 6f 6c 3f ab e7 4b fc 74 ba 85  .....lol?..K.t..
0010   cd cd cd cd cd cd fd                             .......

Length: 17 00
ID: 0b

Size: 03 00 // ends to early should be 2 more bytes here

And there should be another DWORD flags after it, not the string. Lemme look at the code.

[Hdx]

Correct!!!! And there is actually one more error but it should be obvious once you fix the one you found!
Now, how hard was that, with a little understanding of how to read the logs. It makes identifying issues million times easier.

[Trunning]

Finally fixed the packet up, now let me confirm it.

Code Select Expand

0000   17 00 0b 03 00 00 00 02 00 00 00 6c 6f 6c 88 ad  ...........lol..
0010   e7 4b 90 ee 12 9a fd                             .K.....

Length = 17 00
ID = 0b

Size = 03 00 00 00
Flags = 02 00 00 00
Password = 6c 6f 6c
ClientKey = ad e7 4b 90
ServerKey = ee 12 9a fd

Everything is there, let me test it.

[Trunning]

Omg, I logged in fine!

Now do I have to enter chat now, or can I startup mcp and logon to a character, and then enter chat?

And is this still the correct order for mcp? http://forum.valhallalegends.com/index.php?topic=11383.0

[Hdx]

You actually still have an issue.
I would suggest your fix it before moving on.
Look at your packet log, and ask yourself 'where did 88 go?'

And yes, the post your linked to looks correct.

[Trunning]

Uh what packet are you referring to? 88 is in the log I posted above. Unless you mean, where was it sent.

[Hdx]

Finally fixed the packet up, now let me confirm it.

Code Select Expand

0000   17 00 0b 03 00 00 00 02 00 00 00 6c 6f 6c 88 ad  ...........lol..
0010   e7 4b 90 ee 12 9a fd                             .K.....

Length = 17 00
ID = 0b

Size = 03 00 00 00
Flags = 02 00 00 00
Password = 6c 6f 6c
ClientKey = ad e7 4b 90 <~~Wrong
ServerKey = ee 12 9a fd <~~Wrong

Everything is there, let me test it.