- Joined
- Dec 27, 2006
- Messages
- 288
- Reaction score
- 4
KaLua PacketProxy is a packet sniffer, which acts as a proxy between the client and a server. It was specifically designed as a tool for analyzing the protocol Kal Online uses for KaLua. The original program was made by Erkle, and it was updated by ingam0r to meet certain needs, and I just made a few minor adjustments today so the community could use it.
You can download it
It's targeted towards the .NET platform, which means you will need the .NET framework which can be downloaded
Before being able to use it, you will have to open up config.txt and add the following line:
I'm sure you can guess what that is. Now that that's set, you will need to change your xlate-e so that you can connect to PacketProxy.
By default, PacketProxy will expect the client to connect to on port 30001. You CAN change it, by passing a different port on the command line.
That would cause it to listen for the client on port 30002. Why can't you set in the config.txt like the server address and port? Well.. there never really was any need for changing the port to listen on, and based on the source's design, it wasn't easy to add it, and I rushed it sooo.
Moving on, once you've got PacketProxy started, you can connect to it with the client. Please note, if PacketProxy cannot connect to the server, it will crash. If everything is successful, you should see some packets being shown in the PacketProxy console.
Blue for extra information, green for packets that are being sent from the client, and red for packets that are being sent from the server. All packets that are sent are conveniently logged in a .log file in the same folder. The log files are named according to the 'current time' in the format: hour-day-month-year.log.
PacketProxy also has the ability to ignore packets, due to the fact that you can be 'spammed' with packets, making it harder for you to correctly analyze a specific action. To ignore a packet, open up the config.txt and add a line.
Where <sender> is either 'server' or 'client', and <ID> is the ID of the packet you want to ignore (in hexadecimal).
So, how do you do you actually analyze packets and the actions associated with them you say? Well you are going to need a decent hex editor, PacketProxy and some common sense.
If you have zero programming experience, you will need to read
In the above article, take note of the C# names. Since I will be using them to explain. ALL packets have the same basic structure:
Note: The [] signifies an array. See:
To actually 'figure out a packet', you will need to take note of your actions, and the packets sent as a result. As an example, let's do a rundown of how one would have figured out the structure of the login packet. (Which is as follows, but you may want to take a look at
Note: All of the strings sent by the server and client are
One would have figured out this structure, by first attempting to login with the sniffer on. After which, you should notice that the client sends a packet with an ID of 0x02. Now all that's needed is to figure out the structure of this packet, which is where the hex editor comes in. Upon pasting the recorded data in your hex editor, you would notice 2 blatantly obvious strings, matching the ID and password you entered. Tada, structure figured out.
And that concludes this release/guide. It's poorly written, but you should get the gist of things. Post any bugs you may have found with the PacketProxy and I may consider fixing them.
You can download it
To view the content, you need to sign in or register
.It's targeted towards the .NET platform, which means you will need the .NET framework which can be downloaded
To view the content, you need to sign in or register
.Before being able to use it, you will have to open up config.txt and add the following line:
Code:
set server 127.0.0.1 30002
I'm sure you can guess what that is. Now that that's set, you will need to change your xlate-e so that you can connect to PacketProxy.
By default, PacketProxy will expect the client to connect to on port 30001. You CAN change it, by passing a different port on the command line.
Code:
PacketProxy 30002
That would cause it to listen for the client on port 30002. Why can't you set in the config.txt like the server address and port? Well.. there never really was any need for changing the port to listen on, and based on the source's design, it wasn't easy to add it, and I rushed it sooo.
Moving on, once you've got PacketProxy started, you can connect to it with the client. Please note, if PacketProxy cannot connect to the server, it will crash. If everything is successful, you should see some packets being shown in the PacketProxy console.
Blue for extra information, green for packets that are being sent from the client, and red for packets that are being sent from the server. All packets that are sent are conveniently logged in a .log file in the same folder. The log files are named according to the 'current time' in the format: hour-day-month-year.log.
PacketProxy also has the ability to ignore packets, due to the fact that you can be 'spammed' with packets, making it harder for you to correctly analyze a specific action. To ignore a packet, open up the config.txt and add a line.
Code:
set ignore <sender> <ID>
Where <sender> is either 'server' or 'client', and <ID> is the ID of the packet you want to ignore (in hexadecimal).
So, how do you do you actually analyze packets and the actions associated with them you say? Well you are going to need a decent hex editor, PacketProxy and some common sense.
If you have zero programming experience, you will need to read
To view the content, you need to sign in or register
and
To view the content, you need to sign in or register
.In the above article, take note of the C# names. Since I will be using them to explain. ALL packets have the same basic structure:
Code:
struct Basic Packet {
ushort size
byte id
byte[] data
}
Note: The [] signifies an array. See:
To view the content, you need to sign in or register
To actually 'figure out a packet', you will need to take note of your actions, and the packets sent as a result. As an example, let's do a rundown of how one would have figured out the structure of the login packet. (Which is as follows, but you may want to take a look at
To view the content, you need to sign in or register
first.)
Code:
struct Login Packet : 0x02 (The ID) {
string loginID
string Password
}
Note: All of the strings sent by the server and client are
To view the content, you need to sign in or register
. One would have figured out this structure, by first attempting to login with the sniffer on. After which, you should notice that the client sends a packet with an ID of 0x02. Now all that's needed is to figure out the structure of this packet, which is where the hex editor comes in. Upon pasting the recorded data in your hex editor, you would notice 2 blatantly obvious strings, matching the ID and password you entered. Tada, structure figured out.
And that concludes this release/guide. It's poorly written, but you should get the gist of things. Post any bugs you may have found with the PacketProxy and I may consider fixing them.