From: David W. Fenton on
Banana <Banana(a)Republic.com> wrote in
news:4B7477CE.5050903(a)Republic.com:

> David W. Fenton wrote:
>> I think it would be relatively trivial to decompile an MDE that
>> isn't encrypted (and password-protected) to figure out what your
>> encryption code actually does.
>
> My understanding is to the contrary. It was mentioned to me by a
> non-Access programmer that it would be more difficult to decompile
> a MDE compared to an executable (whether compiled to machine code
> or to intermediate bytecode).

I didn't mean to imply that there are ready-made solutions to do
this, just that it's not even close to an impossible task. VBA is a
finite language and no doubt compiles to a finite symbol set. I'm
not sure how user-defined code and APIs compile, and maybe that's
the key, but I doubt it's an insurmountable task for the person who
wants to do it.

> There's plenty of decompilers out there for
> C-family languages & Java & .NET languages and even for Visual
> Basic. However, good luck finding a MDE decompiler to download &
> run with few clicks. Heck, none of those beforementioned
> decompiler are click'n'run.
>
> Here's a thread where Wayne Phillips, the guy who runs
> EverythingAccess.com and offer MDE to MDB conversion service
> agrees with this assertion:
>
> http://www.utteraccess.com/forums/showflat.php?Cat=&Board=81&Number
> =1877894

The key point there seems to be the assertion that you need the
source code to do the decompiling and that with an EXE you have
everything you need. Except you don't. Any modern EXE is going to be
linked to a host of DLLs and other outside libraries. In the case of
custom encryption code, you're not depending on anything but a
finite set of VBA commands (ones that are going to be quite
predictable, i.e., you don't need to be able to recognize
DoCmd.TransferSpreadsheet and the vast majority of VBA functions),
so I think that it makes things even easier.. If you are using the
Windows encryption functions (as I would think anybody with any
sense would), the link to those APIs is going to be identifiable
somehow, I'm sure (it's the first thing someone trying to crack
encryption would look for, surely).

So, while recreating an entire MDE by decompiling it is probably a
near-impossible task (and a waste of time anyway, since most
experienced Access developers can probably recreate the app just by
looking at it in less time than decompiling would take), if someone
is trying to crack encryption, they only need to figure out which
parts are relevant, and they should be able to figure out the
relevant symbols by creating their own MDE that does encryption and
then examining it and looking for the same things in *your* MDE.

> Also, if we're at the point of being sufficiently concerned about
> someone decompiling the program in order to extract the algorithm
> for salting & hashing, then we're most likely way past the point
> of Access being the right tool for the job, IMHO.
>
> Of course, if one is so worried about the possibility of someone
> decompiling, they could get Wayne's utility to strip out the
> symbols as well, but we should do very well to remember that the
> skill required to successfully decompile a program (whether it's
> an executable or a MDE file) would be very high and most likely
> out of reach for vast majority of users, even those who are
> otherwise fluent developers.

All of this is a discussion over something that belongs in the
database engine, not in the application. And that takes us back to
where we started -- the ACE really ought to have some form of real
security built into it, and it has nothing at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on
David W. Fenton wrote:
> I didn't mean to imply that there are ready-made solutions to do
> this, just that it's not even close to an impossible task. VBA is a
> finite language and no doubt compiles to a finite symbol set. I'm
> not sure how user-defined code and APIs compile, and maybe that's
> the key, but I doubt it's an insurmountable task for the person who
> wants to do it.

As I pointed out, the person with sufficient expertise to even attempt
this, even if only to target the encryption code, would be few and far
between. If this is such a concern, then this was the wrong solution.
Besides, the program is distributed within a network where it is
expected that no outsider would have access to so in theory, the people
with access to the program would be the employees.

I've already stated that not all security problems are solved by
technology, and the company has much bigger problems if they can't trust
their own employees to not decompile or otherwise circumvent the
security in place. The outside malicious hacker should be stopped at the
network firewall and therefore can't decompile what he doesn't have in
the first place.

Again, if the breach by malicious hackers is such a concern, this was
the wrong solution.

> The key point there seems to be the assertion that you need the
> source code to do the decompiling and that with an EXE you have
> everything you need. Except you don't. Any modern EXE is going to be
> linked to a host of DLLs and other outside libraries.

How is that going to be different from a MDE which doesn't have the
source code and links to several other DLLs such as VBA, Access object
library and whatever other?

Indeed, if one had sufficient skill to examine a compiled file and
extract information to compromise the security, this would be true
whether it's a MDE, a EXE or even whether the database engine has the
security mechanism in the place.

> All of this is a discussion over something that belongs in the
> database engine, not in the application. And that takes us back to
> where we started -- the ACE really ought to have some form of real
> security built into it, and it has nothing at all.

We're solidly in agreement here that ACE needs a security mechanism &
access control in place for contexts where it is not desirable to rely
on external mechanisms. However, it won't change that if we are
concerned about attacks from someone sufficiently proficient to
decompile a binary & extract the security logic, it won't stop them from
doing so to the ACE binary. It's our responsibility to be mindful &
consult with the clients with what is acceptable level of security - the
idea of perfectly secured object is achievable... by not having it exist
at all.