Alright, in order to get a packet log of me logging on to Diablo II, I set the Ethereal filter to ("tcp.port == 6112"). Then I chose my device, began capturing, logged on, and stopped capturing. After that, In Ethereal, I went to the Analyze menu and clicked "Follow TCP Stream", and viewed it in Hex.

This is what I got:
[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.
                                                                              00000000  ff 3a 08 00 00 00 00 00                          .:......
00000030  ff 40 04 00                                      .@..
                                                                              00000008  ff 40 33 00 00 00 00 00  01 00 00 00 01 00 00 00 .@3..... ........
                                                                              00000018  55 53 45 61 73 74 00 52  65 61 6c 6d 20 66 6f 72 USEast.R ealm for
                                                                              00000028  20 74 68 65 20 55 53 20  45 61 73 74 20 43 6f 61  the US  East Coa
                                                                              00000038  73 74 00                                        st.
00000034  ff 3e 23 00 03 00 00 00  31 40 de 00 41 fe 35 f3 .>#..... 1@..A.5.
00000044  c6 5c ea 92 ab 1d 62 a3  f4 b8 18 9e 55 53 45 61 .\....b. ....USEa
00000054  73 74 00                                        st.
                                                                              0000003B  ff 3e 5e 00 03 00 00 00  87 1e 3f 3c 3f f0 ca 80 .>^..... ..?<?...
                                                                              0000004B  29 70 95 00 3f f0 ca 94  17 e0 00 00 00 00 00 00 )p..?... ........
                                                                              0000005B  79 e2 25 06 4c e1 3a af  50 58 32 44 36 38 58 49 y.%.L.:. PX2D68XI
                                                                              0000006B  3f f0 ca 80 09 04 00 00  91 8f d9 e1 e2 d5 4c d1 ?....... ......L.
                                                                              0000007B  4f 46 98 41 6e b8 1a bd  1d 69 55 75 76 65 78 2e OF.An... .iUuvex.
                                                                              0000008B  72 65 73 75 72 72 65 63  74 65 64 00 ff 22      resurrec ted.."[/code]

I am using a wireless device to capture packets, not sure if that would impact this in any way.

If this is correct, I can begin interpreting the packets so I understand exactly what they do. If not, that means I did something wrong and would appreciate a few pointers regarding what error I made.

Thanks in advance!

