Many have sought the holy grail of making commercial media both readable and copy-proof, especially once everyone began to copy those floppies. One of these attempts to make floppies copy-proof was Softguard’s Superlok. This in-depth look at this copy protection system by [GloriousCow] comes on the heels of a part 1 that covers Formaster’s Copy-Lock. Interestingly, Sierra switched from Copy-Lock to Superlok for their DOS version of games like King’s Quest, following the industry’s quest in search of this holy grail.
The way that Superlok works is that it loads a (hidden) executable called CPC.COM which proceeds to read the 128 byte key that is stored on a special track 6. With this key the game’s executable is decoded and fun can commence. Without a valid ‘Play’ disk containing the special track and CPC.COM executable all one is instead left with is a request by the game to ‘insert your ORIGINAL disk 1’.
As one can see in the Norton Commander screenshot of a Sierra game disk, the hidden file is easily uncovered in any application that supports showing hidden files. However, CPC.COM couldn’t be executed directly; it needs to be executed from a memory buffer and passed the correct stack parameters. Sierra likely put in very little effort when implementing Softguard’s solution in their products, as Superlok supports changing the encryption key offset and other ways to make life hard for crackers.
Sierra was using version 2.3 of Superlok, but Softguard would also make a version 3.0. This is quite similar to 2.x, but has a gotcha in that it reads across the track index for the outer sector. This requires track wrapping to be implemented. Far from this kind of copy protection cracking being a recent thing, there was a thriving market for products that would circumvent these protections, all the way up to Central Point’s Copy II PC Option Board that would man-in-the-middle between the floppy disk drive and the CPU, intercepting data and render those copy protections pointless.
As for the fate of Softguard, by the end of the 1980s many of its customers were tiring of the cat-and-mouse game between crackers and Softguard, along with issues reported by legitimate users. Customers like Infographics Inc. dropped the Superlok protection by 1987 and by 1992 Softguard was out of business.
This kind protections is popular on 80s&90s. I was able pass these kind protection at that time for testing purpose
The statue of limitations is over, bud. We all know that it was not for “test purposes”
Interesting. I used something called pctools to make low level copy of floppies in those days, and never had a copy not work. I wonder if it got over that protection.
PC Tools was made by Central Point Software, famous for their Copy II PC product that could duplicate many copy-protected titles, so they had years of experience bypassing these sort of protections. I’ll be looking at how Copy II PC worked in a future article.
Why couldn’t track 6 get copied along with everything else? Was there some special physical trick somewhere in the track? I’ve probably misunderstood something, but i don’t see any explanation in the article.
I guess I should just watch the video.
You could have copied the outermost sector, but it would have stripped the ‘inner’ sectors of their special encoding as address markers, turning them into plain data. Then when the protection attempted to read those inner sectors, the sector reads would have failed. There was no low-level “copy track” command that would have reproduced all that exactly.
Huh… I couldn’t open his blog at work, Fortiguard thinks it is a phishing website…
That’s concerning. If you have a way to report a false positive, I’d appreciate it.
I have heard back from Fortinet that the ‘phishing’ classification has been removed. Thank you for letting me know!
I cracked leisure suit Larry, 3 days after release (was protected by superlok). Superlok would format a track with 9 sectors per track and all sectors were marked as being 512 bytes in length, except sector 1 was made as having a physical size larger than a full revolution of the disk/track. Sector 1 would have a CRC error and sectors 2-9 were normal. When writing a sector there are a few data-splice-bits before and after the data to compensate for variance in timing. When you read the first sector you actually read more than a full revolution of the disk/track. If you write data into any of the sectors 2-9, you will still have readable sectors, but the splice bits will change slightly, resulting in the CRC total of the first sector changing. Tl;Dr using a modified first sector size allows you to create a track that can’t be recreated without writing a full track in a single pass (copyiipc option board could do it, but no software solution could). I found that using an in circuit debugger called periscope allowed me to place breakpoints on memory, port I/O, interrupts, etc. I basically let leisure suit Larry decrypt itself, found the entry point to the code and wrote it back out to file. It was stupid easy (less than an hour to accomplish it). Periscope + Peter Norton’s book “inside the IBM PC” were my goto tools – learned assembly language in the process
Dunno about PC ones, but similar tricks were done on Apple II floppy drives, including
– writing a key outside of a normally valid block
– writing data at a density that can be read on a normal drive, but can only be written by adjusting the drive motor speed
– drive the track stepper motor to a half-track position – you don’t get twice as many tracks due to overlapping signal, but a copy that uses the normal track either side will not be aligned so reading in the half-track gets messed up.
– trick the track stepper motor by bit-banging it to start moving then stop at a quarter-track position (where it won’t normally stop)
– use half or quarter track tricks to make a spiral track
Disk copy programs countered these by raw-reading whole tracks instead of sectors, synchronising between adjacent tracks, and retrying tracks while displaying the effective track length as the user adjusts the floppy drive speed (just drill one hole to access a calibration pot)
The IBM PC used the NEC 765 floppy controller chip. Copy Protection techniques relied on non-standard disk formatting that the NEC chip could read, but was unable to reproduce. To understand how this worked, you need to dive into how data was stored on PC floppies.
A PC floppy has two sides (heads), 40 or 80 tracks (cylinders), and a software defined sector layout on each track. While the number of heads and tracks are determined by the mechanics of floppy drive, the sectors on each track are logical constructs created under the direction of BIOS or other software via the NEC controller. The NEC controller offers more flexibility than the PC normally uses. For example, while all standard IBM PC disks store 512 bytes of data in each sector, the NEC controller supports power of two sector sizes between 128 and 8192 bytes.
Each sector consists of a four byte ID field + CRC, a gap, then the sector’s data and its CRC, and another gap. The four byte sector ID contains: the cylinder number (0-255), head number (0-255), sector number (0-255), and a sector size identifier (02h=512 bytes, 06h=8192 bytes). When reading or writing a sector, the floppy controller scans the track under the head for the first ID field that matches the requested sector, and when found the sector data transfer begins. If not found, you will get a ‘sector not found’ error.
One note about reading sector data, if there is a data CRC mismatch, the sector data is still returned along with an error status, meaning a PC can ‘read’ any bad sector it can find.
A 360K formatted floppy normally has nine 512 byte sectors, or 4608 bytes of usable capacity. Imagine what would happen if you attempted to write a 8192 byte sector to a 360K disk using the standard controller? The NEC controller would start writing data, and shortly after the halfway point, the disk would complete a full revolution, causing the written data to obliterate the sectors own sector ID marker, rendering the entire track unreadable.
Now imagine you had special hardware that gave you greater control of what was written to the disk. You could write 8 normal 512 byte sectors, and one sector with a header for a 8192 byte sector despite only having 512 bytes of actual sector data. This mislabeled sector could be read using the NEC controller, which would cause the controller to read the entire track, and all data in the gaps between sectors, and then some, but a standard NEC controller could never be used to recreate this special oversized sector and its data.
NEC 765 app note: http://www.bitsavers.org/components/nec/_dataSheets/uPD765_App_Note_Mar79.pdf
(see page 33 for a diagram showing the format of a sector)
NEC 765 datasheet: http://www.bitsavers.org/components/nec/_dataSheets/uPD765_Data_Sheet_Dec78.pdf
TY – very clear description of how it worked
The problem with the PC floppy controller was that the track is formatted in 1 pass, then the data is written in a second pass. The splice bits were never perfect and crc failed when reading the first sector (8K in length that contained the full sectors 2-9 w/ headers, splice bits, data, splice bits, crc, etc…)
There was a means to perform an aborted write (start a clock countdown timer, initiate 8k write process, when N milliseconds into the write process have passed, hard reset the floppy controller), but as hard as we tried, we could not write a successful reproduction of the superlok track due to the variables in the encoding method (tracks vs. data within them).
Copywrite was the most effective software-only solution, copy][pc was a close second, and I had this oddball package (can’t remember the name) it was written in basic with assembly language overlays that allowed doing very granular exploit reproductions/writes/mods… one of the really odd features was called weak-bits (everytime you read a sector the data changes — assumption was that the mag strength of the write head was reduced resulting in “weak magnetic bits” being written ). weak-bits was used for laserhole prolok disk duplicates w/ a write protect tab on the floppy. copywrite and copyiipc could not reproduce the weakbits
Unguard (auto-decrypt program for superlok) didn’t work with Leisuresuit Larry, and I had to do it manually with periscope.
I also had a superlok developers toolkit – allows you to copy protect any executable, IIRC the arm total on the dev toolkit was 6 units.
The fun old days… I miss them. I turned 18 shortly after doing LSL and all the other games, and got a job (gave up the games and copy protection exploits). I stumbled across one of the games I did in abandonware recently – pcman by Scott Kuperberg. Terribly hard Pacman game that was self booting disk (required a cga adapter), I extracted the code, turned it into .com file so I could play the game on EGA or use Hercules graphics adapter w/ CGA emulator (Pre-VGA). Nice to see that the game has survived all these years.
Best. Paul
Weak bits are created by areas on the disk where there are no flux transitions. There is a feedback mechanism in the drive amplifier and PLL that leads to random values being returned in the absence of any flux transitions. The idea behind MFM encoding was to ensure that there were regular flux transitions for any data encoding to prevent exactly that from happening – doing it intentionally was probably never considered.