I've not looked at the game or anything, so I can't do everything for you. Looking at your logs, I can see there is a clear solid structure that ALL packets follow (except the HTTP// ones in there for downloading pages.images). The structure is simple, and it just describes 4 individual strings. There are sizes and markers for the strings in the packets, although they are completely unneccesary, as they are all null terminated, and they are always in the correct order. (I wouldn't be proud to write that protocol anyway). All the unnecceasry crap is probably there for validation to try and detect people modding the packets.
//
//Start of packet
//
Each packet starts with 0x72. Its only use is to identify the start of a new packet. Each time you call recv(), you may receive multiple packets in one (because TCP is a streaming protocol. there are no markers at the start and end of each packet). This flag is in little-endian, which is the strange part, because the rest of the data is in big-endian.
Next, there is an int containing the size of the packet. This is in big endian now (use ntohl()
. It contains the size of the packet from this point on. (the size of the whole packet minus the header (6 bytes), we've already read.
8 bytes of blank space. (May be for optional header information. useless anyway.
4 bytes big-e containing the size of the proceeding string. (The size does not include the NULL '\0')
String containing some kind of command. aka, Login, Attack, etc.
4 bytes big-e containing the size of the proceeding string.
String containing a username. ( ? ). null terminated again.
4 byte big-e containing 0x01. This always appears to be the same value. It looks like it marks the start of the main chunk of data, but look rather unneccesary, because the data has a fixed structure in each packet.
4 byte big-e containing size of next string.
String may contain coordinates in the form @x-[%x]y-[%y], or a target (for attacking, talking), or maybe other data.
1 byte containing 0x03. Again, looks pretty useless. just there as a seperator it appears.
4 byte big-e containing size of the next sting
String containing a second piece of data that relates to the last string (ie, password when the first string is the login name. null terminated.
//
//end of packet.
//
As for the strings, I can't clearly make them all out. It seems there is some kind of code/encrypted data/time at the start of most strings. I dunno what its for, but it looks like something you'd have to dig deeper into the client for. Find a debugger. Chances are you'll need to understand this before you can send anything, because its different in every packet, you'd be detected spamming certain packets. If you manage to hook the client in the right places, it may be possible to send the 4 strings and have the client automatically add the random values. That takes alot of hard work though.
Best thing to do after that, is look at packets when you trigger a certain event. for example, if you talk on global and say "Hi!", you're 4 strings in the packet will be something like
"broadcast", "quilby", "@allusers", "Hi!". //with the (random) digit info in it aswell.
Collect enough data like this and you will be able to do countless things. There may be server side protections, but chances are you'll find some bugs to exploit, and you'll be able to bot freey.
hope that helps a bit.
