Reading Ethereal?

[WiLD]

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.

[R.a.B.B.i.T]

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.

[iago]

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.

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 ]

[R.a.B.B.i.T]

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

[iago]

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

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.

[R.a.B.B.i.T]

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).

[iago]

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.

[MyndFyre]

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.

[iago]

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. 

[WiLD]

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.

[iago]

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

[MyndFyre]

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

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

[iago]

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

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

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

[Adron]

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

[iago]

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