Monday, December 14, 2020

The cleverest floppy disc protection ever? Western Security Ltd.


I've been on a bit of a floppy disc protection odyssey recently. This will probably be the last floppy disc related post for some time, so how better to end things than describe a stroke of genius I came across during my research of BBC Micro disc protection?

In my previous posts, we've already covered (directly or tangentially) some interesting floppy disc protection schemes:

  • Weak bits. [link: Weak bits floppy disc protection: an alternate origins story on 8-bit]. "Weak bits" protection is where a patch of disc surface is left empty of magnetic flux transitions. Absent a signal, the floppy disc drive itself will turn up the gain on its amplifier and see noise, which manifests as non-deterministic digital reads from the disc.
  • Fuzzy bits. [link: Technical Documentation - Dungeon Master and Chaos Strikes Back - Detailed analysis of Atari ST Floppy Disks]. "Fuzzy bits" protection is where magnetic flux transitions are recorded at intervals that are out-of-spec with regards to timing expectations (e.g. MFM). By using intervals right in the middle of a pair of expected values (e.g. 5us instead of the expected 4us or 6us), it's possible to cause the disc controller to return non-deterministic digital reads.
  • Long / short tracks. [link: Turning a £400 BBC Micro (1981) into a $40,000 disc writer (1987)] [see the "Capabilities Unlocked" section]. Long track protection is where flux transitions are written a little bit faster than they should be. This could be the whole track or just part of a track. In either case, the track will appear to contain more bytes than a track normally should. This works because the floppy disc controller usually has a broad tolerance of bitrate, to cater for disc drives naturally spinning at different speeds.
Now, we're going to cover something else entirely, with some unique properties that I think are clever.

Western who, now?

It's not readily possible to find any "Western Security, Ltd." company associated with the BBC Micro. So how do we know such a thing exists? Two reasons. Firstly, when developing my beebjit [link] emulator, I made numerous mistakes and had tons of bugs. While grappling with accurate floppy disc emulation -- in order to load original protected disc images -- I hit this:

Jolly Jack Tar by Sherston Software

Of course, the original author here missed out an amusing case. Either the disc is faulty (no), it's an illegal copy (not really?).... or a buggy emulator. Here's another error screen. Perhaps an earlier version of the protection scheme? The message uses "disk" instead of "disc" and does not entertain the fact the disc may be at fault:

Phantom Combat by Doctor Soft

(At the risk of digressing heavily, here's another screenshot. This is unrelated to Western Security Ltd., but follows the pattern of a dedicated screen for when the disc protected loader fails. This case is interesting because there's an entire decent image hidden from normal view!)

Disc Duplicator 3, if it thinks it's a copy

The second reason we know the name Western is from disc duplicator markers. A disc duplicator marker is a special track written by some commercial disc duplication solutions. It is typically one track after the end of the normal disc, i.e. the 41st track or 81st track of the disc. Despite being "out of bounds", most disc drives will seek at least one track out of bounds. On the track, you'll typically find a single sector header, and a sector body with a CRC error. This is an unusual construction and it sticks out, for example when my discbeast program [link] looks at the Jolly Jack Tar disc:

Discbeast's view of Jolly Jack Tar

There's a date and a text string or two embedded in the duplicator marker. The Jolly Jack Tar instance is:

86 07 01 (1986, July 1st)
523-037E        WESTERN NM,10/256 PROT DUP 5"-48/40 1S SD SS

There's one other less common duplicator marker string we see associated with Western security, for example Tens and Units by Sherston Software. It appears to be an earlier prototype version:

85 10 31 (1985, October 31st)
523-037C        BBC NM,10/256 WESTERN SEC. PROTO1 DUP 5"-48/40 1

A recap of disc protection fundamentals

Before diving in to how the Western Security protection works, let's recap the fundamentals of disc protection. The specifics are nuanced but the general principle is pleasantly simple:

  • The disc is easy to read but hard to write.
The disc has to be relatively easy to read. If the disc couldn't be read by standard disc controllers, you couldn't sell the disc because customers would not be able to load it!

And the correct way to make a disc hard to write is to carefully understand consumer disc controller chips and disc drives and make the disc impossible to write with standard kit.

