Anti Cheat

Maelstrom · Post by **Maelstrom** » 30 Jan 2006, 10:55

There has been a bit of discussion going on in the forums about cheating, and how easy it would be. Because of spring being open source and all, people could just modify the code, compile it, and no one would be the wiser about their modified EXE.

Ive though up a way around this potential problem. I know that currently there is no cheating going on, but eventually someone will decide to cheat. There is no stopping people like that.

So, onto my idea.

I suggest one variable/function or something be added to the code, that ONLY the SY's know about. This variable/function is NOT included in the source code released. What this will do is tell other clients if the EXE someone is using is the official SY release or not. Thats all it would do. It would not prevent people from playing with the non-standard EXE, but would just display a message on everyone elses computer that a user is using a potentially hacked EXE.

I know that cheating/hacking is not a problem yet. I know that there is currently no need for this. But this could possibly solve alot of problems regarding cheating that will pop up in the future. It in no way has to be implemented in a release any time soon, but if cheating is looking like it might be an issue, this could possibly be implemented to stop cheaters, atleast for a while.

BvDorp · Post by **BvDorp** » 30 Jan 2006, 11:58

We need some sort of cheating handling code, even if it is for the sake of Group AI's alone. The code should be closed.. but this is kinda hard to do, for the other (open) code will have to communicate with it, and there's your door for cracking it..

The easier way: let the sync be kinda strict, so other's pc's will notice immediately if there's something weird going on. Earlier discussions led to the following:

- Cheating, as in more resources etc, is nearly impossible atm for every pc synces, and cheating will lead to sync errors
- Easy way of cheating is the LOS
- Easy way of cheating is using modified Group AI's

Is there any way to make such 'closed' code possible?

Problem: cheating is not at hand, so this problem is not high on the priority list atm. This discussion is usefull, but I suggest putting this low on the list.

Tobi · Post by **Tobi** » 30 Jan 2006, 12:19

I suggest one variable/function or something be added to the code, that ONLY the SY's know about. This variable/function is NOT included in the source code released. What this will do is tell other clients if the EXE someone is using is the official SY release or not. Thats all it would do. It would not prevent people from playing with the non-standard EXE, but would just display a message on everyone elses computer that a user is using a potentially hacked EXE.

Is there any way to make such 'closed' code possible?

Code wise, this is possible (technically: make a sourcefile with a global singleton which calculates checksum and somehow connects to somewhere to check that checksum or stores it in a global var so that open source networking code can send it).

However, license wise, this is NOT possible, because not publishing all source code for the application (read: the released version) is a violation of the GPL.

Also, you can implement it, but if someone really wants to cheat, they'll figure out how to do that anyway. If the exe checksum checking code sends the checksum to the host for example, one would just run a packet sniffer on his network, look for the checksum package, and add some code to the open source part of the code to spoof that message.

So IMHO we'd better spent our development time on other things...

- Easy way of cheating is using modified Group AI's

Based on opinions/facts in another thread and this one I think we should somehow disable groupAI's being capable of 1st person view orders like D-gunning aircraft.

IMHO, only thing which is guaranteed to work is banning/kicking, either just kicking cheaters by the game host or banning them (their IP) entirely from master server. Won't work of course for people with dynamic IP...

Aschmo · Post by **Aschmo** » 30 Jan 2006, 16:55

Putting in some properitary code that will say cheat or no-cheat will not work out. People always find out ways to reverse-engineer something. You (well... I'll be talking of "you" until I am able to contribute) need to use an algorythm, that uses asymetric crypto - just like in PGP.

So the host (or peer) will send a random number to the other spring. Both calculate checksums with the rand and the binary/resource files and send the results back. If the checksums differ, something is wrong :-)

Well, there is still a chance to get around this if the cheater uses some kind of man-in-the-middle attack. He starts his hacked spring, that will send any crypto stuff to a "legal" spring, that will do the right calculations.

Another thing is, that this aproach will limit games to be possible only with the same builds of spring. Even minor version changes or builds for other platforms/architectures (x86 vs amd64, e.g.) will violate the checksums.

AF · Post by AF » 30 Jan 2006, 20:07

GroupAI cant cheat in the ordinary sense, the onyl cheating they could do as such are things such as exploiting computer pwoer to fine tune thigns or play the game for you.

That and the fact that a groupAI runs from a dll and as such could easily be covertly planted and be used as a backdoor to gain information about the other player but that would be very unusual. GroupAI's dotn even have access to the cheat interface (globalAI only)

