So how 'bout those Mets?

Cheezeninja wrote:

Well. Well indeed.
I've been gone for the Last few days and i come back and we have a huge rigamahoopshamwamdingle. Of course i can't resist the urge to add my two cents, although i'll try my best to remain ...well... i suppose i'll try to remain honest to myself.

On Norfleets cheating:
Between Norfleets early defensive bs, the factual numbers, and Norfleets hasty exit, the case seems pretty clear at this point. Norfleet was cheating. Obviously its not the end of the world, and while its important to find out how he did it so it could be fixed, i dont think it necessarily follows that he should be Banned forever. I liked Norfleet. Despite his arrogance he could be quite funny, and helpful as well, and he would obviously know more about fixing these cheats/glitches than most others. While most games and forums might ban a player for his first infraction, i'd think that most people would agree that both this game and this forum are like no other. I could definetly see conditional parole for Norfleet were he to help fix whatever glitch or weakness he is exploiting. Obviously many people here would no longer want him in their games, and its equally obvious many people are going to be watching their games like a hawk in an effort to prevent any future cheating.

On the subject of Stormbinder:
Yes, you were right, we all know it, even if some of us refuse to admit it. Norfleet cheated, and you proved it and got one up on him. You came off very unctous and lowball doing it though. Now im not trying to insult you, though i understand how it could be taken as such... but you could have gone about this in an entirely different way. I could practically hear the snickers you must have been holding back in both your original post and your post with the actual numbers, you were OBVIOUSLY very happy to be destroying Norfleet on this forum, and that bothered me nearly as much as Norfleets cheating. In the end the cold hard truth is that you did this community a great service in exposing a cheater who was willing to exploit the game and others so he could lord it over us all, and i thank you for it.... But dont expect me to have to like you for it.

On the subject of the powers that be:
I have on occasion been given to think that sometimes certain Moderators come off as arrogant and dissmisive to those that havn't been around as long as they have, but on the whole i find all the seniority around here to be helpful, polite, and fairly open minded about any issues that come up. I can see why they locked the original post about the cheating, but im not sure i agree with it... Locking a corpse in a closet just means its going to stink that much more when it finally does come out in the open, and with an issue that is as serious as this and strikes so deeply as this issue does.... some negativity and displeasure is bound to be voiced. And i dont believe that should be a problem. It will be a sad state of affairs when we are no longer allowed to vocally make our displeasure known about something... attempting to lock down threads about an issue as important to MP games as cheating is just going to start ugly talk of censorship on top of the whole cheating issue. All in all, kudo's to you for paying attention and lavishing your time on this wonderful game.

I've been following this story with morbid interest, but haven't posted because I've been unable to articulate exactly how I feel about all this. I agree with everything Cheeze wrote, except the "arrogant" bit. I think Zen has made the right decisions in a difficult situation, and I thank him for the effort he's put in to the forum. Not sure what's with the drug-crazed stream of consciousness stuff a couple of Posts ago though. Is the strain finally telling?

[Gandalf Parker]

I've been following this story with morbid interest, but haven't posted because I've been unable to articulate exactly how I feel about all this. I agree with everything Cheeze wrote, except the "arrogant" bit. I think Zen has made the right decisions in a difficult situation, and I thank him for the effort he's put in to the forum. Not sure what's with the drug-crazed stream of consciousness stuff a couple of Posts ago though. Is the strain finally telling?

Im with you all the way. And Zen has made acceptable decisions as far as Ive seen. (especially since Im the first line person who would be backing them out of the system if they werent).

[Taqwus]

Odd. I would have thought that a PBEM TBS server-client game design would follow one oft-espoused rule: Never trust the client. If one does follow that, it should be impossible for a client to cheat outside of having a more efficient or useable interface -- and interface modifications are perhaps less unfair dangerous in a PBEM TBS than in practically any other genre.

You don't let a client program directly modify the server's concept of state, such as how much resources a side has available. The client will modify its local perception of state (e.g. adjusting gem quantities during alchemy) but the modifications need to be noted and checked for legality.

