I could care less about the packets been sent back and forth once the game has started.

I'm actually interested in breaking down the packets that are sent back and forth when a host creates a custom game and people leave/join.

Some of you may be familiar with the program "WC3Banlist" (wc3banlist.com). Which uses winPcap to do exactly what I'm curious about.

I am using vBpCap to capture the packets via winPcap, and I've actually been quite successful in retrieving data from the packets in what I can only assume is a very amateur fashion.

I've managed to isolate the packets that include the strings of the names of the people that join my game and add them to a listview. 

As I really didn't have any experience interpreting/breaking down packets and very little experience working with hex...I'll I really did was locate unique offsets for bytes that always seemed to be the same in packets that included username strings, and just counted up from the offset to extract the string within my program - using a simple "loop until" statement that went through the byte array 1 by 1 to retrieve each character of the string.

ALL I really need at this point is to isolate the packet that indicates a user has left the game lobby. I'm a bit stumped because there is no legible ASCII FOR ME TO WORK WITH!!! AHH!! LOL, as I said earlier, my methods up until this point were rather amateur and simple and only worked because the packets consisted of strings that were understandable to me.

I'm assuming blizzard uses similar command and type flags for all of their games so hopefully someone could point me in the right direction.

Any help would be greatly appreciated!
Thanks!

You need to understand how their protocol works to correctly identify all the fields in a packet.

not all data will be ascii, they will be sending perhaps integers, longs, shorts, bytes which represent numbers not an ASCII character (otherwise known as a string/char array/byte array) An ASCII character is actually just a number too btw, it's just that each number stands for a certain character.

so on so forth, this is basic elementary shit

