Tibia Wireshark 2.5.0 nightly now has Tibia support

[.: Strike :.]

The XTEA key as shown in Wireshark has the same byte order as in the packet. Let's see what OTClient does with it:

c4 7e 46 25 5a d4 92 29 84 18 e9 82 d1 e2 e7 38                         # 16 bytes, as in the Wireshark key
c4 7e 46 25        5a d4 92 29         84 18 e9 82        d1 e2 e7 38   # turn into array of 4 integers
25 46 7e c4        29 92 d4 5a         82 e9 18 84        38 e7 e2 d1   # swap byte order of each integer, this is same as in OTClient

You can convert between both representations with this snippet:

echo "c4 7e 46 25 5a d4 92 29 84 18 e9 82 d1 e2 e7 38" | sed -es/^/0:/ | xxd -r | xxd -g4 -e

but it looks to me that an XTEA key is at least offered

Yes, the client generates a random XTEA key and sends it over the line RSA-encrypted. You can copy the XTEA key as shown in Wireshark and add it to the XTEA key list for dissection.
I think I misunderstood your

And a completely different XTEA key is also shown through Wireshark for packets to and from the login server.

as meaning there's a different key displayed in the login packet and the subsequent packets.

I was using the 7.72 protocol

Aha. I have tested version 7.72. I will have to test 7.70 and 7.71, because at least one of them seems to differ in which fields are RSA-encrypted and which aren't.

Is there a way we could contribute to this using OTC source code or something as an easy reference

Some information about when commands changed (The same command ID being used for different things across versions) would be helpful to avoid the false positives.
But I am not sure how often (if at all this occurred). Anything else, I think should be written in Lua by users for their specific use case instead.

just trying to understand how this works so I can everything working and possibly contribute as well in the future.

 

[e.e]

The XTEA key as shown in Wireshark has the same byte order as in the packet. Let's see what OTClient does with it:

c4 7e 46 25 5a d4 92 29 84 18 e9 82 d1 e2 e7 38                         # 16 bytes, as in the Wireshark key
c4 7e 46 25        5a d4 92 29         84 18 e9 82        d1 e2 e7 38   # turn into array of 4 integers
25 46 7e c4        29 92 d4 5a         82 e9 18 84        38 e7 e2 d1   # swap byte order of each integer, this is same as in OTClient

You can convert between both representations with this snippet:

echo "c4 7e 46 25 5a d4 92 29 84 18 e9 82 d1 e2 e7 38" | sed -es/^/0:/ | xxd -r | xxd -g4 -e

Omg, of course, each segment has to be flipped! Haha, I'm so silly
Now I see they match!

Yes, the client generates a random XTEA key and sends it over the line RSA-encrypted.

Aha, yes precisely!

You can copy the XTEA key as shown in Wireshark and add it to the XTEA key list for dissection.

Hmm...
I was still having trouble with this, or so I thought, but I just realized that it partially works, I just didn't notice before.
For some reason the initial client packet is not decrypted and as a result the account login info is not decrypted and naturally not available for display in the following packets either :\
Maybe I've supplied the wrong packet id? The only thing that seems to have worked for me so far is to specify the id of the initial client packet sent to the respective servers.

I think I misunderstood your
as meaning there's a different key displayed in the login packet and the subsequent packets.

There is as far as I can tell.
Ah, I knew I probably should have shown the XTEA key in the login packet the first time, I shouldn't have been so lazy.

In my latest capture (7.72, but same applies for my 7.7 server):
XTEA key shown for login server packets: 7e9efdaf369a4be11652b776d2df1da1
XTEA key shown for game server packets: e77bd565ddbf9baadd31441d216a29c3

And indeed I could only decrypt the respective traffic (minus the initial data packet) by supplying each of these keys.
I.e. the game server XTEA key only decrypted the game server traffic (minus initial data packet).

Aha. I have tested version 7.72. I will have to test 7.70 and 7.71, because at least one of them seems to differ in which fields are RSA-encrypted and which aren't.

Yes.
I just tried to make a pcap according to your request, but either the pem file you provided me earlier never worked and I never realized it or it's stopped working
I thought it worked because wireshark in my 7.7 instance says "Data" instead of "RSA encrypted data", and it's still displaying "Command" etc.
I'm not sure.
Well, I'll upload the capture anyway, here: http://zanera.realots.org/zanera.pcap

Some information about when commands changed (The same command ID being used for different things across versions) would be helpful to avoid the false positives.
But I am not sure how often (if at all this occurred). Anything else, I think should be written in Lua by users for their specific use case instead.

Hmm. Ok.

 

[.: Strike :.]

Well, I'll upload the capture anyway, here: http://zanera.realots.org/zanera.pcap

Thanks for the capture. I'll update the dissector when I've time (next month probably) for proper 7.70-7.71 support.
Your capture helped me find a more serious bug: The method I use to differentiate between server and client packets is flawed. That's probably the reason, why the game commands are wrong*.

[*]: Some more info: In a TCP connection, you have a fixed server port (e.g. 7171/7172) and a random client port chosen by the TCP/IP stack. I thought the IANA recommendation of using port numbers bigger than 0xc000 (49,152) for client ports is followed universally, but your capture shows this is not true.

 

[kito2]

Great!

 

[Codinablack]

Holy Sh*t! This is a game changer! How does this thread not have more views and replies!

 

[moekl]

How hard would it be to spot a Rsa Key From OTclient
or is this just supporting the original Clients.