Covert Channels in Multiplayer First
Person Shooter Online Games
Sebastian Zander,
Grenville Armitage, Philip Branch
{szander, garmitage, pbranch}@swin.edu.au
Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology
Overview
Covert channels overview
Covert channels in First Person Shooter
(FPS) games
Empirical evaluation
Countermeasures
Conclusions
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
2
Often encryption alone is not sufficient
Encryption protects communication from being read
Existence of communication is enough to take actions
Covert channels hide the existence of communication
Usually covert channels use means of communication
not intended for communication
Huge amount of overt network traffic makes Internet
ideal for covert communication
Alice
LCN’08
Wendy
Escape Plan
http://www.caia.swin.edu.au
Bob
{szander, garmitage, pbranch}@swin.edu.au
October 2008
3
Covert channels have different users
Government agencies vs. criminals and terrorists
hiding communication and coordination
Hackers ex-filtrating data or controlling systems vs.
sysadmins hiding management traffic
Ordinary users circumventing censorship or encryption
laws (or bypassing firewalls)
Distribution and control of viruses, worms, bots
Many network protocol-based covert channels have
been proposed
Very limited work on covert channels in network
games, focused on board games
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
4
Hide covert channels in game traffic
Hide covert data as slight variations of player character
movements in First Person Shooter games
Channel remains covert so long as variations are
visually imperceptible to human players
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
5
October 2008
6
Advantages of FPS covert channels
FPS games are very common and their traffic is not
suspicious
Channel cannot be eliminated because it is tied to
player movement (intrinsic function)
Sufficient noise in player movement to hide channel
Covert sender/receiver use game server as
intermediary, rather than directly exchanging data
Tens of thousands of game servers active on the
Internet at any time for popular games
Player movements are not logged or filtered by the
servers, unlike in-game chat messages
Not limited to FPS games
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
FPS network protocol overview
Focus on Quake III Arena (Q3), but other FPS games
have similar protocols
Asynchronous message exchange over IP/UDP
Client sends user commands to server
Movement (x,y,z) and view angles (pitch, yaw)
Server sends game state to client in snapshots
State of player character
State of other entities (players, bots and objects)
Compression: delta encoding + adapt. Huffman coding
Client
User Com
m
Snapsh
Server
and
pitch
ot
yaw
y
z
x
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
7
Encoding and decoding of covert bits
Encode covert data as slight, yet continuous,
variations of player character movements
Encode N covert bits with integer value b in changes
of (modified) parameter values ỹ between snapshots:
b = |ỹj − ỹj−1 | mod 2N
Covert sender can only manipulate ỹ indirectly through
user commands
Character’s position perturbed by various ‘forces’
But view angles mostly depend on player input only
Encode only when player changes view angles so that
channel is effectively masked
Covert bits can be encoded simultaneously in pitch
and yaw
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
8
Encoding and decoding example
Without covert channel
User
Client 1
4
y0=0
Server
4
13
13
19
19
Client 2
y0=0
y1=4
y1=4
http://www.caia.swin.edu.au
LCN’08
{szander, garmitage, pbranch}@swin.edu.au
October 2008
9
October 2008
9
Encoding and decoding example
Without covert channel
User
Client 1
4
y0=0
4
13
13
19
19
24
y1=4
Server
y0=0
24
24
24
14
14
y1=4
y2=24
LCN’08
Client 2
y2=24
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
Encoding and decoding example
Without covert channel
User
Client 1
4
y0=0
13
19
19
y1=4
24
14
14
y2=24
7
y0=0
24
24
10
Client 2
4
13
24
Server
y1=4
y2=24
10
7
y3=14
y3=14
http://www.caia.swin.edu.au
LCN’08
{szander, garmitage, pbranch}@swin.edu.au
October 2008
9
Encoding and decoding example
With covert channel
User/Client
Covert Sender
4
~
y0=0
4
13
b0=0
12
19
Server
Covert Receiver
~
y0=0
18
~
y1=4
LCN’08
y~1=4
http://www.caia.swin.edu.au
b0= |4 – 0| mod 2 = 0
{szander, garmitage, pbranch}@swin.edu.au
October 2008
9
Encoding and decoding example
With covert channel
User/Client
Covert Sender
4
~
y0=0
4
13
b0=0
12
19
Server
Covert Receiver
~
y0=0
18
24
~
y1=4
25
24
b1=1
25
14
y~1=4
13
y~2=25
y~2=25
http://www.caia.swin.edu.au
LCN’08
b0= |4 – 0| mod 2 = 0
b1= |25 – 4| mod 2 = 1
{szander, garmitage, pbranch}@swin.edu.au
October 2008
9
Encoding and decoding example
With covert channel
User/Client
Covert Sender
4
~
y0=0
4
13
b0=0
12
19
Server
Covert Receiver
~
y0=0
18
24
~
y1=4
25
24
b1=1
25
14
y~1=4
13
10
~
y2=25
7
b2=0
y~2=25
9
b1= |25 – 4| mod 2 = 1
7
~
y3=13
LCN’08
b0= |4 – 0| mod 2 = 0
~
y3=13
http://www.caia.swin.edu.au
b2= |13 – 25| mod 2 = 0
{szander, garmitage, pbranch}@swin.edu.au
October 2008
9
Synchronisation errors
Synchronisation errors
Bits lost on channel (bit deletions)
Bits inserted on channel (bit insertions)
Exchange of player state based on potential visibility
Players only receive state updates for pot. visible players
Depends on static information (map) and current positions
In Q3 potential visibility is asymmetric
IP/UDP is unreliable so snapshots can be lost
⇒ Bit synchronisation mechanism
Visibility
Covert
channel
LCN’08
Deletions
Insertions
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
10
October 2008
11
Substitution errors
Substitution errors (= flipped bits)
Game mechanics change player’s view angles
Respawning after death
Pitch is clamped between -87 and +87 degrees
⇒ Pause encoding and decoding
Map elements change player’s view angles
Teleportation portals
⇒ Same as respawning
Moving platforms players can step on
⇒ Rare on multiplayer maps, can be avoided
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
Broadcast vs. unicast communication
In broadcast mode covert sender continuously sends,
but covert receiver(s) receive only when sender visible
No insertions but many deletions
In unicast mode covert sender only sends when
receiver visible
Minimises deletions but introduces insertions
Covert sender must know covert receiver’s in-game identity
Covert receiver either knows covert sender’s in-game
identity or uncovers it (meaningful bit sequence)
http://www.caia.swin.edu.au
LCN’08
{szander, garmitage, pbranch}@swin.edu.au
October 2008
12
October 2008
13
Implementation and deployment
Implemented for Q3 as transparent proxy using the
Covert Channels Evaluation Framework (CCHEF)
Cheat detection mechanisms cannot detect proxies
But knowledge of protocol’s ‘encryption’ is needed
Could be implemented as client modification (mod),
but many Q3 servers do not allow modified clients
Could be implemented like other client-side cheats
Covert Sender
Covert Channel
Overt Channel
LCN’08
Covert Receiver
Covert In
Covert Out
Channel
Channel
Overt In/Out
Network
http://www.caia.swin.edu.au
Overt In/Out
{szander, garmitage, pbranch}@swin.edu.au
Evaluation in local testbed
One Q3 server and 2–4 Q3 clients (human players)
One covert sender and 1–3 covert receivers
10 minute games on the standard map q3dm1
Measure average bit rates and bit error rates
Broadcast and unicast mode
Encode 1 bit per angle change
Encode in pitch and yaw
Analyse how different covert channel looks from
normal traffic (fingerprint)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
14
October 2008
15
Bit rates and bit errors
Broadcast mode
Sender Rate
[bits/s]
Deletions
[%]
14.6–18.0
42.9–54.9
Insertions Substitutions
[%]
[%]
0.0
0.0
Unicast mode
Sender Rate
[bits/s]
Deletions
[%]
8.0–10.4
3.0–3.6
Insertions Substitutions
[%]
[%]
1.0–2.5
0.0
⇒ Net bit rates of 7.7–9.8 bits/s
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
Length of transmission periods
Bit deletions/insertions occur in bursts
(between errors → transmission periods)
1.0
Proportion ≤ x
0.8
0.6
0.4
Broadcast (2 players)
Unicast (2 players)
Broadcast (3 players)
Unicast (3 players)
Broadcast (4 players)
Unicast (4 players)
0.2
0.0
0
50
100
150
200
250
300
Transmission period length (bits)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
16
October 2008
17
Investigating the fingerprint: packet sizes
Compare client-to-server packet size distribution of
covert sender with normal players
1.0
Normal (2 players)
Normal (2 players)
Normal (3 players)
Covert (2 players)
Covert (2 players)
Covert (3 players)
Proportion ≤ x
0.8
0.6
0.4
0.2
0.0
55
60
65
70
Packet size (bytes)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
Investigating the fingerprint: packet sizes
Compare server-to-client packet size distribution of
covert sender with normal players
1.0
Proportion ≤ x
0.8
0.6
0.4
Normal (2 players)
Normal (2 players)
Normal (3 players)
Covert (2 players)
Covert (2 players)
Covert (3 players)
0.2
0.0
50
100
150
200
Packet size (bytes)
http://www.caia.swin.edu.au
LCN’08
{szander, garmitage, pbranch}@swin.edu.au
October 2008
17
Investigating the fingerprint: view angles
Compare pitch angle distribution of covert sender with
normal players
1.0
Proportion ≤ x
0.8
0.6
0.4
0.2
Normal (player 1)
Covert (player 1)
Normal (player 2,3,4)
0.0
−20
0
20
40
60
Angle (degrees)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
18
Investigating the fingerprint: view angles
Compare yaw angle distribution of covert sender with
normal players
1.0
Normal (player 1)
Covert (player 1)
Normal (player 2,3,4)
Proportion ≤ x
0.8
0.6
0.4
0.2
0.0
−150
−100
−50
0
50
100
150
Angle (degrees)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
18
Countermeasures
Generally available countermeasures
Elimination
Capacity limitation
Detection
Channel cannot be eliminated because player
movement is intrinsic function of FPS games
Capacity of channel could be reduced
Warden introduces noise (random angle fluctuations)
Noise in own view angles more easily visible than in other
player’s character’s view angles
Covert sender could always send with higher ‘power’
Warden could target specific players if channel is detected
Detection is non-trivial, but probably possible
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
19
Ongoing and future work
Reliable message transport: bit synchronisation,
framing, error correction etc.
Developed bit synchronisation and framing mechanism
(unicast)
Throughput of 2–13 bits/s
No synchronisation errors, even with packet loss (≤ 1%)
No substitution errors
More and longer trials to better understand
performance and limitations (bots and humans)
Develop efficient detection mechanism
Statistical tests
Anomaly detection or machine learning methods
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
20
Conclusions
Developed novel covert channel in first person shooter
online game traffic
Channel is not limited to FPS games, but could be
used for other game types
Throughput is low, but sufficient for short text
messages or chatting
Covert channel cannot be eliminated
Detection is non-trivial as covert channel looks similar
to normal traffic (but probably possible)
CCHEF is available, but Q3 module is not public yet
(http://caia.swin.edu.au/cv/szander/cc/cchef/)
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
21
Acknowledgements
Many thanks to Lucas Parry, Lawrence Stewart and
Kewin Stoeckigt for being tough opponents in the Q3
tests
LCN’08
http://www.caia.swin.edu.au
{szander, garmitage, pbranch}@swin.edu.au
October 2008
22