Problems with the 0x3E packet

[Tejjoj]

I got a question. How is the hasing done in there? It is not the usual hash thought. Can anyone hook me up with informations? Thanks!

[Barabajagal]

3E C>S
I assume you're talking about the password hashing? It's not your character's password, it's the realm's password, which is always "password"

[Tejjoj]

3E C>S
I assume you're talking about the password hashing? It's not your character's password, it's the realm's password, which is always "password"

OH! Thanks!

[Chriso]

Just to clarify that, you should send it double hashed.  Also I am not sure but is the USEast realm down?  I keep getting:

08:04:25 AM : Realm listing received!
08:04:25 AM : - USEast (Realm for the US East Coast)
08:04:25 AM : Connecting to realm 63.240.202.148:57367..
08:04:46 AM : [Realm] #10060: The attempt to connect timed out

[Barabajagal]

57367?
Isn't the realm port usually 6112? And it works fine for me.

[brew]

That's one thing I absolutely hate about the 0x3E's response. The port is a DWORD and the byte order appears to be big endian but the entire low word is 0... I think I gave up trying to parse that correctly and hard coded 6112 for the port.

EDIT*** To clarify...
Ya get it like 17 E0 00 00.
What he did was use GetDWORD. It produces the value of E017. Equivalent to 57367 in decimal. This however makes no sense. If it was in big endian byte order as is the standard for sending IPs and ports, the port would be 400556032. Oh please. Blizzard's mistake for using a DWORD for the port. Unless ofcourse, bnetdocs is wrong (this could happen, ya know) and the two bytes after that are actually part of another field... bah.

[l2k-Shadow]

ever see this lovely function?

[Chriso]

That's one thing I absolutely hate about the 0x3E's response. The port is a DWORD and the byte order appears to be big endian but the entire low word is 0... I think I gave up trying to parse that correctly and hard coded 6112 for the port.

EDIT*** To clarify...
Ya get it like 17 E0 00 00.
What he did was use GetDWORD. It produces the value of E017. Equivalent to 57367 in decimal. This however makes no sense. If it was in big endian byte order as is the standard for sending IPs and ports, the port would be 400556032. Oh please. Blizzard's mistake for using a DWORD for the port. Unless ofcourse, bnetdocs is wrong (this could happen, ya know) and the two bytes after that are actually part of another field... bah.

Yeah, in the past I seem to remember using a function to convert the port to 6112, I forget what it was though.  Its been a while since I've bothered with MCP packets.

[Chriso]

ever see this lovely function?

Haha very nice, thanks l2k-Shadow.

[l2k-Shadow]

to clarify:

Code Select Expand


#include <windows.h>
#include <winsock2.h>
#include <iostream.h>

#pragma comment(lib, "ws2_32")

void main()
{
char s[] = "\x17\xe0\x00\x00";
DWORD d = 0;
memcpy(&d, s, 4);
cout << ntohs(d) << endl;
}


[Chriso]

10:31:58 AM : Connecting to realm 63.240.202.148:6112..
10:31:58 AM : [Realm] Connected!



Visual Basic Alternative:

Code Select Expand


Public Declare Function ntohs Lib "ws2_32" (ByVal netshort As Long) As Long

' Get the port
Port = ntohs(r.GetInt32())


[Camel]

Are you sure that the packet format is a DWORD for the port? Ports are unsigned 16-bit integers.

[Chriso]

The received port is E017 (57367), but the port itself should be 17E0 (6112).  However the ntohs function seems to fix this ordering problem.

[l2k-Shadow]

The received port is E017 (57367), but the port itself should be 17E0 (6112).  However the ntohs function seems to fix this ordering problem.

If we say that the server sends it as 0x17E00000, remember you're working on a little endian machine. So when you plug that variable into a "Long" it becomes 0x0000E017 or 0xE017 (57367). ntohs() switches the byte order for you to have it become 0x17E0 which is 6112.

The reason you receive it as 57367 is because TCP/IP data is sent in big-endian byte order.

[Barabajagal]

Moral: Non-universal standards are a bitch.