Licensing

  • Thread starter Thread starter Stephen
  • Start date Start date
S

Stephen

I have created a greate MDE for a small client. They have since shown it to
a number of other businesses like themselves and they are not contacting me
to discussing getting a copy of the software.

I want to secure the software so that it cannot be copied from one client to
another without a license key.

There seems to be a lot of "encryption" and "secure" software utilities out
there, but alas, I am not a wizard with that technology.

Does anyone have a good recommendation for a simple, yet effective, software
taht is proven to work well at securing MDB/MDE/ADP files with
licensing/anti-copying securities?

-Stephen
 
Stephen said:
I have created a greate MDE for a small client. They have since
shown it to a number of other businesses like themselves and they are
not contacting me to discussing getting a copy of the software.

I want to secure the software so that it cannot be copied from one
client to another without a license key.
Click to expand...

There are some ideas on Tony Toews site, I believe
http://www.granite.ab.ca/access/demo.htm
 
Remember the "99/1" rule. The simplest scheme you can imagine, will stop 99%
of users from copying your database. (Maybe a hidden file, or a value in the
registry.) Conversely, the most complex scheme you can imagine, will not
stop the other 1%. So it's a matter of finding a balance. I designed a very
capable but complex scheme some years ago, then junked it for a simpler
method.

HTH,
TC
 
What was the simplier method?


TC said:
Remember the "99/1" rule. The simplest scheme you can imagine, will stop 99%
of users from copying your database. (Maybe a hidden file, or a value in the
registry.) Conversely, the most complex scheme you can imagine, will not
stop the other 1%. So it's a matter of finding a balance. I designed a very
capable but complex scheme some years ago, then junked it for a simpler
method.

HTH,
TC



it client
Click to expand...
 
I just put values in the registry. However:
Encrypt< those values somehow. Then the user can't make sense of them. For
Click to expand...
example, it's fine to have a value called AppExpiryDate. (I wonder what
that< might be!) But store the value as ^%$##@!@&*, not 5/6/2004 (for
Click to expand...
example). Then your application decrypts ^%$##@!@&* (at runtime) to get the
actual value.
Checksum< the values. Then the user can not change them at random to see
Click to expand...
what happens. Search the web for "checksum algorithyms" or similar if you're
not sure what a checksum is. A checksum lets your software tell if the user
has tried to change a saved value.

You might also "obfuscate" important data names. For example, you might
store the (encrypted) application expiry date in an item called
"SoftwareVersion" - not "AppExpiryDate"! A cryptographer would laugh at this
naive suggestion. But it is an easy, cost-free way of adding another hurdle
for casual crackers to jump.

If you checksum & encrypt the values, the user is free to look at them using
registry editor or whatever - but he doesn't know what each one does -
except what he can deduce from their names - and he certainly can not change
their values!

Of course, there are still some holes in this scheme. For example, a
"replay" attack, where the user installs your product, immediately saves the
new registry values (whatever they are), runs the product until it expires,
then restores the saved values & starts again. There are certain techniques
that you can use to defeat this. But that is working to stop the 1% of users
who probably can't be stopped, no matter how hard you try. So is it really
worth the effort?

One other thing. Say the user must give you a number (say the windows
product code), & you return an unlock code. With a simple approach, that
unlock code would work for any instance of that product code. So an evil
user could change his windows product code, then use the (known) unlock code
for that product code.

You can stop this in various ways. For example, you could have the user send
a cryptgrpahic has of (product code + random number). Then, an unlock code
can be restricted to a >single instance< of that product code. That is, in
essence, how my scheme works. Tom, with PC ID #123, gets unlock code ABC;
but Dick, who changes his PC ID to #123, will find that ABC won't work for
him!

HTH,
TC
(off for the day)
 
Stephen, further to this, my other post might take you in an
unnecessarily-complex direction.

If you want a really simple scheme, try something like this.

Have the installation process of your application create a new value in the
registry, or a new hidden file in a directory other-than your application's
normal directory.

Then, when a naive user copies your application to a different PC, he will
probably not know to copy the registry entry and/or hidden file.

Your application can detect the missing entry and/or file, and refuse to
run: "Application not properly installed!".

Of course, you would not want the message to say: "Can't find hidden
security file C:\SecretFile.dat" !!

HTH,
TC
 
Back
Top