How to get packet structure using ollydbg
Introduction
Let's say, you want to create a specific (old) version of a server emulator. All you have is the client files. You have done some packet sniffing tasks with success before. However, there is no public available server for you to sniff this time.
Not big deal, you have read one or two tutorials about how to get packet structure using IDA. You applied what you've learned to update some CLogin packets. It works.
The complexity of packet structure and control flow quickly increase as you proceed further. You go back to the old padding zero method. Add and remove zero here and there, and soon realize this process will take you forever...
Who is this for?
1. Anyone who wants to upgrade / downgrade their server emulator.
2. Anyone who is interested in general reverse engineering.
What solutions do we have already?
1. Packet sniffing if there are public servers available. MapleShark or MapleSnowSniffer.
2. Getting packet structures/opcodes using IDA by Hendi48
3. How to get packet structures using Cheat Engine by Hendi48
4. Getting packet structures and opcodes with IDA after GMS new update by oxysoft
How can we do it in ollydbg?
The concept is easy. You set breakpoints to these addresses.
Whenever the breakpoints hit, write logs, and continue to run the program.
This way, you get only what has been executed. Plus, in the right order.
As opposed to the whole control flow in IDA.
Screenshot: CLogin::SendLoginPacket in ollydbg
What can be improved?
1. You can write everything into an odbgscript, make it somehow like a packet sniffer.
2. You can log the register values, so you get not only the structure but also the data.
Conclusion
1. I am not saying that this method is better than IDA. You will need ollydbg to know what's currently going on, and IDA to view the whole picture. In my opinion, you will need both most of the time.
2. I am not saying that this method is easy either. Reverse engineering is not easy task in general. This is just another way to achieve things. You will still need to do the hard work.
3. That's all for now. Happy hacking.
Introduction
Let's say, you want to create a specific (old) version of a server emulator. All you have is the client files. You have done some packet sniffing tasks with success before. However, there is no public available server for you to sniff this time.
Not big deal, you have read one or two tutorials about how to get packet structure using IDA. You applied what you've learned to update some CLogin packets. It works.
The complexity of packet structure and control flow quickly increase as you proceed further. You go back to the old padding zero method. Add and remove zero here and there, and soon realize this process will take you forever...
Who is this for?
1. Anyone who wants to upgrade / downgrade their server emulator.
2. Anyone who is interested in general reverse engineering.
What solutions do we have already?
1. Packet sniffing if there are public servers available. MapleShark or MapleSnowSniffer.
2. Getting packet structures/opcodes using IDA by Hendi48
3. How to get packet structures using Cheat Engine by Hendi48
4. Getting packet structures and opcodes with IDA after GMS new update by oxysoft
How can we do it in ollydbg?
The concept is easy. You set breakpoints to these addresses.
Code:
COutPacket::Encode1
COutPacket::Encode2
COutPacket::Encode4
COutPacket::EncodeBuffer
COutPacket::EncodeStr
Whenever the breakpoints hit, write logs, and continue to run the program.
This way, you get only what has been executed. Plus, in the right order.
As opposed to the whole control flow in IDA.
Screenshot: CLogin::SendLoginPacket in ollydbg
What can be improved?
1. You can write everything into an odbgscript, make it somehow like a packet sniffer.
2. You can log the register values, so you get not only the structure but also the data.
Conclusion
1. I am not saying that this method is better than IDA. You will need ollydbg to know what's currently going on, and IDA to view the whole picture. In my opinion, you will need both most of the time.
2. I am not saying that this method is easy either. Reverse engineering is not easy task in general. This is just another way to achieve things. You will still need to do the hard work.
3. That's all for now. Happy hacking.
Attachments
You must be registered for see attachments list
Last edited: