
Weak bits floppy disc protection: an alternate origins story on 8-bit - scarybeast
https://scarybeastsecurity.blogspot.com/2020/06/weak-bits-floppy-disc-protection.html
======
sowbug
The Apple II's disk controller could easily write "flaky bits" in software. By
telling the controller to write three or more consecutive zero bits, you'd
produce a sector that read back unpredictably. So your copy protection scheme
would be to turn off sector checksums and then read your test sector a few
times in a row. If the sector came back identical each time, then you were
likely a copy rather than an original.

After reverse-engineering the verification code in a few different games, I
wondered how the publishers produced those weird sectors. I called them "weak
bits," coincidentally, because my theory at the time was that they modded the
disk head to write the bit weakly so that it couldn't distinguish a one from a
zero during readback. A friend at school had a copy of Don Worth's _Beneath
Apple DOS_ , which absolutely blew my teenage mind. Until reading that book, I
didn't think that any single human could understand and clearly explain a
complex system so thoroughly.

~~~
scarybeast
Interesting, I didn't know the Apple II's controller could write the combined
data and clock bits. That's unfair :) I was also pointed to this Twitter
thread where it is explained that they wrote Mr. Do weak bits with a hacked up
Commodore 64 drive controlled by an Apple II!

[https://twitter.com/JBrooksBSI/status/936476972611334147](https://twitter.com/JBrooksBSI/status/936476972611334147)

------
dunham
It's much simpler than weak bits, but I remember one of the Ultima games for
DOS had a track with a small sector embedded in the middle of a long sector.
So from the point of view of the controller after decoding, there were more
sectors than could be written onto a track.

All the copy protection did was decrypt itself, read the starting address of
the executable from a sector on that track, and jump to it. My fix was to just
stuff that address back into the executable header. (I had actually purchased
the game, I was just tired of having to insert the floppy every time I ran it
off of the hard drive.)

------
userbinator
This reminds me of "weak sectors" as used in the infamous SafeDisc and related
CD protections, which exploit a _digital_ aspect of the media (EFM encoding)
to create an optical equivalent of a
[https://en.wikipedia.org/wiki/Lace_card](https://en.wikipedia.org/wiki/Lace_card)
:

[https://web.archive.org/web/20090603002402/http://sirdavidgu...](https://web.archive.org/web/20090603002402/http://sirdavidguy.coolfreepages.com/SafeDisc_2_Technical_Info.html)

------
lanerobertlane
I remember Dungeon Master on the Atari ST having fuzzy bits. There was also
another game, I can't remember which that instead of locking up or not loading
on detecting that the fuzzy bits were not fuzzy (and hence it was a copy)
changed the gameplay so that the end boss was unbeatable.

~~~
someguyorother
The Atari had a _lot_ of copy protection approaches[1]. No wonder, with the
floppy controller being so flexible.

[1] [http://dmweb.free.fr/files/Atari-Copy-
Protection-V1.4.pdf](http://dmweb.free.fr/files/Atari-Copy-
Protection-V1.4.pdf)

------
mrlonglong
Fabulous explanation of how they did copy protection in the old days. I
remember the 8271 well. I'm not sure why they used such an old chip with the
BBC B, as it was quite expensive. The WD1770 was better and cheaper.

~~~
LeoPanthera
1770 upgrades were extremely common for the BBC Micro. (They are,
astonishingly, still made.) The B+ and the BBC Master came with a 1770 by
default.

