Some Thoughts on PBEM / IP Cheating -- Hubert Please Read

[JerseyJohn]

[originally posted at SC Forum]

This was really intended in relation to regular SC but it leads into some ideas that might help curb cheating, at least in PBEM reloads, so I thught I'd post it here as well. The idea is highlighted in bold print below.

--

To begin with, PBEM is unsuitable for competitive games. Players, I don't care what the game is, can't compete when any of the elements in volved is the other player's honor. Most people have it most of the time but during the decades I played in chess tournaments there were always numerous safeguards to insure neither player was doing anything unethical -- in other words the option was taken out of the players hands, which is the way it should be.

So if you're playing PBEM it's only for a recreational game. Some of us prefer it that way. SC isn't something I want to study and I don't want to worry about winning or losing, it's just something I enjoy relaxing with. Those of us who don't see this as a competitive activity don't worry much about cheating, why should we?

If you're any good at this you can reload moves without having it show up in the file -- yeah, yeah, I know the comments that will follow, but if that were the case I ought to never lose. Well I do lose so that's shot out the window and I've also won a lot. Anyone who wants to think I cheated is free to do so, those games were so important that none of the accusers would even know who they were played against, but I'm sure it will come up anyway!

It would be very good if there were a way of saving PBEM games during a move because occasionally you have to leave the machine without being able to finish what you've started. It would also be good if reloads were impossible. The same people who play PBEM now would still play that way if it were impossible to reload; if they're PBEM players they aren't obsessed with winning and cheating would be senseless for them.

Maybe the way to stop reloads would be to have a system where the move can only be downloaded once in a player's turn, from there it can be started and saved any number of times -- things like undo should be automatically disabled and FoW automatically turned on in PBEM and IP games, in other words, there should be a tournament mode. Once begun, a game should be savable but it would always move forward, no way to go back earlier than the point it was saved at.

I've read things from time to time that there is even cheating in IP games. I have no idea how any of that would work and can't speculate on it.

But the thing is this, if it's possible to cheat at a game then that game isn't really suitable for competitive play.

[ May 06, 2004, 03:44 PM: Message edited by: JerseyJohn ]

[vveedd]

Only way to decrease cheating is that game have luck factor at minimum in all aspects. I said <decrease> not removed because there is no way to do that except to make a game like chess. But good example of PBEM game is Civilization 3 Conquest. You CAN cheat in this game but it need lots of work.

In <old> SC, research concept has very powerful influence for final outcome and if someone wants to cheat he will cheat in research for sure. I Hope that Hubert realized that.

[JerseyJohn]

The kind of cheating I'm talking about, and what is commonly discussed, is where one of the players keeps playing his move over till he finally likes it -- along the way seeing where his enemy's units are etc & etc. ... in other words, reloading the move.

It has nothing to do with the game itself.

What I'm suggesting is a kind of file that can only be downloaded once after which the download won't open. Once downloaded and opened the player would be able to save it at any point and resume playing again later at that point till he's finished his turn. At which time the file can only be saved and sent back to the other player. I don't know if such a file exists but I think it would be the only way to stop PBEM abuses and make it possible for SC to be a game for players who want to use it in tournaments.

[Arngrim]

Good idea, but in that case there would have to be a safeguard against crashes. SC crashes for me occasionally, ag. AI it is a bummer to have to do the turn again, but versus a human it is noted as a reload. If all moves up until the crash were cached, and the turn would restart where you were that would solve that problem.

[fischkopf]

Just some input from a professional programmer (and a big fan of SC, and someone who sometimes replayed his PBEM moves...):

A sytem to prevent replaying moves can easily be implemented.

(Note that this is transparent to the user, except for when he tries to replay a turn).

SC generates a unique (say, 256-bit) number whenever a new PBEM game is created. This number is attached to all saved turns.

When the other player first plays the saved turn, the game's id and the current turn number are added to a locally stored cache of recent games. If he tries to replay it, the game id and the turn number will be in the cache, and SC can detect it.

