Cheating

[ecn1]

marshall,

Its insanely easy to cheat as defender in this game.

Okay,

1. As defender I simply copy my sav and dat files to another folder.
2. Download attacker battle file
3. Click on battle area, Run the battle, pick my chit and see first round results with attacker chit revealed
3. Delete battle file, sav file and dat file
4. copy in previously saved sav and dat file from other folder back into my save folder
5. redownload original battle file from attacker
6. rerun battle from scratch, pick a defense based on knowing attackers chit pick
7. generate defender battle file and send to attacker...

The problem that you built into the game is that you reveal chits and run 1st round of combat on with defender (actually all rounds of combat run on defenders computer, never on attackers)...so defender can just run the battle once...see what the attacker picked, and rerun it again easily with a new chit pick. Also, for rounds 2 and 3, defender can also rerun battles to in order to get better dice rolls for themselves and worse dicerolls for attacker

What you need to do to avoid cheating is

1. Have the 1st round of combat, with chits revealed and dice rolled, run on the attacker's computer.
2. Have the 2nd round of combat dice rollling run on defenders computer
3. have the 3rd round combat of dice rolling run on attackers computer...

this disallows the defender from seeing what chit the attacker picked, and splits the dice rolling between players so no one can manipulate the dice for the entire battle

erik

[MarshallEllis]

Erik:
 
That's exactly what I wanted! Appreciate the info. My PBEM design had little security (Obviously) but this doesn't mean that I cannot circle back to help prevent this type of stuff.
 
 

[pzgndr]

That's exactly what I wanted!

Marshall, you would still have the issue of unethical players copying files and rerolling for better results. The game could have some sort of internal counter to identify how many times a file is reloaded by a player and then convey that information to opponents. There should be a way for EiA to generate a unique battle file identifier which cannot be easily edited by a player, regardless if the battle file is renamed for reload attempts. Opponents receiving a battle file showing multiple reloads could then respond appropriately.

Unless you are very clever, some folks will usually find a way to hack into just about anything. But most wargamers are pretty decent and won't bother even trying to cheat. Nevertheless, there's no point keeping things as easy as erik just described.

[Ashtar]

ORIGINAL: pzgndr
Marshall, you would still have the issue of unethical players copying files and rerolling for better results.

Ehm, pzgndr, have you bothered to read the way out from this
I posted before?

More practical then setting up a server at matrix games or to
ask for a die rolling game master...

[larrywrose]

Ashtar has a good idea. When the battle file is generated the game also generates a string of die rolls. So now matter how many times you reload the game the same die roll will be used. I like it. Just please make sure to include enough die rolls for the Guard Commitment, Artillary and Pursuit after combat, You could even do a check when a file comes back to be sure nobody edited the die rolls. Ok, maybe I am pushing a little. But thinking someone might have cheated tends to poison a game. I like the old "Trust, but verify" ideas.
 
Marshall thank you for taking this subject seriously. I really love this game, and I hate thinking that someone might have cheated.
 
Larry W. Rose

[pzgndr]

Ashtar has a good idea. When the battle file is generated the game also generates a string of die rolls. So now matter how many times you reload the game the same die roll will be used.

Something like this might work also. But, pardon my lack of familiarity with the pbem exchange, you could also have an issue with players reloading their turn and changing sequences of battles requiring die rolls. This could be problematic, at least for initial battles, since there's no way you can control what a player chooses to do first, second, etc.

The game TacOps uses an interesting system for generating a string of die rolls, but that game uses simultaneous turn resolution and the game engine strictly controls the sequence of resolution. That's why I express some concern that a similar system may not work where players have freedom to sequence their own actions. The idea I suggested is currently used with the Strategic Command series and works pretty well.

[Grognot]

Unless the die rolls are discoverable before PBEM exchange, by examining the files, that's probably not a problem.  It's not very meaningful to alter the sequence of battles to change PRNG initialization if you can only do so blindly.

Foraging would be manipulable unless you foreordained the results (e.g. based on a seed generated at game creation time, interacting with game turn / location so forage rolls were independent).
[align=center] [/align]

[Jimmer]

ORIGINAL: larrywrose

I have not tried this, but I have been told that the defender in a fight can save the files, pick his chit, and then over write the files with the saved files to "fix" the fight. I would like to suggest a quick fix to this problem. The problem with an email game is that we don't know most of the people we play with, and we like to believe they are honest. But sometimes they are not.

The simple fix is just to add one more step. The Attacker picks his chit choice and sends the battle file to the defender. The Defender picks his chit chice and sends it back to the Attacker. No information is revealed until the Attacker has the Battle File back. Now with both choices locked in the choices are revealed. I would also like to recommend that the Attackers choice is not included in the battle file that is sent to the defender. I know that this slows down the game a bit, but I think it would be worth it. I hate even thinking that the person who picked the "Perfect Defense" might not have played fair. And lets be honest, we all wonder if that is the case sometimes.

