PC Floppy Copy Protection: Vault Prolok
This is Part 4 of a series on PC floppy copy protection methods. You can read the previous parts here:
- Part 1, covering Formaster Copy-Lock
- Part 2, covering Softguard Superlok
- Part 3, covering EA Interlock
Vault Corporation
Vault was conceived in 1979 and incorporated in 1983. There's not much information about the early days of the company, but 1983 was a busy year for them. The trademark filing for Prolok, their first copy-protection product has a first-use date of March 1983. That same year would see several full-page, color advertisements in various PC magazines, making them one of the major competitors of firms like Softguard. Compared to the modest back-page adverts from other copy-protection firms, Vault's advertisements were very slick - clearly put together by a professional ad agency.
One of Vault's biggest customers was Ashton-Tate, makers of the industry-leading dBase database software and later owners of the Framework office suite. Both dBase III v1.0 and Framework 1.0 would see releases incorporating Vault's Prolok copy protection. Ashton-Tate was even impressed enough by Prolok to invest $500,000 in Vault, acquiring a 20% interest in the company.
Vault had over 2,000 customers of Prolok during its heyday, according to former Vault VP Peter Avritch.
Vault expressed a high degree of confidence in their product. One of their advertisements even stated the following:
We're proud of Prolok and the fact it represents the end of software piracy.
I probably don't need to tell you that Prolok was not the end of software piracy.
PROLOK
Prolok differed from other floppy copy-protections in two significant ways. First, the protection did not rely on unusually formatted diskettes, crazy track layouts or non-standard sectors. Instead, the protection relied on deliberate damage to the disk surface, which Vault referred to as a "fingerprint."
Secondly, unlike other methods which were applied during a professional disk duplication process, Prolok was offered as a commercial product in the form of pre-damaged diskettes upon which a software publisher could write their software.
Prolok Software Protection Diskettes
Once a software publisher had purchased a set of Prolok protection diskettes, they would use the PROLOK.EXE utility included on the disk to write their software to the disk. The utility would encrypt and wrap the program inside a protected loader.
Vault offered a evaluation package for $9.95, if you just wanted to see how it worked for your application. A 10-pack cost a little over $30, but bulk orders of Prolok diskettes could drop the cost to as little as $1 a disk. This was still relatively expensive compared to what commercial disk duplicators paid for blank media.
The Prolok technology is described in US patent #4785361. The inventor is listed as W. Krag Brotby, who was Vault's president and chairman.
The patent gives a good description of how the technology worked:
The security check procedure involves a test to determine whether the disk on which it has been recorded has or does not have the physical fingerprint that is the hallmark of an authorized disk. If the fingerprint is present, the security check procedure enables the read/write head to read out the protected material; however, if the fingerprint is absent, as it would be from an unauthorized disk, the security check procedure prevents the read/write head from reading out the protected material.
In a preferred embodiment, if the fingerprint is not present, the security check procedure instructs the read/write head to obliterate or to erase the protected material.
Note the last sentence, this would not be the last time Vault expressed a cavalier attitude toward the data of suspected pirates. Deliberately damaging user data is almost always a bad idea - Vault ended up replacing some early Prolok-protected media that was inadvertently erased due to compatibility issues.
In a first embodiment of the invention, which is preferred for its simplicity, a localized permanent defective area is intentionally created at the factory on the unrecorded disk at a random location on the recording surface, on the portion of the recording surface reserved for the material to be protected. The effect of the defect is to render the affected portion of the disk incapable of accurately reading out a piece of data that previously a write head had attempted to record on the defect.
Exactly how this damaged area was created is not specified - PC folklore often describes burning a hole through a disk with a laser. In actuality, no physical hole is produced through the disk media, but you could think of it as a "hole" in the magnetic oxide coating. The side of the disk opposite the fingerprint is not affected.
Regardless of the exact mechanism - laser or otherwise - a robotic process was employed that precisely disturbed the fine iron oxide coating on the disk sufficiently that it could no longer be written to. More than one damaged area may be present on a single disk.
The Prolok "Fingerprint" |
The disk protection check therefore worked under the assumption that you could write to a sector containing the damaged area, but not read all of the written data back. Reproducing these partially-writable areas would be impossible via conventional means.
Curiously, the patent describes a "third embodiment" of Prolok that enters the realm of science-fiction. It describes a special disk jacket that would somehow incorporate a miniaturized write head and battery. This tiny drive head would modify the disk every time you ran the software:
I don't really need to comment further on the feasibility of that particular scheme, especially considering the limitations of 1980's era technology.
Vault had a bit of a habit of overstating the sophistication of their fingerprinting technology. At the end of the day they were just burned circles on a disk.
Vault's Other Products
Hard Disk Prolok
Filelok
Techline
PC Week, Oct 1987 |
Telelok
MIS Week, Jan 1984 Are you really doing Computer Science if you don't have your lab coat on? |
Telelok would gain Vault the attention of telecommunications giant AT&T, which at one point was rumored to be considering an investment of $10 million into the company. This investment would ultimately never materialize.
InfoWorld, July 1984 |
Miscellaneous Other Products
Analyzing The Prolok Software Protection Disk
Running PROLOK.EXE without arguments |
Analyzing PROLOK.EXE
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:
I removed the copy protection diskette, and executed catprot.exe off our new copy. It felt like the loading process took a bit longer, but just as I was expecting to see an error Alley Cat started up in all its CGA glory.
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:
PC Magazine, Nov 27, 1984 |
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.
Letter to the Editor, PC Magazine, Mar 1985 |
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
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:
DosBox-TC fooling Prolok |
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:
A Prolok fingerprint, 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.
Prolok-protected dBase III v1.0 running in MartyPC |
Comments
Post a Comment