Copy Protection Bits: File Flags and The Bozo Bit

[mrw]

Have you ever tried to copy a folder or file only to be stopped by a dialog that looks like one of these on System 6?


(Alert that says: "That contains items that cannot be duplicated or copied.")

(Alert that says: "That cannot be duplicated or copied.")

..or these on System 7?

(Alert that says: "Some selected items cannot be copied, because of copy protection. Do you want to continue copying?")


(Alert that says: '"Macintosh Pascal" cannot be copied, because of copy protection.")

I ran into this trying to use the Macintosh Pascal 1.0 disk image I downloaded from Macintosh Garden. I managed to defeat this restriction so I could code in 1985 style (and upload a usable SIT to the Garden).
Here's what I learned: a copy protection bit causes all of these errors, but it's not the bozo bit!

The Bozo Bit and Finder Flags

Apple included an infamously weak copy protection scheme known as the bozo bit that only early versions of the system software honored. Stephen Chernicoff's first volume of Macintosh Revealed defines it unkindly on page 546:

bozo bit - A Finder flag that prevents a file from being copied; named for the Apple programmer who invented it.

and goes into greater detail on page 360:

A 1 in this bit prevents the file from being copied: a protection scheme so feeble that only a bozo would think of it. Recent versions of the Finder (version 5.0 or greater) don't even
pay any attention to this bit.

One reason for its ignominious name might be that Apple gave up on it by 1985 when they released System 2.1 with Finder 5.0. But a more likely reason is its location: the bozo bit is a finder flag.

Finder flags are part of the FInfo structure that tracks important file metadata. Apple documented it as a public API at least as early as 1985's Inside Macintosh Volume II (II-84):

A file directory on a volume lists information about a ll the files on the volume. The information used by the Finder is contained in a data structure of type Flnfo:

TYPE Finfo = RECORD
fdType: OSType; {file type}
fdCreator: OSType; {file's creator}
fdFlags: Integer; {flags}
fdLocation: Point; {file's location}
fdFldr: INTEGER; {file's window}
END;

and (on II-85):

FdFlags indicates whether the file's icon is invisible, whether the file has a bundle, and other characteristics used internally by the Finder:

Bit Meaning
13 Set if file has a bundle
14 Set if file's icon is invisible

What about the other 14 bits? An enterprising programmer would only have to use GetFInfo and SetFInfo to find out what they did, and it turns out that bit 11 marks a file as uncopyable (Chernicoff' p 360) - the bozo bit. I suppose Apple hoped that Macintosh programmers would be more likely to pay for software than the average user. Oops.

By the time System 7.0 rolled around, the THINK Reference Inside Macintosh commentary for FInfo included a complete explanation of what each bit meant. But System 6's Finder flags meant different things!

The meaning of the flag bits in this structure [FDInfo] have changed significantly in System 7.0. Make sure you look at both diagrams below. The first one shows the old flags, and the second shows the new flags.

I underlined the "BOZO (don't copy)" bit in the System 6 and earlier Finder flags description above. You can see it's 0x0800 (2048), or bit 11.
In System 7.0, however...

Bit 11 marks a file as "stationery"! Inside Macintosh: Files agrees (1-41):

If your application supports stationery, it should check the stationery bit in the Finder flags to determine whether to treat the selected file as stationery.

It seems clear from Chernicoff, THINK Reference, and even Inside Macintosh that the "bozo bit" died with System 7. What's the source of those "can't copy" alerts in System 6, which shouldn't care about the bozo bit, and System 7, which didn't know about it?

The copy protection bit and file flags
The FInfo structure documented above is an in-memory representation of file metadata. But files live on disks when the power's off. How is that metadata stored on disk?

As early as MFS, HFS' predecessor, Macintosh stored metadata in a file directory near the start of a volume. Remember that MFS wasn't hierarchical; folders appeared in the Finder, but not in file dialogs, and you couldn't create them - you got one "Empty Folder" that would reappear if you renamed it.

Inside Macintosh Volume II explains graphically on II-120:


I'll save a deeper discussion of MFS for a different post; for this one, it's important to know:

• The volume information section indicates where to find file directory entries;
• Each file has its own directory entry with its metadata, including Finder flags and where the actual contents exist in the file contents section

Inside Macintosh is a little coy about the particulars of that metadata, but mentions something interesting in the diagram on II-123:

I underlined the first byte of the directory entry definition, flFlags, or the file flags. These describe things like if the entry is used (I suppose in case of a soft delete) and if the file is locked. Once again, what about the other 6 bits?

But first, where are the Finder flags? It turns out they're buried in the 16 bytes of flUsrWds, which consists of:

• 4 bytes of file type code;
• 4 bytes of creator code;
• 1 16-bit integer word of Finder flags (2 bytes);
• 3 remaining words (6 bytes)

HFS apparently uses these words in the same way, which made deciphering flUsrWds as easy as a lucky guess.

So much fo Finder flags. Clearly anything in flFlags must be distinct metadata. Maybe there's a copy protection bit in there?

Jörg Langowski determined that there is and wrote about it in a very early issue of MacTech:

The first part of the entry tells the system several parameters it needs to know about the file. ‘Attributes’ [flFlags] contains 8 bits of file attributes. For instance, Bit 7 set means that the file is open, bit 0 set means it is software locked, . Bit 6 is the copy protect bit. If you reset this one to zero, you will be able to copy a ‘protected’ file by dragging the icon.

Perfect! Now, what can we do about it?

If it were 1985 I would have braved Fedit, but I wasn't keen on breaking my PowerBook 100's ZuluSCSI drive image, even if it is an easy laptop to open up.

Instead, wrote a Python script based on the descriptions in that MacTech article and Inside Macintosh Volume II that can rewrite the entries on an MFS formatted disk image, removing copy protection bit 6 from the file flags. It traded clarity for verbosity - hopefull it's comprehensible even if you don't know (or like) Python.

The script prints out interesting information about each entry, and wouldn't you know:

Macintosh Pascal
copy protected? True
UserWords(file_type=b'APPL', file_creator=b'PASC', finder_flags=FinderFlags(locked=False, invisible=False, bundle=True, system=False, bozo=False, busy=False, changed=False, inited=True, private=0, original=8448), word_2=128, word_3=320, word_4=0)

The Macintosh Pascal program itself had bit 6 in its file flags set, but not bit 11 in its Finder flags. The patched disk image allowed me to copy Macintosh Pascal off the disk on Systems 6 and System 7!

There's more to say about this:

• What about HFS? HFS appears to honor this flag as well, though I'm not ready to publish my changes to machfs that help demonstrate this;
• Does anybody care about a Python library to manipulate MFS images? If so, I've got a good start that I can turn into something;
• What about the rest of Macintosh Pascal's copy protection? It's interesting! It turns out there are hidden files with resources that Macintosh Pascal must load on start up. If you can copy those along with Macintosh Pascal, then you've got a working program.

This was a long post with a lot of text that I hope comes up the next time somebody searches for "copy protection". Thanks for reading!

 

[Phipli]

Very interesting - I've never seen that in the wild.

I wonder if it got used much? Perhaps Apple used it internally on confidential documents? For example, most older schematics and other documents we have are scans, perhaps it was extremely difficult to copy a schematic file.

Does AppleShare honor it?

 

[tashtari]

Neat discovery, thanks for documenting it!

 

[mrw]

Very interesting - I've never seen that in the wild.

Until Macintosh Pascal, I hadn't either!

I wonder if it got used much? Perhaps Apple used it internally on confidential documents? For example, most older schematics and other documents we have are scans, perhaps it was extremely difficult to copy a schematic file.

Good point! It seems possible Apple used this mechanism to protect files internally, and makes it seem less coincidental that Macintosh Pascal uses it given that it was officially an Apple product. Maybe I should ask an Apple developer who was around then?

Your question also made me think about why this is such an apparently rare copy protection scheme, even though it continued to be supported. Two things occurred to me:

• A hard-to-set copy protection bit was a better fit for an era where the floppy was the Macintosh's primary storage device. Users bought software, like Macintosh Pascal, on floppies that usually served as distribution and boot media. I imagine it was customary to include a System Folder on most disks because nobody wanted their users to suffer from the complex expectation of a dedicated system disk, or from the indignity of disk swapper's elbow when possible.
• As hard drives became common, and software became installable onto those drives, the copy protection bit became at worst a serious impediment and at best as weak as the bozo bit. A lot of software from the late 80s and early 90s seems to have been installable by dragging folders from the disks onto a hard drive (and I guess that's still common in the macOS dmgs). Can't do that with the copy protection bit! Installer programs might have helped, but they would've had to set the bit on the copied files or otherwise circumvent its copy restriction. In both cases, the secret would have been revealed with judicious use of a debugger, and anyway I'm sure Apple wouldn't have wanted third-party developers doing this without a public API. Setting a copy protection bit out in the open like this brings us back to what gave the bozo bit it's name. Oh well!

Does AppleShare honor it?

This was such a good question I had to test it out.

I have a Quadra 650 with a ZuluSCSI and running System 7.5.3 on the same AppleTalk network as a Plus running System 6.0.8 (via LocalTalk) and a PowerBook 180 (via an AirTalk!) running System 7.1. I built a ZuluSCSI disk image (more on that below) with a single file ("Uncopyable File?") that has the copy protection bit set. Then I put this on the Quadra's SD card and shared it on my AppleTalk network. After I verified on the Quadra that I could not copy "Uncopyable File?" to its boot drive, I then tried to copy it from both the Plus and the PowerBook 180... and succeeded! The resulting file did not have its copy protection bit set. I could even use the Finder on either machine to duplicate "Uncopyable File?" on the exported share. That duplicate did not have the copy protection bit set, either, so I was able to copy it on the Quadra to the boot drive.
I didn't have time to try copying over "Uncopyable File?" but it seems clear that AppleShare, at least in 7.5.3, does not honor this bit!

If anybody would like to take it for a whirl I've put the image in a ZIP file attached to this message. It should be recognized by any ZuluSCSI-like device, and I've tested it with BasiliskII as well.

You can build your own with this Python script, also in the attached ZIP, but you'll need to patch machfs:

• Stick filFlags on the File instance created during Volume.read and grab it back for writing on Volume.write;
• Store the disk driver blocks ahead of the HFS volume in the ZuluSCSI disk image and write them back out (the commit message says "first block", but it should have said "initial blocks!").

You can also use the branch on my fork until I submit this upstream.