PC Floppy Copy Protection: Softguard Superlok

 This is part 2 of a series on PC floppy copy protection methods.  You can read Part 1, covering Formaster Copy-Lock here.

Softguard Systems was founded by Joseph Diodati, Paul Sachse and Ken Williams in 1983¹. The company went public in 1984, and by 1985 was one of the industry leaders in copy protection technology, although they produced a few other unrelated products as well.

Advertisements for their copy-protection product, SUPERLoK, were commonly seen in the classified sections of publications such as InfoWorld and PC Magazine:

The original Superlok product required professional disk duplication to lay down the requisite copy protection track. Eventually, Softguard would produce the "SUPERLoK KIT," which was writable with a standard PC floppy controller. An advertisement for the Kit can be seen above, left. The Kit version was aimed at smaller developers on a budget, and did not offer the same level of protection. This article will focus on the original Superlok product.

Softguard landed some big clients, including Lotus development, makers of the Lotus 1-2-3 spreadsheet, and Ashton Tate, the developers of the dBase database software, both heavy-hitters in the PC industry at the time. The Superlok protection scheme wasn't without controversy, with magazines occasionally reporting user complaints and technical issues. 

Superlok was notable for its flexibility compared to some other methods, optionally allowing for consumers to make a single backup copy of their copy-protected product or even install the product to a hard drive (although the original disk must be checked on launch). 

King's Quest, Revisited

With the DOS (non-booter) release of King's Quest, Sierra switched copy-protection methods from Formaster's Copy-Lock to Superlok. They didn't stop being Formaster customers, however, as Sierra's Formaster Series One disk duplicator could also write the Superlok copy protection track.

Let's take a look at the disk surface of Side #0 of the Superlok protected DOS release of King's Quest:

King's Quest (DOS) v1.0

Once again the interesting track is #6, but there's clearly more going on here than a single unusual sector. Before we dive in to an analysis of track 6, there's something else curious about this. There are, in fact, 41 tracks on this side. Track #40 actually has a different encoding from the rest of the disk - it is FM encoded instead of the standard MFM encoding usually seen on PC floppies.

This isn't actually relevant to the protection. It is a mark produced by the disk duplication machine.

It contains a small amount of data and the following string:

IBM M,9/512 SIERRA/SFTGRD 600RPM DUP 5"-48/40 2S

A quick guess was this was a recording of the duplication parameters - IBM MFM format, 9 sectors of 512 bytes, for customer Sierra, mastered at 600RPM on a 5.25" diskette at 48 tracks per inch, 40 tracks per side with 2 sides. This sort of "duplication mark" was fairly common, and is rather handy for giving some potential clues about the copy protection method a disk might be employing.

Back to Track 6

Track 6 contains 8 sectors with consecutive sector IDs, but of unusual size. Sector 1 has an N field of 6, indicating it is 8192 bytes long.  This is actually impossibly long - equating to 131,072 MFM bits, compared to the approximately 100,000 bits a single track could normally hold.  This causes the sector to wrap all the way around the track and then some.

Sectors 2-8, therefore, are effectively inside Sector 1. This technique - overlapped sectors - is another common one we will see performed by various protection techniques.

Sectors 2-8 have an N of 3, indicating they are each 1024 bytes long. A quick glance will show that they don't actually appear to be twice as long as a standard 512 byte track. So Sector 2 overlaps Sector 3, and so on. 

If this sort of overlapping is confusing, bear in mind that a sector on a disk is simply a marker indicating some data follows. An Identification Address Mark (IDAM) is used to locate a specific sector, which is followed by a Data Address Mark (DAM) which immediately precedes the actual sector data.  To locate a specific sector the drive controller simply searches for the correct IDAM - even if that IDAM technically occurs within the data of another sector. 

You may wonder how the drive controller differentiates between an IDAM, which is the four-byte sequence  0xA1 0xA1 0xA1 0xFE, from the same sequence of bytes that might accidentally appear in user data. The key is in the MFM encoding - address markers use a slightly different method of MFM encoding that makes them unmistakable.  This special encoding lets a disk controller determine what is an address mark when searching for one - but notably it doesn't prevent the controller from reading the mark as if it were plain data when an address mark isn't being actively searched for.

