• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

[11.50+] An Easier Way To Teleport

jo3bingham

Excellent OT User
Joined
Mar 3, 2008
Messages
1,103
Solutions
14
Reaction score
772
GitHub
jo3bingham
Prologue
I want to preface this post by making a few statements:
  1. I am, more-or-less, out of the OT development circuit. What I mean to say is, while I'm not actively working on a server, or actively engaging in the community, I still visit the forums and try to help those who seek out my advice. And now I've decided to give back to the community even more by way of providing game mechanics that no server uses, or, at least, hasn't been made public (to my knowledge). So expect more of these posts in the future.
  2. I still sit down after every "major" update that CipSoft has to work out new packets, and changes to any existing ones. This is how the OX team was/is able to keep our map up-to-date (among other things). Yes, that means that I have every packet structure worked out as of the latest version (which is currently 12.3x). Even though I'm no longer working on a server, I still like to do this for personal reasons (I find it fun). For those interested, our tracking software is not based on SharpMapTracker. I wrote a new API upon .NET Core which allows it to be much faster than SMT, and cross-platform. I won't go into more detail here, but I'm happy to answer any questions for those interested. HOWEVER, neither the API, nor the code, will be made available to anyone (not even for a price), so please don't ask.
An Easier Way To Teleport?
What do you mean an easier way to teleport? What could be easier than opening RME, finding the location, copying the coordinates, and using a talkaction in the client to teleport there?! Well, along with the 2017 Winter Update (11.50) CipSoft added a new client packet called Teleport. Obviously, with a name like that, I was quite curious as to what this packet was for, and, more importantly, how to trigger it. To be fair, it took me quite some time to figure it out, and only because I had an "aha!" moment that led to it. I remembered that you could hold down the Shift key and then left-click with your mouse on the Cyclopedia map to walk to that position. So I started playing with key combinations until my API alerted me that it finally had an instance of the Teleport packet. The combination? Ctrl+Shift+Left-Click. Oh, and this also works with the minimap as well.

Packet Structure and Use
The opcode for this client packet is 0x73, and the only data it contains is the coordinates of the position you clicked at:
C++:
void ProtocolGame::parsePacket(NetworkMessage& msg)
{
    ...
    case 0x73: parseTeleport(msg); break;
    ...
}

void ProtocolGame::parseTeleport(NetworkMessage& msg)
{
    auto pos = msg.getPosition();
    addGameTask(&Game::playerTeleport, player->getID(), pos);
}
C++:
void Game::playerTeleport(uint32_t playerId, const Position& pos)
{
    auto* player = getPlayerById(playerId);
    if (!player || !player->isAccessPlayer()) {
        return;
    }

    auto ret = g_game.internalTeleport(player, pos, false);
    if (ret != RETURNVALUE_NOERROR) {
        player->sendCancelMessage(ret);
    }
}

Notes
  • This only works on 11.50 clients and newer.
  • This works with both the Cyclopedia map and the minimap. Obviously, using the Cyclopedia map will only work on your server if you're using an RL map AND your coordinates are 1:1. I'm sure it's possible to create your own Cyclopedia map based on your server and force the client to load it instead, but I've never done it.
  • The code example above doesn't contain the function definitions for the corresponding header files. If you don't know how to do that yourself then you need to learn C++ before you go any further.
 
Last edited:
I always enjoy reading any of your stuff, great job and thanks for this piece of code.
 
Nice contribution! Btw, do you have the API avaiable to other people find out their packets?

Edit: Skipped half of the 2nd point and went directly to code... After reading I saw you wont make avaiable.

I'm just starting in the OT scene (actually been out of tibia for 10~ years), but with ton of c++/reverse enginering in my baggage... Found out about otservBR-Global and now I'm trying to trace out functions on the 12.x clients that's missing on their servers... But IDK how to proceed with a simple API to get all packets sent... Already hooked up wireshark to a client but seems like packets are encrypted or something like it.

Any tips?
 
Last edited:
Nice contribution! Btw, do you have the API avaiable to other people find out their packets?

Edit: Skipped half of the 2nd point and went directly to code... After reading I saw you wont make avaiable.

I'm just starting in the OT scene (actually been out of tibia for 10~ years), but with ton of c++/reverse enginering in my baggage... Found out about otservBR-Global and now I'm trying to trace out functions on the 12.x clients that's missing on their servers... But IDK how to proceed with a simple API to get all packets sent... Already hooked up wireshark to a client but seems like packets are encrypted or something like it.

Any tips?
Does not seem like you have "ton" of reverse engineering in your "baggage" then
 
12.x...

Does not seem like you have "ton" of reverse engineering in your "baggage" then
I've successfully developed and comertialized a fully functional bot for another MMORPG for couple of years... Fully internal and such. I've got the knowledge and not the time to rewrite everything from scratch or try to reinvent the wheel. If someone has the tools already built, there is no need to write them again, right? When I said "I just started" I meant I started couple hours ago. Since that post I've already reversed some of the network functions from 12.x, but since I dont have the "baggage" of years of tibia packet sniffing I might be letting some stuff pass by...

I don't need to prove myself to you tho :) just asking for OP advice (or yours, since you might have years of OT programming/reversing aswell)

Thanks
 
12.x...


I've successfully developed and comertialized a fully functional bot for another MMORPG for couple of years... Fully internal and such. I've got the knowledge and not the time to rewrite everything from scratch or try to reinvent the wheel. If someone has the tools already built, there is no need to write them again, right? When I said "I just started" I meant I started couple hours ago. Since that post I've already reversed some of the network functions from 12.x, but since I dont have the "baggage" of years of tibia packet sniffing I might be letting some stuff pass by...