You don't let a client program have more information than it should. MP FPSes may often break this, I suspect, and let the clients do LOS testing for computation cost reasons, but they really shouldn't in theory.

You do let a client program submit instructions (proposed modifications to state, essentially) but need to check for bogosity. Having the client record "have this commander with a dwarven hammer forge this item" is very different from having the client itself define the new gem and item inventories.

I'm reminded of Netrek, which had an open client architecture with known protocols and open sources but a two-pronged approach to client security --

(a) 'Blessed' clients tested with cryptography-based challenges, where keys were supplied to certain trusted people who compiled with 'em. Could probably still be bypassed with a proxy-type architecture in which an unblessed client would forward challenge/response to/from a 'blessed' client, although this would be much harder if the challenge/response sequence modified local game state in an obscure but predictable way e.g. depended on and itself changed the state of a PRNG such that the 'unblessed' client would somehow get out of sync in a detectable fashion. Eh.

(b) More importantly, regardless of whether or not the client passes the periodic RSA-based server/response, the server tracks game state and enforces rules. Ships controlled by rogue clients still can't be invulnerable, can't gain energy or repair faster than they should, don't get told the locations or velocities of cloaked ships, don't get told how many armies enemy ships are carrying, can't recharge their phasers any faster, can't fire their torpedoes more often, can't teleport, and so forth, because the server doesn't trust the client. A rogue client -can- have illegal interface mods, such as having turn keys to allow simultaneously changing direction while aiming somewhere else, or automatically correctly leading a target assuming known locations and known, constant velocities (subject to server-imposed torpedo wobble), or even indicating which incoming enemy torpedoes seem likely to hit unless the user alters his velocity vector, but that's much more difficult to control because it doesn't require that the server send or accept anything unusual.

In a game like Dom II, unusual / illegal interface mods wouldn't seem to be a huge potential problem; I could see attempts to set tax policy more efficiently (applying a rule system to each of scores of provinces every turn, say) without user tedium, or archiving previous battle replays for the intelligence value... but it would actually be pretty impressive if somebody managed to write these. Simply editing the gem or item treasury shouldn't be possible, however, without a server detecting that the values aren't in sync.

A host could still cheat, but a sufficiently paranoid system could be set up to defeat cruder attempts like a host modifying data after receiving it, or reading turn files before submitting his own; it would increase the number of Messages -- e.g. players submit files encrypted with single-use keys (key pairs, preferably), all encrypted files duplicated at a second host site (a public key algorithm would allow verification of authorship), both hosts process the same files using the same PRNGs and math, both hopefully coming up with consistent results which could be reasonably checked using message-digest algorithms without revealing unencrypted state to all players. Either host in such a system could potentially learn full game state, but only after their turns were submitted, and it would require conspiracy or freakish luck for a host to be able to edit the turn files. Separate host-controlled game state files could be similarly signed/encrypted using keys submitted by all the players, to reduce the probability of the host being able to independently modify or read that file as well. Feh.

But simply a better architecture with regards to not trusting the client would allow better security with respect to the non-host players without too much fuss over message exchange, and likely without damaging gameplay (it's not like it's an FPS requiring blazing-fast processing coupled with minimal bandwidth and detailed rendering).

[johan osterman]

In hindsight it is easy to say that security should have been handled differently. But dominions was not made in an orderly and well planned fashion, but was built up from humble beginnings to greater and greater complexity. Furthermore JK learned much of the required programming while working on the game. Had the game been made by persons familiar with these sort of security issues at the outset things might have been different, but it wasn't.

[Esben Mose Hansen]

In hindsight it is easy to say that security should have been handled differently. But dominions was not made in an orderly and well planned fashion, but was built up from humble beginnings to greater and greater complexity. Furthermore JK learned much of the required programming while working on the game. Had the game been made by persons familiar with these sort of security issues at the outset things might have been different, but it wasn't.

Exactly. We all had to learn, and most of us the hard way. But there is always dom3, rift? I can assure you one buyer, at least (provided you provide a linux Version)

