MDE application cracking issues

[Zikar]

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.

 

[Tony Toews [MVP]]

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.

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

My main
concern is someone getting hold of my code which I do want to protect with a
high level of confidence.

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

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.

Compiled .NET is even easier to crack.

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/

 

[Zikar]

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

 

[Keith Wilby]

I wonder if the guys at everythingaccess have stringent
procedures to verify that their prospect contacts are genuine.

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.

 

[Zikar]

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

Zikar

 

[David W. Fenton]

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.

Are you encrypting your MDE?

 

[Zikar]

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

 

[David W. Fenton]

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.

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.

 

[Tony Toews [MVP]]

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

 

[Zikar]

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

Cheers

 

[David W. Fenton]

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

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

 

[Zikar]

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.

 

[Tony Toews [MVP]]

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

 

[David W. Fenton]

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

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.

 

[David W. Fenton]

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.

I would suggest that encrypting the database via TOOLS | SECURITY
should be sufficient to your purposes. I've certainly always
considered it sufficient.

 

[Tony Toews [MVP]]

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.

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

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/

 

[David W. Fenton]

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

It won't compress at all.

Why would that be an issue?

 

[Tony Toews [MVP]]

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

 

[David W. Fenton]

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.

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.

 

[Tony Toews [MVP]]

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.

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.

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.

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