I think that would suffer from the same sort of problems as Windows Product Activation. Create a simple COM object that has the same function names and always returns true for validation function calls. In general the simpler the input and output values are for the security mechanism, the easier it is to reverse engineer/bypass.
You could, of course write a big chunk of your application logic in the COM object, but that's probably not an ideal solution for most CF developers. Spike > -----Original Message----- > From: Garry Mills [mailto:[EMAIL PROTECTED]] > Sent: 05 September 2002 14:15 > To: '[EMAIL PROTECTED]' > Subject: RE: [ cf-dev ] .cfm enryption > > > How about a COM object or similar to validate registration > that requires a dongle? > > Garry > > -----Original Message----- > From: Spike [mailto:[EMAIL PROTECTED]] > Sent: 05 September 2002 13:12 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] .cfm enryption > > > That sounds like a system that is far too simple to have any > real power in terms of stopping piracy. > > Think about Windows Product Activation. No matter how good > that system is, circumventing it is just a matter of changing > a DLL. Now, if the window manager for windows was accessed > across the internet then Microsoft would have a real way to > stop piracy becuase the cost of rewriting the functionality > of the window manager would be more than the cost of paying > for the windows license in the first place. You would, of > course, have a dog slow system if that's how it worked, but > there wouldn't be anything stopping the rest of the OS > loading the window manager into memory at login and running > it from there. > > The difference with webservices is that it isn't quite so > easy to deploy components or functions as the result of a > webservice call, so you're left with the option of calling > the webservice remotely to implement the valuable parts of > your application. Currently this would not have any hope of > competing in performance terms with a local comoponent being > called from memory. Maybe someone will find a smart way to > return functions and components, that can be used in a CF app > without writing anything to disk, as the result of a webservice call. > > Now that would be a real step forward. > > Spike > > > -----Original Message----- > > From: Stephen Moretti [mailto:[EMAIL PROTECTED]] > > Sent: 05 September 2002 13:37 > > To: [EMAIL PROTECTED] > > Subject: Re: [ cf-dev ] .cfm enryption > > > > > > > > > the problem here is that if the app doesn't depend on checking the > > > license > > everytime, then what's to stop the > > > user from fiddling with the code to stop it from checking > > the license > > > at > > all. There needs to be a key part of > > > the app's functionality which is only accessible through the > > > webservice, > > then the user can't bypass this and > > > avoid the licensing check. > > > > How about using their licence key, plus some other > > information collected from the web service, as the key for > > some piece of information that is encrypted in their > > installation's DB? > > > > > > > > > > -- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] For human help, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
