Hi all.
Honustly... iv have no idea on how ethereal works etc.
Im wanting to be able to read the information captured by ethereal, so i know what packets to send/reply to from the server.

I really have no idea where to look for the packet ID (eg; 0x90).

Heres a picture of what ethereal captured in 5seconds.
Im hoping someone will be able to point out where to look for the packet ID and how to tell what it is etc.

[url]http://netblues.org/raven/ethereal.JPG[/url]

Thanks in advance.

I can tell you that the packet you selected is NOT a battle.net packet.

You click on the packet you want to examine and you click on a portion that says "data" or something of the like. Then you examine the packet all you want.

You will not get WPE-type logs with Ethereal (AFAIK).

The data portion (on a bnet packet) will have:
[code]
FF [PID] [LOW LENGTH BYTE] [HIGH LENGTH BYTE]
[/code]

So look for a FF at the very beginning of the data segment, not the TCP headers. The packet id will be right after it.

Battle.net packets are also always to port 6112.

Captured packets 1, 2 and 3 are battle.net packets.

You might want to be reading the packets with information denoted "Data" as opposed to control packets.

I do know that the packets i selected at not Bnet packets.
Im actually wanting packets from something else.
Iv tried to follow what you said but i cant find anything understandable?

Iv included another screenshot of what i clicked etc.
[url]http://www.netblues.org/raven/ethereal2.JPG[/url]

