- One One Seven
- |
- Exalted Mythic Member
- gamertag: [none]
- user homepage:
Cheating will always exist. That's pretty much a given. No matter how well designed and implemented any anti-cheating mechanisms are, someone will find a way to take advantage of it.
But there are ways to severely reduce these advantages.
Bungie are naturally not releasing the details on how Halo 2's anti-cheating code works - and with good reason - but it's fair to say that they're not particularly efficient; all you have to do is take the most recent figure for banned users, and divide it by the number of days the game has been on the market, to see that.
Now don't get me wrong; these are much better than nothing whatsoever, but they could be better.
So let's consider firstly, the main types of cheating out there:
* 1. Modified Content
* 2. Network Manipulation (Standby, Lagging out players, Bridging Host, etc)
Now let's consider what we know about the way Halo 2 deals with these
1. Modified Content
The banhammer detects the modified content quickly (supposedly instantly), and requests a ban via some subsystem that Microsoft/Bungie have developed, locking the gamertag out of matchmaking. The process takes time, presumably due to the way Xbox Live is designed (other bans such as modified Xbox BIOSes are picked up on instantly when you sign in, but it takes time for the xbox in question to be banned).
2. Network Manipulation
Presumably there's an algorithm in the banhammer that tries to watch out for weird networking issues, as well as what occurs during these interuptions (such as scoring a point etc). Bungie also have custom tools and likely additional data from the postgame reports that they can use too. When a cheater is flagged, they're locked out of matchmaking as above.
So what about the efficiency of these?
Well we know that modders are usually dealt within a fairly reasonable timeframe of a few hours, but it's certainly possible for them to play and win a lot of games, and artificially inflate a rank by a lot, before they get banned.
And with the network manipulation ... not so good. When was the last time you saw someone who blatently standbyed you get banned? For the vast majority, it's probably fair to assume that it was a while ago ... if ever.
So as I say above, they're better than nothing, but there could certainly be better.
Dealing with them
Modified Content is the easiest one to deal with, so let's handle that first.
Clearly the current Halo 2 system isn't fast enough; modders have plenty of time to ruin the experience for people, and boost players up. Now Bungie can't do much about the way Live's banning systems work, so for an instant solution, there's only really one way of doing it; getting the software itself to lock players out of matchmaking.
The solution is in two parts, both relatively simple:
* A. Ensure that modified content is immediately detected, without requiring the content to be loaded up in a game situation
* B. Ensure that a player cannot load modified content, and that there is no time span in which a player may do so.
Part A is simple. Use a strong HASH[1] to verify the files; unlike checksums, it is, to all intensive purposes[2], impossible to modify the file and get the same value. Now verifying the HASH of a large file takes time, but compromising security for speed is a stupid decision. You weaken security because of it, you risk undermining the entire system.
Ok, that's that; we can easily tell when a map is modified. Stopping that content from being used is also reasonably simple
Part B merely involves getting the software to prevent the map from being loaded. All the software needs to do is prevent any games from being played. That's it. Such a subsystem already exists in Halo 2, it just isn't tied in to modified content. So if the HASH fails, prevent any games from being started/played/joined until the content is fixed. Simple. No modding allowed. QED.
So that's one problem fixed, by applying a little understanding about basic cryptography, ensuring no compromised for speed over security, and by writing in a few subsystems to deal with modified content.
Now Network Manipulation is much much harder to detect. Especially when traffic congestion occurs, connections and packets can drop briefly, connections vary, etc etc. There are lots of variables that can affect a connection, many of them can also fluctuate at any given time.
However, there are still things that the netcode can look out for:
Standby:
When a player standbyes, his xbox cannot communicate with the outside world (i.e. the internet). He can't send any data to client xboxes, and he can't recieve any data in return.
Now Clients communicate with the host about 4 times a second. An update cycle is every 250ms. Now when the player standbyes, these can't be sent, and no data is incoming. Now a few cycles might be missed due to network congestion and packetloss, but if 4 or so are missed (1 second's worth of data), then there's either some severe problems with traffic, or the player is cheating.
So what do you do? Attempt to reconnect - if it's problems with traffic, it'll occur pretty much instantly. If the player is standbying, it won't occur for several seconds. And if it doesn't occur for several seconds, merely revert the game back to when the connection was lost, so the standbyer doesn't gain any advantage. Anything he does during that brief window is negated.
Finally, if a connection repeatedly drops, the player's either cheating, or the host isn't good, and neither are desireable. So switch the host to another player.
And if these are feasible, standbying is essentially useless, and it'd get the host switched out, so it couldn't repeatedly occur.
Now Bridging is a completely different thing. Some people have strict NAT settings, and incorrectly configured routers, which means that they can't always connect to people. Problem is, is that any code to catch bridgers would likely get innocent players as well; there's not much that can be done other than giving a player who can't connect to other players the benefit of the doubt. Perhaps scanning to see what % of players he/she cannot connect to (and if it's above an arbitary value, banning that player), but there's no easy way of discriminating between a bridger and someone with strict settings.
And with lagging players out, it's kind of the same. If a connection is lost between players (and if both players can still connect to live), it could be reported automatically, and monitored. And if a certain amount of connections have been lost, implement a ban.
So there you go. A few relatively simple ideas on how to improve the cheating situation. Modding is completely prevented, and the netcode is improved to drastically reduce the efficiency of standbying, and to swap the host out if problems repeatedly occur. And there's code to detect when the system is being manipulated in more subtle ways.
A long post, I know, so if you managed to read all this, good job. Care to leave some feedback too? ;-)
[1]An example would be the widely used and well known 128-bit MD5 algorithm.
[2] Winhex Manual on Hash Codes (Digests):
Digests
A so-called digest is, similar to a checksum, a characteristic number used for verification of data authenticity. But digests are more than that: digests are strong one-way hash codes.
It is computationally feasible to manipulate any data in such a way that its checksum remains unaffected. Verifying the checksum in such a case would lead to the assumption that the data has not been changed, although it has. Therefore, digests are used instead of checksums if malicious (i.e. not mere random) modifications to the original data are to be detected. It is computationally infeasible to find any data that corresponds to a given digest. It is even computationally infeasible to find two pieces of data that correspond to the same digest.
[Edited on 6/18/2006]