MS Access program protection

[Michael]

I just finished a MS Access 2003 program. The VBA code is protected with a
password in the *.mdb file. I compiled it into a *.mde file. I also disabled
the Bypass key (the SHIFT key to ignore startup options) while keeping a
secret password protected back door for me. I did not use database password
since there are lots of password crackers. But I do offer the user the option
to use or not a password saved in a table. I think that this password will
only stop the average people from snooping in his personal data. But a
programmer could use a “Microsoft.Jet.oledb.4.0†connection to list the
tables and queries and their fields, and therefore the data.

Q1: Data protection
I do not see how else to protect the data. But I can live with that flaw. I
do not want to use “user and group accounts†since not everybody wants to use
a password, and the user password popup will unfortunately always appear.

Q2: Program protection
Is it possible to decompile a *.mde file to extract the VBA code of forms,
report and modules, re-edit forms and report? (I disabled the Bypass key (the
SHIFT key) with AllowBypassKey property)

Q3: Copy protection
For now, I ask the user to E-mail me his MAC address. I hardcode his MAC
address in the program (a String global variable), and the program reads all
available MAC addresses of the computer for comparison. For now, it will do
since I do not have lots of orders, and I have very little publicity. But
when I will afford adds, and more frequent orders come, program keys will
have to be automated. How could that be done? Should the program be able to
communicate to a website database, some how?

 

[Tony Toews [MVP]]

Q1: Data protection
I do not see how else to protect the data. But I can live with that flaw. I
do not want to use “user and group accounts” since not everybody wants to use
a password, and the user password popup will unfortunately always appear.

If your data has strict data security requirements then using an
Access BE (backend) MDB is not the solution. SQL Server or equivalent
would be a far better solution.

Q2: Program protection
Is it possible to decompile a *.mde file to extract the VBA code of forms,
report and modules, re-edit forms and report? (I disabled the Bypass key (the
SHIFT key) with AllowBypassKey property)

MDE to MDB Conversion Service for Microsoft® Access
http://www.everythingaccess.com/mdeconversion.htm
Wayne has stated he will require proof that you own the code.

Q3: Copy protection
For now, I ask the user to E-mail me his MAC address. I hardcode his MAC
address in the program (a String global variable), and the program reads all
available MAC addresses of the computer for comparison. For now, it will do
since I do not have lots of orders, and I have very little publicity. But
when I will afford adds, and more frequent orders come, program keys will
have to be automated. How could that be done? Should the program be able to
communicate to a website database, some how?

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 and
frequently used forms.

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

I have thought of using the MAC address, once they've paid me the
money, however I would definitely give them 10 uses before it no
longer works. Just in case a problem happens on a weekend and I'm not
available, etc, etc.

Tony

 

[Michael]

About Q2: Program protection
Do you know if the MDE to MDB conversion service retrieves the VBA password
that I put? Does it re-enable the Bypass key?

Since there is a way to decompile a MDE file, I saw that your reference also
offers a product: “MDE Source Code Protectorâ€
http://www.everythingaccess.com/mdeprotector.htm

I guess this would be one of two ways to protect the source code?
The other way would be to remake the whole program using Visual Studio
Visual Basic? (While connecting to Access or SQL Server table with Visual
Basic)

There is no other way to protect the source code?

Thanks again,

Michael



-----------------------------------------------------------------------------------------

 