I can't tell you how happy I am you're reading this. You are brilliant in game design, which is the hard part. Annoying details such as this are easily overcome if you know the how. You are welcome to ask me anytime, BTW. Thank you again for the game, and thank you for providing the linux Version!

[Heironeous]

Odd. I would have thought that a PBEM TBS server-client game design would follow one oft-espoused rule: Never trust the client.

Absolutely. This is especially true for a turn-based game, where effectively all you are doing is using the client to fill out an orders sheet which is then processed by the server.

I'm reminded of Netrek, which had an open client architecture with known protocols and open sources but a two-pronged approach to client security

Lol. I ran a netrek server when I was starting university (yes, I'm old ). The client in that case had to handle things like movement plotting and aiming, which allowed for some fairly major abuse of the client by C-savvy Users (e.g. phasers that didn't need to be aimed with the mouse).

However, I don't see any of these issues with Dom 2. The server should be controlling all amounts/locations/etc, and the client simply indicates how it wants to manipulate these resources. The server then checks the legality of each order issued by the client. Seems simple enough...

[Gandalf Parker]

You don't let a client program directly modify the server's concept of state, such as how much resources a side has available. The client will modify its local perception of state (e.g. adjusting gem quantities during alchemy) but the modifications need to be noted and checked for legality.

What was apparently done was that the turn file was edited to have extra gems. Those gems had to be converted to something else or used in forge commands or turned into gold and used to make troops in that same turn before turning in a 2h. The game does have checks for such things but the variations make for alot of "thinking" needed by the game. The game sent him a turn with XX gems in each Category, and received back a 2h file of commands to do things. To take into account the original amounts, plus new gem income, plus all of the things that can be done with it in order to decide "oops too much" is pretty hairy. Especially when you try to reverse logic the troop queue to the gold to the fire gems made from the astral gems which were made from the death gems just as one example. NOT IMPOSSIBLE before someone jumps my case about it, just hairy and time consuming to get it put in. I didnt want to get into the "method of hack equals difficult to track" how-to here.

You do let a client program submit instructions (proposed modifications to state, essentially) but need to check for bogosity. Having the client record "have this commander with a dwarven hammer forge this item" is very different from having the client itself define the new gem and item inventories.

Hmmm is that what it does now? The pros and cons of a clearer "log of commands given" is being discussed as something which has some advantages although of course some disadvantages also. As usual, the programmers in the forum have a pretty cler view of what can be done. Its great to see these discussions.

A host could still cheat, but a sufficiently paranoid system could be set up to defeat cruder attempts like a host modifying data after receiving it, or reading turn files before submitting his own; it would increase the number of Messages -- e.g. players submit files encrypted with single-use keys (key pairs, preferably), all encrypted files duplicated at a second host site (a public key algorithm would allow verification of authorship), both hosts process the same files using the same PRNGs and math, both hopefully coming up with consistent results which could be reasonably checked using message-digest algorithms without revealing unencrypted state to all players. Either host in such a system could potentially learn full game state, but only after their turns were submitted, and it would require conspiracy or freakish luck for a host to be able to edit the turn files. Separate host-controlled game state files could be similarly signed/encrypted using keys submitted by all the players, to reduce the probability of the host being able to independently modify or read that file as well. Feh.

To an extent this could be implemented now by players. Before the addition of a master password feature I had setup to be a "seperate trusted host" setting up an email account that people could email their game-file passwords to. That way the host (who was also playing) didnt have access to the passworded files, but if a player fell out of the game then I could step in to turn on AI or do other checks.

In fact, that might work now as a low-tech answer. One thing Im worrie about is that now that Illwinter has shown they can dismantle a turn file to get answers Im afraid they will be swamped by requests every time any player feels another player did something shady. As often as we see Posts to that affect here which get answered as possibilitys that the player hadnt considered, you can see how busy that might be.

