[GloriousCow] has started working on a series of investigations into the various historical floppy disk copy protection schemes used in the early days of the IBM PC and is here with the first of these results, specifically Formaster’s Copy-Lock.
The game in question is King’s Quest by Sierra Entertainment, which used a ‘booter disk’ with the Copy-Lock protection scheme. Instead of having to boot DOS separately, you could just insert this disk and the game would launch automatically. Early copy protections often used simple methods, like adding sectors with non-standard sizes or tampering with sector CRC values to create disk errors. Copy-Lock employed several such tricks together, making it challenging for standard floppy disk hardware to replicate. In the case of Copy-Lock, Sector 1 on track 6 was intentionally written as only 256 bytes, with a 256-byte blank section to fill the gap. Additionally, the CRC was also altered to add another layer of protection.
When attempting to read the disk, the PC BIOS interrupt routine assumes it’s looking for a standard 512-byte sector, so when a “read sector” command is issued to locate the sector, it never finds it. To detect a dodgy copy, the game bypasses the BIOS and talks directly to the floppy disk controller using some custom code. The first part of the code uses the standard INT 13h routine to seek to track 6, sector 1, where it expects a fail since there is no valid sector there. Next, the floppy controller sends the “read track” command to perform a raw dump of all 512 bytes at this address and looks for a magic number, 0xF7, sitting in the final byte. That empty second half of the short sector is indeed not empty and is the check the game makes to determine if it was written with the Copy-Lock capable hardware. That last point is pertinent; you can’t create this disk structure with a standard IBM PC floppy disk controller; you need specialised hardware that can write different-sized sectors and incorrect CRCs, and that costs money to acquire.
We recently covered the copy protection scheme used for Dungeon Master on the Atari ST and the Amiga. If you’re thinking less about how a floppy got cracked and copied and more about how to preserve these digital relics, check this out!
(not picking it up though, have too many projects underway)
And again, with proper formatting (if we can’t have an edit button, maybe at least “preview”?)
This sounds like a challenge :)
This brings back memories.
We had an IBM PC when I was in high school. To back up copy-protected programs, my father and I initially used utilities like Copy2PC, which automatically handled some simple schemes. As protection grew more sophisticated, we moved to Disk Magic (I think that was the name), which was a delightful collection of tools for hacking floppy access. It came with an occasionally-updated set of “tech notes” that described how to duplicate disks for particular programs, including in some cases using a menu option that let you change values in memory. DM is the only piece of commercial software I’ve ever seen that included an interactive POKE (yeah, it was written in BASIC) in its UI.
I’ll be taking a look at Copy II PC in a future article – I’ll put it up against some of the common protection schemes and then take a look at the resulting copies. In the case that it fails to make a working copy, we should be able to see why.
Will you have the special floppy controller? It’s fairly meh without, as I recall.
I had a TRS80 Mod 3/4 game (can’t remember its name) that a techie friend couldn’t copy. He had a setup on a piece of plywood of 2 floppies, a power supply and a Model 3 motherboard connected to a monitor. He had written some kind of copy program that he would load first, then copy any TRS80 program (he claimed). My game kept failing to copy. He had a utility that showed the data as it loaded and it suddenly disappeared and the floppy started randomly seeking. As far as he could tell the boot loader of the game would load code that would cause the FDC to go off track and load data from random areas of the disk as it loaded the game. This prevented his copy routine from creating a copy.
don’t know much about the trs-80 floppy (aside from early experiences with model i having a hard time reading inner tracks because it used the fdc’s internal data separator; external data separators became available from third parties), but i was once involved in a project to build a pc/at floppy/hard disk controller around the smc 9224 instead of the normal 765/wd1010 setup. we wound up with a sparsely populated board that had maybe a dozen chips on it, compared to the stock board stuffed full of chips.
it was killed by the copy protection on lotus.
the 9224 does implied seeks; when you tell it to read the disk, it’ll read a header, figure out what track it’s on, seek to the correct track, and then go for the data you asked for. the lotus copy protection scheme put incorrect track numbers in the sector headers. the 9224 would read the disk, the header would tell it “you are on track 255” and off it would go. the implied seek could not be turned off, so we could not work with lotus or any pc software that used a similar scheme.
to work around it, we wound up having to put a 765 on the board. by the time we had it all sorted out, our board was just as crammed full of stuff as the stock board. and around that time, a new version of the stock board came out using new hardware that was as sparsely populated as our original design.
Worked with a Copy Protection Cracker back in the Early Apple DOS Days, trying to protect stuff I wrote.. He was able to get around any Copy Scheme.. He ran TWO disks Spinning at the Same Time.. Both had the Timing LED Inserted into the Drive Frame so they were Spinning at the the Same Speed, Same Phase. What ever the One read, the Other one Would Write.. Then just March across the Traces copying as you go..
The thing he found that gave him Fits, some games would ‘Half Track’.. where they would Skip a Track then copy on the 1/2 Track.. Full Steps, just off by 1/2 Track.. Most Copy Schemes could not figure this out.. However an O-Scope on the Read Head would show him where they were.. and he would copy by ‘Hand’ for that..
Cap
Half tracks were pretty well known as a copy protection method for Apple games by the mid-80s.
Afaik at least in theory linking two floppies back to back wont work with HD densities due to need for Write precompensation.
The number of times I hacked game copy protection by NOPing out a conditional would blow your mind.
Zeroing out a string to length zero also worked an amazing number of times.
Yeah. I learnt ARM assembler to crack a game. Was very disappointed it took less than an afternoon to do both.
If you like these stories, read the 4AM archives. Apple II disks decoding was all in software, so there was everything from custom encoding, half tracks, empty tracks, bad crcs, bad addressing headers, etc
This. Far easier to find somewhere to nop with debug.com and then write it back to the disk, or use a disk editor.
This is why I created the apple Preserves fdc. It can image,emulate and write back apple diskettes, regardless of copy protection. Version 2.0 will add support for 40 track DS mfm drives and possibly other 35 track media from other retro equipment if there is enough interest from the community.
I did a presentation of it at kansasfest this July.
Apple Preserves FDC – Tom (KansasFest/A24eVR 2024)
Watch it on youtube. https://youtu.be/brEg0BuNnz0
“you can’t create this disk structure with a standard IBM PC floppy disk controller; you need specialised hardware that can write different-sized sectors and incorrect CRCs, and that costs money to acquire.”
I guess that “specialized hardware” was just an ordinary disk duplication machine based on FD179x or WD279x, standard floppy controller chips outside the PC world at that time. They could write (almost) any data anywhere with the write track (format) command.
I think Amiga XCOPY had a nibble mode that would copy copy protected disks as it just copies the flux transitions if I remember correctly.
Back in the day you’d need expensive hardware but today there’s a number of devices that can do it and are inexpensive. Or you can make your own with a 80MHz mcu, floppy drive and some time. All you need to do is reproduce the timing of the flux transitions that are stored in a file like .scp.
The real story here is that beautiful visualization of the floppy’s data!
This is the project, linked in the article’s comments: https://github.com/dbalsom/fluxfox/
Thank you for the tip! That’s really beautiful! 😃💙
“The game in question is King’s Quest by Sierra Entertainment, which used a ‘booter disk’ with the Copy-Lock protection scheme.”
Reminds me of Sierra Unprotect, SUP. It would ask for the original floppy with copy-protection first and then create an unprotected executable.
It was useful for playing original games in a PC/DOS emulator. This was useful long before DOSBox hit the scene, by the way. PC/XT emulators for other platforms had existd since the 80s.
What they had in common though, was incomplete emulation of the low-level stuff. PC Ditto on Atari ST comes to mind.
Sierra used a few different copy protection methods. The later DOS version of King Quest uses Softguard’s Superlok copy protection, which is the subject of the next article in this series. The way that Sierra implemented it leads to a few amusing discoveries.
Just one thing I’d like to add here..
The flux data we see KryoFlux images and similar images are close to reality, but are not absolutely accurate.
To really capture magnetic flux information, an oscilloscope with datalogger output or an A/D converter would have to be directly wired to the read head of the floppy drive.
Otherwise, the floppy drive’s amplifier stages and the filters will alter the raw information.
So it’s maybe taken with a grain of salt. Anyway, I just wanted to mention it. Knowing this might be useful in further improving floppy preservation. Tapping the read head might be an exercise that’s still left open.
I’ve tested using a 4msps ADC directly tapping into the read head on apple disk ii. Software DSP to find the 0 to 1 transitions. Takes longer and only really provided value for disks with drop outs with normal read. Can see transitions at much lower signal level.
“Instead of having to boot DOS separately, you could just insert this disk and the game would launch automatically. ”
It’s maybe not absolutely on-topic, but unlike IBM PC booters many PC-98 booter games come with a minimal copy of MS-DOS.
Often MS-DOS 3.x, I think or more recent versions such as 6.20.
The downside is that this affects Epson PCs, which were PC-98 compatibles that required clean versions of MS-DOS without a built-in NEC-check.
Memories! In the early 80s I cracked disks as a legit job for a company called Xante. You might know them as the company that produced some ultra-rare blue Atari 2600 cartridges. Anyway, I not only had to crack them, but then recreate the exact image on demand in their POS terminal.
With Apple II disks you could do pretty much anything. Woz’s interface was elegant, but primitive. The craziest disk I ever defeated had something (I called) spiral tracking on it. As it read the disk it would nudge the stepper motor to move the head just enough to form a continuous spiral over the disk much like an old vinyl album.
PC disks were not as fun as what you could do to them was limited by the hardware. One of the engineers ultimately built a specialized board to read and write PC disks.
Anybody remember those Lotus 1-2-3 5.25″ floppies that had a hole punched in the disk? One method of copy protection. :-(
Oops, that was supposed to be a :-).
Whatchoo doin off the am forum?
WP2ASS / EX KD6VXI
In 1983/4 I sold copies Lotus 1-2-3 for the IBM PC. The disks had a copy protection scheme which was, from memory, a couple of faulty sectors. Some copy protection systems used a laser to damage the disk. I’m not sure how the Lotus disk was created.
When Lotus was started it attempted to read a couple of specific bad sectors and expected a bad CRC code response. If the disk was a copy then this sector would not be faulty and the program would not start up.
IBM published their BIOS in the manuals that you could buy. I wrote a simple intercept for the disk I/O calls and traced the results on the screen. Once the sequence was discovered I wrote a piece of code that handled the disk I/O calls looking for the unique read calls and returned the correct status for the protection call. All other access calls were passed unaltered. It was 80 bytes in total.
The code was run after PC-DOS boot and stayed in memory. After loading the patch you could run a copy of the Lotus disk and put the original one away.
I sold a product called GO-123 for UKP 29.99. It was a real money-spinner. I cleaned out my local Tandy of floppy disks I bought in 1000 lots.
As I did not modify the Lotus code, or their disk in any way, I was never challenged by Lotus. Happy days.
I used to crack Commodore 64 software. Early protection could be defeated by disassembling the code and jumping around the “copy protection check”. As protection schemes became more complex it was difficult to find the code that checked the protection.
Eventually I wrote routines similar to yours. The first intercepted certain low level disk I/O routines used by the operating system. The code would load an original copy of the software and save the disk I/O data (copy protection check) to an area of memory. This was typically a few hundred bytes at most. The intercepted data was then saved to a disk file. The cracked code would load the intercepted data. It would then redirect the disk I/O routines to code that would “play back” the intercepted data. The software would think that it had a protected disk and would run normally, This method was successful for a year or two until software publishers started utilizing custom disk formats and more complex copy protection.
The biggest weakness of any copy protection is that it had to load code into memory to do anything. It took a bit of study and Trial and Error but I wrote a disassembler / disk editor that could read the code on disk without loading it into memory. While I could read Hex code it was much easier in assembly to figure out what it was doing.
Disk editors were the reason I wrote a simple encryption in my code so that plain text was never visible on the disk. This morphed into a modified DOS that wrote every byte encrypted by a password.
I’ve mentioned this before on Hackaday.
Around 3 decades ago when Linux was still walking around in diapers, we bought a UNIX flavor for PCs that was shipped on 8mm Exabyte tape with a copy protection.
One of our scientists wrote a bit by bit copy program that faithfully copied the original tape.
Arounds the same time I was happily installing Microport System V/AT and System V/386. Can’t remember how many floppies that came on, but it didn’t seem to be copy protected in any way. We did pay them the licences though.
I do remember “porting” the SCO Unix QIC tape driver to Microport. This was done by hacking the .o’s so that they called the Microport kernel routines instead of the SCO ones (just a binary edit of the symbols) and then it all linked, and, more importantly, ran! So I could then back up onto QIC tapes instead of multiple floppies!
With exception of some of the most oddball things that require a specific disk drive (such as a few Commodore 64 protections that read data AS the head is stepping – in an arc) you can duplicate virtually everything with a standard PC drive and a device like SuperCard Pro (.scp file format) that uses a very high capture resolution (40MHz – 25ns). Analog to analog (head level) works as well but is not really necessary, especially for anything that actually has to load using a standard PC drive. You are limited by that architecture. The Commodore systems (C64 and Amiga) were the setups that had the craziest protections because they didn’t use typical FDC chips. I worked on Copy ][ 64/128, the Option Board, and numerous other hardware and software disk copiers as my actual day job for nearly 2 decades.
Some very detailed pretty data:
https://www.cbmstuff.com/data/defender_of_the_crown_flux.png
https://www.cbmstuff.com/data/defender_of_the_crown_g64.png
You can add Apple ][ disks to that list of systems that do not use a standard FDC, so you can do some nifty protection tricks with those as well. I didn’t mean to neglect the Apple ][ crowd… I don’t personally work with non-Mac disks much in the Apple world.