Resolved: on-disc data for Sherston Software protection

[scarybeasts]

Hi,

I finally got my hands on a couple of Sherston Software discs (thanks Eelco!) and as promised, I'm reporting back what is actually on the disc surface.
Most (but not all) Sherston Software titles are protected by a CRC error on track 39, sector 9. The data in that sector is not deterministic and the Sherston loader checks that two subsequent reads of the sector return different bytes.

Non-deterministic byte reads can be caused by weak bits or fuzzy bits: https://forum.kryoflux.com/viewtopic.php?t=972

What do the Sherston disc use? It's weak bits. Or specifically, patches of weak bits. Here's a picture showing the amplified raw waveforms coming off the read head:

The protected sector contains a few bytes of code, then an 0xFF then alternating patches of "empty" disc surface and 0xFF bytes (~6-8 bytes each?). Subsequent reads will return different results:

In terms of protected disc format archiving, this is a useful finding. Patches of "empty" disc surface can be represented by simply using 0 byte values in FM byte streams. Since this isn't fuzzy bits, the complexity of variable flux timings isn't required.


Cheers
Chris

[bonus: one of the discs I received is "Animated Alphabet", which draws pictures and makes sounds for an object or two for each letter of the alphabet. W is for Watch and the sound effect for that sounded immediately awesome -- it's toggling the cassette motor relay for the tick tick! ]

[eelco108]

Nice! And that's a pretty clever protection mechanism ...

So how did Sherston actually write these weak bits? Did they have their own rigged floppy drive, or can this be done by software (clever 8271 programming or whatever) ? Or are these 'weak' bits just unwritten and therefore random? Just trying to understand.

[billcarr2005]

Excellent detective work!

[Multiwizard]

[vanekp]

very interesting, is there any kryoflux image made or available of this? would be interesting to look at.

[scarybeasts]

Nice! And that's a pretty clever protection mechanism ...

So how did Sherston actually write these weak bits? Did they have their own rigged floppy drive, or can this be done by software (clever 8271 programming or whatever) ? Or are these 'weak' bits just unwritten and therefore random? Just trying to understand.

I can now answer this. I chatted to one of the Sherston Software authors, Simon Hosler, who also did the weak bits protection!
Short story is they made a little hardware widget. Long story is here (along with some tricks to make weak bits without hardware tricks): https://scarybeastsecurity.blogspot.com ... ction.html


Cheers
Chris

[eelco108]

Thanks for the write-up! Very ingenious indeed, especially as it worked for both the 8271 and 1770 disk controllers.

[vanekp]

Thanks for that, very interesting indeed.

[The Welder]

Let me just chip in here on this subject because this is something that I know about.

Sherston Software used to produce educational software that they used to load to schools on a trial basis. Obviously, they knew people would try to copy the software that they loaned out so they had this rather interesting protection system on Track 39 Sector 9.

This sector is rather interesting as it's basically unformatted so you get a different read result each time you read that sector, but it is *NOT* completely unformatted. The first 8 or so bytes of the sector will read reliably and usually from what I can remember, contain a few 6502 instructions, or maybe they were values, but these reliable bytes were checked or executed. The results of the reliable bytes were then checked, along with a check to ensure that the rest of the sector was unreliable.

Now I remember breaking the protection on this software really easily, but I always wanted to know how the protection was actually done. I even went to a friend who had a Trace machine but was never able to completely replicate this sector properly. I found it very interesting though.

[scarybeasts]

This sector is rather interesting as it's basically unformatted so you get a different read result each time you read that sector, but it is *NOT* completely unformatted. The first 8 or so bytes of the sector will read reliably and usually from what I can remember, contain a few 6502 instructions, or maybe they were values, but these reliable bytes were checked or executed. The results of the reliable bytes were then checked, along with a check to ensure that the rest of the sector was unreliable.

Great memory! The bytes are indeed executed. I took some notes on The Teddy Bears' Picnic (part of this file: https://github.com/scarybeasts/beebjit/ ... protection).

Putting a breakpoint at $1100, the bytes are very simple:

[ITRP] 1100: STA $0737 [A=3D X=0C Y=04 S=F4 F=C 1 ] [addr=0737 val=FF]
(6502db) d 1100
[ITRP] 1100: STA $0737
[ITRP] 1103: RTS

Now I remember breaking the protection on this software really easily, but I always wanted to know how the protection was actually done. I even went to a friend who had a Trace machine but was never able to completely replicate this sector properly. I found it very interesting though.

The latest discbeast can detect and "copy" weak bits on standard beeb hardware (1770). I didn't find a decent way to unformat an area with the 1770 (8271 can do this) but you can write carefully chosen MFM in the middle of an FM sector and get the same effect as far as the protection code is concerned: an unreliable read after a few reliable bytes.


Cheers
Chris