Packet Analysis

[Astaelan]

Hello everyone,

Well, not much to say this time except I'm feeling nice today, so I've decided to share something with the community. If you don't know how, or what this is, just close this post and move on.

Here is C# code for decrypting packets, you can build a wireshark dissector plugin or a separate tool as I have for packet logging. I encourage people to try and write their own packet loggers, but when I'm satisfied with my own I may release it to the public in the hopes of people contributing what they are able to figure out in the packets.

As mentioned in a previous post, this part of the project I'm working on is the longest and most tedious. A little help from the community could go a long way. Note that the code is somewhat incomplete, I was going to calculate the CRC check but left it out for now. Without further adeui, here is the code.

        private bool Decrypt(byte[] buf)
        {
            Int32 length = BitConverter.ToInt32(buf, 0);
            UInt16 CRC = BitConverter.ToUInt16(buf, 4);
            UInt16 flags = BitConverter.ToUInt16(buf, 6);
            UInt32 seed = BitConverter.ToUInt32(buf, 8);
            if ((flags & 0x8001) == 0x8001)
            {
                byte state = Convert.ToByte((((seed >> 0x10) + (seed & 0xFF)) & 0xFF) & 0xFF);
                byte carry = Convert.ToByte(((seed >> 0x04) + (length - 8)) & 0xFF);
                Buffer.BlockCopy(BitConverter.GetBytes(Convert.ToInt32(length - 8)), 0, buf, 0, 4);
                for (Int32 index = 4; index < length - 8; ++index)
                {
                    byte b = buf[index + 8];
                    buf[index] = Convert.ToByte(carry ^ b ^ state);
                    state = Convert.ToByte(b ^ 0xED);
                    carry += Convert.ToByte(((index / 2) * index) & 0xFF);
                }
            }
            return true;
        }

Stay tuned for a release of the packet logger soon.

 

[Astaelan]

Just a quick update for those who might be interested in where this was leading. The packet logger is nearly finished the release version. Unfortunately I've been held back a bit by the purchase of a new development system, and reformatting and all that fun, plus some other real life crap.

Anyway, progress has been made, the inline structure editor is finished the preliminary version, needs to be tested extensively before I release it. Expect a release sometime this week.

Hope to see this generate some interest in the packet side of things. I do not advocate malicious use of the code, but needless to say if interest is generated and people work together on analyzing packets and sharing it, this information could benefit everyone. I will most likely start another thread for analyzed packets and keep it up to date as myself and others identify pieces of data. In fact I may set up a WIKI for this information, but I don't have the bandwidth to support active use, if anyone cares to donate a little corner of their host for a wiki? Otherwise I'll figure out something myself if I don't hear from someone in a day or two.

 

[DarkKnightH20]

If the project works out well, I may be able to assist in the Wiki :]

 

[Astaelan]

As it turns out I've been offered an exceptionally good career opportunity. As a result I have not been working on PT lately. If the job pans out I will be out of the PT scene altogether for quite some time. Unfortunately I haven't had time to finish the PTSniffer so I won't be releasing it in the timeframe mentioned obviously.

The management of a wiki itself wouldn't be difficult, it's getting people to setup a server, and use PTSniffer to log packets, then go into various things in the server and change stuff to see where packets change. Here is a perfect example.

Let's say we start with a packet further in the protocol, for example, your character list just before character selection (which coincidentally is actually sent right after login, before you select a server). This packet contains a lot of data, segmented into blocks of repeating data, one for each character. As it so happens, it sends data for all characters, even if the characters do not exist. As a result, this data is all random junk from memory and gets ignored by the client. Leave it to korean developers to be so wasteful.
Anyway, logically speaking, in order to display your character, this packet would have to contain data relative to at least your characters name, level, items and some other stuff. It contains much more than that as it turns out, but for sake of explanation we'll just assume that. So this is where the process of differential analysis comes in. What you do is you login, capture the packet, record it, then change something like your level and do it again. See what changes, identify the differences, and eventually isolate to the point of knowing exactly what data in the packet contains what. A large portion of that specific packet has been already figured out through a combination of using the CU.EXE tool to edit my player file, slowly analyzing as much as the editor allowed me to edit. This has narrowed it down significantly, and only a couple chunks of unknown data remains.

This is the process I was/am going to take if I have time to work on PT with the wiki. The information will be publically available, in combination with my already released decrypt function, it will allow anyone with the knowledge to write their own custom server from scratch. Why would I do this? Well, it's a lot of work on my own, and it didn't seem like a lot of people with the right skills were stepping up, and since I may be very busy with my new job, this gives a little something back to the community. Hopefully people will appreciate what they can do with it.

I recently bought a new PC, which in turn had me rebuilding hardware for all the PC's in the house including my Frankenstein box which ran the PT server I was testing with. I haven't really had time to set it back up, but if I get some time I will setup a wiki, and then release the PTSniffer.