In this manner the only turn that could be replayed would be the first. Deleting the saved turn, and getting it again from your email account wouldn't work because that particular game's unique number is stored in your cache.

The cache could easily be 100 or more games because the amount of data being stored is very small, 7 bytes + 1 for current turn number in the 256-bit example. This has to be cleverly hidden by Hubert, ideally in a combination of registry keys, game folder, and a uniquely named hidden file on the user's hard drive.

There are ways for people to cheat this system, but it would be very involved and certainly less than 1% of the population could do it.

For better security, the SC clients would need to be registered with server and would need to communicate with it for each turn. Not a big deal, but still probably not worth the effort.

But something should be done, because I really enjoy PBEM (TCIP involves too much waiting), but I don't enjoy the cheating, even when it's me that's doing it..

[JerseyJohn]

fischkopf

Excellent -- thanks for putting an idea in such precise programming terms. I've edited the title to try and get Hubert's attention and response, which I don't do unless I think it important that he comment on an idea -- hopefully he will.

Mr Cater, I cede the floor ...

[Les the Sarge 9-1]

Very impressive sounding.

Surely there has to be some manner of encypting that data or making it so each time it is saved, the act of reloading is made known so that a person could see that a game is always being multiple saved and blow the whistle.

Because let's face it, a game that is known to be near cheat proof, is going to sell FASTER.

And while errors might account for 1 or two reloads in the course of a full playing of a game, it should not be something that shows up at all in some games, if not most.

In all my PBEM games, I have never had any trouble with playing a full turn, and sending the turn, and having any trouble.

I have asked that a person resend me a turn before, but then, I actually asked for that.

Personally, I think who ever really and truely cracks the security issue, might be deserving of a complimentary copy of the game

[Hubert Cater]

A sytem to prevent replaying moves can easily be implemented.

Hehe... this is always easier said than done

While I won't discount that a 100% cheat prevention system is possible, if the system requires stored data in order to work I suspect even this system will eventually be cracked by someone. Realistically all it takes is one person or even the rumour that it is possible (to crack the system) and the confidence of a cheat proof PBEM game is shattered. (Read the recent posts in the SC forum about FoW sniffers etc. and current tournaments and you'll get an idea of what I am refering to).

I've read your post and I've even had a similar proposal in the past and while it *could* work in theory, I feel there are just too many issues that need to be addressed before it can be truly considered *easy*

SC generates a unique (say, 256-bit) number whenever a new PBEM game is created. This number is attached to all saved turns.

Unique numbers are tricky as it would have to be unique across all SC systems guaranteed. For example, in order for this to work, no two systems can generate the same number otherwise Murphy's Law applies as the possibility of PBEM turns clashing is more than likely.

Unique numbers (across all SC systems) may be possible with some specific manipulation, but off hand I don't know of an easy way to do this.

Also attaching this number to all saved turns is another problem as anyone with a hex editor will be able to edit this value in their favour.

The cache could easily be 100 or more games because the amount of data being stored is very small, 7 bytes + 1 for current turn number in the 256-bit example.

I'm not sure if I understood your whole concept here, but from what I understand this might be Ok for the id and turn number but you would still need to store all the saved games which would make storage considerably larger. Again if you store these turns on the system someone will be able to track it down and manipulate/delete them as necessary in order to cheat.

Keep in mind that each turn is a completely separate file, there is much more data than a single turn number stored here that makes a saved file unique from any other saved file.

But something should be done, because I really enjoy PBEM (TCIP involves too much waiting), but I don't enjoy the cheating, even when it's me that's doing it..

Sure but I really think that if a good system existed it would have been done by now. Good news is that I haven't completely ignored the cheating issue and have even added some improvements/encryption that should make TCP/IP as well as PBEM games slightly more secure from basic cheats but unfortunately I still think the PBEM reloading issue will always be with us no matter what we do.

Hubert

[Hubert Cater]

JerseyJohn

Just because you change the topic heading does not mean I'll answer everytime

Hubert

[JerseyJohn]

Hubert

True, but even if it only works once in a while it's worth doing!