Isaactoo · Post by **Isaactoo** » 31 Jan 2006, 05:11

It would be nice to prevent hackers from cheating by modifying the copy of the game they are playing with...but there are much easier ways to cheat right now. Such as useing F1 to aid you in finding flatened pieces of terrain that your enemy has put buildings on, or clicking on a plant and looking for a place to build on the other side of the map to see where any units are blocking the possible construction site.

Kelson · Post by **Kelson** » 31 Jan 2006, 12:08

As Tobi was saying above, it isn't really possible to stop or detect anyone cheating at TASpring. As long as the project is open source, that will always be the case (when closed source, it is just much harder - far from impossible). While we're all afraid of the big bad cheats, there isn't any way to win that fight - development time is much, much better spent on enhancing the engine (currently, making it portable).

Re: AF => That's not quite true. GroupAIs can also gain access to information they're not supposed to have. That is stuff players can't see unless they hack the engine themselves (a trivial task, actually).

And what do you mean GroupAIs could be used as a backdoor? GroupAIs have no way to communicate (currently) with other players. Unless they were designed to create an internet connect to a specific host and send data (which would then need a complicated system to even make it be somewhat useful)...they can't spy, per se, on other players in any meaningful way. There are far, far, FAR easier ways of being malicious, if one needs, than trying to plant a trojan GroupAI for other people to download. That would be similar to building a giant wooden horse for people to pull into their city...although they're all asleep and they left their doors open so you could just walk in.

Aschmo wrote:So the host (or peer) will send a random number to the other spring. Both calculate checksums with the rand and the binary/resource files and send the results back. If the checksums differ, something is wrong

And even beyond the man in the middle opportunities - don't forget the cheater has full access to the source code. They could simply look at what the checksum should be calculated on (thus what the correct result should be) then turn in whatever results you want. If you can't trust the client, you can't validate them.

Post by **Tim Blokdijk** » 31 Jan 2006, 13:14

It's hard to cheat with Spring.
Once you change a little thing checksums are different and you lose sync.

That the source is available won't help a cheater in any way.
Would be the same argument that Linux is insecure because the source is available.

Maelstrom · Post by **Maelstrom** » 31 Jan 2006, 17:23

But you could easily rig the game to send back a 'valid' checksum, instead of the real thing.

Kelson · Post by **Kelson** » 31 Jan 2006, 19:25

Tim Blokdijk wrote:It's hard to cheat with Spring. Once you change a little thing checksums are different and you lose sync.

Maelstrom already addressed this, but I feel I should really comment as well since many people have responded to me about checksums being the end all and be all of detecting and preventing cheating.

Suppose you wish to calculate a checksum on the TASpring executeable at run-time. This information will be calculated when the game begins and sent to the host to compare with his 'good' copy. If they're the same, everyone is playing the same game. If not, someone has a different game version! Sounds good in theory...except it is very easy to fake a valid checksum. I know how large a valid executeable is, I can calculate a valid checksum for such an executeable (heck, I might keep one in the TASpring directory just for that purpose) and send it to you. There are many, many points of attack against such a system given both of those. Just a couple off the top of my head:

Catch the data being sent and inject the proper checksum (instead of the one Spring tried to send).

Modify the checksum code to always calculate it based of the valid executeable instead of the one I'm actually running.

Modify the checksum checking code to automatically send the valid checksum instead of even calculating it.

AF · Post by AF » 31 Jan 2006, 20:17

And what do you mean GroupAIs could be used as a backdoor? GroupAIs have no way to communicate (currently) with other players.

Kelson, thats a loada b*llocks. GroupAI dll's can be written in C and therefore given you compile the thign with the right headers, have the ability todo whatever you code it todo wether ti be search for flat terrrain then plonk down the most likely building it would be by comapring its footprint against untidefs, or initialising API hooks and other malicious activities.

You also forget that being c++ and not a scripted code it has the necessary API calls to find the host, or generate a GUI for the user to type in the hosts IP, it has the tools to communicate through spring (fiddle around witht he priority values, say a priority higher than 10? It'd get sent through but be filtered out for the player... There's just so much stuff that could be done.....

Your also forgetting that grouPAI could implement their own method rather than using an engine provided system. Shall I make a version fo NTAI that collaborates across different games using some protocol such as MSN or Jabber? Or SMTP? or some arbitrary protocol over the net

Kelson · Post by **Kelson** » 31 Jan 2006, 20:52

AF wrote:Kelson, thats a loada b*llocks. GroupAI dll's can be written in C and therefore given you compile the thign with the right headers, have the ability todo whatever you code it todo wether ti be search for flat terrrain then plonk down the most likely building it would be by comapring its footprint against untidefs, or initialising API hooks and other malicious activities.

And that has what do with my comment? Being written in C, or C++, or Java, or Lua, or Ruby, or D, or Pascal, or any other language doesn't make a difference. My comment was responding to your claim a GroupAI could spy (note- I said it could, just that it isn't trivial)

