Great video! I used to crack "funny floppies" on Atari 8-bit computers. Lacking onboard drive controllers, those machines used a high-level serial interface to talk to the drives. If memory serves, that interface only supported four operations: read sector, write sector, format, and status. Without fine control over the drive mechanism, there was no way for utility software to duplicate surface anomalies of any kind. Interestingly, that interface also made it impossible to CHECK for anything really fancy, so the anomalies were mostly limited to the simple bad sector and the so-called "double sector", where consecutive reads of the same sector number yielded entirely different data. Given those limitations, software publishers concentrated on obfuscating the checks, and man, some of them got REALLY clever, sending would-be pirates down a thousand dead ends, using undocumented CPU instructions to thwart disassemblers, etc. I learned a LOT by studying that code (and killing several dot matrix printers :)
Thanks! Was aware of the double sector method, crazy how creative the developers got! Yeah the Atari (and pc) had very limited control of the floppy drive, but again that’s an advantage to the devs. I’d love to hear how you went about trying to ‘bypass’ the copy protection checks. I imagine a lot of patience is required (I’m guessing the printing was printing out disassembly listings?) - what sort of undocumented commands were there?
@@RobSmithDev "I’d love to hear how you went about trying to ‘bypass’ the copy protection checks." The hard part was finding them. I had my own disassembler that read directly from floppy sectors and dumped the disassembly to a printer. Most protection checks were in the boot code, so it didn't take long to find them. After that it was just a matter of flipping a branch condition, jumping over some code, or overwriting a short sequence with NOPs. It didn't take long for publishers to start trying to hide the checks. Broderbund in particular had some elite ninjas on hand. Their boot code seemed to stop and do nothing for a few seconds, but behind the scenes it was furiously twiddling bits. As I recall, those strange machinations eventually produced a sector number, a memory address, and a decryption key for the next obfuscation stage. This went on and on; stepping through it would have been tedious, but all I had was the disassembly. I once spent a week trying to chase it down, but I ultimately landed in code laced with undocumented instructions. I was stumped, and I never found the checks, but I did find an easy way to bypass the whole thing :) "what sort of undocumented commands were there?" I didn't know it at the time, but the 6502 had a lot of them. Search for "6502 illegal opcodes".
Okay, disk copy protection is something I know a LOT about. As a scener who cracked a lot of stuff, I'm going to watch this video with interest... let's see how well you do. Good luck. Another good job. The only thing I'd have wanted more about was an example of what games used what protection system. Also, to make it through a video on protection without talking about RNC is quite impressive. The protected sector that he used with a reduced bit cell using a Trace machine wasn't all that technical, but coupled with a TVD that you could embed stuff into made it quite challenging sometimes to break. Well, depending on how well it was integrated.
Glad you liked it and found it accurate. Yeah I hadn’t dug into copylock when I made this, but it sure is an interesting one. Still think the DM one is my favourite thiugh
@@RobSmithDev The DM one is very good to look at and hard to break because they embedded checks in some unusual places. I'm more of a coder than a hardware engineer, so breaking protection doesn't necessarily mean you need to understand the mechanics of how the protection was created. For instance the DM protection doesn't actually check for weak bits, but rather that different reads produced different results. You could have got away with an unformatted track rather than trying to create the weak bits. I'd actually be interested in playing with a Trace machine. I'm not sure you could accurately control which were the weak bits. It would be nice to know exactly how it produced things like long tracks, either by changing the spin speed or the data rate. Although to be fair DM wasn't the first protection system to use fuzzy bits. There was a protection system by Sherston Software on the BBC Micro that used weak bits. There's a REALLY interesting article about it on stardot [org] uk. Apparently, DM uses Fuzzy Bits rather than weak bits. Just look for Sherston Software BBC Copy Protection.
The fuzzy / weak bits is just terminology - it’s kind of all the same thing, confusing the PLL with edge case transitions. There’s a really good depth dive on DM I watched recently that showed what the track looked like when read and what the bit flips look like. They have two distinct values in specific places and I wonder if they were checking for those specific values. Anyway as you said, cracking was about bypassing these checks anyway. I suspect long tracks were just written at a higher data rate rather than spin speed as not all tracks were encoded like this. I know less about the software side of cracking however, this was all knowledge gained while working on the WinUAE FloppyBridge plugin
@@RobSmithDev Yeah I think I saw that explanation on the big flipping. I think it went from something like D5 to 55 at certain places in the sector. Since you couldn't guarantee exactly which bits would flip depending on how the PLL interpreted the fluxes, they essentially just checksummed the read data to determine that multiple reads produced different results. The interesting thing about the BBC Micro weak bits is that they created a sector that was partially readable. The first few bytes of the sector always read the same and was actually a few bytes of code that was executed. The rest of the sector would have bit flips all over the place. And a year before DM did it. In the explanation, he explains what the subtle differences are between weak/fuzzy bits etc, which probably helped a lot of people understand what was going on.
That was a fantastic video - the best on this subject, hands down! I also love how they used the fringe case of the PLL there to flip that one individual bit lol, it's technical magic =D It's amazing to see that in simulation working so well too!
That has to be the best explanation of floppy protection I've ever seen. Been looking for a great explanation of my child hood Amiga days. Being blocked on copying games I purchased for friends & vice versa. Always wondered how it worked.
This is one of the only explanations of software copy protection that met my expectations. Most waste viewers time on recapping feelies & lame offline techniques. Really a phenomenal job, Rob. Especially the weak bit overview. I recall the Copy II PC Option Board & Transcopy software being able to replicate weak bits with commercial hard drives. Does this ring a bell? Thank you again for such a wonderful video.
Hi glad you liked the video, most of it was based on my experiences with floppy disks, never looked at anything with hard drives. I interesting, and thanks for watching
This is the most complete explanation on floppy copy protection I ever saw! I'm impressed some basement hackers had probably reversed engineered this back in the 80s and 90s!
Love these videos about how things work. Really informative stuff and fascinating! I gather then most disks were cracked by totally removing the checking code in the program hence making the protection used void? Did the program ever check to see if the checking code had been removed or tampered with?
Hi yes that’s right. Dungeon master was like you described and had several places where it checked the copy protection and unless you removed them all the game would do weird things like kill off your team, or disable some of the actions etc
I had a commodore 64 and I created a write error on the desk by poking a hole with a needle. My boot program would search that track and sector for the write error before it would run, but no copy program in existence was able to copy it. This was in the 1980s.
I noticed that the Drawbridge can't successfully write the protection on for Lotus Turbo Challenge (Amiga) it fails to load, it does work if written with greaseweazle though so I wonder if this can be fixed not sure what the protection system is
@@RobSmithDev Let me know if you want me to compile a list don't want to bombard you with request but I am currently imaging a lot of old classics so happy to test them if it helps :)
