Tibia Wireshark 2.5.0 nightly now has Tibia support

[.: Strike :.]

Download for Windows and macOS: https://www.wireshark.org/download/automated/, On Linux you'll have to compile current Wireshark master branch yourself till there's an official release (Summer 2018). See here for more info.


Wireshark is a very popular network analyzer. It sniffs what happens on your network and attempts to display it in text form:

And now it has Tibia support. So you can, in theory[1], start up any Tibia client from 7.0 to the current one and see in real-time what messages it exchanges with the server it connects to.

What can you do with it? It helped me turn a Tibia client into a chess client:

I've used it to analyze bugs exploited by players on a closed-source OTServ. And to analyze mage bot logins in order to block them.

I hope it makes the barrier of entry for custom Tibia tools lower, write your own custom Tibia server, write a bot for a locally hosted OTServ to learn more about algorithms or analyze what your Tibia client sends to the server and maybe make a loot HUD? You can decide yourself what you want to build with it!

You can easily extend Wireshark dissectors with your own Lua scripts, so you could offload sniffing, key-handling and decryption to Wireshark and write a Lua script that does something with the game commands.

A brief overview of the dissector and the protocol is given here:
Tibia-Wireshark-Plugin/packet-tibia.c at wireshark-merge · a3f/Tibia-Wireshark-Plugin · GitHub

[1]: Tibia is encrypted since 7.7. You would need to supply a XTEA key only you and the server know while you are logged in or a private key only the server has to decrypt the packet. Most OpenTibia servers use the same private key, which is therefore no longer private and can be analyzed directly now in Wireshark. Otherwise, you can supply the session key and dissect even real Tibia traffic.

 

[.: Strike :.]

Joined: Mar 8, 2008

Wow, I've been doing this for way too long ^^'

 

[Zistonick]

Wow Its looks really nice!

Can you give us a little explanation on how you did the chess?

 

[.: Strike :.]

Wow Its looks really nice!

Can you give us a little explanation on how you did the chess?

Sure. I went to a chess board with my character, put some magic light wands to make it brighter. Then I relogged. When I logged in again, the tibia server sends you a big packet with all the map data. In Wireshark, you can see it unencrypted now, and export it to a file with a right click, which I did. After that I wrote a small perl script that handles character login and just send the map file to connecting clients.

Now back to my tibia character, I moved chess pieces and looked at the commands Wireshark decodes. Then I implemented the Tibia protocol commands for remove item, put item, write "Sorry, not possible" status and say text in my perl script.

That's all you need for the user interface. The rest was checking if moves are valid and determining who won.

 

[Zistonick]

Sure. I went to a chess board with my character, put some magic light wands to make it brighter. Then I relogged. When I logged in again, the tibia server sends you a big packet with all the map data. In Wireshark, you can see it unencrypted now, and export it to a file with a right click, which I did. After that I wrote a small perl script that handles character login and just send the map file to connecting clients.

Now back to my tibia character, I moved chess pieces and looked at the commands Wireshark decodes. Then I implemented the Tibia protocol commands for remove item, put item, write "Sorry, not possible" status and say text in my perl script.

That's all you need for the user interface. The rest was checking if moves are valid and determining who won.

That sounds really interesting. I Will give a look as soon as posible.

Thanks for your reply!

 

[River KA]

What you can do with that?
Just sniffing or you can edit values?
I didn'

 

[River KA]

Shit, I can't edit my post.

So, finishing my previous post:
"I didn't understand where is the good part of the Wireshark with Tibia. Could you explain it?"

 

[.: Strike :.]

That sounds really interesting. I Will give a look as soon as posible.

Glad to hear. Wish you fun with it!

"I didn't understand where is the good part of the Wireshark with Tibia. Could you explain it?"

Wireshark is for traffic analysis, it doesn't modify the packets itself, but it makes it easier to write tools that do. I listed some examples of tools I wrote with help of the dissector in the first post.

 

[Zistonick]

Do I have to download something else besides the latest version of wireshark? I downloaded de latest versión and I only get a frame from the server and a frame from the client. I also dont have the protocol preferences like your picture.

 

[.: Strike :.]

The latest nightly release from https://www.wireshark.org/download/automated/

Maybe the game server isn't at port 7171 or 7172, so Wireshark doesn't dissect its TCP packets as Tibia packets?

You can right-click a TCP packet that should be dissected as a Tibia packet, choose "Decode As.." and it should fill out the field and value with the TCP Port, then choose current protocol "Tibia". This will affect all packets from that connection/port.

You can also access protocol preferences from the general preferences (I think Edit->Preferences->Protocols->Tibia). There you can also set global TCP Ports that will always be treated as Tibia ports.

 

[Zistonick]

I have this wireshark version: Wireshark-win64-2.5.0-946-gb9746b6833.

