Back in the late 80's I had a Tandy Coco 1 that had a copy protected game called Dallas Quest. I spent some time copying all the sectors from the master to the copy, and it always got stuck on this one sector. I guessed that the game would check if that sector is readable before deciding it's an authentic disk. I tested that idea by writing a basic program to continually write to that sector, and I would randomly open the disk door to try to corrupt the write. Eventually it worked, I corrupted that sector, and it was unreadable. The game was able to run now on the copy.

Had a very similar thing on the C64, but can't recall what the game was. In my case, the copy program would skip the bad sector, but I was able to use a sector editor to ready the bad sector with the original disk in place, then swap it out and write it back to the copy. Worked just fine. No idea why the sector editor was able to do that but the copy program wasn't.

I remember the feeling of accomplishment of getting the game to run. It was better than playing the game in fact.

That's strange, I had a friend that had a C64 and later an Amiga. I was always so jealous of how many more games he had access to than I did.

Amiga with Xcopy-pro is a friggin machine for copying some protected disks from other platforms (eg Atari ST)

I've been having some fun lately reverse engineering the "password" systems that some console games used prior to memory cards and backup RAM.

Some are very straightforward - just an encoding of which level you were on, your score, etc.

Others are that plus a halfhearted checksum, or an actual standard CRC checksum.

Still others are these elaborate obfuscation schemes with encryption using a fixed key, then scrambling, then a checksum.

My favorite so far: ThunderStrike 2 does a few things, and one of them XORs your input with the string "NOSEY GIT". I took it to mean the original programmer was chiding me for trying to cheat at the game.

NOSEY GIT sounds very British :) I had to look it up -- Core Design. I knew some of the guys there at the time, but none of those in credits for ThunderStrike. Does the original game have the same XOR string?

I remember spending more time on Ecco the Dolphin cracking the password system than playing the game because it was so damned hard. I bought the game on day of release using every penny I had saved, then ruined it by cracking the code on the 2nd day and teleporting straight to the end.

I would have loved to know all this back in the day. In the early 90s I could hack together x86 assembly fairly well... interrupts were your friend. Anyhow, one of my buds showed me a diskette with what he called "laser spots". Apparently, that protection scheme involved the burning of the media with a laser...removing some area of the magnetic coating. The protected software would know where it was and attempt a write operation to that area. Failure to write meant it was (probably) not a copy.

If I recall correctly, we used a Formaster protection scheme (Copy-Lock? CopyGuard? I no longer remember precisely) to protect the mass copies of Rogue we manufactured, as well.

And for personal use, I edited a number of the labels in the data portion of the Rogue executable with a raw disk data editor to make the game have teenage-humor suggestions, frequently referring to anatomy in crude ways.

Ah, the late 80's :)

Cool! Disk structural picture was generated with author's made in Rust toolset https://github.com/dbalsom/fluxfox/#visualization as mentioned in the article comment.

The only real thing I miss from Diskettes is Hardware Write Protection. Too bad flash drives did not have that.

Yes, I can mount ro, but having a Write Protection switch would have been nice :)

A bunch of my SD cards have a write protect slider on them.

Also one of the SD/microSD adapters in my drawer has it.

Apparently the write protection on SD cards is entirely optional and only enforced on the drive/reader side. The reader can just choose to ignore it and allow you to write to the card willy-nilly: https://electronics.stackexchange.com/questions/325868/how-d...

And apparently is common for them to be ignored: https://superuser.com/questions/1737227/is-it-now-typical-fo...

Floppy drives are the same. Though maybe more commonly respected.

SD spec has write protection (not the sliding switch). Protection can be temporary (resettable via a command) and permanent (not resettable). A write protected SD card will ignore write commands from the host. Curiously, most OSs do not seem to check for this, and will pretend the writes work and then be surprised when they did not (eg: Windows, Linux).

For anyone curious: https://github.com/BertoldVdb/sdtool is a tool to for that. I may or may not have bricked a card while toying around with in on a Pi :)

Do you mean brick because you turned on permanent write protection (and it worked) or do you mean the card just completely died for unknown reasons?

It turned on write protection. It was a while ago, so I don’t remember exactly, but things got weird as the OS assumed writes got persisted while in reality they just got completely ignored. Was a fun experiment.

I likewise really miss that. Some early USB drives actually had those too, but it's been a really long time since I've seen one.

Big SD cards also have a physical switch that enables readonly mode, although I don't know if it's the reader firmware which disallows write requests, or simply the software driver needs to support it.