In the case of overlapping sectors, reading the outer sector will return the address mark data patterns corresponding to the IDAM of the "inner" sector(s), and possibly the DAMs as well.  With a sufficiently large outer sector, one can read the entire track - with all the special formatting bytes, marks, and gaps represented as plain data.

The gray sections of the disk are intentional gaps left between normal sectors for timing purposes, allowing the controller time to access sectors sequentially.  A certain amount of this gap was configurable by specifying the GAP3 parameter to the disk controller.  Notice the lack of any visible gaps on Track 6 - the sector overlapping technique means there is data along the entire length of the track. 

Superlok in Action

When starting an early Sierra DOS title, typically you would be prompted for the original disk. Once the disk has been verified (and the executable decoded), the game would ask you to insert your PLAY disk. Making a separate play disk kept your original disk pristine as you saved your game on the play disk. If you had made an unsophisticated copy of the disk from a friend however, you wouldn't get past this prompt, which would just stubbornly keep asking for the ORIGINAL.

.

During the copy protection check, the game accesses the special track 6, and reads a 128 byte key from it.  This key is used to decode the game's executable. This effectively creates a form of one-time pad encryption, but the re-use of the key for successive blocks of data makes it cryptographically very weak.

I'll let Great Hierophant describe how the decryption worked:

A track on a 360KiB or 720KiB disk stores 4,608 data bytes.  The data on the Superlok track remained the same from game to game from 1985's Booter versions of King's Quest II to 1987's Space Quest II.  Each game would identify an offset in the data from which to derive its key.  Then this 128 byte key would be XORed with the first 128 bytes of the true executable, then the key is rotated by one bit, then XORed with the next 128 bytes of the executable, rotate and repeat until the executable is fully decrypted.

The program responsible for retrieving this key from the copy protection track was called CPC.COM, and is a hidden file. Prior to DOS 5.0, there wasn't an easy way to see such files, since the /h flag to the DIR command was not implemented, but you could easily see the file with a program such as Norton Commander:

An early Sierra adventure game basically loads in three parts:

• The loader, which could be named differently per title (SIERRA.COM in this example), does some housekeeping and then loads the hidden CPC.COM file into a buffer in memory, pushes some arguments to CPC on the stack including the offset into the track where the key is located,  then jumps to the buffer address to start CPC.
• CPC reads the protection track, extracting the key from the specified offset, then returns the key to the loader.
• The loader uses the key to XOR-decrypt the 'AGI' script interpreter that actually ran the game.

CPC.COM will hang the system if executed directly - it can only run successfully if executed from a memory buffer and passed the correct stack parameters.

I have no real evidence, but I speculate that CPC.COM was written by Softguard and provided to Sierra for their use. CPC.COM is heavily obfuscated, resistant to static analysis and disassembly. It appears to load only specific portions of code at a time into separate segments.  A full analysis of it would be interesting, but would take significant time.  The reason I suspect this was not code written by Sierra is primarily the stark difference in sophistication between CPC and Sierra's own loader. Sierra makes absolutely zero effort to obfuscate their loader or hide the returned encryption key.

Less than zero effort, actually - it was as if they were actively trying to assist crackers. I was frankly astonished at what I found.

Only As Good As The Implementation

A company like Softguard could only do so much - they could supply documentation and example code, but it was ultimately up to their customers how effective the protection would end up being.  Some users of Superlok did not use the protection track to store an encryption key, but actually hid part of the game executable there, without which obviously the game would not run.

The important part of utilizing the Superlok protection track was to use an unpredictable offset into the track data for your 'secret' data, whether that data was a key or code.  Even so, the limited amount of data limited the number of possible offsets to a few thousand, meaning that even in 1985 this was likely possible to brute-force.

In any case, Sierra made no attempt whatsoever to obfuscate the data offset to be used reading the Superlok track. In fact, they told crackers exactly where it is:

                jmp     start_0
aLoaderV30CCopy db 'LOADER v3.0  (c) Copyright Sierra On-Line, Inc.  1985',0
aKeyofs         db 'keyOfs'
cpc_key_offset  dw 0
aKkkkkkkkkkkkkk db 'kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk'
                db 'kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkss'

There is literally a string containing 'keyOfs' directly preceding the key offset, at the very start of the loader executable.  A potential cracker would see this immediately upon loading the file in a hex editor or disassembler. Basically, Sierra put a big neon sign in their code saying "Steal this."