The BBC Micro disc protection journey did not follow this route -- the earlier discs, and many of the later discs, were exotic but not particularly hard to create with the standard disc controller. But you did need a special program. The software companies had their special mastering program and the customers did not, so in a sense the disc was "hard" to write. But then, general copying programs such as Disc Duplicator 3 appeared and suddenly the discs were "easy" to write, if you or a friend had the advanced disc copying program.

However, a few BBC Micro pioneers did write discs that "can't" be written with the standard disc controller, most notably:
  • Simon Hosler's weak bits scheme, as linked above. (And here: [link].) [1]
  • Many discs, such as The Sentinel by Firebird, hid data between sectors. [2]
[1] One of a disc controller's main jobs is to write precise disc surfaces, i.e. to never write weak bits. However in the modern era I did find a way to trick the Intel 8271 controller into writing weak bits. Best I know, this technique was not discovered or used back in the day.
[2] With a bit of clever programming, I believe data between sectors could be written with standard disc controllers. It would involve writing to a track multiple times and resetting the disc controller at critical timing junctures. I've not seen any historic disc copying program that attempts to copy such discs, though.

Analyzing the Western Security Ltd. protected loader

This version of The Wizard's Revenge by Sherston Software features Western Security Ltd. disc protection.

Here's a gratuitous screenshot of the game.

And here's what discbeast makes of the disc:

There's nothing too unusual here. The red block at the end denotes a track with 1 sector that has a CRC error. It's not part of the disc protection; it's the duplicator marker. The green color represents a standard sector layout with nothing particularly exotic present. The "D" indicates the presence of deleted sectors. This is disc protection, but not exotic or hard to copy. However, loading the disc in my beebjit emulator, using the Western Digital WD1770 floppy disc controller and -log disc:commands, yields something highly unusual:

info:disc:1770: command $E4 tr 1 sr 3 dr 1 cr $29 ptrk 1 hpos 1884

Command $E4 is "read track". It is not used in the normal operation of disc loading, or indeed in any other known protected loaders.
It's time to walk through the loader a little to see what is going on. The goal of this post is not to give a detailed walk through of all the gnarly corners of the loader. Like many protected loaders, it is "encrypted" or more accurately, obfuscated. It de-obfuscates itself using many layers of self-modification. At PC $0657, a disc call is set up to load a bit more of the loader from deleted sectors in track 9. This could easily be confused as being the extent of the protection, but it is not. Later, at PC $3CF7, there is a loop:

[ITRP] 3CF7: JSR $3D16
[ITRP] 3CFA: LDA $75
[ITRP] 3D00: TAX
[ITRP] 3D01: LDA $86
[ITRP] 3D03: STA $3F71,X
[ITRP] 3D06: INC $75
[ITRP] 3D08: LDA $3F4F
[ITRP] 3D0B: CMP $75
[ITRP] 3D0D: BCS $3CF7

It's not expected to be clear from this fragment alone (without all the subroutines), but what is going on here is a loop across tracks 1-8 inclusive. For each track, it is read fully and the length of the track is stored in a table at $3F71. Later, at PC $3CB6, these lengths are checked against a table located at $3D9B. The check is particularly interesting. For the copy protection to pass, a count is taken of each track length that falls within +-1 of the expectation, and this count must be 7 or 8. Immediately we see that this protection is not a precise technology. This is to be expected: discs are analog storage mediums underneath it all and there will be a bit of noise at the beginning or end of the track. From read-to-read, the same disc, drive and controller can and does see slight variations of track length. Looking at the load in beebjit, here are the encountered vs. expected lengths. (0x4A == 3122 bytes.)

My captured disc
3F71: 4A 4D 4B 4A 4B 4D 4D 4A
3D9B: 4A 4C 4B 4A 4B 4D 4C 4A

As can be seen, my disc reads almost exactly to expectations except track 2, which was 3125 bytes instead of the expected 3124. That's within the +-1 range so all 8 tracks pass the check (7 or more are required).

To spell it out, the protected loader expects the track length (in FM encoded bytes) for tracks 1-8 inclusive to be 3122, 3124, 3123, 3122, 3123, 3124, 3123, 3122. That's an incredible level of precision and accuracy of writing for 1985 technology. Each byte covers about 64us on a spinning disc, but disc drives of the era would often specify running RPM variation of "less than +-1.5%". At 300rpm, +-1.5% is +-3ms per rotation! In my experience, drives are much much better than that but still! How did 1985 technology cope??

