Copying Prolok Protected Titles

Despite all of Prolok's software tricks and the physical alteration of the disk itself, it was ultimately possible to defeat. The protection code used the standard disk interrupt vector 13h, meaning that you could load an anti-Prolok software utility that would stay resident in memory, intercept calls to interrupt 13h, and simulate the damaged area of the disk.  The protected program would be none the wiser.  A more robust protection such as Superlok 3.0 would directly access the floppy disk controller to avoid such interception, however this could potentially create compatibility issues.

Various commercial products such as Central Point Software's NOGUARD and Quaid Software's RAMKEY advertised their ability to circumvent Prolok copy-protection. The latest version of Quaid CopyWrite available on the Internet Archive that includes the RAMKEY utility was published in 1990 - that gives me hope that it may have been updated for any changes in this 1989 version of Prolok.

Before we can use the RAMKEY utility, we must make a copy of the protected disk with CopyWrite. This is what the CopyWrite interface looks like:

All we need to do is have our Prolok diskette in drive A:, and our blank diskette in drive B:, and hit enter.

Copying goes smoothly until we hit track 39, where the drive starts to make a lot of noise and we don't make progress for a while.  Eventually we tick over to track 40, which is one track too many for a standard floppy disk, but not unheard of. 

Writing the copy to the disk in drive B: proceeded similarly.

Eventually, the copy operation completes with the following message:

Vault Corporation vs Quaid Software

Vault was obviously unhappy with commercial products being sold that completely bypassed their flagship product.  In May of 1985, Vault filed a lawsuit against Quaid Software seeking $100 million in damages. This case would set an important precedent in copyright case law - significant enough to have its own Wikipedia article: Vault Corp. v. Quaid Software Ltd. 

Quaid Software would prevail in the court battle, confirming the right of users to make backup copies of software under Title 17 of US copyright law. It also overruled a state law, the Louisiana Software License Enforcement Act, which prohibited disassembling or reverse-engineering the Prolok software, deeming such activities an "essential step" of enabling consumer rights under Title 17.

The lawsuit came at no small cost to Quaid software founder, Robert McQuaid, who spent over $100,000 on the defense.

Details from the court filings show how far Vault went to try to protect the secrets of the Prolok code:

Their efforts included encrypting the PROLOK program in four layers of code, separating the various different programmers working on the program from each other, having all employees sign nondisclosure agreements prohibiting them from disclosing any of Vault's secrets, the use of shredding devices at the close of business each day to shred all paper containing any portion of the PROLOK program, and keeping the master PROLOK program locked in a safe.

Given all that secrecy, it's no wonder Vault was a bit upset to see Prolok so easily bypassed. 

An Interview With Robert McQuaid

I was fortunate enough to have the opportunity to interview Robert McQuaid about his experiences and the court battle with Vault. You can read the interview here.

Vault's Corporate Suicide

Occasionally, stories will emerge about a business decision so ill-advised that it basically tanks an entire company's fortunes.  Vault Corporation would give us an excellent example in its announcement of its "Prolok Plus" product.  

Reproduced here is an article from PC Magazine:

Here we hear a description of how Prolok Plus will format your hard drive or infect it with a virus on a failed protection check:

Ignore this at your own peril, cautions Vault Corporation Chairman W. Krag Brotby, because if the machine has a hard disk, its entire contents are likely to be erased. Prolok Plus can also implant a "worm" in the system that will cause immediate or subsequent damage to the data or operating system.

Needless to say, this set off a firestorm of negative consumer perception toward Vault Corporation, its Prolok product, and any commercial products that may have used it.  Although Prolok Plus was never actually implemented into any product as far as I can tell, the damage was done as rumors spread that any Prolok-protected title could potentially infect or erase your computer. 

Ashton-Tate, Vault's biggest customer understandably did not want to be associated with this, and by the end of the year had dropped Prolok from their products.  Vault Corporation would never recover from the reputational damage and loss of large customers, and would face increasing industry irrelevance from that point forward. Softguard Systems - subject of a previous post - would pick up some of Ashton-Tate's business in the wake of Vault's blunder.

Ironically perhaps, years later W. Krag Brotby would author several books on Information Security. 

Emulating Prolok

Emulation is an important tool in the interest of preserving computing history, and Prolok was certainly an important part of that history. I would like people to be able to use and analyze the Prolok protection in MartyPC. 

But how?  First of all, it seems we will need an image format that can define metadata about the disk surface.  The usual type of metadata stored in a disk image is a weak bit mask, relating to a copy-protection scheme which I haven't explained until now.

Weak Bits

Recall that floppy drives do not store 1's and 0's directly on the magnetic medium.  Instead, bits are encoded via a series of flux transitions, essentially reversals of the magnetic field. The time measured by the disk controller between each detected transition encodes a short sequence of bits.  

This scheme requires that flux transitions occur on a regular basis. The MFM encoding standard for floppies is designed to guarantee this - in a valid MFM stream, no more than three 0 bits should exist in a row before we see another 1 bit roll by.  This produces a steady stream of flux transitions.

Some clever copy-protection authors realized that such areas could be intentionally created on a disk, and detected by code that checked that the data read from these areas changed each time. These areas came to be called "weak bits". Like all good copy-protection schemes, such areas could not be created by a standard PC floppy controller.

The Prolok fingerprints essentially create weak bits, as the creation of the fingerprint destroys the regular flux transitions that we would otherwise expect to read.  But unlike a normal area of weak bits, writing over this area will fail to recreate normal flux transitions. The damaged area can no longer be written to. So it's not exactly the same.