Even more helpfully, the 128-byte buffer into which the resulting key is copied is initialized with all k's... what could 'k' possibly stand for? Now you didn't just know the location of the key, but the size.

It gets worse.

The key offset that follows was clearly intended to be a random offset into the protection track. The key offset variable here is initialized to 0.

I kept looking for where the real offset value was set to this variable. Oddly, I had trouble finding it. Maybe we can derive the offset and work backwards. Here's the key buffer in memory, before CPC.COM runs:

And here it is, after:

So our key starts with 43 B7 45 5D.

Coincidentally, here's the first 128 bytes of Track 6, Sector 1:

000000 | 43 B7 45 5D 97 49 2F F2 D8 12 7B 0E C0 3A D2 65 | C.E].I/...{..:.e

000010 | DE 85 64 41 22 51 01 D4 03 B9 D5 AA 4E D6 BE 3D | ..dA.Q......N..=

000020 | 8C 25 4C A1 10 03 56 5F 9C 54 35 5F AE 42 9F FE | ..L...V_.T5_.B..

000030 | 6C 22 21 3F 28 72 39 1D 91 FE 0F FE 78 22 CF 43 | l..?(r9.....x..C

000040 | 3B 29 A5 FB D1 D4 55 B6 72 F5 75 77 E2 3A 49 C2 | ;)....U.r.uw.:I.

000050 | 59 07 3A D5 11 7C F4 F3 6C 95 1A DA C1 70 A7 56 | Y.:..|..l....p.V

000060 | C3 A8 E4 EE 8E DF 00 BB 4F 5A 50 59 8E C6 24 F5 | ........OZPY....

000070 | 19 19 43 86 8F 92 04 18 88 E1 0A 43 5D 63 9B BA | ..C........C]c..

The reason I couldn't find where the key offset was set is because it never was. Sierra left the encryption key offset for King's Quest set to 0.

This wasn't the only Sierra title that would leave the offset at 0, although some titles did manage to change it eventually.  But with Sierra helpfully pointing directly to the key offset variable on every Superlok-protected title they published, it didn't matter. The key could simply be extracted from the same place each time, patched into the loader's 'kkkk' buffer, and the call to CPC.COM skipped entirely by changing one byte. Most cracked versions seemed to have went one step further and just decrypted the whole thing and distributed the unencrypted result.

It's hard to believe this was just incompetence - Sierra games were technically impressive for the time, making great use of graphics and sound. But what other explanation is there?  If Sierra's goal was simply to prevent casual copying, they didn't have to bother with licensing Superlok at all, a simple bad CRC on one sector would have sufficed. It's all very odd. 

Even if Sierra had properly used random offsets into the Superlok track, and had more effectively obfuscated the loader, there was still an additional problem.  They re-used the same Superlok track on each title they published with this protection.  That means that if you owned one Sierra game, you could add a batch file to the disk and produce a key disk for any other Superlok protected Sierra title you wanted.

Sierra only produced a few titles with Superlok protection before moving to everyone's favorite copy protection method: manual-based checks. These would be cracked as well, of course, but cost Sierra nothing assuming they were printing a manual for the game anyway.

About Those Overlapped Tracks...

The large outer Sector 1 serves as a means to read the entire track in one go. What then, is the point of the 7 inner, overlapped sectors? The protection does read them, from Sector 8 to 2, before reading Sector 1 from which it extracts the key.

There's one obvious reason to have sectors inside Sector 1.  If we simply had one large sector, a home user could just copy it, especially since such a large sector would likely not have a valid CRC. The special encoding of sector index and data address markers meant that a direct copy of Sector 1 would not properly recreate the internal sectors, as the address markers would become plain data bytes. Of course if these sectors were found to be missing, the key would not be extracted.

Imagine a curious amateur cracker reading track 6 with a Read Track command. If they used the default value of N==2, they would receive data for 8 sectors, each appearing to be 512 bytes (however, the CRC failure flag and lack of a 9th sector would still be suspicious).  It would be difficult to get a clear picture of what was going on without more specialized knowledge and techniques.

Superlok 3.0

What we've looked at so far is an implementation of Superlok 2.0. Sierra specifically used version 2.3 according to Great Hierophant. But there was also a version 3.0.

