Prevent copying of application by third party

I have googled, and there are various methods around, nothing perfect though. So I am wondering whether anybody has come up with anything new in the area?

Issue: Distributing an Access application. The recipient is to be free to deploy as many frontends as desired. My idea is that all output (=reports) is tagged with "Trial version". Upon the one-off payment, the recipient should be able to insert one specific own logo and one specific own set of company info into the forntend - once. And then distibute the frontends.

A third party should not be able to run away with a copy and insert own info.

Thoughts how to go about this please? Or are we talking Sage or Peter's software only?

Nothing is perfect but there are options. One of the issues with your proposal is if the user wants to change their logo, move address etc.

One of the things I do is to have a 'systemdb' with a few tables in it to control the environment. This db is password protected and only opened via vba code in a referenced module which is compiled - no linked tables.

both files can be hidden and put in say the program files or appdata directory on install (I assume you are using an installer). You can also change the file extension of the systemdb which the app can 'correct' before accessing.

Of course, compiled code can be decompiled and I guess there are ways of breaking the encryption.

I am actually working on a registration process where the first thing the app does on opening is to silently check certain information via an API to a web hosted db which stores information about the licence - how many users allowed, has demo version time expired etc.

If the user isn't connected to the web then it'll 'pass' a few times before throwing a tantrum

First - make an mde
Second - go to everything access, and see why you (most likely) need their code protector
Third - think how you want the copy protection to work.

I use some common info within a users system to generate a MD5 hash. Effectively, you can reveal the MD5 hash without the user being able to work out the details that generated the ND5 hash. So if they install on a different PC, the new PC will produce a different MD5 hash, and the app won't run. The only thing is you can't get an expiry date into a MD5 hash, (for the same reason that you can't recover the details that provided the MD5) so you have to use some encryption techniques for the expiry date along with the MD5 hash.

This way, your user sends you some data that only his PC can produce, but he doesn't know exactly what you do to produce that data. You turn this into an MD5 string, and tell him the MD5 string. (which effectively is his license key). Every time his app opens the software calculates what the MD5 should be from the PC data, and if it matches, then the app opens. MD5 is a one-way function. It doesn't matter if they know how to produce an MD5 string. What they can't do is decode an MD5 string to get the "unencrypted string"

I used a lot of stuff provided by a very helpful guy called IzyRider on dbforums.

Try this link

http://www.dbforums.com/microsoft-access/1658694-licence-copyright-my-database.html

also the link IzyRider refers to in this thread, and other posts by Izy

David Crake (RIP) also posted a lot of helpful stuff on here in the code samples, and I may have uploaded some bits and pieces too.

IzyRider points out that if someone wants to go to the trouble of reverse engineering your code, they can work out exactly what you did do - hence using Waynes's code protector (and avoiding any public constants) makes this a bit harder. I actually encrypt some of my "constants" - so they are dimmed rather than constants, and are actually calculated by processing a "fake" constant to produce the real value.

ie, this sort of thing

and never


let's hope access doesn't do constant folding to defeat the purpose!