CF packet/message format, and other stuff

Bored with CF so here is a bit of my documentation on the netcode and a few other things

Note that this is only relating to the stuff you do at the lobby -- I haven't studied much gameplay stuff and I most likely won't be doing so

Here's a little thing I wrote about how to handle what I call "messages":

Code:

Cross Fire Packet Documentation
(C) 2010-2012 UVB-76
You can use this for whatever you want as long as you include my name in the credits, and
as long as you do not create cheats or exploits.



This file describes various types of packets sent to/received by Cross Fire.
Only game packets were analyzed -- I have not done any work on HGWC/XTrap packets, nor do I
have any interest in doing so.



===




All TCP messages conform to this format:

F1 (dataLength uint16) (id1 uint8) (id2 uint8) (id3 uint8) (dataSection) F2

Thus, the whole message length is dataLength + 7
Minimum message length (no dataSection) is 7 bytes

Generally each type of message has its own format for inside the dataSection.

Since TCP is by nature a stream, you can get multiple messages, or even just parts of 
messages, mashed together in one packet, or split into multiple packets. DO NOT ASSUME EACH
CHUNK OF DATA YOU RECEIVE IS A MESSAGE



***Example:
Here's a chat message "beep boop" sent from "Khaak" to me:
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
.  .  .  .  .  .  .  K  h  a  a  k  .  .  .  .  .  .  .  .  b  e  e  p     b  o  o  p  .  .

F1 and F2 are beginning and end of message markers, so they can be ignored.

"18 00" is a uint16, which is length of the dataSection. In this case, it's 24 bytes.

"02 01 00" is three uint8s, which make up the message ID. The first byte would appear to be
a sort of message "class", but I just treat all three bytes as the ID... so the ID in this
case would be 020100.

Here's the dataSection of that message split out:
00 4B 68 61 61 6B 00 00 00 00 00 00 00 00 62 65 65 70 20 62 6F 6F 70 00
.  K  h  a  a  k  .  .  .  .  .  .  .  .  b  e  e  p     b  o  o  p  . 

For whatever reason, it starts out with a 00.
Next is the sender's name, padded out to 12 bytes with 00s. (Names, when padded at all, 
seem to always be padded to 12 bytes)
Then there's another 00.
Then there's the chat message text. This message can be read either by reading until the 
00, or by calculating the length of the text based on the dataSection length. I prefer, in
this case, to just read until a 00.

Not going to baby anyone and release everything (at least not yet) but here are a few message IDs to get you started:

Code:

011E00  MESSAGE_CHANNEL_LIST_REQUEST
012100  MESSAGE_INVITE_LIST_REQUEST
012200  MESSAGE_BUNCH_OF_PLAYERS
012500  MESSAGE_CHANNEL_LIST
012700  MESSAGE_BUNCH_OF_PLAYERS_END
013300  MESSAGE_ROOM_LIST
014400  MESSAGE_TRANSFER_TO_UDP
014E00  MESSAGE_TRANSFER_TO_UDP_3
014500  MESSAGE_KICK_PLAYER
014600  MESSAGE_KICKED_FROM_ROOM
018000  MESSAGE_ZP_REQUEST
018100  MESSAGE_ZP_REPLY
020100  MESSAGE_CHAT_SC
020A00  MESSAGE_CHAT_BIND_INCOMING
040200  MESSAGE_ANNOUNCE
040800	MESSAGE_SCROLL_MESSAGE

Not going to give any of the structures for the data inside the messages yet. It's easy enough and you can sniff it yourself. x-trap doesn't block Wireshark (and even if it did, it's trivial to make your own packet sniffer that would automatically parse the CF message format

)

Some other stuff that I posted on the Z8 forums a while ago (of dubious usefulness)
option.dat format

Code:

258     //unk
0       //gametype. 0=tdm, 1=snd, 2=ghost, 3=elim, 4=ffa, 5=mutation, 6=escape, 7=hero, 8=zombie
0       //map ID, in that gamemode. NOT global map ID. so for example if this value is zero and gamemode is tdm, you get Ship. if gamemode is snd, you get EagleEyes/
2       //number of players. 0=1player, 1=4players, 2=8players, 3=12players
0       //waiting
1       //playing
1       //weapons - all
1       //weapons - sniper
1       //weapons - pistol
1       //weapons - knife
0       //unk
0       //unk
1       //unk
1       //unk

sort.dat format

Code:

256
76
2       //Game Status - 0=any, 1=waiting, 2=ingame
0       //Players Status - 0=any, 1=4person, 2=8person, 3=12person, 4=16person
0 1
1 0     //this line and onwards is the maps selected. this follows cf's map IDs so there's no real order. the UI only displays TDM maps and the other map IDs appear to be off by default, but you may get interesting results by turning them on here :) but beware that saving sort options in game may turn them off again.
2 0     //Ceyhan SnD
3 1     //Ship TD
4 1     //Mexico TD
5 1     //etc...
6 1
7 0
8 1
9 1
10 1
11 0
12 0
14 1
15 1
16 0
17 0
18 1
19 0
20 1
21 0
22 0
23 0
24 1
25 0
27 1
28 0
29 0
30 0
31 1
32 0
33 0
34 0
35 0
36 0
37 1
38 0
39 1
41 1
42 0
43 0
44 0
45 0
46 0
47 0
48 0
50 1
51 1
52 0
53 0
54 0
55 0
56 0
57 0
58 0
59 0
60 1
61 1
62 0
63 0
64 1
65 1
66 0
67 0
68 1
1000 0  //these i don't know for sure (cbf to test), but see below:
1001 1  //this one is "Random Map" on the UI
1002 0
1003 0
1004 0
1006 0
1007 1
1008 0
1010 0
1011 0
1012 1

I've also got a fully working REZ toolset which you can see in action here:

Not going to publicly release that yet because xxmarv09xx has an idea he is working on that I fully support. Maybe I'll release the rez tools in a few months though, after he's done, who knows~

if that video isn't proof enough (i made it really early on), you can check this video by marv, this is done using my tools:

I was also working on OfflineFire...

...which is pretty much abandoned at this point. Fairly sure it doesn't work with the latest game updates anyway, and I have zero interest fixing it so it does

Anyway, if anyone finds any of this info useful I'd love to hear about it, so just drop me a VM or something...
thanks.