On a side note about PTSniffer, due to complexity of my own desires with the PTSniffer, I opted to use a Lua wrapper for building packet structure information. This means that some minimal understanding of LUA and the functions I added would be needed to use the PTSniffer effectively. However, prior to release I will include one or two scripts and some comments to explain how it works.

Thanks to the folks who've shown some interest in this, it kept me coming back to the forums and is probably what will make me find the time to finish PTSniffer and release it.

 

[Astaelan]

A quick update on the situation. Having built a new PC and running Vista 64bit now, I've run into some difficulties with WinPCap not wanting to work properly. As far as I know wireshark works fine, but the .NET wrapper I used with XP 32bit without a problem appears to be failing to access the winpcap DLL and is returning as though it either can't find the DLL, or cannot access it properly. Before installing winpcap it would give an error when trying to obtain the version, and if you tried to get a device list it would hang indefinately. Now it doesn't hang, produces an empty device list, and the same error when trying to get the version. A peculiar issue that someone else seemed to have as well with another project before I switched off XP32.

Anyway, to make a long story short, Vista is being a lady and I can't continue development of PTSniffer until I resolve the issue with winpcap. And since I'm quickly losing time for this project, it may become a dead end as a result. The decrypt function posted at the beginning of this post is sufficient for anyone to write a packet logger and start analyzing the packets.

Since I am unable to complete the PTSniffer itself, i've decided I'll just share some of what I know regarding packet structures to get people started.

The first packet sent is by the client, and contains the following structure:

Opcode: 0x48470085

12 Bytes Unknown
32 Bytes Username
32 Bytes Password

Invalid login attempts result in the following:

Opcode: 0x48470023

4 Bytes Unknown
4 Bytes Error Code
8 Bytes Unknown

At some point a version packet is transmitted as well:

Opcode: 0x4847008A

4 Bytes Unknown
4 Bytes Version
8 Bytes Unknown

A successful login will render 2 packets, a character list and a server list:

Opcode: 0x48470086

32 Bytes Username
4 Bytes Actual Character Count
<Block repeats 6 times once for each character, even those not created>
32 Bytes Character Name
64 Bytes Character Body Model
64 Bytes Character Head Model
4 Bytes Character Class/Job
4 Bytes Character Level
8 Bytes Unknown
4 Bytes Character Stage (could be ID of map character is on?)
60 Bytes Unknown

Opcode: 0x484700C0

32 Bytes Main Server Name
4 Bytes SubServer Count
<Block repeats for SubServer Count>
32 Bytes SubServer Name
16 Bytes SubServer Main IP
4 Bytes Unknown
16 Bytes SubServer User IP (not sure?)
4 Bytes Unknown
16 Bytes SubServer Extend IP (not sure?)
4 Bytes Unknown
4 Bytes SubServer Main Port
4 Bytes SubServer User Port
4 Bytes SubServer Extend Port
4 Bytes Unknown
<End of Block>
32 Bytes ClanServer Name
16 Bytes ClanServer Main IP
4 Bytes Unknown
16 Bytes ClanServer User IP (not sure?)
4 Bytes Unknown
16 Bytes ClanServer Extend IP (not sure?)
4 Bytes Unknown
4 Bytes ClanServer Main Port
4 Bytes ClanServer User Port
4 Bytes ClanServer Extend Port
4 Bytes Unknown

And there is one more packet I have documented, though I forget what it's purpose is at the moment:

Opcode: 0x48470088

4 Bytes Unknown
4 Bytes Status
4 Bytes Unknown
32 Bytes Username
32 Bytes Character Name


