-
OCX Licensing
This topic is new to me and I'm not sure I completely understand it. This pertains to the check box when compiling an ocx to use Licenses.
Thru some trial and error and a ton of googling/reading, I answered most of the questions below. If you can add to any of them, I'd appreciate it. But I've come to the realization that a licensed ocx is to easy to steal if just one registered owner is willing to pass some information. I will try a different, customized, plan of attack.
1. If I want a usercontrol to require licensing, I understand I can have VB require a license for it. In doing so, I understand that the license is a registry entry inserted by the Setup.exe and anyone on that pc then can use the control in design/runtime. Did I understand that correctly?
Edited: Not quite. VB kicks out a vbl file which is just a .reg with a vbl extension. The registry entry will be added during Setup.exe. If one had access to the vbl, one can change vbl to reg, execute it, register the OCX with regsvr and it has the same effect. This license is for design-time only, runtime license is compiled into the host exe if the design-time license is present.
2. Also, the owner of the ocx can safely distribute an exe they created that uses the licensed ocx and their customers do not need the license because it gets compiled into their app's exe. Did I understand that correctly?
Edited: True, the key is compiled into the application. The key that is compiled is not the same key in the vbl file. Getting this runtime key is a snap. This presents another security hole. If I knew the runtime license, then I can dynamically add ocxs to my runtime form without even purchasing the ocx -- granted that the ocx will be loaded late-bound, but still very usable.
3. Also, if the owner attempts to create a new ocx that contains the one I sold them, and compiles it, it will not work, because the owner would need my license file in order to compile my control in their control. Did I understand that correctly?
Edited: From what I gather this may be true. If the buyer has the vbl file, then has complete control, correct? However, creating a vbl file from the registry is a snap if you know the CLSID of the ocx (and that isn't that difficult to get either).
4. Being that the license is a registry entry, how would you rate the relative security of the control from simply being passed to other people?
Edited: Poor security. The design-time license is too easy to retrieve even if unknown. If the buyer knows where to look in the registry, they simply create a vbl file and pass that and your OCX to other people.
Edited: 4a. Does anyone know how to generate custom design-time licenses for the ocx? If the key that is created by VB that is placed in the vbl file can be customized/self-created, then one can use known strategies to try to prevent the design-time license from being run on other machines.
5. Do you have any recommendations for providing better theft-protection for ocx's? I am aware of creating custom keys to help prevent theft, but would this really work for ocx's? The reason I ask is that normally, the keys are designed from hardware/software on the registered pc. But if the owner wants to include the ocx in their applications (which they have a right to do if normal licensing was in play), wouldn't the custom key fail when the ocx tried to verify the key? Afterall, the ocx is now in a compiled exe that now exists on someone elses pc.
6. Any other tips, advice or "gotchas" are more than welcomed.
Thank you.