I have written an application in which I have included several advanced
levels of security by VBA, Microsoft Access built-in Authentications and
permissions etc...

The last most important part of my security on my software application is
having converted it to an MDE file. My question is that would there be anyone
smart enough to be able to crack my MDE application or is this a robust
procedure?

I also would like to know if there are people out there who could be smart
enough to dis-assemble my application and get my project Code. My main
concern is someone getting hold of my code which I do want to protect with a
high level of confidence.

Can someone advise me on this issue? If this procedure that I have done is
not practical or strong enough, can I get any good advice on what is the best
procedure to protect my Project Code? I would like to know of how I can
create a (.exe) file for my application with Access if possible. I would
greatly appreciate any help and guidance. Thanks.

Zikar <Zi***@discussions.microsoft.com> wrote:

MDE to MDB Conversion Service for Microsoft® Access
http://www.everythingaccess.com/mdeconversion.htm

Wayne has stated that he requires copyright proof.  To what extent I
don't know.

Compiled .NET is even easier to crack.

Tony

Thanks Tony for the reference. I guess the challenge for me now is to develop
a robust procedure which prevents anyone from being able to claim ownership
as my project is continuously being developed and therefore I cannot lock it
under a copyright. I wonder if the guys at everythingaccess have stringent
procedures to verify that their prospect contacts are genuine. Your help was
greatly appreciated.

Cheers


Show quoteHide quote

I suspect that the onus is on the client to testify (rather than prove) that
they own the copyright.  I further suspect that copyrighting a wheel that
works in a slightly different way to other wheels is a whole other can 'o'
worms.

Keith.

Keith, I thank you for the highlight you provided on this issue.

Zikar

Show quoteHide quote

=?Utf-8?B?WmlrYXI=?= <Zi***@discussions.microsoft.com> wrote in
Are you encrypting your MDE?

No, I am not encrypting the MDE. I thought that an MDE file is an encryption
by itself of the MDB. When you say encrypt do you mean encode or is it
creating a replica? I read more about what MDE provides and I believe I need
to do more.I would appreciate if you can explain on the advantages of
encryting and what method can be best applied.

Thanks


Show quoteHide quote

=?Utf-8?B?WmlrYXI=?= <Zi***@discussions.microsoft.com> wrote in
Encrypting the MDE is essential if you have an constants in your
code that would give away important information, such as usernames
and passwords. When you create an MDE, it throws away the code and
keeps only the compiled p-code, but it has to keep string values
that you type into the code literally. This means that a username or
password will show up in plain text in the middle of the binary
p-code. Because of that, you need to encrypt your MDE in order to
prevent someone from compromising it by browsing it with a hex
editor.

Or you encrypt those constants within the code.   And I further
obfuscate them.

Tony

Show quote Hide quote Hmm. Are you suggesting that Access's encryption is not sufficient?
It's stronger in 2007 than before, in fact.

No.   I just have no experience with it and don't want to bother with
it.

Tony

Uh, that would suggest you've never actually use Jet ULS?

It's pretty simple, actually -- a single step on the Tools |
Security menu. And then it's completely transparent to the user --
Access decrypts it when opening, without any additional steps
required.

I just can't see the point of writing code to encrypt/decrypt
strings in your MDEs when you can just do it the built-in way.

Show quote Hide quote Ah, but then I suspect the MDE won't zip/compress down as much as it
did previously.  That's one minor excuse.

Tony

Show quote Hide quote It won't compress at all.

Why would that be an issue?

Significantly more reliable to email a 1,355 kb zipped file than an
6,188 kb file.   Same with downloading the install package from my
website.

Tony

Show quote Hide quote I don't email, and I have remote access to most of my clients'
networks, though in almost all of those cases, I'd be doing
development remotely so there's no file transfer needed.

In terms of email reliability, I'm not sure what you mean. Certainly
many people have limits on the size of attachments, but the limits
I've encountered are mostly in the 10MB range. It's pretty easy to
put something on your website for download and vastly more efficient
than email!

I can't see any reliability issue when downloading from a website.
Perhaps you still have clients on dialup? In that case, I can't see
a whole lot of difference between 1355K and 6188K -- both would be
horrendous.

But none of that seems to me to justify hand encrypting your
constants. I just think that any MDE with sensitive constants in it
needs to be entirely encrypted, partly because of the fact that
encrypting part of it is just going to point out what's sensitive,
and then lead the industrious cracker to try to figure out how to
decrypt those particular strings. With a fully encrypted file, not
so much.

