Re: Access group security is imperfect; how good is MDE aspect?
- From: kiln <kiln@xxxxxxxxxxxxxx>
- Date: Sun, 5 Jun 2005 10:01:02 -0700
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.
In article <1117953955.422348.12830@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
aatcbbtccctc@xxxxxxxxx says...
> "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:
.
- Follow-Ups:
- References:
- Prev by Date: Re: Access group security is imperfect; how good is MDE aspect?
- Next by Date: Re: Access group security is imperfect; how good is MDE aspect?
- Previous by thread: Re: Access group security is imperfect; how good is MDE aspect?
- Next by thread: Re: Access group security is imperfect; how good is MDE aspect?
- Index(es):
Relevant Pages
|