One further note, on the WD1770 vs. Intel 8271 disc controllers. We've focused our analysis on the protection as seen by the WD1770. This disc also loads fine with an Intel 8271 controller. It uses a completely different code path to indirectly calculate track length in this case. It works because the padding bytes up to the end of the track are all 0x00 instead of the usual 0xFF. An "over-read" past the final sector on the track is used, and track length is detected by the change from reading 0x00 to 0xFF.

The genius twist

And then we realize the genius of this scheme. What if they didn't write the tracks with extreme precision, because the technology wasn't there? What if they just wrote the track any-old-how and then examined the result? I think this what they did:

  • Format the disc. (That's it. Just format the disc normally and you've created a fiendishly protected disc.)
  • Read the lengths of tracks 1-8 of the disc you just wrote.
  • On a per-disc basis, generate, obfuscate and write the required table of expected track lengths into the loader on track 9.
What a trick! These discs are savagely hard to copy, even with dedicated hardware of the era. In fact, this trick is so clever that it requires us to revisit the fundamentals of disc protection. Here's our earlier statement:

  • The disc is easy to read but hard to write.
But the Western Security Ltd. protection is quite easy to write -- you just format a disc. So perhaps we should say:
  • The disc is easy to read but hard to recreate.
The Western Security protection is easy to write, easy to read but very hard to copy. One of the advantages of such a protection is that you could use a home computer to write it cheaply if the economics worked for you. That said, many discs I've seen appear to have duplicator markers typically found with expensive disc duplicating machines.

How can we support our theory? One way is to find a second disc of the same title, The Wizard's Revenge, and see if it differs at all. I did find one, and it does. My disc as per above:

Track 0 sectors 10 length 3124 fixups 1 CRC32 2E6B86E9
Track 1 sectors 10 length 3122 fixups 0 CRC32 37E30EC8
Track 2 sectors 10 length 3125 fixups 1 CRC32 F7BDE89B
Track 3 sectors 10 length 3123 fixups 0 CRC32 BB1E32C3
Track 4 sectors 10 length 3122 fixups 1 CRC32 2EC84AF1
Track 5 sectors 10 length 3123 fixups 0 CRC32 58FD732B
Track 6 sectors 10 length 3125 fixups 0 CRC32 43416F5A
Track 7 sectors 10 length 3125 fixups 1 CRC32 B3D8AB10
Track 8 sectors 10 length 3122 fixups 1 CRC32 8D02AC32
Track 9 sectors 10 length 3125 fixups 1 CRC32 75B1F57B
Track 10 sectors 10 length 3123 fixups 1 CRC32 D2B0A1EF

Additional captured disc:

Track 0 sectors 10 length 3126 fixups 1 CRC32 2E6B86E9
Track 1 sectors 10 length 3129 fixups 1 CRC32 37E30EC8
Track 2 sectors 10 length 3127 fixups 1 CRC32 F7BDE89B
Track 3 sectors 10 length 3127 fixups 1 CRC32 BB1E32C3
Track 4 sectors 10 length 3127 fixups 1 CRC32 2EC84AF1
Track 5 sectors 10 length 3129 fixups 1 CRC32 58FD732B
Track 6 sectors 10 length 3129 fixups 1 CRC32 43416F5A
Track 7 sectors 10 length 3128 fixups 1 CRC32 B3D8AB10
Track 8 sectors 10 length 3128 fixups 1 CRC32 8D02AC32
Track 9 sectors 10 length 3127 fixups 1 CRC32 1F5ABD44
Track 10 sectors 10 length 3128 fixups 0 CRC32 D2B0A1EF

As can be seen, the sector data (covered by the CRC32s) of the discs is the same except for track 9, which is where the table of expected track lengths resides. And the track lengths themselves are different. In both cases there's track length wobble and in the case of the latter discs, the tracks are all a little longer. This means that the drive that formatted the disc was running at a slightly slower RPM, enabling more bytes to be written in a single revolution.

And there's a second way to support the theory. I just asked Simon Hosler, who wrote a lot of Sherston Software games back in the 1980s, if he remembered anything. He recalls,

