Anti-Piracy Protection
See Also: Read Only Plug-Ins.
Developers may wish to implement an anti-piracy protection scheme for their plug-ins. The 3ds max SDK provides a function developers may use as part of their copy protection strategy. This function retrieves the unique hardware lock ID attached to a particular machine. 3ds max itself requires the machine to have a hardware lock, and every hardware lock used with 3ds max has a unique ID associated with it. The function HardwareLockID() returns this ID as an unsigned integer. A developer can call this function using the code shown below:
Prototype:
unsigned int HardwareLockID();
Remarks:
This function returns 0 if no lock is found and the lock ID if one is found, regardless if 3ds max is in slave mode or not.
Sample Code:
unsigned int hLockID = HardwareLockID()
Developers may key off this ID in numerous ways to authorize a plug-in to run on only a particular machine. The actual copy protection strategy employed using this lock ID is the developers responsibility. 3ds max is only responsible for insuring the integrity of the HardwareLockID() function. Internally, 3ds max checks the integrity of this function to prevent tampering that attempts to affect the values returned from the function.
Developers are, of course, free to implement any additional copy protection schemes as they see fit. The two basic suggested methods are to either be "tricky" about what they do to the plug-in code / functionality once it has been detected that the lock check has been tampered with or they can go to the extreme of providing an additional hardware lock for use with their own plug-ins.
In any anti-piracy / authorization strategy employed, developers should be careful how their code affects users. For example, putting up an authorization dialog when 3ds max is performing a network render is very destructive and mustn't be done. Also, plug-ins that pop up dialogs when the command panel branch is changed are also far too inconvenient for the user. Anti-Piracy dialogs should not be implemented where they will pop up from any calls within the Class Descriptor. It may be appropriate to put lock checking code inside ClassDesc methods, but putting up dialogs that interrupts the users work flow should not be done there. The best places to show dialogs are within methods such as CreateParamDialog() or BeginEditParams(). If you have a rendering related plug-in (renderer, material, texmap, atmospheric effect, etc.) that you want licensed per CPU, it's better to use a watermark or to disable functionality, but don't disrupt the user's workflow.
Sample code using an authorization scheme can be found in \MAXSDK\SAMPLES\MODIFIERS\TWIST.CPP.