The Long View

 

Copy Protection

 

    During the Summer of Napster in 2000 I bought more CDs than any other 3 month period before or since.  I guess the RIAA, Lars Ulrich, Dr. Dre and Madonna would consider my participation in the Napster phenomenon as having inflicted some kind of financial damage on them, but they would be wrong.  For the artists whose work I admire, and for the RIAA, it was a net positive thing that continues to this day, and it was a wash for those three artists (I have never downloaded or purchased a  Metallica Dr. Dre, or Madonna recording).  A lot of what I (re)discovered on Napster were half-forgotten songs from my youth, and overlooked music from periods of my life when I lost touch with popular music, being preoccupied by career or child-rearing concerns.  It happened at just the right time for me to catch up, and I am still catching up.  Shawn Fanning is directly responsible for the fact that I now make regular monthly payments to emusic.com. 

    It seemed obvious that when somebody is giving music away it would reduce profits in the music business.  The RIAA had facts and figures to prove it.  Their argument goes something like this:  If everybody who had downloaded "Disappear" had bought a copy of it it instead, Metallica's record company would have made a bundle.  But of course all those people wouldn't have bought it.  They downloaded it just to have a listen. Like hearing it on the radio.  The things about downloaded music that seemed obvious to the music company suits were mostly wrong. Everybody knew it.  We had all been there before.  A similarly flawed reckoning had been previously used to prove that software companies were losing millions because of pirated copies of their software.