"Western Security –  this wasn’t my system but I think it worked like this... It works because each disk drive runs at slightly different speeds. So when a drive creates a track on the disk – after it has added all of the headers and sectors etc, it has a bit of space to fill up, so adds a few extra ‘fill in’ bits that do nothing. The number of fill in bits will depend on the exact speed of the original formatting drive. So will be different if it was copied. I remember this system became a pain because disk drives were changing (?) all the time. [...] the system was called 'Fingerprinting'"

There remains the mystery of how a commercial duplicator could handle making these discs. One thing I've come across is references to a "Freeform" script [link], used in conjunction with Trace duplicators. I haven't been able to find a manual for this scripting language. There are some strange fragments in the memory of the loader after de-obfuscation; could it be related?

3F80: 54 70 00 41 44 44 20 20 20 20 20 72 00 4D 4F 56  Tp.ADD     r.MOV
3F90: 45 54 4F 20 20 74 00 55 4E 49 54 20 20 20 20 75  ETO  t.UNIT    u
3FA0: 00 54 52 41 43 4B 20 20 20 76 00 53 45 43 54 4F  .TRACK   v.SECTO
3FB0: 52 20 20 77 00 54 4F 50 54 52 41 43 4B 78 00 55  R  w.TOPTRACKx.U

Recreating Western Security style protected discs

I happen to have a couple of very different disc drives, so I thought I'd try them out. I formatted a disc in each drive, then had a look at the track lengths (in bytes) read back by a WD1772 disc controller in a real BBC Micro model B.

Contender #1: my Chinon F-051MD drive. It is older, 40 track and single-sided only. The pinch-to-close style door mechanism later fell out of fashion (was it less reliable?). Another way to date this is the large DIP-style main chip, a NEC D8048 which is an Intel 8048 clone! (There's a ROM here to extract one day!)

Contender #2: not my Mitsuibish MF504C, but pretty similar. A much newer drive, 80 track and double sided. Notice the newer chips, cleaner wiring and simpler clamp mechanism. Not visible, but it also has a smaller (next gen?) stepper motor.

Track lengths from Chinon F-051MD:

Track 1 sectors 10 length 3137 fixups 1 CRC32 67F0950E
Track 2 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 4 sectors 10 length 3139 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 6 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 7 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 8 sectors 10 length 3139 fixups 1 CRC32 67F0950E
Track 9 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 10 sectors 10 length 3140 fixups 1 CRC32 67F0950E

Track lengths from Mitsubishi MF504C:

Track 1 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 2 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3118 fixups 0 CRC32 67F0950E
Track 4 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 6 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 7 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 8 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 9 sectors 10 length 3118 fixups 1 CRC32 67F0950E
Track 10 sectors 10 length 3119 fixups 1 CRC32 67F0950E

These two drives definitely have unique fingerprints! The older drive has a bit more variance / wobble in individual track lengths. In fact, it seems to fit more bytes per track on the later sectors -- most of the latter tracks are length 3142. The older drive also generally fits 20 or so more bytes per track. This means it is spinning a little slower. By contrast, the newer drive runs like clockwork with minimal track-to-track variance. This might make it a little less suitable for generating varied per-disc fingerprints, but copying the disc on home computing hardware would still be tricky -- the machine used would need to have a similarly precise drive, and the drive would also need to be running at the exact same speed as the drive that made the original disc.

One last look at track lengths, this time from a Phantom Combat game disc, by Doctor Soft. This disc uses Western Security Ltd. protection:

Nothing quite says "we overcooked the disc protection" like a warning sticker about compatibility (left, middle). The sticker states that only Acorn disc ROMs are supported. Unfortunately, non-Acorn disc ROMs were extremely common.

Track 1 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 2 sectors 10 length 3152 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 4 sectors 10 length 3152 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3151 fixups 0 CRC32 67F0950E
Track 6 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 7 sectors 10 length 3150 fixups 0 CRC32 67F0950E
Track 8 sectors 10 length 3151 fixups 0 CRC32 67F0950E

