Transcript Lecture notes.

Last Time
• More collision detection packages
• Time critical collision detection
• Introduction to networking for games
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Today
• Networking protocols
• Cheating and Security
– Great article: Evaluations
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Internet Protocols
• There are only two internet protocols that are widely
deployed and useful for games: UDP and TCP/IP
– TCP/IP (Transmission Control Protocol/Internet Protocol) is most
commonly used
– UDP (User Datagram Protocol) is also widely deployed and used
• Other protocols exist:
– Proprietary standards
– Broadcast and Multicast are standard protocols with some useful
properties, but they are not widely deployed
– If the ISPs don’t provide it, you can’t use it
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
TCP/IP Overview
• Advantages:
–
–
–
–
Guaranteed packet delivery
Ordered packet delivery
Packet checksum checking (some error checking)
Transmission flow control
• Disadvantages:
– Point-to-point transport
– Bandwidth and latency overhead
– Packets may be delayed to preserve order
• Uses:
– Data that must be reliably sent, or requires one of the other properties
– Games that can tolerate latency
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
UDP Overview
• Advantages:
– Low overhead in bandwidth and latency
– Immediate delivery - as soon as it arrives it goes to the client
• Disadvantages:
–
–
–
–
–
Point to point connectivity
No reliability guarantees
No ordering guarantees
Packets can be corrupted
Can cause problems with some firewalls
• Uses:
– Data that is sent frequently and goes out of date quickly
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Choosing a Protocol
• The best way to do it is decide on the requirements and find
the protocol to match
– In most cases, that means TCP/IP
• You can also design your own “protocol” by designing the
contents of packets
– A protocol is simply a set of rules for putting data in the packets and
acting upon it
– Add cheat detection or error correction, for instance
– You then wrap you protocol inside TCP/IP or UDP – just send your
“packet” as a regular chunk of data
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Reducing Bandwidth Demands
• Bandwidth is plentiful on the internet today, so it only
becomes an issue with large environments
– Even “slow” modems have more impact through high latency than
low bandwidth (due to compression, error checking and
analogue/digital conversion)
• Regardless, smaller packets reduce both bandwidth and
latency
– Latency is measured from the time the first bit leaves to the time the
last bit arrives - so fewer bits have lower latency
• There are two primary ways to reduce bandwidth demands:
– Dead reckoning allows you to send state less frequently
– Area of interest management avoids sending irrelevant data
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Area of Interest Management
• Area of interest management is the networking equivalent of visibility only send data to the people who need it
• There is a catch, however: In a network you may not know where
everyone is, so you don’t know what they can see
– A chicken-and-egg problem
• Hence, area-of-interest schemes are typically employed in client-server
environments:
– The server has complete information
– It decides who needs to receive what information, and only sends
information to those who need it
• Two approaches: grid methods and aura methods
– Sound familiar? (replace aura with bounding box)
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Grid and Aura Methods
• Grid methods break the world into a grid
–
–
–
–
Associate information with cells
Associate players with cells
Only send information to players in the same, or neighboring, cells
This has all the same issues as grid based visibility and collision detection
• Aura methods associate an aura with each piece of information
– Only send information to players that intersect the aura
– Just like broad-phase collision detection with bounding volumes
• Players need to find out all the information about a space when they
enter it, regardless how long ago that information last changed
– In other words, have to be careful with “state” information that is
infrequently sent
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Building for Networking
• It is generally agreed that networking must be a
consideration from the start of development
• There are many good practices – see game programming
web sites for tips (and descriptions of past mistakes)
• One good practice: Access all data through a consistent
interface, which both the networking and local code uses
– Avoids different side effects from different access points
– Can check for validity of data in one place, which makes checking
for network errors easier
– Can decrypt/encrypt in one place
– Can automatically propagate data onto network
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Cheating
• It’s an arms race…
– http://www.gamasutra.com/features/20000724/pritchard_01.htm
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Why Care About Cheats?
• Online gaming is big business
• Cheats can achieve financial advantage:
– Competitive games with prizes are the obvious example (casinos)
– Also consider EverQuest: People play the game, build good characters, and
then auction them on ebay. If they can cheat to obtain good characters, they
are achieving unfair financial advantage
• Cheats can ruin the game for everyone:
– Players tend to have a strong sense of fairness
– If they believe they are being cheated, they will not play, and you will not
make any money
• Single player cheaters typically only affect themselves, so you don’t
care
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Sources of Cheats
• Reflex augmentation: Use a cheat to improve some aspect of physical
performance, such as the firing rate or aiming
• Authoritative clients: Clients issue commands that are inconsistent with
the game-play, or mimic the server
• Information Exposure: Clients obtain information that should be hidden
• Compromised servers: A hacked server biases game-play toward the
group that knows of the hacks
• Bugs and Design Loopholes: Bugs are found and exploited, or parts of the
program intended for one purpose are used for another
• Environmental Weakness: Differences or problems with the OS or
network environment are exploited
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Observations About Cheating
• The only way to make a system 100% secure is to completely isolate it
(Eric Brewer, 1996)
• Pritchard’s Rules (Gamasutra article):
–
–
–
–
–
–
–
–
–
12/09/03
If you build it, they will come - to hack and cheat
Hacking attempts increase as a game becomes more successful
Cheaters actively try to control knowledge of their cheats
Your game, along with everything on the cheater’s computer, in not secure not memory, not files, not devices and networks
Obscurity is not security
Any communication over an open line is subject to interception, analysis
and modification
There is no such thing as a harmless cheat
Trust in the server is everything in client-server games
Honest player would like the game to tip them off to cheater, hackers hate it
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Reflex Augmentation
• Aiming proxies intercept communications, build a map of where people
are, and automatically shoot them
• Rapid-fire proxies take each “shoot” packet and replicate it
• Fix #1: The server validates player actions - if they are too good the
player is considered a cheat and kicked out
– What’s hard about this?
• Fix #2: Make it difficult to insert non-valid packets
– Encrypt the packets, but your encryption must be cheap, and cheap
encryption can be broken
– Make the encryption depend on the game state or other time-dependent
“random” value. Hard to do with UDP. Why?
– If using guaranteed delivery (TCP) serialize packets with a unique sequence
of numbers - cannot then replicate or insert extra packets
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
A Word on Encryption
• Typically: A key – known only to intended users – is used to
convert regular data into something that looks random
– Cannot go from random data back to key, or to the real data
• Many ways to come up with the key
– Agree on it ahead of time
– Transmit it – key exchange algorithms
– Derive it from somewhere else in such a way that all parties derive
the same key (e.g. from game state)
• Most encryption algorithms work on blocks of a fixed size
– Split large amounts of data into smaller blocks
– Pad blocks that are too small
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Authoritative Clients
• Occurs when one player’s game informs everyone else that a definitive
event has occurred: e.g. I just got a power-up
• Hacked clients can be created in many ways: change the executable,
change game data in other files, hack packets
• Fix is to insert command request steps:
– Player request an action, its validity is checked, it is sent out on the
network, and added to the player’s pending event queue
– Incoming actions also go on the pending queue
– Actions come off the pending queue, are validated again, and then are
implemented
• Sometimes validation is hard to get right, so try synchronization
– Occasionally send complete game state around, and compare it
– Actually, send something derived from complete game state
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Information Exposure
• Some classics: Modify the renderer to make walls transparent, modify
maps to remove the fog of war
• Basically, display variables must be modified in memory, or read out and
displayed elsewhere
– Hackers are very good at finding the locations of key data in memory, and
modifying them transparently
• Fixes:
– Check that players agree on the value of certain variables, and the validity of
actions - synchronization again
• Note that you can look for actions that cannot be valid with the correct display
– Compile statistics on drawing, and see of they look off (eg # polygons drawn)
– Encrypt data in memory to avoid passive attacks
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Compromised Servers
• Many servers have customization options, and the community is
encouraged to modify the server
– This is completely legal
• However, as a game becomes popular, naïve people start to play the
game
– They do not have the skills or knowledge to check that the server they are
playing on is “pure”
– They will grow frustrated, blame the developer, and complain to their
friends
• Some modifications can be very insidious, and may not be legal. For
example, hack the server to do different damage for opponents
• Solution is to warn people when they connect to the server, and about
any other non standard properties (found through validation)
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Bugs and Design Issues
• Some bugs enable cheating, such as a bug that enables fast
reloading, or one that incorrectly validates commands
• Some design decisions make cheating easier:
– Embedding cheats codes in single player mode makes it easy for a
hacker to track down the variables that control cheats
– Poor networking or event handling can allow repeat commands or
other exploitations
• Age of Empires and Starcraft example: all resource management is
done after all events for a turn are processed. Poor networking allowed
multiple cancel events on the queue, which restored multiple resources
• Solution is to avoid bugs and think carefully about the
implications of design decisions on hacking
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Environmental Weaknesses
• Facilities to deal with the OS or network may leave you
vulnerable to some forms of attack
– Interaction with the clipboard can introduce non-printable characters
– Interaction with almost any scripting language may leave you open
to hacks not related to the game itself (ie your game could be a way
in)
– Network connection drops or overloading can cause problems
• Some cheats destroy the game for every player (tip the
board) which can be useful if you are losing
• Others knock off a specific player (your worst enemy, one
assumes)
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
The Moral of the Story
• You can’t win, you just try to make cheating as hard as
possible and contain the damage
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin
Todo
• By Thursday, Dec 11, Midday, Final Demo
• Monday, Dec 15, Final Exam, 2:45 P.M, RM 1221 CS
12/09/03
CS679 - Fall 2003 - Copyright Univ. of Wisconsin