Volume Number: 13 (1997)
Issue Number: 10
Column Tag: develop

Copy Protection and Serial Numbers

by Brian Bechtel, Apple Computer, Inc.

Copy protection is hard, and it is difficult to find a scheme which is not easily broken. The Mac OS was not designed with copy protection in mind, and there is no unique serial number available on Mac OS based computers. There are some techniques which can be used to help differentiate between two Mac OS computers, and these techniques are described in this article.

DTS does not support copy protection because of the significant compatibility liabilities it involves. This article is a summary of some specific techniques which we have used or recommended in the past. DTS does not maintain expertise in copy protection techniques. Serious copy protection is much more complicated than this article describes.

In general, the only consistent serial number on a Mac OS based computer computer is on the bar code label which is attached to the outside of the case. There is no internal serial number on the logic board of any current Mac OS based computer computer. There is no internal serial number associated with the operating system. The only Macintosh with a real built-in serial number was the Macintosh XL. This machine had a serial number only because the Lisa (upon which it was based) had a serial number as part of the Lisa design.

There are some hardware devices, found on a limited range of Mac OS computers, which contain some unique identifier which could be used as a serial number. Examples are an Ethernet card installed or built-in Ethernet. (This is because Ethernet devices have an unique ID defined for each device.) Some (but not all) hard drives have a serial number which can be read using the SCSI Manager or ATA Manager. Other devices such as Token Ring cards or FireWire may also provide an unique identifier which may be used as a serial number. None of these hardware devices can be found across the entire Macintosh product line.

There are some "semi-unique" characteristics which you can use to help you determine if you are running software on the same machine which you were running on before. These are listed roughly in the order I'd recommend considering them.

File ID References

You can create and store the file ID reference for the application file. Create a file ID reference using PBCreateFileIDRef() and store it in an appropriate place. (An example of an appropriate place would be the preferences file. An inappropriate place would be the application resource fork, since this would prevent your application from running from locked media or a network server.) Compare the file ID reference to the file ID reference of the running application (the file ID reference will be in the ioFileID field returned by PBGetCatInfo). If it isn't the same, you are running on a different volume. File ID references are unique within a particular volume; they don't get reused. It's unlikely that two machines will give you the same file ID reference for the same file.

 // AddFileID creates a file ID reference for the 
 // file specified by the FSSpec. It returns the
 // created file ID reference so that you can store
 // this reference for future use.
 //
 OSErr AddFileID(FSSpec *file, long *fileID)
 {
 OSErr err;
 HParmBlkPtr h;
 
 h = (HParmBlkPtr)NewPtrClear(sizeof(HParamBlockRec));
 
 h->fidParam.ioCompletion = nil;
 h->fidParam.ioNamePtr = file->name;
 h->fidParam.ioVRefNum = file->vRefNum;
 h->fidParam.ioSrcDirID = file->parID;

 err = PBCreateFileIDRefSync(h);
 *fileID = h->fidParam.ioFileID;
 DisposePtr((void *)h);
 return(err);
 }

 // GetFileID returns the File ID reference for a file
 // where the File ID reference has previously been
 // created (by calling PBCreateFileIDRef)
 //
 OSErr GetFileID(FSSpec *file, long *fileID)
 {
 OSErr err;
 CInfoPBPtr cInfo;
 
 cInfo = (CInfoPBPtr)NewPtrClear(sizeof(CInfoPBRec));
 
 cInfo->hFileInfo.ioCompletion = nil;
 cInfo->hFileInfo.ioNamePtr = file->name;
 cInfo->hFileInfo.ioVRefNum = file->vRefNum;
 cInfo->hFileInfo.ioFDirIndex = 0;
 cInfo->hFileInfo.ioDirID = file->parID;

 err = PBGetCatInfoSync(cInfo);
 *fileID = cInfo->hFileInfo.ioDirID;
 DisposePtr((void *)cInfo);
 return(err);
 }

Ethernet Address

For those Macs which have an Ethernet card installed or built-in Ethernet, you can use the EGetInfo() call with a csCode of ENetGetInfo to get the currently assigned Ethernet address. See Inside Macintosh:Networking, page 11-26 and 11-36 for more information. Apple publishes sample code demonstrating how to obtain the Ethernet address under Open Transport.

The complication for this technique is that the default Ethernet address may be overridden by a resource of type 'eadr' in the System file. This is documented in Inside Macintosh:Networking on page 11-26. Because it is easily possible to override the hardware address, and because Ethernet is not guaranteed to exist on any particular model, this is not a good scheme.

Similar techniques can be used for a Mac OS computer with Token Ring cards or other cards, but a discussion of these cards is outside the scope of this document.

Hard Disk Serial Number

Some hard disks have serial numbers. Many ATA drives have such a serial number, but most SCSI hard disks do not. Apple publishes ATA demo sample code which shows how to get the serial number of an ATA drive. Only some Macintosh models have ATA drives, so this is not a good general purpose scheme.

SCSI Defect List

Some developers use the defect list from a SCSI drive. This won't work for a non-SCSI machine, but might be a good approach for a SCSI based Mac. See the SCSI-2 specification and Inside Macintosh:Devices for details of using the SCSI Manager. Source code demonstrating use of the SCSI Manager in a general case is on the tool chest developer CD. Only some Macintosh models have SCSI drives, so this is not a good general purpose scheme.

Directory ID of the System Folder