[Chris O'C via AccessMonster.com]

There are low cost tools on the Internet to remove the VBA password. If you
know where to look you can find out how to remove the VBA password for free.

Since you didn't apply user level security to your file, anybody can reenable
the shift key bypass on your file. Push Ctrl+G to open the immediate window,
paste this line of code and hit enter:

CurrentDb.Properties.Delete "AllowBypassKey"

Close the db and reopen it while pushing the shift key. Your startup
settings have been bypassed.

In case your users don't know to use that 1 line of code, they can find free
tools to set/unset the shift key bypass in any unsecured Access db. Albert
Kallal's is pretty easy to find. It's recommended often in these groups.

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Since you didn't apply user level security to your file, anybody can use the
link table manager to link to the tables and read the password you saved in 1
table.

Depends on how far you want to go, but you can apply user level security to
your file and nobody has to enter their user name and password when opening
the db. They'd still be blocked from certain things because they aren't
joined to the workgroup file you used to secure the db so don't have
permissions.

Chris

 

[Chris O'C via AccessMonster.com]

There are *many* more tools to decompile .net apps than there are to
decompile mdes.

Chris

 

[Chris O'C via AccessMonster.com]

So if the buyer swaps out a bad nic card or replaces his/her pc with a new
one, they have to come back to you to recode and reissue their app?

Do you tell them this when they buy your app or do you tell them after your
app stops working (or accuses them of being a pirate by making an illegal
copy)? Either way you'll make them mad but 1 of those choices will make them
madder.

Chris

 

[Michael]

How can I apply user level security to my file without creating a user and
still not have to enter user name and password when opening the db.

Thanks,

Michael

 

[Michael]

I tell them in advance about the MAC address restriction. And I also tell
them that I allow up to 5 MAC address change. I do not think that somebody
would have to change 5 times their network card. They would have to be very
unlucky with the same computer. After all, the price of that program is 15$
(even though I spent a few years perfecting this program, on and off part
time). If they like the program, they will pay if they need to change it more
than 5 times.

Michael

 

[Chris O'C via AccessMonster.com]

Joan Wild has the instructions here:

http://www.jmwild.com/SecureNoLogin.htm

Chris

 

[Chris O'C via AccessMonster.com]

It's not hard to clone a mac address or find out how. Googling clone mac
address I get almost 700K hits.

So 1 buyer pays $15 for one copy and hands out unlimited copies of your app
and the mac address it works for to everybody who wants it.

Chris

 

[David W. Fenton]

I
do not want to use ƒ ouser and group accountsƒ since not
everybody wants to use a password, and the user password popup
will unfortunately always appear.

If the Jet ULS username is the same as the user's Windows logon, you
can pass \usr %USERNAME% in the command line of the shortcut that
launches your Access app. Users with passwords will prompted for it,
those without a password will not.

 

[David W. Fenton]

Q3: Copy protection
For now, I ask the user to E-mail me his MAC address. I hardcode
his MAC address in the program (a String global variable), and the
program reads all available MAC addresses of the computer for
comparison

If you're not encrypting the MDE front end, or encrypting the MAC
address in your string constants, it's going to be available in
plain text for anyone browsing your MDE with a binary editor.

Tony encrypts his strings when he writes them into his modules so he
doesn't have to encrypt the MDE (so that it will still compress when
zipped). I believe that it's better to encrypt everything so as not
to draw attention to the particular strings that are encrypted.

Remember, constants are compiled literally into the code, so any
constant will be there in the compiled p-code every time it is used,
not just in the place where its value is declared.

 

[David W. Fenton]

Since there is a way to decompile a MDE file

That's not true. There is a way to evaluate the structure of the
compiled code and create something that at least partly replicates
the original code, but it's not going to look anything like the
original code, though it may behave equivalently.

Frankly, if you're worrying about someone stealing your MDE and
decompiling it, I think you're completely nuts. Your work is simply
not that valuable.

Certainly, none of my work is that valuable.

 

[Tony Toews [MVP]]

Tony encrypts his strings when he writes them into his modules so he
doesn't have to encrypt the MDE (so that it will still compress when
zipped). I believe that it's better to encrypt everything so as not
to draw attention to the particular strings that are encrypted.

The strings are encrypted and obfuscated. Chunks of the encryption
password are constants in different modules. ABC here DEF there,
GHI over there and so forth.

Tony

 

[David W. Fenton]

The strings are encrypted and obfuscated. Chunks of the encryption
password are constants in different modules. ABC here DEF
there, GHI over there and so forth.

For non-downloaded front ends, would you consider Access encryptiong
for it? I have a client who needs to store credit card numbers, and
it's going to be encrypted in the data table, so that means I have
to distribute an MDE and I'm going to encrypt the front end. There's
never any real need to download the front end, except for the
occasional update, and I have broadband and they have broadband, so
the full-size 5.5MB front end is not a terrible problem.

 

[Tony Toews [MVP]]

For non-downloaded front ends, would you consider Access encryptiong
for it? I have a client who needs to store credit card numbers, and
it's going to be encrypted in the data table, so that means I have
to distribute an MDE and I'm going to encrypt the front end. There's
never any real need to download the front end, except for the
occasional update, and I have broadband and they have broadband, so
the full-size 5.5MB front end is not a terrible problem.

I have no expertise on Access encryption so I don't know how good it
is. That said I've used the MS Crypto functions in the Auto FE
Updater and it seems to have worked. So maybe that would be a
solution to encrypt just that field.

Tony

 

[David W. Fenton]

I've used the MS Crypto functions in the Auto FE
Updater and it seems to have worked. So maybe that would be a
solution to encrypt just that field.

Back in 2004 I was using your updater and was encountering problems
with different versions of Win2K returning different results for the
encryption of the password. At the time, you were looking into it.
Did you resolve it eventually?

 

[Tony Toews [MVP]]

Back in 2004 I was using your updater and was encountering problems
with different versions of Win2K returning different results for the
encryption of the password. At the time, you were looking into it.
Did you resolve it eventually?

Oh yes, it was sheer stupidity on my part. I was passing different
arguments when encrypting vs decrypting.

I posted about the update and I think you asked me that question in
the newsgroup. <smile>

Tony

 

[David W. Fenton]

Oh yes, it was sheer stupidity on my part. I was passing
different arguments when encrypting vs decrypting.

I posted about the update and I think you asked me that question
in the newsgroup. <smile>

Ah, so it wasn't some exotic difference between the encryption
libraries on different versions of Windows.

If you aren't at bat, you never strike out, so making a mistake like
that is expected, since you're actively programming on a regular
basis.

 

[Tony Toews [MVP]]

Ah, so it wasn't some exotic difference between the encryption
libraries on different versions of Windows.

If you aren't at bat, you never strike out, so making a mistake like
that is expected, since you're actively programming on a regular
basis.

Oh, I have no problem admitting I make mistakes. <smile> I was
rather annoyed at myself for making such a simple, foolish mistake
that took me so long to figure out.

Tony