Show quote Hide quote Reliable wasn't the right word.  Convenient certainly is.   I do email
beta versions of my Granite Fleet Manager FEs to a few clients for
them to test and critique before making available on my website.

Those constants have lots of ASCII symbols and unreadable characters
in them so they blend in quite nicely with the random stuff in an MDE.
And they are further scrambled anyhow.

Again we are going to agree to disagree though.  Mind you it's always
good you are questioning my practices.  I'm forced to articulate
clearly my reasons.  Which may not have been so articulate at the
time.  <smile>

Tony

Before A2007, the encryption key was stored in the MDB file header.  That
vulnerability lead to a simple (and free) tool appearing on the web that lets
you decode an encoded MDB file without needing to know anything about the ULS
that may be applied.  Remember also that ULS and Access encryption are two
seperate things - however the two are usually applied together (e.g. when you
apply ULS, encryption is automatically applied).

Given the vulnerability (by design), the Access encryption is _very_ easily
reversed and therefore offers no real protection.  Once the free tool is used
to decode the protected file, you would then be able to get in with a hex
editor and dig around freely.

In A2007 the difference is that the database password is now used as the key
to the encryption layer.  Great, however in order to use the database you
need to release the password to your users... and therefore the encryption
can be removed easily by any of your users.  Oh the irony...

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?= <Wayne
Phill***@discussions.microsoft.com> wrote in
[quoting me, unattributed:]
Why would Access need to store an encryption key? You seem to be
confusing password protection (introduced in A2K) with encryption
(which was always part of Access going back as far as I'm aware,
i.e., Access 2).

I think you're completelly confused.

The *password* protection is very easily reversed, but not the
encryption.

Passwords have ZILCH to do with Jet encryption.

No, I'm not confused at all.  You are.

ULS security is TOTALLY independant of the 'encryption' Access uses.  ULS
can be applied with or without encryption (you can remove the encryption part
with the encrypt/encode menu options after applying ULS).  Similarly
encryption can be applied with or without applying ULS.

A little test for you... use the encrypt / encode menu option in the
Tools->Security menu on a new MDB database file (pre Access 2007) - this will
encrypt your file without ULS.   Now close and open the file in Access... and
then tell me how Access decrypts the file without prompting the user for the
encryption key.   I'll tell you how...  because it stores the encryption key
in the file header.

Indeed, the encryption has been offered way back in Jet and hadn't changed
until Access 2007.  Before Access 2007, the encryption is RC4 32 bit key and
in A2007 its RC4 with a 40-bit key by default (but can be increased in A2007).

Erm... no, I'm not.  You are.

You seem so convinced that you are right, yet I _know_ I'm right.

Why don't you apply your ULS and then head over to Serge Gavrilovs site:

http://accesstools.narod.ru/

Download MDB DeCryptor and decrypt your file.  Now open the file in a hex
editor... Suprise, suprise - the file no longer is encrypted.

Again you are wrong.

In Access 2007 ACCDBs the database password you set IS the RC4 encryption
key (well a hash version of it). 

You can choose to ignore me, or you can do a little more research and you'll
find everything I've said is correct.  I'm the guy that offers database
repair services, MDE to MDB conversion services etc - believe it or not, I do
know what I'm talking about. 

Wayne Phillips.
http://www.everythingaccess.com

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?=
<WaynePhill***@discussions.microsoft.com> wrote in
Show quoteHide quoteBut if you don't encrypt, you haven't fully secured your data. If
you're trying to protect information from being read, you don't just
want to block access to your data through Jet, but you also want to
prevent someone with a text editor from pulling out data by just
reading in an unencrypted form.

So, yes, you can apply ULS without encryption.

But that doesn't secure your data unless you encrypt it.

No, because the encryption key is stored in the Access executable
because it's the same for all databases.

Now, with passwords, yes, the encryption key is stored in the
database, because it *has* to be, since it's based on the password.

But for plain Jet encryption, there is no need for storing an
encryption key.

And it's not stored in the MDB.

Show quoteHide quoteAn encrypted file is not going to protect you if you aren't using
ULS (unless you're only using it to encrypt strings in the code of
an MDE). But if you are, they'll have to crack the ULS (which we all
know is easily done), and then they'll have access to your data with
no additional cracking necessary.