Encoding Weak Bits

There are a few formats that allow for encoding both weak bits and deliberate damage ('holes') on the disk surface. MAME's MFI can do so - but it is a flux format that we don't yet support. Another format that we do support is 86F, the native format of the 86Box emulator. However, no images in 86F format that utilize the particular 'damage' surface description exist. 

So how do we encode Prolok's fingerprints into a working disk image file?

Jeff Parsons, of the web-based PCjs emulator, has already been down this road with Prolok in 2019, and posted his experiences in this blog post. PCjs uses a custom JSON-based disk format, and he was able to add the necessary metadata to describe the Prolok fingerprints on a diskette.  But this metadata will need to be added to each diskette as a manual process.

The 'Deluxe' version of the Copy II PC Option Board supported duplication of Prolok protection. No, the board did not include a laser to make holes in your copy - instead it was able to characterize the damaged sections and instruct the controller chip to simulate a damaged region. Clever.  This gives us hope that TransCopy-format images produced by the corresponding utility for the Option Board may support such encodings.

One small problem is that I do not currently own an Option Board, so I cannot produce TransCopy images myself.

Our frequent hero of this series, NewRisingSun, produced a utility bundled with his TransCopy-capable fork of DosBox called flux2tc.exe which can read a KryoFlux or SCP-format flux image, and produce a TransCopy format disk image. A TransCopy image of the Prolok-protected dBase III, converted in this manner, apparently works in this DosBox fork. I was optimistic it might support my catprot.exe as well.

I converted a KryoFlux dump of my protected Alley Cat disk using the command:

flux2tc "T:\gw\prolok_alleycat00\prolok_alleycat00.0.raw" catprot.tc --droptracks

Then I started DosBox-TC, and mounted the resulting disk image:

imgmount a -t floppy catprot.tc

After changing to drive A and running catprot.exe, I was greeted with the following:

Unfortunately, support for TransCopy images isn't present in other, more actively maintained forks of DosBox, and the actual DosBox-TC fork itself doesn't appear to be currently maintained or distributed officially anywhere. 

Using documentation provided by NewRisingSun, I added support for the TransCopy format in fluxfox, my disk image library that powers MartyPC.  At first I was a bit puzzled because TransCopy doesn't seem to have any metadata that would define areas of weak bits or intentional damage. So how is DosBox-TC simulating the Prolok fingerprints?

As it turns out, storing separate metadata for weak bits is not necessarily required.  An area of weak bits can be represented inline within the data stored in a bitstream-level image by simply encoding invalid MFM sequences (long strings of 0's).  And this is exactly what the flux2tc tool does.

We can detect this when we import a file, and create our own weak bit mask. Here is what that looks like, visualized:

The magenta color represents our weak bits. You can see that they are clustered around the location of the Prolok fingerprint. 

That's great, but how to we distinguish holes - which we cannot write to - from weak bits, which we possibly can?

The answer is that we may not need to.  At least for Prolok, we have a few assumptions we can make. First, we can assume that the relevant NFAs will always appear on Cylinder 39. (And probably just head 0, but there's no guarantee Vault didn't change sides of the disk at some point).  This is because the fingerprint 'hole' is actually so large that it would cover multiple tracks if it was not at the very inner edge of track data.

The second assumption is that we can treat sectors with weak bits, at least on Cylinder 39, as safely writable. There are other copy protection schemes that use weak bits, but these NFAs are never meant to be written to. Writing to an NFA could lay down a fresh set of flux transitions and actually ruin the protection, leaving you with a useless floppy.  So we don't really need to expect to write to a sector containing weak bits, normally. 

Therefore we can use a heuristic: if we encounter weak bits on Cylinder 39, we can treat those weak bits as holes. We will preserve our weak bit mask on writes, and use the mask to return random data on reads.

With weak bit support officially in place for TransCopy images, I created an integration test that validated that sector data could be written to a Prolok-fingerprinted sector then read back, and would see different data returned.

One Last Detail

With both support for TransCopy images and weak bits, I was hopeful that catprot.exe would run in MartyPC; but again I was presented with an error message instructing me to insert the original disk.

Looking at disk activity, I spotted a potential reason why. After performing the write test to the Cylinder 39, Head 0, Sector 4, Prolok issues a series of Read Sector ID commands.

Read Sector ID is another standard NEC drive controller command that simply returns the next sector ID the read head encounters as the disk is rotating. I have basic support for this command, but there is no simulation of the disk actually rotating, yet - so Read Sector ID always returns the sector ID set in the result phase of the previously issued command.  When Prolok issues this command multiple times, and sees that the resulting sector ID returned does not increment, it would be able to detect that it was not dealing with a real floppy drive.

My plan for MartyPC is to eventually have a full model of physical floppy timings, including head seek times and spindle rotation.  Am I going to need to implement that now before Prolok can be conquered?  There's only one way to find out. I added a function that, given a sector ID, will return the next sector ID actually present on the track, or wrap around to the start of the track and return the first sector ID. Every time Read Sector ID is called, we'll advance to the next sector.  Hopefully this will be enough, and we won't yet need to model the rotational speed of the disk just yet.

Success

With our Read Sector ID command fixed, we find that catprot.exe starts right up!

Let's try another Prolok protected title, Ashton-Tate's dBase III, v1.0.

We'll make a TransCopy image out of this from an SCP file, using flux2tc.  Normally, dBase will present an error message immediately if the protection check fails. So if we see anything at all, we're in business.