This is disc protection hidden in plain sight. These 8 protected tracks are in fact 100% default format tracks (CRC32 67F0950E). There's the correct number of sectors and there are no deleted sectors. discbeast would show these tracks as plain green, aka. move on, nothing to see here!
There's a bit of track length wobble from track to track, but the tracks are also unusually long (the ideal is 3125 bytes). It is not clear whether the tracks were deliberately laid down a little long, but it definitely helps the disc protection. Any disc drive used to attempt to re-create these tracks is unlikely to be spinning at that speed because it is 0.8% slow and the disc drive motor technology is generally better than that. It's interesting to note that simple long track protection is just another variant in the Western Security scheme.
This disc was probably written from a BBC Micro itself, rather than a fancy duplication machine, as evidenced by the lack of a duplicator marker and by the fact the game data sectors show evidence of being written sector-at-a-time, not track-at-a-time. Who knows, maybe there was a deliberate attempt to find a slow drive; some older drives even have a twiddleable variable resistor to vary motor speed.


We've reviewed the most powerful BBC Micro model B disc protection scheme I found, across an audit of most of the copy protected discs released for the machine. It's clever in that you don't need specialized hardware to create the disc, or read the disc. But you're going to struggle to duplicate the disc.
My suspicion is that even modern hardware -- a Greaseweazle perhaps -- might struggle to hit byte-perfect precision, unless it is paired with a high quality disc drive that rotates very consistently (such as my Mitsubishi MF504C).
Talking again to Simon, as far as he's aware, this was the work of George Keeling, who I'd love to contact if only to tell him I think this work was awesome.


Anonymous said...

Everybody used "disk" in the 80s

Anonymous said...

"Disk" is for magnetic mediums.
"Disc" is for optical ones.

Din Djarin said...

This Is The Way.

Anonymous said...

