29 Jun
2006
29 Jun
'06
9:47 p.m.
der Mouse wrote:
[arcade pieces]
Yeah, I had a Tempest upright but gave it to a neighbor
when I left Chicagoland (they are phenomenally HEAVY!
easier to move a refrigerator than a Tempest!!)
Lots of clever
ideas to prevent/discourage that sort of thing ;-)
I have images online of the Tempest ROMs. (Tempest was a colour
vector game from 1980, possibly the best arcade game ever in my
estimation, though Omega Race gives it a run for its money. Certainly
a little sniffing around on the Web indicatse that Tempest is one of
the most sought-after arcade games.) I've been working on disassembling and uncompiling
them. There's all
of 24K of data there - very parsimonious of code space compared to
"modern" umpty-ump megabyte games, and more playable than most - and
yet it has defense in fair depth against such copying. There are at
least three or so (it's been a while since I looked) loops that
checksum various things to make sure they haven't been tampered with:
one to checksum the copyright message for the splash screen, one to
checksum its appearance in video RAM, one to watch the other two, and
for all I know more I haven't sussed out yet. At least one of these is
In at least one game, the logo is "drawn" (algorithmically).
A counterfeiter modified the drawing routine (since their
title/logo is obviously different!) and learned that one
of the counterfeiting checks was to make sure the "pen"
ends up in the same place as the original logo left it!
broken and misfires in legitimate copies of the game;
it is responsible
for Easter-egg lists of the form "die between levels X and Y with the
last two digits of your score being ZZ and get this magic effect" - the
actions these bits of code take when they think they've detected
invalid copying are to bash bits of memory to produce random breakage,
and those "magic effect"s are the random breakage. Someone noticed
that the "random" part wasn't really random but just came from the low
byte of the (BCD) score.
The trick to fighting counterfeiting is to make the actions
that happen random when something is "incorrect". And, to
design the code so that you never do explicit tests for
"correct".
Instead, you leave a computed/checksum value someplace...
then magically use it in a computation (*expecting* it
to be the correct value). So, if it is incorrect, some
object might move in a nonlinear fashion. Or, might
become invisible (e.g., the color map entries for the
object get mangled).
With these sorts of failures, the counterfeiter is hard
pressed to notice them: "Hmmm... was the angle of incidence
equal to the angle of relection when I bounced off that wall?"
And, even harder to set up a breakpoint condition to check
(since the problem may manifest itself differently next time you
press GAME START)
However, to a PLAYER of a counterfeited game, they QUICKLY
learn that they are being screwed by the game. And, stop
playing it. Operator (the guy who buys the games) sees
drop in revenue and realizes game is crap. Vendor sees
lower sales for next "90 day wonder".
Unfortunately, this sort of "random failures" pattern is
hard to leverage to other devices. Imagine yourself trying
to defend (in court) a piece of code that deliberately
screws up the normal operation of the product -- *if*
that code screws up unexpectedly!!
"And, could you please tell the court why you designed
that algorithm to deliberately cause my client's pace maker
to put out 300 stimuli per minute? ..."
Finally, using that sort of an approach in a *desktop*
market would also probably be fruitless -- since people
seem to EXPECT desktop software to be buggy! :-(