Thanks for that reply Mr C., it went a long way toward explaining the issue and at least there will be improvement in the system, which is all anyone can ask for. :cool:

[jon_j_rambo]

Hubert --- Thanks for your honest, open comments. Just do the best you can.

[vveedd]

Originally posted by JerseyJohn:

The kind of cheating I'm talking about, and what is commonly discussed, is where one of the players keeps playing his move over till he finally likes it -- along the way seeing where his enemy's units are etc & etc. ... in other words, reloading the move.

It has nothing to do with the game itself.

Yes I understood what you meant. My post about research is also in that issue. You can reload game until get new tech as well as to get good moves. Player can do that because research concept depends on luck too much. I didn’t mean to criticize game in generally.

Well, I am not a programmer and don’t understand what you are saying above but I have one suggestion too. It is called PBEM ONLINE. We can have servers where we will send our turns. Players will log in and play his turn online directly on server without downloading turn. In that way we can avoid reloading because if someone want to log in again opponent player will be noticed automatically. I am sorry if I am talking impossible stuff but as I said I am not a programmer and I don’t know much about computer.

[JerseyJohn]

vveedd

Now I see what you were saying, yes, that's part of the problem, one of the worst parts although any advantage gained from reloading is equally bad.

That online PBEM game you mentioned sounds perfect -- wouldn't Battle Front have to set it up, though? Providing the server, etc ... it sounds like something like that can be done as an offshoot serviece with a monthy fee and no doubt a lot of people wouldn't mind paying it if they could play against one another without having all these problems.

Last year the leagues started out as all PBEM and it would be hard to imagine all the accusations that went back and forth. Problem is it's often difficult to deal with one guy having a lucky game while the other may be having no luck at all.

[fischkopf]

Just to clarify.

Uniqueness:

A 100-bit number gives you the following number of combinations:

1,267,650,600,228,229,401,496,703,205,376.

That's a large number. That alone would effectively guarantee uniqueness. (Note that lotto 6-49 gives you odds of 13,983,816 to 1. Compare the number above to 13,983,816 then think about how often you've won lotto 6-49).

Also, I was suggesting you use 256-bit ids. For every 1-bit increase, the number of ids doubles. So double the huge number above, and keep doubling the result 155 more times. I can assure you, you will not have two games with the same id.