If someone declared their game to be only playable by people who were willing to email their passwords to a trusted site, would that help? In the case of what occured we would either have had a player who flatly refused "to let anyone view his secret tactics and strategies" (in which case anyone who played with that player would be taking their chances) or we would have had a much quicker and sooner way to have someone examine the turn file for inconsistancies. I AM NOT SAYING THIS IS THE ANSWER OR THAT OTHER THINGS CANT BE DONE just that its a low-tech thing that can be done today if people are concerned. (thats another disclaimer to cut off some of the responses I tend to get)

[Taqwus]

If he modified gem inventories to do stuff with it, then the game presumably isn't too fanatical about checking this, or the server itself was somehow compromised or worked-around.


It occurs to me that their shouldn't be that much looping. That is --

Gems left in the treasury were computed from the previous turn.

Gem income from sites, gifts, events and enchantments was computed from the previous turn.

Outside of diplomatic means (handled by the messaging system) there is no in-game way to turn anything that's not a gem into a gem, or for 1 gem to turn into more than 1 within a turn. Within a turn but before processing, then, total gems should be strictly nonincreasing. It also should not matter at what point gem alchemy was done, because you can't get more in-turn except by alchemy and because the ratio is fixed. That is, if alchemy was done at any point in the turn, it must have been legal with identical results and with the gems available at the beginning of the turn.
Then there aren't that many numbers to juggle (six types of gems turning into pearls, pearls turning into six types of gems, fire and earth gems turning into money -- which can be done after all other alchemy checks because that's a one-way street and can't make other alchemy operations possible if they weren't already).

Forging has a bit of bookkeeping; the game would need to check that the number of forges done using hammers does not exceed the number of hammers available from the end of the previous turn, and that the forgers had the necessary item slots in addition to skills.

Then, once alchemy is completed, gold becomes a one-way-street; you can get gold from alchemy, but you can't easily turn anything else (people, buildings, units) into gold that you can use that very same turn. You can pillage or hike tax rates, but you don't see the gold until next turn, so it'd be illegal to spend it or put it in the treasury until the appropriate time in turn computation.

Exception: You can get a refund of gold by clearing a recruitment queue that was non-empty after the previous turn. Whether or not you can clear a queue, however, is not affected by other in-turn actions, and the maximum you can get should be based on the Last turn since even if you increase the refund by adding units you have an equally large debit incurred during the addition.

And so forth. I don't think there's much room for bizarre circular operations (actually profitable alchemy, say; e.g. a _MoM_ player with Alchemy, Runemaster and obscene casting skill forging and breaking small items during a turn for pure profit) or anything else that would be unusually difficult to serialize.

[Gandalf Parker]

If he modified gem inventories to do stuff with it, then the game presumably isn't too fanatical about checking this, or the server itself was somehow compromised or worked-around.

No it was the turn file itself. As near as can be figured the .trn had a gem number, the gems were added, and then they were "money laundered" into other things before returning the .2h to the server. There were checks but even the checks that were put into the game caused complaints from players when they reported "cheats" which werent really cheating players. That may have slowed down adding additional checks.

[nakomus]

The methods of cheating discussed in this forum (with the exception of Taqwus) seem to focus on alteration of *data* files of the game in question, in two forms:

1. The machine on which the game was hosted was compromised and the fatherland file was edited to change game state. Than the modified, but structurally valid fatherland file was used the hosting Dominions 2 system generate the next turn

2. Either trn or 2h files were modified such that an illegal (but structurally valid) 2h file was returned to the server, which failed to detect the inconsistency in the game state.

Both of these methods assume that the hosting installation of Dominions was operating correctly on the input it was given (although it may be insufficiently paranoid).

If 1) is the true scenario than this clearly need not be the case, the attack would have had access to the executable, configuration information, and runtime state during hosting.

Even if the attacker does not have root access on the hosting server, there is the possibility of a remote exploit in Dominions, either through structurally invalid 2H files or attacks through the network connection.
In short, it may be that the server was coerced to generate invalid turn files, rather than failing to detect subtle modification of an otherwise valid input.

I won’t speculate further as to how this could be carried out.

Of course, the devs may have reason to rule these sorts of attacks out.