Gates Open Letter on Software Piracy

    In 1976, long before Napster, and long before there was a commercial market for personal computer software, Bill Gates wrote a famous open letter to computer hobbyists.  On the basis of informal feedback from users of his Altair BASIC interpreter (Microsoft's first product, back when they were called Micro Soft), Gates concluded that only 10% of the copies of his company's software in use had been legally purchased. We don't know much about Bill's data and it seems a little dubious.   Apparently, Altair owners, when asked whether they used Gate's BASIC said yes they did, and when asked whether they had acquired it legally, they told him no, they hadn't.  Whether his information was accurate or not, Gates calculated that the return on his and Paul Allen's time in developing the software was less than $2/hour, and would have been more (something more like $20/hr) if all those users had paid for the interpreter.  He complained:


" As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?"


Gates predicted that the personal computer software business would never get started if this continued.  Of course it did get going, and when that happened, Gates and all the other commercial software houses protected their software from copying, one way or the other.  The BASIC interpreter for the Altair was distributed on punched paper tape.  The software market really heated up with the Apple II, which had a floppy disk, and its software was distributed on 5.25" diskettes.  This suggested a possible means of controlling illegal copying.  If you couldn't copy the diskette, you couldn't share the software on it with others.  The legitimate purchaser of the program would have the disk, and could share it if desired, but would have to get it back to use it himself.  Programmers deployed a lot of clever tricks for preventing copying, most of which depended on disk drive implementation details, and the hardware and software designs of the Apple II disk drive were famously loaded with clever hacks.  Inventing a cool copy protection scheme on your disk was yet another way to express your creativity and awes0me skilz as a programmer.  Likewise, it was a challenge to the hobbyist software purchaser to try to remove (crack) it, and computer hobbyists took up the challenge, whether they wanted to share the software or not.  This set off a battle of skills between software producers and consumers that raged for years. 


The Lisa, and the Professional Software Market

    Corporate software was originally in-house.  Even the early operating systems for IBM mainframes were written by customers.  IBM wrote the first bundled operating system for their 360 machines in the 1960's and after that customers expected software and software support as part of the bargain in the purchase of a corporate computer system.  The minicomputers that were all the rage at universities and engineering firms in the 1970's and 1980's came with operating systems and programming tools, and nothing more.  Users wrote their own software, and shared it with others.  Users of DEC's PDP-11, which was introduced in 1972 and was widely used in universities for more than a decade, relied on an independent DEC user's group called DECUS.  Early computer games, like Adventure, were distributed by DECUS.  Scientific computing at Universities was based on sharing software.  But in the 1980's, corporate customers were more and more basing their computer purchases on 'whole solutions'.  This meant that the computer came with software that was expected to fulfill all the purposes for which the computer was intended. Engineering firms purchased computers with computer-aided design and manufacturing software as a package from OEMs.  And offices purchased specialized office systems that were expected to be turnkey systems.  Examples of this included the CPT office systems, Wang Laboratories office computers, and of course the Xerox 8010 Star Office System.  It was into this environment that Apple inserted the Lisa Office System.

    The Lisa came with the Lisa 7/7 Office System, which was expected to be a complete software solution for the office.  Other than the programming tools, there was no other software available for the Lisa, and every Lisa customer got the Lisa Office System.  Even so, every Lisa came with software-accessible unique serial number, and the first time you installed the 7/7 software, the serial number of your particular Lisa got associated with those disks, and they could not be used to install on any other Lisa. Each program's entry in the disk catalog was followed by a block of bytes that included the serial number of the Lisa it was installed on.  Setting those bytes to zero with a sector editor could restore the disk to its original deserialized state, and allow it to be used on another Lisa.  It was not a particularly strong copy protection system.  Anybody with a sector editor could defeat it, but Apple did not provide a sector editor for the Lisa.  And anyway, why would you need to deserialize your disks? 

    More importantly, why did Apple think they needed to protect their Lisa software from being copied?  The only people who could use it were people who had bought a Lisa from Apple, and they already had a copy of the software.  Apple made their money from the sale of the computer, not the software.  Maybe they were looking forward to a time when there would be 3rd party software for the Lisa, and they were offering copy protection as a feature to assure those software producers that their product would be protected.  But if that was it, why was the copy protection scheme so weak?  Experience with the Apple II had already proven that computer purchasers were pretty resourceful when it came to defeating disk copy protection.  The Lisa mechanism was so lame.  It wouldn't have lasted a minute with the Apple II crowd.  Maybe they thought that office workers were less capable in this regard.  Don't worry, that bunch of Bozo's will never figure this out. 


The Bozo Bit

The Macintosh came equipped with what has got to be the lamest copy protection scheme of all time.  It was built into the Finder's private database of information on files, which could readily be accessed by any program using the toolbox call PBGetFInfo.  Among the information obtainable that way was a data structure called FInfo.  Within the FInfo was a 16 bit word called fdFlags, whose bits were used to hold a set of flags governing the file's use by the Finder.
Bit 11 of this was called Bozo, or don't copy.  If this bit was set, the Finder would refuse to make a copy of the file.  Of course, if you wanted to change this bit, you could just do so, and write the changed version of FInfo to the Finder's database using PGSetFInfo.  I don't know what was on the minds of whomever put this into the Finder, but it was never used by anybody and even the Finder quit paying any attention to it starting with System 5.  In System 7, the fdFlags bitfields were reorganized, and bit 11 was repurposed to become the isStationary bit.  Technical Note #40 documented the change.  I never heard an official explanation of why it was called the Bozo bit.  Maybe no explanation is necessary.


Key-Disk Protection on the Macintosh

   A very healthy software industry assembled around the Macintosh rapidly after its introduction.  The Macintosh disk drive was a little different from the one on the Apple II, but the methods adopted by 3rd party developers to protect their software from being pirated were about the same. There was no internet at that time, and so pirated software was copied from disk to disk.  The best way to prevent it was to make the software impossible to copy.  This meant that consumers could not make a working backup of the diskette, but had to use their original diskette to run the software.  This made most consumers nervous.  Most early versions of the Macintosh had a single disk drive, so the System and Finder had to be on the same diskette with the program.  The original diskette could not be locked, as the system needed to write to it (e.g. the clipboard and scrapbook files).  There was a small but finite chance of ruining the diskette every time it was used. Customers wanted to make backup copies of their original diskettes and use those, even if they had no intention of selling or giving away an illegal copy. But if you let them do that, they could also make a copy for distribution.

   There was no effective way of preventing users from copying programs from one diskette to another.  Of course, to execute the software the segment loader would have to be able to read and load the program from the disk.  Thus, the file containing program itself had to be intact and readable.  In the absence of a working Bozo bit or something like that, there was nothing to keep the Finder from writing it on another disk.  The most common approach was to put bad sectors on the disk at known locations, not contained within any file.  The Finder, and standard disk copy programs couldn't (wouldn't) copy the bad sectors, so any copy would either fail because of the bad blocks, or would ignore them (as they were benign).  At startup, the application would try to read the disk at those locations.  If the read(s) succeeded, it meant that the program was a copy. In an effort to lighten the risk of damage to the original disk, many programmers allowed their customers to run the program from a copy.  But in that case they would make you insert the (locked) original disk one time at startup, and it would be validated and ejected.  Hence the original diskette was a sort of key that could be used briefly to unlock a copy of the program.  It would have to be unlocked with the key disk each time it was launched. 


