Jump to content
Sign in to follow this  
gonk

Fennec.ws network traffic

Recommended Posts

The problems are gone with and without BE due to BIS activating the enhanced gamespy protocol for the arma servers, which require a challenge/response.

http://dev-heaven.net/issues/22808

---------- Post added at 08:21 ---------- Previous post was at 08:20 ----------

The byte following the 'splitnum\0' can be parsed like this:

flag = s.get_byte.unpack("C")[0]

index = flag & 127

final = flag & 0x80 > 0

index is the packets index in the series, it's possible to recieve packets out of order so reassembly in the correct order is required to query some servers.

Thanks! Only thing left is glueing the packets properly together, it seems for player info the first entry of the next packet might have to overwrite the last entry of the previous packet completely as it might be incomplete.

Share this post


Link to post
Share on other sites
The problems are gone with and without BE due to BIS activating the enhanced gamespy protocol for the arma servers, which require a challenge/response.

Well, sorta. Whoever or whatever is initiating the UDP packets appears to have a cache of the IP addresses of servers that it "knows". So while armaserver.exe itself no longer reacts to the incoming UDP packets, in many cases the packets will continue to come into the server at the network stack. If you run Wireshark and have experienced these packets, it's very likely that you will still see the inbound UDP packets (60 bytes long) but without the reply from armaserver.exe.

I suspect this will drop off over time, but the updates to BE and the use of v3 of the Gamespy protocol do not fully stop the traffic...just the majority of it. As we've seen, each inbound UDP packet of 60 bytes was causing outbound traffic of 1-2KB so the exponential effect was pretty significant. The fixes have removed the outbound part, but can do nothing about the inbound.

Share this post


Link to post
Share on other sites

That's what I was saying and have been saying past pages.

The inbound traffic is neglible - so that's why I call the problems gone, and the inbound traffic will probably subside in time.

Edited by Sickboy

Share this post


Link to post
Share on other sites
Hi Sickboy... is there any chance that you will update your Advanced GameSpy Server Query Script, please..

:rolleyes:

Hi i'm afraid not, kinda abandoned php quite a while ago :) Anyone's free to modify it (if they really wanted to ;))

I could recommend to check http://gameq.sourceforge.net/ (make sure to select the gamespy v3 protocol),

or any of the other php-based solutions that are floating around :)

Or get an image etc @ www.gametracker.com

Edited by Sickboy

Share this post


Link to post
Share on other sites

Sickboy, do you have any Ruby code for the new queries? This is what I have:

        sock.send("\xFE\xFD\x09\x58\xEF\xD0\xC8", 0, server_ip, port)

       challenge = sock.recv(64).gsub(/[^0-9\-]/, "").to_i

       sock.send("\xFE\xFD\x00\x58\xEF\xD0\xC8#{x(challenge >> 24)}" +
                 "#{x(challenge >> 16)}#{x(challenge >> 8)}" +
                 "#{x(challenge >> 0)}\xFF\xFF\xFF\x01", 0, server_ip, port)

       response = sock.recv(512)

A challenge packet is received, but after sending back the final request there is no response. (x is the handle_chr function you posted.)

Some debug output:

The challenge is: 77381309
Challenge info: 4 1180 302270 77381309 (24 / 16 / 8 / 0, and the spaces are only there in the debug output)

(This is for a script to fix the yellow server browser issue with the Linux server. The idea is to accept the original requests, but use iptables string matching to drop the response. The script uses libpcap to find that request, and makes its own query to the server, fixes the hash, and forwards it. The firewall rule isn't in place right now, so that's definitely not the issue. I'll also be releasing this as soon as it's working.)

Share this post


Link to post
Share on other sites

Ah a fellow Rubyist eh :) Ahoy!

This is what I use; https://github.com/sickboy/six-updater-gui/blob/develop/SixUpdaterGui/Applications/six/query/gamespy.rb#L215

But the UDPSocket/Client im using isn't the one from Ruby but from .NET, so you'll have to switch that.

The problem in your implementation seems to be that you're returning the challenge response as numbers, while you should convert it to string (im using sprintf).

Btw Max Packet size is 1400 not 512, and you can receive up to 7 of them, splitnum tells you which ID this packet has and if it's the last packet.

