Jump to content

PaleTree - Packet Logger


Recommended Posts

PaleTree is a packet logger that utilizes data coming from packet providers, like Zemyna.


Just like its cousin MabiPale, PaleTree allows you to log packets, and save, load, and modify the logs. However, unlike MabiPale, you won't see clear, separated variables here, as ToS's protocol doesn't communicate this information. Instead, PaleTree features a hex editor on the right side, and it has a plugin to show which values might hide behind a bunch of random bytes, starting at the selected index. For deeper analysis, a tool like 010 Binary Editor is recommended.

Another difference to MabiPale, is that due to the availability of op codes, there are no unknown ops, and in case of changes, the ops are saved inside the logs, so you never have to worry about incorrect op names. But you should update PaleTree regularly, since any change in an op could result in confusing data.


Remember to regularly update PaleTree and Zemyna whenever one is available, as they need to be up-to-date to work with the latest client.


  • Logging packets
  • Saving logs
  • Log management (deleting, filtering)
  • Plugin system
  • Official plugins:
    • Variable Preview: Displays what values could be read from a packet, starting at the selected byte.

How to use

  • Put Zemyna.exe into your ToS folder
  • Create a link to Zemyna.exe, using parameters for the appropriate server. For example to connect to the international server Laima, you would use Laima's login server IP and port:
    Zemyna.exe host: port:2000

    And to connect to a local server, without Steam auto-login, but with a login form, you would use this:

    Zemyna.exe host: port:2000 nosteam
  • Start the client with that link whenever you want to log packets.
  • Click connect in Pale to subscribe to Zemyna's packet broadcast and to start logging packets.

Packet data

The packet data in the hex editor is always the raw data received/sent by the client, incl. packet header. This means the actual values don't start at the first byte.

Packets from the client to the server have a 10 byte header:

short op;
int sequence;
int checksum;

Packets from the server to the client are the same, just without the checksum, so it's 6 bytes in total. Additionally, packets that don't have a fixed size have another short (2 byte) before the actual data, the length of the entire packet. Packets that have a fixed length will say something like "Size: 50 (Table: 50, Garbage: 0)" in the packet information on the right side, after the op, while dynamic packets don't say this (dynamic packets are ones that include lists or variable sized strings, where you can't define a fixed size).

The last thing of note is the potential "garbage" at the end of packets from the client to the server. Because of how the packet encryption works, the length of packets from the client to the server is always a multiple of 8. Packets that have a fixed size will be able to determine that X byte are "garbage", because they don't belong to the actual data, but are a left-overs from the encryption process.

The garbage bytes can generally be ignored, the only reason we don't truncate them is that we could potentially lose data if the ops are outdated.

  • Like 2
Link to comment
Share on other sites

  • exec pinned this topic

Update 1.0.3

I fixed a few bugs, caused by left over MabiPale code. I recommend everybody to update, as those bugs could be potentially problematic.

  • Fixed packets shorter than 12 byte being filtered.
  • Fixed filter using op codes instead of names.

You can download the latest version from the Download link in the first post.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
  • 1 month later...
  • exec unpinned this topic

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...