SHOW:
|
|
- or go back to the newest paste.
| 1 | /* | |
| 2 | Client->Server | |
| 3 | // Login Server | |
| 4 | $CS_LOGIN = Chr(0x0).Chr(0x0).Chr(0x0); | |
| 5 | $CS_SERVERLIST = Chr(0x0).Chr(0x4).Chr(0x0); | |
| 6 | $CS_LOGIN_GO_SERVER = Chr(0x0).Chr(0xF).Chr(0x0); | |
| 7 | $CS_LOGIN_GO_SERVER_STEP_2 = Chr(0x0).Chr(0x11).Chr(0x0); | |
| 8 | ||
| 9 | //MMServer | |
| 10 | $CS_MMSERVER = Chr(0x1).Chr(0x0).Chr(0x0); | |
| 11 | $CS_CHANNEL_LIST = Chr(0x1).Chr(0x1E).Chr(0x0); | |
| 12 | $CS_CURRENCY = Chr(0x1).Chr(0x80).Chr(0x0); | |
| 13 | ||
| 14 | //Channel | |
| 15 | $CS_CHANNEL_JOIN = Chr(0x1).Chr(0x1F).Chr(0x0); | |
| 16 | $CS_CHANNEL_DATA = Chr(0x1).Chr(0x32).Chr(0x0); | |
| 17 | $CS_ROOM_LIST = Chr(0x1).Chr(0x33).Chr(0x0); | |
| 18 | $CS_PLAYERBUNCH = Chr(0x1).Chr(0x21).Chr(0x0); | |
| 19 | ||
| 20 | //Heartbeat | |
| 21 | $CS_HEARTBEAT = Chr(0x1).Chr(0xab).Chr(0x0); | |
| 22 | ||
| 23 | //Leave? | |
| 24 | $CS_QUIT = Chr(0xd).Chr(0x1).Chr(0x0); | |
| 25 | /**********************/ | |
| 26 | ||
| 27 | /*Server->Client | |
| 28 | // Login Server | |
| 29 | $SC_LOGIN_SUCCESS = Chr(0x0).Chr(0x19).Chr(0x0); | |
| 30 | $SC_LOGIN_SERVERLIST = Chr(0x0).Chr(0x1).Chr(0x0); | |
| 31 | $SC_SERVERLIST = Chr(0x0).Chr(0x3).Chr(0x0); | |
| 32 | $SC_LOGIN_GO_SERVER = Chr(0x0).Chr(0x10).Chr(0x0); | |
| 33 | $SC_LOGIN_GO_SERVER_STEP_2 = Chr(0x0).Chr(0x12).Chr(0x0); | |
| 34 | ||
| 35 | //MMServer | |
| 36 | $SC_1_UINT32_1 = Chr(0x1).Chr(0x9).Chr(0x0); | |
| 37 | $SC_PLAYER_DATA = Chr(0x1).Chr(0x1).Chr(0x0); | |
| 38 | $SC_CURRENCY = Chr(0x1).Chr(0x81).Chr(0x0); | |
| 39 | $SC_CHANNEL_LIST = Chr(0x1).Chr(0x25).Chr(0x0); | |
| 40 | ||
| 41 | //Channel | |
| 42 | $SC_CHANNEL_DATA = Chr(0x1).Chr(0x51).Chr(0x0); | |
| 43 | $SC_CHANNEL_JOIN = Chr(0x1).Chr(0x20).Chr(0x0); | |
| 44 | $SC_PLAYERBUNCH = Chr(0x1).Chr(0x22).Chr(0x0); | |
| 45 | ||
| 46 | ||
| 47 | ||
| 48 | ||
| 49 | //Rooms | |
| 50 | $SC_ROOM_UPDATE = Chr(0x1).Chr(0x52).Chr(0x0); | |
| 51 | /*0 uint32 action - 4 roomchunk - e4 unk4byte unknown ---- action is 00 for new room, 01 for delete room, 02 for room update | |
| 52 | // Broadcast | |
| 53 | $SC_ANNOUNCEMENT = Chr(0x4).Chr(0x2).Chr(0x0); | |
| 54 | //Heartbeat 1/min | |
| 55 | $SC_HEARTBEAT = Chr(0x1).Chr(0xac).Chr(0x0); | |
| 56 | /********************* | |
| 57 | Cross Fire Packet Documentation | |
| 58 | (C) 2010-2012 UVB-76 | |
| 59 | You can use this for whatever you want as long as you include my name in the credits, and | |
| 60 | as long as you do not create cheats or exploits. | |
| 61 | ||
| 62 | ||
| 63 | ||
| 64 | This file describes various types of packets sent to/received by Cross Fire. | |
| 65 | Only game packets were analyzed -- I have not done any work on HGWC/XTrap packets, nor do I | |
| 66 | have any interest in doing so. | |
| 67 | ||
| 68 | ||
| 69 | ||
| 70 | === | |
| 71 | ||
| 72 | ||
| 73 | ||
| 74 | ||
| 75 | All TCP messages conform to this format: | |
| 76 | ||
| 77 | F1 (dataLength uint16) (id1 uint8) (id2 uint8) (id3 uint8) (dataSection) F2 | |
| 78 | ||
| 79 | Thus, the whole message length is dataLength + 7 | |
| 80 | Minimum message length (no dataSection) is 7 bytes | |
| 81 | ||
| 82 | Generally each type of message has its own format for inside the dataSection. | |
| 83 | ||
| 84 | Since TCP is by nature a stream, you can get multiple messages, or even just parts of | |
| 85 | messages, mashed together in one packet, or split into multiple packets. DO NOT ASSUME EACH | |
| 86 | CHUNK OF DATA YOU RECEIVE IS A MESSAGE | |
| 87 | ||
| 88 | ||
| 89 | ||
| 90 | ***Example: | |
| 91 | Here's a chat message "beep boop" sent from "Khaak" to me: | |
| 92 | F1 18 00 02 01 00 00 4B 68 61 61 6B 00 00 00 00 00 00 00 00 62 65 65 70 20 62 6F 6F 70 00 F2 | |
| 93 | . . . . . . . K h a a k . . . . . . . . b e e p b o o p . . | |
| 94 | ||
| 95 | F1 and F2 are beginning and end of message markers, so they can be ignored. | |
| 96 | ||
| 97 | "18 00" is a uint16, which is length of the dataSection. In this case, it's 24 bytes. | |
| 98 | ||
| 99 | "02 01 00" is three uint8s, which make up the message ID. The first byte would appear to be | |
| 100 | a sort of message "class", but I just treat all three bytes as the ID... so the ID in this | |
| 101 | case would be 020100. | |
| 102 | ||
| 103 | Here's the dataSection of that message split out: | |
| 104 | 00 4B 68 61 61 6B 00 00 00 00 00 00 00 00 62 65 65 70 20 62 6F 6F 70 00 | |
| 105 | . K h a a k . . . . . . . . b e e p b o o p . | |
| 106 | ||
| 107 | For whatever reason, it starts out with a 00. | |
| 108 | Next is the sender's name, padded out to 12 bytes with 00s. (Names, when padded at all, | |
| 109 | seem to always be padded to 12 bytes) | |
| 110 | Then there's another 00. | |
| 111 | Then there's the chat message text. This message can be read either by reading until the | |
| 112 | 00, or by calculating the length of the text based on the dataSection length. I prefer, in | |
| 113 | this case, to just read until a 00. | |
| 114 | */ |