you captured the realm logon sequence. (don't see any MCP in there, though)

you don't have to do any guesswork, until the official BnetDocs are back online, you can view a mirror here.

http://ersan.us/src/bnetdocs/content.html

the second byte of each packet is the packet ID. (0x40, 0x3A, 0x3E, etc) just match up your packets to what's on BnetDocs.

you can view the complete realm logon sequence at https://davnit.net/bnet/vL/index.php?topic=11383.0.

Alright let me make sure I understand what is going on here, and what I have to do.

The first packet sent is 0x3a(, or &H3a?).

According to BNET Docs, this "flag" or "event" (not sure which) is SID_LOGONRESPONSE2. It can be found here: http://ersan.us/src/bnetdocs/content6965.html?Section=m&Code=367 and consists of:
(DWORD) Client Token
(DWORD) Server Token
(DWORD[5]) Password Hash
(STRING) Username

In order to assemble this packet in a program that replicates a BNET connection, I.e. a clientless bot, You must take the information it is asking for and convert it to DWORDS etc? For example, I have no idea what a Client or Server token is, but I am assuming you use the MakeDWORD libraries found in BNBDR to convert the data (the tokens), assemble the packet through a packet buffer (also found in BNBDR), and then send it to the server?

I think I am slightly starting to understand this more, but even after reading about Hex and everything I still feel like I am missing valuable steps I should understand more

EDIT: Is this WHOLE part packet 0x3a?
[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 whole thing is a packet, yes.

First part: FF 3A 30 00
header. FF signals beginning of packet. 3A is packet ID. 30 00 is a WORD value for 0x30, which is the byte length of the entire packet.

Second part: F6 4D 3A 00
client token DWORD. This value is created once and sent to the server. Static value throughout a connection, usually GetTickCount.

Third part: 82 57 B1 56
server token DWORD. This value is received from Battle.net once and stored. Static value throughout a connection.

Fourth part: 32 7F 4B AD, EC 84 A6 BA, 33 7A 7C 9D, 53 C9 1A 28, C0 96 B9 DE
password hash 5 DWORDs. This is hashed by Broken SHA hashing the password, then hashing the password again with Client and Server tokens included.

Fifth part: 76 65 78 2E 72 65 73 75  72 72 65 63 74 65 64 00
username NT-STRING. This is the username to log in with, terminated by a null character, as all strings are in BNet connections. If it's a Non-NT-String, it's actually a series of bytes, words, or DWORDs. Non-NT-Strings are just the representation some of us use for raw data, though most people will recommend you don't use them.

Understand?

Yeah man I appreciate the breakdown. The only thing I don't understand is part 4:

[quote]Fourth part: 32 7F 4B AD, EC 84 A6 BA, 33 7A 7C 9D, 53 C9 1A 28, C0 96 B9 DE
password hash 5 DWORDs. This is hashed by Broken SHA hashing the password, then hashing the password again with Client and Server tokens included.[/quote]

How do you include the password hash with the client and server tokens?

EDIT: What are the long strings of 0000 followed by a 1 or 2 before each packet sequence? I.e.

[code]00000000[/code] is before the first ff 3a.

[quote author=option link=topic=16885.msg171052#msg171052 date=1184640061]
How do you include the password hash with the client and server tokens?
[/quote]
the password and the tokens are hashed which produces your final "hashed" product. you can hash them using BNLS (remotely) or a local library such as BNCSUtil, MBNCSUtil, BnetAuth, or many other dlls.

[quote author=option link=topic=16885.msg171052#msg171052 date=1184640061]
EDIT: What are the long strings of 0000 followed by a 1 or 2 before each packet sequence? I.e.

[code]00000000[/code] is before the first ff 3a.
[/quote]
i'm not positive what you mean here, i don't see it in your packetlogs, but perhaps you are referring to the TCP header? this just contains data about where the information is being sent to and where from

Alright next question! :P

The packet immediately after the first one is Also 0x3a, Except it is S->C. Here is the packet.

[code]00000000  ff 3a 08 00 00 00 00 00                          .:...... [/code]

Here is what it says in BNETDocs:
(DWORD) Result
(STRING) Reason


Status

0x00: Success
0x01: Account does not exist
0x02: Invalid password

Reason

This is only present when your account is closed, if not, it should be null.

---

Alright, I do not see an 0x00, 0x01, or 0x02. I see, ff, 3a, 08.

What is the 08? Is the whole first part of the packet a DWORD, ff 3a 08 00, and the second part of the packet the 0x00 DWORD that lets me know the login was a success? (00 00 00 00)

If that is the case what does the 08 mean? It's confusing the life out of me.

Lastly, is the garbled stuff at the end of the packet the NULL stuff given because there was no failure message?

Learn to read packets.

[code]00000000  ff 3a 08 00 00 00 00 00                          .:...... [/code]
The 00000000 IS NOT part of the packet. It's the offset. Find a packet that is more then 0x10 bytes long and it will jump down to 00000010 0x10 more it'll go to 00000020 get the idea?
So the actuall data is this:
[code]ff 3a 08 00 00 00 00 00                          .:......[/code]
Which is in two forms, the hex, and the ascii. They mean the same thing It's jsut that the ASCII lets you see easier if theres any legible text inside (It replaces all chars that arnt alphanumeric with periods. )
So if you had two NT Strings right after eachother "Bob" "John" you'd see "Bob.John." in the ASCII part.
So ff 3a 08 00 00 00 00 00 is the actuall data, you need to chop of the head, ((byte)0xFF (BYTE) ID (WORD) Length)) Which results in this:
00 00 00 00
So you have a DWORD thats null (0x00000000)
Seince it's a successful login, you don't have the following NTString

Also, it's customary to Put S->C: or C->S insted of tabbing out your packet log into two columns. As breaking the table is a big EWWWW.
~Hdx

Alright thanks Hdx, I understand everything I had problems with 100x better thanks to your (and Tazo / Andy's) replies.