Battlefield 2 Protocol Communication

FrancisL · **Joined:** 10 Mar 2009 00:59 **Posts:** 10

Hi Luigi and others,

I rencently used to disassemble Battlefield 2 to know much more of its protocol so I could at least get a clone without running the game client. (Not on PunkBuster server)
I remembered your site and found two useful tools : BF2 Sniff, GSKeyCheck and the Battlefield 2 Fake Player.
so BF2 sniff is very useful to decode which bits are used by the game and I've used the read_bytes, write_bytes from the battlefield 2 fake player.

I've getting something done, but not in a good concept,
because its udp packet I need to use non-blocking because they can arrive out of order?
I would like to know your opinion on how you would do that!

aluigi · **Posted:** 10 Mar 2009 03:20

uhmm nice question but I don't have an exact answer.
judging a sniffed session I have here I see that the size of the first parameter can vary between 4 bits (the most used) and 1 so the order of the packets and this first value can't be considered.
obviously I can't exclude a possible bug in bf2_sniff which is a tool tagged as experimental (was just a test I wrote for curiosity and some bugs are visible moreover after the various packets) but in any case remains a strange protocol which I guess needs a deeper look.

practically bf2_sniff has no longer been touched since its first release of the 16 Oct 2007.

FrancisL · **Joined:** 10 Mar 2009 00:59 **Posts:** 10

I'll put some breakpoints on your hook to get back the trace of these mysterious values.
I think I'll use non-blocking socket for my client

I come back with my finding

aluigi · **Posted:** 10 Mar 2009 17:27

ih ih ih GameSpyware :)

aluigi · **Posted:** 11 Mar 2009 04:52

oh tomorrow I will release an updated version of bf2_sniff.
I have cleaned the code a lot and it's also more commented but the final result is not that different (so was not a problem of the original bf2_sniff)

aluigi · **Posted:** 11 Mar 2009 18:20

just released the new version and I have also made some tests for clarifying the doubts.

take a look to the following packets received by the client at the beginning of the connection:

Code:

==================================================================
packet 02E603A4 size 0000001a
_________________________________________________________________4
0000000f
_________________________________________________________________8
00000000
_________________________________________________________________6
00000001
_________________________________________________________________6
00000000
________________________________________________________________32
00000000

==================================================================
packet 082E0055 size 00000011
_________________________________________________________________1
00000000
_________________________________________________________________1
00000001
_________________________________________________________________8
00000001
_________________________________________________________________5
00000000
_________________________________________________________________1
00000000
_________________________________________________________________7
00000001
_______________________________dump_____________________________80
70 68 65 65 61 70 7a 67 61 00                     pheeapzga.
_________________________________________________________________8
00000003
________________________________________________________________24
00326662
_________________________________________________________________1
00000000

in this case we have the "strange" reading of one bit at the beginning of the packet and the conclusion is that bf2_sniff is not in error but it's just the bf2 client which reads the original packet in 2 parts resetting the bits counter.
I can also demostrate this by using the new version of findbits:

Code:

findbits -s "4 8 6 6 32 16 1 1 8 5 1 7 80" packet.txt

where as you can see I have used all the bits sizes of the first packet, the number 16 and then those of the second one.
that 16 I have added between them is a zone of the packet which seems not handled by the game.

and the following is another packet sent by the client and which has been started to be parsed from the bit offset (bit not byte!) 87:

Code:

==================================================================
packet 07D349FC size 00000400
_________________________________________________________________1
00000000
_________________________________________________________________7
00000003
_________________________________________________________________3
00000000
_________________________________________________________________7
00000002
_______________________________dump____________________________584
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   ????????????????
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   ????????????????
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   ????????????????
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   ????????????????
?? ?? ?? ?? ?? ?? ?? ?? 00                        ????????.

so, in conclusion, all the bf packets start with the 4 bits identifier and those other that start with 1 or other sizes are simply read in other zones of the packet.
while in the first example the bit offset of the second block is "padded" (starts at an offset divisible by 8) in the second case 87 doesn't follow the same rule (use -O 87 in findbits if you want to make the test).
anyway I have not performed additional tests, I gave only a quick look to them for a bit of curiosity, nothing more.

the new bf2_sniff is available at http://aluigi.org/papers.htm#bf2_sniff
while findbits is available at http://aluigi.org/testz.htm#findbits
hope it helps

FrancisL · **Joined:** 10 Mar 2009 00:59 **Posts:** 10

Thanks alot for the info,
This is REALLY interesting, I though to make a "find bit" program like yours but you've got it done before me :)
I really appreciate the time you've spent to help me, I'll share if I come to something with my soft.
Ah and another question,
is it better to use select non-blocking socket or blocking socket like your fake player bug,
because I think that if udp packet come out of order, it will screw up... (fake player only receive one packet, so its ok for that kind of soft, but with a complete protocol?)

aluigi · **Posted:** 12 Mar 2009 13:01

in bf2142 for example it's used an asynchronous socket in a loop where is used select() with a timeout of 3 seconds, something like:

Code:

  for(;;) {
    select(sockets + 1, NULL, NULL, NULL, &timeval_3_seconds);
    len = recvfrom(...);
    if(len >= 0) {
      // handle the data
    }
  }