Bit-by-Bit Disk Copy

    The obvious solution for innocent customers who wanted to back up their software and for pirates alike was to just copy the diskette, bad blocks and all.  The most popular program designed to do this on the Macintosh was CopyIIMac, from Central Point Software.  According to the documentation for that program, making a copy of an "owned" program for "archival purposes only" was legal.  But if the program was licensed, not sold, you might not have that privilege.  CopyIIMac suggested that users check their local state law, and informed them that they should not make a copy if it was illegal.  I don't know how effective this legal advice was.  The program also came with a list of copy protected programs that CopyIIMac was know to be able to copy.  I have version 6.3 (1986), and its list contains scores of popular programs of all kinds.  Copy protection was rampant, and CopyIIMac could defeat practically all of it.  Another Central Point program CopyIIHardDisk, would copy a program to your hard disk in a way that allowed it to run without the key disk.  These programs didn't consist of a set of specific cracks for individual programs, but just tried to do a simple copy of the disk including bad blocks.  Copying to hard disks was harder, and it was easy for programmers to defeat CopyIIHardDisk if they wanted to.  An easy solution was just to try to read a sector that wouldn't exist on a floppy diskette.  Sector copy worked pretty well for making a copy of your original diskette on an diskette of the same size, but pretty soon you had a hard disk and you wanted to run all your programs from there.  In that case, you had to resort to a tougher option.

   

Key Disk Cracking

   Giving the user the privilege of unlocking a copy of the program was a nice gesture.  But customers were still annoyed.  And worse, it created a weakness in the copy protection that made it easier to defeat.  When the program discovered that it had not been launched from the key disk, it would put up an alert saying that, and giving the user the opportunity to insert the key disk.  At this point, an examination of the stack would reveal the key subroutines that had made the discovery and acted on it.  Once you found the code that decided whether the disk was valid or not, it was pretty easy to alter the disk copy of the code to always decide that it was.  This was not a legal gray area.  We were not allowed to do that.  But it was an interesting hypothetical.  If you were going to crack that program, how would you do it, and how hard would it be?  Well actually, not that hard. 

   For example, Habadex (Haba Systems) was an early contacts manager that ran on the original 128K Macintosh.  It used a simple key-disk copy protection that was typical of programs at that time.  I purchased a copy of it for my first Macintosh, and my wife and I used it to keep our contacts book for a year or two.  I still have it around, as an MFS (400k) sony diskette, and it still works.  I tried copying it with CopyIIMac, and that worked fine and ran without asking for insertion of the key disk.  I could also make a regular copy with the Finder, but when I tried to launch it, I got this alert. 

  

   When I inserted the original Habadex diskette, the program would read and eject the disk, and then continue to run from the copy.  So there is your opening for figuring it out.  Launch the program from the copy on a system disk that has TMON installed and when the alert comes up, hit the programmer's switch and go into TMON.  Now open a disassembly window on the current program counter.  As expected, the program is in the ROM, in the toolbox routine GetNextEvent.  The program is looping,  waiting for the key disk to be inserted. 
Toolbox calls like GetNextEvent are not called using a regular A6 stack frame so we can’t walk back to the caller using a stack walk.  Let’s step out of GetNextEvent to find the caller.
  

  

  Whoa.  This program was made using the Lisa Workshop (as expected for a program of its era) and shipped with debugging symbols in the code.  That means we can see the names of all the subroutines in line.  The subroutine calling GetNextEvent is WAITMAST, which has drawn the alert (not using the regular toolbox call, but by just drawing straight to the desktop) and is waiting for the disk insertion event.  It is waiting for the master disk. This isn't the one we want.  Walk up the stack one more level, and we are in... COPYPROTECT. 


