I'm talking about understanding how it works on a code level. You don't need to write the special disk out if you're patching the code, like this article does.
Yeah but you'll have to hunt for and fix the code wherever it is on every disk, which could be subtly or completely different between applications. "Recalculate track 9" is a simple program that would have worked on any Western Security DRM disk.
You're assuming it's always in track 9 in the same spot. What if it isn't? And what if different applications use slightly different obfuscation?
If we're assuming Western Security DRM is always in the same spot using the exact same method, why not compare it against some other type of copy protection that always puts the exact same checking code in the same spot? It would actually be easier to blot out the other type's code with NOPs than to recalculate obfuscated Western Security track-length tables.
Although the GPs suggestion would stand a chance of creating a generic copier for disks protected using this method, rather than having to individually crack each title.
Only if they use the same obfuscation and put the data in the same spot. So it's like any kind of copy protection, you can make a "generic" copier/patcher if and only if a bunch of titles implement it the same way.
Not the Beeb but this copy protection was also used on the Apple II for example which is why we ran with the cases off so we could adjust the speed screw to match track lengths. There was software that would visually feedback the track length so you could get it spot on.
So it's "trivial" after you do the hard part. The clever thing is that it forces you to do the hard part without special hardware.