so depends by your tool the type of solution to adopt, if sync or async

FrancisL · **Joined:** 10 Mar 2009 00:59 **Posts:** 10

After some try, I've reach the GameSpyware cdkey verification :P
I've taken some infos from your gs key check (thanks!) and it seem to works to generate the key but I'm stucked from these bits pattern.
Here is the original packet :

Code:

==================================================================
packet 01D80B95 of 90 bytes
_________________________________________________________________1
00000000
_________________________________________________________________1
00000001
_________________________________________________________________8
00000002
_________________________________________________________________5
00000000
_________________________________________________________________1
00000000
_________________________________________________________________7
00000003
_________________________________________________________________3
00000000
_________________________________________________________________7
00000002
_______________________________dump____________________________584
35 31 62 xx 6x 37 65   51bxxxx517e
65 30 36 34 34 61 62 35 39 33 63 30 34 65 62 64   e0644ab593c04ebd
33 65 30 30 32 39 39 31 36 31 35 63 61 32 32 64   3e002991615ca22d
61 30 37 30 35 63 33 64 39 38 36 63 37 62 62 34   a0705c3d986c7bb4
33 64 33 63 62 66 30 37 00                        3d3cbf07.
________________________________________________________________32
73636669
________________________________________________________________32
110b9500
_________________________________________________________________1
00000000
________________________________________________________________31
00000423
_________________________________________________________________1
00000000

Now here what server is receiving from my code :

Code:

==================================================================
packet 02BB526D of 88 bytes
_________________________________________________________________1
00000000
_________________________________________________________________1
00000001
_________________________________________________________________8
00000002
_________________________________________________________________5
00000000
_________________________________________________________________1
00000000
_________________________________________________________________7
00000003
_________________________________________________________________3
00000000
_________________________________________________________________7
00000002
_______________________________dump____________________________584
xxx 65 30 65 35 35 31 37 65   xxxe5xe
65 30 36 34 34 61 62 35 39 33 63 30 34 65 62 64   e0644ab593c04ebd
36 65 35 36 37 39 33 64 36 34 61 31 37 35 36 62   6e56793d64a1756b
64 34 64 31 66 62 35 62 66 37 30 64 63 63 63 34   d4d1fb5bf70dccc4
61 37 66 64 35 37 64 63 00                        a7fd57dc.
________________________________________________________________32
e6f198f3
________________________________________________________________32
110b9500
_________________________________________________________________1
00000000
_________________________________________________________________1
00000001
_________________________________________________________________8
00000011
_________________________________________________________________1

I may made a mistake due to my tiredness, but here I've attached the code I've did
if you want to take a fast look, the packet is constructed at line 118
it would be greatly appreciated if you could help me to get what the missing field is for too :)

- Francis

aluigi · **Posted:** 14 Mar 2009 15:33

uhmmm shouldn't be 31 the "padding" for that type of client's packet?
87-(4+8+6+6+32) = 31

Francis · **Joined:** 26 Apr 2008 21:50 **Posts:** 27

I know I'm reviving an old topic, but I've some things I cant sort it out.
Many packets start with that :

Code:

                                                                  ==================================================================
                                                                  packet 03325594 of 1473 bytes
                                                                  _________________________________________________________________4
                                                                   04 0000000f
                                                                  _________________________________________________________________8
                                                                  08 00000000
                                                                  _________________________________________________________________6
                                                                   06 00000001
                                                                  _________________________________________________________________6
                                                                   06 00000001
                                                                  ________________________________________________________________32
                                                                   32 00000001
==================================================================
packet 03121154 of 97 bytes
_________________________________________________________________4
R:4, W:0 04 0000000f
_________________________________________________________________8
R:12, W:0 08 00000000
_________________________________________________________________6
R:18, W:0 06 00000002
_________________________________________________________________6
R:24, W:0 06 00000001
________________________________________________________________32
R:56, W:0 32 00000001

The first 4 bit is an identifier.
The second is the player index from the server. I've sorted these things out, correct me if I'm wrong.
The third, forth and fifth, seem to keep track of packets, any ideas on how they work ?

aluigi · **Posted:** 26 Jun 2009 18:34

don't worry for reviving old topics, for me it's ok (in fact I don't understand why on the other forums doing this is avoided).
in my opinion the third parameter (which must be between 1 and 0x1f for doing something) is a tracker or maybe something which specifies how much blocks are available after it... just a stupid unverified hyphotesis I know :)

Francis · **Joined:** 26 Apr 2008 21:50 **Posts:** 27

Any idea on what this block of code is doing?

Actually it seem to read the 6/6/32 and returning their values, but i'm not enough familiar with assembly, can you confirm it?

aluigi · **Posted:** 26 Jun 2009 22:03

yes it's the code which reads the 6/6/32 bytes.
and at 006646e1 starts the check on the third value (1-0x1f) you were looking

Francis · **Joined:** 26 Apr 2008 21:50 **Posts:** 27

I think I'm gonna give up, this challenge is a too difficult for me :)
These little freaking bits are confusing me

Luigi Auriemma

Battlefield 2 Protocol Communication