That definitely sounds like the one we want.  Look up a little bit to see what happened before it decided to ask us for the key disk.  Hmm.  It makes a call to a subroutine called BADTRACK.  This sounds like a routine that would look for a bad sector.  BADTRACK returns a value in D0 that gets tested against 1 and there's a branch that skips WAITMAST.  We should just replace the conditional branch with a nonconditional one so that we always skip WAITMAST.  If we’re lucky, that’s all we have to do.  This can't be done with the memory image in TMON, but requires a sector editor.  I would normally use Resourcerer, but I'm trying to stick to period tools, so I use Fedit.  Fedit won’t disassemble code, so we need to open a TMON dump window on the code, to see it the way it will appear in Fedit.


We can now enter an appropriate search string in Fedit.  Search in fedit for the second line, 67 0A 2F 0E 4D BA FE 94.  This should be enough to make it unique.  The code we want to change is the BEQ (67 0A).  The second byte is the offset, the first is the instruction.  Let’s make it a BRA using the same offset (60 0A). 


Once done, the program always thinks that BADTRACK found the bad track.  That should do it.  



Using only techniques and tools that were available to any Macintosh hobbyist of the time, it took only about 10 minutes to crack the copy protection scheme used by Habadex, and most of the programs of its time.  It is not too difficult to see why these copy protection schemes were not very effective.  They combined annoying with ease in circumvention.  That is not a good combination.  Most copy protection method ultimately rely on the goodwill of users.  Don't annoy them.  Make it easy for legal users to use their software legally.

   One very cool variant of the key disk method was the key disk-manual method.  At startup, if the program is not being launched from the key disk, it asks the user a question from the manual.  My favorite one of these is Ancient Art of War at Sea.  It's predecessor, Ancient Art of War, used a regular key disk method like Habadex.  But Ancient Art of War at Sea let you run the program from a copy, if you also had a copy of the manual you could look stuff in.  At that time, computer manuals were harder and more expensive to copy than diskettes.  Ancient Art of War at Sea had a wonderful manual full of naval history, written in an engaging way that informed the game play.  I have lost a lot of software manuals over the years, but my copy of the AAWAS manual is pristine.  I enjoyed answering the questions from the manual enough to leave the copy protection alone.  It was (is) a great game.

  

A Temporary Victory for Consumers

  Nobody liked copy protection and it didn't work.  In a rational universe, it would not survive. Software vendors would see that it was making things worse, and would try to promote goodwill with customers at the expense of tolerating a little pirating.  That’s what would happen in a rational universe, but it isn’t what you would expect to happen in ours.  Yet, that's exactly what did happen. Nearly everybody abandoned copy protection --  even Microsoft.  During the period in which Microsoft Word came to dominate the Macintosh word processor market, the program came with no copy protection whatsoever.  Likewise for practically all of their competition. The closest thing Word 5.1 had to a copy protection scheme was a feature that personalized the installer disk with your name, so all installations after the first would be personalized with the same name. 

   For a few years, most of the popular Macintosh and also DOS/Windows software came without copy protection.  This was a boon for the shrink-wrap software business, and like Napster, it resulted easy pirating and a huge spike in legal sales.  This same period saw the failure of shrink-wrap software for Unix.  During this period of rapid growth of commercial software, some vendors tried their hand at selling it for Unix Workstations like the Suns.  I tried to buy a Sun version of some favorite programs.  They were a little more expensive that the Mac or DOS equivalent, but not by much.  I bought SunWrite, SunPaint and SunDraw [heh], which later were sold by Island Software.  I also bought a copy of Mathematica (v2), and a copy of Framemaker. These were all great programs, but using them was an amazing pain.  They used a third party license manager (still in use today) that had terrible documentation and an incomprehensible set of command line configuration programs.  It  stored its configuration data in incomprehensible files.  I guess it was obscure and difficult for a reason:  to keep people from cracking it.  But it also made it an enormous pain to set up, and whenever a new program was installed it would mess up the license configuration for all the existing programs. I couldn't quit using the Suns because of a piece of commercial technical software written for it.  We didn't have to pay for that program, but it did use the license manager.  I finally quit trying to install any other commercial software.  If you used the license manager to handle only one program, it seemed to work okay.  Instead of installing word processors and graphics programs on the Suns, I kept a Macintosh sitting right next to each one.  I was so glad when I was able to leave the Sun workstations behind.

  Also, computers turned over pretty fast.  Unix software used the hardware serial number for authentication, so moving the software from an old computer to a new one required a complicated process of contacting the software company, and trying to get the license moved to the new machine.  A new Macintosh or PC just meant removing the old installation and installing on the new machine  

       I guess that was a portent of what was coming.  Unix never took over the desktop.  It couldn’t even reside alone on mine.  At that time, and even today, I think copy protection of its software (in the absence of copy protection on Macintoshs and PCs) was a major contributor in its failure.  The survival of Unix required the open source movement, because the commercial Unix software industry would rather shoot itself in the head  than tolerate a little illegal copying.

 

