Hi,

I have an application that uses a lot of VBA. I put it in a protected password add in. But I am also worried of people moving to other companies and taking the program.

In the past I used a trick to put a couple of files in different folders and the program will verify the existence of those files before running.

The problem is that now with the new Windows versions, I cannot access automatically those folders (for instance c:\windows\system\) to create the files with the installation program (another VBA file to which only I have access). this is quite annoying and ogetn I have to create the file manually, which is a bit pointless if the user is just standing behind you...

Any suggestion to a similar procedure? a file, a windoes registry entry... .... anything that I can create, access, and delete from an Excel VBA application in any PC.

thanks.

Prtecting apps from unauthorized use is only effective for keeping
honest folk honest. Otherwise, there's not much you can do when your
app is not in a DLL or EXE. If someone wants your app badly enough,
there's free password stripper apps out there they can use to break
into your VBA (with macros disabled). Once there, they can
bypass/remove any code that restricts them from using the app.

If you can put your project in a DLL then it would be more difficult
for people to hijack it (but still not impossible). You could also
store an 'activation' file in the same folder, that contains encrypted
machine info so it won't run on any other machine than the one your
'activation' file is written for. This in turn should use an
'activation key' provided by you that your app requires at 1st startup.
Your app then writes the key into the encrypted file so it's available
on subsequent startups. Since the key is contrived from the machine
info in the activation file, the key will only work on the machine it
was created for.

Summary:
1. Put your app into a DLL or EXE.

2. Devise a methodology in your app for 'licensing' it to a specific
machine. This will require some consistent way to collect this on
different machines, as well as a consistent process for
encrypting/decrypting the data stored in the activation file.

3. Write an 'activation key' generator app for generating keys. Note
here that your distributed app will need to produce the same key from
the host machine info, thus both MUST use the same methodology.

4. Make sure your app is installed in a folder users have write
permissions for. This will be needed so your app can write the
activation file on 1st startup. This initial file will be missing a
'validation flag' until the user inputs your activation key.

Activation Process:

A. App creates machine info file on 1st startup.
B. User emails file to you.
C. You generate an activation key from the file info.
D. You email the key to the user.
E. User inputs the key at startup.
F. IF the key validates, your app rewrites the activation file
with a validation flag appended to the info so it knows not to
request a key for subsequent startups.

Notes:

- Your encrypted file should also be encoded in Base64 format for
emailing purposes. This precludes then, that your solution will require
an encrypt/decrypt algorithm AND Base64 encode/decode procedures.

- Your app will require use of WMI (or something similar) to collect
machine info. There are many examples out there for how to get this
info. I suggest using the BIOS serial number since the only way to
change it is by replacing the motherboard (which effectively makes it a
new machine and so will require you to provide a new activation key).


There's also free 3rd party solutions available, if you can't make your
own, which I'm sure some others will mention at some point.

HTH

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc