Copy protecting app

  • Thread starter Thread starter John
  • Start date Start date
J

John

Hi

Is there a way to protect an access app from copying or restricting its use?
If it is a software solution then its better as the app can then be emailed
to a prospective client instead of having to physically send hardware keys
as well.

Thanks

Regards
 
Yes, you can create an mde and user environ(username) (depending on version
of Access) to lock things down. For example in the onload event of the form,
you could lock it down by closing it.

Example:
if environ(username) <> "Jobob" then
docmd.close
end if

If they copy the DB or try and run it, if their Windows username is not
Jobob, then it will not run.
 
Is there a way to protect an access app from copying or restricting its
use?
If it is a software solution then its better as the app can then be
emailed
to a prospective client instead of having to physically send hardware keys
as well.

I create a custom property in the database to store the install date,
then check against this property when you opening the database.
__________________________________________________
NOTE: This function will only run once without crashing (property
already exists) so include error handling to trap the error (3311).

Function SetInstallDate()
On Err GoTo Err_Handler

Dim db As DAO.Database
Dim prp As Property
Dim dtmInstall As Date

'set installation date
dtmInstall = Date

Set db = CurrentDb

'define new property
Set prp = db.CreateProperty("Install Date", dbDate, dtmInstall)

'append new property to collection
db.Properties.Append prp

Exit_Here:
Set prp = Nothing
Set db = Nothing
Exit Function

Err_Handler:
Select Case Err

Case 3311
Resume Exit_Here

Case Else
MsgBox Err.Number
Resume Exit_Here
End Select

End Function
_________________________________________________
Use this function to check the system date against the property to
determine whether to kick them out.

Function IsLegal() As Boolean

Dim db As DAO.Database
Dim dtmInstall As Date

'read install date
Set db = CurrentDb
dtmInstall = db.Properties![Install Date]

'check if evaluation period is up
'or user has wound back system date
If dtmInstall > Date + 30 Or Date < dtmInstall Then
IsLegal = False
Else
IsLegal = True
End If

db.Close
Set db = Nothing

End Function
______________________________________________

In the OnOpen event of your splash screen use something like:

If IsLegal() = true then
' Just let them in
Else
MsgBox "Send money or say good-bye", vbOKOnly,"Exiting ..."
End If

I like this because it is reusable. Keep these functions
in a separate module and import them into any database where
you want to use them.

Of course you still need to have an MDE to keep them from
getting at the database properties. And you'll need to send them
a new front-end when they pay.
 
Arvin Meyer said:
I create a custom property in the database to store the install date,
then check against this property when you opening the database.

If they really know what they are doing and/or read these newsgroups,
then they can reset the property externally.

TOny
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Jobob said:
Yes, you can create an mde and user environ(username) (depending on version
of Access) to lock things down. For example in the onload event of the form,
you could lock it down by closing it.

Example:
if environ(username) <> "Jobob" then

What if the app is installed on a network and there are multiple
users, none of who you know ahead of time?

Also if you were start to start a command prompt you can then change
the environment variable using a SET statement. You can then start
Access using the command line which would use the spoofed environment
variable.

Finally someone could use a hex editor, go through the MDE looking for
the user name string and patch the MDE. Granted though the user name
would have to be the same length. No idea how Access would handle it
if the user name was shorter and padded with spaces or binary 00s.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
John said:
Is there a way to protect an access app from copying or restricting its use?
If it is a software solution then its better as the app can then be emailed
to a prospective client instead of having to physically send hardware keys
as well.

Tools available from sites such as sysinternals.com can crack any
method you use to store a future date anywhere on a system such as in
the registry or a file. Unless it's encrypted. But even then if you
delete the date from wherever it's stored your app may think it's just
installed.

Thus I prefer to limit the number of records in one key table such as
5 units or 50 volunteers but allow unlimited access for everything
else. Once I get paid then I email them an encrypted file containing
the number of records they are licensed for as well as their company
name which goes on the bottom of every page of every report.

For more of my thoughts on this topic see the "Copy protection or how
to safely distribute a demo Microsoft Access Application" page at
http://www.granite.ab.ca/access/demo.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Tony Toews said:
If they really know what they are doing and/or read these newsgroups,
then they can reset the property externally.

True, it is possible to crack almost anything. Locks are meant to keep
honest people out. It is possible to also embed the value within the code,
which is more secure, but some hacker will eventually crack through it. I
remember years ago watching my, then 13 year old, nephew crack through a
hardware dongle key in about 20 minutes.

Years ago, I created a delete bomb which did some serious cleanup work to a
database. I was worried that I wouldn't get paid. I wound up having to drive
over 200 miles to remove the bomb while trying to finish another project.
That was the last time I created anything that was "fool proof" since I'm
the one that turned out being the fool.

I have been ripped off 3 times in 15 years twice for small amounts, and once
for a significant amount. Fortunately, none of them kept food from the
table.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Back
Top