So how 'bout those Mets?

[Gandalf Parker]

actually, all he said was that he only told his side of the story to a few people. and now, thanks to your jumping all over that little post of his, he certainly isnt going to tell the rest of us his most likely interesting but truthless story.

Yes it would appear that luckily he is not angry at the entire Dom2 community or he would publicly tell how to do what he did. The hex location to change in a file can always be found, even if encrypted, by hit-and-miss trial and error. But once found, if its released then its fairly simple. If any other method was used, then even simpler. So the most evil thing he could do would be to post a "haha this is how its done"

[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.

[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...

[Sheap]

So the most evil thing he could do would be to post a "haha this is how its done"

Actually that would be the best thing he could do. If he did that Illwinter could fix it easily right away and put it in the next patch most likely. As it is it will be more work for IW and will probably take longer.

[Gandalf Parker]

Actually that would be the best thing he could do. If he did that Illwinter could fix it easily right away and put it in the next patch most likely. As it is it will be more work for IW and will probably take longer.

Im far more hacker than I am programmer and I dont agree with that view. The chances are very slim that such a post would be something that is easier to fix than it is to do. And telling how it could be done makes it far too easy to use the same steps to do something slightly different to bypass the fix. How its done is not all that necessary for fixing it anyway since we do know what to look for.

Now, sending an email to info over at the illwinter site saying how he did it (as most hackers would do) would be helpful, but posting it here would not be IMHO

[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!

[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.