As you can see there is random chunks of data here and there which have not been identified. If you mock up a quick packet sniffer and implement the decrypt routine (a wireshark plugin would do the trick if you know what you're doing there), then you could break down the packets and possibly figure out more of the unknown data. The packet I was focusing on last was the character list. Much of the data in that packet is unknown, I used the CU.EXE or whatever to edit pieces of a character file then see what changed in the packet. Unfortunately the editor doesn't edit everything, and left some data completely unknown. It should also be noted that the character list is a small subset of data from the main character updates sent by the client... The main update is saved directly from the packet the client sends to a file on disk and that file is used to sent to other clients I believe to update them on changes to a character they can see.

Anyway, looks like I'm going to have to step out of PT for a while now, hopefully this information will find it's way to someone who makes use of it.

 

[Superman666]

Seems to me like im the only on helping him... i mean you guys may not see it but im the bg helper.. but yet i help more then anyone. Does the PT section not want help from a 15+ year C# .net programmer? If so give him a hand... seriously. Help him... and he will help you back.

 

[Astaelan]

Well Superman666, I do appreciate your enthusiasm, though before someone jumps at me for claiming I have 15 years of C#.NET experience, best to clarify that obviously isn't possible.

I've been programming C for about 15 years, and C# for over 5 years now, suffice to say I know my stuff. All the same your point remains true, a little enthusiasm from the community would go a long way.

As for nickette, nothing says you can't take the C# decrypt method I provided and recreate the code in VB. The languages are not so different that they don't provide the same means to the end result. Just adapt it for your language, C# just happens to be my language of choice when it comes to most coding I do these days.

This is a large part of why I avoid releasing code or anything like that, it tends to be too specific for many to use. I rather release information that people can use within the confines of the language of their choice. Everything I've provided would be a big gem had it been provided for me, so you just have to be interested in taking this approach. I'm not even asking folks to write the server themselves, just help to contribute by taking the information I've provided and adapt your own code to figure some of this out and share it.

In fact, if you want to provide usefulness without even having to deal with encryption, or anything, just run a server, and grab your player file out of the data directory. Each character gets it's own data file which is a verbatim copy of a packet the client sends periodically so far as I can tell anyway. You could simply grab a hex editor, and try to understand more of the unknown parts of that file. The CU or GUD I forget which, but that character editor that comes with the server does a good job of breaking a lot of the file down, however there is still some I haven't figured out simply because I haven't had the time to go change my character in ways that the editor doesn't cover explicitly, like item inventory, equipped gear, some other stuff...

Anyway, all it takes is a little motivation, the key ingredients are provided.

 

[GuhMP]

I'm tracking the progress, I'm here to help as needed. I have knowledge in C #/JAVA with other emulators and a little packet analysis.

I'm with a friend put his job to work. You think about creating a community for developing an emulator? xD

THANKS!

 

[SheenBR]

Me too

 

[bobsobol]

IMHO, PT doesn't need an emulator. For what it does, the current server is fine. What it needs is a complete re-write... Something which happens a lot with off-line games. If you could treat PT the way

You must be registered to see links

are treating Morrowind, you would have a good project going.

Really, the communication protocol between the client and server needs to be replaced, not emulated. The client needs to be subservient to the server, and the server needs to provide the game... where presently, the server is simply used as a database, and communication hub for clients.

Another interesting move, is that in Vietnam (as I understand the translations of their forums) the "private" developers are working hard to replace the requirement of a server, at all, to play PT. So the client runs solo turning the game back into the single player / LAN game it was originally.

The client it's self needs a complete overhaul to support modern APIs (Direct3D proper and or OpenGL) and take advantage of Shaders and multi-processors and so on, to support compressed and archived assets and so on and so forth.

Server side, hostile NPCs need better AI capabilities, server security needs to be improved, and the best method of achieving that is to treat the server as the game, not a repository, NPC dialogue, and quest status needs to be improved. Server state data needs to be shifted to the SQL database, not the mish-mash of .DAT files, .INIs, .TXTs, .INFs, .ASEs, .SMDs and .SMBs, .SPPs, .SPCs and .log files.

All of this is just wrong, but the way the client is written, it becomes the most logical way to make a server. And since the server is not much different from a client which doesn't have a player, that's where it all comes from.

The problem is, if you write a new client... will people still feel like they are playing PT? By which I mean, I think many of the people still playing PT do so because they like how insecure and generally flaky the PT servers are, and how easy the game is to hack as if it where a local only game, only you can kick another players arse instead of just NPCs. But also, if you centralised processing (as it should be) and updated the UI, would players still "feel" that it was PT? And if you don't do that... what are you putting your effort into, and why?

And as far as "packet logging" if you want me to write a file dumper into my Protocol.dll so that each packet is written to a new file (indexed or something) after it's decrypted, I can do that without problems. I'm not sure if it's possible to tell (from the calls) if the packets are incoming or outgoing, but the information in them is pretty self evident.

I've done enough packet tracing to know that the packets sent and received are not complex. Most of the time it's a simple state update, or a save game file.

 

[SheenBR]

I would be very grateful if u make some kind of DLL that I could use to encrypt/decrypt a packet, because i didnt get success in your reply on my previous thread... I think its the first step.

 

[GuhMP]

And as far as "packet logging" if you want me to write a file dumper into my Protocol.dll so that each packet is written to a new file (indexed or something) after it's decrypted, I can do that without problems. I'm not sure if it's possible to tell (from the calls) if the packets are incoming or outgoing, but the information in them is pretty self evident.

I just wanted to pass the login with an emulator, just for knowledge.

bob, could you describe could find that information relating to packets? I wanted to get a sense of how to get the "Encryption".

Sorry my bad english. You are the best, thanks! tt:

 

[bobsobol]

bob, could you describe could find that information relating to packets? I wanted to get a sense of how to get the "Encryption".

I see in many places a simple byte-wise XOR as "encryption"... *I* was taught very early on that it is *not* encryption. In fact, translating Latain text from EBCIDIC to ANSI is a far more complex "encryption" than a simple XOR.

Call it "encoding" if you like, but it's not a Cypher to be cracked, any more than x = -x is an "encryption".

If I write the word "Zookd" and you "decrypt" that as "Apple" how hard is that? It's not a tough "encryption" but considerably more complex than the method used in PT packet encoding.

How do I get "Apple" from "Zookd"? Every letter shifted one place to the left, with the first letter of the alphabet wrapping around to the last.