I’m part of the small but avid group of vassal players from Brazil, especially of the D&D Miniatures modules. We are trying really hard to bring some older players who gave up the game, and vassal has been a incredible tool for those who can’t find another players in their cities.
But last week a guy posted in our forum about how easy the Vassal modules are to hack, especially the dice rolls. He claims that using the Edit Module feature he change the 1d20 rolls to 1d10+10 rolls, and that cheating can easily pass unnoticed. I know that the Edit Module is a really outstanding feature that allows hundreds of games use the same java engine, but by the other way, I really can’t see how can we respond to this guy about this stupid hacking idea. Worse, now that he posted in our forum, the whole community is kinda suspicious about our vassal games and the incoming D&D Miniatures Vassal World Championship 2008 (http://ddmspoilers.com/forum/viewtopic.php?t=1270).
So I’m asking you guys for a little help. How can I prove to this player that the vassal engine is “cheat-proof”? There is some tool or way to notice when someone edit the modules or two players are using different ones (I mean, with little differences, like the dice script)?
Thanks in advance and sorry for the crappy english,
Interesting post. We did have a problem in the past during one of our play testing sessions where one of our players was all messed up. He couldn’t find what we were telling him to find and nothing seemed to be working right. We initially thought there was a major network bug until we discovered he was running an older version of the mod.
Which brings up the question, why would different versions of the mod connect with each other? There should be some sort of check to verify the mods match and, if not, a message should appear stating there’s a version incompatibility.
If different versions of the game can connect with each other, I can see hacking as a problem …a player can make adjustments to their die roll system on their end and the other players would have no idea.
On the other hand…
It’s nice that the Vassal community is made up of mostly gamers who want to play games …not cheat. Personally, I think anyone whose self-esteem is so low they have to cheat to feel better about themselves is pretty freakin’ sad. I don’t think there’s really that many of those types within this community. …I haven’t run into any of them yet (crossing fingers).
VASSAL is definitely not cheat proof and there is no program that is.
One possible solution is to timestamp modules on saving and have this stamp checked when online. Another solution is to use an Internet die roller. However, for every solution we arrive at, I can think of possibly 10 ways to circumvent it. At some level, you have to resort to the honour principle.
A possible mechanism is to require that all sessions be logged and submitted, which would enable the distribution of die roll results to be analyzed. If a typical game requires a lot of rolling, then it should be quite clear if someone is cheating. Otherwise, over a series of games it should become clear if a user is cheating. You can define cheating based upon a statistical calculation of how unlikely the distribution is to have been generated by chance.
Just add into the tournament rules that play logs must be submitted and that anyone with a fishy distribution will be disqualified, no questions asked and no appeals allowed. Obviously actually analyzing the results would be time-consuming, but the mere threat of performing the analysis might be enough to discourage cheating.
If you try to load with version X of a module a saved game saved under
version Y of a module, and X < Y, you should receive a warning telling
Is this not also the case for online play?
While that might be better in practice, it’s no better in principle:
Even if different versions of a module weren’t interoperable, if software
on the user’s computer is responsible for reporting what counts as
“different”, there’s no way to prevent someone from using both a modified
module and a modified version of VASSAL which uses the modified module
but reports that it’s the original.
Yes, the online play will also show a message.
Problem with it is the visibility of the message - one line of text, a few
moments later it may be gone depending on what happens in module reports,
people typing etc…
A more visible / permanent representation to all users might be in order -
such as a red bordered window appearing around the chat window edge and
remains in place while users of mismatched versions are synched.
The best solution to me to prevent module cheating/altering is not only to
check the version but check the module’s date. Any modification of the
module should change the file date whenever a user saves their changes. - If
they are just poking around looking inside, quitting after should not alter
the saved date.
Likewise if a cheater were to modify the module by saving it as a another
name - alter the duplicate module and then replace the original module’s
build file through the zip instead, this should also alter the time/date of
the original module file and be detectable
You can’t, because it’s not. You should never rely on someone whom you
don’t trust to report honestly on an event that only they can observe.
This problem is wholly general and has nothing to do with VASSAL (or
any other system, like Cyberboard).
Consider the following game: I flip a coin where you can’t see it.
If I report heads, you give me $50, and if I report tails, I give you
If you don’t trust me enough to report on the result honestly, then
this is a game you should not play with me, as in the case where I
have no scruples I will ignore the coin flip and always report ‘heads’.
That said, this problem can be overcome one of two ways:
Use a dice roller controlled by a disinterested third party.
Don’t play with people you don’t trust enough not to fudge their
There’s been work on a dice server which will integrate with VASSAL;
it’s possible that it could be finished by the 5 May start date of
your tournament, but only if that work cuts in line ahead of the
other work I was planning to do for VASSAL 3.2.
If you’re talking about the ctime or mtime stored in filesystems, that’s
not going to work—the file modification time could be the time that
the user downloaded the file, which might not even correspond to the actual
time if the system clock is off. Also, it’s possible to set these times
to anything you want. (E.g., ‘touch foo.mod’ on a unix system will set
the ctime and mtime to now without changing the contents of the file,
and you can give it a different date with the -d option.)
If, instead, you’re talking about saving a time inside the module, what’s
to stop someone from editing the time by hand?
Perhaps the list of players could also indicate their version number.
This would be useful in general, although it isn’t a barrier to
cheating, since the version number is assigned to a module, not
Not really. File dates can also be modified, fairly trivially. See,
Not to mention that sometimes copying the file, depending on how it is
done, can change the official creation date.
The best way to identify tampering would involve the computation of
something like an MD5 checksum of the module and use that for
comparison. That would make it a lot harder to substitute a modified
Of course, as Joel points out, the fact that one can substitute an
entirely new, hacked Vassal implementation makes this fundamentally
insecure, but that requires a bit more work than some of the simpler
cheats (like modifying die roll items in modules) and will cut out
some of the less sophisticated cheats.
I would guess that adding MD5 checksums that are computed when the
module is loaded and then reported along with the version number
shouldn’t be too hard to do. That might actually make for a good
starter project for a programmer who wants a simple, independent
project to get started with in Vassal. (hint, hint).
It would slow down module loading a little bit, but probably not too
Yes, there’s a Java class for computing MD5 hashes; even if there weren’t,
it’s not that hard to implement.
But asking someone what the MD5 hash of their module is is from a
theoretical standpoint no different from asking them “Are you
cheating?” and then accepting whatever answer they give. From a
practical standpoint, though, you can deter cheaters who aren’t
technically sophisticated this way, so it might be worth doing.
I’m wondering now whether there would be any purpose to taking a
hash of anything but the buildFile?
Yes - for serious tournament play, use of a verifiable, third party roller should be mandatory.
As Joel stated, he has made a start on such a beast that will be integrated in Vassal, similiar to the old ‘Internet Die Roller’ component, but with the verifiability added. This is a huge project in itself.
With a verifiable die roller, each roll is reported with a serial number that can be used to go back and check with the die server that it was actually rolled. In PBEM play, you would do this manually if you had concerns. With online play, the Vassal client would automatically check back with the server on receipt of a roll from another client and verify it.