[quote author=TheMinistered link=topic=14436.msg147685#msg147685 date=1141618330]
You need to understand how their protocol works to correctly identify all the fields in a packet.

not all data will be ascii, they will be sending perhaps integers, longs, shorts, bytes which represent numbers not an ASCII character (otherwise known as a string/char array/byte array) An ASCII character is actually just a number too btw, it's just that each number stands for a certain character.

so on so forth, this is basic elementary shit
[/quote]

That's essentially what I said in my original post.

Basically you just reiterated what I posted.... Thank you for doing so man, but that's not really why I posted.

The REASON why I posted in the first place was to find out if someone had reversed the protocol and could give me some pointers, or maybe give me some ideas as to how I could break it down myself.

[quote author=lspnet link=topic=14436.msg147711#msg147711 date=1141639788]
That's essentially what I said in my original post.

Basically you just reiterated what I posted.... Thank you for doing so man, but that's not really why I posted.

The REASON why I posted in the first place was to find out if someone had reversed the protocol and could give me some pointers, or maybe give me some ideas as to how I could break it down myself.
[/quote]

Well, realistically, your original post did not convey that message.  It really seems that you don't know the distinction and relation between hex/ascii/binary data -- for instance you said:
[quote author=lspnet link=topic=14436.msg147636#msg147636 date=1141571548]
I'm a bit stumped because there is no legible ASCII FOR ME TO WORK WITH!!! AHH!!
[/quote]
This tells us that you don't know or understand when it's appropriate to interpret data as something other than ASCII, or how to do so.

You might want to review TheMinistered's post to possibly grasp the concept he's trying to explain.

[quote author=lspnet link=topic=14436.msg147711#msg147711 date=1141639788]
The REASON why I posted in the first place was to find out if someone had reversed the protocol and could give me some pointers, or maybe give me some ideas as to how I could break it down myself.

[/quote]

[me="Explicit[nK]"]points at TheMinistered[/me]

Ok, this is the packet I am trying to reverse.... excluding the header info (which I already understand) - the data, as usual, starts at 0x37. This particular packet was a packet sent right after the user joined the lobby. Generally, the joiner will send a packet which really only contains his name in ASCII, a port number, and an internal ip (like 192.168.1.101). Then the host will PSH, ACK him with this packet, and that appears to be when the user enters the lobby.

Users can send those request packets (with the names in them) but not all of them will be able to join - the game may fill up before the user can enter the lobby, in which case this PSH, ACK packet is not sent. This happens often when you are closing/opening single slots to refresh the game (which I'm sure some of you DotA gamers are familiar with), and multiple people try to join with only 1 slot open.

At this point I'm not sure how to interpret it any further. This "type" of packet also seems to be sent to the clients multiple times during a lobby session even after they have officially entered the game. The 0x64 (100) byte appears frequently in these packets, and they kind of seem to have a pattern:

[code]0000  00 14 95 78 1a 21 00 01  29 fc 87 b1 08 00 45 00   ...x.!.. ).....E.
0010  00 b2 3e 6e 40 00 80 06  39 2a 45 e6 e5 17 45 a9   ..>n@... 9*E...E.
0020  12 07 17 e0 76 0f f3 e8  48 9e 79 1d 5f 2f 50 18   ....v... H.y._/P.
0030  ff cd 83 52 00 00 f7 04  8a 00 73 00 0c 00 ff 02   ...R.... ..s.....
0040  01 00 00 04 01 64 01 64  02 00 00 01 04 01 64 00   .....d.d ......d.
0050  ff 00 00 00 02 04 00 64  00 ff 01 00 00 03 04 00   .......d ........
0060  64 00 ff 01 00 00 04 04  00 64 00 ff 01 00 00 05   d....... .d......
0070  04 00 64 00 ff 02 01 01  06 08 01 64 00 ff 01 00   ..d..... ...d....
0080  01 07 08 00 64 00 ff 01  00 01 08 08 00 64 00 ff   ....d... .....d..
0090  01 00 01 09 08 00 64 00  ff 01 00 01 0a 08 00 64   ......d. .......d
00a0  00 ff 01 00 01 0b 08 00  64 37 f3 a5 00 03 0c 02   ........ d7......
00b0  02 00 76 0f 45 a9 12 07  00 00 00 00 00 00 00 00   ..v.E... ........[/code]

As I mentioned earlier, this packet was sent right as the user joined the lobby. The packet, for whatever reason, also includes the port number (30223) and the user's IP (69.169.18.7) again at the bottom of the data segment.

That’s really the only thing I've been able to break down. Please understand that I litterally just started doing this on Friday (March 3), up until then I didn't even clue what a packet was... So sorry if I ask/say anything stupid.

Any help would be awesome thanks!

Im plan to follow this topic, however I suggest you should have it moved to the BnetDocs research forum.  Its more applicable there and stands a significantly better chance of getting what you're looking for.

Edit: Also look at the starcraft lobby protocol in that same forum.  It is likely that warcraft III atleast uses a simiar system to starcraft so you can know what packets to look for(slot updates, team changes, user leave/join etc..)

Some notes:

[quote]F7 28 13 00 06 01 04 05 06 07 08 03 10 73 74 61  .(...........sta
72 74 00                                        rt.          [/quote]

A packet capture of user talk.

[quote]F7 1E 35 00 06 00 00 00 00 00 00 00 00 E0 17 07  ..5.............
00 00 00 62 6C 61 64 65 5F 64 65 73 74 72 6F 79  ...blade_destroy
65 72 00 01 00 02 00 17 E0 D3 1E 0D B1 00 00 00  er..............
00 00 00 00 00                                  .....      [/quote]

User joining or leaving, I don't recall which.

[quote]
F7 44 0E 00 01 04 01 00 00 00 14 DD 18 00 F7 42  .D.............B
0D 00 01 00 00 00 03 14 DD 18 00 F7 28 1C 00 05  ............(...
01 02 05 06 08 04 10 4C 61 20 6C 61 20 6C 61 6C  .......La la lal
61 6C 61 20 6C 61 00                            ala la.        [/quote]

More user talk, but this time the ID has changed. hm...

[quote]F7 1E 31 00 06 00 00 00 00 00 00 00 00 E0 17 1A  ..1.............
00 00 00 53 6C 69 76 65 72 2E 4B 69 6E 67 00 01  ...Sliver.King..
00 02 00 17 E0 C0 A8 01 40 00 00 00 00 00 00 00  ........@.......
00                                              .              [/quote]

Defiinitely a user join, who is 'Sliver.King'.



A lot of null padding seems to be in use, or maybe they're just unknown response codes? No idea.

In response to the poster above, the second packet is probably a user join event as the (im guessing here) packet ID matches that of the fourth packet.

IIRC all of the games use UDP.  The packets Topaz posted are on BnetDocs anyway.

[quote author=lspnet link=topic=14436.msg147798#msg147798 date=1141728804]
Ok, this is the packet I am trying to reverse.... excluding the header info (which I already understand) - the data, as usual, starts at 0x37. This particular packet was a packet sent right after the user joined the lobby. Generally, the joiner will send a packet which really only contains his name in ASCII, a port number, and an internal ip (like 192.168.1.101). Then the host will PSH, ACK him with this packet, and that appears to be when the user enters the lobby.

Users can send those request packets (with the names in them) but not all of them will be able to join - the game may fill up before the user can enter the lobby, in which case this PSH, ACK packet is not sent. This happens often when you are closing/opening single slots to refresh the game (which I'm sure some of you DotA gamers are familiar with), and multiple people try to join with only 1 slot open.

At this point I'm not sure how to interpret it any further. This "type" of packet also seems to be sent to the clients multiple times during a lobby session even after they have officially entered the game. The 0x64 (100) byte appears frequently in these packets, and they kind of seem to have a pattern:

[code]0000  00 14 95 78 1a 21 00 01  29 fc 87 b1 08 00 45 00   ...x.!.. ).....E.
0010  00 b2 3e 6e 40 00 80 06  39 2a 45 e6 e5 17 45 a9   ..>n@... 9*E...E.
0020  12 07 17 e0 76 0f f3 e8  48 9e 79 1d 5f 2f 50 18   ....v... H.y._/P.
0030  ff cd 83 52 00 00 f7 04  8a 00 73 00 0c 00 ff 02   ...R.... ..s.....
0040  01 00 00 04 01 64 01 64  02 00 00 01 04 01 64 00   .....d.d ......d.
0050  ff 00 00 00 02 04 00 64  00 ff 01 00 00 03 04 00   .......d ........
0060  64 00 ff 01 00 00 04 04  00 64 00 ff 01 00 00 05   d....... .d......
0070  04 00 64 00 ff 02 01 01  06 08 01 64 00 ff 01 00   ..d..... ...d....
0080  01 07 08 00 64 00 ff 01  00 01 08 08 00 64 00 ff   ....d... .....d..
0090  01 00 01 09 08 00 64 00  ff 01 00 01 0a 08 00 64   ......d. .......d
00a0  00 ff 01 00 01 0b 08 00  64 37 f3 a5 00 03 0c 02   ........ d7......
00b0  02 00 76 0f 45 a9 12 07  00 00 00 00 00 00 00 00   ..v.E... ........[/code]

As I mentioned earlier, this packet was sent right as the user joined the lobby. The packet, for whatever reason, also includes the port number (30223) and the user's IP (69.169.18.7) again at the bottom of the data segment.

That’s really the only thing I've been able to break down. Please understand that I litterally just started doing this on Friday (March 3), up until then I didn't even clue what a packet was... So sorry if I ask/say anything stupid.

Any help would be awesome thanks!

[/quote]

I dont have war3, only the demo, and it doesnt have game lobbys, so i souldnt even be posting in such a topic!
Anyway, just going through the topic, and its blinding clear what those packets probly do in that packet dump.
Im guessing you have noticed, theres a 2nd packet appending the 1st in that dump:
[code]
00 14 95 78 1a 21 00 01 29 fc 87 b1 08 00 45 00 00 b2 3e 6e 40 00 80 06 39 2a 45 e6 e5 17
45 a9 12 07 17 e0
76 0f f3 e8 48 9e 79 1d 5f 2f 50 18 ff cd 83 52 00 00



f7 04 8a 00
73 00
0c 00
ff 02 01 00 00 04 01 64 01
64 02 00 00 01 04 01 64 00
ff 00 00 00 02 04 00 64 00
ff 01 00 00 03 04 00 64 00
ff 01 00 00 04 04 00 64 00
ff 01 00 00 05 04 00 64 00
ff 02 01 01 06 08 01 64 00
ff 01 00 01 07 08 00 64 00
ff 01 00 01 08 08 00 64 00
ff 01 00 01 09 08 00 64 00
ff 01 00 01 0a 08 00 64 00
ff 01 00 01 0b 08 00 64 37
f3 a5 00 03 0c 02 02 00 76
0f 45 a9 12 07 00 00 00 00 00 00 00 00
[/code]

The 1st packet contains a IP address and port "69.169.18.7:6112" (like you have already stated)

And the 2nd packet contains infomation about each player, there number, and the game lobby slots(?).
(These are just glancing guess's)
[code]
ff 00 00 00 02 04 00 64 00
(BYTE) Unknown
(BYTE) Race, maybe?
(BYTE) Boolean, Player slot is empty?
(BYTE) Players identification Number? (Why 12 slots?)
(BYTE) Game lobby slot/player state or race?
(BYTE) Unknown
(BYTE) Map DL %?
(BYTE) Unknown
[/code]

Like i said i dont have war3, so i cant check those, i just broke your packet dumps up abit.
Do some more logs, and write down what state the lobby was in at the time the log was cought, then check the values out, 1 by 1.

Also depending how many players can join a war3 game (idk), the end of the last packet maybe containing 8 empty null strings (1 for each possible player?)
[code]
f3 a5 00 03 0c 02 02 00 76
0f 45 a9 12 07 00 00 00 00 00 00 00 00 <-
[/code]

Hope this helps.

[quote author=rabbit link=topic=14436.msg149402#msg149402 date=1143740171]
IIRC all of the games use UDP.  The packets Topaz posted are on BnetDocs anyway.
[/quote]

Not Diablo II and Warcraft III

I found this in some old notes:

(BYTE) Player id
(BYTE) Map download percent (0x64 for custom, 0xff for ladder)
(BYTE) Slot status (0 empty, 1 closed, 2 used)
(BYTE) Player flags (0 for human, 1 for computer player)
(BYTE) Team number (0 - 11, 12 is observer or referee)
(BYTE) Color (0-11, red, blue, cyan, purple, yellow, orange, green, pink, gray, light blue, dark green, brown, color 12 = observer or referee)
(BYTE) Race (0x01=human, 0x02=orc, 0x04=night elf, 0x08=undead,  0x20=random, 0x40=race set by map default)
(BYTE) Computer AI (0-easy, 1-normal, 2-insane, non-AI players this should be 1)
(BYTE) Handicap value (0x32, 0x3C, 0x46, 0x50, 0x5A, 0x64)

For chat messages (in-game, not lobby, this may have changed):

(BYTE) Player id
(WORD) Number of bytes that follow
(BYTE) Flags (0x10 - rarely seen, sometimes at startup; 0x20 for normal message)
(DWORD) Chat mode (not present if flags = 0x10. 0x0-all players, 0x1-to allies, 0x2-to observers or referees, 0x3+ID=message to specific player, ID being slot number)
(STRING) Chat message

Well going by what UL said above, I seperated up the packet linked as follows:
[code]
f7 04 8a 00 73 00 0c

00 ff 02 01 00 00 04 01 64
01 64 02 00 00 01 04 01 64
00 ff 00 00 00 02 04 00 64
00 ff 01 00 00 03 04 00 64
00 ff 01 00 00 04 04 00 64
00 ff 01 00 00 05 04 00 64
00 ff 02 01 01 06 08 01 64
00 ff 01 00 01 07 08 00 64
00 ff 01 00 01 08 08 00 64
00 ff 01 00 01 09 08 00 64
00 ff 01 00 01 0a 08 00 64
00 ff 01 00 01 0b 08 00 64

37 f3 a5 00 03 0c 02 02 00
76 0f 45 a9 12 07 00 00 00
00 00 00 00 00
[/code]

Its important to note that the player id field there is not a unique identifier which is the logical assumption, atleast in my mind.  I also do not understand the Map download percent beign 0x64 or 0xFF.  Does 0xFF denote that a download did not take place and 0x64(100 in decimal) represent that the user downloaded the map and the download was completed?

I would assume that 0xff means the user already has the map and does not have anything displayed, whereas 0x64 (and below) would be the percentage of the map downloaded.

[quote author=rabbit link=topic=14436.msg149442#msg149442 date=1143767092]
I would assume that 0xff means the user already has the map and does not have anything displayed, whereas 0x64 (and below) would be the percentage of the map downloaded.
[/quote]

Yes, something like that