MDE Source Code Protector - Frequently Asked Questions

Please review our example page that details the changes that are made to each MDE file and the reasons why they are highly effective.

The product does not prevent decompilation (or reverse engineering) of the VBA code.  Instead, the product aims to make decompilation harder and more inline with decompiling standard VB6 applications.

Normal MDE files created by Access contain extra information that we like to call "compiler junk" - this is redundant information about variable names, data types, constants, UDTs etc that are no longer needed in a fully compiled MDE file.

However, this "compiler junk" makes it much easier to decompile/reverse-engineer the VBA code in an MDE file to a standard that is very close to the original VBA source code (including for example all variable names).

No.  The "compiler junk" is no longer needed and can safely be removed.  The "compiler junk" is only required when the database is not in a fully compiled state - (i.e. in MDB or ADP format).

There will be no effect on the performance of your code or indeed the logic by removing the "compiler junk".

Yes, but this isn't as effective as what the MDE Protector achieves.  Compilers (including the VBA compiler) make use of both explicit variables (declared by the developer) and implicit variables (declared by the compiler) in order to make everything work as it should.  By examining the "compiler junk", a decompiler can determine exactly which variables are implicit and which ones are explicit - using this information, the decompiler can then optimize the resultant source code by removing all implicit variables - this is key to making the resultant source code very accurate to the original. 

By removing the "compiler junk", the MDE Protector prevents a decompiler from determining whether a variable is real (explicit) or temporary (implicit), which means it has to treat all variables as explicit - this makes the resultant source code much less readable - see the example page to get an idea.

For an example of this, please look at the Example page.

Variables, UDTs and Enumerations that are declared by you as Public scope form part of the TypeInfo of the VBA module.  To explain, Public scope items should not be classified as "junk" because if you remove them from the TypeInfo of a VBA module, they will effectively become Private scope.  If you don't want an item to be publicly viewable, you should declare the items as Private rather than Public in your source code before compiling to MDE format. 

Therefore, the default options in the MDE Source Code Protector are to leave Public scope items intact.  However, you may change the default options if you wish, but beware that if you have late-binding code that requires a public-scope variable, UDT or Enumeration to be present, then the code will fail.  We recommend that you do not change the default options unless you have a specific need to do so.

Yes - ultimately we want you to be delighted with your purchase.  If you aren't, then just notify us within 14 days of purchase and we will refund your full payment. All that we require from you is that you tell us:

• your registered email address
• that you have uninstalled the software and won't use it again
• why the product didn't meet your needs (so we can improve the product)

Yes, as of version 1.25 you can now launch the MDE Source Code protector from the command line passing two arguments for the input MDE and output MDE file paths.  In doing so the application will launch and process the file without interaction from the user (as long as no problems occur).  The application will also close automatically once complete.

The simple command line arguments are displayed below:

 <PathToMDEProtector>\MDEProtector.exe "PathToInputMDE" "PathToOutputMDE"

Tip: The default path for the MDE Protector executable is '%programfiles%\EverythingAccess.com\MDE Source Code Protector for Microsoft Access'.

---

New in v1.29:

Extended command line support:

<PathToMDEProtector>\MDEProtector.exe "PathToInputMDE" "PathToOutputMDE" /rvX /rcX /rtX /reX

0 = Private Only

1 = Private and Public

2 = None

/rv is the equivalent of the 'remove module variables' option inside of the application.

/rc is the equivalent of the 'remove module constants' option inside of the application.

/rt is the equivalent of the 'remove module types' option inside of the application.

/re is the equivalent of the 'remove module enums' option inside of the application.