We had encryption before we had passwords. Explain how that worked,
then.

Yes. This is a changed, and a good change for those who find
passwords useful (I find them completely worthless).

But if you have an MDB and encrypt in A2007 without a password, the
password is not used as the encryption key, because, of course,
there *is* no password.

And you don't seem to understand some very basic things about Jet,
which leads me to believe that I should never recommend your
services.

Wrong.  I've already made my point... Jet encryption does *nothing* to
protect your data as it can be completely reversed independantly of whether
you have applied ULS or not.

Did you even try out the previously mentioned tool on one of your ULS
protected files (and then looked at the file with a Hex editor)?

This is the basis of my whole argument with you here:

Stating that the encryption offers better protection when the encryption is
fundamentally flawed, is wrong.  (Note that I'm talking prior to Access 2007
ACCDB file format here, obviously).


Agreed.  But Jet encryption is useless (prior to A2007 ACCDB file format)
for the reasons already explained.


But if you encrypt it (even with ULS), then it can be decrypted with ease
(using the tool aforementioned). 

So what's the point in doing that?  Jet encryption is flawed, so it's next
to useless. 

It is better to look at other methods, like Tony has.


No it is not.  Stop assuming things.  The encryption key is stored in the
file header. 

The encryption key is randomly generated when you create the MDB file and on
subsequent compact & repairs. 

It's a stupid argument since the effect is the same as if the encryption key
had been constant in the EXE ( - but it is not).


The encryption key IS stored in the file header.  Again stop making
assumptions when you obviously know nothing about what you are talking about.

You are still not understanding that ULS has _no_ effect on Jet encryption. 

Jet encryption is a completely independant layer of security and is not
affected AT ALL by ULS.


An encrypted file does NOT offer better protection if combined with ULS. 
Simple.

Frankly, I'm tired of repeating myself.


As I have said far too many times here... the random encryption key is
stored in the file header (- did you get that?). 

Neither database passwords, nor ULS passwords affect the encryption in
anyway.  (apart from A2007 ACCDBs database passwords which I've already
explained)


Me too.  A point I also made in my first post.  Worthless in the majority of
cases.


When I said Access 2007, I meant ACCDB files, not MDB files. 

If you use Access 2007 to encrypt an MDB file then it has the same effect as
encrypting it with Access 2003 (i.e. you do not benefit from better
protection).

It is the ACCDB file format that offers the better protection, not the
version of Access used.


It is you that does not understand some very basic things about Jet.

As an expert in recovering Access databases, over the years I've documented
the file formats completely. 

I know exactly what every single byte of data in a Jet/ACE database is and
does.  Can you say the same?

I think that puts me in a better position to comment than your good self. 
No offence intended.


I don't think I'll lose much sleep over that :)

Wayne Phillips
http://www.everythingaccess.com

For more detailed info, see this article I've just put up:

http://www.everythingaccess.com/tutorials.asp?ID=185


Personally I am not bothered whether you believe what I write is accurate or
not.  I know it's accurate - and that's what matters.

If you still think your approach of using ULS + encryption will stop a
determined person from reading/editing your file in a hex editor, then that's
your problem.  I can only advise.  Discussion over.

Wayne Phillips
http://www.everythingaccess.com

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?=
<WaynePhill***@discussions.microsoft.com> wrote in
[]

<plonk>

Thank you Tony again for this suggestion. As David explained, I do really
have a very important constant value within the code that would lead someone
to gain high level access permission to my project code i.e. entry level as
Database owner. I tried to look for references to help me understand how to
encrypt constants within the code but could not find one. I would greatly
appreciate if you could direct me to any documentation that explains this
with possible examples. Thanks.

Show quoteHide quote

=?Utf-8?B?WmlrYXI=?= <Zi***@discussions.microsoft.com> wrote in
I would suggest that encrypting the database via TOOLS | SECURITY
should be sufficient to your purposes. I've certainly always
considered it sufficient.

Thanks David for this clarification I will apply this method and see how it
would go.

Cheers

Show quoteHide quote

How to split Front end/Back end
HELP!
Password to Access back end file
Shortcut needs to work in a Domain instead of a workgroup
AllowBypassKey with an .MDE file
Locked out
I cannot open a DB created by another user on my PC.
I have Idea for solving problem the security for files by using
Workgroup file Access 2003
How to hide table using User-Level Security