Sometime in the 1980s, a guy named Mike Gustafson made a product called "The Chip" for the Atari 810 disk drive. It was a drop-in replacement controller chip for the drive. With the included software, "The Chip" allowed us to circumvent most (for a while it was all, but IIRC Synapse and ECA started creating disks we couldn't duplicate) copy protection schemes used. I think he was from or at least lived in Minnesota.

Given his ability to do this, I would suggest he may be as knowledgable as anyone regarding floppy disk protection schemes.

And everyone spelled it "disk" then. "Disc" came later with CDROMs.

Anonymous said...

Assuming emulators don't have this random wobble, you have to patch the game once (the emulator fingerprint) to create the perfect archive (including working copy-protection).

Anonymous said...

In the UK /both/ disc and disk were used at that time. Mostly by personal preference it seemed.

Lorenzo Wood said...

Fantastic analysis. Thanks!

IIRC "disk" was short for "diskette" Even 8-inch floppies got the diminutive name. It also explains the shape: a diskette consists of a rectangular sleeve (flexible or rigid, with or withouta shutter) that contains an oxide-coated disc on which data is stored.

mpk said...

with reference to disc/disk pedantry: "disc" and "disk" were completely interchangeable at least in the UK during the 1980s, to the extent that I'm still not completely consistent in my own usage in 2020. They were so interchangeable that the BBC Micro supported both *DISK and *DISC for selecting the disc filing system. (See the BBC MIcro User Guide, page... 416)

Superbeef said...

The first screenshot and the tool "Disc duplicator 3" might disagree!

Anonymous said...

The first screenshot and the tools "Disc Protector 3" and "Discbeat" might disagree!

George said...

OMG this is a blast from the past. I am George Keeling and was the owner of Western Security. I set up the company (in the west of England) to provide software to prevent illicit disk copying. We did call it fingerprinting and it did use the method you describe, basically recording the random-ish length of tracks. Western Security partnered with Sherston Software which I had also been involved with (I was one of the founders). Sadly the system was not reliable enough and so Western Security security.

The technique was in fact invented by Bill Cawley who I also worked with on an amazing computer language called ProgramPlan. It ran on Apples. The other language available was Basic. ProgramPlan beat the pants off Basic. Those were the days! george.keeling(at)

DanielJ said...

@Anonymous peoples... Acorn always used Disc. Back before optical discs were in use. Check any of the old Acorn documentation. The file systems would respond to both Disk and Disc as spellings.

G said...

As far as I remember, commercial disk duplicators at the time worked by having two mechanically interlocked drives which would copy anything regardless of speed (as long as they were fast enough) and copied at the magnetic/electrical level independent of formatting scheme.

Anonymous said...

Mike Gustafson's product for the Atari 810 was The Archiver. It was the first hardware upgrade that allowed direct copying of Atari disks that were protected using non-standard formatting.

The real gold-standard product, though, was the Happy board. This was (as the name suggests) a daughterboard that plugged into the 810 or 1050 once you'd levered out two of the chips, and offered a level of control way above Archiver. It could copy *anything*, even the stuff Archiver couldn't.

It also offered "warp speed" disk reads and writes. It achieved the reads by reading a full track into its own onboard RAM in one pass, without having to wait to read each sector in consecutive order (which is what slowed down disk reads under normal circumstances). Once it had all the sectors in RAM in whatever order it had pulled them off the disk, it was able to send them to the computer in the correct order, which was obviously massively faster.

Happy was a very expensive add-on for the time, though - $249 in 1983, which is the equivalent of $650 today.

berita unik said...

Disk is rare this day right?

rkl said...

Ah, good old Disc Duplicator 3 - I found that if you unlatched the disk drive door on my Teac 40-track drive at just tne right time (and re-latch it a bit later) while trying to use DD3 to copy itself, DD3 wouldn't realise it was present and would copy itself perfectly!

Disk copy protection schemes can always be cracked by someone disassembling the loader code and carefully patching it (either by skipping the checks or if there's actual real data to be loaded, let the loader get it, patch a return, then save that loaded data). You'd then patch in your own loader to get that data from a normal file. The Disc Doctor ROM was a very handy tool to aid in this.

On the BBC Micro, sadly very few disk versions offered an "enhanced" version of the application compared to the tape versions (Elite was one of the rare exceptions) and yet charged significantly more (50% was not uncommon) than the tape version. Also, many programs were available on tape only, so the bulk of my time was spent cracking tape protection (which was much more common and varied than disk protection) and then saving the unprotected version to disk.

Rwarcards762 said...

Reminds me of some methods I learned about in an internship -- referring to using variations in circuitry and et cetera as a means of verification of legitimacy, since it would be almost impossible to recreate the exact "variance in circuitboard trace widths" or whatever. There were quite a few other examples that escape me right now.
Really cool to see that something like this was used way back!

Erix said...

Thanks for the interesting article!

In 1984, for my Apple II games I had the same problem and took a different road. More or less clever, I'll left for you to judge :-)

But first, let's step back two years: in 1982 I self-published the first Italian text adventure (Avventura nel Castello) and designed for it a protection system that the widely used "Locksmith" program could not duplicate: the Apple II didn't use a dedicated disk controller but the hybrid PAL-based "Woz machine" implementing a hugely reliable GCR (Group Code Recording) method, half of which was done in software. I changed the driving software and I was proud of the results... for a pair of weeks. Then the next Locksmith version came out and duplicated my disks without a hitch.

Back to the drawing board.

Forward to the second edition in 1984, distributed by Jsoft in Milan. There were many protection system around, some based on fractional track stepping, but none was really impregnable, free from problems and easy to create.
I discussed the issue with my friend Roberto Cerruti, author of "Signori della Galassia" (an earlier 4x game) along these lines:

[me] - We need something easy to read but impossible or at least very hard to write with a standard drive.
[rob] - We could record information at a different speed.
[me] - good idea, let me see the schematics... alas, no, there is no way to control the motor speed. Due to the way the circuit is designed, PWM would not work.
[me] - but wait a minute... when the disk starts spinning from idle, it accelerates through all intermediate speeds from zero to nominal. We have just to choose a speed far enough from nominal rpm to be unreadable when the disk is spinning, but near enough not to create problems with the reading head amplifiers.

So the idea was born: write a whole track at about 2/3 speed with a repeating pattern, using a modified disk drive. At runtime, make multiple checks, preferably from the same point of the code to make analysis harder (note that the Apple II disks stopped spinning after a few seconds from the last access), depending of the assumed disk state:
- if the disk is expected to be already in motion, the track should be unreadable.
- if the disk is just starting to rotate (first access after some time) the pattern should briefly be readable as the disk passes through the 'right' speed while accelerating. We don't know at which angular position this will happen, so let's fill the whole track with the 'secret' pattern.

The rest was pretty standard: a small self-decrypting, self-erasing routine to perform the check.
As far as I know, my "P2" protection was never defeated directly (of course it was possible to analyse the program and carefully alter the relevant calls, returning the expected values).

Here, at about 2/3 of the page, there is an image of the modified drive:

By the way, the high-level part of the protection-writing utility was my first C program. But I digress :-)