So a while back, I was planning on writing Spring, except that I was going to call it Complete Distruction. I flaked out, but me and my friends came up with some good ideas on cheat prevention in open source code.
You don't need an exe verifier. Palladium isn't the answer, although it will work. They key is to remember that you don't need to prevent cheating, you just need to catch it and tell the users about it. Social forces will do the rest, although if someone keeps changing nicknames, you might want to add some sort of moderation system to the battle room so that people can vote on each other.
There are 3 kinds of cheats.
1) Information cheats, where the user has info they shouldn't.
They answer to this is simple. Only give info to the user's computer that it needs to draw the screen. Comps ask each other for info, and only hand it out on request. (So if I drive a jeffy to your base, my comp asks your comp for what your base looks like right now). Requests are verified after the game, in a process that I will describe below.
2) Input cheats, where the user subtitutes computer input for their own (for example aim better than they should in a FPS).
This is not much of an issue in Spring, as the computer is way too stupid to play better than a human.
3) Rules-bending cheats, where the user ignores game logic about what they are allowed to do, and for example puts up a vulcan in a tenth of a second.
These are more difficult to detect, but are possible. Have each computer save each piece of info it gets from the other computers, and each input it gets from the local user(s). After each game, the computers share all inputs with each other, and rerun the game without any graphics in super ultra sped up mode. They compare each piece of data they received during the game with each piece of data they generate after the game. If there is a discrepancy, then a player cheated (and it should be pretty easy to figure out who). Getting around this requires the cheater to generate command inputs that result in the EXACT same game as they just played by cheating. That problem is probably as difficult as building a human level conciousness, so you've caught all cheaters.
Since you are already saving all data for the TA recorder (or at least can save all data), it shouldn't be that difficult to implement this (and a bunch easier than an exe verifier that will be hacked in about .7 seconds).
Idea for anti-cheating program
Moderator: Moderators
Re: Idea for anti-cheating program
10053r wrote: So a while back, I was planning on writing Spring, except that I was going to call it Complete Distruction.
I flaked out, but me and my friends came up with some good ideas on cheat prevention in open source code.
You don't need an exe verifier. Palladium isn't the answer, although it will work.
They key is to remember that you don't need to prevent cheating, you just need to catch it and tell the users about it.
wrong approach, if games are buld to prevent most cheating, cheating level will drop
ie. what can be done server side, must be serverside and what not, must be VERIFIED server side
and rest, must be checkable
for example PunkBuster's remote screenshot ability, request for memory values of game variables, request for file checksums etc ...
names means nothing as every cheater will write or copy script for changing it in some minutes after his first ban,Social forces will do the rest, although if someone keeps changing nicknames,
you might want to add some sort of moderation system to the battle room so that people can vote on each other.
assign to each user Unique Identified, ideally generated from hardware
(combined strong hash of HDD serial number, motherboard serial number, videocard serial number etc)
easy solution, player DON'T know about anything he can't see (server side control)There are 3 kinds of cheats.
1) Information cheats, where the user has info they shouldn't.
They answer to this is simple. Only give info to the user's computer that it needs to draw the screen.
Comps ask each other for info, and only hand it out on request.
(So if I drive a jeffy to your base, my comp asks your comp for what your base looks like right now).
Requests are verified after the game, in a process that I will describe below.
demo verification, usually saved at all clients and server, control checkpoint hashes etc ...
again can be server controlled and verified ... ie ... if we know this unit have missfire rate X and there is wind Y and gravity Z2) Input cheats, where the user subtitutes computer input for their own (for example aim better than they should in a FPS).
This is not much of an issue in Spring, as the computer is way too stupid to play better than a human.
then cheater sending ABC values will trigger alarm or values will be ignored...
again server controlled and verified, player can't build over resouces he can manage to gain or have3) Rules-bending cheats, where the user ignores game logic about what they are allowed to do,
and for example puts up a vulcan in a tenth of a second.
These are more difficult to detect, but are possible.
Have each computer save each piece of info it gets from the other computers,
and each input it gets from the local user(s). After each game, the computers share all inputs with each other,
and rerun the game without any graphics in super ultra sped up mode.
They compare each piece of data they received during the game with each piece of data they generate after the game.
If there is a discrepancy, then a player cheated (and it should be pretty easy to figure out who).
Getting around this requires the cheater to generate command inputs that result in the EXACT same game as they just played by cheating.
That problem is probably as difficult as building a human level conciousness, so you've caught all cheaters.
player can't build at tech level he can't have etc
checking cheater AFTER he cheated is quite contraproductive because You are in free game,
not helping these he ruined his game already ...
anyone can create new account and cheat next minute again (or You believe in world of dynamic IPs and spoofing you can ban him easily?)
for that you need qualite generated Unique IDs
so once again i repeat most of cheats can be killed by server side processing and verificaiton ...Since you are already saving all data for the TA recorder (or at least can save all data),
it shouldn't be that difficult to implement this (and a bunch easier than an exe verifier that will be hacked in about .7 seconds).
if you ask who i'm then i'm one of co-directors of AASA (America's Army Server Admins) http://www.aaserveradmins.com
we cover several hunders game servers in free game America's Army (one of most cheat infested games after CS/CSS) ...
and we are utilizing best commercially developed anticheat to date PunkBuster from EvenBalance Inc. http://www.evenbalance.com
I think the only sort of cheat that will be a problem in spring is the one you call type 1.
Type2 input improving AI will be really hard to do in a RTS. In fact we encourage people to try to do this sort of things via the groupai interface (will be better documented some day).
Type3 just isnt possible with todays spring network format where only the users (or ais) orders are sent.
Type 1 on the other hand is really hard to defend against since the limited bandwith of todays internet make it very hard to send possibly 1000s of units in realtime to the players.
TA does indeed have sort of this network format but it only sends a complete update for a unit every 30 seconds or so and trust the clients to interpolate in between (only sending any new orders to the units).
Type2 input improving AI will be really hard to do in a RTS. In fact we encourage people to try to do this sort of things via the groupai interface (will be better documented some day).
Type3 just isnt possible with todays spring network format where only the users (or ais) orders are sent.
Type 1 on the other hand is really hard to defend against since the limited bandwith of todays internet make it very hard to send possibly 1000s of units in realtime to the players.
TA does indeed have sort of this network format but it only sends a complete update for a unit every 30 seconds or so and trust the clients to interpolate in between (only sending any new orders to the units).
Dwarden, your ideas are great, if you have the resources of the US Federal Govt to do everything serverside. Unfortunately, unless SY has a lot more funding than I think they do, we don't even trust the game server, so doing everything serverside just means that only hosts can cheat. I guess that might be a step in the right direction, but it is impractical given the current code.
I stand by my original thesis: if the users are given the capability to track each other from game to game, and the capability to tell when someone is cheating, then cheating will disappear instantly. After all, who will play with a cheater? So how do we give players the ability to tell when someone is cheating, and how do we give players the ability to track each other from game to game?
It doesn't matter if you use hardware strings to identify people (plus, are you really going to tell me I can't play from several machines?). Anyone with tcpdump can read the string, and use their own software to send their own string. Short of Palladium, you can't prevent people from controlling the information their machine sends out. That goes for all the punkbuster memory address info also. Fortunately, smarter people than either of us have solved the tracking people game to game problem.
Ebay does it right. Anyone can register. Anyone can register as many times as they want. However, once they are authenticated with a password, they have a point-based reputation system. If you cheat, you get negative feedback. If you don't, you get positive feedback. So if you are identified as a cheater, people won't play with you pretty quick. You can register a new account, but people can see you have no feedback and not play with you.
As for detecting the actual cheat, it can be done in game, but that creates an information cheat. So after each game, all peers compare notes. They do all the same comparison your server is doing in game, except they do it after the game when information cheats are impossible. If they flag a problem, then the computers tell the players who was cheating, and they can give negative feedback.
If it works for ebay with millions of dollars a day, it will work for Spring, WITHOUT rewriting everything from scratch and buying millions of dollars worth of bandwidth and servers...
I stand by my original thesis: if the users are given the capability to track each other from game to game, and the capability to tell when someone is cheating, then cheating will disappear instantly. After all, who will play with a cheater? So how do we give players the ability to tell when someone is cheating, and how do we give players the ability to track each other from game to game?
It doesn't matter if you use hardware strings to identify people (plus, are you really going to tell me I can't play from several machines?). Anyone with tcpdump can read the string, and use their own software to send their own string. Short of Palladium, you can't prevent people from controlling the information their machine sends out. That goes for all the punkbuster memory address info also. Fortunately, smarter people than either of us have solved the tracking people game to game problem.
Ebay does it right. Anyone can register. Anyone can register as many times as they want. However, once they are authenticated with a password, they have a point-based reputation system. If you cheat, you get negative feedback. If you don't, you get positive feedback. So if you are identified as a cheater, people won't play with you pretty quick. You can register a new account, but people can see you have no feedback and not play with you.
As for detecting the actual cheat, it can be done in game, but that creates an information cheat. So after each game, all peers compare notes. They do all the same comparison your server is doing in game, except they do it after the game when information cheats are impossible. If they flag a problem, then the computers tell the players who was cheating, and they can give negative feedback.
If it works for ebay with millions of dollars a day, it will work for Spring, WITHOUT rewriting everything from scratch and buying millions of dollars worth of bandwidth and servers...
Yeah, this is the easiest way to code the network stuff. Unfortunately, it leads to big problems if you want your players to keep secrets from each other.I think the only sort of cheat that will be a problem in spring is the one you call type 1.
Its probably a low priority to recode the entire network protocol, but I'm with Dwarden on this one. If you give info to a user's computer, then you kinda have to expect the user to get it. For example, even if you write a exe verifier (if that was possible), it is possible for the user to write a program that goes into memory and reads all the addresses to get all the info, and then overlays that information on the screen. It doesn't have to even be running in the same process (since you can assume the kernel can be convinced to give read access to the memory space), so the spring exe doesn't have to be modified to get an info cheat to work.
You can change the gameplay so that Fog of War isn't there and isn't needed, but then you lose the element of surprise, which is very cool. If you want to stop cheaters, you have to do it right, and do it from the ground up.
My advice (totally unasked for) is to wait until cheating is an issue, and then rewriting the network protocol (and everything connected to it) will happen quickly.
You could try implementing a reputation system in the battle room, and let the actual players find cheating, which would probably save you some work, but an info cheat isn't obvious. It just looks like I'm really good.[/quote]
Please tell me how You going to track WHO is WHO in free game ... i can create 1000 accounts in one batch (doubt there is flood control on it yet) ...
anyway even after this , it's free game , easy to made new account (same as America's Army) so this will not work so easily like You think ...
related to trustable server ...
You can always minor portion of "server" task to another machines (encrypted) and backward validate on background ... You will discover "server side cheating" much faster and easier than after game in demo sync comparing ...
anyway even after this , it's free game , easy to made new account (same as America's Army) so this will not work so easily like You think ...
related to trustable server ...
You can always minor portion of "server" task to another machines (encrypted) and backward validate on background ... You will discover "server side cheating" much faster and easier than after game in demo sync comparing ...
Dwarden, I'm not trying to flame here, but did you read my post? How does ebay do it? I can log into my ebay account from ANYWHERE, yet I am reasonably certain it is secure.Please tell me how You going to track WHO is WHO in free game ... i can create 1000 accounts in one batch (doubt there is flood control on it yet) ...
Encrypted password authentication is as old as time, and works great. Yes you can make thousands of accounts. Good for you. In my system, you just set your preferences in the battle room to only show games that have players who have at least X positive feedback, and no negative. Also make the ability to limit who can join your game, and you are golden. You with your 10000 accounts will be stuck playing games against other nubes. The nubes who don't cheat will get positive feedback pretty quick, and be let into the real games. The nubes who do cheat will always be playing other nubes, which might be a real ego boost, but wont bother anyone who actually CARES.
However, all of this is irrelevant. SJ has said that info cheats are the only possible ones. And those can't be detected. They have to be prevented by not giving the data to the computer in the first place. So until someone is willing to rip out all the old network code and replace it, plus like half the engine, Spring might as well be played with no LOS restrictions, or against people you know. There are no ways to detect info cheats, short of the cheater bragging about it (which is probably more common than you think).[/quote]
Maybe one way to detect information cheating would be to inject fake events that would not be visible to a non-cheating player. So if the cheating player reacts to this information he has been detected.
I don't really know what the fake events would be. I must be something that definitely would get the cheating players attention.
Hmm...maybe not...
I don't really know what the fake events would be. I must be something that definitely would get the cheating players attention.
Hmm...maybe not...
That is a great idea!Maybe one way to detect information cheating would be to inject fake events that would not be visible to a non-cheating player. So if the cheating player reacts to this information he has been detected.
I don't really know what the fake events would be. I must be something that definitely would get the cheating players attention.
You could add a "just kidding" to the network protocol. Then send things about nukes flying constantly in all directions, and fusion plants being put up in random places, with krogoths marching to destroy you. As long as the "just kidding" packet was sent before a non-cheating player would see it, then the cheater will be deluged in a shower of misinformation...
That would be really amusing. Cheater spends hours coding cheat. Loads up first game, turns it on, and is like, "HOLY SHIT! HOW DID HE GET NUKES IN THE FIRST 4 MINUTES?"
It seems like you'd have to be really clever with your misinfo to make it plausable though. Otherwise, the cheater could detect it pretty simply.
in Your system each of my imaginary useless accounts will be used to give each other "bonus" prestige (scripted again) and in the end Your "point" reward system will be same cheated or more than game itself ...In my system, you just set your preferences in the battle room to only show games that have players who have at least X positive feedback, and no negative. Also make the ability to limit who can join your game, and you are golden. You with your 10000 accounts will be stuck playing games against other nubes. The nubes who don't cheat will get positive feedback pretty quick, and be let into the real games. The nubes who do cheat will always be playing other nubes, which might be a real ego boost, but wont bother anyone who actually CARES.
Good point. However, what stops people from doing this on ebay where it matters? They must have some solution.in Your system each of my imaginary useless accounts will be used to give each other "bonus" prestige (scripted again) and in the end Your "point" reward system will be same cheated or more than game itself ...
One thing would be seeing if you got more than a couple different accounts coming from one machine. That would be a clue that something bad was up. But there must be a solution, since ebay's entire business model is based on it.
You could still implement a system of trust using public key encryption, but that is getting kinda complicated. I'll bet that there is a simple solution. Still, if you needed to, there are plenty of PKI libraries out there.
Well hardware (of course you need use combination of more than 2 devices) based generated unique IDs are best option available ... that will force cheaters to get new hardware after ban or work out complex solutions on low level base...10053r wrote:Good point. However, what stops people from doing this on ebay where it matters? They must have some solution.in Your system each of my imaginary useless accounts will be used to give each other "bonus" prestige (scripted again) and in the end Your "point" reward system will be same cheated or more than game itself ...
One thing would be seeing if you got more than a couple different accounts coming from one machine. That would be a clue that something bad was up. But there must be a solution, since ebay's entire business model is based on it.
You could still implement a system of trust using public key encryption, but that is getting kinda complicated. I'll bet that there is a simple solution. Still, if you needed to, there are plenty of PKI libraries out there.
The solutions are not complicated though. You just pull up your copy of tcpdump and figure out which packet is being sent contains the hardware id. Then a little assembly hacking makes sure that you never send that hardware id again. As long as I have root on my system, I have COMPLETE CONTROL on what gets sent over the wire. So your imaginary hacker with 1000 accounts still gets 1000 accounts. You can kinda fix that if you make him come up with unique ips, but that only limits him a little, because as you said dynamic ips are a dime a dozen.Well hardware (of course you need use combination of more than 2 devices) based generated unique IDs are best option available ... that will force cheaters to get new hardware after ban or work out complex solutions on low level base...
Hardware ids are like CSS encryption on DVDs. 5000 semi-morons online can break it in about 10 seconds, there are like 50 different ways to do it, and anyone who is trusting it for security is kidding themselves big time.
Reminds me of the time my ex-boss wanted to distribute files in "locked .pdf". LOL.
Looks like we might be stuck with a PKI web of trust. That would actually dodge the cheat issue entirely. As long as you have revocable vouching, a cheater gets no games really quick. And you could just vouch for people you know and have played a few games with, so you could be pretty sure they werent cheating...
As for the texture and model "cheats", it does not matter in the slightest, each player has their own information, the important stuff (like the scripts, weapons and suchlike) should be checksummed (like they are in OTA) and there is no or near to no advantage in changing the textures or models.
People couldnt get any advantage from changing the models or textures in OTA as far as I know.
People couldnt get any advantage from changing the models or textures in OTA as far as I know.
I've been thinking about this problem for a while.
I think I have a solution to both the cheating problem and the player modifications problem.
---
Create a closed source file verification program. We'll call it Anti-Cheat. Yes, I know Spring is open source, and it can stay that way. This program will operate independently from spring and will be non-essential.
In a game lobby allow the host to check a box labeled "Verify Files." If this box is checked when the host starts the game Anti-Cheat will start. The server will then randomly generate a key and send it to AntiCheat running on both clients.
Anti-Cheat will then use this key to create an MD5 type hash for each Spring related file in each client's Spring folder, and send these hashes back to the server.
The server will check to see if the hashes sent to it from each client match.
If they do, we can be sure that neither player has made modifications to their client, and that the game will run without risk of desynchonization or cheating.
--
This will not prevent players from modifying values in memory, however.
Perhaps the key could also be used by the client to encrypt data stored in memory and sent over the network. When data is taken out of memory or recieved from another player it could be fed through a function that would decrypt it.
Clever hackers may still be able to figure out the key and modify the actual encrypted values in memory, but this would certainly get rid of most script kiddies.
---
I also like the Ebay style feedback thing that people have proposed.
Perhaps at the end of each game each player could be asked (by the spring lobby server) if they wish to provide feedback about an opponent. Depending on the quanitity of positive feedback the person has recieved themself they could have a greater effect on the feedback rating of others.
To prevent people from using bogus accounts to make their feedback rating very high, players could be required to have played a certain number of games against others who have positive feedback ratings before being able to give feedback to another person.
I think I have a solution to both the cheating problem and the player modifications problem.
---
Create a closed source file verification program. We'll call it Anti-Cheat. Yes, I know Spring is open source, and it can stay that way. This program will operate independently from spring and will be non-essential.
In a game lobby allow the host to check a box labeled "Verify Files." If this box is checked when the host starts the game Anti-Cheat will start. The server will then randomly generate a key and send it to AntiCheat running on both clients.
Anti-Cheat will then use this key to create an MD5 type hash for each Spring related file in each client's Spring folder, and send these hashes back to the server.
The server will check to see if the hashes sent to it from each client match.
If they do, we can be sure that neither player has made modifications to their client, and that the game will run without risk of desynchonization or cheating.
--
This will not prevent players from modifying values in memory, however.
Perhaps the key could also be used by the client to encrypt data stored in memory and sent over the network. When data is taken out of memory or recieved from another player it could be fed through a function that would decrypt it.
Clever hackers may still be able to figure out the key and modify the actual encrypted values in memory, but this would certainly get rid of most script kiddies.
---
I also like the Ebay style feedback thing that people have proposed.
Perhaps at the end of each game each player could be asked (by the spring lobby server) if they wish to provide feedback about an opponent. Depending on the quanitity of positive feedback the person has recieved themself they could have a greater effect on the feedback rating of others.
To prevent people from using bogus accounts to make their feedback rating very high, players could be required to have played a certain number of games against others who have positive feedback ratings before being able to give feedback to another person.
Last edited by web on 29 Apr 2005, 01:11, edited 1 time in total.
Perhaps those could be hased too, but in cases like that the other player could be told something like:Tangaroa wrote:Any anti hack feature that makes hashes of Spring related files should not affect things like textures and models, so that people can make better looking versions and still play against others online.
All of your opponent's files were sucessfully verified except for:
Unit Models
Unit Textures
This should not affect synchonization, but may give your opponent an advantage.
Continue? YES/NO