MS Access program protection

  • Thread starter Thread starter Michael
  • Start date Start date
M

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?
 
Michael said:
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.
Click to expand...

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)
Click to expand...

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?
Click to expand...

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
 
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



-----------------------------------------------------------------------------------------
 
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
 
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
 
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.
Click to expand...

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.
 
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
Click to expand...

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.
 
Since there is a way to decompile a MDE file
Click to expand...

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.
 
David W. Fenton said:
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.
Click to expand...

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
 
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.
Click to expand...

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.
 
David W. Fenton said:
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.
Click to expand...

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
 
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.
Click to expand...

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?
 
David W. Fenton said:
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?
Click to expand...

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
 
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>
Click to expand...

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.
 
David W. Fenton said:
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.
Click to expand...

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
 
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.
Click to expand...

I think of this class of error as the "is it plugged in?" type.
 
Back
Top