And interesting use case - kudos to you :)

---------- Post added at 09:17 ---------- Previous post was at 09:03 ----------

BTW, there's a bug currently in Arma gamespy implementation, if a single server info field value cannot fit in a single packet, http://dev-heaven.net/issues/23389

(The ticket also contains 2 links to some example packet output, the linked pastie also includes my response incl challenge).

Edited by Sickboy

Share this post


Link to post
Share on other sites

Hi all,

I only came across this thread last night and found it a very interesting read (especially the part about ACE being a botnet - naughty ACE team!!!).

Anyway, after reading the full thread I am a little confused as to what the solution is for my server...

1. I have been keeping it up to date with the latest beta's (for OA).

2. I have not rebooted it for a few weeks (actually a lot of a few weeks).

Does the latest beta also install the latest BattleEye?

Should I re-boot the server? It is in use 24 hours so I have to pick a good time to re-boot.

Is there anything I need to add to the server.cfg for Arma2OAServer?

I got a traffic alert from the datacentre a few weeks ago, but this was at the same time as I released a new app to the server (it also has to work for it's keep) so I can't be sure if I fell foul of this exploit or not.

Apologies if the answer is already posted, but there is a lot of info in this thread and it's hard to see where the diagnosis ends and the solution starts!! All good stuff though.

Share this post


Link to post
Share on other sites

Hey Jedra,

BIS has activated the improved gamespy protocol a couple of weeks ago, if you haven't rebooted your server since then, please do, so the new protocol is activated.

BE afaik updates automatically at server start or mission start.

Having both will protect you best.

Share this post


Link to post
Share on other sites
Hey Jedra,

BIS has activated the improved gamespy protocol a couple of weeks ago, if you haven't rebooted your server since then, please do, so the new protocol is activated.

BE afaik updates automatically at server start or mission start.

Having both will protect you best.

Cheers, thanks for the response. Some of the corporations I have slaved myself to in the past would have killed for this kind of collective diagnosis!

Share this post


Link to post
Share on other sites
Ah a fellow Rubyist eh :) Ahoy!

This is what I use; https://github.com/sickboy/six-updater-gui/blob/develop/SixUpdaterGui/Applications/six/query/gamespy.rb#L215

But the UDPSocket/Client im using isn't the one from Ruby but from .NET, so you'll have to switch that.

The problem in your implementation seems to be that you're returning the challenge response as numbers, while you should convert it to string (im using sprintf).

Btw Max Packet size is 1400 not 512, and you can receive up to 7 of them, splitnum tells you which ID this packet has and if it's the last packet.

And interesting use case - kudos to you :)

---------- Post added at 09:17 ---------- Previous post was at 09:03 ----------

BTW, there's a bug currently in Arma gamespy implementation, if a single server info field value cannot fit in a single packet, http://dev-heaven.net/issues/23389

(The ticket also contains 2 links to some example packet output, the linked pastie also includes my response incl challenge).

Thanks!

I'm only forwarding on the "browser info" packet - the one that provides the server name, mod details, number of players, and status/mission. The player names and other data are sent in a different packet, I believe. I've only seen the browser info use one packet, at least with the default BAF/PMC mods.

I don't expect anyone with very long mod fields to be using this (chances are that with so many mods, they'd have a private server for friends/members and wouldn't care about the yellow browser anyway), so I'm just going to assume one packet only to avoid the added complexity. If it does become an issue, that can always be changed later.

And of course, I'll post the finished version in the Linux server thread. I already have the work-in-progress version posted there.

---------- Post added at 11:22 ---------- Previous post was at 10:30 ----------

Sickboy, I got the queries working. Thanks!

What I'm trying to do now: the packet I'm sending seems to be the full info packet. I can't seem to figure out how to get the server browser info query - the one that only provides the server name, version, mods, platform, and the hash. This is the packet I'm looking for:

