(1) No-one had ever done so, and/or, they had not made it publically
available; and,
A decompiler does not publically exist, and will never be released by
EverythingAccess.com. Obviously, I can't guarantee others will not release
a decompiler in time, and that's why EverythingAccess.com will be helping
developers prevent reverse engineering of MDEs/ADEs (to such a high
standard) in the near future...
(2) It was commonly believed (by me & others) that none of the original
names existed in the MDE file; so the decompiler would have to use
dummy names like Sub1, Sub2, Sub3, Integer1, Integer2, Integer3, and
so on. This would make the sourcecode fairly-much unworkable, unless
the code was very simple
For many years this has been a common belief, but it is simply not true.
All the variable/procedure names/types/UDTs etc ARE all available in the
MDE/ADE file and can restored. Using this information, one can retrieve the
VBA code back to virtually the same standard as the original code.
Within the next month, EverythingAccess.com will be releasing an MDE/ADE
protection utility that will strip out all of this redundant variable
information. As TC suggests, this will make reverse engineering the code
much less feasible. For example, take this example code:
Public Function FnTest(abc As String)
Dim strValue As String
strValue = Forms("MyForm").Controls("MyTextBox").Text
Forms("MyForm").Controls("MyTextBox2").Text = strValue & abc
End Function
The normal reverse engineer results of that code in an MDE would produce the
*exact* same source code. However, if you strip out all of the redundant
variable information from the MDE, this has two major effects on the reverse
engineering process:
1. Variables/UDTs/Types lose their names and data types. A clever
decompiler could try to "guess" data types, but would have a hard time doing
so.
2. A decompiler (or engineer) wouldn't be able to distinguish between a
"real" variable versus a "compiler" temporary variable
Therefore the reverse engineered code would then look like this:
Public Function FnTest(Param1 As String)
Dim Variable1 As Object
Dim Variable2 As Object
Dim Variable3 As Variant
Set Variable1 = Forms("MyForm")
Set Variable2 = Variable1.Controls("MyTextBox")
Variable3 = Variable2.Text
Set Variable1 = Forms("MyForm")
Set Variable2 = Variable1.Controls("MyTextBox2")
Variable2.Text = Variable3 & Param1
End Function
Sure, an engineer could tidy up the above code manually, but a decompiler
would have a difficult time, thus making reverse engineering much less
feasible.
The utility to protect your MDEs will be available within 1 month at
EverythingAccess.com for a small fee.
I'd be very interested to hear from anyone who uses their service & can
confirm what they say.
I did an example conversion for Alex Dybenko MVP:
http://alexdyb.blogspot.com/2005/10/access-mde-to-mdb-conversion-service.html
TC, you know where to contact me if you would like a real example...
If it's true, here's what I would suggest. Put this code at the top of
every code module:
As TC said, put contact details and copyright info in every module, and also
in the normal places like in splash forms, summary info etc. We do a lot of
research on each file and our clients, and will only do MDE conversions for
businesses.
If you're really concerned, and want to stop someone with a hex editor
changing your copyright info in the file, consider making a hash-value of
your copyright info and comparing the string hash in your startup VBA code
or similar. If enough people want something like this, we can come up with
something to include in the MDE protection utility soon to be released.
Wayne Phillips
http://www.everythingaccess.com