The Return of Copy Protection

   Copy protection is back now, but it sucks less.  During the period when there was basically no copy protection, otherwise unprotected software came with a serial number that you had to enter to get it to work.  This was not copy protection, because pirates could easily distribute both the disk and the serial number, and of course they did.  But as the internet became ubiquitous, it became possible for the software to call home when first started, and automatically register itself.  When it did this, it could send some identifying number for the hardware, like the ethernet MAC number, along with other registration information.   An approach like this has been employed by Microsoft for their Windows operating system since 2005.  If not validated within 30 days of installation, it disables some features and begins to nag the user.  It sucks, because it means the program has to have internet access to become validated, but it doesn’t suck as bad as it would if it required the program to phone home every time it started up, or if it refused to run at all if not validated.

    Apple doesn’t use this approach, and doesn’t recommend it to their software vendors. These days (since Panther), Macintosh computers do have a hardware serial number that can be accessed from software.   But Apple doesn't recommend using this for DRM.  They recommend using the MAC address, if anything.  And in fact, Apple seems to remember the the lessons of the past, and do not advise software companies to annoy their customers with copy protection schemes of any kind.  Apple Technical Note 1103 says:


"Note: Beyond general advice such as provided in this technote, DTS does not support developing digital rights management products because of the significant compatibility issues involved that can affect customers. DTS does not maintain expertise in DRM techniques. Serious DRM is much more complicated than this technote describes."


    Many vendors have tried to establish soft anti-pirating schemes that do not torture users.  For example, some programs just check to see if someone is running another copy of the same program (with the same serial number) on another machine in the local network.  If so, one of the machines is unlicensed, and so the latecomer refuses to run.  Users can’t complain much about that.

    Linux, child of Unix, continues to be a hostile workplace for commercial software. Mathematica, for example.  If you want to move Mathematica from one linux machine to another, you have to get the new machine's mathpass number (which is unique, probably related to the ethernet MAC address), and send that in to Wolfram, and they send a password that will work with that machine only.  On a Mac, just install on the new machine.

  

The Mac App Store

    Given their history of collaboration with the recording industry on DRM in the original iTunes Music Store, you might expect Apple to employ DRM to protect software vendors using their Mac App Store.  If so, you are wrong, at least so far.  On the contrary, software purchased from the Mac App Store comes with a much more lenient license than that you get with most of the same software purchased elsewhere.  You might not have read the EULA, so here is the relevant part:


MAC APP STORE PRODUCT USAGE RULES


Except as otherwise set forth herein,


(i) If you are an individual acting in your personal capacity, you may download and use an application from the Mac App Store (“Mac App Store Product”) for personal, non-commercial use on any Apple-branded products running Mac OS X (“Mac Computer”) that you own or control.


(ii) If you are a commercial enterprise or educational institution, you may download a Mac App Store Product for use by either (a) a single individual on each of the Mac Computer(s) used by that individual that you own or control or (b) multiple individuals on a single shared Mac Computer that you own or control. For example, a single employee may use a Mac App Store Product on both the employee’s desktop Mac Computer and laptop Mac Computer, or multiple students may serially use a Mac App Store Product on a single Mac Computer located at a resource center or library. For the sake of clarity, each Mac Computer used serially by multiple users requires a separate license.


(iii) Use may require sign-in with the Apple ID used to download the Mac App Store Product from the Mac App Store. Mac App Store Products can be updated through the Mac App Store only.


If you still haven’t read it, it says that if you are a non-commercial user, you can copy the software to every computer you have. 


BG -- basalgangster@macgui.com

 

Sunday, September 25, 2011