And the game server is a port 7171, 7172. Im running my otserv on another machine in the same LAN, can it affect to Wireshark?

 

[Zistonick]

I cant edit my post, I realize that I did not put the XTEA key, can it be the problem?

If it is the problem, where can i get that XTEA key?

 

[.: Strike :.]

I have this wireshark version: Wireshark-win64-2.5.0-946-gb9746b6833.

And the game server is a port 7171, 7172. Im running my otserv on another machine in the same LAN, can it affect to Wireshark?

Yes, that version is ok. In a switched LAN, the switch avoid sending stuff your way that's not destined for you. You can:

• Start a client, connect to your OT and see only this one connection in Wireshark
• Start Wireshark on the same machine as the OT and maybe control it over VNC or SSH/X11
• Record a *.pcap file on the server and transfer it to your computer. There is a tshark console utility that you can use without GUI
• Try Wireshark remote capture (I haven't, so no idea how it works)
• Buy a network TAP or a switch with a mirror port to get all OT traffic to your PC too

I would suggest option 2

I cant edit my post, I realize that I did not put the XTEA key, can it be the problem?

If it is the problem, where can i get that XTEA key?

If you didn't change the RSA key of the OT, you don't need to supply the XTEA key.

When a Tibia client connects to a server it encrypted a randomly generated XTEA key with the RSA key along with the login data. So iether, you specify the XTEA key for one client or the private RSA key for one server. The standard RSA private key is hardcoded (Try OTServ RSA key option), so you don't need to mess with it unless you wan to decode real Tibia traffic or traffic for servers that use custom clients with different RSA keys.
In these clients, you will need to either do a Man-In-The-Middle attack or know where the XTEA key is stored in memory. But as I said, for normal OTServ you can just ignore it.

 

[.: Strike :.]

I want to clarify that game protocol support is (and will most probably remain) incomplete. So you will see the decrypted bytes of, say, a Tibia market transaction but it won't be decoded to (Item, Price, Amount) or whatever. Tracking all protocol changes between 2001-2017 is not something I want to spend my time on. You can turn off game protocol dissection and just write Lua scripts that decode the decrypted Tibia traffic however you see fit if you like.

Also, I said in the commit message that Tibia 11.42 is supported. This is incorrect. Maximum supported version is Tibia 11.00 at the moment, but I will try to add Tibia 11.42+ support when I have more time.

 

[Zistonick]

I finally downloaded npcap and opened the server on the same machine. With npcap you can capture loopback traffict on localhost and see what is happening betwen client and server

 

[e.e]

Since my particular problem addressed in this thread is solved I thought we should maybe move the conversation here.

Did you compile it yourself? I just tested the 64 builds for macOS and Windows and both have GnuTLS bundled and therefore the RSA Key List option.

If you're on Linux and compiling yourself, you need to install GnuTLS before building. e.g. on debian with:

sudo apt install libgnutls28-dev

That worked! Now I can use the "RSA keys list..." option!

As long XTEA key and payload are of correct size, decryption can't fail. We can check the reported length after decryption though and if it's bigger than the number of bytes in the packet for real, something is wrong. That's what the error message means.

The option works if you supply the XTEA key in the same byte order it was in the login packet. I would guess you ran into endianness issues. You can copy the XTEA key out of the login packet from Wireshark GUI and paste it direcrtly into the XTEA keys UAT and check if that indeed was the case, or if it was a bug that could be fixed.

I think I don't know enough about this subject to understand what you're saying here
I don't even know what UAT is. I've only used wireshark and done network dumps a few times and sparsely so.

But in short: I could successfully decrypt all communication with my server using your PEM key, so my particular problem in my thread is completely solved

However I still have issues with decrypting traffic without the RSA key; it looks like the XTEA key I get from OTC by printing out the m_xteaKey array with format %x differs (completely) from the XTEA key that wireshark/your extension displays after successful decryption by using the correct RSA key, so I must be confused/doing something wrong.
OTC provides: 25467ec42992d45a82e9188438e7e2d1
And Wireshark: c47e46255ad492298418e982d1e2e738
And a completely different XTEA key is also shown through Wireshark for packets to and from the login server.

Also after decryption using an RSA key most of the command identifications are completely wrong, at least for protocol 7.72 (tested on someone's OT - I stand still and do nothing and wireshark shows hundreds of walking commands, rotating items, following, etc) :/

But I love the idea of this tool/extension!

 

[e.e]

Or I wrote "doing nothing" at the end there, but to be perfectly accurate I attack a few rotworms that are moving towards me using battle. That's it though.

 

[.: Strike :.]

I think I don't know enough about this subject to understand what you're saying here
I don't even know what UAT is. I've only used wireshark and done network dumps a few times and sparsely so.

Ah, sorry. An UAT is an user accessible table. Like the RSA Key list and XTEA key list options.

OTC provides: 25467ec42992d45a82e9188438e7e2d1
And Wireshark: c47e46255ad492298418e982d1e2e738

Endianness means, which end comes first of a number. With Arabic numerals a thousand is written as 1000. The highest valued digit (The 1) is the first one, so this is big endian (The biggest come first). You could also write is as 0001 and call it little endian, but you don't do that with Arabic numerals, but you do with computer integers. So when you transfer more than one byte of the same thing, you have to think about which end comes first .
Conversion is straight forward though: Just swap the positions.
So for hexadecimal (Remember 1 byte = 2 hexadecimal digits, so we swap every 2 consecutive digits)
25 46 7e c4 becomes c4 7e 46 25 and so on for the remaining 3 integers in the XTEA key.

That's why there are different values. It depends how they are stored internally and how you choose to represent them. My Wireshark dissector shows the bytes in the same order as in the login packet.

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

The first packet to the login server isn't XTEA encrypted, but RSA-encrypted. The response is XTEA-encrypted. Would you be able to take a capture like I described in the other thread, so I can verify 7.70 support works?

Also after decryption using an RSA key most of the command identifications are completely wrong, at least for protocol 7.72 (tested on someone's OT - I stand still and do nothing and wireshark shows hundreds of walking commands, rotating items, following, etc) :/

Keeping up with login/framing changes between Tibia 7.00 and Tibia 11.00 is hard enough (I still have to implement 11.01-11.54 support), but tracking all game command changes across 16 years is not something I want to spend my time on. Wireshark comes with a Lua engine and you can disable Game command dissection and write Lua scripts that do whatever you want. That would be a possibility

But I love the idea of this tool/extension!

Glad to hear.

 

[e.e]

Ah, sorry. An UAT is an user accessible table. Like the RSA Key list and XTEA key list options.

Ok.

Endianness means, which end comes first of a number. With Arabic numerals a thousand is written as 1000. The highest valued digit (The 1) is the first one, so this is big endian (The biggest come first). You could also write is as 0001 and call it little endian, but you don't do that with Arabic numerals, but you do with computer integers. So when you transfer more than one byte of the same thing, you have to think about which end comes first .
Conversion is straight forward though: Just swap the positions.
So for hexadecimal (Remember 1 byte = 2 hexadecimal digits, so we swap every 2 consecutive digits)
25 46 7e c4 becomes c4 7e 46 25 and so on for the remaining 3 integers in the XTEA key.

That's why there are different values. It depends how they are stored internally and how you choose to represent them. My Wireshark dissector shows the bytes in the same order as in the login packet.

Hmm, alright.
I understand the first part, and I did try switching the XTEA key(s) initially when I was trying to use just the XTEA key(s) to decrypt the traffic, but I don't understand the last two lines or how the values can be so different at the end, I mean I don't think that's a viable explanation in this case? or at least I don't understand how it is.

The first packet to the login server isn't XTEA encrypted, but RSA-encrypted. The response is XTEA-encrypted.

Well, I agree with you that it's (as far as I understand too - how could it be) not encrypted yet, but it looks to me that an XTEA key is at least offered?

Frame 4: 199 bytes on wire (1592 bits), 199 bytes captured (1592 bits)
Raw packet data
Internet Protocol Version 4, Src: 10.16.0.12, Dst: *removed*
Transmission Control Protocol, Src Port: 47440, Dst Port: 7171, Seq: 1, Ack: 1, Len: 147
Tibia Protocol
    Packet length: 145
    Command: Charlist request (0x01)
    Operating system: Windows (0x0002)
    Protocol version: 772
    File versions
    Symmetric key (XTEA): a814bc5a3deebd4a39dc4fcaeb4a8883
    Account: *removed*
    Password: *removed*
    Data (99 bytes)

Would you be able to take a capture like I described in the other thread, so I can verify 7.70 support works?

Sure, I'll make a post there, but note that in this case I was using the 7.72 protocol.

Keeping up with login/framing changes between Tibia 7.00 and Tibia 11.00 is hard enough (I still have to implement 11.01-11.54 support), but tracking all game command changes across 16 years is not something I want to spend my time on. Wireshark comes with a Lua engine and you can disable Game command dissection and write Lua scripts that do whatever you want. That would be a possibility

That's very understandable of course
I just wanted to share to in case something was wrong on my end there.
I was thinking for a moment that maybe the false positives could be eliminated too, but for that you'd still need to know exactly when the protocols differ and when not, so I can understand if this is too much work as well.
Is there a way we could contribute to this using OTC source code or something as an easy reference?

 

[e.e]

I also wanna say that I'm fully aware that there's many potential holes in my understanding that may be causing me to not understand what's going on there with the different XTEA keys, me failing to decrypt traffic from XTEA keys, etc, and I'm not trying to argue, just trying to understand how this works so I can everything working and possibly contribute as well in the future.