Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site Shasta.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!cmcl2!harvard!talcott!panda!genrad!decvax!decwrl!glacier!Shasta!gus
From: gus@Shasta.ARPA
Newsgroups: net.micro.mac
Subject: Re: bozo bit?
Message-ID: <1585@Shasta.ARPA>
Date: Wed, 11-Dec-85 23:22:11 EST
Article-I.D.: Shasta.1585
Posted: Wed Dec 11 23:22:11 1985
Date-Received: Sun, 15-Dec-85 00:30:42 EST
References: <2129@aecom.UUCP>
Distribution: net
Organization: Stanford University
Lines: 72

> Can someone explain to me what the bozo finder file bit is for?

The "bozo" bit in the MFS really doesn't do much of anything. It is where the
finder stores an in-memory copy of the copy protection bit. It turns out 
that there are TWO flags words in the directory: one maintained by the finder
and the other by the file system. Ironically however, the only programs that
really honor the copy protection flag are the finder and the old 128K four
pass disk copier. The SetFile utility from Apple only gives you access to
the "finder information" area of each directory entry. Newer programs also
give you access to the C.P. bit.

The "bozo's" are those people without any reasonable tools to deal with this 
sort of thing. Reasonable tools being Disk Util (Larry Kenyon's program),
FEDIT, Copy II Mac, or any of the 512K mass disk copiers. The 128K four
pass copier really has to go out of its way to detect that at least one of
the files on the disk is copy protected using this bit. I believe that there
is also a "global" copy protection bit somewhere in the volume header. I
don't know if it is actually used or not.

In any case, all of this shows the futility of building copy protection into
the operating system. As soon as a C.P. system is well understood, there are
tools designed immediately to defeat it. Any organized attempt to copy
protect more than one program in the same way makes all programs in such a
group vulnerable as soon as one is defeated. The Electronic Arts scheme I
described some weeks ago is a perfect example.

This situation creates an environment where anyone who is serious about C.P.
must "Re-invent the wheel." This leads to general chaos as developers must
devise ways to use undocumented features in the system. Apple DOES provide
some information to certified developers about how copy protection works on
the Mac. Unfortunately, Apple must necessarily not provide too much
information to too many people. Thus the most important products from the
largest companies get the most help. Smaller companies must either fend for
themselves or go to an outside contracter.

Companies that strike out on their own tend to make mistakes. These are the
sort of mistakes that inhibit HFS compatibility, or keep programs from
running on a Mac XL. Such programs will almost certainly NOT work with future
Mac architectures. This is a problem that will hamper Apple's ability to come
out with new products and still retain compatibility with a large portion of
the existing software base.

Companies who go to outside contractors must realize that any copy protection
house must provide a similar protection system to several clients in order
to keep the cost of such systems down to a minimum. I have heared stories of
$35 games serving as key disks for $250 business programs.

Hardware key systems will solve most of these problems if and when.
    1) They become available
    2) They become a built-in feature of the machine and not just an add-on
		kluge.
    3) They become very inexpensive to produce so that inclusion of a key
		does not add significantly to even the least expensive
		pacages.
Unfortunately, the first two criteria do not hold true today, and it remains
to be seen what the cost of such keys will be.

I have no doubt that a protection system using such keys can be cracked
unless 1) An important part of the program is in the key and executed there.
(This means puting a processor and a fair amount of ROM in the key) or
2) The key destroys itself if it suspects tampering. This would be rather
dangerous as some spurious signal could inadvertently erase the key and would
thus not be used any more than a copy protection system that sprinkles random
bits in memory if it smells something fishy. (Killer Prolok) I can emagine a
stong case for a user sueing a software company because valuable data was
lost when a nasty copy protection system triggered its "alarm."

On the other hand, there is no legal commercial market for defeating hardware
copy protection systems that do not otherwise impeed normal work as there is
for software copy protection. You will NOT see any "copy II Mac/key" sold
legally simply because itt could be proved that any attempt to use such a
product constitutes an attempt to make an unauthorized copy.