0000   00 57 8d 65 d6 5b 54 65 61 6d 44 65 61 64 6c 79  .W.e.[TeamDeadly
0010   2e 63 6f 6d 5d 20 5a 61 72 67 61 62 61 64 20 4c  .com] Zargabad L
0020   69 66 65 20 32 00 00 36 00 34 35 00 5a 61 72 67  ife 2..6.45.Zarg
0030   61 62 61 64 00 54 65 61 6d 00 5a 61 72 67 61 62  abad.Team.Zargab
0040   61 64 20 4c 69 66 65 20 49 49 20 28 47 61 6e 67  ad Life II (Gang
0050   20 57 61 72 46 61 72 65 29 00 31 35 00 30 00 30   WarFare).15.0.0
0060   00 32 30 30 35 00 31 35 39 00 31 35 39 00 41 72  .2005.159.159.Ar
0070   6d 61 20 32 3a 20 4f 70 65 72 61 74 69 6f 6e 20  ma 2: Operation 
0080   41 72 72 6f 77 68 65 61 64 3b 41 72 6d 61 20 32  Arrowhead;Arma 2
0090   3a 20 42 72 69 74 69 73 68 20 41 72 6d 65 64 20  : British Armed 
00a0   46 6f 72 63 65 73 20 28 4c 69 74 65 29 3b 41 72  Forces (Lite);Ar
00b0   6d 61 20 32 3a 20 50 72 69 76 61 74 65 20 4d 69  ma 2: Private Mi
00c0   6c 69 74 61 72 79 20 43 6f 6d 70 61 6e 79 20 28  litary Company (
00d0   4c 69 74 65 29 00 30 00 37 00 31 00 6c 69 6e 75  Lite).0.7.1.linu
00e0   78 00 36 35 35 34 35 00 00 31 00 31 00 6a 73 72  x.65545..1.1.jsr
00f0   73 66 61 3b 62 69 00 31 00 50 4d 43 20 76 2e 20  sfa;bi.1.PMC v. 
0100   31 2e 30 31 3b 42 41 46 20 76 2e 20 31 2e 30 32  1.01;BAF v. 1.02
0110   3b 64 61 33 39 61 33 65 65 35 65 36 62 34 62 30  ;da39a3ee5e6b4b0
0120   64 33 32 35 35 62 66 65 66 39 35 36 30 31 38 39  d3255bfef9560189
0130   30 61 66 64 38 30 37 30 39 00                    0afd80709.

To get that, here's what the game sent:

0000   fe fd 00 57 8d 65 d6 42 2d f7 77 19 01 04 08 0a  ...W.e.B-.w.....
0010   05 06 6f 10 13 64 65 66 67 68 69 6a 6b 6c 6d 1f  ..o..defghijklm.
0020   6e 70 72 71 73 00 00                             nprqs..

I assumed the last 4 bytes (0x71730000) be what I need, but that's not working.

The random ID seems to be 0x188D65D6, and the last 3 bytes of that seems to be present in both packets. Not sure where the 0x18 went though.

Edited by eddieck

Share this post


Link to post
Share on other sites

Try to use this as the query part of the packet you send;

0xFF, 0x00, 0x00, 0x00 (notice the last byte not being 0x01)

or leave out that 4th byte:

0xFF, 0x00, 0x00

But hmm, the game seems to send and receive some specific/special format, e.g the returned packet is lacking field names... the above probably wouldn't make that happen.

Edited by Sickboy

Share this post


Link to post
Share on other sites
Try to use this as the query part of the packet you send;

0xFF, 0x00, 0x00, 0x00 (notice the last byte not being 0x01)

or leave out that 4th byte:

0xFF, 0x00, 0x00

But hmm, the game seems to send and receive some specific/special format, e.g the returned packet is lacking field names... the above probably wouldn't make that happen.

Thanks - that's much closer, but still not the exact same. Probably the closest I'll get at least using the "public" protocol.

The game definitely seems to be using another format - the response to the challenge seems to be much longer as well.

Either way, I think I've got enough info from the response to parse it and create my own response that's similar to the original. That's probably the best way to go at this point.

Share this post


Link to post
Share on other sites

Found it:

\x19\x01\x04\x08\x0a\x05\x06\x6f\x10\x13\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x1f\x6e\x70\x72\x71\x73\x00\x00

This returns the proper output without the field names. No clue why it's so long - but it works.

(Now I'm trying to figure out PacketFu - doesn't seem to be sending the packet properly, with the source port.)

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×