Last updated on December 23rd, 2023 at 02:20 pm
A blast from Copyright technology from the past!
Dungeon Master – Clever Floppy Disk Anti-Piracy is a video that discusses the anti-piracy measures used in the game “Dungeon Master.” It provides technical details about the copy protection and security measures implemented in the game. The video is recommended for those interested in understanding how the security of the Sony PlayStation PS1 was defeated and how computer games have been protected from piracy over the years. The video may also be of interest to individuals interested in the history of copy protection in computer games and the methods used to prevent piracy.
From Website description:
Dungeon Master – the classic 16 bit dungeon crawler that defined a genre was one of the best ever games for the Atari ST and Commodore Amiga.
Released in 1987 by FTL (Faster than Light) it saw many ports to different systems including the Sharp X68000, MS-DOS, Apple IIgs, Super Nintendo and more.
It also had one of the most devious floppy disk copy protection schemes ever created.
In an age where most games were cracked in a matter of hours, FTL’s clever protection took an entire year to crack with many attempts to defeat it, resulting in failure over and over again.
From a Youtuber comment:
Don Milo
8 months ago
I used to be an Amiga developer back in the 80’s and we used a similar method for copy protection. I didn’t know it had a name until now :). To understand it, you need to know how the Amiga disk drive controller wrote it’s data. The controller couldn’t recognize a change in magnetization that occurred too quickly. It used a coding system to prevent too many null bits or too many 1 bits from following each other. So basically if you wanted to write out binary 00001111 , the OS would convert it to something like 001 001 011 011 (this is based on my memory so the actual encoding is probably different).
Now with this information, we took control of the hardware directly and bypassed the encoding. We wrote 000000000000 and 111111111111 directly to the disk drive at a certain location. We made sure it would not create an error with the sync marks or track locations, so a copy program would not think anything was wrong. Later, when we read that data the controller would try to make sense out of it and depending on the timing would return a value, which wasn’t always the same every time. We would read that location multiple times and look for a change in value. We didn’t care what value we got back as long as it was different over multiple reads.
If you tried to make a copy of the disk, the copy program would read the value and write it back properly encoded. So when we read the value, it would always come back as the same number. I think later versions of XCopy would perform a deep scan and look for fuzzy bits and write them back to the disk as we did.
