Date : Wed, 30 Apr 2003 03:00:54 -0700 (PDT)
From : "F. Haroon" <haroonpd@...>
Subject: Re: BBC Micro Games Copy Protection
I never had much success hacking most games and putting them onto disk.
Only those from Blue Ribbon, Bug Byte, some Acornsoft, few Superior,
and programs that weren't games were easy. I never yet found any
decent software that could do this and get past the most common
protection schemes, falsified file information, plus number of others.
What do those disk utilities mentioned here do and how good are they?
Fiaz.
--- Richard_Talbot-Watkins@... wrote:
>
> [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
>
>
>
>
>
>
=== message truncated ==
====
HaroonNET - http://www.geocities.com/haroonpd/
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com