First of all the statement
If the packet that the server expect does not match from what the client sent, the server will disconnect you.
makes no sense.
How would the server know what you are going to send to him?
Maybe you ment that the server disconnects you if you malform the packet (change the structure of the packet - or, for example, by disabling the packet encryption - in this case the server would try to decrypt it and would get non interpretable results).
So to answer your question:
IMO you have two possible ways to achieve your goal:
- Find the function that creates the packet before it is encrypted and use it to send your own data.
- Understand how the network protocol and cryptography of your game works and rebuild it in your own program.
I'd suggest you use the first option since it's the simpler one. While the second option provides you more flexibility I don't think it's feasable for you since you said
but I don't know how to translate them into a higher level language like c++..
I can only provide you with general instructions since you didn't post much information about your target (name, some assembly snippets, if it uses TCP or UDP, ..):
- Use a dynamic debugger to find the function mentioned in #1. I prefer x64dbg since it works for both, x86 and x64 bit applications.
- Set a breakpoint on the socket send function. Which send function is used depends on your game but possible candidates are send, sendto, WSASend and WSASendTo.
- Find the used send function by placing a breakpoint on all of them and watch which bp triggers. Now you know which function is used to send the data to the game server. I'll use
WSASendTo in this example since it's very common in modern udp applications (I assume your game uses UDP - I could be wrong tho).
- As you know by the documentation of
WSASendTo the function takes a pointer to one or more
WSABUF structures as second argument. Usually it's just one
- Since almost every windows api function is a
__stdcall the second argument will be at
[esp+0x8] when your breakpoint triggers (
[esp] is the return address,
[esp+0x4] is the first argument
_In_ Socket s).
- If you use x64dbg you can now follow the pointer to the
WSABUF structure "in dump" to see the contents of it. You can also follow the return address at
[esp] to find the function which called
- You will probably need to restart the game a few times and set new breakpoints on the function which called the windows send function.
- At some point you will see that the contents of the buffer change - you said that only the first two bytes are encrypted, so you already know at what to put your eyes at.
- At this point you should know which function is responsible for encrypting your data. Maybe this is already all you need - maybe you need to go a bit higher in the calling hierarchy to find the function which actually starts the whole
packet create-encrypt-send process.
Hope that helps!