I don't need to prove myself to you tho :) just asking for OP advice (or yours, since you might have years of OT programming/reversing aswell)

Thanks
No, you wont find any ready to use full packet structure of everything, no one shared that and no one will probably. For someone who is good at reverse engineering (packet sniffing and stuff) it should be no big deal to obtain them in couple hours. All you can look at is otservbr, but I think you mentioned it already?
 
Nice contribution! Btw, do you have the API avaiable to other people find out their packets?

Edit: Skipped half of the 2nd point and went directly to code... After reading I saw you wont make avaiable.

I'm just starting in the OT scene (actually been out of tibia for 10~ years), but with ton of c++/reverse enginering in my baggage... Found out about otservBR-Global and now I'm trying to trace out functions on the 12.x clients that's missing on their servers... But IDK how to proceed with a simple API to get all packets sent... Already hooked up wireshark to a client but seems like packets are encrypted or something like it.

Any tips?
The first packet the client sends to the game server is partly RSA-encrypted, and the RSA-encrypted portion contains the XTEA key that will be needed to decrypt subsequent packets. Those packets are XTEA encrypted starting at the 7th byte until the end. I took the easy way out by modifying the RSA key inside the client to that of the Open-Tibia public RSA key, modified the loginWebService to localhost, then wrote a proxy to handle the traffic between the client and the login and game servers. That way I can use Open-Tibia's, publicly-available, private RSA key to decrypt the first packet and grab the XTEA key and then decrypt everything else as I wish.
Does not seem like you have "ton" of reverse engineering in your "baggage" then
To be fair, I have a lot of reverse-engineering experience (10+ years) and if I were to look at a game client I had never looked at before I probably would have done the same thing as @dudztroyer (asked if something was available before I wasted my time). Even with a lot of experience, reverse-engineering isn't easy or quick; especially with the 11+ clients (trying to follow it around in a disassembler is a nightmare).
The linked "sniffer" should work with the 12.x clients (I don't know this 100% because I don't use it, but the 11.x clients and the 12.x clients are basically the same).
 
The first packet the client sends to the game server is partly RSA-encrypted, and the RSA-encrypted portion contains the XTEA key that will be needed to decrypt subsequent packets. Those packets are XTEA encrypted starting at the 7th byte until the end. I took the easy way out by modifying the RSA key inside the client to that of the Open-Tibia public RSA key, modified the loginWebService to localhost, then wrote a proxy to handle the traffic between the client and the login and game servers. That way I can use Open-Tibia's, publicly-available, private RSA key to decrypt the first packet and grab the XTEA key and then decrypt everything else as I wish.

To be fair, I have a lot of reverse-engineering experience (10+ years) and if I were to look at a game client I had never looked at before I probably would have done the same thing as @dudztroyer (asked if something was available before I wasted my time). Even with a lot of experience, reverse-engineering isn't easy or quick; especially with the 11+ clients (trying to follow it around in a disassembler is a nightmare).

The linked "sniffer" should work with the 12.x clients (I don't know this 100% because I don't use it, but the 11.x clients and the 12.x clients are basically the same).
You are truly a humble person, I can see with just the way you answered this.
Thanks for sharing the stuffs from the OP. (":
 
The first packet the client sends to the game server is partly RSA-encrypted, and the RSA-encrypted portion contains the XTEA key that will be needed to decrypt subsequent packets. Those packets are XTEA encrypted starting at the 7th byte until the end. I took the easy way out by modifying the RSA key inside the client to that of the Open-Tibia public RSA key, modified the loginWebService to localhost, then wrote a proxy to handle the traffic between the client and the login and game servers. That way I can use Open-Tibia's, publicly-available, private RSA key to decrypt the first packet and grab the XTEA key and then decrypt everything else as I wish.
Hey, just received the follow up in my email, sorry for the delay.
Thanks for the complete answer, that's what I was expecting to understand.

To be fair, I have a lot of reverse-engineering experience (10+ years) and if I were to look at a game client I had never looked at before I probably would have done the same thing as @dudztroyer (asked if something was available before I wasted my time). Even with a lot of experience, reverse-engineering isn't easy or quick; especially with the 11+ clients (trying to follow it around in a disassembler is a nightmare).
I hooked IDA into some OT's, followed up a few functions but the QT frameworks add so much overhead to the game code itself that it really make debugging and reversing a nightmare. I'm used to reverse plain game engines or plain softwares without that much overhead haha. I know if I tried harder I might just pull something out there, but that's mainly why I asked about it here. Didn't feel the need to get that deeper if people with knowledge have the will to share (like you did).

The linked "sniffer" should work with the 12.x clients (I don't know this 100% because I don't use it, but the 11.x clients and the 12.x clients are basically the same).
I tried to use it on OTBR client 12 modified localhost and it didn't attach any way I tried. Used three or four different injection methods but neither of those worked... Just assumed it was broken until I tryied on a plain 12 client and it actually worked. That's my fault tho. I've since then parsed QuickLooting, Bestiary and the bless dialog bytes and published in their github. But after I published this I've seen that a lot of people already got that and they are all holding into it... Got even blamed for "releasing" this lol, which actually just made me step back from the scenario...

But anyways, that helped and for sure If I'm going to get back into OT's, I'll try to make a proxy like yours.

Thanks
 
Back
Top