Compare the dirID of the System Folder. Use FindFolder() to get the dirID of the System Folder, and compare it to a previously stored parID. This isn't quite as unique as the file ID, since the system folder as preinstalled will tend to have the same directory ID from one machine to another. If the user creates a new System Folder (e.g. by doing a clean install of System Software, which appears to be a frequent activity when upgrading) then you will have different directory IDs. This is not a good scheme.

 // GetVolumeDirID returns the dirID of the System Folder
 //
 OSErr GetVolumeDirID(long *dirID)
 {
 OSErr err;
 short notUsed;

 err=FindFolder(kOnSystemDisk, kSystemFolderType, no,
 notUsed,dirID);
 return(err);
 }

Volume Creation Date

Compare the creation date of the volume. You can get this information from PBHGetVInfo(). This isn't quite as unique as the file ID, since the volume creation date will be set at the factory when system software is placed on the volume and will only be reset when a volume is reinitialized. Because this value tends to remain the same for a given set of machines, this is not a good scheme.

 long GetVolCreationDate(short vRefNum ) 
 { 
 OSErr err = noErr;
 HParamBlockRec pb;
 Str255 vName;

 vName [ 0 ] = '\0';
 pb.volumeParam.ioCompletion = nil;
 pb.volumeParam.ioNamePtr = vName;
 pb.volumeParam.ioVRefNum = vRefNum;
 pb.volumeParam.ioVolIndex = 0;
 err = PBHGetVInfoSync ( &pb );
 
 return ( pb.volumeParam.ioVCrDat);
 }

Network Registration

Rather than identifying an unique Macintosh, you may decide that you want to prevent multiple copies of the same application running on a network. The method some developers use is to register a fictitious device on the network using NBP (Name Binding Protocol) with the name being single serial number of the license. Other attempts to register the same device and serial number give an error that the program acts on to deny the use of the program. Chapter 3 of Inside Macintosh: Networking is a useful reference for NBP.

 /* 
 * Registers a entity with the specified object and type on the
 * specified socket. The pointer to the NamesTableEntry is
 * returned in ntePtr if the function returns noErr.
 * 
 */
 OSErr MyRegisterName(ConstStr32Param entityObject, 
 ConstStr32Param entityType,
 short socket, 
 NamesTableEntry **ntePtr)
 {
 MPPParamBlock mppPB;
 OSErr result;
 Str32 entityZone = "\p*";
 
 /* Allocate non-relocatable memory in the system heap for 
 * the names table entity 
 */
 *ntePtr = (NamesTableEntry *) 
 NewPtrSys((Size)sizeof(NamesTableEntry));

 if ( ntePtr == NULL )
 {
 result = MemError(); /* Return memory error */
 }
 else
 {
 /* Build the names table entity */
 NBPSetNTE((Ptr) *ntePtr, 
 (Ptr) entityObject, 
 (Ptr) entityType, 
 (Ptr) entityZone, 
 socket);
 
 /* ioRefNum and csCode are filled in by 
 * PRegisterName's glue */
 mppPB.NBPinterval = 0x0f; /* Reasonable values for the */
 mppPB.NBPcount = 0x03; /* interval and retry count */
 mppPB.NBPentityPtr = (Ptr) *ntePtr;
 mppPB.NBPverifyFlag = (char) true; /* unique name */
 
 result = PRegisterName(&mppPB, false);

 if ( result != noErr )
 DisposePtr((Ptr) *ntePtr);
 }

 return ( result );
 }

Note: DTS advises against applications searching the entire intranet for a matching entity. Such a search is time consuming. On a large network with many zones, you can spend substantial amounts of time doing this search. This would be not be considered reasonable in startup code. Instead, we advise that you search the local zone. If necessary, implement an asynchronous background search into the other zones.

Thing You Shouldn't Do

We discourage you from trying to use special tracks on formatted floppies, or special floppies. Apple does not document the floppy drive sufficiently for DTS to support such an action. Also, DiskCopy and other disk copying programs work very well at copying floppies, thus defeating such schemes. (DiskCopy was written inside Apple with access to the source of the floppy driver; we do not publish these details externally.) You should not rely on specific bizarre sectors of the hard disk (Apple relies on multiple vendors for its components. You cannot make undocumented assumptions about a particular machine or class of machines.)

Note: At some point in the future, Apple will create machines which do not support 800K GCR-formatted floppies. You should not depend upon specific hardware features such as 800K GCR formatting for copy protection purposes.

Copy protection is difficult to implement, and it is difficult to find a scheme which is not easily broken. The Mac OS was not designed with copy protection in mind, and there is no unique serial number available across the entire set of Mac OS based computers. There are some techniques which can be used to help differentiate between Mac OS computers, and these techniques are described in this article.

There are many more sophisticated schemes for copy protection. If you are serious about copy protection, you should probably be contacting one of the many companies which specialize in such solutions, rather than writing a solution yourself. Both hardware solutions (such as ADB dongles) and software solutions (such as licensing software) are widely available from third parties. DTS does not support copy protection because of the significant compatibility liabilities it involves. DTS does not maintain expertise in copy protection techniques.

1. Inside Macintosh:Devices.
2. ATA Device Software Guide.
3. Inside Macintosh:Networking, chapter 3, Name Binding Protocol SCSI-2 specification.

Thanks to Quinn, Jim Luther, Vinnie Moscaritolo, and Pete Gontier.

Brian Bechtel works in Developer Technical Support at Apple Computer, where he deals with PC Cards, PowerBooks, and device drivers. In his non-work life (yes, there is such a thing) he enjoys time with his family (Mary, Meg and Tacy), is passionate about the San Jose Sharks hockey team, and plays lousy acoustic guitar.