MDE and ACCDE files don't adequately protect your VBA source code.

Although compiled MDE and ACCDE files no longer contain the exact source code from the original file, they do contain a lot of extra compiler data that when combined with the compiled code, can be used to very accurately recover the original source code.  EXAMPLE

If you want to improve the protection of your MDE and ACCDE files, then you need to remove this redundant compiler data.  For this, you need Code Protector for Microsoft Access.

   Analyses your application and displays the vulnerable parts of your code

   Removes the vulnerabilities safely and securely (registered version only)

   Afterwards, decompiling the source code produces far less desirable results

   Supports Access files from v97 to v2016 (MDE, ADE and ACCDE file formats)

   Also includes support for Access 64-bit ACCDE file formats

   14 day money back guarantee

Single user licence cost: USD $110

---

 

What is this extra compiler data?...

Normal MDE and ACCDE files contain extra detailed information that we like to call compiler junk - this is redundant information about variable names, data types, constants and UDTs that are no longer needed in fully compiled files.

This compiler junk makes it much easier to decompile and reverse-engineer the VBA code in an MDE/ACCDE file to a standard that is very close to the original VBA source code (including, for example, all variable names).   In fact, for those that can prove ownership of their MDE/ACCDE files, we at EverythingAccess.com offer a service for reverse-engineering them including all VBA code.  You must be able to prove lawful ownership beyond any doubt for our service - but that is not to say that another company (or utility) won't offer a non-validated conversion service in the future.

The solution - Code Protector for Microsoft Access

If you want to properly protect your VBA code, then the solution is to remove the redundant compiler data from your MDE and ACCDE files completely which then makes it much harder and much less desirable for someone to decompile or reverse-engineer the source code. 

Removing the compiler junk does not prevent decompiling or reverse-engineering the VBA code, but it does make it very much harder and the result would be source code that does not look anything like the original source code (and therefore much less understandable).  

Example reverse engineered source code before and after protection  

FAQ: Doesn't the /decompile switch do this?

No.  The Access /decompile switch removes the compiled VBA code from an MDB file, ready for re-compiling.  As soon as the VBA code is compiled again, the compiler junk exists again.  Since all MDE and ACCDE files have to be compiled, the compiler junk is always present and makes it very easy to decompile your file (unless you use our Code Protector software).