Thanks for your time.
Larry W. Rose

Before you are willing to say that the game allows cheating, I suggest you actually TRY to cheat using this method. Until you have succeeded in that attempt, don't speculate about it.

Personally, I don't think this will work at all. I think the moment the second guy tries to overwrite the files, he will have permanently corrupted his copy of the game files, and thus force the game to be restarted from the last backup. Try it, and find out.

[Ashtar]

Something like this might work also. But, pardon my lack of familiarity with the pbem exchange, you could also have an issue with players reloading their turn and changing sequences of battles requiring die rolls.

No, each battle file has his own file. So changing the sequence would have no use.

[bresh]

I sure prefer to use the host for die rolls involving combats, that need fileexchanges. Sure a few extra emails involved, but putting a battle-engine in a host option could be reliable, and likely reuse some of the battlecodes.
 
Its more reliable to me. And possibly easier to implement.
A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat...
And would also need new code to do battles.
 
Regards
Bresh
 
 
 
 

[larrywrose]

No system is  perfect. But on the pre-generated die rolls, we are talking about 1 combat at a time, each time you create a battle file. Could you find out what the die rolls are yes. But this is of limited use. How often do you actually commit the Guard? Not nearly as often as you have basic battles. Would I perfer an automated Battle Server, yes I would love it. I just don't see it happening.
 
Larry W. Rose

[Ashtar]

ORIGINAL: bresh
A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat...
And would also need new code to do battles.

Regards
Bresh

I do not want to be harsh, but I wonder again if people bother to read post before posting themselves. If you read, you will notice there is no way of doing what you fear and no need to write a radically new code for battles:

1a. Combat phase - Non trivial combat. Simple way of doing it:
a) The attacker choses his chits and sends to the defender.
b) The defender choses his cheats and the program generates the needed die rolls. None of them are shown (so no reload is possible), and the file is sent back to the attacker.
c) Results of the first turn are shown to the attacker, he decides about guard commitment and sends back to the defender.
d) The defender receives, check for first turn results and decides about guard commitment. Needed die rolls are secretly generated and stuff his sent back to attacker...
Go on until the end of the combat. No way of cheating here, large battles are often the crucial and more important ones in a game
and are now secured. Moreover, no more file exchanges then now are required.

[Grognot]

ORIGINAL: bresh
Its more reliable to me. And possibly easier to implement.
A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat...
And would also need new code to do battles.

Only in quick-PBEM combat, where you don't have to send files before you find out what the results are. It's the ability to take an action, observe the results, and go back in time to change your mind that's problematic.

It's quite possible to have a system in which you can't skip actions in order to allocate rolls (ex. -- create a random seed when the game is created; create event strings based on the action type in a method independent of other actions; hash the event string and XOR that with the random seed), but quick combat would even let you skip the entire battle by redoing your land phase. You'd have to make it somewhat less quick, e.g. phasing player sends tamper-resistant data to server (* which presumes that phasing player has full data on opposition -- otherwise requires another exchange), battle server sends results to ALL players (encoded in file, not manually entered), game provides way to verify consistency of results with land combat PBM file.

[Cunctator]

Trust in God, but lock your car....
 
I think that Ashtar mode is the best method because it's the simplest to implement, while it reaches a satisfactory level of security.
If a player is not able to foresee the die rolls that are hidden and pregenerated and if the defender choose his chit and then send it to the attacker, without knowing the choice of his counterpart I think that we scored a decisive point.
I'm completely ignorant about software programming, but I believe that it would be very easy to add proper instructions to make it happen.
 
Just my two cents... 

[bresh]

ORIGINAL: Ashtar

ORIGINAL: bresh
A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat...
And would also need new code to do battles.

Regards
Bresh

I do not want to be harsh, but I wonder again if people bother to read post before posting themselves. If you read, you will notice there is no way of doing what you fear and no need to write a radically new code for battles:

1a. Combat phase - Non trivial combat. Simple way of doing it:
a) The attacker choses his chits and sends to the defender.
b) The defender choses his cheats and the program generates the needed die rolls. None of them are shown (so no reload is possible), and the file is sent back to the attacker.
c) Results of the first turn are shown to the attacker, he decides about guard commitment and sends back to the defender.
d) The defender receives, check for first turn results and decides about guard commitment. Needed die rolls are secretly generated and stuff his sent back to attacker...
Go on until the end of the combat. No way of cheating here, large battles are often the crucial and more important ones in a game
and are now secured. Moreover, no more file exchanges then now are required.

Im not sure you read my post .
But sure i had read yours. And your idea is not bad. But i would prefer rolls on the host.
Since yours does improve security, yet i guess could be hacked. And does need some coding, for special rolls if dicerolls would be split. To the defender/attacker. My example was just a bad one. Pre rolls could be misused by one side.

