Home Page








Features Contents

10th October 2004


Paul Blair


Ed: Paul Blair was the Australian correspondent for the original IPUG magazine and it is with pleasure that I publish this recent submission after he contacted me recently.

Reading through the ICPUG web pages, I came across a note by Joe Griffin about his efforts at recovering a Superbase file for a friend. Along the way, he used a utility I had written that allowed the common man to trawl through the structure of Superbase data files.

The utility came at the end of a long period of undiscovered crime, which stretched back to my Wordpro days. Remember Wordpro? One of the main productivity applications written for the CBM PET. The story went that it was written by Lotus and there might be good reason to believe this. It was horribly expensive and came with a chip that sat in one of the spare motherboard sockets, to "protect" the software from theft. Well, that didn’t last long after some wise owl figured that the security ROM was just a copy of one of CBM’s proprietary operating system ROMs and could be copied with an E-PROM burner. Even that was overcome when it was discovered that the program only looked for 2 bytes from it. Take out the few bytes that did this lookup and no ROM was required at all! As most of us had other utility stuff stored on E-PROMs in the spare sockets, this made life good.

Then came Easyscript for the Commodore 64. Joe has described how this "evolved" from something else, but it really was a horrible bit of gear during the loading process. On its own, Easyscript’s copyright protection system probably destroyed more 1541 disk drives and, (because it misaligned drives), saved more thesis lines in an unrecoverable way than anyone could calculate. Our local Commodore user group used to meet fortnightly and in one corner of the room a group of techs spent the entire time realigning disk drives for the others present. This could not go on!

But how to manage this? How did Easyscript work and why did it destroy hardware?

A few of us in Oz were looking at protection systems - how to write beyond track 35, how to write tracks between tracks and all those sorts of useful things. We had a 64 with assorted add-ons and disk drives fitted with large pointers to show us where the head was at any time. But Easyscript was reasonably clever and it seemed that we would never know how it worked.

The theory was easy. A loader was dumped in the buffer and it proceeded to jump ahead a bit, erase the code behind it, and grab some more. This latter did the real work.

The answer had to be on the Easyscript disk. Looking at the sectors at random showed a whole lot of bytes that were not 6502/6510 op codes. But, if you took a wedge of true machine code and did some analysis of the frequency of occurrence of particular bytes, this could be matched against a random grab from the Easyscript disk, just that the bytes had different values. But how to get from one format to the other?

The answer lay in serendipity. One night some buttons got pushed in such a way that the "grab" mentioned above was there to read. There was the conversion algorithm for all the world, (well, me at least), to read.

Then the real fun started. It took no time to figure where the program really started on the diskette and a wee bit of code would read in the sectors, decode them and store them away for me. Voila! Easyscript in the clear. Unassemble the code and look for the bit that crashed the head of the disk drive … aha … bypass that bit and now you had a bump-free Easyscript. But, how many laws had I broken and how to pass the information around in a defensible way?

The deal was to think laterally. I figured out where on disk the offending bytes lay and what replacement bytes should be written there to defeat the error check. The disk would retain its disk error, but the program wouldn’t bother looking for it. The disk remained protected, so I felt I might stay out of jail a while longer. For a couple of years, we Easyscripted away without being destructive.

By the time the 128 came along my disk investigations had gone a lot further. With the 1571 it was possible to do bi-bit transfers, which made loading a breeze - in fact, the code I wrote was sold to an American company who turned it into a commercial product. With Superscript 128 decoded, add on the fast-load code and things were pretty respectable!

Much the same went for Superbase. The parent company retained the same loading system for the database software as their word processor. Doh! With 10 minutes work I had the whole thing in clear code and could amend it as well. It was also reverse engineered and some of the effort to write a recovery utility came from a working knowledge of the original application. That was about as far as I could go public, for obvious reasons. I sent the utility and article to ICPUG for publication and held my breath. But the thought police didn’t come…

When Precision quit the 8-bit business I sent the disks with all the code to Joe. They had served my purpose by then. By now they would be nothing more than museum pieces.