Arkanoid II, from publisher Taito, is another game protected by Superlok. It has its Superlok protection on track 16. This track contains contains 9 sectors, the outer sector again being 8192 bytes but now having a sector ID of 10.  This would disguise itself better on a 360K floppy.  Arkanoid II also shipped on 720K diskette, which has  similar track 16, but the contents are not identical (take notes, Sierra...)

There are some indications that Arkanoid II is using Superlok 3.0.  Both Arkanoid II and the 3.0-protected Lotus 1-2-3 v.2.0 ship with a hidden file named CML0300.FCL. 

The DOS version of King's Quest worked right away in MartyPC after implementing support for bitstream images, but Arkanoid II fails. This may partially be due to improvements in Superlok 3.0. 

Arkanoid II accesses the sectors on the protection track in the same order as King's Quest, the only real difference being that the final, outer sector has an ID of 10.  Another observable difference is that the Superlok 3.0 protection code avoids using interrupt 13h to read the protection track, instead now talking directly to the floppy disk controller. This avoided a potential vulnerability where one could easily monitor what the Superlok 2.0 protection was doing by hooking the int13h vector.

Other than that, the Superlok 3.0 seems to be essentially the same concept. An odd track with a big outer sector, containing internal, overlapped sectors, each sector read in the same order. Except this time, the protection fails to work in MartyPC. Why?

This had me stumped for a bit, but a tip from NewRisingSun shed light on things.

Superlok 3.0 reads across the track index when reading the large outer sector. 

Physically, a track on a diskette is continuous, unbroken surface. Logically, however, the presence of an index hole delineates the start of the track. Correspondingly, if we are reading a track and encounter the index mark, we know we are at the end of the track. 

The index hole is a physical hole in the disk detectable by a photosensor. You can see the index hole on a 5.25" floppy if you rotate the medium until it is visible through the small, circular window:

Photo Courtesy of Jud McCranie, CC

When first written in a standard PC format, a track begins with gap bytes with the value 0x4E, and it ends with similar gap bytes.  When a track has been written all the way around, it must line up with the start again.   Recall that MFM encoded data is a series of clock and data bits.  If there is a single bit mismatch in the pattern of clock, data, clock, data at the index mark, then reading sector data across the index mark will result in a phase error when trying to read it as an unbroken stream.  This can happen naturally as drives start writing at the index or shortly afterwards.  This is called a write splice.

A 8192 byte sector such as the one Superlok declares is larger than a single track can physically hold. When reading such a large sector, the data returned for the sector includes the controller's best interpretation of decoding the MFM stream as it crosses the index mark and trundles onwards into a partial second revolution.  So we can actually see any phase error or write splice reflected in the data returned if we dump such a large sector from the disk image.

This is what that looks like:

1768| 4E 4E 4E 4E 4E 4E 4E 4E | NNNNNNNN

1770| 4E 4E 4E 4E 4E 4E 4E 4E | NNNNNNNN

1778| 4E 4E 4E 4E 4E 4E 4E 4E | NNNNNNNN

1780| 4E 4E 4E 4E 4E 4E 4E 4E | NNNNNNNN

1788| 4E 4E 4E 4E 4E 4E 4E 4E | NNNNNNNN

