Date : Mon, 28 Apr 2003 15:54:20 +0100
From : Richard_Talbot-Watkins@...
Subject: Re: BBC Micro Games Copy Protection
[BBC games protection]
Cracking games' protection systems was a little hobby of mine back then
too; a lot of the time, it was even more satisfying than playing the game
itself! It's a shame that there isn't a disc image format for emulators
which would allow original game discs to be preserved in their original,
protected form, so we could relive the challenge! Here are my memories...
I had a BBC Master. Any game with any kind of protection system would at
some point have issued a *FX 200,2 so that memory was completely cleared
when Break was pressed. On the Master (but not a BBC B) it was possible to
get around this by hitting Break twice in very quick succession, the second
keypress interrupting the memory clear and allowing you to have a look
around memory to see what was there. This proved to be a very useful (if
cheaty!) way of looking at code which had been encrypted in an evil way!
Before I discovered this, it was always necessary to decrypt code "the hard
way"!
One of my favourite protection systems was Exile's. There were so many
different bits to this, but here's what I remember. When cataloged, the
disc looked like a blank formatted disc, apart from its boot option set to
2 (Run). Examining it closer showed there to be a !Boot file which was
hidden by setting bit 7 of its directory character - an undocumented
feature of the DFS I never knew about. *VERIFY/*BACKUP believed it to only
have 1 track! Disassembling !Boot first involved having to get past a
self-modifying decrypter - not too hard but still challenging! This code
then accessed Track 1 of the disc, which had been formatted in an
incredibly strange way. The 8271 controller didn't actually seem capable
of writing a track of this format, which is why not even backup programs
were able to copy it. The sector IDs for track 1 contained text which said
something like "Good evening, I hope you are having fun", followed by an
Osword &7F block *in the sector IDs* which was used to load the next bit of
code. All this code ran in really awkward places like the Basic keyboard
buffer so it wasn't possible to do a stage-by-stage hack from within Basic.
Eventually, the protection system ended up intercepting a load of the
filing system vectors, which reimplemented *LOAD/*RUN to load from
oddly-formatted tracks further on in the disc, using a custom catalogue
sector, also on an oddly-formatted part of the disc.
The biggest surprise in Exile was finding the protection system inserting
CHAIN"!B" into the keyboard buffer and exiting to Basic in order to load
the title screen! Of course, Escape was disabled so there was absolutely
no way to break into it (Break was of course also conditioned to clear
memory). But when you had hacked through to this point, it was possible to
simply load the files and save them onto a 'clean' disc, which made for a
completely tidy unprotected disc.
The next thing I wanted to do was to strip the password-from-novella
request as it was starting to irritate me! The routine was easy enough to
find (it just checksummed the user input, and compared it against a stored
checksum for the word in question, so of course it didn't need to store
lists of words!). However when it was removed, the game just went into its
demo mode instead (where it would hang after a couple of minutes). Sneaky.
It took a little while to figure out what else needed to be done for the
game to run happily.
As an aside, Exile was written in such a robust way, it was able to handle
all sorts of circumstances which it would not normally have to deal with.
Each object in the world had an index number, and the weapons worked by
specifying which object index should be created from the main player (It
was a short table of values in the code somewhere). If the entries in this
table were changed, it was possible to make the player emit ANY object from
the Exile world - including himself! The game dealt perfectly with
multiple players flying in formation around the world. There were other
brilliant weapon objects, including the evil blue fireballs from the nasty
turrets, Chatter's lightning, primed grenades, coronium rocks or little
coronium crystals, red drips and the homing bullets fired by one of the
robots. More bizarre was the ability to fire teleporters (which still
worked fine, though I don't know how it chose a destination), any of the
creatures from the game (robots, turrets, worms, monkeys, piranhas etc
etc), explosion debris, or a mysterious object which was a single red pixel
but which seemed to weigh a ton! I have no idea what that was. The 'real'
weapons were obviously objects which would destroy themselves after a while
(e.g. bullets disappearing when they hit something, plasma fire fading out)
but of course with this hack, it was possible to fire large numbers of
objects which would not disappear (like keys), and would just balance on
top of one another with perfect collision. When the game ran out of
"active object buffer", it would refuse to create any more, but
interestingly when they were sufficiently offscreen and they were deemed by
the game engine to be "unimportant", the game would flash the screen white
and they would be "cleared up" and removed. This would of course never
happen in a normal playthrough, but the mere fact that the engine was able
to deal with this unusual situation is testament to the robustness and
genius of the game engine.
I remember discing Starquake from tape. Its main code was in a
custom-format tape file called "F£@& OFF!" which had incredibly small gaps
between the blocks. This protection was developed by Gary Partis. The
tape loader routine accessed the tape hardware directly in order to load
this file, and meanwhile the block numbers were counted down on the screen
so you could tell how long you had left! Makes sense really. In order to
get to this actual loader routine, it was necessary to decrypt about 500
tight little loops which exclusive-ORed the subsequent block of code with
some value or a VIA timer or something. At the time, I could see no
solution other than to do this by hand, which took a reasonably long time!
What a git!
Of course there are the Kevin Edwards / Ultimate games. The encryption
they used has been talked about here several times, so I won't go there
again. But part of the additional magic of them to me was the non-standard
tape file format (just one continuous block). Ultimate games had a certain
mystery about them anyway, so the strange loading just made that even more
so. It shrunk the screen to a small enough size just to display the word
"Loading..." as the tape loaded data into screen memory, in case you
thought it had given up.
I can't think of any more at the moment. Anyone else with good hacking
memories?
Rich
--
Rich Talbot-Watkins Richard_Talbot-Watkins@...
Sony Computer Entertainment Europe Direct line: 01223 341865
Cambridge Studio
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster@...
This footnote also confirms that this email message has been checked
for all known viruses.
**********************************************************************
SCEE 2003