While when defender/attacker let the dice be rolled at the host, this would not be an issue. Sure you need to trust your host.
You would need an active host though, but then again, files send from to/from host would be simultanious from the attacker&Defender.
I havent tried any combats yet in PBM, so i dont know if it shows up if your enemy tries to reinforce a phase, or commits guards, when you recieve the files, before you take casulties.


Regards
Bresh

[Jimmer]

By the way, if this IS a true security breach, it would be fairly easy to correct:

Create a registry key that has a non-descriptive name or whose value is encrypted. This registry key contains a "heartbeat". Every so often (probably 5 or 10 seconds), the key is updated to state time checkpoints have been passed in the game. In addition, there is a matching value in the saved files for the game that is also updated at each heartbeat.

NOTE: Heartbeats must occur at specific times on the clock, not "after X seconds". Otherwise, synch problems could occur.

So, player opens the game files. < heartbeat > Player picks his chit. < heartbeat > Player notices his chit choice was a bad one. < heartbeat >

Player shuts down the game (abnormally or not -- makes no difference) and attempts to open the game files again. Game files list three fewer heartbeats than the local registry does. Game informs the host at next contact and/or sends an immediate email to host. Host must restart game due to player attempting to cheat. Use of guillotine reinstated. You get the idea.

There would be ways around this, but it would require placing a second instance of the game onto some system, and that's usually not a viable solution for most cheaters.

[bresh]

ORIGINAL: Jimmer

By the way, if this IS a true security breach, it would be fairly easy to correct:

Create a registry key that has a non-descriptive name or whose value is encrypted. This registry key contains a "heartbeat". Every so often (probably 5 or 10 seconds), the key is updated to state how much time has passed in the game.

In addition, there is a matching value in the saved files for the game that is also updated at each heartbeat.

So, player opens the game files. < heartbeat > Player picks his chit. < heartbeat > Player notices his chit choice was a bad one. < heartbeat >

Player shuts down the game (abnormally or not -- makes no difference) and attempts to open the game files again. Game files list three fewer heartbeats than the local registry does. Game informs the host at next contact and/or sends an immediate email to host. Host must restart game due to player attempting to cheat. Use of guillotine reinstated. You get the idea.

There would be ways around this, but it would require placing a second instance of the game onto some system, and that's usually not a viable solution for most cheaters.

Dont think this would work very well.
Maybe you just load the battlefile, then need to talk/ask to your allies about chitchoices/guards/reinforcing etc.

Its not like you know if they find it good to try reinforce you, it could be a screening corps, or there are other plans.
Guard commitments are not just used to win a battles, its a good equipment to reduce the effects of pursuit.
But it could be your allied guards you commit, maybe they dont want you to, maybe +1 is better than +2, sometimes.


Also there is noway you can make the game generate an email which is autosend, atleast not in my network, and its not that different from normal networks.

A in game message to the host might work, but again, you completely remove the effect of allied correspondace.

Again I would mean battles wich involves fileexchange, dicerolls performed on host, is the best security that could be made avaible. Put you need a very active host.


Regards
Bresh

[dauphan129]

Another country heard from[;)]

ecn1 and I checked this cheat out before he posted it. We had a player in our game that consitantly picked the best defense and never rolled less than a five. It got us wondering [X(]

For a work around until Matrix figures this out (and Marshall I have every confidence you will keep up the good work [:)] [&o]) here is what I am implementing in my game:

1) The attacker will email the defender and tell him where he is attacking.
2) The defender will make a text file and type his chit pick in.
3) The defender with password encrypt/zip the text file and email it to the attacker.
4) The attacker will start the battle and send it to the defender.
5) The defender will pick his chit and send the battle back to the attacker and include the password for the zipped file in this email.
6) Battle continues.

This will allow the attacker to verify that the defender picked what they said they would.

It won't help with die roll optimization but it's better than nothing...[8|]

[dodod]

won't work, to easy to break password files...proved by another player in a game who actually asked us to send him one which he broke in about 5 seconds.

what is wrong with letting the attacker open the file with the picked chit, after they have been picked, and letting the next phasing player see the prior player computer roll for both?

Isn't this full proof?

[bresh]

ORIGINAL: dodod

won't work, to easy to break password files...proved by another player in a game who actually asked us to send him one which he broke in about 5 seconds.

what is wrong with letting the attacker open the file with the picked chit, after they have been picked, and letting the next phasing player see the prior player computer roll for both?

Isn't this full proof?

Prior/Next phasing player could be involved in several ways himself, as in lend corps/reinforcement.
Or just an ally to eighter attacker/defender or both. Would work same way as if Host rolled i guess.

Offcourse if he doesnt know the rolls it might be harder.

Then again im sure there would be ways to move around that to. Generate rolls send to your "ally" friend.
But it be very rare you find 2 players in same game who would go to that extend i guess. Since only 1 can win.

Regards
Bresh