1790| 4E 4E 42 27 27 27 27 27 | NNB'''''

1798| 27 27 27 27 27 27 27 27 | ''''''''

17A0| 27 27 27 27 27 27 27 27 | ''''''''

17A8| 27 27 27 27 27 27 27 27 | ''''''''

17B0| 27 27 27 27 27 27 27 27 | ''''''''

17B8| 27 27 27 27 27 27 27 27 | ''''''''

17C0| 27 27 27 27 27 27 27 27 | ''''''''

The difference between the value 4E and 27 is just a single bit shift. We can see the change in the middle of byte 1792h, or 6,034 decimal. This represents 48k bits into sector 1. Considering an entire track can can hold 50k bits, that seems about the right spot since the sector doesn't start at the very beginning of the track.

A disk may just normally have a write splice near the index - and if so, there's no real problem with that. The real problem occurs by the way many bitstream image formats are encoded. Several formats, such as HFE and MFM, store an even number of bytes for each track, even though the number of bits representing the track may not be an even multiple of 8.  This effectively creates 1-7 bits of padding between the end of the track and the start again. If this padding is present, the MFM stream can not be cleanly decoded at the seam by simply wrapping around the track data buffer.  It essentially causes an artificial write splice.

This could a problem if Superlok 3.0 expects to see a clean, unbroken read of gap bytes across the index mark - something a commercial disk duplicator should be able to accomplish.

It may be possible to detect and fix this up automatically, especially if we assume that the data crossing the index mark is consistent, such as the gap byte value 4E.  For the moment though, we can use a format that encodes absolute bit counts, such as 86F or PRI.  All we need to do to fix the game then is to ensure we are properly wrapping around from the end of the track to the start again when reading a sector.

With track wrapping implemented, we can load an unpadded, 86F formatted image of Arkanoid II, and find that we pass the protection check:

An Angry Malware Developer

Softguard's Superlok copy protection was the target of a smear campaign by at least two different software trojans. 

An article from the October 1987 issue of 80 Micro magazine describes the first, a fake Superlok unprotect utility:

    SUG's message distinguishes it from the average dirty trick. After it trashes your disks, it displays a screen that says SUG is actually a product of Softguard, and it is exacting vengeance on people who try to break its copy protection. 

    "This destruction constitutes a prima facie evidence of your criminal violation. If you attempt to challenge Softguard Systems, Inc..., you will be vigorously counter-sued for copyright infringement and theft of services," the message says. 

    It then invites anyone whose disk got zapped to call Softguard's lawyers. 

The second trojan, dubbed "Twelve Tricks" is a bit more subtle - simply placing a Softguard copyright notice and the company's address in the Master Boot Record of an infected hard disk. I doubt either did any serious reputational damage to the company, but it was clear that Softguard was not making friends in the computing underworld.

Anti-Superlok Products

It wasn't just malware developers and crackers causing headaches for Softguard Systems - there was a adversarial commercial ecosystem at play, with various companies producing software that advertised the ability to defeat Superlok copy protection, both version 2 and 3.  Central Point Software's Copy II PC software was a particularly popular product, and their NOGUARD utility was advertised specifically as being able to remove Superlok 3.0.

NOGUARD description from the Copy II PC v6.0 manual

Central Point didn't stop at producing software - they had a hardware product as well, the Copy II PC Option Board, which intercepted data from the floppy drive directly (much as a modern flux capture device does).  This allowed duplication of many copy-protection methods that software products couldn't handle. It was relatively inexpensive as well.

Central Point Software bundled this board with the TRANSCOPY software which could also write image files to disk.  These Transcopy-format disk images can still be found floating around online, with the extension .TC.  Our mysterious friend NewRisingSun even created a DOSBox fork, DOSBox-TC, that can read them. Even if your favorite emulator lacks support, they are a bitstream-level format that should be convertible to a more modern bitstream image format.

I found an interesting allegation that Central Point Software cut a deal with Softguard at some point. Supposedly, a later version of the accompanying software for the Copy II PC Option Board could make a single backup copy of an original Superlok 3.0 disk, but would mark the resulting disk as a copy. The software would then fail to duplicate a disk identified as an existing copy, thus preventing the proliferation of copies of copies.

This seems like a fair compromise perhaps, but there is just one problem - clever publishers could take the same 'copy' markings and ship them on their original disks, rendering the product unable to make copies at all.  I plan on a future article analyzing Copy II PC in more detail. Perhaps we can confirm these rumors for ourselves.

Another backup product was Quaid Software's CopyWrite, which bundled a similar utility to NOGUARD called 'UnGuard,' which could strip the protection from Superlok titles. Quaid software would eventually be dragged into an infamous court battle with another copy-protection company, Vault, but that is a story for another time.

Some publishers eventually decided that watching this cat-and-mouse game continue was not worth the potential issues experienced by end users, and dropped disk-based copy protection entirely. Articles such as this began to appear in publications:

InfoWorld Mar 31, 1986

Eventually, Softguard's biggest customers would move away from disk-based copy protection, leaving the company to face declining profits.  Softguard had developed a few other products, such as a virtual machine product for the Intel 386 called VM/386, but sold it off in 1987. In the end it seems Softguard failed to pivot to any substantial new revenue sources.

I couldn't find much information on the ultimate fate of Softguard Systems, other than that they were out of business by 1992, about which time their magazine advertisements abruptly disappear.