AF wrote:You also forget that being c++ and not a scripted code it has the necessary API calls to find the host, or generate a GUI for the user to type in the hosts IP, it has the tools to communicate through spring (fiddle around witht he priority values, say a priority higher than 10? It'd get sent through but be filtered out for the player... There's just so much stuff that could be done.....

What are you talking about? The GroupAI interface doesn't send across the network - it is local only. That means you can't send data - irregardless of filtering. And being a scripted or compiled language doesn't matter with regard to APIs and such - the API and GUI setups fall into what I said about it being possible, but they aren't assisted by the spring engine.

AF wrote:Your also forgetting that grouPAI could implement their own method rather than using an engine provided system. Shall I make a version fo NTAI that collaborates across different games using some protocol such as MSN or Jabber? Or SMTP? or some arbitrary protocol over the net

I forgot that?? Odd...because that's what I specifically SAID it would have to do. As long as you have some nice way of pulling all the required addresses of other players - go ahead, I'd like to see it as a proof of concept on a GroupAI. I know it is possible, but I don't think it is simple (or assisted by spring). I don't know if you're trying to win some pissing contest here, but at least try to read my posts.

Kelson wrote:There are far, far, FAR easier ways of being malicious, if one needs, than trying to plant a trojan GroupAI for other people to download. That would be similar to building a giant wooden horse for people to pull into their city...although they're all asleep and they left their doors open so you could just walk in.

This analogy, in laymen's terms, means: There are much easier ways to do what you're saying without doing it through the restricted GroupAI interface. All those API hooks and garbage could be done outside of spring completely. It isn't necessary for them to be run as a component.

AF · Post by AF » 31 Jan 2006, 20:56

I was responding specifically to groupAI statements you'd made, I didnt say that you had to use groupAI either. But you felt the need to go through ym post and nitpick so I know now that I need to proof read extensively or it'll go on for ages now.

Post by **Tim Blokdijk** » 31 Jan 2006, 21:01

Kelson wrote:...
Suppose you wish to calculate a checksum on the TASpring executeable at run-time. This information will be calculated when the game begins and sent to the host to compare with his 'good' copy. ...

Catch the data being sent and inject the proper checksum (instead of the one Spring tried to send).

Modify the checksum code to always calculate it based of the valid executeable instead of the one I'm actually running.

Modify the checksum checking code to automatically send the valid checksum instead of even calculating it.

As far as I know Spring won't send a checksum at the start of the game.
Each game "tick" has a checksum based on unit positions, metal/energy los and some other stuff.
I don't see how you could hack around it.
Other then use a AI to help you manage your units.

Even if you manage to run Spring in a "un-synced" state and calculate the correct checksum for a game in sync you still have to somehow make the other clients ignore the fact that your data is not matching the checksum.

And then still if you have units that have more health or do more damage that is still a local hack, the other clients won't use the same data to calculate there gamestate.

But if you like to work it out, Spring needs new more flexible netcode to make it run in sync across different platforms and processor architectures.

Kelson · Post by **Kelson** » 31 Jan 2006, 22:27

Tim Blokdijk wrote:As far as I know Spring won't send a checksum at the start of the game. Each game "tick" has a checksum based on unit positions, metal/energy los and some other stuff. I don't see how you could hack around it. Other then use a AI to help you manage your units.

Sorry for not being clear - I was saying IF one wished to...they could calculate it when the game began...etc..etc (and in reference to the executeable, not game state). Regarding the sync/unsync thing I wasn't trying to make any comments about that.

Cyberwal · Post by **Cyberwal** » 01 Feb 2006, 01:45

I think the time-based ranking system is a great way to counter cheaters already, because many people cheat for better stats

I think automagically comparing replays to see if someone cheated afterwards would be a viable option for tournaments and such, like a program that checks whether all replays are consisten and consistent within the rules of the game.

Spring RTS Engine

Anti Cheat

Anti Cheat