[quote author=Shout link=topic=12006.msg117874#msg117874 date=1119967311]
The data portion (on a bnet packet) will have:
[code]
FF [PID] [HIGH LENGTH BYTE] [LOW LENGTH BYTE]
[/code]
[/quote]
Before answering the question at hand, I wanted to point out that this is wrong (for anyone else who might read this later).  Battle.net encodes integral values larger than a byte in little-endian order, which means the low byte for length is first, and the high byte is second.

[quote author=WiLD link=topic=12006.msg117955#msg117955 date=1119997166]
I do know that the packets i selected at not Bnet packets.
Im actually wanting packets from something else.
Iv tried to follow what you said but i cant find anything understandable?

Iv included another screenshot of what i clicked etc.
[url]http://www.netblues.org/raven/ethereal2.JPG[/url]
[/quote]
What exactly do you want to know?  That part that you have selected is the packet data that the application will process.  You'll need to be more specific if you want to know more.

Ooops and thanks MyndFyre!

[quote author=MyndFyre link=topic=12006.msg117977#msg117977 date=1120001454]
[quote author=Shout link=topic=12006.msg117874#msg117874 date=1119967311]
The data portion (on a bnet packet) will have:
[code]
FF [PID] [HIGH LENGTH BYTE] [LOW LENGTH BYTE]
[/code]
[/quote]
Before answering the question at hand, I wanted to point out that this is wrong (for anyone else who might read this later).  Battle.net encodes integral values larger than a byte in little-endian order, which means the low byte for length is first, and the high byte is second.
[/quote]

Just nitpicking but would probably be better to say "high byte is last" instead of "high byte is second." Within context is sounds fine though ;)

[quote author=dxoigmn link=topic=12006.msg118022#msg118022 date=1120022781]
[quote author=MyndFyre link=topic=12006.msg117977#msg117977 date=1120001454]
[quote author=Shout link=topic=12006.msg117874#msg117874 date=1119967311]
The data portion (on a bnet packet) will have:
[code]
FF [PID] [HIGH LENGTH BYTE] [LOW LENGTH BYTE]
[/code]
[/quote]
Before answering the question at hand, I wanted to point out that this is wrong (for anyone else who might read this later).  Battle.net encodes integral values larger than a byte in little-endian order, which means the low byte for length is first, and the high byte is second.
[/quote]

Just nitpicking but would probably be better to say "high byte is last" instead of "high byte is second." Within context is sounds fine though ;)
[/quote]
High byte is last in any little-endian context though, no?

[quote author=MyndFyre link=topic=12006.msg118024#msg118024 date=1120024554]
High byte is last in any little-endian context though, no?
[/quote]

True, it just sounded weird to me.

[quote author=MyndFyre link=topic=12006.msg117977#msg117977 date=1120001454]
[quote author=WiLD link=topic=12006.msg117955#msg117955 date=1119997166]
I do know that the packets i selected at not Bnet packets.
Im actually wanting packets from something else.
Iv tried to follow what you said but i cant find anything understandable?

Iv included another screenshot of what i clicked etc.
[url]http://www.netblues.org/raven/ethereal2.JPG[/url]
[/quote]
What exactly do you want to know?  That part that you have selected is the packet data that the application will process.  You'll need to be more specific if you want to know more.
[/quote]

I want to know what the packet ID(data, type, number or whatever it is :S) is that iv recieved or sent. For example... where do you get the packet ID "0x25" out of ethereal? Where do you look and what do you do to know that you sent/recieved "0x25"?

Sorry for all this misunderstanding, a said before.... iv never used ethereal nor any other packet logger. I would normally just goto bnet docs if it were to do with bnet, but its to do with another application/game.

Do you want to read BNCS packets or not, because you said you didn't.  Not every protocol uses packet ID's.
[img]http://www.rabbitsoftware.net/images/bncspid.PNG[/img]
Blue = 0xff (BNCS packets all begin with this)
Red = 0x?? (This is the ID of the packet)
Green = 0x???? (This is the size of the packet, including the header)

A 3174182350ms ping!?

You may be interested in "follow TCP stream". It's under one of the menus.

[quote author=Shout link=topic=12006.msg118090#msg118090 date=1120084765]
A 3174182350ms ping!?
[/quote]

They use to send GetTickCount() there...

Thanks rabbit, that definitly helped a lot!
Would all packets be in that same spot/part? (at the end like in the pic)

Incase i have not mentioned it yet, my use of this has nothing to do with battle.net or blizzard games. Its actually to do with a MMORPG called Nexus, which can be found at www.nexustk.com.

At the time being i just want to see what is sent and recieved when you connect to the server.

I used to play that :)  Very fun.  Like I said, the header will always be the same for BNCS packets, but not for every packet.  You'll have to figure out hot NTK protocol works.

[quote author=WiLD link=topic=12006.msg118180#msg118180 date=1120131876]Thanks rabbit, that definitly helped a lot!
Would all packets be in that same spot/part? (at the end like in the pic)

Incase i have not mentioned it yet, my use of this has nothing to do with battle.net or blizzard games. Its actually to do with a MMORPG called Nexus, which can be found at www.nexustk.com.

At the time being i just want to see what is sent and recieved when you connect to the server.[/quote]

Starting a packet with FF <code> <length> is a convention used by Battle.net, and probably won't be found in other games.

Whoever manufactures the game chooses their own protocol, whether it's a binary one like Battle.net, a text-based on like HTTP, etc.  There is no standard for having a "packet id".

To find out how it works, you have to look at a pile of packets.  See what they have in common, and what's different.  If there's no obvious pattern, and everything changes, then it's possible that it's an encypted or compressed protocol.  You can use programs to check the data's entropy which might tell you if it's compressed, but I can't remember what they're called.

If there is no obvious pattern (Battle.net patterns are usually pretty easy to figure out), and you suspect it's encrypted or compressed, then you will probably have to do some reverse engineering.  Disassemble or debug the program and find calls to send()/sendto()/etc. and recv()/recvfrom()/etc., then backtrace from send() or trace forward for recv() to find out where the data is coming from.

Hope that helps.

[Kp edit: changed [] to <> so that iago's message wouldn't be in code tags.]

[iago edit: haha, stupid me.  Thanks :P]

Also I'm pretty sure NTK uses UDP, so good luck with that ;)

[quote author=rabbit link=topic=12006.msg118726#msg118726 date=1120443173]
Also I'm pretty sure NTK uses UDP, so good luck with that ;)
[/quote]

That doesn't really change anything.  But that's why I said "recv()/recvfrom()" instead of just "recv()" -- I noticed in his screenshot that it was UDP.

Yeah, but UDP is a bit trickier for MMORPG because you can recieve a lot of packets in a lot of different orders (as opposed to TCP server<->client where it's usually a single stream).

You still receive packets in some order.  You can send a lot of packets on TCP, or very few packets on UDP.  The trickiness depends on the protocol implemented by the game, not on whether it's TCP or UDP.  TCP/UDP makes very little difference.

Well, in an MMORPG, where people generally want things like economy tracked, a P2P UDP environment would be more harmful than helpful IMO.  It would pave the way for cheating.  Plus, it'd be many times more complex for the client logic.  Rather, only the server has to be powerful to understand everything that's coming in and then relay the result to the client or clients.

I don't think it would be possible to have a P2P MMORPG, since people are always coming and going and there is waay to much stuff for every user to proces. 

Thanks for that iago for that long post of yours. Thats exactly what i needed.

I guess ill start going through some logs shortly. I just need to weed out all the other crap, such as chat clients, games etc.... as i dont know what the server IP is.

Thanks again.

If you know the ports, you can apply a filter; for example, to only show traffic that uses port 6112:
tcp.port = 6112

[quote author=iago link=topic=12006.msg119642#msg119642 date=1120829133]
If you know the ports, you can apply a filter; for example, to only show traffic that uses port 6112:
tcp.port = 6112

[/quote]

More generally, just port = 6112 will work (as you'll get UDP traffic on port 6112 as well).

[quote author=MyndFyre link=topic=12006.msg119680#msg119680 date=1120841323]
[quote author=iago link=topic=12006.msg119642#msg119642 date=1120829133]
If you know the ports, you can apply a filter; for example, to only show traffic that uses port 6112:
tcp.port = 6112

[/quote]

More generally, just port = 6112 will work (as you'll get UDP traffic on port 6112 as well).
[/quote]

Good point.  I avoided saying "right click, then click 'follow TCP stream'" for that reason, and then made the exact same mistake.  *slaps himself*

Right click and follow tcp stream is still a good idea to sort out what's various files downloading and what's data for the actual logon. You just need to be aware that you're filtering things out by doing it :)

Will that work on a UDP "connection"?  I guess if it filters by source/destination port/ip, it'll work on UDP too.

I don't think so. You can select parts of the udp packet headers and use as filters to quickly pick out the packets from/to a particular port though.