Now … a bit more specific …
Copy protection was one of the more interesting areas I worked in. Partly because it was so futile, partly because it was so creative, and partly for the “obvious” …
At the time, copy protection was mostly on disk-based games.
Typical schemes involved writing bad sectors to the disk during production and having the game’s loader try and read those sectors. If it didn’t get an error, it wouldn’t load, as standard copiers/drives cannot write bad sectors.
Another scheme was to write two sectors on the same track with the same sector number. Say, you write two sector nines. Each of those sector nines contains DIFFERENT data. Your loader reads sector nine, twice, back-to-back … if it doesn’t get different data, it’s a copy … because standard drives/copiers won’t try, much less be able, to write two sectors with the same number.
Very smart versions put actual game code in both duplicate sector numbers, which made it harder to simply bypass in the loader if you were close to the memory limits of the machine.
Usually, you had to play with the sector skew for this to work, as drives of the time couldn’t discriminate data fast enough to read sectors any closer than opposite sides of the track in a single rotation.
Archiver and Happy*, despite some other uses, made this sort of copy protection trivial to bypass. They replaced the drive’s normal firmware, and could make it write sectors with mismatched CRCs, write multiple duplicate sector numbers, and other tricks.
And then came people like me …
Devious types, with lots of EE and physics knowledge, a penchant for experimentation, and lots of time on our hands.
Now, I was not the only person to come up with this …
But my favorite scheme was probably the “phantom bad sector” approach. And that absolutely defeated Archiver, Happy, and various other products of that nature.
It worked by creating sectors that, over say a dozen reads, would generate DIFFERENT errors. Sometimes it would be a bad CRC, sometimes it would be “sector not found”, sometimes the data returned would CHANGE vs. a prior read, even for the same PHYSICAL sector.
Techniques for achieving this varied and evolved.
But fundamentally, it involved ablatively damaging sectors/tracks. The first attempts used fine-grit sandpaper. Production techniques used RF or, my favorite, lasers. The goal was to destroy enough of the iron oxide layer to make the coercivity, at a bit level, sit right on the border of what was cleanly a 1 or 0 (simplifying) such that it might read differently each time it went under the drive head.
You could tell if your game was protected this way … as it would do its protection check by constantly reading sectors on a given track until it got two reads, for the same sector, with different issues. Sometimes that’d occur in one try, sometimes it took a minute or t wo (literally).
Of course, the pirate crowd had an easy way around all of this … once the quick solutions (Archiver/Happy etc.) stopped working, they just hacked the loaders/games to bypass the protection checks. Since code was not signed back then, this was TRIVIAL to do.
Sometimes only taking minutes.
…
Today, new drive technology (e.g. GMR heads) make it possible to do a flux-level copy, which results in the ability to write similarly dodgy magnetic alignments without having to physically damage the disc. And clever software can simulate such things in emulators, so even that’s not necessary.
*Archiver and Happy were, fundamentally, special software combined with new drive firmware. The drive firmware was on a ROM. Which could be replaced with a PROM or EPROM. So … those got pirated too.