As for the size, each key is 256bits + a turn number (you only store the latest turn for a particular game), so that's 33 bytes. If you store up to 100 of these on a player's machine (so he couldn't cheat on his last 100 games) then you're using 3300 bytes. That's 3k. The size of a small readme.txt or an extremely small image file. Size is not a problem.

As for someone finding out the locations of the stored keys and telling others:

Ideally you would store 2 copies of the keys (we're now using 6k. peanuts). One would be hidden in the registry, under a name unique to that particular install of SC. (Could be a hashed value from the hard drive ID). And another copy of the keys would be stored in a hidden file on the machine, also with a name unique to that machine. This name can be hashed from hardware settings, or just be randomly generated and hidden itself.

So it would be extremely difficult for someone to be able to find _both_ sets of keys (the game would query both locations before allowing a turn to be played). And even if a person did find both locations, they couldn't tell others because the files/registry keys would be different for everyone's machine.

It's a basic technique in security and it's tried, tested and true.

I think it would benefit SC enormously. In terms of implementation time, I've written similar systems in a day, but these things always vary with the project so it could be longer.

[fischkopf]

Just a note about someone cracking the system.

I'll be the first to admit that someone somewhere will crack this. For some it's just fun to take on the challenge.

To be perfectly honest, if this we're implemented I'd try to crack it myself. (Yes, I cracked the time-crippled demo versions of SC, just to see if I could. Yes, I cracked the CD-requiring version (remember that one?)).

But very few people would or could crack it, and the crack would not readily apply to other's people's installs.

So ask yourself, how many people successfully cracked the time-limited demo of SC? Very few. How many people cheat on PBEM replays? Many.

Would you not rather have very few people cheating on PBEM replays?

[aka_tom_w]

"Sure but I really think that if a good system existed it would have been done by now. Good news is that I haven't completely ignored the cheating issue and have even added some improvements/encryption that should make TCP/IP as well as PBEM games slightly more secure from basic cheats but unfortunately I still think the PBEM reloading issue will always be with us no matter what we do."

I find that VERY regretable.

Are there other PBEM war games out there that PREVENT the reloading until you get the desired result problem?

I could be wrong and I know CMxx is a different type of game but its PBEM system prevents "reload until you get the desired result" does it not? (it also has a slow multi step PBEM cycle involving mulitple e-mail transfers but as far as I can tell you CANNOT reload the turn in PBEM CMxx to get the desired result.

Is the solution NOT just as simple as a multi step PBEM transfer sequence that does NOT let the player see the result of the turn in which the result one turn that player can "reload". Why is it that one player gets the "opportunity" to see the result of something they might not like and THEN can simply re-roll or reload the turn?

Why does a PBEM player have that much choice or control over the "PBEM system"? There ought to be a better way?

If all you have to do to cheat is reload the turn and keep looking for the improbable outcome (whatever is good .... snake eyes? box cars?) and there NOTHING but the honour system to prevents it this, then GUESS WHAT amongst war gamers EVERYONE will be or "should" be doing it because they are figuring why not reload until I get the result I want "Because I KNOW my opponent is doing it too!"

If the reloading/cheating issue is not addressed, all PBEM players "should" be (will be) wondering if their opponent is reloading the turn and thus re-rolling the dice or combat odds outcome until the prefered result is obtained.

IMHO this makes PBEM games somewhat tainted or "objectionable" (sadly)

Is there not a secure "tournement PBEM protocol" that could be offered?

-tom w

[ May 07, 2004, 10:52 PM: Message edited by: aka_tom_w ]

[With Clusters]

The WEGO system is the critical component (along with the somewhat complicated emailing sequence) that prevents PBEM cheating in CM.

[Hubert Cater]

fischkopf

So it would be extremely difficult for someone to be able to find _both_ sets of keys (the game would query both locations before allowing a turn to be played). And even if a person did find both locations, they couldn't tell others because the files/registry keys would be different for everyone's machine.

Hmmm... I could be wrong here, but the only thing you would have to do to cheat this system is edit the number assigned to the PBEM file each time you wish to reload, correct?

If so, this would be just one extra step beyond what is in place now and in this case there would be no need to try and track down the hidden values in registry keys etc. as the game would consider it a new PBEM file each time.

[Hubert Cater]

aka_tom_w

I find that VERY regretable.

Unfortunately there are some inherent limitations to the turn based system, but as I mentioned before at least the encryption of most data will help secure SC2 from some of the more popular cheating methods seen in SC1 like RAM cheats and so on.

In the end, and as even stated by fischkopf, the likelyhood of a completely secure system that cannot eventually be hacked is very minimal. The sad reality is that if someone really wants to do it eventually they will figure out a way (think of all the great minds and resources a company like Microsoft must have and how many security updates have they had to produce recently )

Now I could spend a lot of time and effort constantly trying to prevent cheating with updates and security patches... but instead I've decided to at least make it slightly more difficult and concentrate more on gameplay and design as unfortunately my resources and time are more limited.

Hope this helps,

Hubert

[aka_tom_w]

Dear Mr. Cater

I would like to applogize if the tone of my posts was overly critical.

Thank you for your straight forward and prompt reply.

I am sorry that my past experience with cheaters of all stripes may have colored my posts in a less than flattering light. My applogies.

I appreciate your efforts and I am sure you are also keen and clearly interested in designing a game system as "cheat proof" as possible.

I have been playing war games for over 25 years and it seems to me someone ALWAYS cheats or tries to cheat. Or some players turn into rules lawyers and cheat by bending the rules or totally exploiting gamey loopholes in ANY rule system or gameing system. My experience with wargamers in general is that instead of tyring to win the battle they are in fact far more interested in finding the loopholes in the rules or exploiting some "crack" or weakness in any game system to gain the advantage. It is sad but true I think.

I am hopeing that as a game designer you are more than aware of the tendency amongst keen gamers to exploit every possible crack/hack/weakness or loophole in the system to their advantage because as I am sure you are more than aware we are ALL very competitive about winning!

So my point was; if re-loading the turn is not actually "cheating" and it can be done over and over again until the desired combat result is achieved why would any player believe his opponent was NOT doing it when in PBEM play it would appear it is IMMPOSSIBLE to get caught doing it and there is no possible way to detect if it is being done?

If I am mistaken about the facts in that last part:

" if re-loading the turn is not actually "cheating" and it can be done over and over again until the desired combat result is achieved why would any player believe his opponent was NOT doing it when in PBEM play it would appear it is IMPOSSIBLE to get caught doing it and there is no possible way to detect if it is being done?"...... I hope you will correct me, because I fear I may be overstating the problem or not understanding the issue suffciently to comment on how it might be prevented.

Thanks again for your very prompt and insightful reply.

-tom w

Originally posted by Hubert Cater:

aka_tom_w

I find that VERY regretable.

Unfortunately there are some inherent limitations to the turn based system, but as I mentioned before at least the encryption of most data will help secure SC2 from some of the more popular cheating methods seen in SC1 like RAM cheats and so on.

In the end, and as even stated by fischkopf, the likelyhood of a completely secure system that cannot eventually be hacked is very minimal. The sad reality is that if someone really wants to do it eventually they will figure out a way (think of all the great minds and resources a company like Microsoft must have and how many security updates have they had to produce recently )

Now I could spend a lot of time and effort constantly trying to prevent cheating with updates and security patches... but instead I've decided to at least make it slightly more difficult and concentrate more on gameplay and design as unfortunately my resources and time are more limited.

Hope this helps,

Hubert

[Liam]

There are some brilliant Minds, they love to crack code. Someone may pay another party to create a program to manipulate statistics. The playback feature is a great answer. I really love this idea, you know there is no real way of messing up too much with that.

[Hubert Cater]

tom

No problems at all

If I am mistaken about the facts in that last part:

" if re-loading the turn is not actually "cheating"

Truth is I'm not actually saying it is cheating or not, not really my place to say as this is really a definition that has to be decided by you and your opponent at game time. As it is now the game does allow reloading but it will be flagged as reloaded and by the number of times it has been reloaded. While this can always be circumvented with the redownload method,if you are really concerned about security I would suggest TCP/IP as it is inherently more secure from "cheating".

I realize TCP/IP is not always an option for everyone but again as stated above it (SC2) will at least be more secure from the typical cheats used in SC1.

Hubert

[aka_tom_w]

Thanks Mr Cater

"As it is now the game does allow reloading but it will be flagged as reloaded and by the number of times it has been reloaded. While this can always be circumvented with the redownload method,"

that sounds good... at least then you can tell how many "times the other guy tried" to get the desirable out come in combat.

Thanks again

-tom w

Originally posted by Hubert Cater:

tom

No problems at all

If I am mistaken about the facts in that last part:

" if re-loading the turn is not actually "cheating"

Truth is I'm not actually saying it is cheating or not, not really my place to say as this is really a definition that has to be decided by you and your opponent at game time. As it is now the game does allow reloading but it will be flagged as reloaded and by the number of times it has been reloaded. While this can always be circumvented with the redownload method,if you are really concerned about security I would suggest TCP/IP as it is inherently more secure from "cheating".

I realize TCP/IP is not always an option for everyone but again as stated above it (SC2) will at least be more secure from the typical cheats used in SC1.

Hubert

[fischkopf]

posted May 08, 2004 10:54 AM

--------------------------------------------------------------------------------

fischkopf

So it would be extremely difficult for someone to be able to find _both_ sets of keys (the game would query both locations before allowing a turn to be played). And even if a person did find both locations, they couldn't tell others because the files/registry keys would be different for everyone's machine.

Hmmm... I could be wrong here, but the only thing you would have to do to cheat this system is edit the number assigned to the PBEM file each time you wish to reload, correct?

If so, this would be just one extra step beyond what is in place now and in this case there would be no need to try and track down the hidden values in registry keys etc. as the game would consider it a new PBEM file each time.

--------------------

Fury Software

Hubert

Yes indeed the key must be hidden in the save file. But consider that the smallest possible save game is what, about 30k? (It's been a while since I played PBEM). So in the worst case you're hiding 4 bytes in 30,000. That's a needle in a haystack.

Of course you don't just want to throw it in there, because someone with a hex editor will eventually find it. (Note that maybe 5% of your gamers know how or would care to learn how to use a hex editor, so we're doing ok even as is).

But to cut that 5% down to 0.5%, this is what I would do:

Save the 4-byte game id in 4 seperate 1-byte chunks. These should be in different portions of the file. For a quick and easy first implementatation I would try out this structure:

-generate and store a random offset (say 0 to 100 bytes)

-store garbage random values (make sure they're random though) up to the determined offset

-store the byte of the id

-store remaining garbage randoms

Then do the same for the other 3 pieces of the code.

The use of random numbers makes it a lot harder for the cracker to isolate what's changed file to file. (Personally, my first attempt at cracking would involve comparing differences between two seperate but identical-in-setup first turns. e.g. create two Fall Weiss pbem games and compare them to see the differences. With noise in the file it's a lot harder to find what you're looking for).

The random offset of the byte into the garbage zone just makes it harder to find out what's happening.

The other thing that would make this much stronger would be the inclusion of CRC (Cyclic Redudancy Check). The file stores the CRC value, and if the file has been modified the CRC won't match the CRC stored and you can detect tampering/corrupt file. This is core comp sci. Again there are ways around this but now you're moving into elite and dedicated hacker territory. It's not easy recreating CRC values!

CRC checking code is extremely samll and freely available.

And actually there's one another way to protect it. Take advantage of the fact that there two people playing the game. The only time a player should be receiving a key that doesn't show up in his list is if it's turn 1, or if he's playing the game on a different computer. So if it's not turn 1, and if he's playing on the same computer, then if a new key is reported he knows that the other player has modified the save game.

An example: Player 1 starts the game, the game id is created and stored on his machine and in the turn file. He sends this turn to player 2, who keeps hacking out the id so he can keep replaying it. Once he's done he sends this back to player 1. But now player 1 has received a turn 2 game with an id that's not on his list. How can this be? Either player 1 got a new computer + hard drive, or player 2 hacked the file.

I would just pop up a warning in this case. Player 1 will know that something is rotten if this keeps happening...

Technically, this could be circumvented, but in addition to finding the key in the save file and correcting the CRC, the hacker would then have to change the turn that he just generated, fixing the ID and re-adjusting the CRC. Not easy!!

Btw, we shouldn't really be discussion security detials in an open forum

These barriers are not difficult to code, and I think you would agree that very very few people have the skills and motivation to circumvent them.

On the other hand you're the only programmer on the team (quite impressive), and your to-do list is no doubt pages and pages long.

Anyway, if you need any help feel free to contact me at andrew@alloymail.com. We're in crunch mode ourselves but I could certainly spare a few hours here and there to code this up for you. (Hopefully you've moved off Eiffel by now

Andrew

[fischkopf]

Ok, last post, and I promise to stop all this craziness about security and such.

I just wanted to ask this question: How many readers here would know how to crack the time-limited demo of SCI?

For me, with a comp sci degree and many years of programming, it was still pretty tricky. A good friend of mine who's also a strong programmer wasn't able to crack it. Pretty tough stuff.

The solution that I proposed for protecting PBEM turns from being replayed would be much much harder to crack. I'm not kidding -- it would be a real nightmare. You would have very very few people cheating in this manner.

Ok, before I shut up, I wanted to also suggest that all PBEM and TCI/IP turns send and check a CRC checksum of the actual application executable. If two players (with version numbers matching) had different CRCs a warning could be popped up.

I mention this because for fun I made a hack to my SC such that I would always get my tech rolls. I could have just as easily written one where I was twice as likely, etc.

Again, this is a few hours work. Would be a good idea, time permitting.