Access group security is imperfect; how good is MDE aspect?

[kiln]

As far as I can tell, Access group level security isn't particularly
effective against skilled hackers. The main reason for this is that the
encryption algorithm is supposed to be flawed. I'm not sure of this, but
I've read enough here to at least take the notion seriously. From this
perspective, and because it's a file based db system, I conclude that an
mdb Access database can only be secured to a degree.

However I'm curious if the encryption used for MDE files is as
vulnerable? My understanding is that an MDE simply removes the human
readable source-code, leaving only the lower-level compiled/tokenized
stuff. Can a hacker "restore" the VBA?

A related question, could a hacker somehow manage to get a form in an
MDE into design mode again, after moving it into an MDB? I'm not able to
do this, but I'm not a hacker.

These questions are relevant to my current interest in using Access for
the client end of a client-server setup. The app would be licensed for
distribution to various sites, and I'm trying to see how secure I can
make the front end in Access, to prevent or at least hinder reverse-
engineering.

 

[Douglas J. Steele]

Take a look at http://www.access.qbuilt.com/html/faq.html and draw your own
conclusions.

In my opinion, no desktop product is safe from hacking and reverse
engineering.

 

[kiln]

Take a look at http://www.access.qbuilt.com/html/faq.html and draw your own
conclusions.

In my opinion, no desktop product is safe from hacking and reverse
engineering.

Thanks, that is not good news but it is the info I was looking for.

So it is technically possible to rebuilt, if not exactly recover the
original code. I wonder if qbuilt is actually rigorous about the legal
ownership issues? They don't talk fly by night, but talk is cheap. In
any case, even if qbuilt is above board, someone else out there will
have a similiar capability, and won't be.

 

[TC]

"Encrypted" is not the right term for an MDE. MS have not deliberately
tried to make an MDE unreadable. It just happens that way, because the
technical specs for the MDE format have never been published or
reverse-enginneered, afaik.

Let's review what actually happens. I know you probably know this
already, but bear with me for a moment.

Source code such as VBA, is seldom executed directly by the "language
engine" (for want of a better word). There are just too many overheads.
For example, parsing the statement, checking its syntax, resolving
references to external items, and so on.

Many of those things need only be done /once/, no matter how many times
the statement is actually executed. For that reason, most "language
engines" perform a first pass over the source code, & convert it to a
simpler form: the so-called compiled code. The language keeps the
original source, so you can read and edit that; /and/ the compiled
code, so it can execute that.

That's what happens with VBA. Then, when you create an MDE, Access
simply discards the readable source, & retains the compiled form.

In summary, and here is my main point: MS would not have designed the
simplified form of the VBA, with a view to making it "uncrackable".
They would have designed it with a view to making it "easily
executable". So there is absolutely no reason why, in principle, you
could not put in the effort to reverse-engineer the compiled code
format.

This is fundamentally different to encryption, where /no/ feasible
amount of effort will decryt the code, unless you have the proper key.

However! Even if you could get or reverse engineer the specification of
the compiled code format, you'd never recover the original names of the
various objects (procedures, functions, variables, and so on). Those
are often not saved in the kind of process noted above. You'd have to
construct your own names: eg. Sub1, Sub2, etc. You would also never get
the Comments back, since they don't generate any code.

So, you'd never get back to this:

' initialize the data collection.
Call InitializeCollection (colData)
' amortize the amount of each member.
For Each vEntry in colData
Call AmortizeAmount (vEntry)
Next

All you'd get, is something like this:

Call Sub1 (Var1)
For Each Var2 In Var1
Call Sub2 (Var2)
Next

and so on.

For a complex system, the result would be fairly much unusable, even if
you could produce it.

Cheers,
TC

 

[TC]

Take a look at http://www.access.qbuilt.com/html/faq.html and draw your own
conclusions.

But they explicitly state that they /do not/ retrieve the sourcecode!

TC

 

[Douglas J. Steele]

But they explicitly state that they /do not/ retrieve the sourcecode!

That's not how I read what they're saying.

Q: Will the restored source code be exactly like the original source code
that we paid our developer for? For example, will the variable names and
procedure names be identical?

A: The restored source code will not be identical to the original,
line-for-line. The restored source code will have the same functionality as
the original source code, and will be either more efficient in speed and use
of system resources, or just as efficient as the original source code, but
not less.

 

[kiln]

But they explicitly state that they /do not/ retrieve the sourcecode!

TC

I agree with Doug, I think they are pretty clear that while they can't
get the original source, they can functionally reverse engineer the code
so that it works.

 

[kiln]

Hi TC, thanks for that extensive posting. I was a bit sloppy in using
the word encryption, but the reason I was sloppy is that I've not really
thought much about what an MDE really is, or how it differs from a MDB
file. So the fundementals were only lightly imprinted after having read
around a bit. You're explanation of the MDE format helps.

It is also make sense that on the qbuilt site they state that encrypting
the MDB before making it into a MDE makes it tougher (but not
impossible) to reconstruct the codebase. That makes sense in light of
what you've said.

It's all pretty darn interesting. Most of my apps over the years have
been for inhouse use by various companies, where keeping source code
hidden wasn't very important. Recently though there are some projects
which are likely to be distributed more widely, and these need to be
protected a bit more. I'm new to this angle on things...these are client
server setups, with SQL Server data stores. I don't think there is any
way to hide the table structures from the DB admins, so that part has to
be exposed...right? But the biz logic, code, form design etc would be
worth protecting. Because the forms will be visible to the users, and so
will the tables, I'd think an interested party could reverse engineer
the app regardless of the tools used (Access + SQL, or .Net + SQL, etc).
It could be reconstructed, but there is interest in making it non-
trivial to do so.

I'm not so sure that the reconstructed code would be so hard to work
with, as you've stated. Clearly whomever might be attempting to
reconstruct an app in this fashion (probably with the aid of a firm like
qbuilt) would be quite skilled, and interested.

 

[TC]

Owwww, you are right, I have boo-boo'd big time!

I started at: "Q: I've heard that it's impossible to convert an Access
MDE file back into an Access MDB file", then read through to a point
where I felt that they had clearly said, "we can not do it". On reading
further, now, I see they say that they /can/ do it. I didn't read far
enough, & came to a premature conclusion. Thanks for pointing that out.

However, I'm mystified, now, as to why they say that no-one has
developed an MDE decompiler. It seems, from what they have written,
that this is exactly what they /have/ done. Is that your reading of it?

Have you used their decompiling service or do you know anyone who has?
I'd be really interested to know what kind of code comes back. It's
clear, from what they have written, that they can "plug in" meaningful
names, if you send them those. But I wonder what the main bulk of the
code looks like?

Cheers,
TC

 

[TC]

Hi kiln

I clearly misread the qbuilt site, for which I apologize to all &
sundry! However, I am still a bit skeptical that they could produce
well-readable source code, without extensive (costly) human input,
and/or, considerable input from the original developer, as to what the
object names were in the original source-code.

But I've been wrong about them once so far, so I'm happy to be
corrected on this!

I've always said, previously, there there was no problem with
decompiling an MDE "in principle", but no-one had done it yet, so your
source-code was safe. It seems like this might not be true any longer.
With the proviso that, unreadable source-code is not much better than
no source-code!

I can't see why encrypting the db would make the decompiling any
harder. Anyone who knows how to find the decryption keys (as I do, and
they do) can decrypt an encrypted db, in a few minutes.

I'd be really interested in hearing from anyone who has used their
decompiling services. Please reply to this posting. Or if anyone wants
to comment privately, please feel free to email me via the button in
"Show options" of the new google groups interface.

Cheers,
TC