Apple /// Copy protection - some further investigation

I did some further reading and it seemed that the On Three Uncopyprotect driver would also work for Apple Writer /// (version3.0). I found a copy of the disk images for this on the apple3.org website and booted up the first disk, AppleWriter30MSTR.dsk, in Mess. It failed to start, but came up with a different error message than Visicalc,  SYSTEM FAILURE = $06.

I then used the SCP and added the uncopyprotect driver to the disk image and then booted it again in Mess. This time success!

AppleWriter /// is using the same inbuilt copy protection and the same key as Visicalc. Interesting that it gives a different error. This would depend on the the jump taken in the still encrypted sos.interp file after the protection validation has failed. I traced with the Mess debugger and it jumps to the NMI handler routine, and then jumps to the system death routine which gives the above error.
I have seen this error for other disk images and had wondered why they gave that error. Looks like it could be due to copy protection failing for the disks.

I did some more searching and there is a copy of AppleWriter /// v4.1 in the WAP disks (APPLE-3-WAP-wdp-01a.dsk), and this one is not copy protected. So that's the easiest option to get it running and avoid this problem. Though we really need some NIB or better format images of the original v3.0 disks to preserve them in running condition.

Another disk image that I have seen reported before as broken, is the Apple3SystemDemo disk. I downloaded the disk image of this from apple3.org, Apple3SystemDemo.dsk and booted it in Mess. This also gives the same SYSTEM FAILURE=$06.

I then thought I would try to copy in the uncopyprotect driver to the disk and see if this would also work. One catch though, from the disassembly in the previous blog entry, it needs SOS1.3 to work, and this disk has SOS1.1 on it. I used the Apple3SystemUtilities to copy over the SOS1.3 and driver file with the uncopyprotectdriver on it. (for some reason Ciderpress complains about a damaged directory entry, so i had to do this the long way)

With the new sos.kernel file and the sos.driver file, the disk actually boots. but.. then gives an error about a sos call. I suspect this is due to the change from SOS1.1 to 1.3. The uncopyprotect driver did however, help to successfully decode the sos.interp file (which is business basic) and was able to run it. It must therefore use the same protection key as the other programs. I think this also means that SOS 1.1 had the same copy protection support built in.
 

The easier way to fix this would be to copy in a unprotected version of the Business Basic sos.interp into this disk. I used the Apple3SystemUtils disk and copied one over from a working Business basic disk. Success, the demo works now, here is the classic running Horses :-) (disk image here)

It looks like Apple used the same protection Key for Visicalc, AppleWriter, and this demodisk. I would have thought they may have used individual ones for each program, but seems this is not the case. Also looks like if any disk gives these errors, then it may be due to copy protection failing.

Apple /// Advanced Visicalc and an interesting discovery

I recently purchased a copy of the Apple /// version of Advanced VisiCalc on ebay. It has since arrived and is a nice and complete setup, with the manual, command helper sheet, pocket reference and two sets of disks.

I went to look for some disk images to have a quick play with it on the Mess emulator. I could not find any in any of the usual places, but did remember seeing it in the apple3rtr package. So some time later and some reading of the manual, I was quite impressed at how many features it had back then compared to what I am used to with the current version of Excel. Although no mouse support, so lots of key commands to learn.

I then thought I would image the disks that came with the package, with some suspicion that there might be some copy protection involved. My goto setup for imaging is ADT using my IIc, as this can be setup/removed on my desk quickly. I then tried the newly created disk images on the Mess emulator, and looks like there is some copy protection as the program will not run. SOS boots ok, and then when the application goes to run (sos.interp), you just get the following screen.

I did some basic comparison of the sos.kernal file (v1.3) to check it is not changed, and it was the same as others I had, so not that. I started Mess with the debugger enabled and looked to find out when SOS jumps to the interpreter, and then see what happens there to look for any clues. A quick look at the SOS source code to find a starting point and address $1EB0 is the address in SOS that it jumps to the interpreter. (in sosldr)

That jumped to $2007 (in the sos.interp for Visicalc), which contains an indirect JMP to the address at $FFFC. This turns out to contain address $E833, this looked to be within SOS. A further look through the SOS source code and we find that's the SOS system Cold Start routine, which is what we end up with when we run with the copied disks.

Something strange going on here. It all boots as described in the SOS manuals, but just ends up at the cold start routine.

I left it there, as I remembered the On Three 'uncopyprotect' driver. It allows Visicalc to run and bypass the copy protection. I wonder what this could be doing, it may give some clues. I then ran the SCP and added the uncopyprotect driver to the VisiCalc Loader disk image, and then the disk boots up fine.

So what does this driver do to bypass the protection. I then did a disassembly of the uncopyprotect driver. This takes a little bit to extract the relocatable code part and disassemble, the details for that will be for another blog post.

It was a very small driver so not too much work to decode. The disassembly listing is here uncopy.asm It still needs some finishing off, but the big clue is that it patches the SOS BFM_INIT2 module (bfm_init2.lst). This is very interesting as I had not looked at this in detail, but seems SOS has some copy protection support built in to the operating system! Sounds very similar to some discussion papers that surfaced recently on SSAFE!

The BFM_INIT2 module is run as part of the SOS loader during startup. The module reads the disk from Track 9, Sector 2, and grabs the volume number from the sector. It then waits a set time and seeks to the next track, reads a sector, again grabbing the volume number. And so on until Track 16. It then checks if the last Sector read was 6, and errors if its not. So it needs the sectors synchronized on the disk! (and the volume number preserved, so a DSK image was never  going to work) This leaves us with an 8 byte Key made up of 8 volume numbers, one read from each track. It then uses this key to decrypt the sos.interp file in memory, and then does some modification of the start pointer and then runs the interpreter.

A look back at the uncopyprotect driver and it has the specific Key hardcoded into it for visicalc. And the driver patches it into SOS when the driver is initialised. Then when Visicalc is run, SOS thinks it has read the correct key and decrypts and run Visicalc ok.

To summarise things:
- SOS has copy protection support built into the operating system (aka SSAFE)
- For programs using the protection, the sos.interp file is encrypted with a key stored on the original disk
- SOS uses eight volume numbers stored across eight track/sectors to 'hide' the key- The tracks are read in sequential order via a timed routine, and this expects a particular sector to be read on the last track, so they must be synced!
- When the disk is booted, the key is read and then the sos.interp file is decrypted with the key, and then run.
- without the key, the software cannot be decrypted and run!

I wonder how many other Apple /// software packages used this support. I could see it possible to read the key from the original disk and decrypt the sos.interp file and then make a new disk with this on it. Then the software would be permanently unprotected. This may be worthwhile if there are a few disks that have this protection used.

Wow, not how I thought this journey would have ended.

Update with additional info:
NIB image of the original disk: AVCLOADER.NIB
Volume numbers extracted from the NIB image: Volume Number list

Link to AppleSSAFEProject Documents