Thanks for posting. This pretty much answers one of my oldest still lasting questions:
1. how did people hack those tape protections before the multifaces showed up and
2. how did the programmers compile a protection like that.
[...]
I can answer #2 quite well for the cases I have encountered:
a) Some trivial cases were (XOR) code transformation trickery, _without_ using R register.
b) The most commonly found titles had one or two invocations of loops using the R register.
c) The titles that were bound to become commercial success would use some annoying tricks:
c1. using features of the magnetic media, that were characteristic of that particular game
c2. multiple nested XOR-decoding loops using R register in a back-to-back fashion
a) and b) would fall easily with some mild application of Pyradev, time and patience.
category c) was a different story altogether, since they required fairly good understanding
of many aspects of the system and fiddling with the game in non-trivial ways. examples:
c1. double dragon was becoming very annoying on our cpc6128, since it would force
disk drive to make worrysome noises and would not always actually start. Eventual
reverse engineering on both soft-n-hard fronts, forced me to learn the ins and outs
of NEC765 floppy disk driver (which was a big deal to occupy a single chip back then),
write a sector reader for it *from scratch* (aka device driver nowdays), understand
the mechanical properties of my drive and that track #42 was not really available
until the moment I unscrewed and adjusted a physical limiter inside that drive...
there were also some other disk tricks with oddly formatted sectors etc and I guess
tape protections were of similar style with timing-sensitive write/read operations.
c2. OK this was a category on its own. The amount of work involved here was non-trivial.
Even if you mastered Pyradev and assembly very well, it was not easy at all to push
breakpoints at interesting code points at will, because that would imply mangling the
R register which was part of the decoding-soft-logic itself. If the number of loops was
small (say, <5) with stepwise patience and craft the game could fall. The problem here
was though that the guys protected the game had time with their side, since they could
easily automate the creation of multiple nested tough-to-break R-based XOR loops.
R was difficult because it increased by 1 or 2 with each and every processor operation!
So, if you run Pyradev or another monitor in between, your breakpoint would ruin it all.
The antidote to this technique was to patch Pyradev in the way described earlier;
I think the first game that eventually got hacked like this was quite more >20 loops,
so there's no easy way someone could circumvent it by manual code-relocation tricks...
...or use the trick with bank-shifting, which I didn't know and was ingenious indeed!
For the record: when I was doing all these operations I was maximum 14 y.o.
(and my feeling since then is, that I just decline over time! LOL)
so next time you see a teenager busy with some weird computer problem,
better not underestimate the crap with which he might be fiddling with ;-)
enjoy,
F.
